TARS 系统 —— UI 自动化解决方案

2018年加入去哪儿网，主要负责机票主流程、机票 iOS客户端、TARS UI自动化系统、iOS端指纹加固等方面的工作。

1. 立项背景

业务痛点

互联网 APP 测试在“快速迭代”的开发模式中进行的，每次迭代都会伴随着各种各样的测试，其中以功能集成测试为重要和主要的一个方面，又因版本迭代过程中需要进行的功能特性验证和已有功能回归，要求测试人员既能测试性功能的各种特性，又要保证原有功能不受影响。在频繁的迭代工程中，APP 的功能和结构越来越复杂，新代码的影响越来越广，回归范围越来越多而且 APP 端有各种机型和系统版本，这就造成了潜在的漏测风险和越来越多的重复劳动。以去哪儿网机票业务为例，冒烟 Case 测试点就有300+，月版回归 Case 测试点有1000+，每次月版回归相当耗费测试人员精力，测试的质量依赖于测试人员的质量，并且还有可能遗漏，每次月版回归都要至少10个 QA 集中测试一天，效率十分低下，并且还经常出现线上 bug 和故障。

为了解决其中工作量最大的每次都要进行的回归测试工作量问题，提升工作效率，降低潜在的遗漏风险，减少重复的工作，该项目希望能够通过一种所见即所得的方式完成脚本的录制，即使测试人员不会编程不懂脚本，也可以通过正常用户的点击拖拽等操作，自动完成脚本的录制，从而大幅度降低企业和项目的自动化维护成本。针对移动厂商跨多端的特点，需要开发一套 UI 自动化测试解决方案。支持 TestCase 的自动重复执行，在多种机型兼容性测试，后端响应数据可控，并对执行结果的请求数据、响应数据以及界面截图进行验证，断言执行结果的正确性。

2. 方案选型

2.1 测试分类

自动化测试是随软件开发技术一并发展的一种测试技术。软件测试包括白盒测试与黑盒测试，而自动化测试最早使用白盒测试中的单元测试。这种测试方式较为高效，易于实现。黑盒自动化测试兴起稍晚，但目前应用也非常广泛。黑盒自动化测试原理是用程序和脚本模拟用户的操作行为，通过智能方式验证软件的关键检查点。在桌面软件和 Web 技术兴盛时代，涌现出大量优秀的自动化测试工具如 QTP 和 webdriver，这些工具经过不断完善已经逐步成熟，能够较好地满足传统应用的自动化测试需求。

APP 的自动化测试包括以下这些：

1、按测试目的划分：

功能测试：对产品和模块的各个功能进行测试。

性能测试：对系统的各项性能指标进行测试。

压力测试：测试软件或系统的负载能力，挖掘隐患。

兼容性测试：对产品和软硬件之间的兼容性进行测试，比如软件在各种不同安卓机型上的兼容性。

安全性测试：通过不同方法发现软件的安全性问题，比如信息泄露、非法使用、恶意破坏等等。

其他专项测试：比如弱网络测试、耗电量测试、流畅度测试等等。

2、如果根据软件开发阶段来划分，每个阶段又可以做：

单元测试：对程序中的独立模块进行白盒测试，目的是检验软件基本组成单位的正确性。

集成测试：通过对单元模块进行组合测试，目的是验证单元模块之间的接口是否正确。

系统测试：对整个系统进行完整测试，验证整个系统的正确性与合规性。

回归测试：当软件发生变更的时候，对这次变更可能受影响的功能模块进行验证。

验收测试：测试的最后一个阶段，软件发布或者上线前确保软件质量。

3、其他常用测试概念：

冒烟测试：冒烟测试是对软件最基本的功能进行简单测试，低成本的判断软件是否可测。

冒烟测试来源于硬件的测试，当电路板做好后，首先会进行一次加电，如果没有冒烟才会开始进行接下来的测试，否则说明产品没有达到最基本的质量要求，需要重新制作。

探索性测试：探索性更多的依赖测试人员的个人经验或者特长，依靠的是测试人员的主观能动性。

探索性测试的重要性可以参考游戏测试领域，千千万万的玩家会在各种意想不到的环境下以意想不到的方式来进行游戏，所以游戏的测试者不仅要掌握系统的测试方法论、先进的测试工具以外，还要有丰富的游戏经验和探索的测试思维。

功能集成测试、性能、兼容性、界面交互、访问权限、用户使用体验等等，其中琳琅满目的各种型号、版本的设备数不胜数。其中功能集成测试，在每次版本迭代过程中需要进行的功能特性验证和已有功能回归，要求测试人员既能测试性新功能的各种特性，又要保证原有功能不受影响。

随着时间的推移，APP 的功能越来越完备，结构越来越复杂，每次代码改动的影响范围越来越广，而且有些测试条件构造原本就很复杂，相应的回归范围也会随着越来越多，加上频繁的迭代，这就使质量保证变为过多的重复性有意义的劳动，在执行过程中也会一定程度上造成潜在的漏测风险。受限于经济、人力等因素，想要在一定的时间内完全兼容性测试也十分困难。

综上所述：一是功能测试中的变化可能不好执行，二是回归频繁重复，三是兼容性会成倍加剧以上两种情况，所以为了解决这些问题，提升工作效率，针对 APP 特点，需要开发一套 APP 自动化解决方案。支持打包之后自动执行测试用例，在多种机型兼容性测试，降低测试人员的重复劳动，提升测试质量，并可对执行结果的判断是否通过的自动化测试系统。

2.2 UI 自动化发展趋势

智能手机的应用带来软件测试技术新的革命，相比于传统测试，手机测试在硬件上脱离了 PC 的传统架构，和用户的交互方式存在很大区别。手机软件在使用上具有独特的操作方式，比如用户的滑动、触摸和点击等操作，如何实现手机客户端上的自动化脚本执行成为这类测试的难点。又由于 IOS，Android 两大平台的市场格局，大部分手机应用都需要支持多个平台，它们的基础架构不尽相同，使得手机自动化测试框架对兼容性有了更高要求。移动设备的智能化及普及化，也使越来越多的人享受着科技创新和发展所带来的便捷生活。尤其是今年以来，全世界的网络流量第一次历史性的移动端超过 PC 端，这说明未来的趋势是移动市场将占据主导地位，移动设备上应用最广泛的当属 APP，因其操作便捷性，友好的交互，以及切实的解决用户的问题，首当其冲的为人们所广泛使用。要做好手机客户端的自动化测试，首先要解决测试脚本的健壮性和平台的兼容性问题。

在 APP 的软件使用过程中，需要尽可能的减少用户使用过程中遇到的各种问题，避免因 APP 出现的 bug 给用户带来使用上的不便，使原本带来的便捷，变得不那么“便捷”。所以在开发过程中，就需要把质量作为重中之重，进行全面深入的质量测试。而互联网行业瞬息万变，要满足日新月异的变化在业务和技术上持续不断的推陈出新。因此 APP 的开发模式采用了软件工程中的“快速迭代”模式，以应对快速变化带来的各种影响，既要保证全面的测试覆盖，又要用更小的时间成本就成了重点。

近几年手机客户端自动化工具发展较快，出现了不少自动化框架，比如基于 Android 平台的 UiAutomator 和 Robotium ，IOS 自带的 Instrument 等，但是这些工具都没有有效解决平台兼容性问题，无法用一个统一的框架驱动。

不同平台测试，而且在识别客户端内容和元素时也存在偏差，测试脚本不够稳定健壮。目前具有良好兼容性且框架成熟稳定的工具是 Appium。Appium 是一个开源的、跨多平台多语言的测试框架，相比于其它框架，它编写测试脚本和运行测试时不需要对源码重新编译，在脚本的编写和实现上也对编程语言没有太多要求，测试更轻量灵活。此外，Appium 采用了 C/S 架构 ，提供了一个统一的对外服务接口，使得客户端或模拟器的交互和控制透明化。

目前市面上已有一些 APP 的测试框架，有的跨端能力不强，支持 www 网页测试，有的只支持 Android、IOS 移动端，同时支持 Android、IOS、www、小程序的少之又少，有的解决的功能测试的问题，但是基于快速变化需要维护的成本远大于使用的成本，都没有很好的解决痛点。

TARS 名称来源于《星际穿越》这部著名的科幻电影，TARS 是电影中功能强大的智能机器人，辅助主角完成了很多艰巨的任务。

3.2 框架结构

采用 TARS+Jenkins+STF 作为整体控制调度的系统，整体系统分为应用层，控制层，设备层。通过设备集群控制系统，选择设备集群，批量跑自动化测试 Case。Case 录入系统可根据图片，UI 元素定位识别来确定 Case 的操作步骤。几乎所有系统采用了代码量较少、对数据控制更灵活 python 作为编程语言。

首先是准备：控制系统通过设备管理平台选择好需要进行测试的设备，安装好客户端，配置好测试环境参数，如 AB，MocK。控制系统通修改响应数据，保存响应数据到某个 testcase 中（以备下次 MocK），直接返回服务器响应，还是获取对应 testcase 的 Mock 数据，可控制 APP 端获得的各种数据字段。

然后开始执行 testcase：在指定设备中调起客户端，执行指定 testcase。

最后是 diff 断言阶段，对比返回结果，请求参数，样式图片之间的差异。

• 控制系统，正确的控制调度每一步所要执行何种动作。能够正确转发请求并截获响应。

• Mock 系统能够按照配置正确或把后端响应数据修改、保存再返给前端，或把 Mock 数据返给前端，并正确保存请求和响应的各个数据，完成 http 转发代理。

• 设备平台，能根据现有挂载到平台上的设备，判断可用情况，提供设备共测试使用。

• Case 录入，可让用户手工操作截图，UI 元素识别，OCR 文字识别等方式录入 Case，简化 Case 录入方法。

图片和数据 diff 系统，把测试数据和截图准确 diff，排除可能的影响因素（如数据使用 Mock 接口）。

3.6 持续集成方案
在实际的自动化使用场景中，我们一般是需要在日常的开发和提测过程中进行自动化测试。整个过程一般包括以下几个阶段：

1. 构建开发分支最新 beta 包

2. 安装到自动化设备上

3. 设置运行环境

4. 执行自动化 Case

5. 执行结束发送结果报告

而且，根据不同的使用场景，我们会执行不同的测试，比如：

• 冒烟测试——回归重点 Case，保证提测的基本质量

• 业务回归测试——回归需求相关的业务 Case，辅助 QA 对历史 Case 进行回归

• 性能测试——对比本次修改有没有造成性能的下降

• 兼容性测试——测试在不同设备上的稳定性

由人来操作肯定是不现实的，所以我们需要一个持续集成的工具来帮我们自动完成这些工作。

我们使用 jenkins 作为我们持续集成的平台，整个流程大致由下图所示:

QA 同学也在测试的时候可以选择相关的业务 Case 进行回归。

---

4. 实践过程

路线图

来源：去哪儿网技术沙龙

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！