什么是回归测试?(定义、测试用例、示例)
什么是回归测试以及它是如何工作的?
回归测试是一种用于确保软件更新不会影响产品当前功能的测试。
这是为了保证任何新的功能、错误修复或对当前功能的修改都不会破坏产品。为了验证修改的影响,会重新执行之前执行的测试用例。
回归测试是一种软件测试,其中会重新运行测试用例,以查看应用程序以前的功能是否仍在正常运行,以及新的更改是否导致了任何新的缺陷。
当原始功能发生重大更改时,即使只是一个错误修复,也可能会在新版本上运行回归测试。
回归是指重新测试程序中未更改的元素。
何时应执行回归测试?
回归测试通常在修改或新功能验证之后进行。但这并非总是如此。对于需要数月才能完成的版本,回归测试必须包含在日常测试周期中。当对每周版本的修改进行功能测试完成后,可以运行回归测试。
重新测试的一种变体是回归检查(这仅仅是重复测试)。重新测试的原因可能是任何事情。假设您在一天结束时测试某个功能,并且您无法完成测试,并且被迫在未确定测试成功或失败的情况下停止该过程。
当您第二天返回时,您重复考试——这表示您正在重复您已经完成的测试。重新测试是重新进行测试的简单过程。
回归测试本质上是一种重新测试。应用程序/代码中有一些东西发生了变化,特别是对于这个独特的场合。它可能是代码、设计或任何其他决定系统整体结构的东西。
在这种情况下,回归测试是一种重新测试,用于确保修改不会影响以前正常运行的任何内容。
最常见的原因是由于代码的新版本被开发出来(由于范围/需求的扩展)或问题得到解决。
回归测试的目的是什么?
当程序员修复缺陷或为新功能添加新代码到系统时,就会发生回归。
新引入的功能和现有功能可能有很多依赖关系。
这是一个质量检查,以查看新代码是否与旧代码兼容,以便不会损坏未修改的代码。测试团队通常负责检查系统是否存在任何最后一刻的更改。
在这种情况下,只需要测试受影响的应用程序区域,以便在覆盖所有重要的系统元素的同时按时完成测试过程。
当应用程序持续更改/改进时,此测试至关重要。附加功能不应对已经过测试的代码产生不利影响。
回归测试对于查找由于代码修改而产生的问题是必要的。如果不进行此测试,产品可能在现实世界中存在重大缺陷,从而危及客户。
测试人员报告产品价格显示不正确的问题,即显示的价格低于产品的实际价格,必须尽快解决。
开发人员修复问题后,必须对其进行重新测试,并且还需要进行回归测试,因为虽然已更正报告页面上的价格,但它可能仍在摘要页面上显示不正确价格(总价与其他费用一起显示),或在发送给客户的电子邮件中。
如果不进行此测试,消费者将蒙受损失,因为网站使用错误的价格计算总成本,并通过电子邮件向客户发送相同的金额。如果在客户批准后以更低的价格在线提供产品,消费者将损失金钱。
因此,测试起着重要作用,既必要又实用。
回归测试类型
下面列出了多种回归测试类型:
-
单元回归 − 在单元测试阶段,代码是隔离测试的,这意味着禁用对被测试单元的任何依赖关系,允许单元独立测试而没有任何差异。
-
部分回归 − 部分回归用于确保即使对代码进行了修改并将单元与其他未修改或已存在的代码合并后,代码也能继续正常运行。
-
完全回归 − 当代码中的更改影响多个模块并且不知道另一个模块更改的影响时,使用完全回归。对整个产品进行回归测试,以查看由于更改的代码是否产生了任何修改。
回归测试技术
下面列出了多种方法。
全部重测
顾名思义,重新运行完整的测试套件,以确保代码更改不会导致任何问题。这种方法比其他方法成本更高,因为它需要更多的时间和金钱。
选择性回归测试
在此技术中,选择测试套件中的测试用例来重新执行。这与重新运行整个套件不同。测试用例的选择基于模块代码的更改。
测试用例有两种类型:可重用测试用例和已过时测试用例。可重用测试用例可以在后续的回归周期中重复使用,但已过时的测试用例不会在后续的回归周期中使用。
测试用例优先级排序
首先进行高优先级测试用例,然后进行中优先级和低优先级测试用例。测试用例的重要性取决于其关键性和对产品的影响,以及最常用产品的功能。
混合方法
混合方法结合了回归测试选择和测试用例优先级排序。仅选择基于其优先级重新执行的测试用例,而不是整个测试套件。
回归测试选择
回归测试选择是一种方法,其中运行测试套件中的一部分测试用例,以查看更新的代码是否对软件应用程序有任何影响。测试用例分为两类:可在后续回归周期中重复使用的可重用测试用例和不能重复使用的已过时测试用例。
测试用例优先级排序
根据测试用例的业务影响、关键性和使用频率对其进行优先级排序。如果对测试用例进行优先级排序,回归测试套件将大大减少。
回归测试用例选择
根据行业统计数据,客户报告的大部分缺陷是由最后一刻的错误修复程序造成的意外后果,这使得选择回归测试的测试用例成为一种艺术,而不是一项简单的任务。可以使用以下测试场景来创建有效的回归测试:
-
缺陷数量较高的测试场景
-
如果用户可见性更高,他们将能够看到更多功能。
-
测试产品基本功能的测试场景
-
近期发生重大更改的功能案例研究
-
所有集成测试用例
-
所有扩展测试用例
-
边界值测试用例
-
下面显示了一些成功的测试示例。
-
一些失败的测试场景
下面列出了回归测试的不同好处。
-
它提高了产品的质量。
-
这保证了任何错误补丁或添加的内容都不会影响产品的当前功能。
-
可以使用自动化技术进行此测试。
-
这将保证以前已解决的问题不会再次出现。
回归测试示例
我们将使用一个涉及图像处理软件开发的项目来演示如何进行回归测试。
讨论将基于现实情况,涵盖手动和自动回归测试。
但首先,让我们看看一些现实世界的例子,说明这种测试的不同之处及其重点;
-
错误回归 − 对声称已解决的错误进行重新测试。
-
旧修复方法 − 对以前已解决的所有问题和错误进行重新测试,以确保这些区域仍然功能正常。回归测试的创建目标就是如此。
-
转换/移植方法 − 在这种情况下,软件被迁移到不同的平台。下一步是运行回归测试,以查看迁移的软件是否成功集成。大部分更改将针对较新的环境,而不是之前的环境。
-
配置方法 − 在这种情况下,引入了更新版本的应用程序或设备,并且程序在其上或与其一起执行。转换测试与这种情况非常相似。但是,只有环境和与问题程序相关的少数组件会发生更改,原始代码或平台不会更改。
有几种可用于自动化回归测试用例的自动化工具;但是,应根据项目的需要选择工具。由于回归测试套件需要经常更新,因此工具应该能够更新测试套件。
至此,我们将结束讨论,并期望未来对这个问题会有更清晰的认识。