测试管理

测试组织

• 独立测试的优点与缺点
  • 优点
    • 独立的测试员与开发人员相比可能会识别出不同类型的失败，因为他们都有不同的背景不一样的技术视角具有不同的的能力
    • 可以验证、质疑或者反驳利益相关方在系统规格说明和实施过程中的假设
    • 独立于供应商色测试人员可以以一种正直和客观的方式报告正在测试的系统，而不会受到雇佣他们公司的(政治)压力
  • 缺点
    • 与开发团队隔离，可能导致与开发团队缺乏协作，会延迟向开发团队提供反馈，或与开发团队形成对抗的关系
    • 开发人员可能会失去对软件质量的责任感
    • 独立测试员可能缺乏重要信息
• 测试经历和测试人员的任务
  • 测试经理的任务
    • 制定或评审组织的测试方针和测试策略
    • 通过考虑环境并理解测试目标和风险来规划测试活动。包括选择测试方法，估算测试的时 间、工作量和成本，获取资源并定义测试级别和测试周期，以及规划缺陷管理
    • 编写和更新测试计划
    • 与项目经理、产品负责人和其他人员协调测试计划
    • 与其他项目活动共享测试视角，如集成规划
    • 启动针对测试的分析、设计、实施和执行并监督测试进度和结果，检查出口准则（或完成 的定义）的状态，促使测试完成所有活动
    • 根据收集的信息准备并提交测试进度报告和测试总结报告
    • 根据测试结果和进度（有时记录在测试进度报告中，和/或在项目中已完成的其他测试的测 试总结报告中）调整计划并采取所需的行动以进行测试控制
    • 支持建立缺陷管理系统和针对测试件适当的配置管理
    • 引入适当的度量来测量测试进度并评估测试和产品的质量
    • 支持针对测试过程工具的选择和使用，包括工具选择预算的建议（以及可能的购买和/或支 持），为试点项目分配时间和工作量，以及为使用工具方面提供持续支持
  • 测试经理的角色会因软件开发生存周期的不同而有所差异。例如，在敏捷开发中，上面提到的 一些任务由敏捷团队处理，特别是那些与团队内部日常测试有关的任务，通常由团队内部的测试员 完成。跨越多个团队或整个组织的一些任务、或与人事管理有关的，可以由开发团队以外的测试经 理完成
  • 测试员的典型任务
    • 评审并参与测试计划
    • 分析、评审和评估需求、用户故事和验收准则、规格说明和模型的可测试性（即测试依据）
    • 识别并记录测试条件，并获取测试用例、测试条件和测试依据之间的可追溯性
    • 设计、建立和验证测试环境，通常与系统管理和网络管理协调
    • 设计和实施测试用例和测试规程
    • 准备并获取测试数据
    • 创建详细的测试执行进度表
    • 执行测试、评估结果并记录与预期结果之间的偏差  使用适当的工具来促进测试过程
    • 根据需要自动化测试（可由开发人员或测试自动化专家支持）
    • 评估非功能特性，例如性能效率、可靠性、易用性、安全性、兼容性和可移植性
    • 评审他人开发的测试
  • 测试员是从事测试分析、测试设计、特定测试类型或测试自动化的人员。根据与 产品和项目相关的风险以及所选择的软件开发生存周期模型，不同的人员可以在不同的测试级别上 担当对应的角色

测试计划和估算

• 总结测试计划的目的和内容

  • 测试计划描述了开发和维护项目的测试活动。
  • 制定计划受组织层的测试方针和测试策略影响， 也受开发生存周期和使用的方、测试范围、目标、风险、约束、重要性、可测试 性和资源可用性的影响。
    伴随着测试计划的进展，测试计划中包括的信息会越来越多，越来越详细。测试计划是一项持续的活动，贯穿着整个产品的生存周期，在接下来的使用测试活动会根据反馈来识别不断变化的风险，以便调整计划。
    • 确定测试的范围、目标和风险
    • 定义整体测试方法
    • 将测试活动集成并协调到软件生存周期活动中
    • 确定要测试的内容，开展各种测试活动所需的人员和其他资源，以及如何开展测试活动
    • 安排测试分析、设计、实施、执行和评估活动的进度表，可以按特定日期安排（例如，在顺 序开发中）或以每次迭代的周境安排（例如，在迭代开发中）
    • 选择测试监督和控制的度量
    • 为测试活动编制预算
    • 确定测试文档的详细程度和结构

• 区分各种测试策略之间的差异

  • 测试策略提供测试过程的一般描述，通常是在产品或组织级别上的。常见的测试策略类型包括：
    • 分析型 ：此类测试策略基于对某些因素（例如，需求或风险）的分析。基于风险的测试是 分析型方法的一个示例，这里是根据风险级别设计测试并确定测试的优先级。
    • 基于模型 ：在这种类型的测试策略中，测试是基于产品的某些需求方面的模型设计的，例 如功能、业务流程、内部结构、或非功能特性（例如，可靠性）。此类模型的示例包括业务 过程模型、状态模型和可靠性增长模型。
    • 方法论型 ：此类测试策略依赖于系统地使用一些预定义的测试集或测试条件，例如常见或 可能缺陷类型的分类、重要质量特性列表或公司范围内的用于移动应用或网页的外观和感 受标准。
    • 符合流程 （或符合标准）：此类测试策略是基于外部规则和标准来开展测试，包括分析、设 计和实施测试，例如行业特定标准、过程文档、严格标识和使用的测试依据，或由组织制 定或针对组织制定的任何过程或标准。
    • 指导型 （或咨询）：此类测试策略主要由利益相关方、业务领域专家或技术专家的建议、指 导或指示驱动，这些利益相关方、业务领域专家或技术专家可能来自测试团队之外，甚至 是在组织之外。
    • 规避回归型 ：这种类型的测试策略的动机是希望避免现有功能的回归。此测试策略包括重 用现有测试件（尤其是测试用例和测试数据）、回归测试的广泛自动化以及标准测试套件。
    • 应对型 ：在这种类型的测试策略中，测试被动应对被测组件或系统以及测试执行期间发生 的事件，而不是预先计划（如前面的策略所示）。测试经过设计和实施，并可能立即执行以 响应从先前测试结果中获得的知识。探索性测试是应对型策略中常用的技术

• 给出潜在的入口和出口准则的例子

• 典型的入口准则包括:
  • 可测试的需求、用户故事、和/或模型的可用性（例如，遵循基于模型的测试策略时）
  • 满足任何先前测试级别出口准则相关的测试项的可用性
  • 测试环境的可用性
  • 必要的测试工具的可用性
  • 测试数据和其他必要资源的可用性
• 典型的出口准则包括：
  • 已执行计划的测试
  • 已实现规定的覆盖级别（例如，需求、用户故事、验收准则、风险、代码）
  • 未解决的缺陷数量在规定的限度内  估计的遗留缺陷数量足够低
  • 可靠性、性能效率、易用性、安全性和其他相关质量特性的评估级别已达到要求
• 即使没有满足出口准则，但由于预算已耗尽、预定的时间已到、和/或将产品推向市场的压力， 测试活动被缩减是很常见的。如果项目的利益相关方和业务负责人已经评审并接受了无须进一步测 试的情况下上线的风险，那么在这种情况下结束测试是可以接受的

• 测试进度表
  • 一旦生成了各种测试用例和测试规程（某些测试规程可能会自动化）并集成到测试套件中，测 试套件就可以安排在测试执行进度表中，该进度表定义了它们的运行顺序。测试执行进度表应考虑 诸如优先级、依赖性、确认测试、回归测试和执行测试的最有效顺序等因素
  • 在一些情况下，测试的不同顺序是可能的，在这些情况下必须在测试执行效率与遵守优先级之间进行权衡

测试监督与控制

• 测试监督与控制的目的是收集信息并提供有关测试活动的反馈和可视化。可以手动或自动收集 要监督的信息，这些信息可以用来评估测试进度并测量是否满足测试出口准则，或评估敏捷项目中 定义的相关测试任务是否完成，例如满足产品风险、需求，或验收准则的覆盖目标。
• 测试控制描述了根据收集到和（可能）报告的信息和度量所采取的任何指导或纠正措施。其措 施可能涵盖任何测试活动，并可能影响软件生存周期中的其他活动。
• 调控控制措施的示例包括:
  • 当已识别的风险发生时（例如，软件交付延迟），重新确定测试优先级
  • 由于测试环境或其他资源的可用或不可用而更改测试进度表
  • 由于返工，重新评估测试项是否符合入口或出口准则
• 记忆用于测试的度量
  • 在测试活动期间和结束时收集度量，用以评估：
    • 与计划的时间表和预算对应的进展
    • 测试对象的当前质量
    • 测试方法的充分性
    • 与目标相关的测试活动的有效性

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

• 总结测试报告的目的
  • 测试报告的目的是在测试活动（例如，测试级别）期间和结束时，总结和传达测试活动信息。 在测试活动期间准备的测试报告可能被称为测试进度报告，而在测试活动结束时准备的测试报告可 能被称为测试总结报告

配置管理

总结配置管理是如何支持测试的

风险和测试

• 风险用于关注测试期间所需的工作量。它用于决定何时何地开始测试，以及确定需要更多关注 的区域。测试用于降低发生不良事件的可能性，或减少不良事件的影响。测试用作风险缓解活动， 提供有关已识别风险的信息，并提供有关剩余（未解决）风险的信息。
• 基于风险的测试方法提供了降低产品风险水平的机会。它涉及产品风险分析，包括产品风险的 识别以及每种风险的可能性和影响的评估。由此产生的产品风险信息用于指导测试计划、测试规格 说明、测试用例的准备和执行，以及测试监督和控制。尽早分析产品风险有助于项目的成功。

缺陷管理

• 由于测试的目标之一是发现缺陷，因此应记录测试期间发现的缺陷。记录缺陷的方式可能会有 所不同，具体取决于所测试的组件或系统的环境、测试级别和软件开发生存周期模型。应对所发现 的任何缺陷进行调查，并从发现和分类到其解决进行跟踪（例如，缺陷的修正和缺陷修正后成功进 行确认测试，缺陷延迟到后续版本再修改，接受缺陷作为永久产品限制等）。为了管理所有要解决的 缺陷，组织应建立缺陷管理过程，其中包括工作流和分类规则。此过程必须与参与缺陷管理的所有 人员达成一致，包括架构师、设计人员、开发人员、测试员和产品负责人。在某些组织中，缺陷记录 和跟踪可能不一定很正式。
• 在缺陷管理过程中，某些报告可能会描述假阳性（误报）失效，而不是由于缺陷导致的实际失 效。例如，当网络连接中断或超时，测试可能会失败。这类行为不是由测试对象中的缺陷引起的， 但这是异常情况，需要进一步进行调查。测试员应尽量减少假阳性（误报）缺陷的数量。
• 在编码、静态分析、评审期间，或在动态测试过程中，或软件产品的使用中都可能会报告缺陷。 可能会对代码或工作系统、或任何类型的文档（包括需求、用户故事和验收准则、开发文档、测试 文档、用户手册或安装指南）中的事件报告为缺陷。为了获得有效和高效的缺陷管理过程，组织可 以为缺陷的属性、分类和工作过程定义标准