转转QA 找靓机 App 埋点 Case 自动化回归

志阳、 for 转转QA · 2021年08月13日 · 最后由 cooling 回复于 2021年08月13日 · 2862 次阅读

作者|邹德龙

找靓机埋点 Case 自动化回归

一、背景和目的

​ 线上存在埋点数量总数大于 1000 个,主流程 case 大于 300 个,在对功能迭代过程中经常会有对已有的埋点进行回归的述求,以往都是消耗大量的时间去手工回归,同时覆盖 2 端还容易出现漏测的现象。
为了改善现状,内部调研可做成 UI 自动化回归,经过实践后约能提效 50%,且只要及时补充场景,就可以大大降低漏测的场景。

二、断言方法

CASE 执行流程:

如何获取客户端上报的埋点数据:

1. Android 客户端通过 adb 命令实现:
def save_logcat_to_file(self, file_path, grep_str=``""``, extra_args=``""``, parameter=``"-d"``):
  ``""``"
  ``保存log 到指定文件 & 返回 进程
  ``adb logcat -v time > xxx
  ``:param grep_str: 过滤字符
  ``:param extra_args: 额外的参数
  ``:param file_path: log 存储路径
  ``:param parameter: logcat的额外的参数; 默认-d(将缓存的日志输出, 并且不会阻塞;)
  ``:``return``: log 进程
  ``""``"
  ``logcat_cmd = ``"shell "
  ``to_file_cmd = ``" > "` `+ file_path
  ``if` `extra_args:
    ``logcat_cmd += ``" "` `+ extra_args
  ``if` `grep_str:
    ``if` `config.is_windows:
      ``# logcat_cmd += ``"\"logcat -d -v time | grep \'"` `+ grep_str + ``"\'\""
      ``logcat_cmd += ``"\"logcat "` `+ parameter + ``" -v time | grep \'"` `+ grep_str + ``"\'\""
    ``else``:
      ``# logcat_cmd += ``"logcat -d -v time | grep \'"` `+ grep_str + ``"\'"
      ``logcat_cmd += ``"logcat "` `+ parameter + ``" -v time | grep \'"` `+ grep_str + ``"\'"
  ``else``:
    ``logcat_cmd = ``"logcat -v time"
  ``# 打印日志详细时间的简单数据
  ``return` `self.cmd(logcat_cmd + to_file_cmd, return_proc=True)
2. iOS 客户端通过 idevicesyslog 命令实现:
def save_device_log(device_id, device_log_path):
  ``""``"
  ``开始保存设备log到指定文件 & 返回保存log 进程
  ``:param device_id: 指定设备 id
  ``:param device_log_path: 设备log文件
  ``:``return``: 保存log 进程 / None
  ``""``"
  ``try``:
    ``Logger().setlog(device_id + ``" 准备收集Case 日志"``, LEVEL_INFO)
    ``if` `PLATFORM_IOS in config.operating_system:
      ``# proc = Shell.proc(``"idevicesyslog -u "` `+ device_id + ``" > "` `+ device_log_path)
      ``proc = Shell.proc(``"tidevice -u "` `+ device_id + ``" syslog> "` `+ device_log_path)
    ``else``:
      ``device = ADB(serialno=device_id)
      ``device.clear_logcat()
      ``proc = device.save_logcat_to_file(device_log_path)
    ``Logger().setlog(device_id + ``"开始收集Case 日志"``, LEVEL_INFO)
    ``return` `proc
  ``except:
    ``print(``"存储设备log异常"``)
    ``return` `None
3. H5 页面通过调用客户端 webview 能力实现:

因 H5 是初尝试实现,在落实过程中,为了保证能够有如下效果,调研设想了 3 套方案

  • 方案一「舍弃」: 通过获取 H5 的日志,对 H5 日志进行断言

    • 舍弃原因:
      • 当前线上环境的 H5 埋点,是直接上报到线上环境的,避免测试数据对统计造成影响;实现对 H5 执行日志捕获投入成本高;
    • 实现流程如下:
  • 方案二「舍弃」:写一个新的 API,供 H5 上报埋点时异步调用

    • 舍弃原因:
      • 投入资源成本高,线上会高频调用;无法保证延迟和稳定容易影响到业务
    • 流程如下:
  • 方案三「最终」:

    • H5 实现方案是在上报埋点的方法里面,同时异步调用客户端 webview 的能力,达到共用客户端实现的方法,也可以完成埋点的断言。
    • 实现流程如下:

三、实现前后测试方法对比

场景 传统人工回归验证 UI 自动化验回归 实现后优缺点
客户端操作 手动挂代理,开启彩蛋(客户端调试模式)高频重复操作 APP 自动化操作 优点:可以大大减小人工高频操作缺点:客户端的操作需要提前录入 case
埋点上报验证 操作 APP 后,需要等待 3 分钟左右(平台数据查询有延迟),登录神策平台相关 SQL 查询设备上报记录分析每个字段的上报和时序是否和预期一致 对客户端上报日志自动断言每个埋点都是 1 个 case,单独进行回归,互不影响输出相关 SQL,人工可以随机快速复核埋点 优点: 1、大大降低漏测率,质效提升约 50%2、操作后实时进行断言,无需等待缺点:前期还需人工随机复核
回归频率和范围 回归主流程埋点 只要录入,都能覆盖回归 优点:覆盖范围全,回归次数越多,质效提示越明显缺点:释放的人力,部分时间投入到了埋点 case 录入和维护

四、总结

1、梳理业务流程,明确自动化需要做哪范围

2、自动化框架造型

3、埋点测试存在哪些痛点,对比之后寻找解决思路

4、数据自动校验对比

5、提高自动化利用率,工程发布自动化触发自动化,每天定时执行检测

如果对我们分享的内容感兴趣,欢迎关注我们团队的 VX 公众号:转转 QA

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 3 条回复 时间 点赞

其实除了通过分析 log,还可以 UI 自动化的自动挂个代理抓包,直接分析包的内容这样子我感觉比分析日志可靠一点

残枫 回复

是的,这是另一个方向,我们也在实践

这个和使用 firebase 的区别?

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