一个字：快！
通常情况下，互联网产品要求全回归测试的执行时间不能超过 4 小时
如何在保证测试质量和测试覆盖率前提下，有效缩短测试执行时间呢？这就是今天的主题啦！
一般是白盒测试，由开发工程自己完成
主要针对的是各模块暴露的接口，通常采用 灰盒测试 方法。
灰盒测试：是介于白盒测试和黑盒测试之间的一种测试技术，其核心思想是利用测试执行的代码覆盖率来指导测试用例的设计。
以 API 接口测试为例，首先以黑盒方式设计如何调用 API 的测试用例，同时在测试执行过程中统计代码覆盖率，然后根据代码覆盖率情况来补充更多、更有针对性的测试用例。
最接近软件真实用户使用行为的测试类型。通常是模拟真实用户使用软件的行为，并验证这些操作对应的结果是否正确
优点：实际模拟真实用户的行为
缺点：执行代价比加大
重量级API测试，轻量级GUI测试，轻量级单元测试
以中间层的 API 测试为重点做全面的测试
轻量级的 GUI 测试，只覆盖最核心直接影响主营业务流程的 E2E 场景
最上层的 GUI 测试通常利用探索式测试思维，以人工测试的方式发现尽可能多的潜在问题
单元测试采用“分而治之”的思想，只对那些相对稳定并且核心的服务和模块开展全面的单元测试，而应用层或者上层业务只会做少量的单元测试
开发GUI自动化测试用例的时间非常有限
需求和客户端界面频繁的变化，导致GUI自动化测试效率会非常低
所以，互联网产品的GUI测试通常采用“手工为主，自动化为辅”的测试策略，手工测试往往利用探索性测试思维，针对新开发或者新修改的界面功能进行测试。
对于互联网产品来说，测试重点放在API测试才是最明智的选择，为啥呢？以下原因
API 测试用例的开发与调试效率比 GUI 测试要高得多，而且测试用例的代码实现比较规范，通常就是准备测试数据，发起 request，验证 response 这几个标准步骤。【开发调试效率高】
API 测试用例的执行稳定性远远高于 GUI 测试。 GUI 测试执行的稳定性始终是难题；API 测试天生就没有执行稳定性的问题，因为测试执行过程不依赖于任何界面上的操作，而是直接调用后端 API，且调用过程比较标准【稳定性高，独立性强，规范性好】
单个 API 测试用例的执行时间往往要比 GUI 测试短很多。当有大量 API 测试需要执行时，API 测试可以很方便地以并发的方式执行【执行时间短】
现在很多互联网产品采用了微服务架构，而对微服务的测试，本质上就是对不同的 Web Service 的测试，也就是 API 测试。【微服务测试即API测试】
API 接口的改动一般比较少，即使有改动，绝大多数情况下也需要保证后向兼容性（Backward Compatibility），即保证原本的 API 调用方式维持不变。【改动效，后向兼容】
互联网产品的全面单元测试只会应用在那些相对稳定和最核心的模块和服务上，而应用层或者上层业务服务很少会大规模开展单元测试。