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