如何設計、挑選有效的回歸測試用例

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

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

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

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

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

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

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

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

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

基于風險選擇測試：

哪些功能是軟件的特色？

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

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

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

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

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

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

時間緊迫也可以采用80/20原則，把用戶經常操作、還有bug經常發生的地方進行完全的回歸或選擇有效的用例回歸，然后只要保證剩余的模塊不出現高等級的bug，其他的地方可以等時間空下來的時候測試人員再進行測試，如果軟件幾經發布，發現bug以補丁形式發布。

a.作每日構建

b.基線功能自動化

c.編寫用例時一定要分級（按照風險度，常用度，重要度）

d.手工執行回歸測試用例（就是下面說的7項）

第一，新修改的功能，這個顯然是重點

第二，新修改的功能的關聯功能，就是有耦合的部分，這個一般最好咨詢一下開發人員

第三，程序最有賣點或者說亮點的部分，這個地方一旦有問題，會使程序質量大打折扣

第四，程序中最致命的部分，譬如說安全隱患，數據泄露，加密注冊

第五，程序中比較脆弱的部分，這個要咨詢開發人員，一般就是他們心中最沒底的地方

第六，程序的主干功能

第七，如果以上做完，還有時間的話，最好把用例中級別比較高的用例再執行一遍。

OK、以上是回歸測試用例的選擇優先級。

基于Regress衰退概念的測試：

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

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

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

基于全面測試策略：

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

對于質量要求高的軟件，那就必須進行完全的回歸了，這時可以選用自動化工具（公司有條件可以自己開發工具），可以選用QTP,WR等。

在軟件沒有完全穩定的時候可以選用描述性編程。

其它的回歸測試：

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

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

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