如何为回归测试选择测试用例?

如何为回归测试选择测试用例?

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. 选择要在旧功能更改时更新的测试用例。

客户要求重写旧功能的情况并不常见。然而，这样的事情确实会发生。开发人员必须对其进行修改。因此测试人员必须做出相应的响应。

产品功能的重大转变。

构建过程/先决条件已更改。

部分回归测试用例从未执行过。

回归测试周期仅包括几个选定的测试用例。

预计测试结果与上次执行会有很大的偏差。