回归测试简介

飞儿乐队

定义

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
在软件开发过程当中，一旦软件代码做了修改，就有可能引入新的问题，所以这个时候就需要把已经完成了
的验证用例重新跑一下，以确保代码的修改没有对已经验证过的功能造成影响。我们把这一个过程叫做回归
验证（也有人叫代码回归）。

目的

自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
方法

1、单元测试
2、功能测试

用例设计

（一）白盒技术
⒈逻辑覆盖：⑴语句覆盖。⑵判定覆盖。⑶条件覆盖。⑸条件组合覆盖。⑹路径覆盖。
⒉循环覆盖
⒊基本路径测试：每个可执行语句至少执行一次
（二）黑盒技术
1．等价类划分方法 是把所有可能的输入数据，划分成若干部分（子集）输入输出
2．边界值分析方法
3．错误推测方法
4．因果图方法
5．判定表驱动分析方法
6．正交实验设计方法
7．功能图分析方法

事例详解

代码的修改主要有几个方面：1、添加新的功能。2、修改现有代码中的功能。3、软件版本重构迭代更新等。
这时需要回归发现问题，以保证BUG确实被设计人员修复了。但是开发人员在修复BUG的时候有可能理解的
不够透彻，只修改了BUG的外在表现，而没有修复BUG的内在原因；也有可能是设计人员修复了一个BUG，
却引入了另外一个BUG，使原本验证通过的用例不能通过。所以在回归的时候需要进行分析，针对此BUG是
否需要增加新的用例，是否对原来已经验证过的用例有影响。这也是我们常常遇到的问题。【bug没修好，
新bug却被引入】

另外当代码当中增加或者删除了一些功能的时候，也需要进行了回归。
新代码加入的时候，除了新加入的代码当中有可能含有BUG之外，还有可能对原有的代码带来影响。当然删
除代码的时候也有可能造成影响。因此，每当代码发生变化，我们就必须重新测试现有的功能，以便确定修
改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时还需要补充新的测试用例来测试新的
或被修改了的功能。

那么是不是说，每发现一个BUG，或者代码稍有修改，我们都要把原来已经测试通过的用例重新跑一遍呢？

我觉得没有必要。因为我们验证整个或者单个模块，有可能开发成百上千条用例。随着验证工作的进展，测
试通过的用例会越来越多，如果在后期，每回归一次，可能就要跑成百上千条用例。而这一项工作需要很长
的时间和资源，会对项目的整体进度造成影响。尤其是项目如果采用迭代开发的方法，设计人员逐次提交包
含功能1，功能2，功能3…的代码。验证人员也是相应地完成功能1、2、3…的验证，不可能说在进行功能2
的验证时，把功能1的验证用例回归一下；进行功能3的验证时，把功能1，2的用例再回归一下。当然如果可
以，这样做是最好了。但是我们往往没有这么多的人员、时间和资源。所以每个在写单元测试是，单个模块
或文件写一个测试用例文件，当修改局部功能只需测试该部分的文件即可。

一般地，我们在所有的功能都验证完成了之后，会把所有的验证用例进行回归一次。就这一次回归，也是需
要很多时间和资源的。为了提高效率，需要开发一个回归脚本来完成这项工作。脚本需要具有自动完成验证
用例的提交，自动统计回归结果等功能。在项目做持续集成时或大版本发布前也是需要整体测试，做好回归
，做好代码覆盖率测试，以保证软件的质量和可靠性。