收集一条高质量的Bug需要代码层次和硬件层次，硬件层比较好理解，比如app产生的，我们需要有时间、版本、机型、系统和内存容量等；代码层次就包含错误堆栈，日志和用户的数据。

如果你想要一款类似功能的缺陷管理工具，目前收费的有bugtags、bugly等等，还有全免费的bugout工具，都可以使用。

1.唯一性

一个bug代表一个问题，最好代表一类问题

2.可重复性

附加完整的复现步骤，让开发容易复现

3.完整性

提交的缺陷最好附加截图或者录屏或者日志，方便开发定位问题

4.一致性

提交的bug描述及所有信息要前后一致，不要引起歧义

.简洁性

高质量的Bug记录：

1) 通用UI要统一、准确
缺陷报告的UI要与测试的软件UI保持一致，便于查找定位。
2) 尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷，可以使缺陷修正者迅速定位一个缺陷，集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。
4) 不可重现的缺陷也要报告
首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现，若尽力之后仍不能重现，仍然要报告此缺陷，但在报告中要注明无法再现，缺陷出现的频率。
5) 明确指明缺陷类型
根据缺陷的现象，总结判断缺陷的类型。例如，即功能缺陷、界面缺陷、数据缺陷，合理化建议这是最常见的缺陷或缺陷类型，其他形式的缺陷或缺陷也从属于其中某种形式。
6) 明确指明缺陷严重等级和优先等级
时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决，小装饰性问题可能被当作高优先级。
7) 描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置
描述要准确反映缺陷的本质内容，简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷，包含缺陷发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。
8) 短行之间使用自动数字序号，使用相同的字体、字号、行间距
短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。
9) 每一个步骤尽量只记录一个操作
保证简洁、条理井然，容易重复操作步骤。
10) 确认步骤完整，准确，简短
保证快速准确的重复缺陷，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。
11) 根据缺陷，可选择是否进行图象捕捉
为了直观的观察缺陷或缺陷现象，通常需要附加缺陷或缺陷出现的界面，以图片的形式作为附件附着在记录的“附件”部分。
为了节省空间，又能真实反映缺陷或缺陷本质，可以捕捉缺陷或缺陷产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置，通常要求附加中文对照图。
 附加必要的特殊文档和个人建议和注解
如果打开某个特殊的文档而产生的缺陷或缺陷，则必须附加该文档，从而可以迅速再现缺陷或缺陷。有时，为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现，可以附加个人的修改建议或注解。
12) 检查拼写和语法缺陷
在提交每条缺陷或缺陷之前，检查拼写和语法，确保内容正确，正确的描述缺陷。
13) 尽量使用短语和短句，避免复杂句型句式
软件缺陷管理数据库的目的是便于定位缺陷，因此，要求客观的描述操作步骤，不需要修饰性的词汇和复杂的句型，增强可读性。
以上概括了报告测试缺陷的规范要求，随着软件的测试要求不同，测试者经过长期测试，积累了相应的测试经验，
将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习其他测试工程师的测试缺陷报告，结合自己以前的测试缺陷报告进行对比和思考，可以不断提高技巧。

1)有明确规定的虫号：

始终为每个bug报告分配一个唯一的编号。这反过来将帮助您识别错误记录。如果您正在使用任何自动错误报告工具，则每次报告错误时都会自动生成此唯一编号。

请注意您报告的每个bug的数量和简要描述。

2)可重复性：

如果您的错误是不可复制的，那么它将永远不会被修复。

您应该清楚地提到重现bug的步骤。不要假设或跳过任何复制步骤。一步描述的bug很容易复制和修复。

3)具体：

不要写关于这个问题的文章。

具体点，切中要害。试着用最少的词来概括这个问题，但要用一种有效的方法。不要将多个问题结合在一起，即使它们看起来是相似的。为每个问题写不同的报告。

有效的Bug报告

错误报告是软件测试的一个重要方面。一份有效的bug报告与开发团队进行了良好的沟通，避免了混乱或错误沟通。

一个好的bug报告应该是简明扼要没有遗漏关键点。任何不明确的情况都会导致误解，也会减缓开发过程。缺陷写入和报告是测试生命周期中最重要但却被忽略的领域之一。

好的写作对于错误的归档是非常重要的。测试人员应该记住的最重要的一点是不要用威严的语气在报告里。这破坏了士气，造成了一种不健康的工作关系。用暗示的语气。

别以为开发人员犯了一个错误，因此您可以使用严厉的话。在报告之前，同样重要的是检查是否报告了相同的bug。

重复的错误是测试周期中的一个负担。检查所有已知bug的清单。有时，开发人员可能已经知道了这个问题，并在以后的版本中忽略了这个问题。也可以使用Bugzilla这样的工具自动搜索重复的bug。但是，最好手动搜索任何重复的bug。

错误报告必须通信的导入信息是“怎么做？”和“在哪里？”报告应该清楚地回答测试是如何进行的，缺陷发生在哪里。读者应该很容易地复制错误，并找到错误所在。

记住编写错误报告的目的就是让开发人员可视化这个问题。他/她应该清楚地理解错误报告中的缺陷。请记住提供开发人员正在寻找的所有相关信息。

另外，请记住，bug报告将保留下来供以后使用，并且应该用所需的信息很好地编写。使用有意义的句子和简单的单词来描述你的虫子。不要使用令人费解的语句来浪费审阅者的时间。

将每个bug报告为一个单独的问题。在单个错误报告中出现多个问题时，除非所有问题都得到解决，否则无法关闭它。

所以最好是把问题分成不同的错误。这确保了每个bug都可以单独处理。一个写得很好的bug报告可以帮助开发人员在他们的终端复制bug。这也有助于他们诊断问题。

怎么报告臭虫？

使用以下简单的Bug报告模板：

这是一个简单的错误报告格式。根据您正在使用的bug报告工具，它可能会有所不同。如果您正在手动编写bug报告，那么需要特别提到一些字段，比如Bug编号，应该手动分配。

记者： 你的名字和电子邮件地址。

产品：你在哪种产品里发现了这个漏洞。

版本： 产品版本(如果有的话)。

构成部分：这些是产品的主要子模块。

平台：提到你发现这个错误的硬件平台。各种平台如“PC”、“MAC”、“HP”、“Sun”等。

操作系统： 提到所有你发现错误的操作系统。操作系统，如Windows，Linux，Unix，SunOS，MacOS。提到不同的操作系统版本，如Windows NT，Windows 2000，WindowsXP等，如果适用的话。

优先事项：什么时候应该修复bug？优先级通常从P1设置为P5。P1为“以最高优先级修复错误”，P5为“时间允许时的修正”。

严重程度：

这描述了bug的影响。

严重程度类型：

阻滞剂：没有进一步的测试工作可以做。

关键：应用程序崩溃，数据丢失。

专业：主要功能丧失。

未成年人：轻微的功能丧失。

琐碎的：一些UI增强。

增强：请求新特性或现有功能中的某些增强。

现状：