分层测试分了个寂寞？
分层测试这个风吹了好多年，不分层都不好意思说自己是专业测试。各互联网公司更是对此乐此不疲，测试架构、测试平台，搞了一套又一套，然而。。。
理想总是丰满，现实总是骨干，投入了大量的人力物力在单元测试和服务端测试，还是要投入大量的集成测试，才能守住最后一道防线。怎么落地变成了困扰测试人许久的问题？分层测试真的分了个寂寞？
什么是分层测试？
分层测试：就是不同的时间段，不同的团队或团队使用不同的测试用例对产品不同的关注点进行测试。一个系统/产品我们最先看到的是UI层，也就是外观或者说整体，这些是最上层，最上层依赖下面的服务层，也就是接口或者模块，最底层就是单元，这个单元是函数或者方法。按照这三层选择不同时间段，不同团队不同测试用例进行的测试就是分层测试。
单元(Unit )测试
单元测试是针对代码单元（通常是类/方法）的测试，单元测试的价值在于能提供最快的反馈，在开发过程中就可以对逻辑单元进行验证。
接口（Service/API）测试
接口测试是针对业务接口进行的测试，主要测试内部接口功能实现是否完整。如主要业务流是否能走通，异常处理是否正确，数据为空时校验等等。
接口测试的主要价值在于接口定义相对稳定，不像界面或底层代码会经常发生变化，所以接口测试比较容易编写，用例的维护成本也相对较低。在接口层面准备测试的性价比相对较高。
集成（UI）测试
集成测试从用户的角度验证产品功能的正确性，测的是端到端的流程，并且加入用户场景和数据，验证整个业务流。集成测试的业务价值最高，它验证的是一个完整的流程，但因为需要验证完整流程，在环境部署、准备用例及实施等方面成本较高，实施起来并不容易。
分层测试模型
测试冰淇淋模型
目前大多数的时间都在做UI方面的测试，包含UI页面元素+功能，测试的80%时间都用在UI测试上。而在单元测试和接口测试方面投入不足，也就导致测试的压力都放到UI测试阶段，一方面需要各方都提测之后才能进行，开始的时间晚，测试时间紧张；另一方面许多异常场景无法构造，测试不充分，造成漏测。但这也是我们大多数的团队采用的方式。
测试金字塔模型
Google的自动化分层投入占比是：单元测试（Unit）：占比70%；接口测试（Service/API）：占比20%；集成测试（UI）：占比10%；这是我们理想的测试模型。这种模型的好处不言而喻，但是由于该模型对开发人员的测试能力要求很高，所以在一些测试和开发完全分离的团队以及开发能力较弱的团队，这种模式往往难以推广。
因此在基于目前中台化盛行微服务架构下，又提出了一种 测试橄榄球模型：单元测试相对较少；测试的重心放在接口级的测试上，并且提倡高度自动化；UI级的测试可以较少。
目前大多数互联网项目都是用的微服务模型，服务之间沟通交流的方式大多数是通过各种接口，接口是微服务模型项目和产品的核心。增加接口测试的比例，测试左移，让测试能提早介入，发现问题；越往上，发现问题和解决问题的成本会越高。
买家秀发生了什么？
卖家秀和买家秀总是有出入，我们的设想是能用金字塔模型来实现分层测试，然而在实际项目运转过程中，deadline一来，开发急急忙忙的提测，测试火急火燎的测试，掐着时间点上线，还谈什么单元测试、接口测试、自动化测试。
听过最多的抱怨就是：道理我都懂，可是臣妾做不到啊！
于是金字塔模型就变成了冰淇淋模型。
可是这难道是分层测试的错吗？！
难道没有deadline的压力分层测试就可以做好？就可以保证0bug上线？
买家秀卖家秀的差距，在于自身，如果自己是模特身材，才可能逆转差距，自身的修炼：理念、体系、人才、自动化成熟度。
Do！How？
要摆脱冗余繁重的测试，提高测试的效率和质量，分层测试的优势还是很明显的：
- 降低成本：测试左移，尽早发现问题解决问题，降低开发和修改成本；
- 分层测试：在用例设计和执行测试的时候，更具有针对性，思维更加清晰，减少场景遗漏；
- 重点测试：不同阶段关注不同，分重点测试，层层防护，减少漏侧，提高质量；
- 业务及技能的提升：加强开发和测试对业务及代码理解，可以更好的进行技能拓展和延伸。
每个项目情况不一样，一招鲜显然是很难走到最后的，测试模型也只是模型，适用才是硬道理。单元测试、接口测试的覆盖率和门禁也要因时制宜，在实践的过程中不停地调整去适应项目的现状和发展，以更快更好地做交付。
在每个项目去实践探索的过程中，都会遇到这样那样的问题，唯有坚持与相信，才能走出一条康庄大道来！