业界的回归测试策略基本上有两种：
● 全部回归，也就是把之前的所有的测试用例，无论是手动的，还是自动的，全部跑一遍
● 部分回归，定性分析代码改动有哪些影响，代码改动的文件/模块和其他的文件/模块的依赖性，然后选择被影响到的文件/模块相应的测试用例来跑一遍
第一种的好处就是，通过大量的跑测试用例，可以尽量多的发现哪些功能是否有被影响到，缺点就是如果你的测试用例库很大，那这个是相当消耗时间和人力的；
第二种的好处就是，不需要消耗大量的时间和人力，缺点就是因为是定性分析，所以有可能漏掉一些没有被分析出的影响；
那么有没有其他第三种办法，用定量分析的方法来进行回归测试，答案是肯定的，可以依赖代码覆盖这个方式。
总的来说是这样的：
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。