軟體測試中的回歸測試用例選擇方法

回歸測試就是修改完bug後對程式的新一輪測試，根據微軟的統計，按照他們的經驗，一般開發人員解決3~4個bug會衍生出乙個新的bug，這就是必須作回歸測試的原因。

一般的軟體測試流程是後期快速迭代的，bug在後期是快速收斂的，debug和測試的週期也是越來越短，頻率是越來越高，譬如說第一輪測試需要花上10天跑用例，那麼到後期就沒那麼長的時間，可能就是1~2天的測試時間，在後期有時候一天就有乙個新版本，這時候就要求測試人員能快速的進行一輪回歸測試。

一般來說，覆蓋越高，風險越低，但是效率就越差，反之亦然。如果時間允許的話，能把所有用例都再跑一遍最好不過，但是一般不會有這個時間，這就需要在效率和覆蓋間找乙個適當的平衡，選擇一部分用例來進行回歸測試。

基於風險選擇測試：

哪些功能是軟體的特色？

哪些功能是使用者最常用的？

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

哪些程式是最複雜、最容易出錯的？

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

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

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

回歸測試優先選擇

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

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

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

第四，程式中最致命的部分，譬如說安全隱患，資料洩露，加密註冊

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

第六，程式的主幹功能

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