标签：客户端 质量 重要 pat 重用 功能 单元 图片 利用
推崇的是迈克的金字塔模型，重单元测试，API测试次之，轻GUI测试。
互联网产品的研发流程就一个字：“快”，发布周期的巨大差异决定了，传统软件产品的测试策略必然不适用于互联网产品的测试，二者的测试策略必然在测试执行时间和测试执行环境上有巨大差异。
互联网产品采用菱形的测试策略，遵循“重量级 API 测试，轻量级 GUI 测试，轻量级单元测试”的原则。
互联网产品的上线周期，决定了 GUI 测试不可能大范围开展。
互联网产品的 GUI 测试通常采用“手工为主，自动化为辅”的测试策略，手工测试往往利用探索性测试思想，针对新开发或者新修改的界面功能进行测试，而自动化测试的关注点主要放在相对稳定且核心业务的基本功能验证上。所以，GUI 的自动化测试往往只覆盖最核心且直接影响主营业务流程的 E2E 场景。
对于互联网产品来说，把测试重点放在 API 测试上，才是最明智的选择。
API 测试用例的开发与调试效率比 GUI 测试要高得多，而且测试用例的代码实现比较规范，通常就是准备测试数据，发起 request，验证 response 这几个标准步骤。
API 测试用例的执行稳定性远远高于 GUI 测试。 GUI 测试执行的稳定性始终是难题，即使你采用了很多技术手段，它也无法做到 100% 的稳定。
单个 API 测试用例的执行时间往往要比 GUI 测试短很多。当有大量 API 测试需要执行时，API 测试可以很方便地以并发的方式执行，所以可以在短时间内完成大批量 API 测试用例的执行。
现在很多互联网产品采用了微服务架构，而对微服务的测试，本质上就是对不同的 Web Service 的测试，也就是 API 测试。在微服务架构下，客户端应用的实现都是基于对后端微服务的调用，如果做好了每个后端服务的测试，你就会对应用的整体质量有充分的信心。所以，互联网产品的 API 测试非常重要。
API 接口的改动一般比较少，即使有改动，绝大多数情况下也需要保证后向兼容性（Backward Compatibility）。所谓后向兼容性，最基本的要求就是保证原本的 API 调用方式维持不变。显然，如果调用方式没有发生变化，那么原本的 API 测试用例也就不需要做大的改动，这样用例的可重用性就很高，进而可以保证较高的投入产出比（ROI）。
来源于：极客时间 茹炳晟 软件测试52讲
标签：客户端 质量 重要 pat 重用 功能 单元 图片 利用
原文地址：https://www.cnblogs.com/Uni-Hoang/p/13237702.html
