软件的缺陷
1)软件缺陷的状态
- 提交 (缺陷刚刚提交到系统上)
- 拒绝 (程序员认为此问题不修改)
- 修复 (程序员修改了代码 又提交后的状态 测试人员必须进行回归测试)
- 关闭 (回归测试后 确认没有问题)
- 推迟 (此问题放在后续版本解决,经理开会决定)
2)软件缺陷分类—BUG分类
3)缺陷严重程度划分
1、非常严重的bug,只要影响了系统或者出现了严重的计算错误
2、严重的bug,功能点没有实现、数据丢失
3、一般性的bug,影响独立模块、断断续续的问题、特定条件才发生、与产品要求不一致
4、表面错误,建议性的问题
4)开发人员拒绝修改的缺陷
1,程序员无法重现或者现象难以捕捉
2,没有明确的报告以说明重现缺陷的步骤
3,程序员无法读懂的缺陷报告
4,用户很少使用或者不符合用户使用习惯的操作出错
5,由不受信任的测试人员提出
5)缺陷修改说明
1,不是所有缺陷都会修改
2,市场的压力使得产品最终发行有时间限制
3,测试人员错误理解或者不正确操作引出的缺陷(FAQ)
4,错误的修改影响的模块较多,带来的风险较大(遗留)
5,修改性价比太低
6,缺陷报告中提出的问题很难重现
6)缺陷修复优先级
1、 最低优先级 只要时间允许才去修复
2、 低优先级 不延迟发布,可以在后续来修复
3、 高优先级 影响其他开发或者测试工作的进行,必须在发布之前修复
注意:优先级和严重程度不是绝对的正比关系;
7)缺陷报告细节
1、 一个缺陷报告只能有一个缺陷的描述
2、 缺陷一定要保证可以复现
3、 复现缺陷的步骤要写清晰,一个编号写一个步骤(有些不重要的步骤可以整合)
4、 描述结果(bug产生的效果)和期望结果(希望程序员要如何改正)
5、 避免使用强调符号和俚语(家乡话),正常描述问题即可
6、 使用术语描述问题,不要使用“似乎、好像”等模糊词
8)缺陷密度
每千行代码出现的缺陷个数
一个29.6万行的源程序总共有145个缺陷,则缺陷密度为:
缺陷密度=1000*145/296000=0.49 个/KLOC。