12.7 软件缺陷管理流程
案例12-7：软件缺陷管理流程。
1．定义
1.1 问题类型
Bug |
测试过程以及维护过程中发现影响系统运行的缺陷 |
New Feature |
对系统提出新功能 |
Task |
需要完成的任务 |
Improvement |
对现有问题的改进 |
1.2 目的
把缺陷分成不同等级的目的是为了方便错误的确认、控制以及避免将来不再发生错误，也为以后对缺陷分布密度进行统计提供依据。
1.3 适用范围
适用于所有软件产品的内部测试和外部测试。
1.4 软件缺陷分级
1.4.1 Bug分类
Blocker： （危急） |
阻碍其他工作正常进行，如系统无法登录 |
系统无法编译 |
|
Critical： （严重） |
基本功能没有完全实现，不能完全满足系统要求。系统崩溃或挂起导致系统不能继续运行，如普通用户登录后，菜单无法操作 |
操作造成严重影响，如操作造成系统死机、被测程序挂起、不响应、进程没有关闭等 |
|
操作造成数据库死锁 |
|
操作造成程序中发现死循环 |
|
操作造成重大安全隐患情况（如机密性数据的泄密） |
|
某一模块功能没有实现或者实现错误，影响系统使用，而这一模块又正是系统中的关键模块 |
|
操作造成系统性能慢，大多数用户对此无法接受 |
续表[J1]
Critical： （严重） |
程序运行过程中造成内存泄漏或者指针溢出 |
|
操作造成现有数据错误、丢失，且不可恢复的，或者系统宕机的危机 |
||
操作造成数据通信错误 |
||
Major： （一般） |
功能基本实现，但在特定情况下导致功能失败。如打印功能，在多用户同时打印时，功能发生错误 |
|
在经常使用的系统中运行正常，但是在特殊的操作系统、网卡等情况下无法使用 |
||
导致输出的数据错误（如数据内容出错、格式错误、无法打开等），如导出的面板图片无法打开 |
||
导致其他功能模块无法正常执行，如A、B两个模块，单独执行都可以，但是执行完A后，再执行B运行就发生错误 |
||
功能不完整或者功能实现不正确如功能要求增加、修改、删除，只有增加、删除功能，没有修改功能 |
||
导致数据最终操作结果错误，如由于运算错误，造成最后的结果不正确 |
||
界面错误对用户使用造成误导 |
||
界面链接错误或者链接到一个不存在的界面 |
||
实现的功能不符合需求或有遗漏 |
||
业务流程不正确 |
||
报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误） |
||
Minor： （次要） |
功能部分失败，对整体功能的实现基本不造成影响，如输入过长的字符串系统没有报错，但没有导致系统死机 |
|
系统出错，提示不正确或没有捕获系统出错信息，如邮编输入非数字字符，系统提示为输入系统调用接口错误 |
||
删除操作没有提示，所有的删除操作必须有提示 |
||
系统风格不一致，如必须填写字段，有的地方是红色的*，有的地方是黑色的* |
||
Minor： （次要） |
提示窗口文字未采用行业术语 |
|
打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误） |
||
可输入区域和只读区域没有明显的区分标志 |
||
滚动条无效 |
||
键盘支持不好，如在可输入多行的字段中，不支持回车换行；或对相同字段，在不同界面支持不同的快捷方式 |
||
界面不能及时刷新，影响功能实现 |
||
Trivial： （轻微） |
产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等 |
|
软件测试工程师的建议 |
||
1.4.2 缺陷分级打分标准
Blocker：5。
Critical：4。
Major：3。
Minor：2。
Trivial：1。
1.5 状态与解决
状态
Open |
问题提交有待确认 |
In progress |
问题在处理过程中，还没有确认 |
Resolved |
问题已经解决，但是没有经过问题提出者复测 |
Reopen |
问题复测失败，问题仍旧存在 |
Closed |
问题复测成功，问题被关闭 |
解决
Unresolved |
没有解决的问题 |
Fixed |
问题已经解决 |
Won’t fix |
没有办法解决的问题 |
Duplicate |
重复的问题 |
Incomplete |
问题描述不够完全（建议不使用，遇到这样的问题，开发工程师及时与软件测试工程师联系，软件测试工程师把问题书写清楚） |
Cannot Reproduce |
问题重现失败，没有足够的信息重现 |
Suspend |
目前版本不处理的缺陷 |
Temporarily Solution |
临时解决的缺陷 |
Reject |
非缺陷 |
2．送测与退测流程
如图12-28所示。
2.1 步骤描述
2.1.1 流程启动条件
（1）开发部门认为自己修改完毕，可以提交测试。
（2）软件测试部门认为产品可以进行软件测试（达到复测标准：Open、Reopen个数≈缺陷级别≤50），参见缺陷分级打分标准。
2.1.2 步骤
（1）如果是开发工程师提出软件测试申请，就转到步骤（6）。
（2）如果是软件测试工程师提出软件测试申请，就交给开发部门。
（3）开发部门考虑是否可以提交测试。
（4）如果不可以，流程结束。
（5）否则接受申请。
（6）开发工程师将代码check in（签入）到SVN中。
（7）软件测试工程师建立安装程序，在SVN中打上Tag（标记）。
图12-28 送测与退测流程
（8）软件测试工程师对新版本程序按照冒烟测试用例进行冒烟测试工作。
（9）软件测试工程师进行软件测试评估。
（10）如果符合退测标准，退回软件测试，流程结束。参见本文2.2节退测标准。
（11）否则进行软件测试工作。
Ø 先对上次软件测试的fixed的缺陷进行复测。
Ø 然后重点测试本版本的新功能。
Ø 最后根据版本号进行回归测试（如果不是里程碑版本，这步不可作）。
顾翔凡言：
不是好的工作会给你带来好的心情，而是好的心情会给你带来好的工作。
