接口与数据链路
从请求发出到落库，逐段对齐字段、时区和统计口径，确认页面上那个数字能一路追回它的来源。
个人主页 · 质量与可靠性
测试说是
把模糊的想法改写成能被验证的问题，再让结果开口。这里放我做完的实验、踩过的坑，以及那些被数据推翻过的判断。
01
关于我
我在一个小团队里负责数据产品的质量与可靠性，日常和接口、日志、定时任务打交道。工作里最难的部分往往不是把功能跑通，而是搞清楚它到底在什么条件下会不按预期运行。
写这个站点，是因为很多结论在聊天里说完就散了。把它们落成文字，能少走一遍弯路，也能在半年后回头确认当时的判断是否还站得住。
我偏好把话说小一点：能量化的就给出数字，不能量化的就标清楚那是猜测。名字取作「测试说是」，是想提醒自己别急着下结论——先让测试说话。
02
我在测什么
边界与异常
空值、超长输入、重复提交、超时重试。真正让系统出问题的，通常不是那条走得好好的主流程。
可复现的记录
每条结论都留下环境、时间、操作步骤和原始输出，让下一个人能照着跑一遍，而不是只听我说。
03
手记
-
2025.11.14
一次误报的复现路径
把「偶发失败」按请求阶段拆成三段之后，问题从偶发变成了必现——中间那次重试掩盖了超时。
-
2025.10.02
口径对齐比修缺陷更要紧
两个团队的同名报表差 3%，查到最后是统计时区不同。数字没错，是我们在说两件事。
-
2025.08.27
关于重试这件事
幂等没做好的时候，重试不是容错，只是把问题放大一倍，顺带把日志搅乱。
-
2025.06.09
用最笨的方式定位慢查询
先看日志里两行时间戳的差值，确认慢在哪一段，再决定要不要动索引。顺序反了会白忙一天。
-
2025.03.21
把用例当文档来写
命名比断言更能说明意图。半年后回头看，能读懂的是名字，不是那一串条件。
04
工作台
用到的东西不多，够用就好。下面这些是反复用到的组合，按场景排。
- 接口验证
- HTTP 客户端加一层断言脚本，先把响应结构和错误码固定下来，再谈业务逻辑。
- 数据核对
- SQL 加对账脚本，按天、按渠道拉差异，把不一致缩到某一天、某个字段。
- 日志排查
- 先对齐时间戳，再用关键字检索，把范围压到分钟级，然后才去看代码。
- 本地复现
- 容器里搭最小环境，把线上变量一个一个还原，直到本地也能稳定重现。
- 自动化
- 重复三次以上的操作就写成脚本，宁可贵一点，也别靠记忆。
05
联系
如果某篇手记对你正好有用，或者你正被同一类问题卡住，写信给我就好。看到会回，只是不一定快。我更愿意聊具体的细节，越具体越好。