STLC 快速指南

---

---

STLC - 概述

STLC 代表软件测试生命周期 (Software Testing Life Cycle)。STLC 是一系列由测试团队执行的不同活动，以确保软件或产品的质量。

• STLC 是软件开发生命周期 (SDLC) 的组成部分。但是，STLC 只处理测试阶段。

• STLC 在需求定义或利益相关者共享软件需求文档 (SRD) 后立即开始。

• STLC 提供一个逐步的过程来确保软件质量。

• 在 STLC 的早期阶段，当软件或产品正在开发时，测试人员可以分析和定义测试范围、准入和准出标准以及测试用例。这有助于缩短测试周期时间并提高质量。

• 一旦开发阶段结束，测试人员准备好测试用例并开始执行。这有助于在初始阶段发现错误。

STLC 阶段

STLC 包含以下不同的阶段，但并非必须遵循所有阶段。阶段取决于软件或产品的性质、分配给测试的时间和资源以及要遵循的 SDLC 模型。

STLC 有 6 个主要阶段：

• 需求分析 - 当 SRD 准备好并与利益相关者共享时，测试团队开始对被测应用 (AUT) 进行高级别分析。

• 测试计划 - 测试团队计划策略和方法。

• 测试用例设计 - 根据范围和标准开发测试用例。

• 测试环境搭建 - 集成环境准备好验证产品时。

• 测试执行 - 产品的实时验证和错误查找。

• 测试结束 - 测试完成后，文档化矩阵、报告和结果。

比较 - STLC 和 SDLC

本章，我们将了解 STLC 和 SDLC 之间比较的因素。让我们考虑以下几点，从而比较 STLC 和 SDLC。

• STLC 是 SDLC 的一部分。可以说 STLC 是 SDLC 集的子集。

• STLC 仅限于确保软件或产品质量的测试阶段。SDLC 在软件或产品的完整开发中发挥着巨大而重要的作用。

• 但是，STLC 是 SDLC 中非常重要的阶段，在经过 STLC 流程之前，最终产品或软件无法发布。

• STLC 也是发布后/更新周期（SDLC 的维护阶段）的一部分，已知缺陷在此阶段得到修复，或向软件添加新功能。

下表列出了基于其阶段的 SDLC 和 STLC 之间比较的因素：

STLC - 测试基本原则

测试的共同目标是尽早发现错误。并且，一旦错误被修复，确保它按预期工作并且不会破坏任何其他功能。

为了实现这些目标，给出了软件测试的七个基本原则：

测试能显示什么？

测试可以显示存在缺陷，但无法证明产品中没有缺陷。测试阶段确保被测应用程序根据给定的要求工作，并且有助于降低应用程序中未发现缺陷的可能性。但是，即使没有发现缺陷，也不意味着它是完全正确的。我们可以假设 AUT 符合我们的退出标准并根据 SRD 维护需求。

是否可以进行详尽测试？

除了琐碎的情况外，不可能实现 100% 的覆盖率或对所有输入组合和可能组合进行测试。代替详尽测试，使用风险分析和优先级来定义测试范围。在这里，可以考虑包含大多数实时场景，包括最可能的负面场景。这将有助于我们跟踪故障。

尽早测试

测试活动应尽早开始，并应关注测试策略和预期结果中定义的目标。测试的早期阶段有助于识别需求缺陷或设计级别的差异。如果在初始阶段捕获到这些类型的错误，这将有助于我们节省时间，而且成本效益也更高。尽早开始测试的原因很简单——一旦收到 SRD，测试人员就可以从测试的角度分析需求，并可以注意到需求差异。

缺陷聚集

根据以前的产品缺陷分析，可以说大多数缺陷是从对应用程序至关重要的一小部分模块中识别的。可以根据复杂性、不同的系统交互或对其他不同模块的依赖性来识别这些模块。如果测试人员可以识别这些关键模块，他们可以更关注这些模块以识别所有可能的错误。在一项研究中发现，80% 的缺陷是从 AUT 的 20% 的功能中识别的。

杀虫剂悖论

什么是杀虫剂悖论——如果经常在农作物上使用杀虫剂，就会出现昆虫产生某种抗药性，并且逐渐喷洒的杀虫剂对昆虫似乎无效的情况。

同样的概念也适用于测试。这里，昆虫是错误，而杀虫剂是反复使用的测试用例。如果反复执行相同的测试用例集，这些测试用例在一段时间后会变得无效，并且测试人员将无法识别任何新的缺陷。

为了克服这些情况，应不时地检查和审查测试用例，并且可以添加新的和不同的测试用例。这将有助于识别新的缺陷。

测试依赖于上下文

此原则指出，除非两个应用程序的性质相同，否则不能使用相同的方法来测试两种不同类型的应用程序。例如，如果测试人员对基于 Web 的应用程序和移动应用程序使用相同的方法，这是完全错误的，并且存在产品发布质量较差的高风险。测试人员应针对不同类型和性质的应用程序使用不同的方法、方法、技术和覆盖范围。

无错误谬论

此原则指出，查找缺陷并修复它们直到应用程序或系统稳定，既费时又会消耗资源。即使修复了 99% 的缺陷，应用程序仍然存在不稳定的高风险。首先要验证应用程序的稳定性和环境的先决条件。如果这两个条件满足，只有这样我们才能开始详细测试。

STLC - 需求分析

需求分析是 STLC 的第一个阶段，它在 SRD/SRS 与测试团队共享后立即开始。让我们考虑以下几点来了解 STLC 中的需求分析。

• 此阶段的准入标准是提供 SRS（软件需求规范）；还建议应用程序架构可用。

• 在此阶段，质量保证团队在高级别上分析要测试的内容以及如何测试。

• 如果需要任何查询或澄清以了解需求，质量保证团队将与业务分析师、系统架构师、客户、测试经理/负责人等各种利益相关者进行跟进。

• 需求可能是功能性的或非功能性的，例如性能、安全、可用性等，或功能性和非功能性兼而有之。

• 此阶段的准出标准是完成 RTM 文档、自动化可行性报告以及如有必要更具体地说明需求的问题列表。

需求分析执行的活动

在此阶段，质量保证团队执行三个主要活动。下面描述了这些活动。

定义范围

测试团队在高层次上确定测试范围，并将其划分为不同的功能模块。团队还确定需要执行的测试类型——冒烟测试、健全性测试、功能测试、回归测试等。测试团队分析测试所需的前提条件和环境细节。团队收集有关测试优先级的详细信息，并重点关注要验证的模块顺序。如果模块之间存在矛盾，并且功能无法与其他模块一起延续，它还会识别需求缺陷。

准备RTM

需求追踪是记录需求与其为实现和验证这些需求而开发的工作产品之间链接的过程。RTM在一个文档中捕获需求分析中的所有需求及其可追溯性。所有这些都在生命周期结束时交付。

矩阵是在项目开始之初创建的，因为它构成了项目范围和将要交付成果的基础。

矩阵是双向的，因为它通过检查交付成果的输出向前跟踪需求，并通过查看为产品特定功能指定的业务需求向后跟踪需求。

自动化分析

在需求阶段，测试团队分析回归测试的自动化范围。如果自动化被添加到范围内，团队将决定可以使用哪个工具，哪些功能将被覆盖为自动化，以及自动化开发涉及的时间范围和资源分配。一旦此分析完成，测试团队将向不同的利益相关者提供自动化可行性报告以获得签字。

STLC - 准入和准出标准

在本章中，我们将了解STLC不同级别的进入和退出标准。需要考虑以下几点才能理解这些标准。

理想情况下，除非当前阶段的退出标准得到满足，否则测试团队不会进行下一阶段的工作。进入标准应包括上一阶段退出标准的完成。

实际上，不可能等到退出标准满足后再开始下一阶段。现在，如果上一阶段的关键交付成果已完成，则可以启动下一阶段。

在STLC的每个阶段，都应定义进入和退出标准。

进入标准

STLC阶段的进入标准可以定义为特定条件；或者，在进入任何STLC阶段之前，应该存在所有需要启动特定阶段的文档。

进入标准是一组允许执行任务的条件，如果没有这些条件中的任何一个，则无法执行该任务。

在设置进入标准时，还必须定义进入标准项可用于启动流程的时间范围。

例如，要启动测试用例开发阶段，应满足以下条件：

• 需求文档应该可用。
• 需要完全理解应用程序流程。
• 测试计划文档应该准备就绪。

退出标准

STLC阶段的退出标准可以定义为在结束当前阶段并进入下一阶段之前必须完成的项目/文档/操作/任务。

退出标准是一组期望；在结束STLC阶段之前，应该满足这些期望。

例如，要结束测试用例开发阶段，应满足以下期望：

• 测试用例应该已经编写并审查。
• 测试数据应该已经确定并准备就绪。
• 如果适用，测试自动化脚本应该准备就绪。

STLC - 验收标准

验收标准是指需求文档中列出的功能、模块和应用程序的预期行为。它是验证阶段/检查点，用于确定软件系统是否满足需求规范。此测试的主要目的是评估系统是否符合业务需求，并验证其是否满足所需标准。

验收标准是一组语句，清楚地说明了预期的通过/失败结果。验收标准指定了功能性和非功能性需求。这些需求代表“满意条件或预期行为”。没有部分验收；要么满足标准，要么不满足标准。

这些标准定义了功能/模块的边界和参数，并确定功能/模块是否已完成以及是否按预期工作。

高级验收标准在测试计划级别提到。验收标准转换为在测试用例级别要验证的要点或预期结果列表。

验收标准基于以下属性定义：

• 功能正确性和完整性
• 数据完整性
• 数据转换
• 可用性
• 性能
• 及时性
• 机密性和可用性
• 安装和升级能力
• 可扩展性
• 文档

STLC - 测试计划

测试计划概述了将用于测试应用程序的策略、将使用的资源、将执行测试的测试环境以及测试的局限性和测试活动的进度安排。通常，质量保证团队负责人将负责编写测试计划。

测试计划包含什么？

测试计划包括以下内容。

• 测试计划文档的介绍。
• 测试应用程序时的假设。
• 测试应用程序中包含的测试用例列表。
• 要测试的功能列表。
• 测试软件时要使用的方法。
• 需要测试的交付成果列表。
• 分配给测试应用程序的资源。
• 测试过程中涉及的任何风险。
• 要实现的任务和里程碑的进度安排。

测试计划的重要事项

在STLC中进行测试计划时，需要考虑以下几点。

• 理想情况下，测试分析师（主管）/经理准备测试策略/测试计划文档。

• 分析更侧重于应用程序相关的数据/信息。

• 这是实际测试任务的第一阶段。

• 本阶段回答“要测试什么”和“需要哪些资源来测试”。

• 本阶段的基本进入标准是提供需求文档（不清楚/缺失/已澄清的需求的更新版本）以及需求可追溯性矩阵。

• 如果自动化在范围内，则应在进入此阶段之前准备自动化可行性报告。

• 本阶段的退出标准是完成测试策略/测试计划文档和测试工作量估算文档。

测试计划阶段的各个方面

本阶段的主要目标是准备测试计划/测试策略文档。它包括三个主要方面：交付成果范围、工作量估算和资源计划。

交付成果范围

需要执行以下活动才能得出交付成果的范围：

• 确定合适的参与和交付模型。
• 定义测试目标、测试范围、测试阶段和活动。
• 审查业务需求和系统需求以确定测试可行性。
• 定义测试流程、测试类型和程序。
• 定义缺陷管理和变更管理程序。
• 确定测试工具、技术和最佳实践。
• 定义风险分析。
• 定义自动化解决方案，并确定合适的自动化候选者（如果适用）。

工作量估算

估算是寻找估计值或近似值的过程，即使输入数据可能不完整、不确定或不稳定，该值也可用于某种目的。

估算确定构建特定系统或产品需要多少资金、工作量、资源和时间。估算基于：

• 过去的数据/过去的经验
• 可用文档/知识
• 假设
• 已识别的风险

测试估算的四个基本步骤是：

• 估计被测应用 (AUT) 的大小。
• 估计以人月或人时计的工作量。
• 以日历月为单位估计进度安排。
• 以商定的货币单位估计项目成本。

资源计划

资源计划是测试阶段的关键要素。这些计划与测试团队完成特定任务所需的时间成反比。增加资源数量将在一定限度内减少完成天数，之后它将达到饱和，增加资源不会产生太大影响，并且可能不会导致完成天数减少。

资源请求者（通常是项目经理）创建资源计划以请求资源、跟踪工作量和成本。资源经理可以在使用资源计划之前修改和批准资源计划。

资源计划的正常工作流程为：

• 项目经理的计划
• 项目经理提出的请求
• 资源经理批准/修改/拒绝
• 完成——在资源经理签字后关闭请求

STLC - 测试用例开发

测试计划准备就绪后，测试团队将启动测试用例的开发。本阶段的主要目标是为单个单元准备测试用例。这些功能性和结构性测试用例涵盖了测试计划中提到的功能、验证点和验证点。

在STLC中进行测试用例开发时，需要考虑以下几点。

• 在此阶段，测试团队采用逐步方法编写测试用例。然后，业务分析师在审查或修改测试用例（如果需要修改）后签字。

• 测试用例准备就绪后，测试团队将根据前提条件准备测试数据。

• 本阶段的进入标准是测试计划中的活动应该完成并且测试计划应该准备就绪。

• 本阶段的退出标准是测试用例应该签字，测试数据应该准备就绪，并且如果自动化在范围内，测试脚本应该准备就绪。

• 测试用例应与需求可追溯性矩阵映射，以便跟踪需求的覆盖范围，如果遗漏任何内容。

测试用例开发阶段中的活动

以下是测试用例开发阶段中执行的三个活动：

测试场景识别

场景简化了复杂系统的测试和评估。以下策略有助于创建良好的场景：

• 列举可能的使用者、他们的行为和目标。

• 以黑客思维评估用户，并列出系统滥用的可能场景。

• 列出系统事件以及系统如何处理这些请求。

• 列出优势并创建端到端任务来检查它们。

• 阅读关于类似系统及其行为的资料。

• 研究关于竞争对手产品及其前代产品的投诉。

测试用例编写

测试用例是一个文档，其中包含测试数据、前提条件、预期结果和后置条件，为特定的测试场景而开发，用于验证对特定需求的符合性。

测试用例作为测试执行的起点。应用一组输入值后；应用程序有一个确定的结果，并将系统留在了某个端点，这也称为执行后置条件。

测试数据准备

测试数据用于在测试件上执行测试。测试数据需要精确且详尽，才能发现缺陷。为了实现这三个目标，采用以下分步方法：

• 确定测试资源或需求
• 确定要测试的条件/功能
• 设置优先级测试条件
• 选择要测试的条件
• 确定测试用例处理的预期结果
• 创建测试用例
• 记录测试条件
• 进行测试
• 根据修改验证和更正测试用例

活动流程图

下图显示了构成测试用例开发一部分的不同活动。

STLC - 测试环境搭建

测试环境由支持测试执行的元素组成，包括已配置的软件、硬件和网络。测试环境配置必须模拟生产环境，以便发现任何与环境/配置相关的问题。

测试环境设置需要考虑以下几点。

• 它是将执行测试的软硬件环境的组合。

• 它包括硬件配置、操作系统设置、软件配置、测试终端以及执行测试的其他支持。

• 这是测试过程中最关键的方面。环境设置的不可用或故障可能会破坏所有测试工作。

• 实际上，如果没有合适的测试环境，QA 团队无法开始实际工作。

• 这是一个独立的活动，可以与测试用例开发同时开始。

• 最普遍的是，开发人员执行技术方面的此活动，而需求条件可以由客户/业务分析师完成。

• 测试环境的准备情况可以通过冒烟测试进行验证，并由 QA 团队执行。

• 理想情况下，可以说此阶段的进入标准是提供测试计划、冒烟测试用例的准备以及测试数据的准备。

• 此阶段的退出标准是测试环境应该已准备好，并且冒烟测试应该以预期结果成功执行。

测试环境设置执行的活动

此阶段执行以下活动。

设计测试环境

以下因素在测试环境的设计中起着重要作用。

• 确定测试环境是否需要存档以进行备份。

• 验证网络配置。

• 确定所需的服务器操作系统、数据库和其他组件。

• 确定测试团队所需的许可证数量。

环境设置

分析环境设置需求，并准备设置的软件和硬件需求列表。获得测试环境设置的正式确认，并配置以访问测试环境。

冒烟测试

一旦环境设置好并且 QA 团队可以访问它，就应该进行快速一轮冒烟测试，以验证测试环境构建的稳定性。如果结果符合预期，QA 团队可以进入下一阶段，否则指出差异，并在修复后等待部署。

STLC - 测试执行

测试执行是执行代码并将预期结果与实际结果进行比较的过程。测试执行过程需要考虑以下因素：

• 根据风险，选择要在本周期执行的测试套件的子集。
• 将每个测试套件中的测试用例分配给测试人员执行。
• 持续执行测试、报告错误并捕获测试状态。
• 解决出现的阻塞问题。
• 每天报告状态、调整分配并重新考虑计划和优先级。
• 报告测试周期结果和状态。

测试执行需要考虑以下几点。

• 在此阶段，QA 团队根据准备好的测试用例对 AUT 进行实际验证，并将逐步结果与预期结果进行比较。

• 此阶段的进入标准是完成测试计划和测试用例开发阶段，测试数据也应该准备好。

• 在正式进入测试执行之前，始终建议通过冒烟测试验证测试环境设置。

• 退出标准要求成功验证所有测试用例；缺陷应已关闭或延期；测试用例执行和缺陷汇总报告应已准备就绪。

测试执行活动

此阶段的目标是在继续进行生产/发布之前对 AUT 进行实时验证。为了从此阶段签字，QA 团队执行不同类型的测试以确保产品质量。除此之外，缺陷报告和重新测试也是此阶段的关键活动。以下是此阶段的重要活动：

系统集成测试

产品的真实验证/AUT 从这里开始。系统集成测试 (SIT) 是一种黑盒测试技术，用于评估系统对已准备好的指定需求/测试用例的符合性。

系统集成测试通常在系统的子集上执行。SIT 可以使用最少的测试工具来执行，验证交换的交互，并调查各个层中每个数据字段的行为。集成后，数据流有三个主要状态：

• 集成层中的数据状态
• 数据库层中的数据状态
• 应用程序层中的数据状态

注意 - 在 SIT 测试中，QA 团队试图发现尽可能多的缺陷以确保质量。这里的主要目标是发现尽可能多的错误。

缺陷报告

当预期结果与实际结果不匹配时，就会出现软件错误。它可能是计算机程序中的错误、缺陷、故障或错误。大多数错误是由开发人员或架构师犯下的错误造成的。

在执行 SIT 测试时，QA 团队会发现这些类型的缺陷，这些缺陷需要向相关团队成员报告。成员采取进一步行动并修复缺陷。报告的另一个优点是它可以轻松跟踪缺陷的状态。许多流行的工具（如 ALM、QC、JIRA、Version One、Bugzilla）都支持缺陷报告和跟踪。

缺陷报告是通过测试或记录客户反馈来查找被测应用程序或产品中的缺陷，并根据客户反馈制作修复缺陷的新产品版本的流程。

缺陷跟踪也是软件工程中的一个重要流程，因为复杂的和业务关键的系统有数百个缺陷。最具挑战性的因素之一是管理、评估和优先处理这些缺陷。缺陷的数量随着时间的推移而成倍增加，为了有效地管理它们，缺陷跟踪系统被用来简化工作。

缺陷映射

一旦缺陷被报告和记录，它应该与需求可追溯性矩阵中相关的失败/阻塞的测试用例和相应的要求进行映射。此映射由缺陷报告人完成。它有助于制作适当的缺陷报告并分析产品中的缺陷。一旦测试用例和需求与缺陷映射后，利益相关者可以分析并决定根据优先级和严重性来修复/延迟缺陷。

重新测试

重新测试是对 AUT 执行先前失败的测试，以检查问题是否已解决。修复缺陷后，将执行重新测试以检查相同环境条件下的场景。

在重新测试期间，测试人员会查看功能更改区域的细粒度细节，而回归测试涵盖所有主要功能，以确保由于此更改而没有破坏任何功能。

回归测试

一旦所有缺陷都处于关闭、延期或拒绝状态，并且没有任何测试用例处于进行中/失败/未运行状态，就可以说系统集成测试完全基于测试用例和需求。但是，需要进行一轮快速测试，以确保由于代码更改/缺陷修复而没有破坏任何功能。

回归测试是一种黑盒测试技术，它包括重新执行由于代码更改而产生影响的那些测试。这些测试应该在整个软件开发生命周期中尽可能频繁地执行。

回归测试类型

• 最终回归测试 - “最终回归测试”用于验证一段时间内未发生更改的构建。此构建被部署或交付给客户。

• 回归测试 - 常规回归测试用于验证最近的代码更改（用于缺陷修复或增强）是否未破坏应用程序的其他任何部分。

活动流程图

下图显示了此阶段执行的重要活动；它还显示了与先前阶段的依赖关系：

STLC - 缺陷生命周期

缺陷生命周期，也称为错误生命周期，是缺陷的历程，缺陷在其生命周期中所经历的周期。它因组织而异，也因项目而异，因为它受软件测试流程的约束，也取决于所使用的工具。

缺陷生命周期 - 工作流程

下图显示了缺陷生命周期的工作流程。

缺陷生命周期的状态

以下是缺陷生命周期的不同状态。

• 新建 - 已提出但尚未验证的潜在缺陷。

• 已分配 - 分配给开发团队以解决。

• 活跃 - 缺陷正在由开发人员解决，并且调查正在进行中。在此阶段，有两种可能的结果 - 延期或拒绝。

• 测试/已修复/准备重新测试 - 缺陷已修复并准备进行测试。

• 已验证 - 已重新测试并且测试已由 QA 验证的缺陷。

• 已关闭 - 缺陷的最终状态，可以在 QA 重新测试后关闭，如果缺陷是重复的或被认为不是缺陷，也可以关闭。

• 已重新打开 - 当缺陷未修复时，QA 会重新打开/重新激活缺陷。

• 已延期 - 当在特定周期中无法解决缺陷时，它会被延迟到将来的版本。

• 已拒绝 - 由于以下三个原因之一，缺陷可能会被拒绝 - 重复缺陷、不是缺陷、不可重现。

STLC - 缺陷分类

缺陷从QA团队的角度被分类为优先级，从开发的角度被分类为严重程度（修复代码的复杂性）。这是两个主要的分类，它们在修复缺陷的时间范围和工作量方面起着重要的作用。

什么是优先级？

优先级定义为应解决缺陷的顺序。优先级状态通常由QA团队在针对开发团队提出缺陷时设置，同时说明修复缺陷的时间范围。优先级状态是根据最终用户的需求设置的。

例如，如果公司徽标在公司网页上的位置不正确，则优先级很高，但严重程度很低。

优先级列表

优先级可以按以下方式分类：

• 低 - 在修复关键缺陷后可以修复此缺陷。

• 中 - 应在后续版本中解决此缺陷。

• 高 - 必须立即解决此缺陷，因为此缺陷会严重影响应用程序，并且相关模块在修复之前无法使用。

• 紧急 - 必须立即解决此缺陷，因为此缺陷严重影响应用程序或产品，并且在修复之前产品无法使用。

什么是严重程度？

严重程度定义为缺陷对应用程序的影响程度以及从开发角度来看修复代码的复杂性。它与产品的开发方面相关。严重程度可以根据缺陷对系统的严重程度/重要程度来决定。严重程度状态可以说明由于缺陷导致的功能偏差。

示例 - 对于航班运营网站，生成预订对应的票号的缺陷属于高严重性和高优先级。

严重程度列表

严重程度可以按以下方式分类：

• 严重/严重程度1 - 缺陷影响应用程序最关键的功能，并且在修复之前，QA团队无法继续验证被测应用程序。例如，应用程序/产品频繁崩溃。

• 主要/严重程度2 - 缺陷影响功能模块；QA团队无法测试该特定模块，但可以继续验证其他模块。例如，航班预订功能无法正常工作。

• 中等/严重程度3 - 缺陷存在于单个屏幕或与单个功能相关的问题，但系统仍在运行。此处的缺陷不会阻塞任何功能。例如，票号的表示方式不遵循正确的字母数字字符，例如前五个字符为字母，后五个字符为数字。

• 低/严重程度4 - 它不影响功能。它可能是一个外观缺陷、UI字段不一致或来自UI方面的改进最终用户体验的建议。例如，“提交”按钮的背景颜色与“保存”按钮的背景颜色不匹配。

STLC - 测试周期结束

对测试退出标准进行检查对于声明测试已完成至关重要。在结束测试过程之前，根据测试完成标准衡量产品质量。

本阶段的进入标准是测试用例的执行已完成，测试结果可用且缺陷报告已准备就绪。

测试完成标准包括以下内容：

• 已达到指定的覆盖率。
• 没有阻碍性或严重缺陷
• 只有很少已知的，中低优先级的缺陷。这些缺陷不会影响产品的用途。

本阶段的退出标准是提供测试结束报告和准备矩阵，之后由客户签字确认。

现在让我们讨论测试周期结束所涉及的活动。

测试完成报告

测试完成报告是一个过程，通过该过程，测试指标以汇总格式报告以更新利益相关者。这使他们能够做出明智的决策。

测试完成报告包含以下信息。

• 测试汇总报告标识符
• 摘要
• 差异
• 汇总结果
• 评估
• 计划与实际工作量
• 签字确认

一份良好的测试完成报告表明质量、衡量突出风险并确定已测试软件的级别。

测试完成矩阵

测试完成后，将收集各种矩阵以准备测试报告。准备报告的标准包括以下内容：

• 已执行的测试数量
• 已通过的测试数量
• 已失败的测试数量
• 每个模块中失败的测试数量
• 执行周期中提出的测试缺陷数量
• 已接受的测试缺陷数量
• 已拒绝的测试缺陷数量
• 已推迟的测试缺陷数量
• 活动缺陷的状态
• 计算版本的质量指标

测试结果

在执行测试用例、重新测试缺陷和执行回归测试用例时，应保存测试结果说明，并可以与测试周期结束文档一起提供，以支持测试执行的完成。

说明可以是屏幕截图、数据库查询结果、记录、日志文件等。