業界的回歸測試策略基本上有兩種：
● 全部回歸，也就是把之前的所有的測試用例，無論是手動的，還是自動的，全部跑一遍
● 部分回歸，定性分析**改動有哪些影響，**改動的檔案/模組和其他的檔案/模組的依賴性，然後選擇被影響到的檔案/模組相應的測試用例來跑一遍
第一種的好處就是，通過大量的跑測試用例，可以盡量多的發現哪些功能是否有被影響到，缺點就是如果你的測試用例庫很大，那這個是相當消耗時間和人力的；
第二種的好處就是，不需要消耗大量的時間和人力，缺點就是因為是定性分析，所以有可能漏掉一些沒有被分析出的影響；
那麼有沒有其他第三種辦法，用定量分析的方法來進行回歸測試，答案是肯定的，可以依賴**覆蓋這個方式。
總的來說是這樣的：
1、每次跑完乙個測試用例就把對應的**覆蓋情況錄入關係型資料庫，這樣資料庫裡面就有了測試用例和**覆蓋率的一一對應的**。（**覆蓋率可以是檔案級別或者是函式，類級別的）詳情可以見下圖：
2、對於修改的**，分析是屬於哪個函式，類或者是檔案的，然後去資料庫查詢所對應的測試用例
3、這些對應的測試用例就是我們需要的，可能會因為**改變而受到影響的測試用例。
測試用例
**覆蓋（檔案級別）
tc1file1, file2
tc2file1, file2,file3
tc3file3
......
......
tcnfile1,
比如，資料庫裡面已經有上面這樣一張**，那麼假如開發修改了檔案file3裡面的**，根據上面的**我們知道tc2,tc3是和file3有關聯的測試用例，所以我們可以挑出tc2，tc3出來執行，這樣就是通過定性的方法來執行回歸測試。
當然你的**覆蓋也可以是函式級別的：
測試用例
**覆蓋(函式級別)
tc1func1,func2,func3
tc2func1,func2
tc3func1,func3
......
......
tcnfunc1
那麼當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。
***********************************=分割線******************************==
回歸測試的策略及方法
業界的 回歸測試策略基本上有兩種 全部回歸，也就是把之前的所有的測試用例，無論是手動的，還是自動的，全部跑一遍 部分回歸，定性分析 改動有哪些影響，改動的檔案 模組和其他的檔案 模組的依賴性，然後選擇被影響到的檔案 模組相應的測試用例來跑一遍 第一種的好處就是，通過大量的跑測試用例，可以盡量多的發現...
回歸測試策略
選擇回歸測試策略時,需要兼顧效率和效益,我們可從以下兩方面開展工作 1 測試用例庫的維護 刪除過時的測試用例 改進不受控制的測試用例 一些對輸入或執行狀態十分敏感的測試用例,其測試不易重複且結果難以控制,影響回歸測試的效率,需要進行改進,使其達到可重複和控制的要求 刪除多餘 重複的測試用例 增添 補...
回歸測試策略
策略一 重複所有測試，即窮舉法 策略二 重複一些測試 1.追溯法是測試和系統行為描述相關聯之處，系統行為描述包括諸如需求規約元素，設計規約元素或質量風險 2.利用變化分析，檢視系統的結構描述，找出變化的作用怎樣波及整個系統 3.利用質量風險分析，使用追溯法與變化分析，可利用技術風險 缺陷可能在 找到...