我們在 Guru 中專注於知識分享，當我們發現一些新且有幫助的東西時，我們希望全世界都知道！ 我們的工程團隊在測試和質量保證過程中使用 Cypress。 他們發現了一種新的方法來幫助運行更好的燒測試，並希望與其他工程師和測試人員分享他們的新改進過程。

在過去的一年中，我們一直專注於增加我們的測試覆蓋率——特別是端到端測試，以確保隨著我們進行代碼更新，產品的不同部分的功能正確。 對於這種測試，我們利用一種名為 Cypress 的工具，它模擬用戶在我們的網頁應用程序和 Google Chrome 擴展上的行為。 這個測試套件在每一個拉取請求上運行，以確保新代碼不會破壞我們的用戶界面。 如果我們的 Cypress 套件在生產分支上失敗，我們也希望阻止版本的發佈。

我們在傳統測試中尋找什麼

我們遇到的一個問題是，看到部分測試失敗，但不是因為與用戶界面或代碼相關的原因。 那麼，Cypress 在這些情況下如何幫助我們呢？ 我們讓 Cypress 擔當用戶的角色，我們可以定義其行為。 有幾個變數可能導致 Cypress 告訴我們有故障，但從用戶的角度看，似乎沒有問題。

例如，可能有一個測試說：“轉到網頁應用的這個部分 > 添加新 Guru 卡片 > 期望看到創建後的狀態”。 如果創建卡片的加載狀態停留太久，而 Cypress 開始在狀態還不存在時查找創建後的狀態，這個測試可能會失敗（不過大部分情況下，測試應該會通過）。 如果它在拉取請求中通過一次，我們就可以合併可能有時候不穩定的代碼。 但我們無法確定；通過的測試並不保證代碼是正確的。

這種情況降低了我們測試覆蓋率的可靠性。 因此，當在我們的部署管道中出現測試失敗時，我們需要驗證這是 UI 的問題還是測試的問題。 為了解決這個問題，我們開始思考如何能在測試進入生產代碼分支之前檢測到可能的不穩定。

燒測試的幫助

進入燒測試。 燒測試是一種用於在更嚴格或極端條件下進行測試的過程。 根據不同的測試方法或特定領域，這有時也稱為壓力測試或負載測試。

在 Guru，我們將燒測試作為我們 Cypress 套件的一部分，適用於任何被添加到我們代碼庫的新或修改測試。 在這些測試合併之前，我們連續運行幾次，所有測試都必須通過，才能進入我們 CircleCI 構建管道的下一步。

這個步驟在我們運行整個 Cypress 測試套件之前立即發生。 這樣做的好處是，如果我們的燒測試步驟產生故障，我們可以儘早將整個檢查標記為失敗。 跳過其餘的測試套件使我們能夠節省時間，減少確保新引入測試的可靠性和容錯性所需的周期數量。

為了找到我們需要的文件，我們在當前分支上使用 git diff，並將輸出作為參數提供給一種稱為 cypress-repeat 的工具，它讓我們能夠以任何指定的次數運行這些測試，從而有效地將燒測試作為我們端到端測試套件中的一個步驟。

結果

對我們來說，對我們的測試計劃進行這一調整取得了一些非常實質性的正面結果。 對我們而言，增加燒測試可以減少找到不可靠測試所需的時間最多達 30 分鐘。  它還提高了添加新功能的周轉時間。 由於新添加的測試現在是第一個運行的，它們允許我們在繼續其他構建過程之前驗證穩定性。

總的來說，我們持續專注於使測試過程更有效率和穩健，提高了整個工程團隊對快速推出新功能的信心。 我們正在更快地修復錯誤，並使跨所有代碼庫的工作變得更加輕鬆。 我們希望這篇文章能幫助其他 Cypress 用戶創建更好的測試，並使整個團隊的建設更高效。