合理的bug流程管理有助于提高整个项目的效率与质量,首先我先介结一下BUG相关概念。
一、BUG分类
BUG 就是指系统存的各种缺陷,可以从很多角度对BUG进行分类。
1.从功能方面分,产生BUG的原因大体可以归结为以下四种:
A.重复的功能; B.多余的功能;
C.功能没有达到设计的要求; D.功能实现与设计要求不相符。
2、从易用性方面分,可以归结为三点:
A.界面不美观,控件排列、格式不统一,焦点控制不合理或不全面;
B.缺少帮助信息,或者帮助信息不完全;
C.功能操作复杂,提示信息不合理,易产生歧义。
3、从 安全性方面分,BUG可以划分为以下几类:
A.数据有效性检测不合理; B.重要数据在传输中没有加密;
C.缺少身份认证机制或认证不合理;D.数据产生缺乏随机性;
E.网络安全性:开放端口、服务; F.系统日志、审计。
4、从 可靠性方面分,BUG可划分为以下几类:
A.数据存贮的可靠性; B.业务处理的可靠性;
C.硬件可靠性:如打印机;D.应急处理措施;
E.数据备份、恢复。
5、从性能方面考虑,BUG可划分为三种:
A.并发量; B.吞吐量; C.响应时间。
6、从兼容性方面考虑,BUG有两种:
A.硬件兼容性; B.软件兼容性。
7、从可维护性方面考虑,可划分为两种原因:
A.可扩展性; B.方便升级。
二、Bug等级
BUG等级是根据BUG出现在系统中的严重程度来分的,主要定义如下5级:
1级——轻微的(Low):不影响正常使用,轻微、微小的问题,对功能几乎没有影响,产品及属性仍可使用,如有个错别字。修改优先级为低,该级别建议程序员修改。
2级——一般的(Medium):系统能够正常使用,但有潜在风险;系统业务受到轻微影响。如提示信息不完整。该级别需要程序员修改。
3级——较高的(High):系统次要功能无法实现;主要功能部分失效;系统业务受到影响;导致用户利益受到一定损失。该级别需求程序员修改。
4级——严重的(Very High):系统主要功能无法正常实现,系统业务受到严重影响;导致用户利益受到损失。该级别需要程序员修改。
5级——致命的(Fatal):系统重要功能无法正常使用,系统崩溃;系统设计存在重大隐患;导致用户利益受到重大损失。该级别需要程序员修改。
三、Bug状态
BUG状态标记BUG当前所处的状态,是用来处理BUG流程的主要参数,我们QC缺陷管理平台有以下一些状态:
新增(New):测试人员新发现的系统Bug;
打开(Open):测试人员通知开发人员需要修改的BUG;
修改(Modify):开发人员正在修改的BUG;
固定(Fixed):开发人员通知测试人员已修复的BUG;
跟踪(Trace):测试人员短时间内很难确定是否已经修复的BUG;
已关闭(Close):测试人员经回归测试后确定已修复的BUG;
已否决(Rejected):被开发人员否决了的BUG;
重新打开(Reopen):Bug未被修复,重新出现在新的测试版本中;
延迟修改(Wait):因为种种原因需要等待延期修复的Bug。
四、Bug优先级
1级——建议的:建议修改,对应bug等级为1级轻微的;
2级——一般的:需要修改,对应bug等级为2级一般的和3级较高的;
3级——高等的:重点修改,对应bug等级为4级严重的;
4级——紧急的:立即修改,对应bug等级为5级致命的。
五、BUG处理流程
1.测试人员添加BUG到QC平台,初始状态为新建,测试员会把状态置为‘打开’状态,通知开发人员修改;
2.开发人员双击自己负责的BUG,状态置为‘修改’,修改好BUG后在注释框内加以说明,填上修复日期,把缺陷状态置为‘固定’状态;
若开发人员觉得没必要改,就把状态置为‘已否决’;
3.测试人员看到固定状态的BUG会进行验收测试,通过后就把状态置为‘已关闭’状态;若验收不通过则状态置为“重新打开”。
4.对被置为‘已否决’状态的BUG,测试人员与开发人员协商后同意关闭,则置为‘已关闭’;若测试人员不同意关闭则提交到项目负责人处,由他来决定是否要修改;
若要修改,则把BUG状态置为‘重新打开’ ,然后开发人员继续修改;若不用再修改则置为‘已关闭’;若延期处理则置为‘延迟修改’。
5.到能够修改这个BUG的时候,开发人员再置为‘修改’,进行修复。