软件的缺陷
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。
