测试计划评估模型

测试计划评估模型

陈能技

2007-8-12

原文：Test Plan Evaluation Model - James Bach,

要回答“测试计划定得好不好？”这个问题，就要回答测试计划应该是怎样的。虽然有很多测试计划文档格式模板，但是它们不区分好的计划和差的计划。这个模型识别基本的概念和测试计划应该有的功能，测试计划应该满足的标准，并且提供一些启发以帮助判断测试计划的功能是否满足标准。

Terms and Concepts 术语和概念

_ Test Plan.

测试计划是指导和体现计划的测试过程的想法的集合。

_ Test Plan Document.

测试计划文档是用于传递测试计划信息的任何文档。然而测试计划文档并不是测试计划信息的唯一来源。测试计划信息还包括口头的、公司传统做法等。

_ Test Strategy.

测试策略是测试的设计和执行的方式和方法，用于支持有效的质量评估。测试策略用于计划产品的哪些部分需要测试覆盖，需要使用什么测试方法、技能。

_ Test Project.

测试项目是指测试策略应用和结果输出的项目。

Test Plan Functions 测试计划的功能

1、支持开发的质量评估，确保做出关于产品的明智的和及时的决定。

2、根据技术需求和技术风险描述和表明测试策略（包括提议的测试覆盖）。提醒关于测试策略的好处和限制。

3、为了让测试项目顺利进行而描述和表明任何特定的要求或需满足的进入标准，还有退出的标准或决定停止测试的过程。

4、支持测试项目的初始化和组织，包括准备、组队、职责分配、工具的获取、任务计划和时间表等。

5、支持测试项目和测试策略的每日管理和评估。

6、支持有效的协调、合作、测试组人员之间、测试组与项目组其他人员之间的关系。

7、识别和管理可能影响项目的风险或问题。

8、指明测试项目需要输出的结果和过程。

9、记录历史信息用于支持过程审计、过程改进和将来的测试项目。

Test Plan Quality Criteria 测试计划的质量标准

_ Usefulness.

有效性，测试计划能否有效地支持它应有的功能？

_ Accuracy.

准确性，与实际状态是否一致？

_ Efficiency.

效率，是否充分利用现有资源？

_ Adaptability.

适应性，能否兼容项目中合理的变更和某些未预期的改变？

_ Clarity.

清晰性，测试计划是否自相矛盾，是否足够清晰？

_ Usability.

可用性，测试计划文档是否简单明了，可维护，组织良好？

_ Compliance.

一致性，是否与外部需求一致？

_ Foundation.

基础性，是否是有效测试计划过程的结果？

_ Feasibility.

可行性，是否组织有足够能力执行这份测试计划？

Test Plan Heuristics 测试计划启发

启发	基础启发
1.测试应该被优化以便更快地找到问题，而不是尝试用相同的优先级去把所有问题找出来	问题发现得越迟，在ship date之前安全地修复问题的风险越高。
2.测试策略应该主要专注于潜在的技术风险，同时还要关注低风险的区域，预防出现错误的风险分析	完全的测试是不可能的
3.测试策略应该指明测试的平台配置，产品怎样操作，产品怎样观测，怎样评估产品	忽略这些方面可能造成一些重要的问题不被发现
4.测试策略应该根据测试技术和方法变化。评估测试覆盖的方法应该考虑覆盖的多维性，包括结构、功能、数据、平台、操作方式和需求等	没有一项测试方法能发现所有重要问题，我们也永远不能确信我们是否发现了所有问题。测试策略的多样性可以减少单一测试方法只发现特定类型的问题的风险。
5、测试策略应该指明测试数据怎样设计和产生	测试策略通常围绕功能和代码来组织，让测试员在测试时再考虑与数据连接。那通常意味着测试策略过于关注功能的验证，而忽略了可靠性。
6.并不是所有测试都需要详细地预先指定。测试策略应该让测试员充分考虑环境因素去推理，转注于重要的但非预期的问题。	在不冒犯基本的覆盖的前提下，鼓励测试的合理变化，例如，与哪个结果交互，探索性测试，增加偶发的测试覆盖
7.针对隐含的需求进行测试 - 需求所蕴含的，而不仅仅是需求所说的	只是针对所写的需求进行测试是揭露不了重要问题的，因为需求的定义通常是不完整的，自然语言通常是容易引起误解的。
8.测试员应该尽可能与开发人员、技术支持人员和技术文档编写人员多交流，还应该多与真正的用户和客户多接触以便更好地理解需求	其他组员或利益相关方通常有很多对测试非常有用的关于产品的问题或潜在问题的信息
9.测试员应该多请教开发人员以便帮助他们构建可测性更强的产品	测试策略的有效发挥有赖于产品的可测试性
10.测试计划应该强调非常规的、项目特有的测试策略和测试项目的方面	不要让测试计划看起来跟测试模板没什么两样
11.测试项目应该在人手测试做得好的地方使用人手测试，在自动化测试做得好的地方使用自动化测试。手工测试应该应用在需要思考的地方，自动化测试应该应用在需要高度重复的地方，需要快速进行的地方，不怎么调整的地方	手工测试和自动化测试是两种完全不同的测试方法
12．测试时间表应该体现与开发进度的依赖关系，产品的可测试性，报告问题所需的时间，风险的评估	测试不是独立的活动。
13.测试进度应该尽可能保持独立于决定性的路径。这只能通过测试与开发工作并行，测试员发现错误的速度尽可能比开发人员修复的速度快	这对于为了减轻压力而裁剪测试过程来说非常重要
14.测试员与开发人员之间的反馈周期应该尽可能紧密。测试流程应该设计提供一个快速反馈的机制，让开发人员反馈关于最近新增功能和所做的改变，在一个完整的回归测试开始前测试员应该获取这些信息	这对于最大化质量改进的速度和效率来说非常重要。
15.测试项目应该获取关于质量的信息以便帮助评估和调整测试项目，不仅仅通过正式的测试渠道，还可以通过审查、beta测试、测试组以外的非正式测试	防止正式测试所采用的测试策略不能发现的盲区
16.与测试策略相关的文档，包括测试用例和测试方法应该通过评审	通过评审揭露测试设计的盲区，还能互相学习和提高