转自：http://tmq.qq.com/2016/10/do-need-to-consider-all-aspects-of-the-test-plan/
【本文系google blog翻译】
如何做测试计划书，并能有理有力的推动测试计划实施？三星手机连爆事件警醒我们质量是企业头上的一把刀，也是测试工程师头上的一把刀。那么如何做好测试工作？ 首先要做好测试计划并推进计划实施，认真思考并回答文章中这些问题。
原文链接：http://googletesting.blogspot.com/2016/06/the-inquiry-method-for-test-planning.html
制定测试计划是一项复杂的工作。一个理想的测试计划通过成本收益分析和风险分析综合平衡软件开发（kevndi备注：本文中的软件开发是软件工程中的软件开发，包括开发和测试）的相关因素来实现：
- 开发成本：一些特殊场景提供可测试版本和实现自动化测试耗费的时间和复杂性差别很大，而这会影响短期开发成本。（kevindi备注：google基本上是做全自动化测试）
- 维护成本：有些测试工作或测试计划维护成本差别很大，可能很容易也可能很难维护，这会影响长期的开发成本。如果需要手动测试，这也会增加长期成本。
- 金钱成本：有些测试方法可能需要付费资源。
- 测试收益：测试是能够预防问题，并不同程度上助力项目开发（kevindi备注：提高开发效率）。当然，越早发现问题助益越大。
- 风险：缺陷场景的出现概率会有所不同，可能极少出现也可能大部分情况都出现。他们的影响可能是轻微滋扰，也可能是灾难性的后果。
在测试计划中准确的平衡这些因素在很大程度上取决于项目的重要性、实施细节、可利用的资源和团队的意见。许多项目在单元测试中可以高收益，低成本的实现很高的覆盖率，但他们可能需要权衡大规模的测试和复杂边界情况的测试。关键项目必须最大限度地降低风险，所以他们将接受更高的成本，对各级测试用例都大量投入资源。
这份指南用于帮助读者在自己的项目中找到平衡点。此外，它并没有提供一个测试计划模板。模板，因为往往过于笼统或过于具体，很快就会过时。相反，它着重于教你编写测试计划时，如何选择合适的内容。
测试计划与策略
首先，需要澄清测试计划两种常用方法：
单一的测试计划：有些项目有一个“测试计划”，它描述了项目所有执行和计划中的测试。
单一测试策略和大量计划：一些项目有“测试策略”文件以及许多较小的“测试计划”文件。策略通常涵盖了整体的测试方法和目标，测试计划涵盖特定功能或项目变更。
他们都可以写进或者集成到项目设计文件档。这两种方法都很有效，所以可以根据项目情况任意选择。一般来说，稳定的项目受益于一个单一的计划，而迅速变化的项目，最好选择不经常更改的策略和经常变更的计划。在这份指南中，我将把两种测试文档类型简单地统称为“测试计划”，如果您有多种类型文档，只需要把下面的建议应用到全部文档。（kevindi备注：下面开始通过一系列的问题引导读者编写测试计划）
内容选择
写测试计划的一个好办法是先列出所有需要回答的问题，下面的清单提供了所有可能会适用于你的项目的重要问题。浏览一遍列表然后选择适用的。通过回答这些问题，你就可以确定测试计划的内容，你应该围绕所选内容以你团队喜欢的格式创建测试计划。做选择时，请务必平衡好上面提到的影响软件开发的各种因素。
前提条件
你需要一个测试计划吗？如果没有项目设计文档或一个清晰的产品概念，你可能不需要这么早编写测试计划。
项目设计阶段考虑了可测性吗？项目开始实施前，所有方案必须设计为可测试的，最好是通过自动化。项目设计文档和测试计划都应根据需要添加可测性评价。
你需不需要保证测试计划是最新的？如果是这样，请注意不要添加太多的细节，否则可能难以维护测试计划。
其他团队也做质量保障吗？如果是这样，你怎么减少重复性的工作？
风险
- 是否有任何关键的项目风险，以及你将如何缓解呢？比如：
伤到人或动物用户数据的安全性和完整性用户隐私公司系统的安全性硬件或财产损失法律与合规问题机密或敏感数据暴露数据丢失或损坏
收入损失
不可恢复的场景
服务水平协议
性能要求
误导用户
影响到其他项目
受他项目的影响
影响公司的公众形象
生产力损失
- 该项目有没有技术漏洞？试想一下：
功能或组件没有特色，易出故障，或者急需重构开发平台和其他依赖库（SDK等）经常出错用户危害到系统的可能性已知的技术漏洞
覆盖
测试入口是什么样的？它是只有一个对外接口的库，还是一个多平台，有客户端-服务器且有大量用户状态组合的系统？在测试计划中重点说明系统设计和架构可能出现的故障。
支持哪些平台？考虑列出所支持的操作系统，硬件、设备等，还需要说明各个平台如何执行测试用例，如何输出测试结果。
有哪些功能点？考虑把所有功能做一个摘要列表，指出哪些功能是需要测试的。
究竟要不要测试？没有测试套件会涵盖所有的可能性。我们需要直面这个事实，并说明部分用例无法执行的原因。比如：低优先级且低风险的用例，低优先级且复杂的用例，其他团队覆盖的部分，没有达到测试标准的功能等。
需要在什么用例中覆盖？单元测试（小），集成测试（中）还是系统测试（大）用例中覆盖？一般尽量在较小的用例测试，尽可能减少大的测试用例。测试计划需要说明把测试用例放在各个阶段执行的理由。
手动测试和自动化测试哪个是最好的？如果考虑可执行性和成本-收益，自动化通常是最好的。许多项目可以自动化实现所有的测试。但是，可能有更好的理由来选择手动测试。测试计划需要描述手动测试用例的类型并提供理论基础。
- 你是如何覆盖每个测试类别？试想一下：
辅助（无障碍）功能测试功能测试模糊测试国际化和本地化性能，负载，压力和耐久性测试（又名浸泡测试）隐私测试安全测试冒烟测试
稳定性测试
可用性测试
你会使用静态和动态分析工具吗？静态分析工具和动态分析工具可以发现很难在review和测试发现的问题，因此推荐考虑使用它们。
如何对系统组件和依赖库（SDK）stub, mocke, fake, stage和进行功能测试？我们都有足够的动力去做这些事情，这些测试在覆盖率上都有各自的影响。
测试用例是在什么构建版本上执行？最新构建版本测试（kevindi备注：日构建版本？），还是迭代稳定版本，或者预发布版本？如果只测试最新版本，那么你怎么做release版本的增量测试（每个release构建版本的changelist）和系统配置变更测试，这些无法在日构建版本中覆盖到。（kevindi备注：这里指的是release版本间的升级测试）（原文：What builds are your tests running against? Are tests running against a build from HEAD (aka tip), a staged build, and/or a release candidate? If only from HEAD, how will you test release build cherry picks (selection of individual changelists for a release) and system configuration changes not normally seen by builds from HEAD?）
- 哪些测试将在您的团队之外执行呢？例如：
开发自验（DogFooding）外部众包测试公开的alpha/ beta版本（他们发布前如何进行测试？）外部信任的测试（External trusted testers）
数据迁移是如何测试？您可能需要专门测试迁移前和迁移后的结果。
你需要关注向后兼容？你可能拥有已发布的客户端或者有其他系统依赖你的协议，配置，特性和逻辑。
你需要测试升级服务器/客户端/设备软件或依赖库(SDK)/平台/ APIs这些软件组件？
你有代码覆盖率的目标吗？
工具和基础设施
是否需要新的测试框架吗？如果是这样，补充说明或在计划中添加设计环节。
你需要建立一个新的测试实验室？如果是这样，补充说明或在计划中添加设计环节。
如果您的项目需要为其他项目提供服务，你需要提供测试工具给这些用户？考虑提供mocks, fakes, and/or reliable staged servers协助其他用户进行集成测试。
对于端到端的测试，如何将测试基础设施，测试系统，以及其他依赖库（SDK）进行管理？他们如何部署？如何构建持续测试环境和恢复环境？如何做数据中心间的迁移工作？
你需要一些工具来帮助调试系统或异常测试吗？您可以使用现有的工具，或者您可能需要开发新的。
过程
有测试进度要求？已经取得了哪些时间承诺，什么时间该完成什么测试（或提供测试反馈）？是否有些测试是更重要需要提前完成？
如何持续构建和测试？大多数小测试有持续集成工具运行，但大的测试可能需要其他方法实现。或者，如果有必要您可以选择性地运行大型测试。
- 如何报告和监测系统构建及测试结果？
你有一个团队来监控持续集成？大测试可能需要由具有专业知识的人来监测。你需要测试结果状态图和其他项目健康检查工具吗？谁会收到电子邮件警报又如何处理？只需要有人将测试检测结果简单地口头汇报给团队吗？
- 测试在版本发布中起什么作用？
他们是明确要发布待测版本，还是依赖持续集成测试的结果来确定是否发布？如果系统组件和依赖库（SDK）独立发布，需要对他们的每个发布进行测试吗？“阻塞发布”的bug真的能阻止管理者进行版本发布吗？有没有对阻塞发布的标准达成共识？如果进行版本预发布（内测版本、金丝雀版本），这个过程是如何监控和测试的？外部用户将如何报告bug？可以考虑反馈链接或其他类似的工具来收集和汇总。如何完成bug派发工作？可以考虑用标签和分类把bug放置到不同的过滤结果中，需要确保负责创建bug和创建bug报告模板中的团队都指导这一点。您正在使用bug跟踪系统或者你需要设置一些自动或手动导入任务？你有没有制定一个规范，规定在已发现bug解决之前如何再次提测新版本？如何测试未提交的修改？如果任何人都可以对任何实验版本执行所有的测试（一件好事），可以考虑提供一个HOWTO。
团队成员如何创建和/或调试测试用例？可以考虑提供一个HOWTO。
实用技巧
谁是测试计划的读者？有些测试计划只能由少数人看，有的则是被许多人看。至少，你应该考虑所有利益相关者（项目经理，技术负责人，特性负责人）都进行了review。当写测试计划时，一定要了解读者的期望，为他们提供足够的背景了解该计划，并回答您认为他们可能存在的疑问——即使你的答案是，你也没有一个答案。也可以考虑为测试计划添加联系人，因此，任何读者可以得到更多的信息。
读者如何查看实际的测试用例？手工测试用例可能在一个测试用例管理工具里，在一个单独的文件中，或者包含在测试计划中。考虑提供链接到包含自动测试用例的目录。
你是否需要在需求、功能和测试用例之间建立关联性？
- 你是否有产品健康或质量目标，你会如何衡量成功？试想一下：
发行节奏在开发阶段用户抓bug的数量在发布测试阶段bug的数量延期解决Bug的数量代码覆盖率手动测试成本创建新测试用例的难度