自动化测试报红后，Agent 怎样区分待查产品问题与测试准备问题

自动化测试报红后，先判断失败发生在准备、操作还是断言阶段，通常比立即归咎产品更能推进处理。Agent可以读取脱敏报告和已有录迹摘要，整理最后成功动作、失败观察及缺失材料，再给出测试维护或产品复核的候选入口。它不凭报错文字宣布根因。

报告中的几个对象别混在一起

测试用例描述想验证什么，运行记录说明某次执行做过什么，夹具记录说明前置是否建好，trace提供动作和页面等观察。它们需要通过运行标识关联。将不同运行的截图与错误拼在一起，会产生并不存在的执行链，因此输入先固定同一次运行及其配置。

每个候选记录失败阶段、原错误、最后成功节点、预期依据和证据定位。没有打开页面就失败，不能写成页面提交功能失败；页面操作确实完成但数据与规则不同，也不能只交给测试脚本维护人员处理。

官方机制说明1：记录后的trace可查看动作、快照与网络等线索；此页不把任一异常直接确认为产品缺陷。；官方机制说明2：计划手工测试、用户验收、探索测试及反馈是不同测试活动，配置、运行与用例各有对象。

这些机制提供记录和查看测试材料的方式。本文方案只整理客户已取得的脱敏材料，没有抓取真实trace，也没有将文件上传外部查看服务。实际材料的访问位置仍按企业授权安排。

合成输入1。 fixture创建合成账号失败，业务页面从未打开

预期处置：列测试准备问题候选，不能判产品保存失败

合成输入2。 测试期望成功弹窗，trace显示按钮未找到，页面结构已改

预期处置：列定位器/需求变更待查，附最后动作

合成输入3。 页面按步骤提交，断言读到与获批规则不同的返回值

预期处置：列产品复核候选，保留输入与断言证据

第一例是fixture未完成，产品业务步骤根本没有执行。第二例需要检查选择器与页面结构是否对应，也可能是已批准的界面变更没有同步测试，当前只能列候选。第三例具备已确认规则和返回值差异，适合交产品复核，但仍应保留服务条件和数据来源，不能从断言失败一步跳到代码错误。

分诊包首页可写本次想验证的行为和实际到达阶段；后面按顺序放夹具摘要、动作、观察与断言。每段留原始定位，摘要不改写错误含义。缺一个前置对象时，应说明它影响哪项动作，而不是泛泛要求重跑。

报告还需把已知事实与调查问题分列。例如“按钮未找到”是观察，“按钮被改名”只是待核解释；“返回人数不符”是差异，“缓存过期”也不能凭空成为原因。这样的区分能让研发迅速复核证据，同时给测试维护明确的检查项。

候选可以同时指向两个窗口：产品确认页面变化，测试维护核定位方式。无需为了一个唯一责任人而隐藏证据不全。人工接受归口后，保留它依据的运行与规则，后续出现新材料时可以调整，不把最初建议写成不可更改结论。

验收这类助手可对照附件三条输入，检查它能否停止在正确阶段、列出可执行的补充问题，并保持实际结果空白。若原平台已经能显示失败阶段，定制价值更多在跨报告关联、业务解释和交接格式，不应贬低原工具后再重复实现同一屏幕。

附件R1明确业务页面未打开，补件指向账号种子；R2已经到动作阶段，补件指向当前页面结构与批准变更；R3到了断言阶段，补件是规则条款和原返回值。这些去向说明下一位人员要检查什么，不能统一替成请开发排查。

分诊审阅还可检查是否错误使用未发生的观察。R1不能附上一次别的运行的页面图来完善链条，R2不能将找不到按钮解释成提交被服务器拒绝。对证据没有覆盖的步骤保持空白，才能防止摘要把原本有限的报告扩成确定故障结论。

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