回归测试的几种方法

回归测试，是对修复Bug后的软件进行验证，确保所有缺陷得到修复，并且没有引入新的Bug。

如果确保缺陷得到修复，那么只需要执行发现缺陷的测试用例，但这样不能排除引入新的Bug；而如果把所有测试用例都执行一遍，可以确保没有新的Bug，但这样做又需要大量的测试工作量，可能代价太大。

所以，回归测试需要讲究方法、策略。

以下是两种回归测试方法介绍。

1. 基于用例的回归测试方法

基于用例的回归测试方法又可分为全部回归、影响分析回归、全部回归与影响分析回归结合以及巩固回归四类。

• 全部回归

顾名思义，全部回归就是把所有用例重新再执行一遍，这种回归基本没有风险，但是成本很高。当测试用例数目庞大，且软件版本不稳定时，即使是实现了自动化测试，结果也不会尽如人意。所以全部回归的策略可以用，但要少用，要用在关键点上。

• 影响分析回归

影响分析回归是指通过变更影响分析，将变更点及受其影响的功能点所对应测试用例全部挑选出来进行回归。相较于全部回归，这种回归方法执行的用例较少，效率很高，但风险较大。如果影响分析不准确、不充分。可能会遗漏新的Bug。

为了降低风险，可以使用黑盒与白盒结合的分析方法：首先站在黑盒角度，找出变更点对应的业务，以及系统中与它关联的业务，画出业务功能的影响关系图，通过图中的影响业务收集回归测试用例；然后站在白盒角度，画出变更点的模块与模块之间、函数与函数之间的依赖图，从依赖关系中找出必测路径，对黑盒角度分析得来的回归测试用例查漏补缺。

• 影响分析回归与全部回归相结合

如果软件开发一直在进行版本迭代，频繁提交的版本中会不断增加新功能，理想情况下除了测试新功能外还需验证原来的功能，但在进度紧张时这样做是不现实的。但如果一直到最后才进行全部回归，工作量将非常庞大，而且风险也很大。采取影响分析回归与全部回归相结合的方法，就是在小阶段进行影响分析回归，大阶段进行全部回归，最后在软件交付前再进行全部回归，以降低Bug没有及时发现的风险，同时也能减少过度测试，

• 巩固性回归

巩固性回归是在更改很小，基本不会影响原有功能的情况下，选择变更点对应的测试用例以及常用功能和重要功能的测试用例进行回归。它适合于更改很小的补丁发布版本。

1. 基于Bug的回归测试方法

基于Bug的回归测试方法也有彻底回归版本的Bug和回归缺陷库中所有Bug两种类型。

• 彻底回归版本的Bug

软件修复Bug后，要确保这个Bug得到解决，并且没有引入新的Bug并不容易。做好以下三件事有助于达成这个目标：

（1）记录Bug是如何修改的

开发人员修复Bug前应记录“Bug解决方案”、“影响分析”、“测试建议”等内容，指明更改对本模块、其他模块的影响，具体更改内容，以及给测试提出建议。

（2）开发人员确认Bug被更改

开发人员修复Bug后，先验证Bug更改的有效性，再提交给测试。

（3）记录Bug是如何回归的

测试人员完成回归测试后，应做好回归路径的记录。

• 回归缺陷库中的全部Bug

几乎有测试实战经验的朋友都遇到过，并不是缺陷库中每一个Bug都有测试用例对应的。因为有些Bug可能不是软件本身的缺陷导致的，而是受相关环境的影响导致偶然出现的。所以在软件交付前可以对缺陷库中所有的Bug回归一遍，验证是否仍存在。根据经验，这些Bug重新打开率在0.5%～1%左右。

总之，要达到回归测试的有效性、充分性，又有较高的效率，选择合适的回归测试方法很重要。

 

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取