Android手机QQ的UI自动化实践，为什么spring能最好地改变Android

---

按照部门的要求，我们本次的自动化需要用到同源（同语言同工程）的形式，而且针对手Q很多复杂的场景，我们需要稳定复现，所以我们排除了QTA、Appium、AirTest等框架，最终选择了UiAutomator。

UiAutomator是Google官方提供的同源测试框架，它的底层使用了Android的系统级服务AccessibilityService，关于这一块的介绍，可以看文章：《从Android手机的抢红包插件说起 》

官方文档传送门：UI Automator | Android Developers。

封装模式

---

在上一步环节中，我们虽然确定了自动化框架，但是框架只提供底层的驱动能力，如果无统一封装模式进行规范，随着用例的增多会变得难以维护，所以我们需要一个统一模式来封装细节，可以使 testcase 更稳健，不需要大改动。即我们需要对UiAutomator API进行二次封装。

业界最常见的一种封装模式是Page Object模式，“页面即对象”。这种封装模式把一个页面看做一个对象，把页面上的控件（按钮、图片等）元素当做对象的属性，把对页面上的控件操作（如点击某按钮）当做对象的方法。这种封装模式的优势是维护简单，对于页面的某些改动，只需要维护该页面对应的对象。劣势是代码复用率较低，不利于大规模铺量。

还有一种常见的封装模式是Scene模式，“场景化封装”。这种封装模式就是按照用例的场景，也不需要API的二次封装，简单粗暴去实现。这种封装模式的优势是简单粗暴，可读性高。劣势是代码复用率低，十分冗长。

我们的痛点是，需要快速铺量，那按照用例场景，所见即所得的代码方式，的确是