本指南旨在帮助读者制定
测试计划。请注意，真正的测试计划是实际指导自己实施测试的一套想法。不管读者是否制定书面测试计划，我们设计的这个指南都会有所帮助。
本指南并不是一种模板，不是供读者填写的表格，而是一组旨在帮助读者思考的思想，用于降低读者遗忘重要内容的可能性。我们使用的是简洁语言和描述，有可能不太适合测试新手。本指南主要向有经验的测试员或测试组长提供支持。
以下分 七个任务主题。这些主题没有一定顺序。实际上，读者可以按任何顺序阅读。只是需要注意，测试计划的质量与是否很好地执行了任务以及使否很好地考虑了像这里提出的问题相关。状态检查部分有助于读者确定是否制定了足够好的测试计划，但是我们建议读者要在整个项目开发过程中，重新检查并修改测试计划（至少要在心中修改）。
1. 监视影响测试计划的主要问题
确定影响制定实用、有效的测试策略中时间、
工作量或可行性要素的风险、障碍或其他挑战。要把握计划的整体作用。在整个项目开发过程中，全程监视这些问题。
____ 状态检查___________________________________________________
□ 是否有要满足的特别关键或很难度量的产品质量标准？
□ 产品是否复杂或很难学会？
□ 测试员是否需要特殊培训或工具？
□ 是否很难得到或配置的部分测试平台？
□ 是否将测试未集成或半可操作的产品组件？
□ 是否存在具体的可测试性问题？
□ 项目团队是否缺乏产品设计、技术或用户群的经验？
□ 测试是否必须很快开始？
□ 是否有制定测试计划所需的信息还没有收集到？
□ 是否能够评审被测产品的某个版本（甚至是演示版、原型版或老版本）？
□ 是否有足够的难以录用或组织的测试人员？
□ 是否必须遵循自己所不熟悉的测试理论？
□ 项目计划的制定是都没有考虑测试需要？
□ 计划是否要经过漫长的协商或批准？
□ 测试员是否远离客户？
□ 计划是设计的一个内容吗？
□ 客户是否说不出测试员能够为他们做什么？
2. 明确任务
本节给出的任何一部分或全部目标都可能是具体测试任务的一部分。有些任务比另外一些更重要。根据对具体项目的了解，为这些目标排队。对于所有使用的目标，找出可以用来评判的具体的成功指标。
需要考虑的任务要素
□ 快速找出重要问题。
□ 进行综合质量评估。
□ 确认产品质量是否达到具体标准。
□ 尽可能缩短测试时间或降低测试成本。
□ 尽可能提高测试效率。
□ 就提高质量或可测试性问题，向客户提出建议。
□ 就如何测试向客户提出建议。
□ 保证测试过程总是可以充分说明的。
□ 严格遵守特定的方法或指示。
□ 使特定的项目相关人员感到满意。
可能的工作产品
□ 说明测试任务的简短电子邮件。
□ 一页纸篇幅的测试要求。
____ 状态检查___________________________________________________
□ 是否知道谁是自己的客户？
□ 关键人物是否赞同测试任务？
□ 测试任务是否足够清晰，以作为制定计划的基础？
3. 分析产品
了解被测试产品及其内部技术。了解如何使用被测产品。需要深入下去。随着对产品了解的深入，测试会变得越来越好，因为自己越来越接近成为产品专家
分析什么
□ 用户（用户是谁，他们的职业是什么）。
□ 结构（代码、文件等）。
□ 功能（产品做什么）。
□ 数据（输入、输出、状态等）。
□ 平台（外部硬件和软件）。
□ 运营（产品是用来完成什么任务的）。
分析方式
□ 执行探索式测试。
□ 评审产品和项目文档。
□ 与设计人员和用户面谈。
□ 与类似产品进行比较。
可能的工作产品
□ 测试覆盖大纲。
□ 带注释的规格说明。
□ 产品问题清单。
____ 状态检查___________________________________________________
□ 设计人员赞同产品覆盖大纲吗？
□ 设计人员认为测试员了解产品吗？
□ 测试员能够可视化产品并预测产品行为吗？
□ 测试员能够产生测试数据（输入和结果）吗？
□ 测试员能够配置并操作被测产品吗？
□ 测试员理解产品将被怎样使用吗？
□ 测试员是否发现设计中的不一致问题？
□ 测试员是否找出显式和隐式规格说明？
4. 分析产品风险
被测产品可能怎样以一种重要方式失效？开始测试员最多也智慧有一个一般想法。随着测试员对产品了解的深入，测试策略和测试会变得越来越好，因为对被测产品的失效机理了解的越来越多。
分析对象
□ 威胁（具有挑战性的条件和数据）。
□ 脆弱性（在什么地方可能失效）。
□ 失效模式（可能的问题种类）。
□ 失效影响（问题的严重程度）。
分析方式
□ 评审需求和规格说明。
□ 评审实际失效。
□ 与设计人员和用户面谈。
□ 对照风险启发和质量评判大纲评审产品。
□ 找出一般问题和失效模式。
可能的工作产品
□ 组件/风险矩阵。
□ 风险清单。
____ 状态检查___________________________________________________
□ 设计人员和用户对风险分析认可吗？
□ 测试员能够找出所有重要的问题种类吗？这些问题都应该在测试期间出现吗？
□ 为了尽可能提高测试效果，测试员知道该把测试工作集中到哪些对象上吗？
□ 设计人员是否采取措施使重要问题更容易被检测，或降低发生的可能性？
□ 测试员如何发现自己的风险分析是否准确？
5. 设计测试策略
为了根据已有的产品最佳信息快速、有效地测试，测试员可以做什么？首先尽可能做出最好的决策，同时又要让测试策略能够在项目整个开发过程中改进。
考虑五方面的手段
□ 以测试员为核心的手段。
□ 以覆盖率为核心的手段（结构覆盖率和功能覆盖率）。
□ 以问题为核心的手段。
□ 以活动为核心的手段。
□ 以评估为核心的手段。
计划方式
□ 针对风险和产品域确定手段。
□ 可视化具体和实用手段。
□ 使测试策略多样化，尽可能减少遗漏重要问题的机会。
□ 寻找通过自动化测试扩展测试策略的途径。
□ 不要计划得过死，使测试员能够发挥自己的才智。
可能的工作产品
□ 逐项列出的每条所选测试策略以及如何运用的说明。
□ 风险/任务矩阵。
□ 所选测试策略固有的问题或挑战清单。
□ 针对没有充分覆盖的产品部分提出的建议。
□ 测试用例（仅当需要时）。
____ 状态检查___________________________________________________
□ 客户认同测试员制定的测试策略吗？
□ 测试策略给出的所有内容都是必要的吗？
□ 测试策略是否能够实际贯彻？
□ 测试策略是否过于通用？可以容易地用于任何产品吗？
□ 是否还有不准备测试的任何重要问题？
□ 测试策略利用了可用的资源和帮助者吗？
6. 条件计划
测试经理将如何实现测试策略？测试策略会受到条件约束或指示的很大影响，努力争取所需的资源，并尽量利用可用的所有资源。
保障条件方面的问题
□ 测试工作量估计和进度评估。
□ 可测试性宣传。
□ 测试团队力量（合适技能）。
□ 测试员培训与管理。
□ 测试员任务分配。
□ 产品信息收集与管理。
□ 项目团队会议、沟通和协同。
□ 与项目团队所有其他小组、包括开发小组的关系。
□ 测试平台的获得和配置。
□ 约定和协议。
□ 测试工具和自动化测试。
□ 插桩和模拟需要。
□ 测试包的管理和维护。
□ 构建和传送协议。
□ 测试周期管理。
□ 错误报告系统和协议。
□ 测试状态报告协议。
□ 代码冻结与增量测试。
□ 项目最后的压力管理。
□ 测试停止协议。
□ 测试效果的评估。
可能的工作产品
□ 问题清单。
□ 产品风险分析。
□ 责任矩阵。
□ 测试进度计划。
____ 状态检查___________________________________________________
□ 项目团队的保障条件是否支持已制定的测试策略？
□ 是否存在阻碍测试的问题？
□ 测试条件和策略是否能够修改，以适应可以预见的问题？
□ 现在是否可以开发测试，以后再解决其余问题？
7. 共享测试计划
测试员并不孤独。测试过程必须服务于项目团队。因此，要吸收项目团队成员参与测试计划的制定。不必夸大这个问题，至少要与团队的关键成员讨论，从而得到他们的理解和隐含的支持，以争取实现测试计划。
共享方式
□ 吸收设计人员和项目相关人员参加测试计划制定过程。
□ 积极征求有关测试计划的意见。
□ 尽自己所能帮助开发人员获得成功。
□ 帮助开发人员理解他们的行为会对测试产生的影响。
□ 与技术文档编写员和技术支持人员就分享质量信息进行沟通。
□ 请设计人员和开发人员评审和批准参考材料。
□ 记录和跟踪约定。
□ 请别人分段评审测试计划。
□ 通过减少测试计划文档中不必要的文字，来改进文档的可评审性。
目标
□ 对测试过程的一致理解。
□ 对测试过程的一致承诺。
□ 测试过程的合理参与。
□ 管理层对测试过程的合理预期。
____ 状态检查___________________________________________________
□ 项目团队是否关注测试计划。
□ 项目团队，特别是一线管理人员是否理解测试小组的角色？
□ 项目团队是否感觉到测试小组关心项目团队的最佳利益？
□ 测试小组和项目团队其他小组之间是否有对立或积极的关系？
□ 是否有人认为测试员没有将注意力集中到重要的测试上？
=========================================================================
这是一篇很长的文章，是讨论如何制定语境驱动测试的测试计划。会有很多的检查项，帮助读者不要忘记重要的内容。如果想照搬，肯定是不现实的。