作者 | 庄锦弟

一、A/B 测试的认知

百度一查,ab 测试的介绍太多了,这里就不再详细介绍了。本文主要是介绍如何对 ab 需求进行测试和验证。

二、历史背景

1、需求文档缺失定义

2、业务场景梳理不清晰

3、研发过程对业务流程理解不一致

4、测试过程覆盖颗粒度不全,部分场景属于盲测状态

5、缺少数据验证

三、业务测试流程改进

改进现有的测试流程,从业务场景测试,埋点测试,A/B 数据验证这些流程进行梳理,流程图如下:

【改进说明】

1、需求文档(大数据产品确认之后)要明确业务场景和业务流程,A/B 实验测试 id、相关字段说明或者验证 sql,如果不明确或者不清晰,需要找产品,需求方提供(产品、研发、测试 三方对需求理解需保持一致性)

需求评审,大数据产品一定要到场(或者安排相关人员)

埋点文档需要明确测试字段(产品/需求方提供),和哪些业务场景有埋点,如有影响 A/B 实验场景,必须说明场景

A/B 测试范围有哪些业务场景(产品/需求方提供),有哪页面或者入口

如果大数据产品未确认的需求,又是需要做的,需求评审结果: 评审不通过

2、研发过程设计文档或者接口字段,需提供 A/B 实验相关的场景说明,便于测试理解

提供数据验证的 sql(研发),或者验证字段说明

3、测试用例:设计 A/B 实验的测试场景用例,A/B 测试需要通过神策系统验证数据是否正确

用例内审:A/B 实验测试场景的覆盖、数据上报和数据验证

如有与埋点有相关的 A/B 实验,需把组合场景用例输出

神策验证测试账号(验证测试数据)

4、增加验收环节,埋点验收人:业务产品 A/B 测试验收人:大数据产品 测试流程验收:QA 验收

PS:测试环境验收不通过,不能上线

5、A/B 实验测试需要加入到迭代版本计划中

【问题】

1.实验字段说明,哪个场景传什么内容

2.上传加密串暂时无法解密,无法确认上传数据是否正确

四、测试实施方案

1、埋点测试
A、需求文档标注检查参数和字段说明(数据敏感已过滤,需求文档要明确各个字段是什么意思,上报什么内容)

B、编写检查测试 sql,根据测试时间段和触发条件

测试 sql 语句示例

--  xxx页,进入页面时 上报商品id"
SELECT page_id,event_xxx,goods_id AS "上报商品id" ,time

FROM EVENTS

WHERE DATE<='2020-07-17' AND page_id=10xxxx AND event_xxx='pagexxxxxx'  

ORDER BY TIME DESC LIMIT 10;

--  xxxx页,点击时,click_xxxx,上报商品名"

SELECT page_id,event_xxx,goods_id AS "上报商品id",goods_name AS "上报商品名",time

FROM EVENTS

WHERE DATE<='2020-07-17' AND page_id=10xxxx AND event_xxx='click'

ORDER BY TIME DESC LIMIT 10;

C、根据埋点文档,操作对应测试流程步骤(埋点上报有时间延迟,1 分钟左右)

D、进入神策系统(测试环境需要添加本地 hosts 配置,参考 wiki 文档:测试环境和预览环境 Hosts 说明)

分析--》自定义查询–》查询结果

验证查询 sql 数据是否与测试结果一致,如果一致,则证明埋点上报正常,如果数据不对,埋点上报则有问题。注意:上报延迟时间

2、A/B 实验测试

A、需求文档需要标明 AB 实验页面、实验 id 相关的字段说明,及上报节点

例如:实验--》新用户,上报数据,某页面弹窗

实验 B--》新用户,上报数据,不弹窗

实验 C--》新用户,上报数据,不弹窗

B、研发确认上报接口参数

验证接口


1、冷启动检查点,确认对应环境下是AB实验哪个组,返回接口:
HTTPS://xxxxxxg?group_id=100&XXXXXXXXXX
响应参数:dynamxxxxxx 里面包含所有已经添加实验的页面key
settings
xxxxx_id=桶号
urlMap:获取动态参数(作为上报参数数据)
2、抓包工具返回报文有带 _md_data这部分内容,都是AB实验

C、测试步骤:

进入到首页:

打开开发者模式,切换服务器

切换桶号,重新启动

通过 fiddler 抓包:

ctrl+f 查找 _md_data 字段,把所有包含字段的接口都过滤出来

A/B 实验返回报文验证

首页上报AB实验格式
    _md_data
        event=ab_event
        event_content
            bucket_content=[{"test_id":10xxxx,"bucket_id":31},{"test_id":10xxxx,"bucket_id":87},{"test_id":10xxxx,"bucket_id":39}]
            channel_id=1
            event_type=ab
            page_id=10xxxx
            test_name=[{"test_id":10xxxx,"group":"E"},{"test_id":10xxxx,"group":"C"},{"test_id":10xxxx,"group":"B"},{"test_id":10xxxx,"group":"A"}]

具体业务场景上报AB实验数据格式:
    _md_data
        event=ab_event
        event_content
            event_type=ab
            page_id=10xxxx
            test_content=[{"test_id":10xxxx,"group":"E"}]


 _md_data 返回null,则未实验数据未上报

通过连接数据库,查看对应实验 id 包含的桶号:

检查神策上报数据接口,http:/xxxxxxx.sa?project=dafault

D、进入神策系统(测试环境需要添加本地 hosts 配置,参考 wiki 文档:测试环境和预览环境 Hosts 说明) (AB 测试数据上报有时间延迟,1 分钟左右,最大延迟上报 2 分钟)

分析--》自定义查询–》验证 A/B 测试数据是否正常上报

验证查询 sql 数据是否与测试结果一致(事件属性说明,可以参考:神策埋点属性说明),如果一致,则证明 A/B 测试上报正常,如果数据不对,A/B 测试上报则有问题。注意:上报延迟时间

注意事项:1、关键上报事项 event= 'ab_event'

2、test_name或者test_content,必有一个字段有值,若两个字段都为空,则说明数据上报异常

3、test_name和test_content上报数据保持一致,如:test_name 上报 A实验,test_content 上报 也是A实验,如果test_name和test_content上报数据不一致,则A/B实验数据上报异常

A/B 测试验证 sql

select "$os","$app_version",zlj_device_id,
distinct_id, -- 登录取user_id,没登录取设备id
"$device_id", -- 没登录取版本号,登录之后取设备版本
test_name,
test_content,
group_id, -- 匹配关系的桶号字段
"$lib",channel_id,event,event_xxxxx,time,page_id,page_xxxx,
operation_xxxx, -- 操作模块
operation_xxxx, -- 操作区域
operation_xxxx --区域索引
from events
where date='2020-08-12'
-- and event= 'ab_event'
and time >='2020-08-12 00:01:11'
and zlj_device_id = '66155xxxxxxxxxxxxxxB9A' -- 抓包获取设备id x_device_id
order by zlj_device_id,time desc -- limit 20;

3、AB 问题验证流程

五、AB 测试注意事项

1、后端返回格式(首次接触 AB 的开发容易出现返回格式错误问题)
注意:实验开启情况下,后端未返回数据,检查鹰眼配置是否有误

实验开启情况下,后端有返回数据,但仍查不到数据上报,优先检查后端返回数据格式是否正确

2、上报时机

1)明确产品文档规定的上报时机(若产品文档未明确,需及时与产品沟通补充文档):

2)进入页面即上报时:

注意上报顺序,先上报 enter_page 事件再上报 AB

3)实验组在实验页面需要满足某种条件才上报时(测试前同产品及大数据确认对应场景):

验证满足条件时后端正确上报 AB(接口及神策数据体现)

验证不满足条件时后端不上报 AB(接口及神策数据体现)

4)业务接口会在实验页面有多个操作下触发时:

提前与大数据验收人员确认,多时机触发是否会影响数据准确性

5) 需求存在后端相关埋点时:

与大数据确认具体上报字段,如何验收,避免漏测

3、上报路径
根据产品文档,操作对应流程,检查上报

检查 Android 和 iOS 相同操作下,业务接口请求顺序及 AB 上报是否一致,若不一致及时与产品及大数据沟通

检查常规路径,尤其是提交订单、购买相关埋点上报:商城提交订单

埋点上报脚本

埋点上报路径(为业务主要流程,其它区域显示埋点根据实际情况有则上报,没有则不上报)

4、版本隔离
需要验证高版本正常上报 AB

需要验证低版本对应场景不上报 AB


关注我们,更多精彩内容陪伴你


↙↙↙阅读原文可查看相关链接,并与作者交流