UI自动化框架分层
项目以前的UI自动化大概是这样分层的1.Common功能层：一些经常被调用的基本常用操作，用来完成某项具体的功能，与具体的业务无关。比如常用的封装：
--将元素定位方法重新封装
--封装上下左右滑动 eg: swipe(direct='down',count=1)
--pinch
-截图
-元素等待
有效的封装，能减少代码量，提供用例写作效率，减少维护成本。
2.应用功能层：
与业务有关，调用基础控件操作实现特定的功能，比如被很多页面共享的公共组件，如导航栏。 经常要执行的操作， 如登录。
好处：
这些功能会被多次调用，实现复用提供效率。
当功能实现发生变化时，只需要修改这个方法就可以了。 比如，登录在用例中被多次调用，版本升级后，登录的步骤发生了改变，我们只需要修改登录这个方法，用例不需要做任何改变。
3. 页面元素目录
自动化测试很大一部分工作就是页面元素的维护。为每一个页面或是activity创建一个模块，每一个模块里有其同名类，类中存放元素的信息。将多页面共享的组件抽出来，单独创建一个类。
这么操作的好处是，如果页面元素发生了变化， 一是能快速的找到并修改。 二是，只需要修改这一个地方就可以了。 如果按照网上那些例子，元素的信息都是写在代码里，简直灾难，日后如何维护。
PS：按照PO模式，类里还应该有这个页面的类方法。但是由于我们的APP的特殊性，单独属于某个页面的方法并不多，所以我们将方法集中到一个文件到了应用功能层中了。
4.用例层
按照需要划分子目录， 包含所有的用例。
用例层大量调用Common功能层和业务功能层的方法， 选择元素，操作元素， 为用例添加断言。
5.全局变量目录
存放诸如：屏幕尺寸，等待时长，桩信息，用户登录信息，被测试的APK包名，启动activity等。
6. 日志目录
7.截图目录
8.报告目录
9.apk目录，存放被测apk和测试中所需要的其它apk。
另：上面存在多个目录（有的是包），目录下还会有子目录， 在模块中导入其它模块/包时，按照什么原则来导入？
我的经验，将项目所在目录设置为PYTHONPATH, 涉及到导入时，皆此目录为基准，
hiApp(项目名称)
--Common
CommonFun.py
--testcases
--子目录
--xx.py
假设在xx.py里要导入CommonFun.py，在xx.py里这么写
from Common.CommonFun import xx 支持分享
页:
[1]
