业界的回归测试策略基本上有两种：

　　● 全部回归，也是把之前的所有的测试用例，无论是手动的，还是自动的，全部跑一遍

　　● 部分回归，定性分析代码改动有哪些影响，代码改动的文件/模块和其他的文件/模块的依赖性，然后选择被影响到的文件/模块相应的测试用例来跑一遍

　　第一种的好处是，通过大量的跑测试用例，可以尽量多的发现哪些功能是否有被影响到，缺点是如果你的测试用例库很大，那这个是相当消耗时间和人力的；

　　第二种的好处是，不需要消耗大量的时间和人力，缺点是因为是定性分析，所以有可能漏掉一些没有被分析出的影响；

　　那么有没有其他第三种办法，用定量分析的方法来进行回归测试，答案是肯定的，可以依赖代码覆盖这个方式。

　　总的来说是这样的：

　　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。