把失败信息整理成缺陷报告

这个场景能帮你做什么

“功能不好用”无法让开发复现。WorkBuddy 可以把测试失败、日志和环境记录整理成缺陷草稿，标明还缺什么信息，把事实与根因假设分开。

开始前需要准备什么

提供用例名称、模块、预期与实际、错误信息、相关日志、系统与应用版本、操作记录、最近变更及历史通过失败情况。日志中的无关敏感内容先按企业要求处理。

具体怎么做

第一步：确认失败事实

核对测试预期是否来自有效需求，区分产品、测试脚本、环境和数据问题。不能仅凭断言失败就认定产品缺陷。

第二步：整理复现条件

按实际记录写前置、输入和操作步骤；未记录动作标缺失，不从日志想象用户点击。历史失败次数只说明观测，不能直接判定偶发测试。

第三步：起草报告

标题概括模块、现象与条件，正文列环境、步骤、预期、实际、证据和影响线索。根因候选注明支持与反证，不写成已定位。

第四步：人工确认再提交

让测试人员补缺、复现并确定严重程度。自动创建工单需要另外的系统权限，本流程先输出草稿。

可以直接交给 WorkBuddy 的完整要求

将附件失败信息整理成缺陷草稿，列模块/现象/条件、环境、前置、复现步骤、预期、实际和证据。
区分产品、用例、数据与环境疑点；未记录步骤不编。根因只作候选并附依据。
历史通过失败只陈述记录，不按固定失败率认定偶发。严重程度与影响标待人工确认，输出补充信息清单，不自动提交或关闭工单。

完成后会得到什么

一份开发能理解的缺陷草稿和缺失信息表，测试人员可以据此补齐复现。

结果应该怎么检查

照报告复现，回查环境、版本、时间和日志对应关系。确认预期未被 AI 擅改，候选原因没有出现在确定结论栏。

遇到这些情况怎么处理

无法复现时保留条件和历史记录。多次失败疑似同因时先关联，不直接合并关闭。缺日志时先补采，不用常见原因填满报告。

哪些必须人工决定

测试确认缺陷与严重程度，开发验证根因与修复。AI 负责整理，不替团队定责或确认修复完成。