背景
埋点对电商类app的业务发展一直有着重要的指导作用,但是其复杂的数据组成使得它的稳定性难以得到保障,往往业务逻辑的一些重构就会导致一些埋点属性甚至是整个埋点的丢失。
也正是由于埋点具有多个数据源,常规的自动化验证只能验证埋点是否存在,无法跟业务场景匹配。而对于人工排查来说,虽然能解决和场景匹配的问题,但是像不同埋点的属性之间的关联或者属性和接口字段的关联这类复杂的校验做起来也非常的困难。
本文将介绍我们是如何通过teslaLab+埋点验证平台实现了埋点的自动回归以及多维度的埋点校验,并在最近三个版本中累积发现了数十个埋点问题。
安卓

IOS

痛点
一个埋点中的数据主要由三个部分组成:
-
接口下发数据
-
用户行为
-
本地运行的代码
要想验证一个埋点是否符合预期的设计,关键的难点就在于如何固定住这三个数据源,使其每次生成的结果都保持一致或者符合我们预定的规则。因此我们分别采用了以下方案来实现埋点生成时数据源的固定
-
接口数据:对接口mock实现了对接口数据的录制&回放
-
用户行为数据:通过谷歌的uiautomator来实现用户行为的录制&回放
-
本地代码:和ab平台打通,通过动态调整ab配置下发接口来最大限度上固定客户端ab实验相关的代码。
概览
名词解释
-
teslaLab: 是一款无线测试工具(MAC/WIN应用),提供开箱即用的无线性能 /体验 /UI自动化 等专项测试工具。
-
ubt-verification:安卓侧实现埋点数据录制和接口Mock功能的SDK。
-
测试场景:即校验规则组,对应着一个测试用例,包含了这个case的所有埋点校验规则
-
mock记录:包含了一个case在运行过程中请求的所有接口的数据,用于自动化回归时进行接口mock。
-
测试记录:自动化回归的产物,即录制到的所有埋点数据。
-
验证报告:即测试记录和测试场景的结合产物,包含了所有异常埋点的具体异常信息。
-
任务组:来自teslaLab的概念,即测试记录的集合,一般用于聚合各业务线的测试记录。
-
通过率:指一个测试记录中没有任何埋点异常的埋点(去重)占埋点总数(去重)的百分比。
-
任务组通过率:指任务组中所有测试记录中没有异常的埋点总数之和(去重)占所有埋点总数之和(去重)的百分比。
系统架构图
整个埋点自动化验证平台主要由三部分组成,分别是:
-
自动化工具:teslaLab
-
移动端SDK:安卓的ubt-verification和ios的kylin
-
验证平台:无线研发平台的埋点验证模块

流程图
下图为单个测试用例的首次验证流程:
主要可分为三个阶段:
1. 准备阶段
-
用teslaLab录制或者编写自动化脚本
-
在脚本编辑页手动执行脚本并选择录制Mock功能,录制接口数据并创建Mock记录
-
新建运行任务并选中前面新建的脚本和Mock记录,执行任务之后得到一组埋点数据(即测试记录)。
-
根据需要验证的埋点的数量自行选择手动配置(不推荐,太麻烦)或者从上一步得到的测试记录中自动生成(推荐)相应基础规则(即测试场景)。
-
至此,埋点自动化验证的三要素(自动化脚本,Mock记录,测试场景)已集齐。
2. 运行阶段
-
可以手动执行或者通过配置Cron表达式实现定时执行在准备阶段新建的自动化任务,产出一份测试记录和一份验证报告。
3. 验收阶段
-
根据预定策略和测试记录自动生成的验证规则可能无法满足预期,因此产出的验证报告中的问题需要人工核查是否有效。
-
如果无效则可以通过报告详情页中的修复按钮快速订正规则,或者前往测试场景详情页手动订正规则。
-
如果有效则可以选中有效的埋点并提交报障至埋点管理平台,提交成功后会飞书通知至最后一位负责该埋点的研发和测试,当问题修复并被测试验收之后即可验收报障。
-
-
至此,一个测试用例的完整验证流程结束。

详情
接下来将按照验证流程的顺序逐一介绍这三个模块的详细流程
自动化模块
埋点自动化依赖 「Tesla-lab」 的自动化模块,其中数据Mock 记录的录制和UI自动化 脚本的录制依赖 「Tesla-lab」 本地编辑器,任务和任务组的定时执行依赖 「Tesla-lab」 任务调度模块,任务的实际执行依赖 「Tesla-lab」 任务执行器。
「Tesla-lab」自动化流程图


本文介绍了如何通过teslaLab+埋点验证平台实现电商APP的埋点自动化回归及多维度校验,解决了接口数据、用户行为和本地代码数据源固定的问题。系统包括自动化工具、移动端SDK和验证平台,支持接口Mock、用户行为录制和本地代码调整。通过自动化测试和人工核查,累计发现了数十个埋点问题,提高了埋点数据的准确性和稳定性。
最低0.47元/天 解锁文章
955

被折叠的 条评论
为什么被折叠?



