● 全部迴歸，也就是把之前的所有的測試用例，無論是手動的，還是自動的，全部跑一遍

　　● 部分迴歸，定性分析程式碼改動有哪些影響，程式碼改動的檔案/模組和其他的檔案/模組的依賴性，然後選擇被影響到的檔案/模組相應的測試用例來跑一遍

　　第一種的好處就是，通過大量的跑測試用例，可以儘量多的發現哪些功能是否有被影響到，缺點就是如果你的測試用例庫很大，那這個是相當消耗時間和人力的；

　　第二種的好處就是，不需要消耗大量的時間和人力，缺點就是因為是定性分析，所以有可能漏掉一些沒有被分析出的影響；

　　那麼有沒有其他第三種辦法，用定量分析的方法來進行迴歸測試，答案是肯定的，可以依賴程式碼覆蓋這個方式。

　　總的來說是這樣的：

　　1、每次跑完一個測試用例就把對應的程式碼覆蓋情況錄入關係型資料庫，這樣資料庫裡面就有了測試用例和程式碼覆蓋率的一一對應的表格。（程式碼覆蓋率可以是檔案級別或者是函式，類級別的）詳情可以見下圖：

　　2、對於修改的程式碼，分析是屬於哪個函式，類或者是檔案的，然後去資料庫查詢所對應的測試用例

　　3、這些對應的測試用例就是我們需要的，可能會因為程式碼改變而受到影響的測試用例。

　　比如，資料庫裡面已經有上面這樣一張表格，那麼假如開發修改了檔案File3裡面的程式碼，根據上面的表格我們知道TC2,TC3是和File3有關聯的測試用例，所以我們可以挑出TC2，TC3出來執行，這樣就是通過定性的方法來執行迴歸測試。

　　當然你的程式碼覆蓋也可以是函式級別的：

　　那麼當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。