用例失败后重跑又通过，Agent 怎样整理偶发失败的调查材料

测试失败后重跑通过，应保留首次失败和重试观察，再判断是不是偶发问题。Agent适合把多次运行、配置和样本身份整理成矩阵，帮助测试人员选择下一步调查。不能因为最后一列是绿的，就把前面失败从报告中删掉。

把运行身份放在用例身份旁边

一个用例可以有很多次运行，每次可能使用不同浏览器、数据和版本。只按用例名聚合，会把不可比较的结果混在一起。表中至少保留用例、运行组、首次或重试、配置、数据标识、观察和时间顺序；重试是关系，不是覆盖上一条记录的新值。

官方机制说明1：Playwright区分首次通过、重试后通过flaky和持续失败；重试后通过不等于问题消除。

这是工具对运行表现的分类，不是原因诊断。重试后通过可能来自时序、数据或环境，具体原因需要证据；本文也不提供调高重试次数来掩盖问题的方案。

合成输入1。 同一用例首次失败、重试通过，配置与数据相同

预期处置：标重试后通过候选，保留首次失败

合成输入2。 第一次Firefox失败第二次Chrome通过

预期处置：标配置变化不可直接归flaky

合成输入3。 两次都失败但报错不同且测试数据被复用

预期处置：列样本污染疑点与受控重跑条件，不宣告产品无问题

第一条在同条件下先失败后通过，应保留两次并列，列为不稳定候选。第二条改了浏览器，不能将跨配置差异归成同条件偶发。第三条两次报错不同且复用了可变数据，需要查看数据准备和运行之间的影响，不能仅按最后报错分类。

矩阵可按配置和数据身份分组，让接手者看到哪些因素相同、哪些改变。没有数据版本信息时写未知，不把没有变化记录误读为完全相同。实际现象保留原文和证据位置，摘要只解释差异，不自动发明等待不足或服务波动。

对于重复使用可变业务对象的情形，下一步可以先审查夹具蓝图，确认每次运行是否真的从同一前置开始。某次失败已改变对象状态，后续通过可能验证了另一条路径。这里提出的是调查条件，不在真实环境重置对象，也不把重跑当作无副作用动作。

若报告只显示最终通过率，测试负责人会失去不稳定性的观察。可以把首次通过、重试后通过和持续失败分别汇总，但每类都能回到具体运行。样本很少时，几次现象只描述当前材料，不外推长期稳定概率。

本文合成三组输入没有真实平台日志，附件实际栏为空。拟定制助手的验收应检查它能否区分跨配置与同配置、保存首次证据、指出数据身份缺口，并给出受控再调查的问题。已有工具的flaky标签可以沿用，客户特有的业务对象与调查归口才是需要额外连接的部分。

附件G1用TC1、同一C1浏览器配置和D1数据，先提示超时，再取得通过候选观察；预期归为同条件间歇失败材料。G2用TC2和D2，但首次Firefox、第二次Chrome，预期先检查配置差异。G3两次引用DEV-DEMO，第一次失败后设备已借出，第二次报对象不可用，预期先审数据起点是否改变。

这张矩阵明确区分观察输入与本文实际执行。输入中的通过只是合成记录内容，工作表actual仍为空。读者可以逐行比较环境和数据，判断建议是否符合已知事实。只看最终结果，会把G1的不稳定、G2的配置差异和G3的数据污染压成相同标签。

复核人还应检查组内顺序是否完整。缺首次记录时只能说有一次重跑记录，无法证明先失败后通过；缺数据身份时也不能写同条件。交接材料应保留这些限定，让后续调查建立在可核对的运行事实上。

运行矩阵同时保留attempt和业务数据状态，使人员能检查所谓同条件是不是只指浏览器相同。对于G3，设备借出是已知合成状态变化，尚不能推断哪段代码造成变化；应先补准备和清理证据，再讨论产品原因。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。