提纲

分层测试的好处

为什么要做分层测试

从软件工程的角度，结合软件开发的V模型、MVC架构、测试金字塔，综合起来便于理解

从V模型的底部往右上方向，先做单元测试，再做集成测试一直到最后的验收测试。

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。

我们可以简单理解为V是用户看到的界面，C是中间逻辑，M是数据。对于现在流行的微服务SOA来说，V就是前端WEB或者APP, C就是中间密密麻麻的各种接口，M就是最下层的数据：

testing pyramid，类似于V模型，把测试行为从下往上分为单元测试、组件测试、集成测试、系统测试、手工测试。对于测试金字塔，越往下靠越容易自动化，越靠下成本越低，越靠下效率越高。

1.定位快：测出哪一层问题，很明确。此方法在处理线上问题则比较常用。

2.针对性强：在用例设计和测试执行时，更具有针对性，思维更清晰。

3.加强对代码实现逻辑的理解，拓展测试技能。

4.节约时间成本：1）分层测试是一个迭代的过程，测试可以提前介入，不用等到最后面才介入，缩短整体项目时长。2）提前暴露问题，缩短BUG查找时间和修复BUG的时间。

分层测试的测试方法还是原来的测试方法，但对测试人员的代码能力还有自动化测试水平有较高要求，同时要求测试人员和开发团队真正的理解敏捷开发和敏捷测试，甚至要求开发团队达到开发即测试、测试即开发的能力。

手工测试：需要测试界面、微服务的接口和数据库。

测试开发：还需要关注分层的自动化测试、单元测试、持续集成和持续发布。

在测试的时候，不仅要关注需求文档中的需求，还要考虑一些隐藏的需求，以及开发的实现，开发采用不同的实现方式，会产生不一样的测试点

要更多的站在用户的角度去考虑用户的使用场景，流程设计是否合理，交互是否顺畅，文字是否有歧义，提示是否明确而友好

开发采用了什么技术，什么框架，设计是否合理，是否高效，是否有扩展性，流程是否可控，是否考虑了异常情况，数据处理是否合理，是否存在性能问题，安全性有没有考虑等等

针对上面的分层结构，我们在设计测试用例的时候，需要考虑以下图所示的情况（粗略，还需要拓展）：

通常测试人员和开发打交道较多，那么分层测试可以是下图这种模式：

实施方法

单元测试由开发人员在代码实现完成后进行，QA主要进行接口和UI层的测试。
接口层测试：
1. 项目启动时，相关人员评估是否需要QA介入接口测试；交付节奏快、代码量很小的项目，可以直接从UI层验证，不需要QA人员进行接口测试；其他项目根据需要进行接口测试。
2. 根据开发计划，确定执行接口测试的时间。
3. 参与到接口评审，根据接口文档，确定被测接口。
4. 设计case、准备数据、执行测试。
5. 跟踪Bug。
UI层测试：前后端联调完毕后，进入接口层测试。UI层测试除了关注UI交互的问题，更重要的是站在用户的角度，从UI层完成端到端业务流程验证，易用性、稳定性等因素也是这个层面测试需要考虑的事情。
分层测试自动化：
1. 从接口层、UI层选择回归频率高的业务流程做自动化回归，降低回归测试成本。
2. 不是所有业务流程都适合做自动化测试，自动化用例维护也有成本，选择自动化目标时，应考虑选择不频繁变动的流程。
3. UI层的变动大，维护成本高，从自动化用例的比例来看，也应该遵循金字塔的结构，UI层应该是占比最少的，把更多的自动化回归放到接口层、单元测试层。