業界的回歸測試策略基本上有兩種：
● 全部回歸，也就是把之前的所有的測試用例，無論是手動的，還是自動的，全部跑一遍
● 部分回歸，定性分析代碼改動有哪些影響，代碼改動的文件/模塊和其他的文件/模塊的依賴性，然后選擇被影響到的文件/模塊相應的測試用例來跑一遍
第一種的好處就是，通過大量的跑測試用例，可以盡量多的發現哪些功能是否有被影響到，缺點就是如果你的測試用例庫很大，那這個是相當消耗時間和人力的；
第二種的好處就是，不需要消耗大量的時間和人力，缺點就是因為是定性分析，所以有可能漏掉一些沒有被分析出的影響；
那么有沒有其他第三種辦法，用定量分析的方法來進行回歸測試，答案是肯定的，可以依賴代碼覆蓋這個方式。
總的來說是這樣的：
1、每次跑完一個測試用例就把對應的代碼覆蓋情況錄入關系型數據庫，這樣數據庫里面就有了測試用例和代碼覆蓋率的一一對應的表格。（代碼覆蓋率可以是文件級別或者是函數，類級別的）詳情可以見下圖：
2、對於修改的代碼，分析是屬於哪個函數，類或者是文件的，然后去數據庫查找所對應的測試用例
3、這些對應的測試用例就是我們需要的，可能會因為代碼改變而受到影響的測試用例。
| 測試用例 |
代碼覆蓋（文件級別） |
| TC1 |
File1, File2 |
| TC2 |
File1, File2,File3 |
| TC3 |
File3 |
| ...... | ...... |
| TCn |
File1, |
比如，數據庫里面已經有上面這樣一張表格，那么假如開發修改了文件File3里面的代碼，根據上面的表格我們知道TC2,TC3是和File3有關聯的測試用例，所以我們可以挑出TC2，TC3出來執行，這樣就是通過定性的方法來執行回歸測試。
當然你的代碼覆蓋也可以是函數級別的：
| 測試用例 |
代碼覆蓋(函數級別) |
| TC1 |
Func1,func2,func3 |
| TC2 |
Func1,func2 |
| TC3 |
Func1,func3 |
| ...... | ...... |
| TCn |
Func1 |
那么當func3函數有修改，我們就知道TC1，TC2，TC3都是相關的測試用例，就可以挑出TC1，TC2，TC3出來跑。（對於新增的函數，我們 只能通過文件級別的代碼覆蓋表格來找，因為之前沒有這個函數對應的測試用例，但是有這個函數所在的文件所對應的測試用例）。
此外，也可以通過數據挖掘，尋找出文件與文件直接，或者是控件（dll）與控件之間的依賴性，比如文件A引用了文件B的函數（可以通過“函數名”在代碼 庫里面進行全文搜索，就知道那些函數被其他函數引用了），那么他們就有了依賴性（A對B有依賴，如果C對A有依賴，那么C對B也有了依賴，這里面設計到遞 歸），控件1含有文件A，控件2含有文件B，那么控件1對2就有了依賴性；通過數據挖掘把依賴性尋找出來以后，如果文件B被修改，那么所有對它有依賴的文 件/控件有可能受到影響，我們就可以把這些對應的測試用例找出來跑一遍；
另外一種數據挖掘的方法是，通過bug數據庫來挖掘， 比如在執行TC1（目的是為了測試Component A）的時候發現的Bug，她的root cause是Compoent B，那么Component A和Compoent B就有了耦合關系，以此類推，就知道Compoent。