找靓机埋点 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、提高自动化利用率，工程发布自动化触发自动化，每天定时执行检测