CTFL（五）管理测试活动

管理测试活动

缺陷管理（defect management），缺陷报告（defect report），入口准则（entry criteria），出口 准则（exit criteria），产品风险（product risk），项目风险（project risk），风险（risk）， 风险分析（risk analysis），风险评估（risk assessment），风险控制（risk control），风险识别 （risk identification），风险级别（risk level），风险管理（risk management），风险缓解 （risk mitigation），风险监测（risk monitoring），基于风险的测试（risk-based testing），测 试方法（test approach），测试完成报告（test completion report），测试控制（test control），测试监测（test monitoring），测试计划（test plan），测试规划（test planning）， 测试进度报告（test progress report），测试金字塔（test pyramid），测试象限（testing quadrants）

测试规划

测试计划的目的和内容

测试计划描述了测试项目的目的、资源和过程。测试计划的目的包括：

• 记录实现测试目的的方法和进度表。
• 有助于确保执行的测试活动符合既定标准。
• 作为与团队成员和其他利益相关方沟通的一种方式。
• 表明测试遵守现有的测试方针和测试策略（或解释为什么测试会偏离这些策略）。

测试规划引导测试人员思考，并促进测试人员面对与风险、进度、人员、工具、成本、工作量等相关的未来挑战。准备测试计划是思考实现测试项目目的所需工作量的过程。

测试计划的典型内容包括：

• 测试的周境（例如，范围、测试目的、约束条件、测试依据）。
• 测试项目的假设和限制。
• 利益相关方（例如，角色、职责、与测试、招聘和培训要求的相关性）。
• 沟通（例如，沟通的形式和频率、文档模板）。
• 风险记录（例如，产品风险、项目风险）。
• 测试方法（例如，测试级别、测试类型、测试技术、测试可交付成果、入口准则和出口准则、 测试的独立性、要收集的度量、测试数据需求、测试环境需求、与组织测试方针和测试策略的偏差）。
• 预算和进度表。

有关测试计划及其内容的更多详细信息，请参阅 ISO/IEC/IEEE 29119-3（或 GB/T 38634.3-2020） 标准。

测试人员对迭代和发布规划的贡献

在迭代软件开发生存周期（SDLC）中，通常会出现两种规划：发布规划和迭代规划。

发布规划着眼于产品的发布，定义和重新定义产品待办事项，并可能涉及将较大的用户故事细化为一组较小的用户故事。它还作为跨所有迭代中测试方法和测试计划的基础。参与发布规划的测试人员参与编写可测试的用户故事和验收准则（参阅第 4.5 节），参与项目和质量风险分析（参阅第 5.2 节）， 估算与用户故事相关的测试工作量（参阅第 5.1.4 节），确定测试方法，并为发布计划进行测试。

入口准则和出口准则

入口准则定义了开展特定活动的先决条件。如果不符合入口准则，这项活动很可能会变得更困难、 耗时、成本高昂、风险更大。出口准则定义了完成测试活动必须达到的目标。应为每个测试级别定义入口准则和出口准则，并根据测试目的而有所不同。

典型的入口准则包括：资源的可用性（例如，人员、工具、环境、测试数据、预算、时间）、测试件的可用性（例如，测试依据、可测试的需求、用户故事、测试用例）和测试对象的初始质量水平（例如，所有冒烟测试都已通过）。

典型的出口准则包括：充分性度量（例如，已实现的覆盖级别、未解决的缺陷数量、缺陷密度、失败的测试用例数量）和完成标准（例如，已执行计划的测试、已执行的静态测试、已报告发现的所有缺陷、已自动化的所有回归测试）。

时间或预算不足也可以被视为有效的出口准则。即使不满足其他出口准则，如果利益相关方已经评审并接受了不做进一步测试就上线的风险，那么在这种情况下可以接受结束测试。

在敏捷软件开发中，出口准则通常称为完成的定义（DoD），定义团队发布项目的客观度量。入口准则包括了必须满足用户故事才能开始开发和/或测试活动，入口准则也称为就绪的定义（DoR）。

估算技术

测试工作量估算包括预测满足测试项目目的所需的测试相关工作量。要向利益相关方明确，估算是基于许多假设的，并且总是会出现估算误差。小任务的估算通常比大任务的估算更准确。因此，当估算大任务时，可以将其分解为一组较小的任务，然后再对其进行估算。

在本教学大纲中，描述了以下四种估算技术。

基于比率的估算：在这种基于度量的技术中，数据是从组织内以前的项目中收集的，这使得可以得出类似项目的“标准”比率。组织自身项目的比率（例如，取自历史数据）通常是估算过程中能使用的最佳数据来源。可以使用这些标准比率来估算新项目的测试工作量。例如，如果在以前的项目中，开发与测试的工作量比为 3:2，而在当前项目中，预计开发工作量为 600 人日，那么测试工作量可以估算 为 400 人日。

外推：这是基于度量的技术，在当前项目中尽早进行测量以收集数据。有了足够的观测结果，剩余工作所需的工作量可以通过外推这些数据（通常通过应用数学模型）来估算。这种方法非常适用于迭代的 SDLC。例如，团队可以将即将迭代的测试工作量外推为最近三次迭代的平均工作量。

宽带德尔菲：这是基于专家的迭代技术，专家进行基于经验的估算。每一位专家独立估算工作量。 收集到的结果如果存在超出商定边界范围的偏差，专家们将讨论他们目前的估算。然后，要求每个专家根据反馈重新独立估算。不断重复此过程，直到达成共识。规划扑克是宽带德尔菲方法的一个变体，通 常用于敏捷软件开发。在计划扑克中，通常使用代表工作量大小的数字卡片进行估算。

三点估算：在这种基于专家的技术中，专家做出三个估算：最乐观的估算（a）、最可能的估算（m）和最悲观的估算（b）。最终估算（E）是它们的加权算术平均值。在该技术最流行的版本中，估算值计算为 E=（a+4m+b）/6。该技术的优点是允许专家计算测量误差：SD=（b–a）/6。例如，如果估算值（人时）为：a=6，m=9 和 b=18，则最终估算值为 10±2 人时（即 8 至 12 人时），因为 E= （6+49+18）/6=10，SD=（18-6）/6=2。

可参阅（Kan 2003，Koomen 2006，Westfall 2009）了解更多的测试估算技术。

测试用例优先级排序

制定完测试用例和测试规程并组装到测试套件之后，测试套件就可以填写进测试执行进度表，该进度表定义了测试套件的运行顺序。在对测试用例进行优先级排序时，可以考虑不同的因素。最常用的测 试用例优先级策略如下：

• 基于风险的优先级：测试执行顺序基于风险分析的结果（参阅第 5.2.3 节）。优先执行覆盖最重要风险的测试用例。
• 基于覆盖范围的优先级：测试执行顺序基于覆盖（例如，语句覆盖）。优先执行覆盖率最高的测试用例。另外一种优先级策略称为附加覆盖优先级，优先执行能达到最高覆盖的测试用例； 后续的每个测试用例都是达到最高附加覆盖率的测试用例。
• 基于需求的优先级：测试执行的顺序基于测试用例对应需求的优先级。需求优先级由利益相关方定义。优先执行最重要需求相关的测试用例。

理想情况下，测试用例将根据它们的优先级排序运行，例如使用上述优先级策略之一。但是如果测试用例或正在测试的特征具有相关性，则这种做法可能不起作用。如果优先级较高的测试用例依赖于优先级较低的测试用例，则必须优先执行低优先级的测试用例。

测试执行的顺序还必须考虑资源的可用性。例如，可能仅在特定时间窗口内可用的测试工具、测试环境或人员。

测试金字塔

测试金字塔是表明不同测试可能具有不同颗粒度的模型。通过说明不同级别的测试自动化支持的不同目标，测试金字塔模型支持团队的测试自动化和测试工作量分配。各金字塔层表示测试集。层越高， 测试颗粒度就越粗，测试独立性越弱和测试执行速度越慢。底层的测试规模小、独立性强、快速，只检查部分功能，因此通常需要大量测试来实现合理的覆盖率。顶层代表复杂的、高级别的、端到端的测 试。这些高层的测试通常比底层的测试慢，并且它们通常检查大块的功能，因此通常只需要其中的几个 测试就可以实现合理的覆盖。金字塔层的数量和命名可能不同。例如，最初的测试金字塔模型（Cohn 2009）定义了三层：“单元/组件测试”、“服务测试”和“UI 测试”。另一个流行的模型定义了单元 （组件）测试、集成（组件集成）测试和端到端测试。也可以使用其他测试级别（参阅第 2.2.1 节）。

测试象限

Brian Marick（Marick 2003，Crispin 2008）定义的测试象限将敏捷软件开发中的测试级别与适当的测试类型、活动、测试技术和工作产品组合在一起。该模型可视化了这些内容，以确保所有适当的测试类型和测试级别都包含在 SDLC 中，解释了某些测试类型比其他测试类型与某些测试级别相关性更 强，以此支持测试管理。该模型还为所有利益相关方（包括开发人员、测试人员和业务代表）提供了区分和描述测试类型的方法。

在这个模型中，测试可以是面向业务的，也可以是面向技术的。测试还可以支持团队（即指导开发）或评价产品（即根据预期衡量其行为）。这两种观点的结合决定了四个象限：

• 象限 Q1（面向技术，支持团队）。此象限包含组件和组件集成测试。这些测试应该是自动化的，并包含在持续集成（CI）过程中。
• 象限 Q2（面向业务，支持团队）。此象限包含功能测试、实例、用户故事测试、用户体验原型、API 测试和模拟测试。这些测试检查验收准则，可以是人工的，也可以是自动的。
• 象限 Q3（面向业务，评价产品）。这个象限包含探索性测试、易用性测试和用户验收测试。这些测试是面向用户的，通常是人工测试。
• 象限 Q4（面向技术，评价产品）。此象限包含冒烟测试和非功能性测试（易用性测试除外）。 这些测试通常是自动化的。

风险管理

组织面临许多内部和外部因素，使其无法确定是否以及何时能实现目的（ISO 31000）。风险管理使组织能够增加实现目的的可能性，提高产品质量，增加利益相关方的信心和信任。

风险管理的主要活动包括：

• 风险分析（包括风险识别和风险评估；参阅第 5.2.3 节）。
• 风险控制（包括风险缓解和风险监测；参阅第 5.2.4 节）。

基于风险分析和风险控制来选择、安排优先级和管理测试活动的测试方法称为基于风险的测试。

风险定义和风险属性

风险是指潜在的事件、危险、威胁或情况，其发生会造成不利影响。风险可由两个因素表征：

• 风险可能性–风险发生的概率（大于零且小于一）。
• 风险影响（危害）–风险发生的后果。

这两个因素表示了风险级别，这是衡量风险的指标。风险级别越高，其处理就越重要。

项目风险和产品风险

在软件测试中，人们通常关注两种类型的风险：项目风险和产品风险。

项目风险与项目的管理和控制有关。项目风险包括：

• 组织问题（例如，工作产品交付延迟、估算不准确、成本削减）。
• 人员问题（例如，技能不足、冲突、沟通问题、员工短缺）。
• 技术问题（例如，范围蔓延、工具支撑不足）。
• 供应商问题（例如，第三方交付失败、供应商公司破产）。

项目风险一旦发生，可能会对项目进度、预算或范围产生影响，从而影响项目实现其目的的能力。

产品风险与产品质量特性有关（如 ISO 25010 质量模型中所述）。产品风险的例子包括：功能缺失或错误、计算错误、运行时错误、架构不良、算法效率低、响应时间过长、用户体验差、安全漏洞。发 生产品风险，可能会导致各种负面后果，包括：

• 用户不满。
• 收入、信任和声誉损失。
• 对第三方的损害。
• 维护成本高，服务台过载。
• 刑事处罚。
• 在极端情况下，造成身体损伤、受伤甚至死亡。

产品风险分析

从测试的角度来看，产品风险分析的目标是提供对产品风险的认识，以便以最小残留产品风险级别的方式集中安排测试工作量。理想情况下，产品风险分析自 SDLC 早期开始。

产品风险分析包括风险识别和风险评估。风险识别就是生成一份全面的风险清单。利益相关方可以使用各种技术和工具来识别风险，例如头脑风暴、研讨会、访谈或因果图。风险评估包括：对已识别的风险进行分类，确定其风险可能性、风险影响和级别，确定优先级，并提出处理方法。分类有助于提出缓解措施，通常同一类别的风险可以使用类似的方法来缓解。

风险评估可以使用定量或定性方法，也可以混合使用。在定量方法中，风险级别为风险可能性和风险影响的乘积。在定性方法中，可以使用风险矩阵来确定风险级别。

产品风险分析可能会影响测试的充分性和范围。其结果可以用于：

• 确定要进行的测试范围。
• 确定特定的测试级别，提供建议执行的测试类型。
• 确定采用的测试技术和达到的覆盖。
• 估算每项任务所需的测试工作量。
• 进行测试优先级排序，以尽早发现关键缺陷。
• 确定是否可以采用除测试之外的其他活动来降低风险。

产品风险控制

产品风险控制包括为应对已识别和评估的产品风险而采取的所有措施。产品风险控制由风险缓解和风险监测组成。风险缓解包括实施风险评估中提出的行动，以降低风险级别。风险监测的目的是确保缓解行动有效，获取进一步信息以改进风险评估，以及识别新出现的风险。

关于产品风险控制，风险分析后，可能有多种风险应对方案，例如通过测试缓解风险、接受风险、 转移风险或应急计划（Veenendaal 2012）。可以通过测试缓解产品风险的活动如下：

• 选择具有适当经验和技能水平、适合特定风险类型的测试人员。
• 应用适当级别的测试独立性。
• 实施评审及静态分析。
• 应用适当的测试技术和覆盖级别。
• 针对受影响的质量特性应用适当的测试类型。
• 执行动态测试，包括回归测试。

测试检测、测试控制和测试完成

测试监测关注测试相关信息的收集。该信息可用于评估测试过程，并测量测试出口准则或与测试出口准则关联的测试活动是否已经满足，例如产品风险、需求、或验收准则是否达到了覆盖目标。

测试控制通过使用测试监测提供的信息，以控制指令的方式提供指导或必要的纠正措施，以达成最有效和最高效的测试。

控制指令的示例包括：

• 已识别的风险成为问题时，重新确定测试优先级。
• 重新评估由于返工而导致的测试项是否满足入口或出口准则。
• 调整测试进度表以应对测试环境交付延迟的问题。
• 在必要的时间和地点增加新资源。

测试完成从已完成的测试活动中收集数据，总结经验、整合测试件和收集任何其他相关信息。测试完成活动发生在项目里程碑处，如测试级别已完成、敏捷的迭代已结束、测试项目已完成（或取消）、 软件系统已发布、或维护版本已完成。

测试中使用的度量

收集的测试度量用以显示相对于计划和预算的当前进度、测试对象当前质量、以及测试活动在达成期望目标或者迭代目标的有效性。测试监测收集各种度量以支持测试控制和测试完成。

常见的测试度量包括：

• 项目进度度量（如：任务完成情况、资源使用情况、测试工作量）。
• 测试进度度量（如：测试用例实施进度、测试环境准备进度、已执行/未执行测试用例数、通过/失败的测试用例数、测试执行时间）。
• 产品质量度量（如：可用性、响应时间、平均失效时间）。
• 缺陷度量（如：发现和修复的缺陷数和优先级、缺陷密度、缺陷检测率）。
• 风险度量（如：遗留风险级别）。
• 覆盖率度量（如：需求覆盖率、代码覆盖率）。
• 成本度量（如：测试成本、组织的质量成本）。

测试报告的目的、内容和受众

测试报告用于在测试过程中和测试结束后总结并沟通测试信息。测试进度报告支持对测试的持续控制，当出现由于偏离计划或环境变化而需要修改测试进度表、资源或测试计划时，测试进度报告应提供足够的信息。测试完成报告总结了测试的特定阶段（如：测试级别、测试周期、迭代），并能为后续的测试提供信息。

在测试监测和控制期间，测试团队为了让利益相关方随时了解情况，向他们提供测试进度报告。测试进度报告通常以固定频率（如：每天、每周等）生成，包括：

• 测试周期。
• 测试进度（如：进度提前或延迟），包括任何显著偏差。
• 测试的阻碍及解决方案。
• 测试度量（参阅 5.3.1 节示例）。
• 测试周期内的新风险和变化的风险。
• 为下一周期计划测试。

在项目、测试级别、测试类型完成，以及理想情况下出口准则得到满足时，测试完成期间准备测试完成报告。测试完成报告使用测试进度报告和其他数据。典型的测试完成报告包括：

• 测试总结。
• 基于原始测试计划（即：测试目的和出口准则）的测试和产品质量评估。
• 与测试计划的偏差（如：与计划的进度表、持续时间和工作量的差异）。
• 测试障碍和解决方案。
• 基于测试进度报告的测试度量。
• 未缓解的风险，未修复的缺陷。
• 与测试相关的经验教训。

在报告中，不同的受众需要不同的信息，因此影响报告的正式程度和频率。向同一团队的其他成员报告测试进度通常更频繁也不正式，而针对已完成项目的测试报告则应遵循固定的模板，并且只进行一 次。

ISO/IEC/IEEE 29119-3 标准（GB/T 38634.3-2020）包括了用于测试进度报告（称为测试状态报告）和测试完成报告的模板和示例。

沟通测试状态

沟通测试状态的最佳方式各不相同，取决于测试管理的关注点、组织级测试策略、法规标准、或者在团队自组织情况下（参阅第 1.5.2 节），取决于团队本身。可能的选项包括：

• 与团队成员和其他利益相关方进行口头沟通。
• 仪表盘（如：CI/CD 仪表盘、任务板、燃尽图）。
• 电子沟通渠道（如：电子邮件、聊天工具）。
• 在线文档。
• 正式测试报告（参阅 5.3.2 节）。

可以使用上述中的一种或多种方式。对于分布式团队来说，由于地理距离或时区差异，直接面对面的沟通可能并不可行，因此更正式的沟通方式可能更合适。通常，不同利益相关方会对不同的信息感兴 趣，因此沟通应进行相应的定制。

配置管理

在测试中，配置管理（CM）提供了识别、控制和跟踪工作产品的规程，如测试计划、测试策略、测试条件、测试用例、测试脚本、测试结果、测试日志和测试报告作为配置项。

对于复杂的配置项（如：测试环境），配置管理（CM）记录它所包含的项、项之间的关联关系和版本信息。如果该配置项被批准用于测试，它就成为了基线，只能通过正式的变更控制过程对其进行更 改。

当创建新基线时，配置管理会记录已变更的配置项。使得通过恢复到先前的基线以重现测试结果成 为可能。

为了恰当的支持测试工作，配置管理（CM）确保：

• 所有的配置项，包括测试项（测试对象的各个部分），均唯一标识、版本控制、变更跟踪，并与其他配置项建立关联，以确保在整个测试过程中的可追溯性。
• 所有标识的文档和软件项在测试文档中都被明确引用。

持续集成、持续交付、持续部署以及和其相关的测试通常作为自动化的 DevOps 流水线的一部分来实现（参阅第 2.1.4 节），其中通常包括自动化的配置管理（CM）。

缺陷管理

发现缺陷是测试的主要目标之一，建立缺陷管理过程是完全必需的。尽管这里指的是“缺陷”，但报告的异常既可能是真正的缺陷，也可能是其他（如：误报，变更请求）——这在处理缺陷报告的过程中会得到确认。在软件生存周期中的任何阶段都可能报告异常，其形式取决于软件生存周期。缺陷管理过程至少包括处理从发现到关闭各个异常的工作流程以及分类规则。工作流程通常包括记录报告的异 常、分析和分类、决定适当的响应（如修复或保持原样）以及最终关闭缺陷报告的活动。所有利益相关方都必须遵守该过程。建议以类似的方式处理静态测试（尤其是静态分析）中的缺陷。

典型的缺陷报告包括以下目的：

• 向负责处理和解决缺陷报告的人员提供足够信息，以解决问题。
• 为跟踪工作产品质量提供途径。
• 为改进开发和测试过程提供思路。

动态测试期间记录的缺陷报告通常包括：

• 唯一标识符。
• 标题，简要总结所报告的异常情况。
• 发现异常的日期、提交的组织、作者及其角色。
• 测试对象和测试环境的标识。
• 缺陷的周境（如：运行的测试用例、执行的测试活动、软件生存周期阶段，以及其他相关信息，如使用的测试技术、检查表或测试数据）。
• 重现失效和解决方案的描述，包括可检测到异常的步骤、以及任何相关的测试日志、数据库转储、屏幕截图或者记录。
• 期望结果和实际结果。
• 缺陷针对利益相关方的利益或需求的严重程度（影响程度）。
• 修复的优先级。
• 缺陷的状态（如：打开、延迟、重复、待修复、待确认测试、重新打开、关闭、拒绝）。
• 引用（如：测试用例）。

使用缺陷管理工具时，其中的一些数据可能会自动包含在内（如：标识符、日期、作者和初始状 态）。在 ISO/IEC/IEEE 29119-3（GB/T 38634.3-2020）标准中可以找到缺陷报告的模板和示例，该标准将缺陷报告（Defect Reports）称为事件报告（Incident Reports）。

---

欢迎关注我的博客，如有疑问或建议，请随时留言讨论。