作者 | 张志阳
App 自动化测试平台，是 App 客户端相关自动化测试流程&数据管理平台，主要目的是作为 App 客户端自动化的统一入口，提供 版本管理、任务执行、设备调度、数据存储&分析 等一系列连贯的全自动流程。本文主要介绍 UI 自动化之平台化管理- 你负责 Case，我负责其他～

背景

很多同学会想问一个问题：UI 自动化可以本地手动执行、脚本定时执行、配合 Jenkins 等 CI 任务执行... 就可以满足个人的执行需求、为什么要考虑平台化管理呢？
我们先列举一些平时执行自动化时会遇到的几类问题：

• 本地执行时偶尔会出现因个人失误，造成的无效执行 比如：代码没有更新、调试代码没有删除、使用错误版本、设备忘记连接、Case 没有选择全等
• 个人更改执行环境，导致环境不稳定，影响任务执行 比如：个人更换了 Appium/Android SDK/Xcode/依赖工具的版本，导致执行环境异常/不兼容/速度变慢/原有方法不可用等
• 执行结果不易分析 虽然 UITest 框架提供了执行过程详细、格式规范的执行 log 记录 & 保存到了本地，但在辣么长的汇总 log 里去定位到具体的 Case 和分析失败原因，也是十分考验眼睛滴
• 本地执行结果不能长久保存、历史数据不能被利用 用于分析的 log、截图、报告等文件在长时间执行后，会产生大量的目录，即使目录的命名格式再友好，面对辣么多的文件夹，找起来还是很 “头疼”，有时一天执行的太多，记不清某次异常 Case 的 log 是在哪个目录下了。几十天的执行下来，数（lan）不（de）清（shu）的目录占了大部分的磁盘空间，一下全部删掉，痛（dei）快（jin）！ 可是误删了还没分析的记录，再想找可就找不到喽
• 个人设备有限，执行时长太长、想要快点执行完 客户端 Case 现在有 300 多条，一台设备执行起来，没有一晚上是不可能执行完的、有时候碰见个别设备心情不好，早上来的时候刚执行 200 多条，当天就要发版本了，愁 skr 人。UITest 框架提供了多设备分配 Case 执行功能，但是面对个别时候发版前 2、3 个小时就需要提供结果，仅靠手里的设备还是会手忙脚乱、有些担心的。毕竟我们这 300 条自动化 Case 可是没有人在执行的，承担着责任的
• 还有一些其他经常会碰到的问题，就不一一列举了。这些问题都或多或少的对 UI 自动化的执行&调试造成了影响。 那么平台化的目的就是解决上述这些经常会影响效率的问题，提供稳定的执行环境、可靠的版本、大量的设备与账号，可对比分析的历史记录… 统一管理 UI 自动化的整体流程，保证测试任务稳定执行，不受一些客观因素影响。

功能设计

在讲测试平台的 UI 自动化流程之前，先了解一下整个 UI 自动化执行流程中不同阶段应该考虑的因素都有哪些？平台怎样为其一一提供方案。

• 执行前
  • 执行的前提条件： 1.被测应用 App 2.账号 3.设备 4.执行环境 5.Case 工程 6.UITest 框架 7.执行策略
  • 想要通过平台触发执行，就要先考虑如何准备这些前提条件
• 被测应用 App 平台保存 Jenkins job 编译的历史包信息，在执行时提供选择， UITest 框架支持 指定安装包文件执行，这样就可以自由的选择版本执行了
• 账号 & 设备 MCP 现在提供了大量的已绑定微信账号的设备，与其合作，实现可以调度 MCP 中的设备执行自动化；UITest 框架提供 指定微信账号 执行的功能，只需要再对设备进行筛选 & 调试，就可以满足多设备执行的需求了
• 执行环境 在 MCP 的 Agent 服务器上，搭建统一的稳定的执行环境，一起维护升级。就可以保证不会因个人尝试升级环境 导致的一段时间内不能稳定执行测试任务的问题出现，待管理测试过新环境后再统一进行升级
• Case 工程 & UITest 框架 Agent 执行时将两个工程代码下载 & 按照规则存放就可以用于执行了。但是业务线不同，如何确定使用哪个 Case 工程? 测试平台提供 项目 模块，可以为每个 Case 工程创建一个项目 & 绑定所属的业务线 & 设置 Case 工程的 git 链接 就可以了。再根据不同的测试任务需求，分别创建测试计划，执行测试计划时，就会下载对应的 Case 工程
• 执行策略 在测试计划详情页面，提供 重装 App 开关、分配 Case 开关、选择版本、选择 Case、选择设备、设置报告收件人等一系列功能 ，在执行前按个人需求进行更改 & 保存，触发执行时提交数据，传递给 Agent 拼装执行命令就可以了
• 执行过程中 过程中的基本需求：
  1. Case 执行 log & 异常 保存
  2. Case 执行 结果 & 失败截图保存
  3. Case 执行时设备 log 保存
  4. Case 执行时 应用性能数据 收集&保存 如果通过 Agent 执行，上述内容通过个人远程连接后获取，反而增加了操作成本。 平台提供对应的结果/数据同步接口，UITest 框架在执行过程中，实时的上报结果和数据；较大的 log & 图片文件，存储到 FTP，平台记录文件与 Case 之间的关联, 这样只要 FTP & 数据库 空间足够大，管理上万次的执行记录应该是没有问题的。
• 执行结束 结束后的常见操作：
  1. 查看整体的测试报告
  2. 失败 Case 分析
  3. 调试
  4. 重新执行 想要管理这个自动化流程，最后的结果汇总、分析、调试后重新执行当然不可忽视。
• 测试报告 平台采用了新的报告模版，在 UITest 框架模版的基础上增加了所测安装包的详细信息（版本、Tag），方便后续的版本统计及多次记录的区分
• 失败 Case 分析 平台为每次执行的每条 Case 都创建一个单独的结果详情页，里面展示了完整的执行 log、对应的失败截图、执行此 Case 时的设备 log，报告中可以直接进行跳转
• 调试后重新执行 重新在测试计划页面选择 Case & 版本 & 设备执行 的操作还是比较繁琐。平台提供提供重新执行入口，一键触发，自动选择最后一次执行记录所有失败的 Case 及当时使用的版本、自动分配设备（原设备优先）、自动触发执行。这样只需要调试后更新代码，一键触发，等待报告就好了。至于调试嘛，还是要自己进行滴。通过以上内容看下来，整个自动化的执行流程，除了 Case 的编写、调试，其他的平台都可以进行管理了。

最终流程

整个执行流程所涉及的点都想好策略后，就可以开始进行开发，拼接流程了，具体的实现细节就不多说了，直接说结果。
基础的执行流程如下:
- 手动执行测试计划流程

- 自动执行测试计划流程

另外～为了方便 FE 项目 UI 自动化的执行，测试平台与 Beetle 合作 为 FE 增加了 UI 自动化 CI 配置，将 FE 上线节点 与 UI 自动化测试流程串连， 实现 FE 项目上线后自动进行 UI 自动化回归的全自动流程，具体流程如下：

总结

1. 现在的测试平台，已经具有完善的 UI 自动化测试体系，保证了 UI 自动化可以稳定自由的执行 & 结果分析、对比。
2. 结合测试平台的项目管理 及 MCP 提供的设备池，可以支撑多业务同时执行自动化任务。
3. 与 Beetle 的合作，也为 UI 自动化 与 项目流程的结合做了较好的开端。 现在真的是 “你负责 Case，我负责其他

后续计划

1. 与其他的 项目流程 关联，增加更多的自动化流程
2. 尝试与 TAPD 打通，实现 BUG 的提交、关联
3. 提供更多更方便的执行方案，根据不同业务/项目 优化对应的执行流程， 提升流程效率