在应用质量保障体系里, 自动化测试框架是不可缺少的基石, 合适的框架能大大提高测试效率与覆盖率, 这篇文章会系统地解析生态中几个主流、成熟的开源自动化测试框架, 还探讨搭配使用的方法, 给开发与测试人员提供选型上的参考建议。
一、 我们将主流开源框架进行了横向对比, 并且分析了它们的核心定位。真正的跨平台移动自动化测试解决方案支持iOS和应用, 覆盖了原生、混合与应用移动Web应用。工作原理是指它将供应商提供的原生测试框架（如iOS的、的/）封装为符合W3C标准的协议接口。测试脚本通过HTTP与通信, 进而控制设备。
关键特性方面, 它无需改动被测应用的源码或进行重编译。这非常适用于那些不需要碰被测应用代码的黑盒测试场景。此外, 它还支持多种语言, 开发者可以使用Java、、Ruby等多种语言来编写脚本。同时, 它还拥有一个活跃的社区。这个庞大的开发者社区带来了丰富的生态插件, 方便大家使用。
关于UI核心定位, 它是官方提供的系统级UI测试框架, 主要专注于对这个平台的黑盒测试。
它的工作原理是运行在设备的系统进程之中, 因为这样它能够访问屏幕上存在的所有用户界面组件,并且这种访问方式并不会依赖于被测试应用的内部结构如何设置, 其具有的关键特性在于可以进行跨应用测试, 也就是说可以用来测试那些涉及多个应用相互交互的场景情况, 比如同样可以使用例子来讲就是从应用A里面分享数据到应用B这样一个过程, 同时也具备系统级操作的能力, 会提供设备级别的接口功能, 像是能够点击物理按键或者获取屏幕截图等动作都包含在内, 不过它也存在着明显的局限性, 就是对应用内部具体内容方面的支持相对较弱一些, 而且现在它已经不再是目前阶段主要推广的用户界面测试工具了。
核心定位就是官方所推荐的那个轻量级UI测试框架, 这个框架是专门为应用的白盒测试工作而进行设计的。其工作原理是被测应用是在同一个进程里运行的, 这样就能够同步地监测主线程的活动情况了。该工具会自动等待UI处于空闲状态之后再去执行相应的操作, 从而使得整个测试的执行过程变得快速且稳定。
关于关键特性, 在同步机制方面, 它内置了等待功能, 这就意味着开发人员不需要在测试代码里去编写那些sleep语句了。同时, 它还拥有简洁的API, 因为API的设计意图表达得十分清晰, 所以整体学习成本相对较低。
存在局限性, 这主要体现在它主要被用于单应用内的测试场景, 如果需要进行跨应用的测试, 就必须依靠其他工具来辅助完成。关于核心定位, 它是历史非常悠久的一款UI测试框架, 并且支持灰盒测试模式。在特性方面, 这款工具能够测试本地应用以及混合应用, 同时还支持各种手势操作。
不过, 因为它的维护状态并不明朗, 所以在新项目中的使用频率已经相对较低了。此外还有另一个核心定位, 即它是一个基于某种框架的测试方案, 完全兼容相关协议。
当前的情况是, 这项技术在早期曾经是自动化领域非常有利的工具, 不过, 随着某些新技术的兴起, 以及这些新技术具备更加强劲的跨平台能力, 它现在已经逐渐退出了人们的主流视野。二、深度剖析。
这绝对是现在最火的那种移动自动化框架, 能成功主要是因为它架构设计得很清楚, 还有社区支持很厉害。
核心架构概念包括中心枢纽, 它的作用是接收客户端发来的指令, 然后把这些指令路由给对应的平台驱动, 其次是驱动程序模块, 举例来说像用于的驱动和用于iOS的驱动, 它们主要负责与特定的操作系统进行交互, 接下来是期望能力部分, 这是一堆配置参数的键值对用在这个地方, 其作用是告知系统要启动哪个平台的测试会话, 以及具体的设备和应用等信息, 最后是会话模块, 代表的是一次自动化测试所依托的全套上下文环境, 随后要讨论优势之间的权衡问题, 也就是第三部分关于UI元素分析与UI对象辨析这两个概念的对比区别。
这两个名字看着差不多, 但是它们的位置和负责修的人完全不一样。
(升级版本)：
简单地说, UI是官方提供的“原装”工具。而生态则是社区基于前者精心打造的功能更为强大的“增强版”。目前, 生态主要在该领域内发挥着至关重要且不可动摇的核心作用。
四、 实战：组合框架的最佳实践
在如今实际的企业级测试工作里, 如果只靠一个单一的框架, 往往就很难把各种各样的需求全都满足掉。当下业界普遍都在用一种分层组合的策略。这种策略里面的“ + ”, 就是去构建那些能够跨平台使用的自动化测试套件时, 被认为是非常核心的黄金组合方式。
1. 架构示意图与流程
交互流程简述：
测试脚本是通过任何语言来编写的, 它将通过协议向系统发送HTTP请求。然后, 系统将解析这个请求, 并且通过特定的方式将指令转发到安装在测试设备上的那个应用程序, 也就是那一个已经安装好的APK包。
接下来, 在这台设备上执行真实的操作, 比如说点击屏幕什么的操作之类的动作, 或者是输入文本等操作。执行完之后就会得到结果, 这些结果将沿着相反的路径回传给那个最初发起请求的测试脚本程序。
2. 实战案例场景优化（修改版）
现在我们来假设一下, 如果我们想要去测试一个电商应用里的那个环节, 就是用户从商品的详情页面, 分享到社交应用那里去的这样一个跨应用的流程。
脚本伪代码逻辑：# 使用 () from
第一步进行配置, 第二步启动电商App, 将参数赋值为字典变量caps, 该字典中包含空键值对、包名"com..shop"等内容, 随后调用方法并传入服务地址":4723"与上述caps参数。
现在需要在电子商务应用程序里面执行操作, 这部分工作由驱动来完成。具体而言, 系统使用名为“id”以及内容为空字符串的识别依据定位到元素中的手机对象, 随后接着定位通过名为“xpath”以及内容为“//商品列表项”的路径所描述的页面元素节点。
确定目标元素后, 驱动会执行点击动作, 从而实现对电商App内部页面的交互操作。
