Bug的分类

严重程度

　　是指Bug对软件质量的破坏程度，即此Bug的存在将对软件的功能和性能产生什么样的影响。　　　

　　A类—严重错误，包括以下各种错误：
　　　　1． 由于程序所引起的死机,非法退出
　　　　2． 死循环
　　　　3． 数据库发生死锁
　　　　4． 因错误操作导致的程序中断
　　　　5． 功能错误
　　　　6． 与数据库连接错误
　　　　7． 数据通讯错误

　　B类—较严重错误，包括以下各种错误：
　　　　1． 程序错误
　　　　2． 程序接口错误
　　　　3． 数据库的表、业务规则、缺省值未加完整性等约束条件

　　C类—一般性错误，包括以下各种错误：
　　　　1． 操作界面错误（包括数据窗口内列名定义、含义是否一致）
　　　　2． 打印内容、格式错误
　　　　3． 简单的输入限制未放在前台进行控制
　　　　4． 删除操作未给出提示
　　　　5． 数据库表中有过多的空字段

　　D类—较小错误，包括以下各种错误：
　　　　1． 界面不规范
　　　　2． 辅助说明描述不清楚
　　　　3． 输入输出不规范
　　　　4． 长操作未给用户提示
　　　　5． 提示窗口文字未采用行业术语
　　　　6． 可输入区域和只读区域没有明显的区分标志

 

优先级

　　表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

　　高：应该立即修复的Bug

　　中：在产品发布之前修复的Bug

　　低：时间允许该修改的，或可以暂时存在的Bug

 

#Tips：严重程度高，优先级一定高？

　　（1）如果某个严重的缺陷只在非常极端的条件下产生，则没有必要马上解决。严重程度高，优先级一定高？

　　（2）若修正一个缺陷，要修改软件的整体架构，可能产生更多缺陷，市场压力尽快发布。

#Tips：严重程度低，优先级不一定低？

　　例如软件名称或公司名称的拼写错误，随属于界面错误，不严重，但关系公司形象，必须尽快修正。

 

 

Bug的种类

　　 需求阶段的BUG

　　 分析、设计阶段的BUG

　　 实现阶段的BUG

　　 配置阶段的BUG

　　 短视将来的BUG

　　 静态文档的BUG

 

 

缺陷报告要素

　　1）缺陷编号（defect id）

　　2）缺陷标题（summary）

　　3）发现者/创建者（detected by）

　　4）日期（detected on date）        ps：及时，确认和评审

　　5）指派给谁（assigned to）           ps：测试人员→开发方负责人→具体的开发人员

　　6）功能模块（subject）

　　7）版本（deteccted in release）

　　8）状态（status）     ps:new.open,fixed,closed,rejected,reopen

　　9）严重程度（severty）      ps：urgent,[very high],high,medium,low

　　10）优先级（priority）    ps:建议，开发方可以修改

　　11）缺陷描述（description）   ps：将发现BUG的过程(步骤，数据),和测试结果记录下来，从而让开发人员能够重现该BUG（让开发人员看明白BUG）

 

#Tips：提交缺陷注意事项

　　（1）确保重现Bug。严重错误重复测试两次以上。

　　（2）用最少且最必要的步骤描述Bug。

　　（3）简介，准确，完整。尽量使用中性词语。

　　（4）一个Bug一个缺陷报告。--便于Bug分配，便于回归测试。

 

Bug的生命周期 

　　发现bug ==> 提交并指派bug ==> 确认并修复bug  ==> 验证bug ==> 关闭bug 

　　生命周期中缺陷状态：新建-->指派-->已解决-->待验-->关闭

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

---

 

#Tips：缺陷与Bug

　　Bug：指出了错误，影响用户继续使用

　　缺陷：指出现BUG又是指有缺点和瑕疵。它的出现会给用户在使用过程中对某些感觉和习惯上带来不便。但不影响使用。 

 

 

 

标签：ps,错误,管理,--,Bug,缺陷,BUG,软件测试
来源： https://www.cnblogs.com/phoenixy/p/16686104.html