文本
写好bug report的14个技巧
错误报告通常是测试人员和开发人员可能遇到争吵的原因。是的，争吵——你读对了！当然还有其他的原因，但 bug 报告绝对是其中之一，这是一个古老的传说
每个测试人员都必须编写 bug 报告，如果你的 bug 报告清晰、干净、准确，那么 bug 就不会被拒绝。然而，通常当测试人员记录开发人员拒绝的 bug 时，缺陷跟踪和 bug 拒绝就会变成一个永无止境的循环。我建议您阅读这篇文章，了解更多开发人员拒绝您的 Bug 报告的原因: 缺陷跟踪: 拒绝 Bug 的5个常见原因。
任何人都可以编写一个 bug 报告，但是为了编写一个好的 bug 报告，需要获得良好的分析技能和耐心。首先，确保其他测试团队成员没有报告与你相同的错误，否则，你将会产生重复的问题和不必要的缺陷循环。因此，一旦我们最终打开了一个 bug ——我们如何确保只用几个简单的步骤就能写出一个有效的 bug 报告呢？我们开始吧
问题 ID: 我们需要确保问题 ID 得到维护。如果您使用的是 bug 跟踪工具，那么它将创建自动生成的 id，并且不会生成重复的 id。
问题摘要: 这是 bug 报告中最重要的部分。问题摘要定义了 bug 的问题陈述。试着写一个简明扼要的总结，说明你的 bug 是什么。例如: 登录按钮在主页上不起作用。从这个总结中，开发团队将很容易理解问题的根源以及需要解决的问题。
问题描述: 在描述区域中，您需要提到帮助开发人员重新生成问题的步骤。例如: 应用程序的主页抛出了一个500内部服务器错误。复制步骤: 输入应用程序的 URL 添加客户登录 Id 和密码 浏览主页
根据上面的描述，开发团队/产品负责人/scrum Master 将理解，一旦使用了客户的登录凭证，主页将抛出一个500个内部服务器错误。尝试在描述中添加更多的细节，例如: 客户的登录 id/密码，因为可能存在其他角色权限，而且对于某些角色，它可能正在工作。也就是说，一定不要写得太长
预期/实际结果: 预期和实际结果可能是报告中需要提到的最重要的方面之一。每个人都应该知道你期望的结果是什么，而不是你得到的实际结果是什么。例如: 实际结果: 主页抛出一个500内部服务器错误 预期结果: 客户应该在申请的主页登陆
严重性/优先级: 严重性和优先级必须出现在错误报告中，因为它显示了错误的复杂程度以及需要解决的紧迫程度。例如: 我们可以从 P1-Blocker 定义优先级， 从 P2-Critical 到 P5-trivial，等等。 而我们可以将严重性定义如下: Blocker – 拦截-测试不能做，你被阻止使用的应用程序 Critical – 关键-应用程序崩溃，硬件问题等 Major – 主要-主要功能中断 Minor – 次要-次要功能性破坏 Trivial – 一些 UI 增强 根据 bug 的复杂性，您可以将上述因素添加到 bug 报告中。
平台/环境: 您的报告中提到的平台/环境表明您的 bug 可以在哪个环境中重现。很有可能您的 bug 可以在 QA 环境中重现，但是在其他更高级的环境(如 AUT 或 PROD)上却不能重现。
受托人/报告人: 如果您正在使用 bug 报告工具，它将自动以您的名字作为报告者。但是，如果您手动输入数据(例如在 excel 表中) ，那么您需要提到报告者，并且相应地需要根据团队结构将其分配给 Dev/PO。
屏幕截图/视频录制: 这是测试人员有史以来最好的武器。你必须为你正在报道的场景添加屏幕截图/视频。在 bug 报告中附加截图/视频是一个很好的实践，因为它可以作为一个证据，如果 bug 在目前的情况下不可重现，但是在一段时间以前测试了该特性之后可以重现。如果您可以轻松地捕获并使用环境日志，那么您还可以附加它。例如: API 日志、 UI 日志等。
状态: 状态是我们可以了解 bug 当前状态的东西，例如: ‘ New’。后来，这些问题通过各种状态，如修复，验证，重新打开，不会修复，等等。
组件: 这不是一个必需的部分，但是如果您提到了各种组件，那么您的团队将更容易过滤出到底是哪个组件在创建问题。如果您的应用程序不是很大，您也可以添加到报告中，无论它是否与 UI、 API、数据库等相关。
版本/发布: 请不要忘记提及在哪个版本/发布中检测到了 bug。它为测试人员、开发人员和整个团队提供指导。
固定版本/发布: 提及它固定在哪个版本总是一个好习惯，这样我们就能看到变化。它通常由开发人员/po 提到。
以下两个额外的提示，使你的错误报告最好 13. 在点击提交按钮之前阅读一遍所有的 bug 报告，确保上面的步骤1-12都包含在内 14. 确保你的错误报告不要显得粗鲁或辱骂。保持积极的语气和礼貌的态度。 总结 你的错误报告应该是一个高质量的文档，易于阅读，清晰和简洁，不应该提出任何额外的开放性问题，任何人通过阅读他们。一份好的 bug 报告一旦提交给开发人员，总会让您感到自信，并且还会与整个开发团队建立良好的关系
author
石头 磊哥 seven 随便叫
company
thoughtworks（离职了。。。。）
大家好，本人不才，目前依旧混迹于thoughtworks，做着一名看起来像全栈的QA，兴趣爱好前端，目前是thoughtworks 西安QA社区的leader，如果有兴趣分享话题，或者想加入tw，可以找我
roles
QA（营生） dev（front-end dev 兴趣爱好）
联系方式
如果想转载或者高薪挖我 请直接联系我 哈哈
wechat:
qileiwangnan
email:
qileilove@gmail.com
