离线下载
PDF版 ePub版

极客学院团队出品 · 更新于 2017-09-25 14:00:37

UI自动化测试基于Activity的封装模式

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

从以上结构,不难发现应用基础库比较凌乱,没有分类。如果是自己写的还记得住,要是移交给别人,就显得很糟糕了,别人不愿意去看去用。那么,急需解决的问题就是如何分类比较合理。

从基于UI测试的测试对象出发,我们测试的对象为一个个的Activity,那我们可以使用Activity来进行分类。首先每个Activity 都有自己的专有方法,如拨号界面,会有输入号码、拨号、删除号码等功能,我们将每个Activity划分为一个单独的类,类里面把这个Activity 涉及的方法都写好提供给用例调用,如下图拨号界面的属性与功能的基础分解。

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

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

  • 方法1:从开发那取得manifest文件
  • 方法2:使用命令查询应用的全部Activity
    adb shell dumpsys package <包名>
  • 方法3:查询当前Activity 栈顶的Activity,推荐使用此方法
adb shell dumpsys activity 

找到栈顶Activity

  • 方法4:找焦点Activity
adb shell dumpsys activity | find “mFocusedActivity”

简化搜索字符

adb shell dumpsys activity | find “mF”

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

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

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

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

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

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

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

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

更多 APP 测试解答及职业规划问题,请扫描下面二维码加群:(行内10年大牛定时指导)