如果直接回答互联网产品和传统软件产品的测试策略有何不同，你会有些摸不着头脑，那么按照我一直在强调的知其然知其所以然的原则，你可以先去总结这两类产品的研发本身最大的不同是什么？
金字塔最底部是单元测试，属于白盒测试的范畴，通常由开发工程师自己完成，由于越早发现缺陷其修复成本越低，所以传统软件产品的测试策略提倡对单元测试的高投入，单元测试这一层通常都会做得比较“厚”。另外，传统软件产品，生命周期都比较长，通常会有多个版本持续发布，为了在后期的版本升级过程中能够尽早发现并快速定位问题，每次build过程中都会多次反复执行单元测试，这也从另一个角度反映出单元测试的重要性。
金字塔中间部分是API测试，主要针对的是各模块暴露的接口，通常采用灰盒测试方法。灰盒测试方法是介于白盒测试和黑盒测试之间的一种测试技术，其核心思想是利用测试执行的代码覆盖率来指导测试用例的设计。以API接口测试为例，首先以黑盒方式设计如何调用API的测试用例，同时在测试执行过程中统计代码覆盖率，然后根据代码覆盖率情况来补充更多、更有针对性的测试用例。总体来看，API测试用例的数量会少于单元测试，但多于上层的GUI测试。
金字塔最上层的是GUI测试，也称为端到端（E2E，End-to-end）测试，是最接近软件真实用户使用行为的测试类型。通常是模拟真实用户使用软件的行为，即模拟用户在软件界面上的各种操作，并验证这些操作对应的结果是否正确。GUI测试的优点是，能够实际模拟真实用户的行为，直接验证软件的商业价值；缺点是执行的代价比较大，就算是采用GUI自动化测试技术，用例的维护和执行代价依然很大。所以，要尽可能地避免对GUI测试的过度依赖。另外，GUI测试的稳定性问题，是长期以来阻碍GUI测试发展的重要原因。即使你采用了很多诸如retry机制以及异常场景恢复机制等方式，GUI测试的随机失败率依旧高居不下
对于互联网产品来说，迈克的金字塔模型已经不再适用，我会通过GUI测试、API测试、单元测试这三个方面，来跟你聊聊互联网产品的测试策略有哪些变化，应该如何设计。
而互联网产品要求GUI测试是轻量级的，你见过或者听过有哪个互联网产品设计了上千个GUI测试用例吗？互联网产品的上线周期，直接决定了不允许你去执行大量的用例。
你现在可能要问，既然互联网产品不适宜做重量级的GUI测试，那么怎样才能保证其质量呢？其实，对于互联网产品来说，把测试重点放在API测试上，才是最明智的选择。为什么呢？我给你总结了以下五条原因。
从理论上讲，无论是传统软件产品还是互联网产品，单元测试都是从源头保证软件质量的重要手段，因此都非常重要。但现实是，互联网产品真正能全面开展单元测试，并严格控制代码覆盖率的企业还是凤毛麟角但凡存在的都会有其合理性，我认为最主要的原因还是在于互联网产品的“快”，快速实现功能，快速寻求用户反馈，快速试错，快速迭代更新。