如何编写有效的缺陷报告

四、 缺陷报告的组成

分类:该问题所属的模块。

出现频率:包括“经常”、“有时”、“随机”、“无法重复”等。

严重度:包括“新特性”、“微不足道”、“文字错误”、“不合理或别扭”、“次要错误”、“严重错误”、“系统崩溃”、“系统死锁”。

优先权:“低”、“中”、“高”、“加急”、“特急”。需要根据该bug对后续程序测试的影响来选择。

选择平台:Bug的产生有时跟平台有关，有的bug并不是在所有平台下都会出现，所以需要记录下该测试环境的平台、操作系统、版本号等信息。

版本:本次测试产品的版本。

产品构建号:本次测试产品的产品构建号。

摘要:需要简单明了的说明在什么位置出现了什么样的错误信息。

说明:描述BUG的出处和BUG不合理的地方，需要准确反映错误的本质内容，要足够详细。

问题重现步骤说明:按照详细操作步骤可以重现BUG，以方便开发人员快速解决bug，或以后翻查起来更方便理解。注意，每一个步骤尽量只记录一个操作。

附加信息:对于该问题的一些补充，比如错误日志、期望结果或者期望什么时候完成修改等。

附件:针对文字难以表达的或界面方面的问题，可以使用截图补充，也可以在截图上搭配简单的文字加以说明。

五、 衡量缺陷报告的标准

• 用中性语言来陈述事实，不用幽默或情绪化的语言。
• 对bug的描述要准确、清晰。
• bug的位置描述清晰。
• bug易于重现。在提交bug时，应当尽量找到bug重现规律，当问题可重现时，才会便于开发人员更快速的查找和解决该问题。面对一些比较不易重现或者不易描述的缺陷时，可以现场演示给开发人员。如果无法找到重现规律，也应该记录下该bug，并描述清楚上次出现的具体场景，同时指明偶然性。
• 环境步骤等条件描述清晰。
•  具备充分证据(比如截图、日志等)来证明这个bug的存在。
• 摘要应该包含该缺陷的关键字以及清晰的描述了该缺陷的重要信息，并且便于从bug跟踪系统中查找和定位该缺陷。
• 每个缺陷报告仅报告一个错误，以便日后查找、修改、统计该缺陷。

缺陷报告作为测试人员和开发人员的交接说明，对修改软件缺陷的工作起到了描述和指示的作用，是软件可靠性提高的有力保障。内容简洁、科学、明确的缺陷报告，是沟通测试人员和开发人员的桥梁，所以，能否编写出高效的缺陷报告是衡量一个测试人员水平的条件，更是体现一个软件项目质量的可靠依据。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友