Android手机QQ的UI自动化实践，音视频服务器开发难点

---

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

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

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

我们的痛点是，需要快速铺量，那按照用例场景，所见即所得的代码方式，的确是很快，但是我们需要对该模式规范化。结合测试用例的3A原则（Arrange、Act、Assert）,我们创造了一种新的封装模式QTS（QQ Testcase Service）。

自动化框架QTS

---

我们在写测试用例的时候，是按照用户角度，从一个个控件元素触发，经过一个个场景页面，最终验证某一个结果。那为什么不直接把上面的元素触发（Action）、场景页面（View）、验证（Check or Assert）自动化呢？这样就可以快速实现任意一个用例了，因为自动化代码和测试用例的文字描述是一一对应的。

QTS是Scene模式的进一步改进。我们抽象出测试用例的3A，抽象出控件动作（Action）、页面元素（View）、断言（Check）这三个最基本接口，同时因地制宜，结合手Q复杂的环境，又抽象出场景流（Workflow）、环境（Env）接口。

TestBase是全部测试用例类的基类，包含了测试用例的一些通用属性和方法。它的属性包括单例模式的action，env，check，qqAcount等，方法包括登录QQ，初始化手Q环境等。所有的测试用例类都继承这个类。