多客户端UI自动化测试架构设计

对自动化测试接触不深的同学，往往会认为自动化测试只是简单的手工测试步骤的脚本翻译过程，其实不然，如果真这样操作，往往后期的维护成本会很高。在互联网，特别是移动互联网盛行的当下，一款受欢迎的产品，多半会部署Android，iOS，PC等多个版本的客户端。本文中根据一个真实的自动化测试项目的实现抽象出如下的测试架构图，以此解决自动化测试会遇到的以下几个难点问题：

1. 测试业务抽象：从业务测试需求描述（What，即做什么）的抽象层面讲，在多个客户端上是基本一致的，比如挖财这款记帐软件的绝大部分功能需求，在Android，iOS客户端上抽象出来是一致的，不同的无非是控件的布局，以及操作流程稍有差别。我们采用RobotFramework（以下简称RF）中文描述测试需求，然后在多个客户端上尽可能最大粒度的复用这份测试需求，这样在新的端接入的时候，只要实现下层的驱动层和测试逻辑层面即可。在敏捷测试领域中推崇的”活的文档“这一概念，大体上也是这个意思。

2. 多自动化测试框架的适配：现如今，对于Web端的自动化测试，Selenium基本上是一统天下的局面，但是对于Android和iOS移动端来讲，自动化测试框架呈现的基本是日新月异的现状，就Android来讲，现如今比较出名的有Robotium，UIAutomator，Appium等，新框架总有其更有优势的地方，在传统实现来讲，如果替换自动化测试框架，所消耗的成本和重新所有测试用例区别不大。从传统软件设计的理念上来讲，要尽可能减少软件本身对第三方库API的直接依赖，以避免库升级或变更导致API的变化所带来的产品代码变更。自动化测试对第三方测试框架的依赖也是同样道理，所以在第三方测试框架上层加了一层ExternalApiWrapper，以此屏蔽掉干扰。

3. 业务操作的多用途复用：举个简单的例子，拿登录这个功能的测试来讲，作为测试本体，会有常规的数据驱动测试；作为测试辅助体，它又是很多业务流程测试的准备条件，所以对于登录这个业务操作，要能满足一处实现，多处复用。同样我们还需要它来辅助进行基于模型的探索性测试，关于这点在下面来介绍。

4. 基于模型的探索性测试：传统自动化测试脚本在编写调试完成后，在很长的一段时间内执行的顺序都是固定不变的，能发现的bug大多在调试自动化脚本的开始阶段就已经被发现了，后期不断执行的过程中就少有bug发现了，我们称这类自动化脚本为静态自动化测试，这种自动化测试方式存在的最大问题，就是杀虫剂效应。这种类型的自动化测试偏向用于持续集成中保证产品功能没有被破坏的验证。在敏捷测试中，除了这类测试之外，一般也会引入手工的探索性测试，用于发现杀虫剂效应之外那些没有被发现的缺陷。如果利用自动化测试来尝试探索性测试这个领域，是自动化测试面临的一个挑战，也是展现其重要价值的一个突出的亮点。反思我们测试人员了解产品的过程就会发现，随着对产品的不断熟悉，业务的不断了解，慢慢地在我们的大脑中建立起了这个产品的业务模型，这个模型就是辅助我们做手工探索性测试的基础。如何将我们大脑中已存储的产品业务模型用测试代码来实现，是关键的难点。在实践过程中，我们将此类测试分成两类：单点功能利用有限状态机实现探索性测试（通过这种在状态节点间轮循的方式发现了一个经过四五十步发现的缺陷）；整体业务逻辑的模型探索性测试，这种探索性测试的难点是构建Activity/页面节点的路径图、节点之间步进方路径法实现，步进方式分为最短路径和多路径随机等多种方式。

在以后的博文中，会逐渐将整个测试架构中涉及的一些关键点的代码贴上来。