软件测试缺陷管理

缺陷标准

1. 未达到需求说明书的功能
2. 实现了需求说明书之外的功能
3. 出现了需求说明书指明不该出现的错误
4. 未达到需求说明书虽未明确提及但是应该实现的目标（如：性能要求等）
5. 用户角度发现的各种与错误

出现缺陷的原因

1. 需求分析阶段：需求文档存在错误，需求描述不易理解，有歧义、错误等
2. 设计阶段：设计文档存在错误或缺陷
3. 编码阶段：程序代码出现错误
4. 运行阶段：软硬件系统本身故障导致软件缺陷

缺陷状态

• New：发现Bug，未经评审决定是否指定给开发人员进行修改
• Reject：不被认定为Bug，拒绝修改
• Open：确定是Bug并且认为需要对该Bug进行修改，将其指派给相应的开发人员进行修改
• Fixed：经开发人员修改过后的状态，需要测试人员进行回归测试
• Reopen：修改后经测试发现该Bug仍然存在，需要重新修改
• Closed：Bug修改完经测试通过回归测试后关闭该Bug
• Delay：认为该Bug暂时不需要修改或则暂时不能修改，需要延期处理

缺陷的严重程度

• 严重（s1）：主功能存在严重缺陷、应用模块无法启动、异常退出等
• 一般（s2）：影响系统功能或操作但是不会影响系统稳定性
• 微小（s3）：易用性、界面、兼容性存在缺陷
• 建议（s4）：建议性问题

缺陷优先级

• priority 0：24小时内解决
• priority 1：发布前必须修复
• priority 2：可以在下一个版本中修复