一、简介

1. 背景

如果公司bug管理混乱，bug未划分优先级，将会导致许多优先级高的bug未能及时解决，同时研发部门会花费大量的时间处理非紧急bug，将会严重影响研发中心、产品中心、运营中心、商务中心的工作效率。

2. 影响范围

研发中心、产品中心、运营中心、商务中心。

二、软件缺陷分类标准

1. 缺陷类型定义

表2-1 缺陷类型定义表

2. 缺陷严重程度定义

Blocker:

阻碍了项目开发或者测试的继续进行

Critical:

1. 方案错误：
   数据字典、数据库、程序结构、流程上存在错误致使程序质量难以改善，导致日后的开发、维护、升级和扩展难度加大或造成难以弥补的局面。
2. 功能缺少或功能错误：
   存在需求分析的错误，即软件不能满足或不能实现用户实际需求的功能、或者与设计目标要求的功能不符，意味着项目的延期或需要投入更多的人力和资金进行重新开发。
3. 死机错误：
   程序在运行过程中存在宕机或死机现象，如：导致Windows的致命错误的蓝屏，系统出现的异常操作导致系统非正常退出（系统失败，其关闭的决定已超出编程者或测试人员的职权范围），系统与计算机硬件不兼容导致系统无法运行，或出现异常的操作被编程工具拦截但没有被编程处理。
4. 病毒错误：
   具有传染性，由于失灵，损坏其它系统（自身受损或不受损）。
5. 实时性错误：
   对于实时系统，系统响应时间慢，不能满足用户要求和实际使用情况。
6. 容量错误：
   用户数量不够(例如规定可以容纳用户为10个,但实际最多只能容纳5个等)。即未实现预期的设计容量目标
7. 账目错误：
   帐务数据、统计数据不正确，导致账目混乱，无法处理。

Major:

1. 系统不稳定：
   发生关键错误且致使系统无法操作，测试或使用无法继续进行。
2. 数据存取错误：
   数据操作存储错误，数据库内数据与实际数据不符合，数据没有被保存、修改、更新。（如：输入的数据没有保存到规定的地方，或对数据进行修改后，但数据库或文件中该数据并没有得到更新等）。
3. 系统恢复错误：
   恢复数据库或文件错误(用户在使用系统之前或使用中间系统出现异常的情况下，用户恢复系统过程中，对某些数据库或文件进行恢复, 但出现了不能进行恢复的现象)。
4. 稳定性错误：
   长期的、不可恢复的数据库损坏并且损坏不易发现。
5. 通讯错误：
   系统同外部通讯之间的错误（如：系统在网络正常情况下，不能跟其它机器进行网络数据传输通信或出现通信错误等）。
6. 数据一致性错误：
   即程序各模块之间联系产生的错误。（如：在调用其它模块是出现错误，或模块之间的传输的数据错误，比如有两个模块X和Y使用同一个数据库，其中X模块对数据库中的某些数据做了处理之后，需要到Y模块对数据做进一步的处理，但数据库的数据没有得到及时更新，导致Y模块操作的数据还是X模块处理前的数据）等。
7. 功能错误：
   拒绝处理合法的工作。
8. 查询错误：
   进行查询时,查询条件丢失；且有时附加条件(处理了不应处理的条件)、重复、重叠条件(出现条件重复现象：如一个条件显示两次)；有时还出现可怕的输出数据(输出了没有要求的不知道来源的数据)。
9. 文档错误：
   文档与软件不符、文档严重不足、系统文档关键错误
10. 计算错误：
    数值计算错误，或者处理数据算法错误；
11. 性能错误：
    系统性能变差或响应时间变慢(不必要的重复操作占系统资源)。
12. 其他测试人员认为不可接受严重的缺陷；

Normal:

1. 操作中间结果出错但不影响程序运行的最终结果。 正确地实现了功能,但与其他功能存在功能重叠交互现象。
2. 规定的资源空间不够(规定的系统运行环境和需求资源不能满足条件,例如主存不够,磁盘空间不够)。
3. 操作界面、报表数据出现的个别错误、溢出、出现非预期结果。
4. 数据在系统各部分连接表达不一致；
5. 对输入的数据没有进行有效性/合法性检查，并给出错误的结果或导致死机。
6. 在规定参数上下边界的情况下，出现超过边界的数值也能进行操作的情况（如：规定输入0到5之间的数后进行操作，但是输入6或-1也能进行操作的情况
7. 界面出现了一些不必要的功能模块（使系统出错几率增大）。
8. 系统处理未优化导致操作繁琐、不必要的环节控制等
9. 程序非正常终止但可通过其它输入来避免。
10. 其他测试人员认为一般的缺陷。

Minor:

1. 拼写错误的输出、错误提示；
2. 扭曲的打印、报表中文字字体、格式排列不整齐。
3. 界面布局、界面风格错误、风格不一致（如：对话框设计不符合标准）
4. 信息含糊或用户使用不方便，如：输出提示存在异议用户被引入歧途且多余。
5. 在线说明帮助不准确、不完整；
6. 查询结果格式错误、系统查询操作不方便。

Trivial:

1. 测试人员认为对功能进行修改，会增加功能的易用性和用户友好性。
2. 测试人员认为对系统业务逻辑进行修改，会完善、改进系统的业务逻辑。
3. 测试人员认为对功能错误处理方式进行修改，会增加功能的可维护性。

Enhancement:

1. 系统发布后用户反馈的改进建议和意见

3. 缺陷解决优先级别定义

表2-2缺陷解决优先级定义表

4. 缺陷状态定义

表2-4缺陷状态定义表

三、软件缺陷处理流程

软件缺陷通常可称为BUG，BUG的处理流程图如下所示.

• Bug正常解决处理流程说明：

• Bug不解决处理流程说明：
操作步骤 Bug状态 责任人 负责工作项 注意事项
第1步 未确认 测试人员 创建问题，并把问题指给相应的开发负责人 精简语句，准确描述
第2步 不解决 开发人员 由于各种原因，开发不解决 更新bug状态为：不解决，备注说明不解决原因
第3步 确认不解决 测试人员 与产品或测试负责人确认是否同意不解决 同意不解决bug，bug状态为：确认不解决，备注说明产品同意不解决原因
• 无效Bug处理流程说明：

• 重复Bug处理流程说明：

• Bug重新打开处理流程说明：