《软件测试52讲》读书笔记（十一） —— 互联网产品测试策略

互联网产品特点：快、迭代周期短

面对快速迭代的产品，应如何在保证测试质量和测试覆盖率的前提下缩短测试执行时间？

• 引入测试并发执行机制，用包含大量测试执行节点的测试集群（由一个主节点（Master）和若干个子节点（Node）组成）来并发执行测试用例
• 在测试策略上寻找突破点

传统软件产品的测试策略设计

单元测试（Unit Test）

特点：厚重

属于白盒测试，由开发工程师自行完成测试，越早发现缺陷修复成本越低，在后期版本升级时都需要反复执行单元测试

API测试（API Test）

属于灰盒测试，介于白盒测试与黑盒测试之间，核心思想：利用测试执行代码覆盖率指导测试用例设计，主要针对各个模块暴露的接口

API测试用例数量会少于单元测试，但多于GUI测试

GUI测试（GUI Test）

属于界面测试（E2E测试），最接近真实用户使用行为的测试，模拟用户在软件界面的各种操作，并验证操作结果是否正确

GUI测试用例维护成本和执行代价大，并且稳定性差，随机失败率高 —— 尽可能避免过度依赖

互联网产品测试策略设计

互联网产品测试策略遵循：重量级API测试，轻量级GUI测试，轻量级单元测试的原则

GUI测试（GUI Test）

采用“手工为主、自动化为辅”的测试策略，对于GUI测试往往只覆盖核心且直接影响主营业务流程的场景

• 手工测试结合探索性测试思想，针对新开发或者修改的界面功能进行测试
• 自动化测试关注点放在相对稳定且核心业务的基本功能验证上

API测试（API Test）

API测试可以更好实现良好的投入产出比

重API测试原因：

1. 测试用例的开发与调试率高于GUI测试
2. 测试用例执行稳定性高于GUI测试
3. 执行时间低于GUI测试
4. 目前互联网公司采用微服务框架。本质就是对不同的Web Service测试，也就是API测试
5. API接口改动少，且一般都是具有向后兼容性

单元测试（Unit Test）—— 从源头保证软件质量的重要手段

互联网产品产品的单元测试策略采用“分而治之”的思想

• 互联网产品分为：应用层和后端服务；后端服务分为：应用服务和基础服务

互联网产品全面单元测试只会应用在相对稳定和最核心的模块和服务上，而应用层或上层业务服务很少大规模开展单元测试