定义:缺陷就是软件的问题,最终表现为没有满足用户的需求。
一、哪些算软件缺陷?
- 软件未达到规格说明书表明的功能
- 软件出现了规格说明说中指明不会出现的错误。
- 软件功能超出了规格说明书指明的范围
- 软件未达到规格说明书虽未指明但应该达到的目标
- 软件测试人员或用户觉得不好
二、缺陷的表现形式
1.功能、特性没有实现或者部分实现
2.设计不合理,功能特性不明确,逻辑不清楚或存在矛盾
3.产品实际结果和期望结构不同
4没有达到规格说明要求的性能指标
5.运行出错、崩溃、中断、界面混乱
6.数据不正确、精度不够、不完整或格式步统一
7.用户不能接受的其它问题,如存取时间过长、界面不美观
8.硬件或软件存在其它问题
三、软件缺陷的状态
- 提交—测试人员提交了一个缺陷给程序员
- 打开—待处理
- 拒绝—程序员认为不是缺陷或者重复,就可以修改状态为拒绝
- 修复—程序员修复缺陷后提交的一个状态
- 关闭—测试人员经过回归测试后,认为此缺陷已经解决,将其关闭
- 推迟—可以放在后续版本解决的问题,但是要详细写出修复的日期或版本
四、软件缺陷的严重程度划分
- Low—表面性错误,如错别字
- Medium—影响一个相对独立功能、仅仅发生再特定条件上、与需求定义不一致、断断续续出问题
- High—功能点没有实现、不符合用户需求、导致数据丢失
- VeryHigh--频繁死机、大部分功能不能使用
- Critical—系统瘫痪、异常退出、死循环、严重的计算错误
五、软件测试的优先级
- Low—时间和资源允许的情况下修复
- Medium—不会延迟发布,会在以后修复
- High—会制约开发和测试的进行,需要在发布之前修复
- VeryHigh—影响系统,产生严重影响
- Urgent—导致系统几乎不可用
六、软件缺陷分类
- 系统缺陷
- 数据缺陷
- 数据库缺陷
- 接口缺陷
- 功能缺陷
- 安全性缺陷
- 兼容性缺陷
- 性能缺陷
- 界面缺陷
- 建议
七.缺陷报告注意事项
- 尽量保证缺陷可以重现
- 简洁、准确、完整
- 一个缺陷报告只写一个缺陷
八、缺陷书写规范
1、标题简洁、提供缺陷的本质信息即可
2、复现的步骤要详细,用数字编号
3、实际结果要描述清楚复现后的结果
4、列出期望结果
5、提供附件
6、提供严重性属性和其它公司需要填写的属性
注意:要避免一些常见错误
- 避免使用情绪化语言和强调标点符号
- 避免使用模糊的词语
- 避免使用自认为幽默的语言,直接描述问题即可
- 避免提交不不确定的缺陷;
九、缺陷跟踪
新提交的缺陷为“新建”状态,在确认有效之后变为“打开”状态,开发人员修改后变为“已修复”状态,此时测试人员需要回归测试,如果验证问题已解决,状态为“已解决”,如果问题依然存在,状态为“打开”;如果开发人员任务此缺陷可以延期修改,状态为“延期”;注意此时必须由项目相关人员讨论确定后,才可以延期处理,否则状态继续为“打开”
十、缺陷密度
每千行代码的缺陷数;
缺陷密度=1000*缺陷个数/代码行数