收益：
- 能够在人工智能的支持下将分散的观察结果转化为包含明确标题、确定性再现步骤、预期/实际结果和证据的报告
- 能够将“只使用我给出的信息，不杜撰”的规则强加给人工智能，并通过自己的控制保证再现性
- 能够区分严重性（技术影响）和优先级（业务紧迫性），并根据业务上下文给出最终标签
测试人员发现的错误只有被修复才有价值；修复它在很大程度上取决于错误报告的质量——以开发人员可以理解、重现和修复的方式记录缺陷的记录。写得不好的错误报告（“登录无法正常工作”）会使开发人员拖延数小时，导致来回通信，并且经常因“无法重现”而关闭。一份好的报告包括明确的步骤、预期和实际结果、背景信息和证据。人工智能 (AI) 非常擅长将分散的观察结果转化为专业的结构化报告。但核心警告也适用于此：人工智能无法弥补你看不到的步骤；可以用“看似合理”但不准确的猜测来填补缺失的信息。您的工作是确保报告的每一行都基于您实际观察到的内容。
剖析一份好的错误报告
一份有效的报告包括以下组成部分：
- 标题：简短、具体、可搜索。不是“有错误”； “购物车中商品超过 10 件时，无法点击‘结帐’按钮 (Chrome)”。
- 重现步骤：编号、从头开始可追溯、确定性。遵循这些步骤后，开发人员应该能够看到错误。
- 预期结果：根据验收标准应该发生什么。
- 实际结果：发生了什么（错误消息、屏幕、行为）。
- 环境：浏览器/设备、版本、环境（测试/实时）、用户角色、数据。
- 证据：屏幕截图、视频、日志、错误跟踪（堆栈跟踪）。
- 严重性和优先级：详细信息如下。
提示：在发送报告之前，询问“如果我将这些步骤交给其他人，他们可以在没有我帮助的情况下看到错误吗？”问。如果答案为“否”，则报告不完整。 AI可以让报告变得漂亮，但只有你才能保证可重复性。
暴力和优先：两个混淆的概念
严重性是错误的技术影响：系统崩溃、数据丢失还是拼写错误？优先级是需要修复的紧急程度；是关于业务影响。两者并不总是朝着同一方向发展：主页上拼写错误的公司名称严重程度较低，但优先级较高（声誉）。在极少数情况下，崩溃的严重程度可能很高，但优先级较低。当你进行观察时，人工智能可以帮助你做出区分；但最终的标签是由了解业务背景的你给出的。
暴力
例子
优先级
例子
关键（阻止者）
付款无法完成
紧急 (P1)
生活收入损失
高（专业）
报告给出的总计不正确
高 (P2)
即将发布的必备品
中等（轻微）
罕见的边缘情况错误
中（P3）
在计划好的冲刺中
低（琐碎）
按钮对齐已关闭
低（P4）
当有机会的时候
弱提示/强提示
弱：“报告此错误：付款不起作用。”
Strong：“将我的以下观察结果转换为标准错误报告格式：标题、重现步骤（编号）、预期结果、实际结果、环境、严重性和优先级建议（合理）。仅使用我提供的信息；弥补任何缺失的字段，标记“信息缺失：...”。观察结果：Chrome 120，测试环境，购物车中有 12 件商品，当我按“结帐”时没有任何反应，控制台中出现“未定义不是函数”错误，没有问题11 个产品。”
强大的提示功能；强加格式、“拟合”规则以及缺失信息的标记。这样，报告就会既准确又诚实。
重复错误检测
在大型团队中，相同的错误会一遍又一遍地报告。 AI 可以将您的新报告与现有的未解决错误进行比较，并标记潜在的重复项 - 这可以使您的错误跟踪系统（Jira、Azure DevOps、GitHub Issues）保持干净。但要注意：表面上看起来相似的两个错误可能有不同的根本原因；在关闭人工智能的“重复”建议之前，比较两份报告的重复制作步骤和环境。意外关闭的“重复”实际上是缺少一个单独的错误。
从错误追踪到根本原因：人工智能读取日志的力量
错误报告中最具技术性的部分通常是错误跟踪（堆栈跟踪 - 哪一行代码、哪个调用链触发了错误的详细信息）。又长又复杂的日志甚至会让开发人员感到疲倦。 AI 读取数百行日志，并在几秒钟内总结出最关键的行、可能的根本原因假设以及触发错误的代码点。这既缩短了报告，又为开发人员提供了一个直接的起点。
但请记住两个限制。首先，AI给出的根本原因是假设，而不是证据；开发人员不应在未经验证的情况下尝试修复此问题。其次，日志通常包含个人数据（电子邮件、用户 ID、会话令牌）；在将原木放在车辆上之前遮盖这些区域。一个好的做法是首先让 AI 说“列出此日志中需要屏蔽的字段”，然后分析清理后的日志。
提示：不要将整个日志粘贴到报告中，而是包含 AI 总结的最关键的 3-5 行以及完整日志的链接。这样报告就保持可读性，需要详细信息的开发人员可以访问完整的日志。
四个可复制模板
1）从观察到报告：
您的角色：高级 QA。将以下原始观察结果转换为标准错误报告：标题/复制步骤（编号）/预期/实际/环境/证据说明/严重性+优先级（合理）。规则：仅使用我提供的信息；将缺失字段标记为“缺失信息：...”观察结果：[原始注释]
2）再现性控制：
从从未见过该错误的开发人员的角度阅读此错误报告。按照步骤进行操作并标记不会产生错误的位置：不明确的步骤、缺少先决条件、缺少测试数据、跳过条件。告诉我应该为每个间隙添加哪些信息。报告：[粘贴报告]
3) 严重性/优先级顾问：
我描述了以下错误：[错误+业务上下文]。分别针对严重性（技术影响）和优先级（业务紧急性）提出建议和理由。解释为什么两者可能不同。我将做出最终决定。
4）日志/错误跟踪摘要：
检查下面的错误跟踪/日志。给我总结一下 (1) 根本原因假设，(2) 发生错误的可能代码点，(3) 要添加到报告中的 3 个最关键的行。屏蔽是否有个人数据。日志：[粘贴日志]
三个迷你箱子
案例 1——从“我无法生产”中解放出来。在一个团队中，30% 的错误因“无法重现”而被关闭。报告流程中添加了“再现性检查”模板；在发送每份报告之前，人工智能都会标记缺少的步骤和先决条件。三个月后，“无法生产”率从30%下降到8%。不同的是，步骤从一开始就是准确的。
案例 2——假步骤的危险。测试人员让人工智能写了一份不完整观察结果的报告； AI 添加了一个从未发生过的步骤，例如“用户从设置页面打开通知”。当开发人员按照该步骤操作时，他找不到错误并且浪费了时间。该团队强制执行“只使用我提供的信息，不要编造”的规则；消除了虚构的步骤。
情况 3 — 严重性/优先级区别。主页上的公司标语有一个拼写错误。测试人员会将其视为“低”； AI顾问提醒，技术暴力较低，但业务优先级较高（每个访问者收到的声誉元素）。该错误在同一天被修复，并带有“高优先级”标签。
常见错误
- 标题模糊。无法搜索的、非歧视性的标题，例如“不工作”。
- 缺少/跳过步骤。没有写出在你的上下文中显而易见的内容；开发商未能生产。
- 让AI来弥补吧。用“合理的估计”填写缺失的信息；错误的步骤。
- 没有写出预期的结果。只说“错”，却没有具体说明什么是对的。
- 混淆暴力和优先顺序。将两者误认为是一个标签；误判业务影响。
- 敏感数据为证据。在屏幕截图/日志中共享真实的个人数据，而不屏蔽它们。
综上所述
Bug 报告的价值在于，开发人员无需您的帮助即可重现并修复 Bug。人工智能非常擅长将分散的观察结果转化为专业的、结构化的报告；它组织标题、步骤、预期/实际结果、环境和证据，并就严重性和优先级之间的区别提供咨询。但人工智能可以弥补缺失的信息；执行“仅使用我提供的信息，标记缺失的”规则并保证您自己的可重复性。掩盖个人数据作为证据。
应用任务
采取您最近发现的错误，并使用“观察到报告”模式（使用“拟合”规则）将原始观察结果转换为报告。然后执行“再现性检查”并填补标记的空白。将报告交给同事，看看他是否可以在没有您帮助的情况下产生错误。最后，与“暴力/优先顾问”确定标签，并自行决定最终确定。记下人工智能在此过程中尝试弥补的任何信息。
清单
- [ ] 我的标题具体且可搜索。
- [ ] 重现步骤是从头开始、确定且完整的。
- [ ] 我分别写了预期结果和实际结果。
- [ ] 设置及证据信息完整；我屏蔽了个人数据。
- [ ]我对AI强加了“补上，标记缺失”的规则，并自己填补了空白。
- [ ] 我分别评估了严重性和优先级并做出了最终决定。