STLC - 快速指南

STLC - 概述

STLC 代表软件测试生命周期。STLC 是测试团队为确保软件或产品的质量而执行的一系列不同活动。

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

  • 一旦定义了需求或利益相关者共享了 SRD（软件需求文档），STLC 就会开始。

  • STLC 提供了一个分步流程来确保软件质量。

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

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

STLC阶段

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

STLC阶段

STLC 有 6 个主要阶段 -

  • 需求分析- 当 SRD 准备好并与利益相关者共享时，测试团队开始有关 AUT（测试中的应用程序）的高级分析。

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

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

  • 测试环境设置- 当集成环境准备好验证产品时。

  • 测试执行- 实时验证产品并发现错误。

  • 测试结束- 测试完成后，矩阵、报告、结果都会被记录下来。

比较 - STLC 和 SDLC

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

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

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

  • 然而，STLC是SDLC的一个非常重要的阶段，最终产品或软件如果不经过STLC流程就无法发布。

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

下表列出了 SDLC 和 STLC 基于其相位的比较因素 -

阶段 SDLC STLC
需求收集
  • 业务分析师收集需求。
  • 开发团队分析需求。
  • 在高层之后，开发团队开始从架构和设计角度进行分析。
  • 测试团队审查并分析 SRD 文档。
  • 确定测试要求 - 范围、验证和确认要点。
  • 审查各个模块之间的逻辑和功能关系的要求。这有助于在早期阶段识别差距。
设计
  • SDLC的架构可帮助您根据需求开发软件的高层和底层设计。
  • 业务分析师致力于 UI 设计的模拟。
  • 设计完成后，将由利益相关者签署。
  • 在 STLC 中，测试架构师或测试主管通常会规划测试策略。
  • 识别测试点。
  • 资源分配和时间表在此最终确定。
发展
  • 开发团队开始开发软件。
  • 与不同系统集成。
  • 一旦完成所有集成，就提供了可供测试的软件或产品。
  • 测试团队编写测试场景来验证产品的质量。
  • 为所有模块编写详细的测试用例以及预期Behave。
  • 此处确定了测试模块的先决条件以及进入和退出标准。
环境搭建
  • 开发团队为开发的产品建立测试环境以进行验证。
  • 测试团队根据先决条件确认环境设置。
  • 执行烟雾测试以确保待测试产品的环境稳定。
测试
  • 实际测试是在这个阶段进行的。包括单元测试、集成测试、系统测试、缺陷复测、回归测试等。
  • 开发团队修复报告的错误（如果有）并将其发送回测试人员进行重新测试。
  • 从 SIT 测试签核后，UAT 测试将在此处执行。
  • 系统集成测试根据测试用例开始。
  • 报告的缺陷（如果有）将被重新测试并修复。
  • 回归测试在这里进行，一旦产品满足退出标准，产品就会被签核。
部署/产品发布
  • 一旦收到各个测试团队的签核，应用程序就会部署在生产环境中供真正的最终用户使用。
  • 产品部署后，生产环境中的烟雾和健全性测试就在这里完成。
  • 测试报告和矩阵准备由测试团队完成，以分析产品。
维护
  • 它涵盖部署后支持、增强和更新（如果有）。
  • 在此阶段，测试用例、回归套件和自动化脚本的维护是基于增强和更新进行的。

STLC - 测试基本原则

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

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

测试显示什么？

测试可以表明产品存在缺陷，但无法证明产品不存在缺陷。测试阶段可确保被测应用程序根据给定的要求运行，并有助于降低应用程序中未发现缺陷的可能性。但是，即使没有发现任何缺陷，也不代表它绝对正确。我们可以假设 AUT 与我们的退出标准相匹配，并根据 SRD 维持要求。

详尽的测试可能吗？

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

早期测试

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

缺陷聚类

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

农药悖论

什么是农药悖论——如果农作物经常使用农药，昆虫就会产生一定的抗药性，渐渐地，喷洒的农药似乎对昆虫无效了。

同样的概念也适用于测试。在这里，昆虫是虫子，而杀虫剂是用来一次又一次运行的测试用例。如果多次执行相同的测试用例集，那么这些测试用例在一段时间后就会失效，测试人员将无法识别任何新的缺陷。

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

测试取决于上下文

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

不存在错误——谬误

该原则指出，发现缺陷并修复它们直到应用程序或系统稳定为止，这既耗时又消耗资源。即使修复了 99% 的缺陷，应用不稳定的风险也很高。首先要验证应用程序的稳定性和环境的先决条件。如果满足这两个条件，我们就可以开始详细的测试了。

STLC——需求分析

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

  • 本阶段的进入标准是提供SRS（软件需求规范）；还建议应用架构得心应手。

  • 在此阶段，QA 团队在更高的层面上分析要测试什么以及如何测试。

  • QA 团队会与业务分析师、系统架构、客户、测试经理/主管等各个利益相关者进行跟进，以防需要任何查询或澄清来理解需求。

  • 需求可以是功能性的，也可以是非功能性的，例如性能、安全性、可用性等，或者既可以是功能性的，也可以是非功能性的。

  • 此阶段的退出标准是完成 RTM 文件、自动化可行性报告和问题列表（如果适用）以更具体地说明要求。

为需求分析而进行的活动

质量检查团队在此阶段执行三项主要活动。活动描述如下。

定义范围

QA 团队在高层确定测试范围并划分为各个功能模块。该团队还确定了需要执行的测试类型——冒烟测试、健全性测试、功能测试、回归测试等。QA 团队分析了应该执行测试的先决条件和环境细节。团队收集有关测试优先级的详细信息，并将重点放在要验证的模块的顺序上。如果模块相互矛盾并且功能没有与其他模块一起继承，它还可以识别需求缺陷。

准备RTM

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

该矩阵是在项目一开始就创建的，因为它构成了项目范围和将产生的可交付成果的基础。

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

自动化分析

在需求阶段，QA 团队分析回归测试的自动化范围。如果在范围内添加自动化，团队将决定可以使用哪种工具、自动化将涵盖哪些功能、自动化开发所涉及的时间框架和资源分配。分析完成后，质量检查团队会向不同的利益相关者提供自动化可行性报告以供签署。

STLC - 进入和退出标准

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

理想情况下，质量检查团队在满足当前阶段的退出标准之前不会继续下一阶段。进入标准应包括完成上一阶段的退出标准。

实时地，不可能等待下一阶段直到满足退出标准。现在，如果上一阶段的关键交付成果已经完成，就可以启动下一阶段。

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

入学标准

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

进入条件是允许任务执行的一组条件，或者在不存在任何这些条件的情况下，任务无法执行。

在设置进入标准时，定义进入标准项目可用于启动流程的时间范围也很重要。

例如，要开始测试用例开发阶段，应满足以下条件 -

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

退出标准

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

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

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

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

STLC - 验收标准

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

验收标准是一组声明，明确提及预期的通过/失败结果。验收标准指定了功能性和非功能性要求。这些要求代表“满意的条件或预期的Behave”。不存在部分接受；要么满足标准，要么不满足标准。

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

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

验收标准是根据以下属性定义的 -

  • 功能正确性和完整性
  • 数据的完整性
  • 数据转换
  • 可用性
  • 表现
  • 时效性
  • 保密性和可用性
  • 安装和升级能力
  • 可扩展性
  • 文档

STLC - 测试计划

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

测试计划包括什么？

测试计划包括以下内容。

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

测试计划的要点

STLC 中的测试计划需要考虑以下几点。

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

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

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

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

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

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

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

测试计划阶段的各个方面

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

可交付成果的范围

需要执行以下活动来确定可交付成果的范围 -

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

努力估计

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

估算确定构建特定系统或产品需要多少资金、精力、资源和时间。估计基于 -

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

测试估计的四个基本步骤是 -

  • 估计 AUT（被测应用程序）的大小。
  • 以人月或人时为单位估算工作量。
  • 以日历月为单位估计时间表。
  • 以商定货币估算项目成本。

资源计划

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

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

资源计划的正常工作流程是 -

  • 由项目经理策划
  • 项目经理提出的要求
  • 由资源经理批准/修改/拒绝
  • 完成 - 资源经理签字后关闭请求

STLC - 测试用例开发

一旦测试计划准备就绪，QA 团队就会开始测试用例的开发。此阶段的主要目标是为单个单元准备测试用例。这些功能和结构测试用例涵盖了测试计划中提到的功能、验证和确认点。

STLC 中的测试用例开发需要考虑以下几点。

  • 在此阶段，QA 团队采用逐步的方法编写测试用例。然后，在审查或返工测试用例（如果需要进行案例修改）后，业务分析师会签署测试用例。

  • 一旦测试用例准备好，QA 团队就会根据先决条件准备测试数据。

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

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

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

测试用例开发阶段的活动

以下是测试用例开发阶段进行的三项活动 -

测试场景识别

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

  • 枚举可能的用户、他们的操作和目标。

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

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

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

  • 了解类似的系统及其Behave。

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

测试用例编写

测试用例是一个文档，其中包括测试数据、前置条件、预期结果和后置条件，为特定测试场景开发，以便验证是否符合特定要求。

测试用例充当测试执行的起点。应用一组输入值后；应用程序有一个明确的结果，并使系统处于某个终点，这也称为执行后条件。

测试数据准备

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

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

活动框图

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

活动框图

STLC - 测试环境设置

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

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

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

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

  • 这是测试过程中最关键的方面。不可用或错误的环境设置可能会毁掉所有测试工作。

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

  • 它是独立的活动，可以与测试用例开发一起启动。

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

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

  • 理想情况下，我们可以说这个阶段的进入标准是提供测试计划、烟雾测试用例的准备情况和测试数据的准备。

  • 此阶段的退出标准是测试环境应准备就绪，并且烟雾测试应成功执行并达到预期结果。

为测试环境设置执行的活动

此阶段执行以下活动。

设计测试环境

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

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

  • 验证网络配置。

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

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

环境设置

分析环境设置要求并准备设置的软件和硬件要求列表。获取测试环境设置的官方确认并配置以访问测试环境。

烟雾测试

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

STLC - 测试执行

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

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

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

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

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

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

  • 退出标准要求所有测试用例均成功验证；应关闭或推迟缺陷；测试用例执行和缺陷总结报告应该准备好。

测试执行活动

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

系统集成测试

产品/AUT 的真正验证从这里开始。系统集成测试（SIT）是一种黑盒测试技术，用于评估系统是否符合指定的要求/准备的测试用例。

系统集成测试通常在系统的子集上执行。SIT 可以使用最少的测试工具来执行，验证交换的交互，并且还研究各个层内每个数据字段的Behave。集成后，数据流有三种主要状态 -

  • 集成层内的数据状态
  • 数据库层内的数据状态
  • 应用层内的数据状态

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

缺陷报告

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

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

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

缺陷跟踪也是软件工程中的一个重要过程，因为复杂的业务关键系统有数百个缺陷。最具挑战性的因素之一是管理、评估这些缺陷并确定其优先级。随着时间的推移，缺陷的数量会成倍增加，为了有效地管理它们，缺陷跟踪系统可以使工作变得更容易。

缺陷测绘

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

重新测试

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

在重新测试期间，测试人员会查找功能更改区域的详细信息，而回归测试则涵盖所有主要功能，以确保不会因此更改而破坏任何功能。

回归测试

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

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

回归测试的类型

  • 最终回归测试- 执行“最终回归测试”以验证一段时间内未发生更改的构建。此版本已部署或交付给客户。

  • 回归测试- 执行正常的回归测试，以验证构建是否没有通过最近用于缺陷修复或增强的代码更改破坏应用程序的任何其他部分。

活动框图

以下框图显示了此阶段执行的重要活动；它还显示了之前阶段的依赖性 -

测试执行

STLC-缺陷生命周期

缺陷生命周期（Defect Life Cycle），也称为缺陷生命周期（Bug Life Cycle），是缺陷的旅程，是缺陷在其生命周期中所经历的循环。它因组织和项目而异，因为它受软件测试过程的控制，并且还取决于所使用的工具。

缺陷生命周期 – 工作流程

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

缺陷生命周期

缺陷生命周期的状态

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

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

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

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

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

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

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

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

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

  • 已拒绝- 缺陷可以因以下三个原因中的任何一个而被拒绝：重复缺陷、非缺陷、不可再现。

STLC - 缺陷分类

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

什么是优先权？

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

例如，如果公司徽标错误地放置在公司网页中，则优先级较高，但严重性较低。

优先上市

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

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

  • 中- 该缺陷应在后续构建中得到解决。

  • 高- 该缺陷必须立即解决，因为该缺陷对应用程序有相当大的影响，并且在修复之前相关模块无法使用。

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

什么是严重性？

严重性被定义为应用程序中的缺陷的顽劣程度以及从开发角度修复该缺陷的代码的复杂性。这与产品的开发方面有关。严重性可以根据系统缺陷的严重程度来确定。严重性状态可以让您了解由于缺陷而导致的功能偏差。

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

严重性列表

严重性可以按以下方式分类 -

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

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

  • 中/严重度 3 - 缺陷存在单个屏幕问题或与单个功能相关，但系统仍在运行。这里的缺陷不会阻止任何功能。例如，Ticket# 是一种不遵循正确的字母数字字符（如前五个字符和后五个字符）的表示形式。

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

STLC - 测试周期结束

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

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

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

  • 已达到规定的覆盖范围。
  • 没有阻碍或严重缺陷
  • 已知的中优先级或低优先级缺陷很少。这些都不影响产品的使用。

此阶段的退出标准是提供测试结束报告并准备矩阵，随后由客户签署。

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

测试完成报告

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

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

  • 测试总结报告标识符
  • 概括
  • 差异
  • 结果总结
  • 评估
  • 计划与实际努力
  • 搁笔

一份好的测试完成报告可以表明质量、衡量突出的风险并确定测试软件的水平。

测试完成矩阵

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

  • 执行的测试数量
  • 通过测试的数量
  • 失败的测试数量
  • 基于每个模块的测试失败数量
  • 执行周期内出现的测试缺陷数
  • 接受的测试缺陷数量
  • 被拒绝的测试缺陷数量
  • 推迟的测试缺陷数量
  • 活动缺陷的状态
  • 计算构建的质量指数

检测结果

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

表述可以是屏幕截图、数据库查询结果、录音、日志文件等。