STLC – 快速指南
STLC – 快速指南
STLC – 概述
STLC 代表软件测试生命周期。STLC 是测试团队为确保软件或产品质量而执行的一系列不同活动。
-
STLC 是软件开发生命周期 (SDLC) 的一个组成部分。但是，STLC 只处理测试阶段。
-
一旦需求被定义或利益相关者共享 SRD（软件需求文档），STLC 就会开始。
-
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 基于它们的阶段之间的比较因素 –
| Phase | SDLC | STLC |
|---|---|---|
| Requirement Gathering |
|
|
| Design |
|
|
| Development |
|
|
| Environment Set up |
|
|
| Testing |
|
|
| Deployment/ Product Release |
|
|
| Maintenance |
|
|
STLC – 测试基本原则
测试的共同目标是尽早发现错误。而且，一旦修复了错误，请确保它按预期工作并且不会破坏任何其他功能。
为了实现这些目标，软件测试给出了七个基本原则 –
什么测试显示？
测试可以表明存在缺陷，但无法证明产品中没有缺陷。测试阶段确保被测应用程序根据给定的要求工作，并有助于降低应用程序中未被发现的缺陷的可能性。但是，即使没有发现缺陷，也不代表它是绝对正确的。我们可以假设 AUT 与我们的退出标准匹配并根据 SRD 维护需求。
是否可以进行详尽的测试？
除了微不足道的情况外，不可能对所有输入组合和可能的组合进行 100% 覆盖或测试。不是详尽的测试，而是使用风险分析和优先级来定义测试范围。在这里，大多数实时场景也可以考虑包括最可能的负面场景。这将帮助我们跟踪失败。
早期测试
测试活动应尽快开始，并专注于测试策略中定义的目标和预期结果。测试的早期阶段有助于识别需求缺陷或设计水平差异。如果在初始阶段捕获这些类型的错误，它可以帮助我们节省时间并且也具有成本效益。为什么应该在早期开始测试的答案非常简单——一旦收到 SRD，测试人员就可以从测试的角度分析需求，并可以注意到需求差异。
缺陷聚类
根据之前的产品缺陷分析，可以说大部分缺陷是从对应用程序至关重要的一小组模块中识别出来的。可以根据复杂性、不同的系统交互或对不同其他模块的依赖性来识别这些模块。如果测试人员能够识别这些关键模块，他们就可以更加关注这些模块以识别所有可能的错误。在一项研究中，发现 10 个缺陷中有 8 个是从 AUT 的 20% 功能中识别出来的。
农药悖论
什么是农药悖论——如果在农作物上经常使用农药，那么当昆虫产生某种抗药性时，就会逐渐喷出的农药似乎对昆虫无效。
同样的概念也适用于测试。在这里，昆虫是虫子，而杀虫剂是用来反复运行的测试用例。如果重复执行相同的测试用例集，这些测试用例在一定时间范围后变得无效，测试人员将无法识别任何新的缺陷。
为了克服这些条件，应不时修改和审查测试用例，并且可以添加新的和不同的测试用例。这将有助于识别新的缺陷。
测试是上下文相关的
该原则指出，除非两个应用程序具有相同的性质，否则无法使用相同的方法测试两个不同类型的应用程序。例如，如果测试人员对基于 Web 的应用程序和移动应用程序使用相同的方法，那是完全错误的，并且产品发布质量不佳的风险很高。测试人员应该针对不同类型和性质的应用程序使用不同的方法、方法论、技术和覆盖范围。
没有错误——谬误
该原则指出发现缺陷并修复它们直到应用程序或系统稳定，既耗时又消耗资源。即使修复了 99% 的缺陷，也存在应用不稳定的高风险。首要的事情是验证应用程序的稳定性和环境的先决条件。只有满足这两个条件，我们才能开始详细的测试。
STLC – 需求分析
需求分析是 STLC 的第一阶段，一旦与测试团队共享 SRD/SRS，它就会开始。让我们考虑以下几点来理解 STLC 中的需求分析。
-
本阶段的准入标准是提供SRS（Software Requirement Specification）；还建议应用程序架构得心应手。
-
在此阶段，QA 团队在更高级别分析要测试的内容以及如何测试。
-
QA 团队会跟进各种利益相关者，如业务分析师、系统架构、客户、测试经理/负责人，以防需要任何查询或澄清来了解需求。
-
需求可以是功能性的或非功能性的，如性能、安全性、可用性等，或者功能性和非功能性两者。
-
此阶段的退出标准是完成 RTM 文档、自动化可行性报告和问题列表（如果适用）以更具体地说明要求。
为需求分析执行的活动
QA 团队在此阶段执行三项主要活动。活动描述如下。
定义范围
QA 团队在高层次上确定测试范围并划分为各种功能模块。该团队还确定了需要执行的测试类型——冒烟测试、健全性测试、功能测试、回归测试等。QA 团队分析了应该执行测试的先决条件和环境细节。该团队收集有关测试优先级的详细信息，并将重点放在要验证的模块序列上。如果模块相互矛盾并且功能没有与其他模块一起继承，它还可以识别需求缺陷。
准备 RTM
需求跟踪是记录需求和为实现和验证这些需求而开发的工作产品之间的链接的过程。RTM 在需求分析中捕获所有需求及其在单个文档中的可追溯性。所有这些都是在生命周期结束时交付的。
矩阵是在项目一开始就创建的，因为它构成了项目范围和将要产生的可交付成果的基础。
矩阵是双向的，因为它通过检查可交付成果的输出来向前跟踪需求，并通过查看为产品的特定功能指定的业务需求来向后跟踪需求。
自动化分析
在需求阶段，QA 团队分析回归测试自动化的范围。如果在范围内添加自动化，团队将决定可以使用哪种工具、将涵盖哪些功能作为自动化、时间框架以及自动化开发所涉及的资源分配。完成此分析后，QA 团队会向不同的利益相关者提供自动化可行性报告以提供签收。
STLC – 进入和退出标准
在本章中，我们将看到 STLC 中不同级别的进入和退出标准。要理解标准，需要考虑以下几点。
理想情况下，QA 团队在满足当前阶段的退出标准之前不会进行下一阶段。进入标准应包括上一阶段退出标准的完成情况。
实时地，在满足退出标准之前不可能等待下一阶段。现在，如果前一阶段的关键可交付成果已经完成，则可以开始下一阶段。
在 STLC 的每个阶段，都应该定义进入和退出标准。
入学条件
STLC 阶段的进入标准可以定义为特定条件；或者，在进入任何 STLC 阶段之前，应提供开始 STLC 特定阶段所需的所有文件。
进入标准是一组允许执行任务的条件，或者如果没有这些条件中的任何一个，则无法执行任务。
在设置进入标准时，定义进入标准项目可用于启动流程的时间范围也很重要。
例如，要开始测试用例开发阶段，应满足以下条件 –
- 需求文档应该是可用的。
- 需要完全了解应用程序流程。
- 测试计划文件应该准备好了。
退出标准
STLC 阶段的退出标准可以定义为在结束当前阶段并进入下一阶段之前必须完成的项目/文件/行动/任务。
退出标准是一组期望；这应该在结束 STLC 阶段之前得到满足。
例如，要结束测试用例开发阶段，应满足以下期望 –
- 应该编写和审查测试用例。
- 应识别并准备好测试数据。
- 如果适用，测试自动化脚本应该准备好。
STLC – 验收标准
验收标准是指需求文档中列出的功能、模块和应用程序的预期行为。确定软件系统是否满足需求规范是验证阶段/检查点。此测试的主要目的是评估系统是否符合业务需求，并验证其是否符合要求的标准。
验收标准是一组陈述，明确提及预期的通过/失败结果。验收标准规定了功能和非功能要求。这些要求代表“满意或预期行为的条件”。没有部分接受；要么满足某个标准，要么不满足。
这些标准定义了功能/模块的边界和参数，并确定功能/模块是否已完成并按预期工作。
测试计划级别提到了高级验收标准。验收标准转换为测试用例级别要验证的点或预期结果的列表。
验收标准是根据以下属性定义的 –
- 功能正确性和完整性
- 数据的完整性
- 数据转换
- 可用性
- 表现
- 及时性
- 保密性和可用性
- 安装和升级能力
- 可扩展性
- 文档
STLC – 测试计划
测试计划概述了将用于测试应用程序的策略、将使用的资源、执行测试的测试环境以及测试的限制和测试活动的时间表。通常，质量保证团队负责人将负责编写测试计划。
测试计划包括什么？
测试计划包括以下内容。
- 测试计划文档简介。
- 测试应用程序时的假设。
- 测试应用程序中包含的测试用例列表。
- 要测试的功能列表。
- 在测试软件时使用的那种方法。
- 需要测试的可交付成果列表。
- 为测试应用程序分配的资源。
- 测试过程中涉及的任何风险。
- 要实现的任务和里程碑的时间表。
测试计划的要点
STLC 中的测试计划需要考虑以下几点。
-
理想情况下，测试分析师（主管）/经理准备测试策略/测试计划文档。
-
分析更侧重于与应用程序相关的数据/信息。
-
这是实际测试任务的第一阶段。
-
此阶段回答“要测试什么”和“需要测试什么资源”。
-
此阶段的基本进入标准是提供需求文档（不明确/缺失/明确需求的更新版本）以及需求可追溯性矩阵。
-
如果自动化在范围内，则应在进入此阶段之前准备自动化可行性报告。
-
此阶段的退出标准是完成测试策略/测试计划文档和测试工作量估算文档。
测试计划阶段的方面
此阶段的主要目标是准备测试计划/测试策略文档。它包括三个主要方面——可交付成果的范围、工作量估算和资源计划。
可交付成果的范围
需要执行以下活动以总结可交付成果的范围 –
- 确定合适的参与和交付模式。
- 定义测试目标、测试范围、测试阶段和活动。
- 审查业务需求和系统需求以确定测试可行性。
- 定义测试过程、测试类型和程序。
- 定义缺陷管理和变更管理程序。
- 确定测试工具、技术和最佳实践。
- 定义风险分析。
- 定义自动化解决方案并确定合适的自动化候选者（如果适用）。
工作量估计
估计是寻找估计值或近似值的过程，即使输入数据可能不完整、不确定或不稳定，该值仍可用于某些目的。
估算决定了构建特定系统或产品所需的资金、精力、资源和时间。估计基于 –
- 过去的数据/过去的经验
- 可用文件/知识
- 假设
- 已识别风险
测试估计的四个基本步骤是 –
- 估计 AUT（被测应用程序）的大小。
- 以人-月或人-小时为单位估算工作量。
- 估计日历月的时间表。
- 以商定的货币估算项目成本。
资源计划
资源计划是测试阶段的关键要素。这些计划与测试团队完成特定任务所花费的时间成反比。增加资源数量会在一定限度内减少完成天数，然后达到饱和，增加资源不会有太大影响，可能不会导致完成天数减少。
资源请求者（通常是项目经理）创建资源计划以请求资源、跟踪工作量和成本。资源经理可以在使用计划之前修改和批准资源计划。
资源计划的正常工作流程是 –
- 项目经理规划
- 项目经理提出的要求
- 资源经理批准/修改/拒绝
- 完成 – 资源管理器签收后关闭请求
STLC – 测试用例开发
测试计划准备就绪后，QA 团队将启动测试用例的开发。此阶段的主要目标是为单个单元准备测试用例。这些功能和结构测试用例涵盖了测试计划中提到的功能、验证和确认点。
在 STLC 中进行测试用例开发需要考虑以下几点。
-
在此阶段，QA 团队使用逐步方法编写测试用例。测试用例然后由业务分析师在审查或返工测试用例后签署，以防需要修改。
-
测试用例准备就绪后，QA 团队会根据先决条件准备测试数据。
-
这个阶段的进入标准是测试计划中的活动应该完成，测试计划应该准备好。
-
这个阶段的退出标准是测试用例应该被签署，测试数据应该准备好，如果自动化在范围内，测试脚本应该准备好。
-
如果有任何遗漏，测试用例应该与需求可追溯性矩阵进行映射，以跟进需求的覆盖范围。
测试用例开发阶段的活动
以下是在测试用例开发阶段进行的三项活动 –
测试场景识别
场景简化了复杂系统的测试和评估。以下策略有助于创造良好的场景 –
-
列举可能的用户、他们的行动和目标。
-
以黑客的心态评估用户并列出可能的系统滥用场景。
-
列出系统事件以及系统如何处理此类请求。
-
列出好处并创建端到端任务来检查它们。
-
阅读有关类似系统及其行为的信息。
-
研究对竞争对手产品及其前身的投诉。
测试用例编写
测试用例是为特定测试场景开发的文档，其中包括测试数据、前提条件、预期结果和后置条件，以验证是否符合特定要求。
测试用例作为测试执行的起点。在应用一组输入值之后；应用程序有一个明确的结果，并在某个端点离开系统，这也称为执行后条件。
测试数据准备
测试数据用于在测试件上执行测试。测试数据需要精确和详尽才能发现缺陷。为了实现这三个目标，接下来是逐步方法，如下所示 –
- 确定测试资源或要求
- 确定要测试的条件/功能
- 设置优先测试条件
- 选择测试条件
- 确定测试用例处理的预期结果
- 创建测试用例
- 记录测试条件
- 进行测试
- 根据修改验证和更正测试用例
活动框图
下图显示了构成测试用例开发一部分的不同活动。
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 – 缺陷生命周期
缺陷生命周期，也称为缺陷生命周期，是缺陷的旅程，是缺陷在其生命周期中所经历的循环。它因组织而异，也因项目而异，因为它受软件测试过程的约束，还取决于所使用的工具。
缺陷生命周期——工作流程
下图显示了缺陷生命周期的工作流程。
缺陷生命周期的状态
以下是缺陷生命周期的不同状态。
-
新– 提出但尚未验证的潜在缺陷。
-
已分配– 分配给要解决的开发团队。
-
Active – 开发人员正在解决该缺陷，调查正在进行中。在这个阶段，有两种可能的结果——延期或被拒绝。
-
测试/固定/准备重新测试– 缺陷已修复并准备好进行测试。
-
已验证– 重新测试且测试已由 QA验证的缺陷。
-
Closed – 缺陷的最终状态，可以在 QA 重新测试后关闭，或者如果缺陷重复或被视为不是缺陷，则可以关闭。
-
重新打开 – 当缺陷未修复时，QA 重新打开/重新激活缺陷。
-
Deferred – 当在该特定周期中无法解决缺陷时，它会推迟到未来版本。
-
Rejected – 缺陷可以因以下三个原因中的任何一个而被拒绝 – 重复缺陷、非缺陷、不可重现。
STLC – 缺陷分类
缺陷从 QA 团队的角度归类为优先级，从开发的角度归类为严重性（修复它的代码的复杂性）。这是两个主要分类，它们在时间范围和修复缺陷的工作量中起着重要作用。
什么是优先级？
优先级定义为应解决缺陷的顺序。优先级状态通常由 QA 团队设置，同时向开发团队提出缺陷，并提及修复缺陷的时间范围。优先级状态是根据最终用户的要求设置的。
例如，如果公司徽标错误地放置在公司网页中，则优先级高但严重性低。
优先上市
优先级可以按以下方式分类 –
-
低– 在修复关键缺陷后可以修复此缺陷。
-
中– 缺陷应在后续构建中解决。
-
高– 必须立即解决缺陷，因为该缺陷对应用程序的影响很大，并且在修复之前相关模块无法使用。
-
紧急– 必须立即解决缺陷，因为该缺陷严重影响应用程序或产品，并且产品必须在修复后才能使用。
什么是严重性？
严重性被定义为应用程序缺陷的顽皮程度和从开发角度修复它的代码的复杂性。它与产品的开发方面有关。可以根据系统缺陷的严重程度/严重程度来确定严重性。严重性状态可以提供有关由于缺陷而导致的功能偏差的想法。
示例– 对于航班运营网站，针对预订生成票号的缺陷是高严重性和高优先级。
严重性列表
严重性可以按以下方式分类 –
-
严重/严重性 1 – 缺陷会影响应用程序的最关键功能，并且 QA 团队无法在不修复它的情况下继续验证被测应用程序。例如，App/Product 频繁崩溃。
-
主要/严重性 2 – 缺陷影响功能模块；QA 团队无法测试该特定模块，而是继续验证其他模块。例如，航班预订不起作用。
-
中/严重性 3 – 缺陷有单屏问题或与单个功能有关，但系统仍在运行。此处的缺陷不会阻止任何功能。例如，Ticket# 是一种不遵循正确的字母数字字符（如前五个字符和后五个字符）的表示形式。
-
低/严重性 4 – 它不会影响功能。可能是外观缺陷、某个字段的 UI 不一致或从 UI 端改进最终用户体验的建议。例如，提交按钮的背景颜色与保存按钮的背景颜色不匹配。
STLC – 测试周期结束
检查测试退出标准对于声称测试现已完成非常重要。在结束测试过程之前，根据测试完成标准测量产品质量。
该阶段的进入标准是测试用例执行完成，测试结果可用，缺陷报告准备好。
测试完成的标准包括以下内容 –
- 达到了指定的覆盖范围。
- 没有搅局者或严重缺陷
- 很少有已知的中等或低优先级缺陷。这些不会影响产品的使用。
此阶段的退出标准是提供测试结束报告和矩阵的准备，然后由客户签字。
现在让我们讨论关闭测试周期所涉及的活动。
测试完成报告
测试完成报告是一个过程，其中以汇总格式报告测试指标以更新利益相关者。这使他们能够做出明智的决定。
测试完成报告包含以下信息。
- 测试摘要报告标识符
- 概括
- 差异
- 总结结果
- 评估
- 计划与实际工作
- 登出
一份好的测试完成报告表明质量，衡量突出的风险，并确定测试软件的级别。
测试完成矩阵
测试完成后，收集各种矩阵以准备测试报告。准备报告的标准包括以下内容 –
- 执行的测试数量
- 通过的测试数量
- 失败的测试次数
- 基于每个模块的测试失败次数
- 执行周期中出现的测试缺陷数
- 接受的测试缺陷数
- 被拒绝的测试缺陷数
- 推迟的测试缺陷数
- 活动缺陷的状态
- 计算构建的质量指数
检测结果
在执行测试用例、重新测试缺陷和执行回归测试用例时，应保存清晰的测试结果，并可以与测试周期结束文档一起生成，以支持测试执行的完成。
Articulates 可以是截图、数据库查询结果、记录、日志文件等。
