如何更高效的進行軟件回歸測試

如何更高效的進行軟件回歸測試   回歸測試策略

這個話題比較難定義，隨便談談自己的體會吧……

　　題目要求還是老傳統——“高效”！那就意味著必須有的放矢的實施工作，不能一股腦兒都重新來一遍。而“回歸”的核心并不是“執行”測試，其實是回歸測試前需要做的準備和測試后的結果分析。

　　1、回歸測試的前提

　　在第一次乃至第二次、第三次測試過程中，應該保存下來每次測試的缺陷記錄單和詳細缺陷描述表。且缺陷應該適當進行歸納和等級劃分。這個是定位回歸測試點“ 輕重”的前提條件。且必須考慮修正缺陷后，原有缺陷是否會給系統帶來相應功能模塊的連帶影響，孰輕孰重、及其范圍的大小。

　　2、回歸測試的執行

　　有了清晰的測試重點，那么對癥下藥很容易對先前出現過的缺陷再進行測試。而大型系統肯定是基于較完整的測試用例庫和測試腳本來執行測試的。利用自動化工具，對系統做一個完整回歸執行，可以明顯減少諸多成本。

　　3、回歸測試的分析

　　測試完了，結合工具跟蹤后得到的報表或統計分析圖，看原有缺陷的修正情況，以及該缺陷覆蓋周邊的最可能已經觸發的新缺陷。這點比較關鍵，測試開始前理清思路，現在分析時就一目了然。一般情況下，測試工程師回歸自己發現的缺陷很容易，如同樓上所說，僅靠腦袋里想法和自身累積的項目經驗即可完成回歸測試工作。

　　4、工具的結合使用

　　開發工程師往往只會對測試工程師發現的缺陷修正。然而，其他一系列新問題還是可能發生了，只找原發現的缺陷，肯定片面，還是會遺漏諸多新問題。如，回歸后，對系統帶來的新的嚴重的問題。所以，最好還是利用原先錄制好的用例和腳本對全局進行完整的自動化操作。否則，缺這補那，永遠難以結束復雜的“回歸”之路。性能測試更需使用工具來執行測試，不是么？

原文轉自：http://www.anti-gravitydesign.com