这是我购买的"极客时间"上的一套课程的笔记，总共52讲，定期对其中的内容做一笔记，巩固学习内容。
本文原创首发在我的个人博客，同步搬运到简书等平台。
11 互联网产品的测试策略应该如何设计？
互联网产品和传统软件产品的不同
互联网产品"快"，发布周期通常以"天"甚至是"小时"为单位。
传统软件产品"慢"，发布周期多以"月"甚至以"年"为单位。
由于发布周期的巨大差异，二者的测试策略必然在测试执行时间和测试执行环境上有巨大差异。
有效缩短测试执行时间的方法
- 引入测试的并发执行机制
- 从测试策略上找到突破口
传统软件产品的测试策略设计
|GUI Test|
/ API Test \
/ Unit Test \
简单图示一下，差不多是一个金字塔形，底部厚，越向上越小。
这个模型在很长一段时间内都被认为是测试策略设计的最佳实践。
- 单元测试
属于白盒测试。通常由开发工程师自己完成。传统软件产品生命周期较长，每次build过程中都会多次反复执行单元测试。 - API 测试
针对各模块暴露的接口，通常采用灰盒测试方法。灰盒测试的核心思想是利用测试执行的代码覆盖率来指导测试用例的设计。 - GUI 测试
也成为端到端（E2E）测试，通常是模拟真实用户使用软件的行为，即模拟用户在软件界面上的各种操作，并验证这些操作对应的结果是否正确。
优点是直接验证软件的商业价值；缺点是执行的代价比较大，就算采用GUI自动化测试技术，用例的维护和执行代价依然很大。所以要尽可能避免对GUI测试的过度依赖。
互联网产品的测试策略设计
遵循重量级API测试，轻量级GUI测试，轻量级单元测试的原则。
|GUI Test|
| API Test |
|Unit Test|
也来图示一下，是一个菱形，中间厚重，两头小。
一、GUI 测试
互联网产品的上线周期，决定了GUI测试不可能大范围开展。
- 互联网产品的迭代周期决定了留给开发GUI自动化测试用例的时间非常有限。
- 互联网产品客户端界面的频繁变化，决定了开展GUI自动化测试的效率会非常低。
因此GUI测试通常采用"手工为主，自动化为辅"的测试策略。手工测试则往往利用探索性测试思想，针对新开发或者新修改的界面功能进行测试，而自动化测试关注相对稳定且核心业务的基本功能验证。
二、API 测试
把重点放在API测试上的五条原因
- API 测试用例的开发与调试效率比GUI测试要高得多。
- API 测试用例的执行稳定性远远高于GUI测试。
- 单个API测试用例的执行时间往往要比GUI测试短很多。
- 目前很多互联网产品采用微服务架构。对微服务的测试，本质上就是对不同的Web Service的测试，也就是API测试。微服务架构下，客户端应用的实现都是基于对后端微服务的调用。
- API接口的改动一般比较少。即使改动，绝大多数情况下也需要保证向后兼容性。
因此，API测试可以实现良好的投入产出比。
三、单元测试
互联网产品的"快"，基本不会有时间去做全面的单元测试。
单元测试策略要采用"分而治之"的思想。
互联网产品通常会分为应用层和后端服务，后端服务可以进一步细分为应用服务和基础服务。
后端服务有必要展开全面的单元测试，而客户端应用和非公用的后端应用服务，一般很少去做单元测试。
总结起来，互联网产品的全面单元测试，只会应用在哪些相对稳定和最核心的模块和服务上。
总结菱形模型的关键点
- 以API测试为重点做全面的测试
- 轻量级GUI测试，只覆盖最核心直接影响主营业务流程的E2E场景
- 最上层GUI测试通常利用探索性测试思维
- 单元测试采用"分而治之"的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试
【心得】
综合自己的从业经历，以及同行小伙伴们的经验，不少公司可能连传统软件产品的那一套测试策略都没有采用，而是把重点放在了GUI手工测试上面。
所以也就总有人抱怨：测试人员技术能力不高，被开发鄙视，等等。通过作者这样一分析，可以结合自己所在公司产品的情况——是传统软件产品，还是互联网产品，而调整自己的测试策略，以小博大。
另外，关于API的部分作者提到了微服务架构。这点也是自己薄弱的地方，虽然有做API测试，却没有很好地了解这部分的知识。结合作者前面几讲说过的内容，测试一个产品就要了解他，看来需要去补补微服务相关的知识，帮助自己更好的做api测试，更好的去制定测试策略。
本文原创首发在我的个人博客https://mmcatt.github.io，同步搬运到简书等平台。
