分层测试终究是大梦一场空？(2)，跳槽字节跳动-CSDN博客

本文链接：https://blog.csdn.net/2401_84264692/article/details/137726210

本文探讨了分层测试方法，如单元测试、接口测试和集成测试，以及它们在不同测试模型（如金字塔模型、橄榄球模型）中的应用。作者指出在实际项目中，由于时间和压力因素，往往倾向于UI测试，而忽视了其他层次的测试。同时，提供了关于软件测试学习资源的分享，以帮助测试工程师提升技能。

摘要由CSDN通过智能技术生成

分层测试：**就是不同的时间段，不同的团队或团队使用不同的测试用例对产品不同的关注点进行测试。**一个系统/产品我们最先看到的是UI层，也就是外观或者说整体，这些是最上层，最上层依赖下面的服务层，也就是接口或者模块，最底层就是单元，这个单元是函数或者方法。按照这三层选择不同时间段，不同团队不同测试用例进行的测试就是分层测试。

单元(Unit )测试

单元测试是针对代码单元（通常是类/方法）的测试，单元测试的价值在于能提供最快的反馈，在开发过程中就可以对逻辑单元进行验证。

接口（Service/API）测试

接口测试是针对业务接口进行的测试，主要测试内部接口功能实现是否完整。如主要业务流是否能走通，异常处理是否正确，数据为空时校验等等。

接口测试的主要价值在于接口定义相对稳定，不像界面或底层代码会经常发生变化，所以接口测试比较容易编写，用例的维护成本也相对较低。在接口层面准备测试的性价比相对较高。

集成（UI）测试

集成测试从用户的角度验证产品功能的正确性，测的是端到端的流程，并且加入用户场景和数据，验证整个业务流。集成测试的业务价值最高，它验证的是一个完整的流程，但因为需要验证完整流程，在环境部署、准备用例及实施等方面成本较高，实施起来并不容易。

分层测试模型

测试冰淇淋模型

目前大多数的时间都在做UI方面的测试，包含UI页面元素+功能，测试的80%时间都用在UI测试上。而在单元测试和接口测试方面投入不足，也就导致测试的压力都放到UI测试阶段，一方面需要各方都提测之后才能进行，开始的时间晚，测试时间紧张；另一方面许多异常场景无法构造，测试不充分，造成漏测。但这也是我们大多数的团队采用的方式。

测试金字塔模型

Google的自动化分层投入占比是：单元测试（Unit）：占比70%；接口测试（Service/API）：占比20%；集成测试（UI）：占比10%；这是我们理想的测试模型。这种模型的好处不言而喻，但是由于该模型对开发人员的测试能力要求很高，所以在一些测试和开发完全分离的团队以及开发能力较弱的团队，这种模式往往难以推广。