互联网产品的测试策略应该如何设计？
文章内容来源于《软件测试52讲》
先思考一下互联网产品的测试策略和传统软件产品的测试策略到底有哪些不同？
答：研发流程的不同决定了测试策略的不同（源于互联网产品的“快”。）
但对互联网产品来说，通常 24 小时就会有一到两次的发布，发布流程通常包含了代码静态扫描、单元测试、编译、打包、上传、下载、部署和测试的全流程。显然留给测试执行的时间就非常有限，传统软件动辄十几个小时的测试执行时间，在互联网产品的测试上，根本行不通。
通常情况下，互联网产品要求全回归测试的执行时间不能超过 4 小时。
如何在保证测试质量和测试覆盖率的前提下，有效缩短测试执行时间呢？
- 引入测试的并发执行机制
用包含大量测试执行节点的测试执行集群来并发执行测试用例
测试执行集群，可以简单理解为是一批专门用来并发执行测试用例的机器。
常见的测试执行集群，由一个主节点（Master）和若干个子节点（Node）组成。其中，主节点用来分发测试用例到各个子节点，而各个子节点用来具体执行测试用例。
- 从测试策略上找到突破口
菱形测试策略：重量级 API 测试，轻量级 GUI 测试，轻量级单元测试
互联网产品的菱形测试策略.png
关键点：
- 以中间层的 API 测试为重点做全面的测试。
- 轻量级的 GUI 测试，只覆盖最核心直接影响主营业务流程的 E2E 场景。
- 最上层的 GUI 测试通常利用探索式测试思维，以人工测试的方式发现尽可能多的潜在问题。
- 单元测试采用“分而治之”的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试，而应用层或者上层业务只会做少量的单元测试。
一、GUI测试
互联网产品的上线周期，决定了 GUI 测试不可能大范围开展。
- 互联网产品的迭代周期，决定了留给开发 GUI 自动化测试用例的时间非常有限；
- 互联网产品客户端界面的频繁变化，决定了开展 GUI 自动化测试的效率会非常低，这也是最糟糕的。
因为敏捷模式下的快速反馈，在下一个迭代（sprint）可能就需要根据反馈来做修改和调整客户端界面，那么刚开发完，甚至是还没开发完的 GUI 自动化测试用例就要跟着一起修改。
这种频繁地修改，对开发 GUI 自动化测试是非常不利的。因为，刚开发完的自动化用例只跑了一次，甚至是一次还没来得及跑就需要更新了，导致 GUI 自动化测试还不如手工测试的效率高。
互联网产品的 GUI 测试通常采用“手工为主，自动化为辅”的测试策略
手工测试往往利用探索性测试思想，针对新开发或者新修改的界面功能进行测试，而自动化测试的关注点主要放在相对稳定且核心业务的基本功能验证上。
所以，GUI 的自动化测试往往只覆盖最核心且直接影响主营业务流程的 E2E 场景。
互联网产品要求 GUI 测试是轻量级的，你见过或者听过有哪个互联网产品设计了上千个 GUI 测试用例吗？互联网产品的上线周期，直接决定了不允许你去执行大量的用例。
二、API测试（互联网产品的测试重点）
-
API 测试用例的开发与调试效率比 GUI 测试要高得多
测试用例的代码实现比较规范，通常就是准备测试数据，发起 request，验证 response 这几个标准步骤。 -
API 测试用例的执行稳定性远远高于 GUI 测试
GUI 测试执行的稳定性始终是难题，即使你采用了很多技术手段，它也无法做到 100% 的稳定。
而 API 测试天生就没有执行稳定性的问题，因为测试执行过程不依赖于任何界面上的操作，而是直接调用后端 API，且调用过程比较标准。 -
单个 API 测试用例的执行时间往往要比 GUI 测试短很多
当有大量 API 测试需要执行时，API 测试可以很方便地以并发的方式执行，所以可以在短时间内完成大批量 API 测试用例的执行。 -
现在很多互联网产品采用了微服务架构
对微服务的测试，本质上就是对不同的 Web Service 的测试，也就是 API 测试。
在微服务架构下，客户端应用的实现都是基于对后端微服务的调用，如果做好了每个后端服务的测试，你就会对应用的整体质量有充分的信心。所以，互联网产品的 API 测试非常重要。 -
API 接口的改动一般比较少
即使有改动，绝大多数情况下也需要保证后向兼容性（Backward Compatibility）。
所谓后向兼容性，最基本的要求就是保证原本的 API 调用方式维持不变。
显然，如果调用方式没有发生变化，那么原本的 API 测试用例也就不需要做大的改动，这样用例的可重用性就很高，进而可以保证较高的投入产出比（ROI）。
三、单元测试
互联网产品的“快”，快速实现功能，快速寻求用户反馈，快速试错，快速迭代更新。
在这样的模式下，互联网产品追求的是最快速的功能实现并上线，基本不会给你时间去做全面的单元测试。
即使预留了单元测试的时间，频繁的迭代也会让单元测试处于不断重写的状态。因此，单元测试原本的价值，很难在实际操作层面得到体现。
互联网产品通常会分为应用层和后端服务，后端服务又可以进一步细分为应用服务和基础服务。
后端基础服务和一些公共应用服务相对稳定，而且对于系统全局来说是“牵一发而动全身”，所以后端服务很有必要开展全面的单元测试；而对于变动非常频繁的客户端应用和非公用的后端应用服务，一般很少会去做单元测试。
另外，对于一些核心算法和关键应用，比如银行网关接口，第三方支付集成接口等，也要做比较全面的单元测试。
总结来讲，互联网产品的全面单元测试只会应用在那些相对稳定和最核心的模块和服务上，而应用层或者上层业务服务很少会大规模开展单元测试。
