不论是刚毕业的Tester还是测试老鸟，是否想过“测试计划”怎么写？以前写的测试计划“合格”吗？我想很多人无法给出答案。
做测试计划通常是一件非常复杂的事情，一个理想的测试计划要完成“投资回报分析”和“风险分析”，在软件开发的众多因素中寻求一个最优解▼
实现投入： 实现“可测试性”和某些场景的自动化测试，需要花费大量的时间，还会增加软件复杂度。会增加短期内的研发投入。
维护投入： 不论是自动化测试还是手工测试，都会不同程度地增加长期投入。
财务投入： 有些测试可能会需要资金投入。
回报： 测试能够减少软件bug，并在不同程度上提升生产力。在软件研发过程中，越早发现问题，带来的收益越大。
风险： 无法预测什么时候会碰到出问题的场景，而一旦出问题，带来的后果也无法预测：可能只是对用户体验有少许影响，也可能是一场灾难。

要有效的平衡以上因素，需要评估项目的具体情况：如何实现的？资源是否可用？团队是什么意见？尽管许多项目能够做到“低投入，高回报”的高覆盖率单元测试，但是他们也需要衡量“larger tests”和更复杂的场景。关键性的项目必须尽可能的降低风险，为了覆盖所有的测试层级，可能会做出一个高投入的测试决策。
本文将围绕“如何找到项目中的平衡点”展开。因为模板往往不具备通用性，而且很容易“过时”，所以在这里并不会提供测试计划模板。内容聚焦于做测试计划的过程中“如何选择最优的内容”。

测试计划 vs 测试策略

开始之前，先澄清一下两种定义测试计划的方式：
单个测试计划： 一些项目拥有单个“测试计划”，描述与项目相关的所有实现与测试。
单个测试策略+多个测试计划： 一些项目拥有单个“测试策略”和许多小的“测试计划”文档。测试策略覆盖所有的测试路径与目标，测试计划覆盖特定的特性或者项目更新。

或许两种“测试计划”并没有孰优孰劣之分，请针对具体的项目具体选择。一般来说，稳定的项目选择“单个测试计划”更好，变化频繁的项目更加适合“固定测试策略”+“不固定增加的测试计划”。

内容选择

做测试计划最好的方式是罗列出所有需要解答的问题。无论是否会对项目产生影响，我们都要全面的进行收集所有重要问题。浏览一下收集的问题列表，筛选出所有影响项目的问题。在回答这些问题的过程中，就可以理出测试计划的内容，然后以团队可接受的方式编写一份测试计划（需要综合考虑上文中提到的几个因素来衡量计划的内容）。

前提

需要测试计划吗？ 如果没有项目设计文档或者还不清楚项目长什么样，那么不要急着去写测试计划。可测试性是否被纳入了项目设计？ 在项目开始大规模开发之前，必须为所有的场景设计可测试性，最好能够支持自动化测试。项目设计文档和测试计划中都需要对可测试性提出要求。需要持续更新测试计划吗？ 如果要持续更新，请不要在计划中描述太多的细节，否则将难以维护。工作成果是否与其他团队有重叠？ 如果有重叠，如何避免重复工作？

风险

是否有明显的项目风险，如何减少风险？ 例如：

会伤害人或动物
影响用户数据的安全性和完整性
侵犯用户隐私
影响公司系统安全
导致硬件或财产损失
存在法律或诚信问题
泄露机密或者敏感信息
导致数据丢失
导致收入减少
存在无法覆盖的场景
需要满足性能要求
误导用户
影响其他项目
被其他项目影响
影响公司对外形象
降低生产力
项目有哪些技术缺陷？ 例如：

已知特性或者组件容易被入侵，健壮性检查，或者急需重构
项目依赖的组件或者平台频繁导致问题
用户有可能会对系统造成破坏
以往问题的趋势如何

覆盖率

项目长什么样？ 是一个只有一个方法的简单library，还是有复杂用户场景的软件系统？描述被测系统的设计和架构，分析可能出问题的地方。
支持什么平台？ 建议列举出支持的操作系统，硬件，设备等。描述一下不同平台上测试的表现。
有什么特性？ 建议将所有特性列出概要清单，描述一下哪些特性要进行测试。

哪些内容不会被测试？ 没有一种测试会覆盖所有可能性。最好提前想好哪些用例不会进行测试。例如：”低风险低优先级用例“，”复杂功能低优先级用例“，”被其他团队测试过的功能“，”没有准备好的特性“等等，都属于低风险功能，而不会进行测试。

单元测试（small）、集成测试（medium）、系统测试（large）分别应该覆盖那些功能？ 尽可能多地做“smaller tests”，少部分的用例使用“larger tests”。描述一下不同种类测试用例分别在哪种规模的测试中进行，并提供理论依据。

哪些用例要手工执行，哪些用例要自动化？ 如果自动化具备可行性并且实现代价不高，通常是最好的选择。许多项目能将所有测试都自动化。然而，有些项目选择手工测试也有充分的理由。描述一下什么样的测试用例要进行手工测试，并提供理论依据。
是否覆盖了所有测试类型？ 例如：
可达性
功能
模糊（测试）
国际化和本地化
性能，加载，压力和耐久性
隐私
安全性
冒烟
稳定性
易用性
需要使用静态和/或动态分析工具吗？ 无论是静态分析工具，还是动态分析工具都能够找到一些测试过程中很难找到的问题，所以建议使用分析工具。

测试过程中，系统组件和依赖之间是“stubbed”，”mocked”，”faked”，”staged”,还是正常使用？ 每一项内容都会影响最终的测试覆盖率。

测试运行在哪个”构建“之上？ 在”HEAD“，”stage“，还是”待发布“版本之上？如果是在”HEAD“上测试，怎么测试”cherry picks（只发布部分改动）“？怎么测试系统配置的改变？

什么样的测试应该在团队之外进行？ 例如：
”吃狗粮“
外部的众包测试
公开的”alpha/beta“版本（如何在正式发布前测试）
可信的外部Tester

怎么测试数据迁移？ 可能需要特殊的测试来对比迁移数据前后的结果。
是否需要关注向后兼容？ 可能存在一个以前版本的客户端，或者有另外一个系统依赖于当前系统的协议、配置、特性或者行为。
是否需要测试”服务器/客户端/终端“的升级场景？是否需要测试软件所依赖的”库/平台/API“？
是否有代码行的覆盖率的目标？

工具和基础建设

是否需要新的测试框架？ 如果需要，请描述或者在测试计划中增加设计链接。
是否需要新的测试实验室？ 如果需要，请描述，或者在测试计划中增加设计连接。
如果当前项目为其他项目提供服务，是否要像用户提供测试工具？ 建议提供”mocks“，”fakes“和/或可靠的stage服务器，方便用户进行集成测试。
对于end-to-end测试，如何管理测试基础设施、被测系统和其他的依赖？ 如何部署？如何持续地进行“set-up/tear-down”？数据迁移怎么做？
是否需要工具来对系统进行debug或者测试错误？ 可以使用现有的工具，也可能需要开发一款新的工具。

执行过程

是否要拿出一个测试时间表？ 什么时间，会进行哪一项测试（或者提供测试结果）？是否一些测试的比其他测试更加重要？
如何持续不断的进行构建和测试？ 大部分”small tests“会通过持续集成工具来运行，但是”large tests“可能需要不同的运行方式。
如何上报和监控构建和测试的结果？

是否有一个团队负责监控持续集成？
”large tests“可能要求专业技术人员来进行监控。
是否有一个dashboard来查看测试接结果和项目的健康度？
如何发送告警邮件，以及告警邮件会通知哪些人？
监控测试的同事只是简单地以口头传达的方式通知团队吗？
发布过程中如何进行测试？

是不是只会使用”待发布版本“，或者发布的程序严格依赖于持续测试的结果？
如果系统组件和依赖要被独立发布，是否在每一个发布类型上都进行了测试？
发布决策者是否会因”阻塞发布”的bug停止发布？“阻塞发布”是否有统一的标准？
首次发布的时候，如何监控进度并组织测试？
外部用户如何上报bug？ 建议增加反馈连接或者其他类似的工具来收集上报的问题。

如何将bug分类？ 建议使用标签和类型对bug进行分类管理。同时确保团队也要使用与此相同的bug上报模板。

应该被解决的bug未解决就要被close，是否有一种机制可以提交新的测试？

未提交的改动如何进行测试？ 如果有人能做到，建议提供使用说明。

团队成员如何构建测试 和/或 进行debug？ 建议提供使用说明

使用
测试计划的读者是谁？ 虽然有些测试计划会被许多人读到，但是有些测试计划只会被很少一部分人读到。测试计划至少应该被所有的利益相关者（项目管理者，技术leader，产品管理者）review。写测试计划的时候为了确保读者能够理解，需要提供足够的背景材料，回答所有可能的疑问。同时，建议在测试计划中增加联系方式，方便读者能够获取更多的信息。

读者如何review测试用例？ 手工测试用例可能会被放在一个测试用例管理工具中，可能会放在单独的文档中，也可能直接写在测试计划中。自动化测试建议提供对应的链接。

需求、特性和测试之间是否需要可追溯？

是否有通用的产品健康度或者质量目标？如何进行评估？ 例如：
发布节奏
用户发现的bug数量
在“release testing”中发现的bug数量
超时未解决的bug数量
代码覆盖率
手工测试的投入
创建新测试的难度