回归测试的几种方法

回归测试，是对修复Bug后的软件举行验证，确保所有缺陷得到修复，并且没有引入新的Bug。
如果确保缺陷得到修复，那么只需要实行发现缺陷的测试用例，但如许不能排除引入新的Bug；而如果把所有测试用例都实行一遍，可以确保没有新的Bug，但如许做又需要大量的测试工作量，大概代价太大。
所以，回归测试需要讲究方法、计谋。
以下是两种回归测试方法介绍。

• 基于用例的回归测试方法
  

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

• 全部回归
  

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

• 影响分析回归
  

影响分析回归是指通过变更影响分析，将变更点及受其影响的功能点所对应测试用例全部挑选出来举行回归。相较于全部回归，这种回归方法实行的用例较少，服从很高，但风险较大。如果影响分析不准确、不充实。大概会遗漏新的Bug。
为了降低风险，可以使用黑盒与白盒联合的分析方法：起首站在黑盒角度，找出变更点对应的业务，以及体系中与它关联的业务，画出业务功能的影响关系图，通过图中的影响业务网络回归测试用例；然后站在白盒角度，画出变更点的模块与模块之间、函数与函数之间的依赖图，从依赖关系中找出必测路径，对黑盒角度分析得来的回归测试用例查漏补缺。

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

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

• 巩固性回归
  

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

• 基于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%左右。
总之，要到达回归测试的有用性、充实性，又有较高的服从，选择合适的回归测试方法很重要。
末了： 下方这份完备的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【包管100%免费】

 这些资料，对于【软件测试】的朋友来说应该是最全面最完备的备战仓库，这个仓库也伴随上万个测试工程师们走过最艰难的路程，希望也能资助到你！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。