挑選有效的回歸測試用例

　　隨著系統的逐步成熟，每個版本包含的新特性越來越少，但是新功能對原系統的影響有多大是我們在測試時需要重點考慮的問題。此時，就勢必要進行回歸測試。而且系統越成熟，回歸測試的比重也會越大。這將會對測試工作帶來不小的挑戰。

　　在實際工作中，經常是一方面求全，希望覆蓋面盡量廣，避免漏測。另一方面求產出，大量的回歸測試用例，可能只發現很少的問題，投入與產出不太匹配，會影響測試人員的士氣，甚至測試管理者也會對這種投入產出有所質疑。并且，設計大量的自動化測試腳本，會占用大量的時間。

　　引子就說這么多，看看大家對這一普遍問題有什么看法和建議。

　　回答：

　　最近剛到新公司上班，面臨的比較突出的問題是人力緊張，由于公司的產品用在Windows mobile，MTK，Kjava，Symbian，website幾部分，測試人員<5(+上我)，如何高效的組織測試團隊確實是個挑戰?回歸測試屬于軟件測試環節比較重要的部分，所以花費了一些時間總結此文，希望能給測試人員稀少，產品或項目眾多的公司，提供一些建議:

　　所謂回歸測試，即就是在軟件生命周期中，只要軟件發生了改變，就可能給該軟件產產生問題;所以，每當軟件發生變化時，

　　我們就必須重新測試現有的功能，以便確定修改是否達到了預期的目的，檢查修改是否破壞原有的正常功能。

　　其實僅單純從英文單詞Regress很好理解:return to a worse or less developed state.即是退化，衰退的意思， 檢查軟件從正常的穩定狀態退化或是衰退到不正常工作的不穩定狀態。

　　注意：回歸測試不僅僅是針對在系統測試階段，而是在軟件生命周期中^_^

　　如果以上的定義均明確后，有效的回歸測試應從這幾方面：

　　其實最有效的回歸測試方法建立在開發測試庫的基礎上;開發在創建測試庫，每次生成程序的新版本時都可以運行這些用例。

　　只有有效的從源頭避免風險才能有效的進行回歸測試(目前國內的公司，能從事此級別的，太少)

　　1 強調單元測試時加強回歸測試，引入代碼評審，引入自動測試;

　　2 集成和系統級的測試時，加強測試用例評審，回歸測試用例的選擇;

　　具體的選擇可以參考以下幾點：

　　1 開發設計測試用例時制定優先級，如高，中，低，方便以后自動化或是策略選擇;

　　2 配置管理時，引入測試用例基線管理，有效管理測試用例;

　　3 定期維護測試用例增，刪，保持最新狀態;

　　回歸測試時需考慮效率和覆蓋度有效配合，通常的策略有以下幾種：

　　基于風險選擇測試：

　　哪些功能是軟件的特色?

　　哪些功能是用戶最常用的?

　　哪些功能出錯將導致用戶不滿?

　　哪些程序是最復雜、最容易出錯的?

　　哪些程序最容易擴散錯誤?

　　哪些程序是開發者最沒有信心的?

　　備注：只有有效的避免最大的風險，用戶反感的問題，回歸測試可以說達到了70%任務!

　　基于Regress衰退概念的測試：

　　開發人員修改的局部程序時，可能已經處理了癥狀，所以主要測試其被改變的模塊和它的接口上;

　　但是也可能存在未觸及到根本原因，所以需要測試周邊程序及相互依賴性的部分;

　　錯誤本身可能得到了修復，但修復也可能造成其他錯誤，所以有必要為每個修復的錯誤，設計回歸測試。

　　基于全面測試策略：

　　如果時間充足，資源齊全，可以進行全面測試,最低的遺漏回歸錯誤的風險，但測試成本最高，非上策!

　　其它的回歸測試：

　　1 基于GUI方式的自動化回歸測試技術

　　2 基于Ad Hoc 回歸測試：增加隨機測試，避免回歸測試肓點

　　3 基于交叉測試：多人互動的回歸測試，尤其在核心的功能點，交互性比較的

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