测试用例评审流程

当测试工程师编写测试用例时，他/她可能会跳过一些场景，输入，并编写错误的导航步骤，这可能会影响整个测试执行过程。

为了避免这种情况，我们将在开始测试执行之前进行一轮评审和批准流程。

如果我们不进行评审流程，我们将遗漏一些场景，准确性将无法保证，并且测试工程师也不会认真对待。

所有用例都需要在完成测试用例的编写后才发送以进行评审。 因此，其他人不会受到干扰。

一旦作者完成测试用例的编写，就需要将其发送给另一位称为评审员的测试工程师以进行评审。

评审员打开包含相应需求的测试用例，并检查测试用例的正确性，正确的流程以及最大的测试覆盖率。

在本次评审过程中，如果评审员发现任何错误，他/她会将错误写在单独的文档中，该文档称为评审文档，然后将其发回给作者。

作者会浏览所有评审意见，并开始进行必要的更改，然后再次将其发回进行评审。

这种更正过程将持续进行，直到作者和评审员都满意为止。

一旦评审成功，评审员会将其发送回测试负责人以进行最终的批准流程。

在批准过程中，始终将团队负责人纳入其中，以便作者和评审员都能认真对待他们的工作。

当编写，评审和批准测试用例后，它将被存储在一个集中的位置，该位置称为测试用例存储库。

注意

测试用例存储库

• 测试用例存储库是一个集中位置，用于存储所有基准测试用例（已编写，评审和批准）。
• 当客户提供需求时，开发人员开始开发模块，测试工程师将根据需求编写测试用例。
• 测试用例存储库用于存储已批准的测试用例。
• 任何测试工程师想要测试应用程序，则他/她只需要从测试用例存储库中访问测试用例即可。
• 如果我们不需要任何测试用例，则可以从测试用例存储库中删除它们。
• 对于每个版本，我们都会维护一个不同的测试用例存储库。
• 一旦测试用例被基准化或存储在测试用例存储库中，未经测试负责人的许可，就无法进行编辑或更改。
• 测试团队始终对测试用例存储库进行完整的备份，以防止影响软件的任何崩溃发生。

评审流程

在评审时，评审员会检查测试用例中的以下方面

模板

评审员检查模板是否符合产品要求。

头文件

在标题中，我们检查以下方面

• 是否捕获了所有属性。
• 所有属性是否相关。
• 是否填写了所有属性。

机身

在测试用例的主体中，我们将检查以下方面

• 应该准备测试用例，以便执行过程所需的时间最少。
• 是否涵盖了所有可能的场景。
• 查找流程，包括最大的测试覆盖率
• 是否应用了测试用例设计技术。
• 测试用例应易于理解
• 是否编写了正确的导航。

测试用例评审完成后，评审意见将被发送到测试用例评审模板。

评审员将使用上述模板并发送评论。 如果作者修复了测试用例，他/她会将其报告为已修复。

测试执行报告 [Excel]

这是最终文档，由测试负责人准备，用于在完成整个测试过程时。

测试执行报告定义了应用程序的稳定性，并包含了诸如编写，执行，通过，失败的用例数及其百分比的信息。

测试执行报告是最终的摘要报告，基于此报告，定义了应用程序的质量，它也有助于决定是否可以将应用程序移交给客户。

每个模块都有其各自模块的单独电子表格。

让我们看一个测试执行报告的示例，其中我们有不同的模块，例如销售，转账，税收，贷款。

测试负责人制作了此报告，测试工程师发送了他/她测试和执行的各个功能。

测试负责人将此报告发送给以下人员

• 开发团队
• 管理
• 测试经理
• 顾客

开发团队需要失败的测试用例的列表。

正如我们在下表中看到的那样，我们列出了测试用例名称，相关状态和注释。

下表显示了转账测试用例数据。

转账