夜雨聆风
软件测试 – 数据链路先测4个断点
有个报表事故我印象很深。页面没报错，接口也 200，AI 助手还根据报表给了运营建议。最后发现底层同步任务漏了一批退款订单，GMV 被高估。所有上层系统都很努力，只有数据是错的。
所以业务风险侦探不能只盯页面。越是 AI 和 Agent 多的系统，越要往下看数据链路。因为上层越智能，越会把底层错误包装得很像真的。
数据链路先测 4 个断点：采集、转换、延迟、回补。
01采集断点：有没有漏事实
采集层最怕漏。订单创建有了，取消没进；支付成功有了，退款失败没进；用户注册有了，注销没进。测试时不要只核对主事件，要把撤销、失败、补偿、重复事件一起放进去。
02转换断点：有没有改语义
ETL 或实时计算里，字段名没变，不代表语义没变。金额是含税还是不含税？时间是创建时间还是支付时间？会员等级取当前值还是当时值？这些语义一错，报表和模型都会被带偏。
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
03延迟和回补是线上风险
很多团队把延迟当性能问题，其实它是业务风险。风控晚 5 分钟，可能已经放过一批异常订单。库存回补晚 10 分钟，可能已经超卖。测试要问：延迟到多少会影响决策？回补后有没有二次通知？
数据断点清单
data_checks = {
‘capture’: [‘create’, ‘cancel’, ‘refund’],
‘transform’: [‘amount_semantics’, ‘time_semantics’],
‘delay’: [‘sla_minutes’],
‘repair’: [‘backfill_consistency’]
}
如果你们团队已经有 AI 报表、智能客服、运营助手，先别急着测问答多聪明。先把它吃进去的数据测明白。数据错了，越聪明越危险。
数据链路测不好，前端和 Agent 都只是在消费错答案。
下一篇讲工具选型：别先问买哪个 AI 测试平台，先问它能不能留下你要的证据。