UI自动化框架分层

小文0111

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

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

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

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

--pinch

-截图

-元素等待

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

2.应用功能层：

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

好处：

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

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

 3. 页面元素目录

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

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

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

4.用例层

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

    用例层大量调用Common功能层和业务功能层的方法， 选择元素，操作元素， 为用例添加断言。 

5.全局变量目录

      存放诸如：屏幕尺寸，等待时长，桩信息，用户登录信息，被测试的APK包名，启动activity等。

6. 日志目录

7.截图目录

8.报告目录

9.apk目录，存放被测apk和测试中所需要的其它apk。

 

另：上面存在多个目录（有的是包），目录下还会有子目录， 在模块中导入其它模块/包时，按照什么原则来导入？ 

我的经验，将项目所在目录设置为PYTHONPATH, 涉及到导入时，皆此目录为基准，

1. hiApp(项目名称)
   
2. --Common
   
3.     CommonFun.py
   
4. --testcases
   
5.     --子目录
   
6.         --xx.py

复制代码

假设在xx.py里要导入CommonFun.py，在xx.py里这么写

from Common.CommonFun import xx

Miss_love

支持分享