一.缺陷(BUG)定义
1.未实现产品说明书中要求的功能和需求
2.未实现产品说明说中未提及,但应该实现的功能
3.出现了产品说明书中指明不应该出现的问题
4.出现了产品说明书中未提及功能(狗拿耗子,那么猫做什么?)
5.产品难以理解,不易使用,运行缓慢
二.一条缺陷(Bug)的基本字段
1.缺陷编号
2.缺陷标题
3.缺陷发现者
4.发现日期
5.所属模块
6.发现缺陷的版本
7.缺陷状态
8.指派给谁处理
9.优先级
10.严重程度
11.缺陷的描述
7.1缺陷状态
New(新的):bug提交到缺陷库中会自动的被设置成New状态
Assigned(已指派):当一个bug被认为New之后,将其分配开发人员,开发人员将确认这是否是一个bug,如果是,开发组的负责人就将这个bug指定给某位开发人员处理,并将bug的状态设定为“Assigned”
Open(已打开):开发人员开始处理bug时,他将这个bug的状态设置为“Open”,表示开发人员正在处理这个“bug”
Fixed(已修复):当开发人员进行处理(并认为已经解决)之后,他(她)就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人,然后开发组的负责人将这个bug返还给测试组
Rejected(被拒绝):测试组的负责人接到上述bug的时候,如果他(她)发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候,开发组负责人就将这个bug的状态设置为“Rejected”
Postponed(延期):有些时候,对于一些特殊的bug的测试需要搁置一段时间,事实上有很多原因可能导致这种情况的发生,比如无效的测试数据,一些特殊的无效的功能等等,在这种情况下,bug的状态就被设置为“Postponed”
Closed(已关闭):测试人员经过再次测试后确认bug已经被解决,将bug的状态设置为“Closed”
Reopen(再次打开):如经过再次测试发现bug仍然存在,测试人员将bug再次开发组,将bug的状态设置为“Reopen”
9.1优先级
1.高 对产品来说立即需要修复的
2.中 对产品来说优先需求修复的
3.一般 对产品来说需要修复的
4.低 对产品来说可以延缓修复的
10.1严重程度
A 致命的 系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机、或者危及人身安全
B 严重的 系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响
C 较重的 系统的次要功能没有完全实现。如:新增时主要信息已保存但次要信息未保存等
D 一般的 使用户操作不方便或感到麻烦,但不影响正常功能的执行。如:错别字、文字重叠、重复信息、没有提示信息、提示信息不友好等
E 轻微的 建议级别的缺陷,如不易使用、操作习惯不符合常规等
三.缺陷(Bug)的生命周期