在理解分层自动化之前，我们先看自动化测试金字塔。自动化测试金字塔在测试领域耳熟能详，其中UI代表页面级系统测试，service代表服务业务测试（接口测试），unit代表单元测试。金字塔越高，表示需要投入的精力和工作量越大。
单元测试（unit）：它可以通过mock框架，模拟各种异常场景，外部依赖最少，且可以做到测试粒度到最小的一种测试方法。也因为依赖少，可方便随时随地执行，也让问题排查很简单。这是一切测试的地基。
接口测试（service）：这里要求测试人员对系统的结构和系统间的调度非常清楚，同时要了解接口逻辑关系，否则接口测试代码很容易遗漏一些异常场景。这一层由于含有一些业务逻辑和多接口的一个集成，所以相对单元测试来说，多了一些外界依赖，导致问题定位不会有单元测试层那么准确。因此投入会比单元测试多一些。
页面测试（UI）：是常见的黑盒自动化测试场景。它最接近用户真实场景，也容易发现问题，但它的实现成本最高且太容易受外部依赖，影响脚本成功率，所以处在金字塔的顶端，但它不是金字塔的全部。
以上就是分层自动化的主体三层，由此可见，分层自动化测试倡导的就是，将系统分层，不同层次用合适的自动化方法进行测试的一种测试策略。某个项目是否都能用自动化覆盖，那就要看测试负责人的分层策略是否合理、全面。
下面来聊一聊我在项目中的问题和想法：
单元测试：
目前我们的项目unit test主要还是开发人员自己来编写的，这一层发现并解决问题付出的成本相对来说最低，自动化用例的维护成本也不高，总的来说自动化测试的投入产出比最高。所以，开发人员如何在开发工程中能够写好单元测试用例就很关键。（但是，这里有但是，在项目进度的面前，妥协也是没办法的事情 -- 这话就来源于我边上的RD）。所以我们测试工作者如何能弥补这个状况也是我们一直在考虑的，比如如何能评估本项目的unit test覆盖率，如何提高能力可以进行单元测试的编写和校验。接口测试：
接口测试相对于单元测试更偏重于业务，测试人员在了解接口工作方法的同时也要了解各接口之间的业务联系。在开发用例的时候，要考虑到同一业务中的各种情况，如输入参数格式不正确等，又会衍生出同一业务下不同的测试用例。
接口测试如果覆盖面足够多的话，服务端基本的业务功能和流程基本上是可以保证的。它的更重要的目的其实是接口功能的回归，如果UI端没有任何变化的话，可以省去几乎100%的回归测试时间。页面测试：
被誉为最接近用户的测试，可见它的重要性。但是它也是最难实现自动化的，因为它涉及到了几乎所有的用户体验相关的情况。目前没有任何一个工具可以说在UI自动化里面是全能。但是毋庸置疑的是，UI自动化还是非常有用的，只要是有重复的工作，如我们现在的基本流程测试和埋点测试。
在做UI自动化时可以遵循如下两点：
能在底层做自动化覆盖，就尽量不在UI层做自动化覆盖
只做最核心的功能的自动化覆盖，脚本可维护性尽可能提高
