說到回歸測試用例，先說什么是回歸測試。顧名思義，回歸測試就是修改完bug之后對程序的新的一輪測試，據微軟的統計，按照他們的經驗，一般開發人員解決3~4個bug會衍生出一個新的bug，這就是必須作回歸測試的原因。簡單的說，就是檢測一下解決了bug之后有沒有帶進新的問題，以免把聾子給治成啞巴，就得不償失了~~
一般的軟件測試的流程是后期快速迭代的，bug在后期是快速收斂的，debug和測試的周期也是越來越短，頻率是越來越高，譬如說 輪測試需要花上10天跑用例，那么到后期就沒那么長的時間，可能就是1~2天的測試時間，在后期有時候一天就有一個新的版本，這時候就要求測試人員能快速的進行一輪回歸測試。
一般來說，覆蓋越高，風險越低，但是效率就越差，反之亦然。所以如果時間允許的話，能把所有的用例都再跑一邊是最好不過的，但是一般不會有那么多的時間，這就需要在效率和覆蓋之間有一個適當的平衡，選擇其中一部分測試用例用來作回歸測試。
選擇回歸測試的時候，首先要確定的是，回歸測試用例的比例，這個要根據時間情況了，100%是最好了，我個人一般這個比例在60%左右。然后要確定回歸測試用例的優先級。根據我的經驗，一般有如下必須回歸的用例：
，新修改的功能，這個顯然是重點
第二，新修改的功能的關聯功能，就是有耦合的部分，這個一般最好咨詢一下開發人員
第三，程序最有賣點或者說亮點的部分，這個地方一旦有問題，會使程序質量大打折扣
第四，程序中最致命的部分，譬如說安全隱患，數據泄露，加密注冊，
第五，程序中比較脆弱的部分，這個要咨詢開發人員，一般就是他們心中最沒底的地方 軟件測試
第六，程序的主干功能
第七，如果以上做完，還有時間的話，最好把用例中級別比較高的用例再執行一遍。
OK ，以上是回歸測試用例的選擇優先級。
其實，即使這樣做，還是有風險的。最根本的解決方法是自動化測試工具加上手工測試。具體就是常用的程序主干功能，主要功能，用自動化測試，保證每一個版本都能夠執行一遍，其他修改頻繁的小功能手工測試了。
說了這么多，好像比較亂，總結一下。
個人覺得解決這個回歸測試的終極解決方案是：
a.作每日構建
b.基線功能自動化
c.編寫用例時一定要分級(按照風險度，常用度，重要度)
d.手工執行回歸測試用例(就是我上面說的7項)
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
