前言
由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误，也就是bug。因此需要一个方法来跟踪、分析和展示那些测试活动，避免偏离最小。这种方法称之为错误跟踪系统。它主要是有效的管理缺陷，实现以下作用：
1)减少由于缺陷报告不明确而被开发组驳回的情况；
2)加快缺陷的处理速度；
3)提高测试的可信度；
4)加强测试组与开发组在整个项目过程中的团队合作
Bug报告是测试的重点，无论是口头的还是书面的，都是测试最明显的结果。
报告的质量可能是决定测试人员可信度的最重要的因素，一份好的Bug报告不仅可以体现测试人员的专业度，还可以方便开发人员或其他相关人员快速获取Bug相关信息，有助于对Bug的重要程度进行评估和快速修复。
什么是Bug
通俗意义上讲，Bug就是影响产品正常使用或者友好使用，且对产品价值产生影响的缺陷。
Bug可以分为两种：正常Bug和增强需求型Bug。
正常的Bug指的是产品未能实现自身功能；而增强需求型Bug是当你认为需求本身应该改进或优化时产生的问题。
换句话说，“产品没有按照你的期望运行”是一个常见的Bug“，产品已经实现了你需求的功能，但是你觉得可以有更好的实现方式时，这就产生了增强需求型Bug。
举个例子：
假设有一个web应用，点击按钮无响应，那么这是一个正常Bug；
假如点击按钮有响应，但是按钮图标或形式你觉得可以更好时，这个时候你提出的Bug可以被称作增强需求型Bug。
什么是Bug报告
Bug报告是对可疑错误的描述。
最基本的Bug报告是这样的陈述:“我认为产品可能存在一些问题。”在现实生活中，这可以表现为简单地指着屏幕说:“哦，快看，那是个Bug。”
事实上，当你在为站在你身边的朋友进行测试时，你所需要做的就是让他们知道你的产品应该是什么、应该做什么。如果我们都是亲密的朋友，或者我们有相同的认识，那么Bug报告就会非常容易。
Bug报告可以是正式的或非正式的、书面的或口头的。即使是最简单的Bug报告，其基础也是具有以下四个元素：
01、描述你所感知到的问题
你在测试过程中遇到了什么问题，具体一点、说清楚一点。问问你自己，这是否是问题的根源，或者这是否是最终的问题，更或者是否有更大、更基本的问题存在。例如：你可以描述“我在点击这个按钮的时候无响应“。
02、你是如何遇到这个问题的
你所感知到的Bug该基于对产品本身的直接观察。详细说明你使用的步骤和数据。
例如：在什么步骤输入什么样的数据产生的这个Bug，这是一个偶现的Bug还是一个频发的Bug，你有截屏或视频吗，你使用的数据是什么，什么文件，你到底输入了什么?
03、为什么是一个问题
说明你识别问题的方法，可以是需求文档，也可以是一些标准规范等。
例如：问题现象与需求不一致——功能Bug，或问题出现时资源消耗过大——性能Bug。
04、为什么这是个重要的问题
你的客户可能需要知道：这是一个大Bug还是一个小Bug？你应该准备好说明Bug可能有多重要，而重要性与它被发现的可能性以及它发生时可能造成的损害程度有关。
例如：你可以描述“这是个严重Bug，等级为L1，因为这个Bug的出现导致系统卡死无法正常运行”。
Bug报告中的关键内容
以下是正式Bug报告中最常见的字段：
01、标题
描述Bug本质的简短总结：
长度不宜过长
一般来说，标题以不超过12个字为佳。
标题具有独特性
每个Bug标题都能与其他标题相区分。例如，不要写“产品崩溃”这种通用性标题。
02、描述
任何关于特定故障模式和行为的其他信息：
描述尽量保持简短
给出有关Bug的合理细节，但不要包含团队中每个人都肯定知道的信息。如果问题很明显，例如“公司名称在主页上拼错了”，那么你几乎不需要写描述。
描述尽量专业
不要在一个Bug报告中涉及多个问题。
非多个问题可能是产品中一个潜在故障的症状，否则应该将它们划分为不同的错误报告。这是因为开发人员很容易修复一个问题，而不小心忘记修复同一报告中列出的其他问题。
尽量描述重要的步骤
不要提供那些显而易见的步骤，例如:
1.连接到Internet；
2.启动浏览器。
描述你认为是Bug的原因
这意味着要说明你为什么认为这是一个Bug，除非这很明显。不要说“产品不应该崩溃”这样的模糊不清的蠢话。这种描述毫无意义。
可以添加一点你知道的Bug的解决方法。
03、版本
注意附上你测试的版本信息。
注意：如果同一个Bug在多个版本中出现，将该Bug链接到最重要的版本。
例如：Bug A在开发版本Develop V1和发布版本Release V2中同时出现，请在描述中版本信息写明Release V2。因为使用重要版本信息，可以极大地引起开发人员和管理人员对此Bug的关注。
04、环境
你测试的平台。例如：硬件、浏览器和操作系统等信息。
05、附件
能够帮助理解和分析Bug的一些日志、屏幕截图、录屏等。
除了上述基本字段之外，Bug跟踪系统（如jira）可能还有其他字段。它将自动填充ID、Reporter和Date Reported字段，以及状态、严重性和优先级等。
如何判定一个Bug的重要性
测试人员是判断Bug“有多大”的第一个人。对于负责任的测试人员来说，这是你工作中非常重要的一部分。
那么如何判定一个Bug的重要性呢？你可以参考这几个方面：
01、Bug出现的频率
在其他条件相同的情况下，一个经常被很多用户看到的Bug将变得更加重要。是否有很多不同类型的事件可以触发这个Bug？它是否极易受到触发事件的影响？当它出现的时候有多明显?
02、当它发生的时候会造成多大的损失
虽然对于哪些具体症状构成“更严重的损害”没有严格的规则，但请尝试可视化问题，然后考虑受影响的用户的重要性。
最重要的错误通常是那些阻碍项目本身的错误：就是所谓的阻塞错误，这些是妨碍你进行测试或者用户正常使用的Bug。
例如”软件崩溃不能正常使用“，此类现象的Bug可以称为最重要的Bug，其次是会对用户使用造成某些影响但不至于无法使用的Bug。
03、Bug具有潜在的其他风险
Bug可能特别重要，因为它意味着开发过程本身存在一个大问题，可能导致许多类似的Bug还没有被发现。
04、Bug会给产品带来什么样的负面影响
虽然一些Bug在客观上没有那么严重，例如：并没有阻碍产品的正常使用。但是，它会影响用户对产品的好感度和信任度，那么这个时候它也是一个严重Bug。
举个例子
以jira工具为例，报告一个并发请求导致系统崩溃的Bug。关键信息如下图1所示。
jira默认包含了版本、环境、优先级等信息供用户选择，因此在描述部分可以只关注于对Bug本身信息的描述，如：复现频率、复现步骤等。
在复现步骤中，采用了Given——When——Then的描述方式，可以使得描述更加简洁和具有逻辑性，推荐大家使用。
总结
本文主要是向大家介绍了在报告Bug时需要关注的一些重点和细节，希望能为大家带来帮助。
一份好的Bug报告，可以让我们测试人员显得更为专业，也可以缩短开发人员排查Bug和修复Bug的时间，幸福你我他。希望对大家有所启发~
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
