5、bug软件缺陷

bug要素

bug的表现形式

1、功能、特性没有实现或者部分实现
2、设计不合理、功能不明确、逻辑不清楚或存在矛盾
3、实际结果和期望结果不同
4、没有达到规格说明说要求的性能指标
5、运行出错、崩溃、中断、界面混乱
6、数据不正确、精度不够、不完整或格式不统一
7、用户不能接受的其它问题，如存取时间过长、界面不美观
8、硬件或软件存在其它问题

bug等级

1. Critical - 致命错误：即常规操作引起整个软件系统崩溃、死机、死循环、账号隐私数据泄露等。
2. VeryHigh - 频繁死机、大部分功能不能使用
3. High - 严重错误：重要的功能点实现不了，错误的波及面广，影响功能交互，外观难以接受的缺陷，如密码明文显示等
4. Medium - 影响一个独立的功能，仅仅在特定条件和需求定义不一致，断断续续的出现问题
5. Low - 小错误：不美观、用户流畅度不够、文字提示错误等

bug状态

NEW：所有提交到开发对接的问题状态为NEW，表示为未处理
OPEN：开发对接人初判为需流转问题，指定测试人员和开发人员，状态为OPEN。
REFUSE：开发对接人判断为不需要流转至下环节的问题，状态为REFUSE，并且填写原因
FIXED：开发人员完成修复，待测试，状态为FIXED
REOPEN：测似人员针对开发人员的修复结果测试部通过，状态为REOPEN
CLOSE：测试人员判断问题为需求或其他问题，需填写原因；
　　非代码类问题处理完成
　　BUG类问题，测试通过

bug分类

大概有以下种类缺陷
1、 系统缺陷
2、 数据缺陷
3、 数据库缺陷
4、 接口缺陷
5、 功能缺陷
6、 安全性缺陷
7、 兼容性缺陷
8、 性能缺陷
9、 界面缺陷

bug生命周期图

bug处理正常流程(不完整，完整的请看上图)大概为 ：

1. 发现疑似bug的问题后，进一步确认其是否为bug(一般会找开发人员和产品进行沟通)，如果是则提交bug到缺陷管理系统。
2. 指派给对应开发人员修复，并对其进行跟踪，实时关注bug的状态。
3. 待开发人员修复完成后，验证其bug是否被修复，如未被修复，则继续提交bug。
4. 在bug通过后，则再进行一次回归测试，验证该bug是否影响其他模块的功能。

返回软件测试目录