分层自动化

在理解分层自动化之前，我们先看一下经典的测试金字塔。

• UI层：界面自动化测试。可以看出它的价值最小，它最接近用户真实场景，也容易发现问题，但它的实现成本最高且太容易受外部依赖，容易影响脚本成功率。总体来说，适当的界面自动化测试是有必要的，但是没有必要在UI层投入太多；

• Service层：接口自动化测试。它的价值居中，覆盖大多数主要的接口是比较合适的。这一层要求测试人员对系统的结构和系统间的调度非常清楚，同时要了解接口逻辑关系，否则接口测试代码很容易遗漏一些异常场景；

• Unit层：单元测试。最有价值的测试，但是对测试人员要求比较高，一般由开发人员完成，否则只能采用结对编程。 通常来说，手工测试是最基本的,能覆盖绝大部分需求和场景，而对于自动化测试来说，它更像是一件"防弹衣"，用来防护身体的主要部位。有人认为自动化率提高了，就可以节省人力，这实际是非常片面的，因为提高自动化率，意味着需要投入更大的人力在维护的成本上。因为系统的需求是在不断变化的，每一个变化都会导致自动化测试用例需要更新调整。

所以，自动化测试做到什么样才算好，也要结合上面的测试金字塔来分析。对于UI层面的自动化测试，保证少量必要的主流程即可，切勿在这一层面将自动化测试的"防弹衣"变成臃肿的"宇航服"；Service层面的接口自动化测试，可以考虑覆盖大部分的流程；Unit层面的单测，做到100%是最好的，即使有需求变化，一般也很少影响到已有的用例。

实际自动化测试框架中一般定义分层层次为4-6层较为合适；可以根据自身的思想进行封装设计；

a.元素处理层：（PO模式：Page Object表示IDE是页面对象管理；表示的是意思：将每个页面上的所有元素定义在一个模块中）----->对后期前端页面进行修改，后期脚本进行维护十分方便（定位明确）

b.业务操作层：表示的是基于页面元素处理层实现业务流的自由组织；（实际对应自动化的业务流场景的测试用例执行）

c.测试用例层：根据业务流场景进行设计相应的测试用例并执行；用例的执行都是通过框架完成（单元测试框架：unittest、pytest），并且可以很好的自由组织测试用例最好执行产生结果并分析

另可以根据实际需要定义如下集合：

d.数据分离层：将脚本中的所有数据全部提取出来进行专门的数据模块管理，后期可直接修改相应数据即可；不需要进行底层的代码查看分析；

e.公共层：常量数据的存储、报告的生成、日志的保存、邮件的发送等