5.2 测试规划与估算

5.2.1 测试计划的目的与内容
测试计划罗列了开发和维护项目的测试活动。规划受组织的测试方针和测试策略、开发生命周期和使用的方法（见第2.1节）、测试范围、目标、风险、约束、重要性、可测试性和资源的可用性等因素的影响。
随着项目和测试计划的进展，更多的信息变得可用，更多的细节可以包括在测试计划中。测试计划是一项持续的活动，贯穿于整个产品的生命周期。（请注意，产品的生命周期可能超出项目的范围以包括维护阶段。）根据测试活动的反馈来确认不断变化的风险，从而调整规划。计划可记录在主测试计划和单独的测试级别测试计划中，如系统测试和验收测试，或单独的测试类型，如易用性测试和性能测试。测试规划活动可包括以下内容，其中一些内容可记录在测试计划中：
• 确定测试的范围、目标和风险
• 确定测试的总体方法
• 将测试活动纳入软件生命周期活动并加以协调
• 确定测试什么、进行各种测试活动所需的人员和其他资源，以及如何进行测试活动
• 按照特定的日期（例如：在顺序开发中）或在每个迭代的上下文中，针对测试分析、设计、实现、执行和评估活动制订时间进度表
• 选择测试监视和控制相关的度量
• 确定测试活动预算
• 确定测试文档的详细程度和结构(例如：通过提供模板或示例文档)
测试计划的内容各不相同，并且可以延伸到上述主题之外。测试计划的例子可以在ISO标准中找到（ISO/IEEE/IEEE 29119-3）。
5.2.2 测试策略和测试方法
测试策略通常在产品或组织级别对测试过程进行了描述。常见的测试策略包括：
• 分析型:该类型测试策略基于对一些因素(例如需求或风险)进行分析。基于风险的测试是分析型方法的一个例子，根据风险级别设计测试并确定其优先级。
• 基于模型的：该类型的测试策略，测试的设计是基于产品某些方面的模型，如功能、业务流程、内部结构或非功能特性（如可靠性）。这类模型的例子包括业务流程模型、状态模型和可靠性增长模型。
• 方法型：该类型的测试策略依赖于系统化使用一些预定义的测试集或测试条件，如常见或可能的失效分类，重要质量特性的列表，或全公司的手机应用程序或网页的视觉和感觉标准。
• 符合过程(或标准)：该类测试策略基于外部规则和标准的测试分析、设计和实现测试，如特定行业标准，流程文档，严格标识和使用的测试依据，或组织主动或被动强制的过程或标准。
• 指导型(或咨询型)：该类测试策略主要通过利益相关者、业务领域专家或技术专家的建议、指导或指示驱动，他们可能来自测试小组或组织外。
• 回归避免：该类型的测试策略的动机是希望避免现有能力的回归。这个测试策略包括重用现有的测试件（特别是测试用例和测试数据）、回归测试的广泛自动化以及标准化测试套件。
• 应对型：该类型的测试策略是对正在测试的组件或系统以及在测试执行过程中发生的事件作出反应，而不是事先计划好的（如前面的策略）。设计和实现的测试，可能会根据以前测试结果中获得的知识立即得到执行。探索性测试是应对型策略中常用的一种技术。
合适的测试策略通常是结合多种其中几种类型的测试策略来创建的。例如，例如：基于风险的测试（分析型测试）可与探索性测试（应对型策略）相结合；它们相辅相成，并可在一起使用时实现更有效的测试。
测试策略提供了测试过程的广义描述，而测试方法则针对特定项目或发布对测试策略进行裁剪。测试方法是选择测试技术、测试级别和测试类型的起点，也是定义入口准则和出口准则（或分别是已准备的定义和已完成的定义）的起点。根据项目的复杂性和目标、正在开发的产品类型以及产品风险分析作出的决定，对测试策略进行裁剪。选择的方法取决于上下文，并考虑风险、安全、可用资源和技能、技术、系统特点(例如：定制与COTS)、测试目标和法规等因素。
为了有效控制软件和测试的质量，建议制定准则，以定义特定测试活动何时开始，以及何时完成。入口准则（敏捷开发中更典型地称为已准备的定义）定义了进行特定测试活动的先决条件。如果不符合入口准则，则说明该活动很可能会更困难、更耗时、更昂贵和风险更大。出口准则（敏捷开发中更典型地称为已完成的定义）必须达到的条件，以声明一个测试级别或一组测试已经完成。针对每个测试级别和测试类型，都应该定义入口准则和出口准则，并根据测试目标而有所不同。
典型的入口准则包括：
• 可测试的需求、用户故事和/或模型(例如：在采用基于模型的测试策略时)的可用性
• 已满足上一个测试级别出口准则的测试项的可用性
• 测试环境的可用性
• 所需测试工具的可用性
• 测试数据和其他必要资源的可用性
典型的出口准则包括：
• 完成已计划测试的执行
• 已达到规定的覆盖率(如需求、用户故事、验收准则、风险、代码)
• 未解决的缺陷数目在商定的范围内
• 估计剩余的缺陷数量足够低
• 对可靠性、性能效率、易用性、安全性和其他相关质量特性的评估得到的级别，已经满足要求
即使没有满足出口准则，由于预算超支、计划完成的时间耗完，和/或产品推向市场的压力等原因，而减少测试活动也是常见的。如果项目利益相关者干系人和业务负责人所有人已经评审并接受不再进一步测试的风险，此时结束测试是可接受的。
5.2.4 测试执行进度
一旦生成各种测试用例和测试规程（有些测试规程是自动化的）并组成测试套件，测试套件就可以安排在定义了它们执行顺序的测试执行进度中。测试执行进度应考虑到诸如优先级、依赖关系、确认测试、回归测试以及执行测试的最有效顺序等因素。
理想情况下，测试用例应该是按照其优先级顺序进行执行的，通常是先执行优先级最高的测试用例。但是，如果测试用例具有依赖关系或正在测试的特性之间具有依赖关系，那该实践会不起作用。如果优先级较高的测试用例依赖于优先级较低的测试用例，则必须先执行优先级较低的测试用例。同样，如果测试用例之间存在依赖关系，则必须适当地对它们进行排序，而不管它们的相对优先级如何。确认测试和回归测试也必须根据变更的快速反馈，进行优先级排序，但这里同样受依赖关系的影响。
在某些情况下，可能存在各种不同的测试顺序，不同的顺序之间的效率是不同。在这种情况下，必须在测试执行效率与优先级之间作出平衡。
5.2.5 影响测试工作量的因素
测试工作量估算包括针对特定项目、发布或迭代的测试目标，预测与测试相关工作的数量。影响测试工作量的因素包括产品特点、开发过程特点、人员特点和测试结果，如下所示。
产品特点
• 产品相关的风险
• 测试依据的质量
• 产品的规模
• 产品领域的复杂性
• 质量特性需求（例如安全性、可靠性）
• 测试文档所需的详细程度
• 遵守法律和法规的需求
开发过程特点
• 组织的稳定性和成熟性
• 正在使用的开发模型
• 测试方法
• 使用的工具
• 测试过程
• 时间压力
人的特点
• 参与人员的技能和经验，特别是类似项目和产品有关的技能和经验（如领域知识）
• 团队凝聚力和领导能力
测试结果
• 发现缺陷的数量和严重程度
• 需要的返工量
5.2.6 测试估算技术
有许多估计技术用于确定充分测试所需的工作量。最常用的两种技术是：
• 基于度量的技术：根据以前类似项目的度量，或根据典型值估算测试工作量
• 基于专家的技术：根据测试任务责任人或专家的经验估算测试工作量
例如，例如：在敏捷开发中，当工作量被收集捕获和报告时，燃尽图可以作为基于度量的方法的例子，然后将其作为团队速度的输入，以确定团队在下一次迭代中能做的工作数量；而计划扑克是基于专家的方法的一个例子，因为团队成员正是根据他们的经验来估计提供一个功能所需的工作量（ISTQB-AT基础级别敏捷测试扩展大纲）。
在顺序开发模型的项目中，缺陷移除模型是基于度量的方法的例子，其中捕获和报告了大量缺陷以及移除缺陷的时间，从而为估算未来类似性质的项目提供了基础；而宽带德尔菲估算技术是基于专家的方法的一个例子，其中专家小组根据他们的经验提供了估算结果（ISTQB-ATM高级测试经理大纲）。