缺陷报告怎么写

意义：开发人员和测试人员沟通的重要工具

1、缺陷编号（Defect ID）——提交缺陷的顺序
2、缺陷标题（summary） ——简明扼要的描述缺陷
3、缺陷的发现者（Defect by）–
4、发现缺陷的日期（Detected on data）—-当天
5、缺陷所属的模块（subject）————
测试哪个功能模块的时候发现的，开发者可以由此决定谁修改该bug
6、发现缺陷版本（Detected in release）
测试的是哪个版本
（测试是回归测试，自动化测试解决测试中回归的重复性工作）
7、指派给谁处理（Assigned to）
开发经理根据缺陷所在的模块，需再次指派具体的开发人员

8、缺陷的状态
缺陷此时所处的处理阶段或处理情况
（1）测试人员发现缺陷，提交缺陷报告，把缺陷的状态置为：new（新发现的bug）
（2）开发经理验证新提交的bug，如果是bug，把状态改为：open（打开的bug==开发组承认的bug==），指派给具体的开发人员解决；如果不是bug，把状态改为：rejected（开发组拒绝的bug）
（3）开发人员看到指派给自己解决的bug，进行bug修复，修改完后，把状态改为：fixed（已经修复的bug，可以反测的bug）
（4）测试人员对修复的bug进行返测，返测成功，把状态改为closed（关闭的缺陷，归档的bug）；如果返测不成功，把状态改为reopen（重新打开的bug）

说明：
以上的过程就是
（1、缺陷的处理流程
1提交—-2分配—–3处理—–4返测（1：0？5关闭，3处理）

new–open(开发组承认的bug)\rejected（拒绝的bug)
—fixed(测试员返测成功)\reopen(返测不成功)–closed
（2、一个缺陷的生命周期 :
new–open–fixed–closed

每一个等级到底包括哪些缺陷，最好在专门的文档中进行详细说明，
这样可以使开发和测试人员达成共识。

9、缺陷的严重程度（severity）
(1、)bug对软件的影响有多大
(2、)缺陷描述（程序员）
Urgent
1、造成系统死机、重启、崩溃的缺陷
2、程序员应该停止当前的开发任务，进行缺陷修复
Veryhigh
1、非常严重的缺陷
2、程序员在当前开发任务不是特别紧急的情况下，应该优先修复该缺陷。如果程序员当前开发任务较重要，在完成这个开发模块后，应该优先修复此缺陷。
High
1、大的缺陷
2、任务正常排队，但不要影响开发或测试进度
Medium
1、中等程度的缺陷
2、在程序员阶段性任务完成之后，进行缺陷的修复
Low
1、小的缺陷
2、适当考虑，尽量在发布之前修复

严重程度——-优先级——>Urgent、Veryhigh、High、Medium、Low
严重程度：Urgent
严重程度：Veryhigh
严重程度：High
严重程度：Medium
严重程度：Low

优先级：Urgent:——–立刻修改
优先级：Veryhigh：—–本版本修改
优先级：High：———下一个版本修改
优先级：Medium：——-发布之前修改
优先级：Low：———-允许在发布产品中存在
(缺陷的严重程度和优先级不是成正比关系
例：界面问题的严重程度一般比较低，但优先级可能最高—-立即修复
有些重大的功能问题解决不了，但不影响软件其他功能的使用，这时软件的优先级可能定义的比较低—-在发布之前解决)

10、缺陷描述
（
操作过程：
1、在“第一个数”文本框中输入：10
2、在“第二个数”文本框中输入：0
3、点击除法“/”按钮
4、在“错误提示对话框”中点击“确定”按钮
预期结果：“错误提示框”关闭，程序继续运行
实际结果：程序关闭
）

该文为借鉴csdn文章和书籍、视频总结而成，主要借鉴来源来自
———-《黑马教程》。
如果有错误，请指教

发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/192282.html原文链接：https://javaforall.net