我正在嘗試了解撰寫測驗用例的最佳實踐，但我有一個問題。
我正在開發一個復雜的 Web 應用程式，該應用程式目前有大約 10 個頁面和大約 60 個不同復雜性的測驗用例。
我對客戶登錄的賬戶主頁進行了回歸測驗，可以看到他們所有的賬戶和余額。此測驗涵蓋大部分（如果不是所有）可能的帳戶型別和方案。
現在假設我們發現了一個錯誤，其中帳戶型別為xxx的客戶總是看到余額比他們擁有的少 100 美元，我們修復了這個問題。
我應該撰寫一個新的測驗用例來測驗作業流程涉及登錄帳戶型別為xxx的帳戶并驗證其余額，還是應該簡單地運行覆寫該頁面的回歸測驗？
我對第一種方式的唯一擔心是，由于我們正在繼續開發，我們將在大約一年內完成 500 個測驗用例。
uj5u.com熱心網友回復：
由于發現了錯誤，我會避免增加手動回歸測驗的數量。
相反，我會
- 在錯誤單中添加可理解的“如何重現”步驟，以便開發人員可以重現它，并且在修復后，您可以對其進行驗證。
- 鼓勵開發團隊添加自動測驗，例如單元測驗，以驗證此問題是否已修復，并防止其在以后重新引入。一些開發人員默認這樣做，是的。
如果 #2 不可行，我會嘗試在現有測驗用例中嵌入檢查，在這種情況下驗證余額沒有意外減少 100 美元是有意義的。同樣，如果錯誤足夠重要，我只會這樣做。
我已經看到回歸測驗套件因“確保不會重新引入 2019 年 3 月的錯誤 x”而變得混亂。如果你不練習良好的回歸測驗套件維護，隨著時間的推移，這將成為一個野獸。
uj5u.com熱心網友回復：
是的，我建議它添加一個已報告錯誤的測驗用例，因為這樣我們必須確保它不會再次發生。
uj5u.com熱心網友回復：
這里有多種可能性：
如果在測驗執行期間發現的錯誤是基于現有測驗用例開發的，那么這意味著您根據發現的錯誤發現了新的測驗用例，因此如果這對回歸區域產生影響，則必須將其包含在回歸套件中。
如果在測驗執行期間發現的錯誤是基于臨時測驗的，那么它也可以包含在您的完整測驗套件中，但不能包含在回歸中，因為回歸套件涵蓋了主要受影響的區域
如果在測驗執行期間發現的錯誤是非功能性的，則可能不需要在測驗套件中創建或添加測驗用例
如果在測驗執行期間發現的錯誤是建議/增強（一些 QA 將建議視為錯誤），那么必須討論并基于此生成更改請求。
因此，基本上測驗用例管理是 QA 需要根據變更請求不斷更新測驗用例的程序。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/437531.html
下一篇：以正確的方式隱藏元素