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

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

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

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、基於交叉測試：多人互動的迴歸測試，尤其在核心的功能點，互動性比較的。