测试计划的重要性：

如果没有测试计划会带来哪些问题：

1. 很难确切地知道具体的测试范围，以及应该采取的具体测试策略；
2. 很难预估具体的工作量和所需要的测试工程师数量，同时还会造成各个测试工程师的分工不明确，引发某些测试工作被重复执行而有些测试则被遗漏的问题；
3. 测试的整体进度完全不可控，甚至很难确切知道目前测试的完成情况，对于测试完成时间就更难预估准确的时间节点了；
4. 整个项目对潜在风险的抵抗能力很弱，很难应对需求的变更以及其他突发事件。

测试报告的组成部分：

** 测试范围 **
测试范围描述的是被测对象以及主要的测试内容。测试范围的确定通常是在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，这将有助于在早期阶段就发现潜在的测试遗漏。同时，由于不可能进行穷尽测试，而且测试的时间和资源都是有限的，所以必须有所取舍，进行有针对性的测试。因此，测试范围中需要明确 “测什么” 和 “不测什么”。

** 测试策略 **
测试策略简单来讲就是需要明确 “先测什么后测什么” 和 “如何来测” 这两个问题。病有轻重缓急，测试也是一样的道理，重要的项先测，而不重要的项要后测。测试策略会要求我们明确测试的重点，以及各项测试的先后顺序。
测试策略还需要说明，采用什么样的测试类型和测试方法。这里需要注意的是，不仅要给出为什么要选用这个测试类型，还要详细说明具体的实施方法。

• 功能测试，特别是主干业务流程的测试优先级最高。

  • 主线业务的功能测试由于经常需要执行回归测试，所以需要考虑实施自动化测试，通常需要先列出主要的功能测试点，并决定哪些测试点适合采用自动化测试，并且决定具体使用什么样的框架和技术。
  • 对于需要手工测试的测试点，你要决定采用什么类型的测试用例设计方法，以及如何准备相关的测试数据。
  • 还要评估被测软件的可测试性，如果有可测试性的问题，需要提前考虑切实可行的变通方案，甚至要求开发人员提供可测试性的接口。

• 兼容性测试，Web 测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体 iOS/Android 的版本等。

  • 兼容性测试的实施，往往是在功能测试的后期，也就是说需要等功能基本都稳定了，才会开始兼容性测试。
  • 当然也有特例，比如，对于前端引入了新的前端框架或者组件库，往往就会先在前期做兼容性评估，以确保不会引入后期无法解决的兼容性问题。
  • 兼容性测试用例的选取，往往来自于已经实现的自动化测试用例。

• 性能测试，需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。

  • 性能测试的实施，往往先要根据业务场景来决定需要开发哪些单用户脚本，脚本的开发会涉及到很多性能测试脚本特有的概念，比如思考时间、集合点、动态关联等等。
  • 脚本开发完成后，你还要以脚本为单位组织测试场景（Scenario），场景定义简单来说就是百分之多少的用户在做登录、百分之多少的用户在做查询、每个用户的操作步骤之间需要等待多少时间、并发用户的增速是 5 秒一个，还是 5 秒 2 个等等。
  • 最后，才是具体的测试场景执行。和自动化功能测试不同，性能测试执行完成后性能测试报告的解读，是整个测试过程中最关键的点。

** 测试资源 **
测试资源通常包括测试人员和测试环境，这两类资源都是有限的。测试计划的目的就是，保证在有限资源下的产出最大化。所以，测试资源就是需要明确 “谁来测” 和 “在哪里测” 这两个问题。

• 测试人员，测试人员的资源通常有两个维度：一是，测试工程师的数量；二是，测试工程师的个人经验和能力。

  • 难度较大的工作，或者一些新工具、新方法的应用，又或者自动化测试开发工作，通常由资深的测试工程师来承担；而那些相对机械性、难度较小的工作，则由初级工程师完成。
  • 要想规划好测试资源，除了要了解项目本身外，还必须对测试团队的人员特点有清晰的把控。
  • 把具体的任务清晰地落实到每个人的身上，这将有利于建立清晰的责任机制，避免后续可能发生的扯皮。

• 测试环境和设备，不同的项目，可能会使用共享的测试环境，也可能使用专用的测试环境，甚至还会直接使用生产环境。

** 测试进度 **
测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。
比如，版本接受测试（Build Acceptance Test）的工作量，冒烟测试（Smoke Test）的工作量，自动化脚本开发的工作量，缺陷修复的验证工作量，需要几轮回归测试、每一轮回归测试的工作量等等。

** 测试风险 **
通常需求变更、开发延期、发现重大缺陷和人员变动是引入项目测试风险的主要原因。

• 对于需求变更，比如增加需求、删减需求、修改需求等，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目经理和产品经理及时沟通因此引起的测试进度变化。测试经理 / 测试负责人切忌不能有自己咬牙扛过去的想法，否则无论是对测试团队还是对产品本身都不会有任何好处。
• 在制定测试计划时，需要预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略。

互联网产品的测试策略

互联网产品的研发流程和传统软件产品的研发流程的不同决定了其对应的测试策略的不同。发布周期的巨大差异决定了，传统软件产品的测试策略必然不适用于互联网产品的测试，二者的测试策略必然在测试执行时间和测试执行环境上有巨大差异。对互联网产品来说，通常 24 小时就会有一到两次的发布，发布流程通常包含了代码静态扫描、单元测试、编译、打包、上传、下载、部署和测试的全流程。留给测试执行的时间就非常有限，通常情况下，互联网产品要求全回归测试的执行时间不能超过 4 小时。
如何在保证测试质量和测试覆盖率的前提下，有效缩短测试执行时间呢？

• 首先，可以引入测试的并发执行机制，用包含大量测试执行节点的测试执行集群来并发执行测试用例。
• 其次，选择合适的测试策略，有的放矢。

** 传统软件产品的测试策略设计 **
传统软件产品的测试策略，通常采用下图中的金字塔模型。

第一层，单元测试，属于白盒测试的范畴，通常由开发工程师自己完成，由于越早发现缺陷其修复成本越低，所以传统软件产品的测试策略提倡对单元测试的高投入，单元测试这一层通常都会做得比较 “厚”。

第二层，API 测试，金字塔中间部分是 API 测试，主要针对的是各模块暴露的接口，通常采用灰盒测试方法。灰盒测试方法是介于白盒测试和黑盒测试之间的一种测试技术，其核心思想是利用测试执行的代码覆盖率来指导测试用例的设计。

第三层，GUI 测试，金字塔最上层的是 GUI 测试，也称为端到端（E2E，End-to-end）测试，是最接近软件真实用户使用行为的测试类型。通常是模拟真实用户使用软件的行为，即模拟用户在软件界面上的各种操作，并验证这些操作对应的结果是否正确。GUI 测试的优点是，能够实际模拟真实用户的行为，直接验证软件的商业价值；缺点是执行的代价比较大，就算是采用 GUI 自动化测试技术，用例的维护和执行代价依然很大。

** 互联网产品的测试策略设计 **
互联网产品通常采用菱形的测试策略，遵循 “重量级 API 测试，轻量级 GUI 测试，轻量级单元测试” 的原则。

第一层，单元测试，互联网产品追求的是最快速的功能实现并上线，基本不会给你时间去做全面的单元测试。即使给你预留了单元测试的时间，频繁的迭代也会让单元测试处于不断重写的状态。因此，单元测试原本的价值，很难在实际操作层面得到体现。那么，互联网产品真的可以不用做单元测试么？答案是否定的，只不是这里的单元测试策略要采用 “分而治之” 的思想。
互联网产品通常会分为应用层和后端服务，后端服务又可以进一步细分为应用服务和基础服务。后端基础服务和一些公共应用服务相对稳定，而且对于系统全局来说是 “牵一发而动全身”，所以后端服务很有必要开展全面的单元测试；而对于变动非常频繁的客户端应用和非公用的后端应用服务，一般很少会去做单元测试。另外，对于一些核心算法和关键应用，比如银行网关接口，第三方支付集成接口等，也要做比较全面的单元测试。
总结来讲，互联网产品的全面单元测试只会应用在那些相对稳定和最核心的模块和服务上，而应用层或者上层业务服务很少会大规模开展单元测试。

第二层，API 测试，对于互联网产品来说，把测试重点放在 API 测试上，才是最明智的选择。原因如下：

1. API 测试用例的开发与调试效率比 GUI 测试要高得多，而且测试用例的代码实现比较规范，通常就是准备测试数据，发起 request，验证 response 这几个标准步骤。
2. API 测试用例的执行稳定性远远高于 GUI 测试。
3. 单个 API 测试用例的执行时间往往要比 GUI 测试短很多。当有大量 API 测试需要执行时，API 测试可以很方便地以并发的方式执行，所以可以在短时间内完成大批量 API 测试用例的执行。
4. 在微服务架构下，客户端应用的实现都是基于对后端微服务的调用，如果做好了每个后端服务的测试，你就会对应用的整体质量有充分的信心。所以，互联网产品的 API 测试非常重要。
5. API 接口的改动一般比较少，即使有改动，绝大多数情况下也需要保证后向兼容性（Backward Compatibility）。所谓后向兼容性，最基本的要求就是保证原本的 API 调用方式维持不变。 互联网产品的这些特性决定了，API 测试可以实现良好的投入产出比，因此应该成为互联网产品的测试重点。这也就是为什么互联网产品的测试策略更像是个菱形结构的原因。

第三层，GUI 测试，互联网产品的上线周期，决定了 GUI 测试不可能大范围开展：

1. 互联网产品的迭代周期，决定了留给开发 GUI 自动化测试用例的时间非常有限。
2. 互联网产品客户端界面的频繁变化，决定了开展 GUI 自动化测试的效率会非常低。 由此，互联网产品的 GUI 测试通常采用 “手工为主，自动化为辅” 的测试策略，手工测试往往利用探索性测试思想，针对新开发或者新修改的界面功能进行测试，而自动化测试的关注点主要放在相对稳定且核心业务的基本功能验证上。所以，GUI 的自动化测试往往只覆盖最核心且直接影响主营业务流程的 E2E 场景。

总结

传统软件通常采用金字塔模型的测试策略，而现今的互联网产品往往采用菱形模型。菱形模型有以下四个关键点：

1. 以中间层的 API 测试为重点做全面的测试。
2. 轻量级的 GUI 测试，只覆盖最核心直接影响主营业务流程的 E2E 场景。
3. 最上层的 GUI 测试通常利用探索式测试思维，以人工测试的方式发现尽可能多的潜在问题。
4. 单元测试采用 “分而治之” 的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试，而应用层或者上层业务只会做少量的单元测试。