京东金融云测平台方案揭秘

本文作者：京东数科 薛亚斌
文章来源：“京东数科技术说”微信公众号
原文链接: https://mp.weixin.qq.com/s/oxy1SKsjUCZIgjjKO7OiGg.
更多技术干货欢迎关注“京东数科技术说”微信公众号，我们只凭技术说话！

一、源起

2011年初，在国外的一个网站上看到一篇关于移动端云测相关的文章，突然意识到这是一个大有所为的市场，然后游说老板和并开始实施demo版，后来老板因为觉得我们有更重要的事情做，而且这是一个小众市场，就不了了之，后来心有不甘，完成一篇关于云测平台的专利提交。

2017年加入京东金融，进行移动端测试与探索，做了一个简单的系统，支持自动化和客户端性能测试，通过调用执行云设备管理的设备。就在这时，有个国企要采购云测项目邀请参加POC，和领导商议后，觉得这事可以搞。通宵达旦的搞4天3晚上，按照POC要求优化了管理后台的功能和界面，以及后台云设备管理端，较好的完成了此次POC，领导也很满意，借着公司对外赋能的东风，开启了京东金融云测平台工具建设之路。

二、云测平台架构

移动端测试解决方案主要包含四部分内容录制回放、测试管理、测试服务管理、云设备管理。当用户使用平台时，首先通过录制回放模块录制脚本（也可以手写脚本），提交或者上传到移动端测试管理中的脚本管理中，按照业务进行测试脚本和测试数据配置，组织测试用例、测试场景、测试任务，然后选择对应的App包，通过选择执行测试服务内容提供的测试服务类型，调度执行运设备管理上的设备进行执行，执行完成后将测试结果反馈到测试管理中的结果呈现管理模块。

1.录制回放

录制回放模块，当时最主要的目标是对标竞品，根据对外赋能需求支持的模块，录制回放参考了很多PC时代录制回放的优点，同时结合不同厂商使用工具的特点，进行了一系列能力的扩展和优化。

在脚本增强方面，除了支持顺序、分支、循环三种结果体，还增加了参数化、检查点（文本、图片、表格等）、脚本段（事物）等方式的脚本优化。

为了适应不同公司和厂商的习惯和要求，低成本的移植和嵌入到现有工作流程，在录制回放中制定了一套标准的语义规则，方便把录制回放的脚本快速转换成主流的appium、Uiautomator、 Robolectric等脚本语言。平台也支持以上三种工具的标准脚本的执行和调度。

录制回放的框架使用Uiautomator作为底层的组件及对象获取，通过minicap、minitouch进行信息流的交互和转换，实现Android平台的录制与回放的基本功能。因为篇幅限制更多技术细节不在此详细赘述。

2.测试管理

测试管理主要是对测试资产进行管理，包含测试对象、测试脚本、测试数据、用例的组织方式、测试结果进行管理；

测试对象主要是对应用安装包的管理，包括应用包的上传下载、应用包的版本信息和开发者信息等。

测试结果呈现主要是各种测试结果进行聚合呈现，分类分析，方便统计和分析测试执行情况，质量发展趋势等。

测试脚本主要是录制回放的脚本或者根据框架提供的demo编写的脚本，支持脚的上传下载和git地址自动打测试包的方式。脚本管理对脚本版本管理做了严格的区分，方便制定不同的执行策略，并减少自动执行时的出错几率。

测试用例和测试数据是测试最核心的资产之一，测试用例和测试数据管理是检验工具平台是否好用的最主要标准之一。京东云测平台测试用例组织主要有测试步骤、测试用例、测试场景三部分，测试数据也对应的有三部分，基于测试步骤的业务数据、基于测试用例的依赖数据（包含测试步骤之间的依赖和用例之间的依赖）、基于测试场景的参考数据、基于运行或者执行环境的全局数据。

业务数据：业务数据，顾名思义，就是与业务相关的数据，主要是为了完成某项业务而准备的数据，业务数据与业务密切相关，比如登录，必须有账号和密码等信息、信用卡开卡必须填写身份证证明信息、个人以及卡属性相关信息。这些信息和数据都是密切和相关业务绑定。

依赖数据：简单的理解为完成某一项业务，而必须依赖上一个业务或者前置业务产生的结果数据作他的输入，我们称之为依赖数据，包含测试步骤之间的依赖和用例之间的依赖。比如存钱业务，先需要依赖银行卡号等。

参考数据：参考数据是针对测试场景而提供的一个功能增强的便捷功能。比如登录有多种场景，账号密码登录、一键登录（微信、微博、京东）、人脸识别登录、手机号码一键登录等等。在测试时需要准备不同的数据，为了方便测试，提出了一个依赖参数，比如可以每个场景关联一个sql语句，实现场景与数据的关联，方便进行测试。

全局数据：和各种语言中的全局数据一样，主要是方便配置和灵活迁移执行，比如测试地址，测试环境、公共账号等信息。

3.测试服务管理（测试类型支持）

测试服务管理，提供统一的接口方式，以服务化的方式接入各种测试类型，如App自动化测试、App性能测试、App标准兼容性测试、稳定性测试（Monkey、自动遍历）、安全测试等等。

▶ 稳定性工具&monkey测试工具
Android端通过Android SDK提供的命令行工具，iOS端利用XCTest单元测试和Facebook的 WDA，实现Server-Client架构（C/S）的消息通信。发送伪随机的用户事件流。

自动启动App向系统发送大量、连续、随机的用户事件流，如按键输入、触摸屏输入、手势输入等，实现对正在开发的应用程序进行压力测试，跟踪日志输出，查看是否会出现崩溃，无响应等问题，以此监控App稳定性。

▶ 自动遍历
APP运行过程中，通过Android SDK获取APP当前页面上所有的可点击元素，依次按照策略（深度遍历算法或者广度遍历算法）点击每个可点击元素，并记录新页面。通过算法对元素和新页面进行记录并去重。当前页面遍历完毕后，重复之前逻辑，依次遍历记录的新页面。

自动化遍历工具为在非人工干预的情况下，通过按指定级别，依次点击APP上所有可点击的元素，并记录点击过程中的崩溃、错误、黑白屏、异常日志等数据。

▶ 自动化测试工具
APP运行期间，通过命令和内嵌SDK方式获取APP的资源消耗信息。

APP性能测试工具主要为了检测应用在执行期间的性能消耗，包括CPU、内存、耗电量、流量、启动速度、跳转速度等，保证APP在重大功能发布以及版本迭代升级中，不影响用户体验。

▶ 云设备管理
云设备管理，就是对手机进行集中式管理，通过Android SDK提供的命令行工具，iOS端利用Facebook的 WDA，通过Server-Client架构（C/S）的消息事件流的通信。进而实现从web端访问云端手机设备，以达到设备资源利用率最大化。

设备管理在移动端测试中也没有很好的利用起来，主要有以下几个原因：

1）设备不足，显得工具华而不实，之所以作为一个平台，也具有集装箱原理，需要有足够的设备，一般的公司设备都是比较少或者“刚刚够用”，这个时候建设一个云测平台就会影响整个效率。

2）效率问题，云设备管理，在测试过程中，需要频繁上传、下载、安装测试包，由于网络因素，导致测试过程比在本地测试需要的时间更长。

3）稳定性，云设备平台遇到最大的一个问题，就是长时间使用会导致莫名其妙的链接中断，导致维护成本过高。

4）兼容性，在新加入设备时，需要对各种接入工具进行设配，工作量对于一个普通的业务团队来说是巨大的。

三、思考与建议

录制回放功能虽然现在很鸡肋，但随着图片识别技术、人工智能的发展有可能会有一个大发展。在实践过程中曾经想过通过设计原型稿和手机展示的界面，通过分层切图进行比对识别，做兼容性测试，但因为人力成本问题没有完成，但我觉得这个应该是未来发展的一个方向。

测试管理部分，用例和数据的组织方式，设计时追求完美，但在实际使用过程中略显繁琐，当然这也和互联网业务相对较为简单有关系。工具和平台真正要好用，需要不断的修正磨合。

测试服务管理中的工具模块，工具只是提供一种能力，如何使用是需要测试工程师在工作中不断思考和调整。

云设备管理，通过实践个人觉得私有云的方式可能符合中型规模团队（30-50人），这样可以克服上文提到公有云中的效率和稳定性的问题，目前这种方案团队正在实践中，需要进一步验证实践。