UML软件工程组织

 

 

BUG 参考标准
 
作者: 未知 来源: 网络转载
 

一、目的

对 BUG 概念、类型划分、 BUG 状态、 BUG 严重程度等内容进行定义和规范,以便进一步指导我们的测试工作。

二、概念

BUG :软件中存在的瑕疵,可能会导致系统失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷。

三、 BUG 的类型划分

  • 功能类

    A. 重复的功能

    B. 多余的功能

    C. 功能实现与设计要求不相符

    D. 功能使用性、方便性、易用性不够

  • 界面类

    A. 界面不美观

    B. 控件排列、格式不统一

    C. 焦点控制不合理或不全面

  • 数据处理类

    A. 数据有效性检测不合理

    B. 数据来源不正确

    C. 数据处理过程不正确

    D. 数据处理结果不正确

  • 流程类

    A. 流程控制不符和要求

    B. 流程实现不完整

  • 提示信息类

    A. 提示信息重复或出现时机不合理

    B. 提示信息格式不符和要求

    C. 提示框返回后焦点停留位置不合理

  • 建议类

    A. 功能性建议

    B. 操作建议

    C. 检校建议

    D. 说明建议

  • 性能类

    A. 并发量

    B. 数据量

    C. 压缩率

    D. 响应时间

  • 常识类

    A. 违背正常习俗习惯的,比如日期 / 节日等

  • 特殊类

    A. 不符合 OEM 版本或 DEMO 版本特殊要求的

四、 BUG 状态

已提交:测试员发现 BUG 后提交到 BUG 管理系统中的状态。(初始状态)

已修改:程序员在修改了 BUG 后提交到 BUG 管理系统中的状态。

不修改:程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对 BUG 不进行修改。其 BUG 的状态为不修改,需要说明理由。

延迟:根据目前项目进程或计划等情况,暂时延期的状态

待讨论:需要进行讨论后才能决定是否需要修改的 BUG 的状态。

已验证:已经解决的并经过测试员复测的 BUG 的状态。

关闭:完全解决了,只供以后备查的状态

重新打开:重新出现在新的版本中,重新打开以前关闭的 bug 状态

( 当然在 bug 工具中,可以自己定制适合项目的状态项目,比如废除,拒绝等 )

五、 BUG 的等级划分与优先级

1 、严重:死机,数据丢失,主要功能完全丧失,系统悬挂等错误。修改优先级为最高,该级别需要程序员立即修改。

2 、较高:主要功能丧失,导致严重的问题,或致命的错误声明。修改优先级为高,该级别需要程序员尽快修改。

3 、一般:次要功能丧失, 不太严重,如提示信息不太准确。修改优先级为中,该级别需要程序员修改。

4 、轻微:微小的问题,对功能几乎没有影响,产品及属性仍可使用,如有个错别字。修改优先级为低,该级别需要程序员修改或不修改。

六、 BUG 的优先级 (一般与 BUG 等级挂钩)

参考 1 、紧急、非常高、高、中等、低

参考 2 、下一个 build 版本 ,a 测试 ,b 测试 , 发布版本,最终发布版本

七、 BUG 记录内容

  • 编号
  • 标题
  • 项目模块
  • 测试阶段
  • 类型
  • 操作环境 ( 操作系统 ,IE 等软硬件环境 )
  • 严重程度(等级及优先级)
  • BUG 状态
  • 测试员
  • 程序员(解决者)
  • 解决方案
  • 解决日期
  • 测试日期
  • 详细描述(步骤、结果、期望、备注)
编号
  测试日期
 
标题
     
项目模块
  测试阶段
 
测试员
  操作环境
 
BUG 类型
  等级及优先级
 
详细描述
  • 步骤(操作、数据输入等)
  • 结果
  • 期望
  • 备注
程序员
  解决日期
 
解决方案
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号