theme: healer-readable
这是我参与8月更文挑战的第5天，活动详情查看：8月更文挑战
回归测试 是一种用于测试产品的增量验证技术。它旨在验证在正在进行的开发过程中，产品的新变化没有破坏现有功能。为每个新功能添加新的测试用例可确保回归测试成功。
开发人员可能会发现它没有帮助，因为他们不仅必须修复通过回归报告的问题，而且还必须与 QA 保持同步，以了解影响系统行为的更改。然而，它也给测试人员带来了选择更相关、更现实和重复的案例的挑战。
回归测试适用于所有类型的测试模型。然而，它在敏捷测试中更成功。如果应用得当，从长远来看，它可以显着降低测试成本。它是同类测试方法之一，旨在建立对经历快速变化的软件的信心，而不会产生意外的副作用。
由于回归的范围会增加，因此手动进行是不可行的。最好的方法是选择与您的测试需求相关的自动化框架。然后创建测试套件，启动测试用例自动化，并减少手动测试工作。要利用这样的测试套件，请将其与 Jenkins 等 CI 工具集成并准备好在每晚运行。
什么时候执行回归测试有用？
我们应该在以下场景中采用回归测试方法。
- 在不断需要添加新功能的产品中。
- 用于测试产品增强，您希望最大限度地减少手动测试工作。
- 验证客户报告的缺陷修复。
- 当产品预期与其性能相关的变化时。
回归测试有哪些优点？
如果正确实施，回归测试效果最好。它提高了被测产品的质量，与传统方法相比具有以下优点。
- 通知我们由于模块或应用程序中的修复或增强而发生的任何副作用。
- 确保之前发现的错误不会再次出现。
- 它不仅可以手动完成，而且可以使用工具使其自动化。
- 它有助于提高产品质量。
- 在生命周期长的产品中，借助自动化可以大大减少人工测试的工作量。
回归测试有哪些缺点？
回归测试使测试人员在处理大型软件项目时的工作更轻松。但是，它有一些限制，我们可以通过本教程下一部分中提到的步骤来克服这些限制。
- 没有自动化，随着测试范围随着产品的每个新功能的增加而增长，很难管理回归测试的成本。
- 自动化回归需要熟练的软件工程师。
- 旧功能的更改导致相关测试用例的修改，这进一步需要版本控制。
- 测试新功能需要添加更多案例，这会增加维护成本。
- 它会影响项目预算的总成本。
- 回归测试必须在代码中发生的任何小的或大的更改上运行，因为最小的修改可能会降低现有功能。
回归测试有哪些挑战？
在以下场景中，回归测试对测试人员来说可能很困难。
- 大的是没有。在产品的功能中，更多的是没有。回归所需的测试用例。
- 执行大型回归套件需要时间，有时由于时间和预算限制而变得不可行。
- 每晚运行回归测试套件需要专用的基础设施或系统，这会产生额外的硬件成本。
- 优化测试套件以减少执行时间并实现最大测试覆盖率一点也不容易。
- 充分利用回归测试套件是一项挑战，因为它需要知道何时运行套件，即每次微小更改或每次构建之后或何时有一堆错误修复可用。
如何为回归测试选择测试用例？
您已经知道回归测试对于交付优质产品的重要性。测试用例是回归测试计划的主要元素，对使其成功的贡献最大。因此，不可避免地要选择最合适的测试用例来获得最好的结果。所以这里有一些想法供你思考。
1. 为缺陷最多的特性选择测试用例。
找出您的产品中出现最多错误的区域，只需对代码进行少量更改即可导致失败。通过查看每周/每月的错误报告，您很容易确定导致最大错误的区域。的缺陷。首先，您可以将这些缺陷添加到回归中，然后寻找增加该特定区域的测试覆盖率。
2. 为产品的核心功能选择测试用例。
在开始设计回归测试用例之前，一定要找出产品的核心领域。因此，了解需求规范，查看产品设计文档并提出对产品最关键的功能。因此，您可以继续选择测试用例并涵盖所需的功能。借助可追溯性矩阵，您可以确认测试覆盖率。
例如，在 Web 应用程序中，回归应涵盖诸如登录、仪表板、报告和主页上明显的其他核心功能等区域。
3. 关注产品最近更新区域的测试用例。
在敏捷世界中，需求经常变化。但大多数时候，变化只发生在产品的一部分。一旦产品的第一个版本准备就绪，由于增强或错误修复，可能会有 20-30% 的更改。在这种情况下，请尝试关注最近的更改并添加可能破坏现有功能的案例。
4. 选择涵盖集成测试的测试用例。
但是，集成测试是软件测试过程的一部分。但它的一些测试也应该与回归测试一起运行。它有助于排除产品因最后一刻的更改而错过重要功能的任何可能性。
例如，身份验证协议的更改可能会导致登录 API 失败，修复错误消息可能会导致报告 API 失败。
5. 选择所有端到端测试用例。
每个产品都有一些关键的端到端业务流，需要遵循 UI 操作的复合序列。
例如，要从电子商务网站购买产品，首先用户需要从特定类别中找到该产品，选择该产品，将其添加到购物车，如果有优惠券，则申请，选择付款方式, 提供联系方式/送货详情并继续付款。
通过在序列中添加更多操作，您可以增加发现严重错误的可能性。如果任何操作从链中绊倒，那么整个功能都可能崩溃。这就是为什么我们提倡将如此复杂的测试用例作为回归测试套件的一部分。
6. 根据回归测试的优先级过滤测试用例。
我们不能有一个不断增加无限期的回归。这些案例中。在某个地方我们必须停下来，我们应该通过做出明智和深思熟虑的决定来了解这一点。
所以开始对所有回归测试用例进行分类。具有优先类别，如 P1（非常高）、P2（高）、P3（中等）等。或者，您可以根据其功能分离测试用例。您甚至可以添加标签来过滤测试用例。它可能是一个发布标签、Service Pack 或 Patch 的标签。
将测试用例分为几个优先级背后的想法应该来自重要性和客户影响。
以下是一些软件测试人员可以应用来自定义回归测试执行的规则。
一、 如果错误的严重性和影响较低，那么从 P1、P2 和 P3 优先级执行一系列测试就足够了。
二、 如果错误的严重性和影响为中等，则执行所有 P1 和 P2 测试用例。但是，如果需要，测试人员也可以运行 P3 测试用例。顺便说一句，如果错误修复需要添加新的测试用例，那么它们也应该作为回归的一部分运行。
三、 如果错误的严重性和影响都很高，则执行所有 P1、P2 测试用例并包括一些选定的 P3 用例。
7. 选择要在旧功能更改时更新的测试用例。
客户要求重写旧功能的情况并不常见。然而，这样的事情确实会发生。开发人员必须对其进行修改。因此测试人员必须做出相应的响应。
- 产品功能的重大转变。
- 构建过程/先决条件已更改。
- 部分回归测试用例从未执行过。
- 回归测试周期仅包括几个选定的测试用例。
- 预计测试结果与上次执行会有很大的偏差。
执行回归测试需要哪些步骤？
回归测试的目的是在产品生命周期的各个阶段发现错误。为了实现这个目标，QA 团队和开发人员应该从一开始就设计一个有效的回归测试策略。在这里，我们列出了有助于成功进行回归测试的步骤列表。
第 1 步：建立需求和目标组件
确定产品是从头开始开发还是正在开发的产品部分很重要。过滤第一部分后，再深入研究并隔离发生更改的组件/模块。这就是人们如何确定什么应该成为回归测试的一部分。每当模块修复错误或向产品添加新功能时，您都应该重复此步骤。
第 2 步：选择自动化工具进行回归测试。
选择一堆满足您测试要求的自动化工具。评估并确定他们的优缺点。与业务利益相关者、开发人员和软件测试工程师讨论。并为您的项目或产品确定合适的工具。与所有相关方就当前和未来的成本达成协议。这是您需要执行一次的步骤，因此您必须非常清楚地选择正确的回归测试工具。
第 3 步：定义回归测试用例的输入标准。
入学标准概述了在开始测试之前要满足的最低资格或最少条件。因此，测试工程师应注意以下事项。
- 确保测试或缺陷是可重复的并且有适当的文档。
- 如果它是回归中要覆盖的缺陷，那么请检查其历史记录以识别和跟踪回归测试工作。
- 添加针对缺陷或测试需求的回归测试。
- 让利益相关者审查和批准测试。
第 4 步：定义回归测试用例的退出标准。
由于回归的范围随着新功能和缺陷的到来而不断增加，因此设置退出点很重要。与进入标准一样，退出标准也定义了在宣布测试阶段结束之前要满足的最低资格或最少条件。
- 软件测试工程师应在计划阶段完成此步骤并及时获得批准。以下是一些需要遵循的提示。
- 确保回归测试完成整个周期。
- 检查所需的代码覆盖率是否已准备就绪。
- 不要错过检查任何严重的错误或在批准后推迟。
- 最后，验证回归没有跳过任何“高风险”区域。
第 5 步：定义执行计划。
在完成上述步骤后，是时候决定测试执行的频率和时间表了。通常，最佳实践是在代码中发生任何提交之后运行回归。但是，为每个小的更改启动所有测试有点过头了。因此，您可以分割测试用例并对少数测试进行分类以确保完整性。您可以经常运行理智。但是，您应该准备每天至少执行一次完整的回归。
由于手动运行回归或部分回归是不可行的，所以更喜欢使用像 Jenkins 这样的持续集成工具。它会让你的生活更轻松。您可以使用它来配置测试以运行任何没有。次。它将让您以您希望的方式控制回归。
