原文：https://testing.googleblog.com/2016/06/the-inquiry-method-for-test-planning.html

写测试计划通常是件蛋疼（complex undertaking）的事情。一份理想的测试计划通常是基于成本效益分析和风险分析，各种权衡之后得到的最优解决方案。

• 实现成本：实现的功能要有高可测性，特定的场景要使用自动化，这里面的时间成本和复杂性成本会增加短期开发成本。
• 维护成本：有些测试或者测试计划容易维护，有些根本看不懂，长远来看，也会影响开发成本。尤其是手动测试的功能用例，换了一拨人就完全不会执行了。这成本又大大的增加了。
• 财务成本: 有些测试方法要话费巨大的开销，比如购买几百万的仪器，简直了。
• 收益: 在不同阶段，测试发现和预防问题的能力是不同的。通常越早发现，成本越低，收益越高。
• 风险: 有些异常场景很难出现，有些经常出现，导致的结果有的很轻微，有的也很严重。

如何有效地平衡这些因素，很大程度依赖项目严重性，实现细节，可用资源和团队意见。利用高收益低成本的单元测试，很多项目可以达到高覆盖率。但是这样可能不够，需要投入更多的测试，尤其是复杂的边界情况。关键性项目需要尽可能的减少风险，所以就得投入更高的成本，在所有阶段都要经过严格的测试。

本文其实没啥用，如何找到适当的平衡点得靠你自己。本文也不会提供一个测试计划模板给你，反正给了你也没有啥用。本文主要告诉你，在写测试计划的时候，如何选择最有用的内容。

测试计划和测试策略

开始搞之前，有两个常用的方法需要澄清下：

• Single test plan：某些项目只有一个测试计划，包含了项目中所有的测试实现和计划。
• Single test strategy and many plans: 某些项目有一个测试策略和很多小的测试计划。通常，测试策略包含了所有的测试方法和测试目的，而测试计划则覆盖特定的功能或者本次项目更新。

项目设计文件通常都会有测试计划或者测试策略。这两种方式都挺好，所以选哪个都可以，只要你搞的定。但是通常来说，项目比较稳定的时候，用一个测试计划就够了。如果项目变的很快，那么就需要不停地变化测试策略，然后对应的添加测试计划。

简单起见，后面我们就把这两种方法都写成测试计划。如果你有多个文档，就把下面的建议放进去吧。

内容选择

测试计划，从列出所有需要回答的问题开始。下面会比较综合地列出一些重要的问题，有的适用有的不适用，自己衡量。通过寻找这些问题的答案，组织测试计划的内容，然后用团队常用的格式输出文档。一定要记得，做决定前，需要权衡上面提到的因素。

前提

• 你需要测试计划吗？ 如果项目啥都没有，就不要急着写测试计划。
• 项目设计的时候有没有考虑可测性？ 在开始项目前，所有的场景设计都必须考虑可测性，最好能自动化。所有的文档都要有测试部分。
• 保持测试计划实时更新？ 如果你要 keep 测试计划保持更新，那就要小心了，不要添加太多的细节，否则就很难维护了。
• 测试工作是否和其他团队重叠了？如果是，我们怎么减少这些重复工作呢？

风险

• 是否有值得注意的项目风险, 如何减少项目风险？比如：
  • 会伤害人和动物
  • 用户数据的安全性和完整性
  • 用户隐私
  • 公司系统的安全性
  • 硬件或者物产受到损坏
  • 法律和合规问题
  • 机密或敏感数据的曝光
  • 数据丢失或者损坏
  • 收入损失
  • 不可恢复的场景
  • 能否满足服务标准
  • 性能需求
  • 误导用户
  • 影响其他项目
  • 被其他项目影响
  • 影响公司公众形象
  • 生产力下降
• 技术漏洞是什么？ 比如:
  • 已知的容易被倾入, 脆弱, 需要大规模重构的功能和模块
  • 依赖系统或者平台经常出故障
  • 用户行为可能会破坏系统
  • 从过去的故障中可以预见的问题

覆盖率

• 系统曝露了哪些东东给用户？ 是简单到只有一个方法的库，还是有巨多的接口和组合的多平台 cs 架构系统？我们需要从设计和架构角度指出有可能出问题的点。
• 系统支持哪些平台？ 列出所有支持的操作系统，硬件，设备等等。也要把各个平台上如何执行测试描述清楚。
• 系统有哪些功能？ 把所有的功能都列出来，然后哪些要测试的标注出来。
• 哪些不用测？ 没有一个测试集可以 cover 所有的可能性。所以编一些理由出来为啥不测。。 比如：低风险就低优先级，用例越复杂优先级越低，其他团队负责的用例，还没提测的功能。
• 单元（小型）测试，集成（中型）测试，系统（大型）测试分别覆盖了哪些？ 小型测试越多越好，大型测试越少越好，这也符合那个注明的金字塔。
• 哪些要手动测试，哪些要自动化测试？ 从可行性和效益上来说，自动化通常是最好的。很多项目可以完全采用自动化测试。然而，有时候手动测试也必不可少。描述清楚这些用例为什么需要手动测试。

• 你是怎么覆盖不同的测试种类的？ 比如：

  • 残障测试
  • 功能测试
  • 模糊测试
  • 国际化和本地化
  • 性能, 负载, 压力, and 持久 (aka soak)
  • 隐私
  • 安全
  • 冒烟
  • 稳定性
  • 可用性

• 你会使用静态或者动态分析工具吗？ 静态或者动态代码分析工具可以帮助发现一些 code review 和测试很难发现的问题，所以能用就用呗。

• 系统模块或者依赖是怎么被 mocked 的？单个系统最好把外围依赖都 mocked，然后自己测试，确保自己系统的覆盖率。

• 你是基于什么版本来测试的？ 最新的版本，阶段性的版本，还是 RC 版本？如果每次都用最新的，那你得考虑下怎么测试线上才有的功能。

• 团队之外，还有哪些测试可以做？ 比如：

  • Dogfooding——邀请公司员工参与到测试中来,提供反馈和建议
  • 外部的众包测试
  • 公开的 alpha 或者 beta 测试
  • 给外面的可信任的人测试

• 数据迁移怎么做？ 假如数据结构发生变化或者数据有迁移，必须针对这一块数据相关的进行测试。

• 向下兼容性 新发布的系统是否兼容之前的老版本？其他依赖你的系统是否需要做相应的测试？协议层，接口层，配置，功能等。

• 升级场景测试

• 有行覆盖率吗？

工具和基础设施

• 你要用新的测试框架么？ 如果要用的话，在测试计划里写清楚。
• 你需要设置新的测试实验室么？ 如果是的话，在测试计划里写清楚。
• 如果其他项目需要用到你的项目的服务，那你得提供给其他系统能用的测试工具
• 端到端测试如何联调？环境如何配置，系统如何部署？ 
• 你需要工具来调试系统吗? 要么用现成的工具要么开发一个。

流程

• 有测试进度的要求吗？ 什么时间点交付什么测试？测试执行是否有顺序依赖？
• 持续集成和持续测试怎么整？ 小型测试，比如单元测试应该放到持续集成中去。大型测试，比如 ui 测试，集成测试这些还是按需进行比较好，否则跑一次时间太久。
• 如何报告和监控版本和测试结果？
  • 有团队成员轮班来监控持续集成吗？
  • 大型测试需要一个专家来监控
  • 你需要一个 dashboard 来监控测试结果或者项目健康度吗？
  • 一旦出问题，应该给谁提醒？邮件形式还是其他形式？
• 发布的时候怎么测试？
  • 是否在 RC 版本测试？或者发布流程依赖持续测试的结果？
  • 系统模块和依赖是否可以独立发布？是否要对每个类型的发布进行测试？
  • 如果遇到问题，是否可以终止发布？终止发布的策略是什么？
  • 要发布金丝雀版本，流程监控，测试怎么整？貌似只有谷歌才有金丝雀版本吧？
• 外部用户怎么报 bug？ 一般就是反馈了。
• bug 怎么分类？ 其实一般会有 bug 讨论的时间，对 bug 进行分类降级。然后对严重性高优先级高的 bug 第一响应。
• 关 bug 前，是否会把新的测试用例提交？
• 代码没有提交的时候怎么测试？ 
• 团队其他成员怎么创建或者执行测试？

功用

• 谁是测试计划的读者？ project managers, tech leads, feature owners，把自己当成这些人，才能写好测试计划。
• 读者如何 review 测试用例？有测试用例管理工具就够了。
• 你是否需要追踪需求，功能，测试用例的变化？
• 是否有通用项目健康或者质量目标？怎么才有信心？ 如：
  • 发布节奏
  • 线上 bug 数量
  • 发布测试过程发现的 bug
  • 逾期的 bug 数量
  • Code coverage
  • 人工测试成本
  • 创建测试的困难