接口自动化断言该追「绝对确定」还是「合理容忍」？聊聊非确定性用例的取舍

背景 做了 5 年测试开发，最近盘一套 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7 + httpx，约 800 条用例），一个反复出现的痛点不是「断言写错」，而是「断言写多严」的尺度问题。举几个真实例子：一是分页列表断言，有人逐字段全量比对（连 created_at 毫秒、trace_id、耗时字段都断言），也有人只断言核心业务字段；二是金额类接口，有人断言分位精度，有人因为下游汇率服务波动只断言到元；三是并发场景下「先调 A 再调 B」的时序断言，跑本地稳、上 CI 偶发挂，重试三次才过，团队里有人主张加 sleep 等稳定，有人主张改成轮询最终态。

我踩过的坑：曾经把一条列表断言写得极严，结果下游一次字段重命名（新增可空字段）让 60 条用例集体变红，排查一上午才发现是断言过敏而非逻辑错；反过来，有一条订单状态断言只写了「不为空」，线上一次真正的状态机 bug 它居然全绿放过。两边都翻过车，所以这个问题不是「严格 vs 宽松」二选一，而是「哪些维度必须严格、哪些维度应该容忍、容忍的边界谁来定」。

常见的几种做法

1. 全量快照断言（snapshot testing）：快、覆盖广，但对非业务字段敏感，误报率高，维护成本随用例数指数上涨；
2. 白名单断言：只断言业务关键字段，稳定但容易漏掉「字段消失 / 类型变更」这类回归；
3. 分场景分级：P0 链路核心字段全断言，P1/P2 只断言状态码 + 关键字段，CI 上跑分级不同；
4. 引入「容忍断言」：对时间、顺序、数值范围用区间断言或软断言（soft assertion），把非确定性隔离出来。

我的倾向 我倾向「分级 + 隔离」：把断言拆成三层——状态码层（必须严格）、业务不变量层（金额、状态机、唯一性约束，必须严格且用不变量而非具体值）、易变字段层（trace、耗时、时间戳、排序，要么剔除要么区间断言）。关键是把「非确定性」显式建模，而不是靠 sleep 和重试去赌。理由：断言过敏和断言过弱本质是同一个错误——把「环境噪声」和「业务回归」混在同一层断言里，分开了才谈得上维护成本。

想听大家

1. 你们团队有没有一条明确的「断言分级规范」？是写在 wiki 还是直接落到代码约定（比如统一断言工具函数）？
2. 遇到「本地稳、CI 偶发挂」的时序用例，你们第一反应是 sleep、重试，还是改断言策略？踩过什么坑？
3. 金额 / 时间 / 排序这三类字段，你们分别怎么断言的？给个具体写法最好。
4. snapshot testing 你们用吗？在什么场景下值得，什么场景下是坑？ 欢迎贴你的踩坑案例，我这边把讨论整理成一篇避坑清单。