定义
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
在软件开发过程当中，一旦软件代码做了修改，就有可能引入新的问题，所以这个时候就需要把已经完成了的验证用例重新跑一下，以确保代码的修改没有对已经验证过的功能造成影响。我们把这一个过程叫做回归验证（也有人叫代码回归）。
目的
自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
方法
用例设计
（一）白盒技术
⒈逻辑覆盖：⑴语句覆盖。⑵判定覆盖。⑶条件覆盖。⑸条件组合覆盖。⑹路径覆盖。
⒉循环覆盖
⒊基本路径测试：每个可执行语句至少执行一次
（二）黑盒技术
1．等价类划分方法 是把所有可能的输入数据，划分成若干部分（子集）输入输出
2．边界值分析方法
3．错误推测方法
4．因果图方法
5．判定表驱动分析方法
6．正交实验设计方法
7．功能图分析方法
事例详解
那么是不是说，每发现一个BUG，或者代码稍有修改，我们都要把原来已经测试通过的用例重新跑一遍呢？
我觉得没有必要。因为我们验证整个或者单个模块，有可能开发成百上千条用例。随着验证工作的进展，测试通过的用例会越来越多，如果在后期，每回归一次，可能就要跑成百上千条用例。而这一项工作需要很长的时间和资源，会对项目的整体进度造成影响。尤其是项目如果采用迭代开发的方法，设计人员逐次提交包含功能1，功能2，功能3…的代码。验证人员也是相应地完成功能1、2、3…的验证，不可能说在进行功能2的验证时，把功能1的验证用例回归一下；进行功能3的验证时，把功能1，2的用例再回归一下。当然如果可以，这样做是最好了。但是我们往往没有这么多的人员、时间和资源。所以每个在写单元测试是，单个模块或文件写一个测试用例文件，当修改局部功能只需测试该部分的文件即可。
一般地，我们在所有的功能都验证完成了之后，会把所有的验证用例进行回归一次。就这一次回归，也是需要很多时间和资源的。为了提高效率，需要开发一个回归脚本来完成这项工作。脚本需要具有自动完成验证用例的提交，自动统计回归结果等功能。在项目做持续集成时或大版本发布前也是需要整体测试，做好回归，做好代码覆盖率测试，以保证软件的质量和可靠性。
【上一篇】单元测试简介
到此这篇回归测试简介_怎么做回归分析的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/te-hg/8587.html