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

問題描述：項目頻繁的改動，我們在做回歸測試的時候若選擇完全重復測試。把所有的測試用例，全部再完全的執行一邊，以確認問題修改的正確性和修改后周邊是否受到影響，但是如果把全部用例全部執行，會增加項目成本，也會影響項目進度。若選擇性重復測，不能確保周邊受影響的能測試到，請問如何更高效的進行回歸測試？

回答：

　　1、回歸測試基本策略及其評價

　　基于以上基本原則的闡述，回歸測試的基本策略目前有如下幾種，現一一進行闡述。

　　1.1 回歸測試方式

　　● GTRT：全面用例回歸測試選擇基線測試用例庫中的全部測試用例組成回歸測試包，這是一種比較安全的方法，再測試全部用例具有最低的遺漏回歸錯誤的風險，但測試成本最高。全部再測試幾乎可以應用到任何情況下，基本上不需要進行分析和重新開發，但是，隨著開發工作的進展，測試用例不斷增多，重復原先所有的測試將帶來很大的工作量，往往超出了我們的預算和進度（即使在引入了回歸測試自動化來緩解回歸測試的工作強度及時間進度壓力）。

　　● BRRT：基于風險的回歸測試可以基于一定的風險標準來從基線測試用例庫中選擇回歸測試包。首先運行最重要的、關鍵的和可疑的測試，而跳過那些非關鍵的、優先級別低的或者高穩定的測試用例，這些用例即便可能測試到缺陷，這些缺陷的嚴重性也僅有三級或四級。一般而言，測試從主要特征到次要特征。

　　● BORT：基于操作剖面的回歸測試如果基線測試用例庫的測試用例是基于軟件操作剖面開發的，測試用例的分布情況反映了系統的實際使用情況?；貧w測試所使用的測試用例個數可以由測試預算確定，回歸測試可以優先選擇那些針對最重要或最頻繁使用功能的測試用例，釋放和緩解最高級別的風險，有助于盡早發現那些對可靠性有最大影響的故障。這種方法可以在一個給定的預算下最有效的提高系統可靠性，但實施起來有一定的難度。

　　● BIRT：基于影響面分析的回歸測試當測試者對修改的局部化有足夠的信心時，可以通過相依性分析識別軟件的修改情況并分析修改的影響，將回歸測試局限于被改變的模塊和它的接口上。通常，一個回歸錯誤一定涉及一個新的、修改的或刪除的代碼段。在允許的條件下，回歸測試盡可能覆蓋受到影響的部分。

本文出自51Testing軟件測試網，感謝會員archonwang在每周一問（08-12-01）中的精彩回答。
http://bbs.51testing.com/forum-157-1.html

　　1.2 回歸測試基本策略

　　評價具體的回歸測試基本策略評價表如下所示：

　　圖表2　回歸測試基本策略評價表

　　全面用例回歸測試的策略是最安全的策略，但已經運行過許多次的回歸測試不太可能揭示新的錯誤，而且很多時候，由于時間、人員、設備和經費的原因，不允許選擇再測試全部用例的回歸測試策略，此時，可以選擇適當的策略，進行縮減的回歸測試。某一個項目的回歸測試往往是針對具體的情況，分別引用不同的執行策略而確定的。

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