缺陷报告组成

来自https://www.cnblogs.com/ningskyer/articles/7669097.html

1、缺陷编号defect id 
提交缺陷的顺序 
注意：在实际项目中一般采用缺陷管理工具可以生成编号，整个项目组统一编号 
2、缺陷标题summary
简明扼要的描述一下该bug 
3、缺陷的发现者detected by
一般就是自己 
4、发现缺陷的日期detected on date
一般就是当天 
5、缺陷所属的模块subject
在测试程序的哪个功能模块时发现的bug 
开发经理会根据bug所在的模块找到由谁解决该bug 
6、发现缺陷版本detected in release
在测试程序的哪个版本时发现的bug 
7、指派给谁处理assigned to 
测试人员指派给开发经理开发经理会根据该bug所在的模块再次指派给具体的开发人员进行解决bug 
8、缺陷的状态status
缺陷此时所处的情况或处理的阶段

• 测试人员发现bug提交缺陷报告给开发经理把缺陷的状态写成New——新提交
• 开发经理验证此bug如果是把缺陷状态改为Open——开发组承认的bug，并指派给开发人员进行bug修复，如果不是则把缺陷状态改为rejected——拒绝的bug
• 开发人员看到指派给自己的bug进行bug修复，修改完后把缺陷的状态改为Fixed——解决的bug、待返测的bug
• 测试人员对修复的bug进行返测，如果返测成功把缺陷的状态改为Closed——关闭的bug、归档的bug、返测成功的bug；如果返测失败把缺陷的状态改为Reopen——重新打开的bug

此过程称为缺陷的处理流程或者缺陷报告处理流程、缺陷的跟踪管理过程、缺陷的生命周期：
New-Open-Fixed-Closed 
9、缺陷的严重程度severity
表明该bug有多糟糕或者对软件影响的大小

• urgent——致命的、造成系统死机、崩溃的bug
• VeryHigh——非常严重的bug
• High——严重的bug
• Medium——中等程度的bug
• Low——小的bug

说明：在实际工作中每个单词代表的具体情况会有所不同。为了避免争议应该在相关文档中把每个级别的具体情形列举出来供
测试人员和开发人员参考，如Bug Level Definition.xls

10、缺陷的优先级priority

希望程序员什么时间内或在程序的哪个版本中解决该bug

• Urgent——立即修改否则影响测试/开发进度
• VeryHigh——本版本修改
• High——下版本修改
• Medium——发布之前修改
• Low——允许在发布中存在的bug

优先级制定时主要考虑因素

• 1严重程度—— 一般严重程度越高优先级越高
• 2影响范围—— 一般影响范围越广优先级越高
• 3参考开发组的当前任务压力——开发任务越轻优先级越高
• 4解决bug的成本——成本越低优先级越高

11、缺陷描述 
把发现缺陷的过程、步骤、使用的数据等记录下来使程序员通过该描述能够再现该bug

注意：
1、优先级和严重程度不是严格正比关系 
2、严重程度确定好后一般就不再更改而优先级确定好后可能经常修改一般会向后推延 
3、不是所有的bug在产品发布之前都能被修复，对于发布之前不修复的bug要通过缺陷讨论明确解决bug
的成本、时间以及该bug如果不解决给用户造成的影响、损失 
4、不可重再现的bug也叫做随机bug也要报告，但要说明该bug不可重现，如果可能可以对bug做截图

转载于:https://www.cnblogs.com/songqh-123/articles/8953513.html