一個產品累積的測試用例越來越多，跑一次完全的回歸時間越來越長，如何有效管理巨量測試用例？

03-02

看到這個問題，我就想起了我之前自己的經歷，我也有過這樣的，最後還是靠分級的方式才解決的呢，我個人建議就是採取分級的方式來弄，或者就是使用面向對象測試法。接下來我們一起來分析一下吧！

首先要判斷，產品累計的越來越多是否正常，如果所有新增加的測試都有其價值，是應該增加的；而現有測試也都是仍有價值的，應該保留，那麼「累積了越來越多的測試用例」這件事情本身就不是問題，應該從後面兩個部分尋找解決問題的突破口。

接下來「回歸時間」在此就是說回歸測試的執行時長，這個時長取決於所執行的測試用例總數，以及單個測試用例的執行所需時長，加起來就是總的回歸時間。如果你是設置了自動化的還不行的話，你可以重構一下

管理的話可以

梳理，維度：功能點。對所有用例進行梳理，去掉無效，重複的用例，合併一些整體的用例
分級，維度：模塊。重要程度，影響面（我就是這樣）
優化，對重要模塊的case進行優化，最好達到完全自動化

一般的話都可以採取這些措施，如果還是不行的話，我記得在我們測試前期有一個步驟叫測試用例評審，它可以測試用例的質量、覆蓋面還有可以進行測試用例裁剪的方式！

如果你有實力的話，也可以多加的人，靠人力來補。

上面就是我之前在使用的解決的方法，你也可以去試一下，應該是可以的！

測試這個，首先我們要有目的性的去測試，

1.哪種節點要用到測試

2.什麼節點做到增量測試

3.測試的粒度到底是什麼,在此基礎上考慮用例的優先順序
4.如果是長期項目，功能穩定再考慮自動化
5.考慮如何提高個人效率而非盲目增加測試人員

隨著回歸時間的增長

「回歸時間」是指測試一次然後總過程所用的時間多長。個時長取決於所執行的測試用例總數，以及單個測試用例的執行所需時長，全部加起來就是總時長了。

如果，這些回歸測試都是手工執行，那麼我只有一個建議——趕緊做自動化吧。或者就是一個次優建議，挑選需要回歸執行的測試用例，通過減少需要執行的用例數量，來減少執行總時間。

如果，這些回歸測試都已經實現自動化，那麼我建議可以考慮檢查是否有需要重構的用例腳本。我自己曾經親歷的一個極端案例，某位leader聯繫我說他們有一個很簡單的測試用例居然要執行1個多小時，調查後發現的原因是因為採取了一些沒有必要的測試手段或者說測試動作所致，經過修改過後，該測試只需要1分多鐘即可執行完畢。另外還有就是，進行自動化實現的時候，模擬了手工執行的測試動作，但這些動作卻並不適合機器自動化執行，以至於事倍功半，拖長了執行時間。

通過採取上述一些動作，多多少少應該都能夠縮短一些總回歸時間。

我們如何去管理這個效率呢！

首先，是考慮「管理」，為什麼我們需要管理這些測試用例？如果我們在創建時可以遵循一些規範或約定，是否會有利於後續的管理（與或維護）工作？或者，是否是「管理工具」阻礙了我們的管理效率，革新我們的測試用例管理理念並選擇相應的工具是否可以簡化我們的管理工作需要？例如，借用Executable Requirements等一些理念，用純文本文件承載測試用例及腳本，設定文件夾結構規範，並用SVN、Git等版本控制工具進行管理。

接下來，可以從「巨量」入手。可以試問自己，測試用例的顆粒度是否過於小？是否可運用數據驅動方式減少需要管理的「測試用例」（單個文件承載同一功能或邏輯的多個測試）？

最後，再有我們自己本身去測試這些，和管理這些所謂的回歸時長和效率！

在一些測試團隊中，手工測試用例會在測試人員之間進行傳播，比如李雷寫了手工測試用例，韓梅梅則是用例的執行者。如果李雷的測試用例寫的比較抽象派和印象派，韓梅梅是很難去直接執行的，所以會有一些測試團隊強調盡量編寫可以讓人理解，也就是不用腦補的手工測試用例。但是寫的越精確花費的時間就越長，如果項目周期緊張的話，是沒有充足的時間去寫完備的測試用例的。判斷，越來越多是否正常，如果所有新增加的測試都有其價值，是應該增加的；而現有測試也都是仍有價值的，應該保留，那麼「累積了越來越多的測試用例」這件事情本身就不是問題，應該從後面兩個部分尋找解決問題的突破口。

通過測試用例異常處理分析：

1、僅僅只能保證已有的邏輯沒有問題，但是可能出現部分情況沒有處理導致失效的情況，可以通過後面的場景用例和需求用例來補充覆蓋。

2、邏輯裡面異常情況考慮不充分，導致測試用例也相對比較欠缺，可以通過對每個邏輯進行頭腦風暴，分析是否有其他異常情況，並且評審時重點評審這塊。

3、研發的邏輯有可能本身就是錯誤的，但是如果順著研發的邏輯去編寫用例時會導致用例也有問題，達不到測試目的，所以需要從需求和設計的角度去提前分析邏輯是否有問題。4、過程中研發的邏輯可能變化比較快，這樣會導致邏輯測試用例也要經常變化，所以需要保證研發的編碼是與設計一致的，並且邏輯是盡量根據設計來進行的。

另外，邏輯用例的設計可以在編碼中後期進行，這樣的改動會少點，從而減少測試時間。

可以從「巨量」入手。可以試問自己，測試用例的顆粒度是否過於小？是否可運用數據驅動方式減少需要管理的「測試用例」（單個文件承載同一功能或邏輯的多個測試）？　　最後，是否必須由「我們自己」來管理這些測試用例？