一个好的缺陷报告应该具备以下几点：

1，  标题描述清晰，以最简洁最直接的方式描述缺陷内容，最好也可以包含缺陷产生位置和原因。

2，  指派给合适的人。几乎没有开发会去改一个不是自己负责部分的bug。

3，  主题内容简洁明了：bug步骤描述清晰，不一定傻子都能看得懂，但至少你离职了，你的同事能够看你的bug就接着干活。结果和期望尽可能少文字说明，多开发符号。

4，  附属内容完整。其中，严重程度（可能涉及开发kpi）、浏览器、环境配置、优先级，这几项最重要。除此以外的创建build，相关case及相关result信息，尽可能填写完整，在做缺陷分析的过程中很必要。

5，  适当补充备注：我感觉很少有人重视备注，但如果稍加利用，可以将一些暂时无法确定或者和bug不直接相关的信息放在备注，以作为提醒。

6，  尽可能避免无效和重复bug。无效bug的影响不言而喻，重复bug有时候和测试同学的习惯有关，发现了若干问题时如何合并或者分类提交，这个取决于对系统和合作者的了解。

7，  Bug周期过程的末期，关闭bug这个过程也很重要，修改的细节等都可以一一备注。

一个好的缺陷报告是一个联系开发与测试的桥梁，也是开发观察一个测试人员及其所在团队的镜子。

因此除了满足最基本的要求以外，好的缺陷报告要尽量避免理解困难而引起额外的沟通工作量，尽可能节约开发和测试的时间。

比如，将你在探索确认开发过程中所做过的努力以附件截图，视频，备注等形式写出来，节省开发的工作量，最终也就为测试节约了时间。

此外，每个项目中的缺陷报告最好保持风格一致，方便后人查看和学习。