北京
一个AI写的补丁，在默认顺序下跑通了整套测试。绿灯亮起，很多人到这一步就点了合并。但绿灯只证明了一件事：这套测试在某一个特定顺序下能过。它没有证明这些测试彼此独立。
这是两个完全不同的问题。前者问的是"补丁有没有跑通"，后者问的是"这套测试作为一个有状态的程序，会不会因为谁先跑谁后跑而改变结果"。机器写的补丁恰恰特别擅长扰动这种状态：新加一个模块级缓存、一个会改动共享数据行的 fixture、一个带副作用的 import、一个没被撤销的 monkeypatch，都可能让后面的测试莫名其妙地过或挂。
所以在信任一个机器补丁之前，值得先搞清楚：哪些测试能过，只是因为前面有别的测试先跑过了。
先确认顺序契约，再谈扫描
第一步不是急着打乱顺序，而是先跑两遍：一遍默认顺序，一遍固定种子但不启用任何 shuffle 插件。如果这两次结果就对不上，那说明存在 flaky 测试，不是顺序耦合，直接扫只会产出一堆噪声。
把基线记录成一组节点 ID 加结果，后面所有对比都拿它当参照。两次基线之间发生翻转的测试，先隔离掉。一个本身就不稳定的套件，做排列扫描无法归因——你分不清某个测试挂掉是因为前面的测试，还是因为它今天心情不好。
抽样跑种子排列，而不是穷举
400 个测试的排列组合多到跑不完，只能抽样。做法是：先收集全部节点 ID，用固定种子打乱顺序，再按这个顺序跑一遍，把每个测试的通过/失败记进矩阵。
这里有两个刻意的设计。一是把 PYTHONHASHSEED 跟着种子一起变，这样能顺带抓到依赖 set/dict 迭代顺序的问题；但代价是，一次失败可能来自哈希顺序而非前驱顺序，下一步必须把两者区分开。二是 junitxml 会篡改节点 ID，用之前得拿收集输出核对一遍映射关系。
报告里该给的是具体指标，不是一句"有点不稳定"：
- 耦合率 = 结果随种子变化的测试数 ÷ 收集到的测试总数
- 基线干净率 = 在默认顺序下能过的耦合测试占比（这些正是当前 CI 藏起来的问题）
- 最小化配对数量 = 归因之后剩下的不同"前驱→目标"边数
没算过的耦合率，就是一个你辩护不了的结论。
把失败压缩成最小前驱集合
一次失败的排列几乎说明不了什么——目标测试前面可能跑了 37 个测试。要做的是对前缀做增量调试：不断删掉前缀里的测试，直到再删任何一个都无法复现失败为止。
这个过程的复杂度是前缀长度的平方，但只对已经失败的测试跑，成本可以接受。产出通常小得离谱——一般就一两个测试——而这个小小的复现件，才是你附在补丁评审里的东西。
先分类，再动手修
最小化出来的配对是证据，不是诊断。分类时最容易被评审者跳过的一步是：在基线提交上跑同一套扫描，把两边的配对集合做差。耦合增量为零，说明补丁没有引入泄漏，只是让一个老问题浮出了水面——这依然值得知道，但不构成拒绝补丁的理由。
如果确实要冻结某些测试，边界得写死：冻结条目要写明最小化的前驱，而不只是那个测试；冻结要有硬性到期日；被冻结的测试仍然参与扫描，以便观察耦合是否扩散；冻结到期后挂掉的是构建，不是测试本身。一个没写前驱的冻结，本质上就是删测试换了个说法。
这套方法管不到的地方
它只能发现顺序耦合。最小配对集合为空，不代表补丁正确，只代表测试之间相互独立，还得配合 diff 覆盖率和断言强度检查一起看。
成本随套件时长线性放大：30 个排列乘以 12 分钟的套件，就是六小时。可以少抽几个种子，或者只扫补丁碰过的那些测试文件。
没有按测试隔离数据库的套件，几乎会把所有东西都报成耦合，先把隔离修好再谈扫描。做不出基线提交对比的，也别跑——否则每个历史遗留的泄漏都会被算到 AI 头上，评审一周内就会开始无视这道关卡。至于本身还没稳定下来的套件，同样先放一放。
起步建议很简单：拿五个种子，只扫补丁碰过的测试文件。如果最小配对集合非空，你手上就有了能摆上评审桌的具体材料——这比一句"看着没问题，测试都过了"要有分量得多。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
