分层测试的概念已经提出来多年了，至今已经不再新鲜，不过最近却发现分层测试的模型有了一些演进，在这里给大家分享一下。

三种模型

分层测试把测试分层了3个层次，从下往上分别是: 单元测试，服务级的测试以及ui测试。

上图展示了3种不同的测试成熟度模型，分别是

• 测试冰淇淋模型
• 测试金字塔模型
• 测试橄榄球模型

测试冰淇淋模型

这种模型的特点如下

• 单元测试很少
• 有一定的服务级的接口测试
• 测试的重点放在通过ui去测试系统的功能上

由于单元测试和接口测试有限，在这种模型下，持续集成的实现难度很高。

质量的重心放在ui上，就意味着系统必须充分开发完成并且正确部署之后才能进行测试，测试的开始时间相对就会较晚，面临着测试时间不充分的风险。

自动化测试率有限，测试周期相对可能较长。

ui测试较多，一些代码级的异常在ui测试时相对难以构造，有较高的测试不充分的风险。

单元测试少就意味着代码改动的影响很难第一时间得到发现和评估，有可能出现改1个bug送几个bug的情况。

大多数团队可能都符合这个模型。

测试金字塔模型

对于单体应用来讲，测试金字塔模型是一个比较理想的模型，特点如下

• 单元测试非常多
• 接口级的测试相对少一点点
• ui级的测试最少，通常只是用户验证性的测试，可以用自动化测试去做

这种模型的好处不言而喻，不过由于该模型对开发人员的测试能力要求很高，而且质量控制基本成为开发的本职工作，所以在一些测试和开发完全分离的团队以及开发技能一般的团队，这种模式往往难以推广。不过一些著名的开源项目基本上都符合这个模型。

测试橄榄球模型

• 单元测试相对较少
• 测试的重心放在接口级的测试上，并且提倡高度自动化
• ui级的测试可以较少

对于微服务模型的项目来说，服务之间沟通交流的方式一定是各种接口，所以接口是微服务模型项目和产品的核心。橄榄球模型正是抓住了这个重点，把测试的重心放在接口上。

由于单元测试用例的开发需要额外的知识及技能，加上大家对单元测试的重要性理解也不太一致，所以这个模型弱化了单元测试的作用。

ui测试由于开始的时间较晚以及实现和执行成本较高，所以这里也相对弱化。

对于测试同学来说，橄榄球模型里我们可以承担大部分接口层的用例编写以及依赖服务接口的mock工作。

另外微服务间的协作与信息对称对质量保障来说也是挑战，测试同学可以重点关注一下。

最后，我说的基本上都是错的。每个团队有不同的质量要求和实践，没有标准，只有参考。