顾名思义,回归测试是一种软件测试,用于确认最近的程序或代码更改未对现有功能产生不利影响。
这样做是为了确保现有应用程序具有新添加的功能,并且没有任何损坏。 为了实现这一点,现有的测试用例有选择地执行,有时甚至完全执行。 回归测试可确保新代码更改完成后,旧代码仍然可以使用。
在许多情况下进行回归测试-
- 更改现有功能的要求。
- 增加新功能
- Bug修复
- 技术变更/升级
- 性能修复
- 代码优化
回归测试可确保所做的更改不会在以前功能良好的现有功能中引入新的错误。 有时,现有功能本身的要求发生了变化,可能会影响应用程序的其他功能。 在这种情况下,将对其他功能执行回归测试。
如果由于过时的库而弃用了基础技术,则还需要进行回归测试。 为了确保这不会对功能造成任何影响,测试人员将执行完整的回归测试。
当开发人员进行代码优化或性能修复时,测试人员还将执行回归测试。
重新测试和回归测试-重新测试和回归测试之间是有区别的。 重新测试是在修复缺陷后测试软件/应用程序,以确保在执行回归测试时可以完全消除原始缺陷,以确保在开发新功能或更改现有功能时不引入新缺陷。
回归测试技术-通常,测试人员在每个版本的测试计划中都包括回归测试。 按照定义,应执行此步骤以确保新功能不会对现有功能产生任何影响,必须将其包含在每个发行计划中。 由于大多数组织遵循频繁发布的敏捷方法,因此通过持续测试和自动化来实现回归测试。 回归测试有多种技术-
- 全部重测-这是测试工程师执行所有现有测试用例而不会遗漏的技术。 这是相当昂贵的,因为它需要大量的时间和资源。
- 回归测试选择-在这种技术中,测试工程师根据影响分析选择一部分测试用例。测试选择的案例分类为
- 可重用的测试用例
- 过时的测试案例
在后续回归周期中使用的可重用测试用例。 在以后的循环中不使用过时的测试用例。
- 测试用例的优先级排序-根据业务影响,关键和频繁使用的功能主义者,对测试用例进行优先级排序
回归测试的类型
- 选择性–选择性回归测试是一种回归测试,测试人员从先前运行的测试套件和测试覆盖范围识别中选择测试用例。 为了执行此操作,测试工程师使用已运行的测试用例的子集来减少重新测试所需的成本和工作量。
- 完全–当软件的根代码发生更改时,将使用完全回归测试。 当对现有代码进行了多次更改时,也会执行此操作。
- 纠正–在现有软件/应用程序没有任何更改的情况下执行。 可以将已经存在的测试用例重新用于执行这种类型的回归测试。
- 部分分析–这种回归测试是在影响分析之后执行的。 测试工程师根据模块进行选择性的测试案例执行,这些模块会由于新代码合并而受到影响。
可以手动进行回归测试吗?
回归测试可以手动执行。 但是,如果应用程序很大且影响很大,则会导致效率低下。 而且,对于测试工程师而言,一次又一次地执行重复的测试用例非常无聊。
要执行回归测试,测试人员需要确定必须执行的测试用例。 很大,测试人员需要找出最佳组合并对其进行优化。
回归测试工具-回归测试用例可以自动化并按计划执行。 有许多可靠且可扩展的工具。 让我们看一些最受欢迎的工具-
- Winrunner –
- QTP –
- Watir –根据Watir网站,Watir代表Ruby中的Web应用程序测试。 通过模仿用户与网站交互的行为,它有助于编写自动化测试。 它支持多种浏览器,例如Internet Explorer,Chrome,Firefox,Opera和Safari。
它的最新版本是基于硒API的watir Webdriver。 - Selenium –
- actiWate –
- Rational Functional Tester –
- SilkTest –
- TimeShiftX –
- CloudQA- CloudQA为各种测试需求提供了一个统一的平台。 他们有一个带有集成报告的记录和回放工具,很容易用于创建和安排回归测试套件。 它还提供了与各种第三方工具的集成,例如-
- ALM工具(TestRail,TFS,Asana)
- 错误跟踪(Jira,BugTracker)
- CI / CD(Jenkins,CircleCI,TravisCI和DevOps支持)
- 开放式API集成
- 团队沟通(Slack,SMS,webhooks)
- 版本控制工具(Github,TFS)
翻译自: https://www.javacodegeeks.com/2019/07/regression-testing-tools-techniques.html