转转QA UI 自动化之平台化管理

笑哼 for 转转QA · 2018年11月16日 · 最后由 一丢丢 回复于 2020年02月27日 · 388 次阅读

作者 | 张志阳
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. 提供更多更方便的执行方案,根据不同业务/项目 优化对应的执行流程, 提升流程效率
共收到 1 条回复 时间 点赞

期待开源

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册