從年前開始做一個產品新build的regression 測試,因為是第一次接觸產品,之前沒有時間去了解功能,著實花了很多時間,連續加班半個月,還是有點累人的。在這里總結一下這大半個月的工作,從中學到知識得到成長。
結合實踐,我希望對regression有更加透徹的理解,以幫助日后的工作:
查了一些資料,先從原理來理解。
Regress 的英語定義是: return to a worse or lessdeveloped state
而Regression test 的意義在于:在新版本上運行所有已通過測試的case,從而驗證新版本的穩定性。
在軟件項目中,如果一個模塊或功能以前是正常工作的,但是在一個新的構建中出了問題,那這個模塊就出現了一個“退步”(Regression),從正常工作的穩定狀態退化到不正常工作的不穩定狀態。
在一個模塊的功能逐步完成的同時,與此功能有關的測試用例也同樣在完善中。一旦有關的測試用例通過,我們就得到了此模塊的功能基準(Baseline)。
如果這樣的“倒退”是由于模塊的功能發生了正常變化(由于設計變更的原因)引起的,那么測試用例的基準就要修改,以便和新的功能保持一致。
針對一個Bug Fix,我們也要作Regression Test。
?。?)驗證新的代碼的確把缺陷改正了。
?。?)同時要驗證新的代碼沒有把模塊的現有功能破壞,沒有Regression。
回歸測試最好要自動化,因為這樣就可以對于每一個構建快速運行所有回歸測試,以保證盡早發現問題。
結合上面的原理,我總結有以下幾點:
1. Regression測試主要目的是驗證模塊和功能是否出現倒退,以前修過的bug是否重新復發;
2. Regression測試除了圍繞上面兩個工作展開,還需要進行測試用例baseline的維護工作:
a) 模塊功能的正常變化所引起的不符合,需要及時更正case;
b) 把上一個版本所出現并且修復的缺陷及時的引入到case庫里面;
c) 把功能的變更和名稱的改動及時地反映到case里面;
3. Regression測試中也會遇到以前版本里面本來就存在但沒有被發現的缺陷,但這些缺陷不應該作為重點驗證的部分,因為regression測試的主要目的是發現因為修改而出現的倒退現象;
4. 為了節省時間和精力,節約成本,regression測試應該重點側重于分析因為上一版本所改動部分可能引起的問題并重點驗證,而不要過多的集中于一些邊緣測試和性能測試等;
這就是我這次項目所學到的東西,幫助我對下一次regression測試的效率和重點有所調整。也希望對你有所幫助!
原文轉自:http://www.anti-gravitydesign.com