1 背景

APP端UI自动化因其特殊性（需连贯测试机）个别都在本地执行，这种执行形式的局限性有以下弊病：

  1. 时效性低：研发每次打包后都须要告诉测试，测试再去打包平台取包，存在时间差
  2. 研发自测或产品验收无奈应用自动化脚本：研发自测及产品验收时如果想用自动化脚本须要搭建相应的运行环境并筹备测试机，繁琐的步骤导致研发/产品放弃应用自动化。而手工验证的过程中常常须要测试帮助下单、改数据，效率低
  3. 本地执行的后果没有长久化存储，不利于进行后果度量

2 计划剖析

为解决以上问题须要搭建流水线，CI/CD畛域罕用的流水线平台非Jenkins莫属，Jenkins功能强大、可二次开发，但执行APP自动化须要windows执行机、模拟器/真机，这些要求无疑减少了测试老本。与之相比，Bamboo平台是基于Jenkins开发的流水线平台，不仅继承了Jenkins的泛滥性能，且反对图形化配置，并对接了赛博平台等其余平台。

从下图比照中能够看出，复用现有的Bamboo平台老本更低，同时须要做以下扭转：一、自动化框架须要改为airtest框架；二、须要对测试报告进行解决以合乎预期。

[]()

3 计划施行

架构图：

[]()

流程图：

[]()

执行后果：

[]()

4 执行过程中遇到的问题及解决方案

1.bamboo打debug包成，release包不胜利

解决：证书治理中上传 sign.properties 文件，该文件中去掉绝对路径信息，应用相对路径

2.赛博平台无奈输出汉字

解决：用poco().set_text()代替text()办法

3.跑脚本失败提醒 RuntimeError: unable to launch AndroidUiautomationPoco

解决：赛博的机器有ATX,会影响poco初始化。poco初始化前加代码：

# 进行ATXtry:shell("am force-stop com.github.uiautomator")shell("/data/local/tmp/atx-agent server --stop")except Exception as e:print("兼容非赛博机器")

5 待解决问题

  1. 接入coding平台，只反对airtest框架
    影响：须要对原框架进行改变，老本较高。与赛博平台负责产品沟通过，赛博平台前期会开发对接其余框架的性能。
  2. 手动配置的数据比拟多：模块、用例、用例集
    影响：除了测试脚本外还需独自配置模块、用例、用例集，人工成本较高。后需可思考coding平台代码合并后触发定时工作主动生成对应的模块、用例、用例集。
  3. 无奈指定机型
    影响：无奈指定机型进行兼容性测试，与赛博平台分则产品沟通过，暂未有打算批改此项。
  4. 京管家未接入线上打包平台
    影响：测试过程中须要本地保留apk包，占本地内存且容易混同；无奈进行版本治理，须要复现问题时不能及时提供历史版本；UED走查或产品验收时只能京ME分割研发取包，时效性差；无奈接入流水线。

6 预期收益

流水线不仅解决了环境配置及测试机有余的问题还有以下劣势：

  1. 学习成本低，操作简略，预计可节俭三分之二的工时
  2. 执行后果能够做长久化存储，前期可与自动化度量平台相结合进行数据分析
  3. 流水线中可退出Sunglasses原子，UI自动化测试过程中监控Flutter异样
  4. 线上版本可做日常化监控，及时发现问题

作者：京东物流 范文君

起源：京东云开发者社区 自猿其说Tech