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

笑哼 for 转转QA · November 16, 2018 · 1355 hits

作者|张志阳
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. 提供更多更方便的执行方案,根据不同业务/项目 优化对应的执行流程, 提升流程效率
No Reply at the moment.
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up