回歸測試掃盲帖

相信做過測試的人對回歸測試都深有感觸吧。。。。特别是在進入Alpha, Beta之後，如果不幸發現産品的Bug不斷、持續、穩定的出現，那麼恭喜了，賣糕的知道需要做多少次回歸測試。

真實項目中，即使是相當順利地開發過程，通常也許要多輪的回歸測試。隻要是個正常人，在一輪輪的回歸測試轟炸下，相信都有發狂的趨勢。很多人把回歸測試當作枯燥、無趣、低端的工作，認為這種測試沒有什麼價值，對自己也沒有任何的提高。我猜存在這類想法的人主要有以下幾個原因：

1。 回歸測試次數過多。當QM無法正确的評估代碼改動對程式帶來的風險時，通常最簡單、最粗暴的方法就是“我們來一輪回歸測試”！當然，還有更粗暴的：來一輪Full Cycle！

2。 每輪回歸測試中使用的相同的測試用例。雖然說回歸測試的主要目的是驗證代碼的改動沒有影響到程式原來的正常功能，但是這不是說就應該用相同的測試用例去做測試。使用完全相同的測試用例，一方面會造成測試疲勞，另一方面測試的效果也不會很好。

3。 如何評估回歸測試的效果。是不是說回歸測試沒有發現新的問題就說明産品沒有問題，這次回歸測試的目标已經達到？其實回歸測試的本質目标是原來的産品代碼沒有引入新問題。回歸測試的用例僅僅說明這些測試用例沒有發現問題，而不是說新的代碼沒有對産品造成問題。是以如何評估回歸測試的效果是整個環節中最後，也是很重要的一點。

上面說了這麼多，我想大家也該明白要想真正的做好回歸測試，也不是一件容易的事情了吧。

無論做什麼，首先要明确目标！

回歸測試的主要目标通常可以劃分為：

1。確定系統的穩定性

2。對軟體的品質建立足夠的信心。

根據這兩類目标，回歸測試用例可以大緻分為：

1。針對修改的測試用例。這類測試用例的目标是確定修改的正确性。

2。確定系統品質的測試用例。根據測試覆寫率和風險選擇或者建立測試用例，用來保證系統品質“足夠好”

第一種類型的測試用例通常的原則是：

1。發現Bug的case重新run，確定結果正确。

2。分析Bug Fix對系統直接相關的其他部分有沒有影響。選擇一些cases來驗證。

這類測試的選擇一般都比較直接。相對較複雜的是如何選擇第二類測試用例，即如何保證系統整體的品質。

目前還沒有什麼通用的方法可以直接、友善、高效的選擇回歸測試用例。通常都是根據經驗法則去作相應的選取。