前言
1、回歸測試就是修改完bug后對程序的新一輪測試。
根據微軟的統計，按照他們的經驗，一般 開發人員解決3~4個bug會衍生出一個新的bug，這就是必須作回歸測試的原因。
2、一般的軟件測試流程是后期快速迭代的，bug在后期是快速收斂的，debug和測試的周期也是越來越短，頻率是越來越高，
譬如說第一輪測試需要花上10天跑用例，那么到后期就沒那么長的時間，可能就是1~2天的測試時間，在后期有時候一天就有一個新版本，這時候就要求 測試人員能快速的進行一輪回歸測試。
3、一般來說，覆蓋越高，風險越低，但是效率就越差，反之亦然。如果時間允許的話，能把所有用例都再跑一遍最好不過，但是一般不會有這個時間，這就需要在效率和覆蓋間找一個適當的平衡，選擇一部分用例來進行回歸測試。
回歸測試時需考慮效率和覆蓋度有效配合，通常的策略有以下幾種：
基於風險選擇測試：
①哪些功能是軟件的特色？
②哪些功能是用戶最常用的？
③哪些功能出錯將導致用戶不滿？
④哪些程序是最復雜、最容易出錯的？
⑤哪些程序最容易擴散錯誤？
⑥哪些程序是開發者最沒有信心的？
只有有效的避免最大的風險，用戶反感的問題，回歸測試可以說達到了70%任務!
回歸測試優先選擇的測試用例：
①新修改的功能，這個顯然是重點
②新修改的功能的關聯功能，就是有耦合的部分，這個一般最好咨詢一下開發人員
③程序最有賣點或者說亮點的部分，這個地方一旦有問題，會使程序 質量大打折扣
④程序中最致命的部分，譬如說 安全隱患，數據泄露，加密注冊
⑤程序中比較脆弱的部分，這個要咨詢開發人員，一般就是他們心中最沒底的地方
⑥程序的主干功能
⑦如果以上做完，還有時間的話，最好把用例中級別比較高的用例再執行一遍。