为什么要做分层测试
从软件工程的角度，结合软件开发的V模型、MVC架构、测试金字塔，综合起来便于理解。
1.借鉴与软件开发的V模型
从V模型的底部往右上方向，先做单元测试，再做集成测试一直到最后的验收测试。
2.来源于MVC架构
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。
我们可以简单理解为V是用户看到的界面，C是中间逻辑，M是数据。对于现在流行的微服务SOA来说，V就是前端WEB或者APP, C就是中间密密麻麻的各种接口，M就是最下层的数据：
3.来源于测试金子塔
testing pyramid，类似于V模型，把测试行为从下往上分为单元测试、组件测试、集成测试、系统测试、手工测试。对于测试金字塔，越往下靠越容易自动化，越靠下成本越低，越靠下效率越高。
分层测试的好处
1.定位快：测出哪一层问题，很明确。此方法在处理线上问题则比较常用。
2.针对性强：在用例设计和测试执行时，更具有针对性，思维更清晰。
3.加强对代码实现逻辑的理解，拓展测试技能。
4.节约时间成本：1）分层测试是一个迭代的过程，测试可以提前介入，不用等到最后面才介入，缩短整体项目时长。2）提前暴露问题，缩短BUG查找时间和修复BUG的时间。
怎么做分层测试
手工测试：需要测试界面、微服务的接口和数据库。
测试开发：还需要关注分层的自动化测试、单元测试、持续集成和持续发布。
在测试的时候，不仅要关注需求文档中的需求，还要考虑一些隐藏的需求，以及开发的实现，开发采用不同的实现方式，会产生不一样的测试点。
要更多的站在用户的角度去考虑用户的使用场景，流程设计是否合理，交互是否顺畅，文字是否有歧义，提示是否明确而友好。
开发采用了什么技术，什么框架，设计是否合理，是否高效，是否有扩展性，流程是否可控，是否考虑了异常情况，数据处理是否合理，是否存在性能问题，安全性有没有考虑等等。
针对上面的分层结构，我们在设计测试用例的时候，需要考虑以下图所示的情况（粗略，还需要拓展）：
通常测试人员和开发打交道较多，那么分层测试可以是下图这种模式：
实施方法
单元测试由开发人员在代码实现完成后进行，QA主要进行接口和UI层的测试。
接口层测试：
项目启动时，相关人员评估是否需要QA介入接口测试；交付节奏快、代码量很小的项目，可以直接从UI层验证，不需要QA人员进行接口测试；其他项目根据需要进行接口测试。
根据开发计划，确定执行接口测试的时间。
参与到接口评审，根据接口文档，确定被测接口。
设计case、准备数据、执行测试。
跟踪Bug。
UI层测试：前后端联调完毕后，进入接口层测试。UI层测试除了关注UI交互的问题，更重要的是站在用户的角度，从UI层完成端到端业务流程验证，易用性、稳定性等因素也是这个层面测试需要考虑的事情。
分层测试自动化：
从接口层、UI层选择回归频率高的业务流程做自动化回归，降低回归测试成本。
不是所有业务流程都适合做自动化测试，自动化用例维护也有成本，选择自动化目标时，应考虑选择不频繁变动的流程。
UI层的变动大，维护成本高，从自动化用例的比例来看，也应该遵循金字塔的结构，UI层应该是占比最少的，把更多的自动化回归放到接口层、单元测试层。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
