APP 自动化测试详解（30天）

做过UI自动化测试同学，都会深深体会几个痛点：维护量大、适配量大、编写代码巨大等。基于这些问题，大家都会想到抽象封装通用常用方法，编过程序的同学都知道，如何提高编程速度，那就是有一套自己熟悉和好用的函数库，这样编程很大部分就如搭积木游戏，可以快速搭建程序。基于此我们设计了第一套封装结构模式，如下图所示：



从以上结构，不难发现应用基础库比较凌乱，没有分类。如果是自己写的还记得住，要是移交给别人，就显得很糟糕了，别人不愿意去看去用。那么，急需解决的问题就是如何分类比较合理。
从基于UI测试的测试对象出发，我们测试的对象为一个个的Activity，那我们可以使用Activity来进行分类。首先每个Activity 都有自己的专有方法，如拨号界面，会有输入号码、拨号、删除号码等功能，我们将每个Activity划分为一个单独的类，类里面把这个Activity 涉及的方法都写好提供给用例调用，如下图拨号界面的属性与功能的基础分解。



依据以上 Activity 封装模式，我们还需要在结构中再加入一层 Activity 函数库，那么，新的结构图如下所示：



这里涉及了几个Activity的查询方法。[LG1]


方法1：从开发那取得manifest文件

方法2：使用命令查询应用的全部Activity
adb shell dumpsys package <包名>

方法3：查询当前Activity 栈顶的Activity，推荐使用此方法
adb shell dumpsys activity
找到栈顶Activity

[LG1]这几个查询方法再做下比较吧？



方法4：找焦点Activity

adb shell dumpsys activity | find “mFocusedActivity”

简化搜索字符
adb shell dumpsys activity | find “mF”

以上方法，最快捷的是方法四可以马上知道当前的页面信息，最全面的是方法1与方法2，使用哪种方法需要依据实际使用情况进行选择。

之前我们介绍过，基于同种布局抽象出通用方法。我们将常用的通用方法，放在公共库中，将每个界面方法放于每个单独界面的类中。下面来看一下基本基本类图：



在各种方法都固化完后，编写用例就成了搭积木游戏，可以快速的搭建需要的用例。将用例的逻辑写在用例中，用例的数据分离出来全部写在对应的Activity 类中。这样平时主要维护已有的各个Activity内方法与数据。

最后再按照功能将用例结构抽象成为一个标准框架层理论，这样大家就更容易明白与理解了。



基于此框架，基本不变的层为：布局层、组件层、通用层。界面层会因为界面的变化而进行维护变化。设计时候尤其注意函数的通用性、函数的参数、各种重载函数，以及各种异常情况都需要重点考虑和规避。作为通用的方法，为了保证函数的调用不出问题，也是需要测试的，我们必须写一份用例来测试这些方法，模仿单元测试方式来检查这些通用方法的可用性、稳定性、可靠性，以此来保证在应用变化，Android版本变化时候能快速的发现哪些函数存在的不兼容现象，进行及时的修改，保证业务的正常进行。

界面层的所有方法都基于接口方式进行设计，实际的用例由这些接口方法组成。当版本变化的时候只需要重新实现接口重新变化一份，用例只需要变换一下实例化的类就可以完成切换用例。如此这样，用例的固定步骤也可以不用变化，仅仅变化每块积木里面的内容就可以。

以上内容总结为如下几点：

• 合理封装方法，优化工程架构
• 组件化
• 布局化
• 界面化
• 接口化