ISTQB考点五

5. 测试管理

5.1 测试组织 

5.1.1独立测试

测试中的独立程度包括以下几类（独立性从低到高）：

• 没有独立的测试员；唯一可用的测试形式是开发人员测试他们自己的代码
• 开发团队或项目团队内的独立开发人员或测试员；这可能是开发人员测试他们同事
• 的产品
•  组织内的独立测试团队或小组，向项目管理或企业执行管理层报告
• 来自业务组织或用户团体的独立测试员，或具有特定测试类型的专业知识的测试员，
• 这些特定测试类型包括，例如易用性、安全性、性能、法规/合规性、或可移植性
• 组织外部的独立测试员，无论是工作现场（内包）或现场外（外包）

测试独立性的潜在好处包括：

• 独立的测试员与开发人员相比更可能会识别出不同类型的失效，因为他们有不同的背景、 不一样的技术视角和具有不同的能力
• 独立测试员可以验证、质疑或反驳利益相关方在系统规格说明和实施过程中的假设
• 独立于供应商的测试员可以以一种正直和客观的方式报告正在测试的系统，而不会受到雇
• 佣他们的公司的（政治）压力

测试独立性的潜在缺点包括：

• 与开发团队隔离，可能会导致与开发团队缺乏协作，会延迟向开发团队提供反馈，或与开
• 发团队形成对抗关系
• 开发人员可能会失去对软件质量的责任感
• 独立测试员可能被视为瓶颈
• 独立测试员可能缺乏重要信息（例如，关于测试对象的信息）

 5.1.2 测试经理和测试员的任务

测试经理的典型任务可能包括：

• 与其他项目活动共享测试视角，如集成规划 
• 根据收集的信息准备并提交测试进度报告和测试总结报告
• 支持针对测试过程工具的选择和使用，包括工具选择预算的建议
• 决定测试环境的实施

测试员的典型任务可能包括：

• 分析、评审和评估需求、用户故事和验收准则、规格说明和模型的可测试性（即测试依据）
• 设计、建立和验证测试环境，通常与系统管理和网络管理协调
• 设计和实施测试用例和测试规程
• 创建详细的测试执行进度表
• 评估非功能特性，例如性能效率、可靠性、易用性、安全性、兼容性和可移植性
• 评审他人开发的测试
   

  ---

5.2  测试计划和估算

5.2.1 测试计划内容：

•  安排测试分析、设计、实施、执行和评估活动的进度表
• 选择测试监督和控制的度量
• 为测试活动编制预算

5.2.2. 测试策略和测试方法 

• 分析型：此类测试策略基于对某些因素（例如，需求或风险）的分析。基于风险的测试是

分析型方法的一个示例，这里是根据风险级别设计测试并确定测试的优先级。

• 基于模型：在这种类型的测试策略中，测试是基于产品的某些需求方面的模型设计的，例

如功能、业务流程、内部结构、或非功能特性（例如，可靠性）。此类模型的示例包括业务

过程模型、状态模型和可靠性增长模型。

• 方法论型：此类测试策略依赖于系统地使用一些预定义的测试集或测试条件，例如常见或

可能缺陷类型的分类、重要质量特性列表或公司范围内的用于移动应用或网页的外观和感

受标准。

• 符合流程（或符合标准）：此类测试策略是基于外部规则和标准来开展测试，包括分析、设

计和实施测试，例如行业特定标准、过程文档、严格标识和使用的测试依据，或由组织制

定或针对组织制定的任何过程或标准。

• 指导型（或咨询）：此类测试策略主要由利益相关方、业务领域专家或技术专家的建议、指

导或指示驱动，这些利益相关方、业务领域专家或技术专家可能来自测试团队之外，甚至

是在组织之外。

• 规避回归型：这种类型的测试策略的动机是希望避免现有功能的回归。此测试策略包括重

用现有测试件（尤其是测试用例和测试数据）、回归测试的广泛自动化以及标准测试套件。

• 应对型：在这种类型的测试策略中，测试被动应对被测组件或系统以及测试执行期间发生

的事件，而不是预先计划（如前面的策略所示）。测试经过设计和实施，并可能立即执行以

响应从先前测试结果中获得的知识。探索性测试是应对型策略中常用的技术。

5.2.3 入口准则和出口准则 

典型的入口准则包括：

• 可测试的需求、用户故事、和/或模型的可用性（例如，遵循基于模型的测试策略时）
• 满足任何先前测试级别出口准则相关的测试项的可用性
• 测试环境的可用性
• 必要的测试工具的可用性
• 测试数据和其他必要资源的可用性

典型的出口准则包括：

• 已执行计划的测试
• 已实现规定的覆盖级别（例如，需求、用户故事、验收准则、风险、代码）
• 未解决的缺陷数量在规定的限度内
• 估计的遗留缺陷数量足够低
• 可靠性、性能效率、易用性、安全性和其他相关质量特性的评估级别已达到要求

即使没有满足出口准则，但由于预算已耗尽、预定的时间已到、和/或将产品推向市场的压力，

测试活动被缩减是很常见的。如果项目的利益相关方和业务负责人已经评审并接受了无须进一步测

试的情况下上线的风险，那么在这种情况下结束测试是可以接受的。

 
5.2.4. 测试执行进度表  

如果具有较高优先级的测试用例依赖于具有较低优先级的测试用例，则必须首先执行此优先级较低的测试用例

5.2.5. 影响测试工作量的因素

产品的特点

•  测试依据的质量
•  产品规模
•  产品应用领域的复杂性
•  质量特性要求（例如，安全性、可靠性）
•  所需的测试文档详细程度
•  对法律和法规的合规性要求

开发过程的特点

• 组织的稳定性和成熟度
• 所使用的开发模型
• 测试方法
• 使用的工具
• 测试过程
• 时间压力

人的特点

• 参与人员的技能和经验，尤其是类似的项目和产品（例如，领域知识）
• 团队凝聚力和领导力

测试结果

• 发现缺陷的数量和严重程度
• 所需要的返工量

5.2.6. 测试估算方法  

• 基于度量的方法：根据先前类似项目的度量，或基于典型值来估算测试工作量
• 基于专家的方法：根据测试任务负责人或专家的经验来估算测试工作量

例如，在敏捷开发中，燃尽图是基于度量的方法的示例，当获取和确定剩余工作量并报告，然

后与团队速度（敏捷项目中生产力的度量）一起使用，以确定团队在下一次迭代中可以完成的工作

量；而计划扑克是基于专家的方法的一个例子，团队成员根据他们的经验估算出交付一个特征的工

作量（ISTQB-CTFL-AT）

在顺序开发模型的项目中，缺陷移除模型是基于度量方法的示例，其中获得和报告了缺陷的数

量和移除它们所需的时间，然后为未来估算类似性质的项目提供了基础；而宽带德尔菲估算技术是

基于专家的方法的一个例子，其中专家组根据他们的经验提供估算（ISTQB-CTAL-TM）

---

5.3 测试监督与控制 

5.3.1 测试中使用的度量

常见的测试度量包括：

• 在测试用例准备中，计划工作已完成的百分比（或计划测试用例已实施的百分比）
• 在测试环境准备中，计划工作已完成的百分比
• 测试用例执行（例如，测试用例运行/未运行、测试用例通过/失败，和/或测试条件通过/ 失败的数量）
• 缺陷信息（例如：缺陷密度、发现和修复的缺陷、失效率和确认测试结果）
• 需求、用户故事、验收准则、风险，或代码的测试覆盖
• 任务完成、资源分配和使用以及工作量
• 测试成本，包括与发现下一个缺陷的成本与收益，或执行下一个测试的收益相比的成本

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

典型的测试总结报告可能包括：

• 所开展测试的总结
• 测试周期内发生的情况的信息
• 计划的偏离，包括测试活动的进度、持续时间，或工作量偏差
• 对照出口准则或完成的定义，测试和产品质量的状态
• 已阻碍或继续阻碍进度的因素
• 缺陷、测试用例、测试覆盖、活动进度和资源消耗的度量（例如，如 5.3.1 中所述）
• 剩余风险（见 5.5 节）
• 生成的可重用的测试工作产品

  ---

5.4 风险和测试 

5.4.1. 风险的定义

风险涉及未来可能发生负面后果的事件。风险级别取决于事件发生的可能性以及事件的影响程

度（伤害）

5.4.2. 产品和项目的风险

产品风险涉及工作产品（例如，规格说明、组件、系统或测试）可能无法满足其用户和/或利益

相关方的合法需求的可能性。当产品风险与产品的特定质量特性（例如，功能性、可靠性、性能效

率、易用性、安全性、兼容性、维护性和可移植性）相关联时，产品风险也称为质量风险。产品风险的例子包括：

 软件可能无法根据规格说明执行其预期功能

 软件可能无法根据用户、客户、和/或利益相关方的需要执行其预期功能

 系统架构可能无法充分支持某些非功能性需求

 在某些情况下，可能会不正确地执行特定计算

 循环控制结构可能不正确地编码

 对于高性能事务处理系统，响应时间可能不足

 用户体验（UX）反馈可能无法满足产品预期

项目风险涉及的情况如果发生，可能会对项目实现目标的能力产生负面影响。项目风险的例子

包括：

项目事件：

 延迟可能会出现在交付、任务完成，或满足出口准则或完成的定义时

 不精确的估算、将资金重新分配给更高优先级的项目，或整个组织的一般成本削减可

能导致资金不足

 后期更改可能会导致大量的返工

组织事件：

 没有足够的技能和培训，员工不足

 人员事件可能会导致冲突和问题

 由于业务优先级冲突，用户、业务人员或领域专家可能无法支持

政治事件：

 测试员可能没有充分传达他们的需要和/或测试结果认证测试工程师

基础级大纲

 开发人员和/或测试员可能无法跟进测试和评审中发现的信息（例如，没有改进开发和

测试实践）

 对测试可能存在不正确的态度或期望（例如，不了解测试期间发现缺陷的

价值）

技术事件：

 可能没有很好地定义需求

 考虑到现有的限制，可能无法满足需求

 测试环境可能未按时准备就绪

 数据转换、迁移规划、和它们的工具支持可能延迟

 开发过程中的弱点可能会影响项目工作产品的一致性或质量，例如设计、编程、配置、

测试数据、和测试用例

 较差的缺陷管理和类似问题可能导致累积缺陷和其他技术债务

供应商事件：

 第三方可能无法提供必要的产品或服务、或破产

 合同事件可能会给项目带来问题

项目风险可能会影响开发活动和测试活动。在某些情况下，项目经理负责处理所有项目风险，

但测试经理有时也会负责与测试相关的项目风险。