作者 | 庄锦弟
一、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
