大家好，我是阿萨。今天讲述一个测试人员必须要掌握的技能。那就是报bug。你日常工作中会经常遇到开发人员找你复现问题吗？ 如果自己报的bug 经常被人找让你复现问题，那么你就要注意了，很可能你写的缺陷单不达标。
Bug的基本信息
在编写bug报告时，提取相关的细节并讲述整个故事是很重要的。正如最基本的故事有5w (who/what/when/where/why)一样，bug报告也必须包含它的关键元素。
以下是一些关于缺陷内容的基本信息:
1. 标题:你的标题必须简洁而有描述性(例如，X功能被破坏了vs. X功能在第一次用户体验时没有被触发)
2. 环境:说明故事背景;360度全方位描述相关信息(在测试期间，你使用的是什么浏览器/设备版本/操作系统?还有哪些值得注意的细节可以帮助描绘出准确的画面?)
3. 详细描述:生动地描述故事，不要遗漏任何重要的事实。也就是说，尽量不要包含任何可能偏离或分散读者注意力的无关细节(稍后会详细介绍)。
4. 期望与现实:当读者开始发现更多的信息，随着他们深入挖掘，变得更加专注于他们正在阅读的故事，他们开始在脑海中得出他们期望发生的与实际发生的之间的结论。
5. 注意你的措辞:讲故事时，用词、语言和术语的一致性很重要。写bug报告时，要注意用词
6. 产品术语——它是一个“正方形”、一个“按钮”还是一个“行动号召”?了解其中的区别，选择一个，并自始至终保持一致。从原始设计中寻找线索。
7. 语气——记住你的读者是谁，并牢记编写bug报告的目标是什么。它们不是什么:一个表达你对特定产品/特性的愤怒或沮丧的地方，或者为什么某些东西不能像预期的那样工作(是的，即使是Internet Explorer)
8. 补充图片或者视频:任何好的故事都包含有趣的东西，以一种有意义的、有用的方式来修饰它。使用的媒体示例:
截图——一图胜千言
屏幕记录-一段视频描绘了数千个
9. 控制台错误日志——暴露JavaScript错误
参考点——可能是你过去遇到的相关问题的猜测，希望为开发指出解决方案或至少类似的方法
Bug包含信息越多越好吗？
如果你没有包含足够的信息，你就有可能忽略对问题解决者有帮助的潜在的有价值的信息。但是，如果你提供了太多信息，你就有可能让问题解决者误入歧途，因为多余的信息会分散他们的注意力。随着时间的推移，必须学会包含适当数量的信息，这些信息将为那些解决错误的人提供有效地排除故障所需的信息。
如果你提供了太多的信息，包括无关的杂项细节，这可能会分散读者的注意力，使他们无法吸收关键数据点。这将延长调查和调试问题所需的时间。
另一方面：
如果你提供的信息太少，而没有包括关键信息，这可能会使开发人员很难把碎片放在一起，以达到根本原因和潜在的解决方案。这也会延长调查和调试的时间
一个好的bug需要明确的要求有哪些？
在编写bug报告时，始终记住最终读者可能不是你(除非你碰巧是团队中唯一的QA工程师)。很有可能，一个开发人员或多个/一个开发人员团队将收到并阅读这些信息。因此，你需要知道他们需要知道什么，包括适量的细节。
需要明确的点：
1. 关键问题是什么?
2. 关于这个问题的所有相关细节是什么?(有助于进一步调查的相关资料或细节)
3.这种情况还发生在哪里?(说明环境或场景，尽可能具体;相反的情况也有帮助——哪里没有发生这种情况?)
4. 预期的结果是什么?有时仅仅陈述问题是不够的。在上下文方面，概述预期的结果可以帮助描绘出更完整、更清晰的画面，帮助开发人员理解事物的行为方式。
记住KISS(keep it simple stupid)原则，记住当你试图尽可能简洁地传达你的关键信息时，少即是多。
当你结束bug报告过程时，为了最大化你的报告的实质内容，你需要考虑以下几个最终标准:
关键问题——确保读者可以很容易地理解并立即认识到手头的问题
背景信息——通过丰富的内容为读者提供足够的信息，以任何形式帮助你表达你的观点
预期结果——预测解决问题所需的下一步步骤
看完今天的内容，快来看看你会报bug不。
