11.互联网产品的测试策略应该如何设计
- 传软件产品的测试策略设计
通常采用金字塔模型。
单元测试：
在金字塔最底部，属于白盒测试的范围，通常由开发工程师自己完成，由于越早发现缺陷其修复成本越低，所以传统软件产品的测试策略提倡对单元测试的高投入，单元测试这一层通常都会做得比较“厚”。
API测试：
在金字塔的中间部分，主要针对的是各模块暴露的接口，通常采用灰盒测试方法。
总体来看，API测试用例的数量会少于单元测试，但多余上层的GUI测试。
GUI测试：
在金字塔的上层，也称端到端（E2E，End-to-end）测试，是最接近真实用户使用行为的测试类型。通常是模拟真实用户使用软件的行为，即模拟用户在软件界面上的各种操作，并验证这些操作对应的结果是否正确。
优点：能够实际迷你真实用户的行为，直接验证软件的商业价值
缺点：执行的代价比较大
- 互联网产品的测试策略设计
对于互联网
产品来说，金字塔模型已经不再适用。
GUI测试：
互联网产品的上线周期，决定了GUI测试不可能大范围开展。
互联网产品的GUI测试通常采用“手工为主，自动化为辅”的测试策略，手工测试往往利用套索性的测试思想，针对新开发或者新修改的界面功能进行测试，而自动化测试的关注点主要放在相对稳定且核心业务的基本功能验证上。所以，GUI的自动化测试往往只覆盖最核心且直接影响主营业务流程的E2E场景。
从GUI测试用例的数量来看，传统软件的GUI测试属于重量级的，动不动就有上千万个用例，。而互联网产品要求GUI测试是轻量级的。
API测试：
在互联网产品上，把测试重点放在API测试上。原因如下：
- API测试用例的开发与调试效率比GUI测试要高得多。
- API测试用例的执行稳定性远远高于GUI测试。GUI测试执行即使你采用了很多技术手段，也无法做到100%的稳定。而API测试在测试执行过程中不依赖任何界面上的操作，而是直接调用后端API，且调用过程标准。
- 单个API测试用例的执行时间往往要比GUI测试要短很多。
- 现在很多互联网产品采用了微服务架构，而对微服务的测试，本质上就是对不同的Web Service的测试，也就是API测试。
- API接口的改动一般比较少，即使有改动，，绝大数情况下也需要保证后向兼容性，所谓后向兼容性，最基本的要求就是保证原本的API调用方式维持不变。
- 单元测试
轻量级单元测试。
在互联网这个快的模式下，基本不会有时间去做全面的单元测试，所以安远测试很难再实际操作层面得到体现。
所以互联网的单元测试要采用“分而治之”的思想，
互联网产品通常会分为应用层和后端服务，后端服务又进一步分为应用服务和基础服务。
后端基础服务和一些公共应用服务相对稳定，而且对于系统全局来说是“牵一发而动全身”，所以后端服务很有必要开展全面的单元测试，而对于变动非常频繁的客户端应用和非公用的后端应用服务，一般很少去做单元测试。
对于一些核心算法和关键应用，比如银行网关接口，第三方支付继承接口等，也要做比较全面的单元测试。
互联网产品的全面测试只会应用在那些相对稳定和最核心的模块和服务上，而应用层或者上层业务服务很少会大规模开展单元测试。