UI自动化框架分层

项目以前的UI自动化大概是这样分层的

1.Common功能层：一些经常被调用的基本常用操作，用来完成某项具体的功能，与具体的业务无关。比如常用的封装：

 --将元素定位方法重新封装

--封装上下左右滑动 eg: swipe(direct='down',count=1)

--pinch

-截图

-元素等待

有效的封装，能减少代码量，提供用例写作效率，减少维护成本。 

2.应用功能层：

       与业务有关，调用基础控件操作实现特定的功能，比如被很多页面共享的公共组件，如导航栏。 经常要执行的操作， 如登录。

好处：

        这些功能会被多次调用，实现复用提供效率。 

       当功能实现发生变化时，只需要修改这个方法就可以了。 比如，登录在用例中被多次调用，版本升级后，登录的步骤发生了改变，我们只需要修改登录这个方法，用例不需要做任何改变。 

 3. 页面元素目录

     自动化测试很大一部分工作就是页面元素的维护。为每一个页面或是activity创建一个模块，每一个模块里有其同名类，类中存放元素的信息。将多页面共享的组件抽出来，单独创建一个类。　

     这么操作的好处是，如果页面元素发生了变化， 一是能快速的找到并修改。 二是，只需要修改这一个地方就可以了。 如果按照网上那些例子，元素的信息都是写在代码里，简直灾难，日后如何维护。

     PS：按照PO模式，类里还应该有这个页面的类方法。但是由于我们的APP的特殊性，单独属于某个页面的方法并不多，所以我们将方法集中到一个文件到了应用功能层中了。 

4.用例层

    按照需要划分子目录， 包含所有的用例。

<