其他分享
首页 > 其他分享> > 【软件测试】缺陷管理

【软件测试】缺陷管理

作者:互联网

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