产品BUG管理制度

 

 

产品BUG管理制度：

• 职责

1. 测试工程师：依据制度上报BUG,及时验证BUG是否解决，与研发人员沟通，反馈解决进展，关闭BUG;
2. 研发工程师：及时更新BUG解决进展；根据DEBUG计划尽快解决BUG,并通知测试工程师进行BUG验证；上报单元测试BUG，解决追踪；负责关闭单元测试和集成测试BUG;
3. 研发组长：及时审核研发工程师的bug解决进展，对产品质量改善进行风险评估；

• BUG状态：

1. 上报：新发现并提交的BUG
2. 分析中：BUG涉及的模块研发工程师，开始分析BUG信息
3. 延期解决：暂时不能按计划解决BUG
4. 已解决：已经实施修复BUG的解决方案
5. 已验证：对解决的BUG进行验证，未复现
6. 已关闭：已验证的BUG,持续下一个里程碑未复现，可将BUG状态改为已关闭
7. reopen:BUG解决方案中或系统验证中，重现BUG
8. 重复上报：确认为重复的BUG
9. 拒绝：经过评估不在产品需求定义范围内

• BUG现象归类

1. 需求不明确
2. 不符合产品需求
3. 不符合产品技术要求
4. 不符合集成技术需求
5. 不符合技术模块需求
6. 不符合辅助工装需求

• 严重程度S

严重程度S

分值	严重级别	状态描述	举例	设计参考	过程参考
10	S1致命	导致运行中断；预设功能未实现； 程序引起死机，退出，数据丢失，功能丧失，系统悬挂等错误 产品功能或者性能造成80%用户无法使用	程序异常退出，功能无法使用 严重花屏 内存泄漏 系统崩溃，死机，爆炸 程序或者模块无法正常启动或异常退出 数值计算错区，功能与需求不符合
8	S2严重	较大的功能缺陷，功能未实现或实现错误 严重影响系统要求，且没办法避免冲突 主功能丧失，致命的错误声明 用户可以使用，性能不稳定，经常服务中断	按键操作错误，失灵 非客户环境问题的网络不稳 功能和我需求不符，功能错误 数据通讯错误，计算错误，
6	S3一般	次要功能丧失，不严重，可变通解决 用户可使用，偶尔服务中断	按键偶尔失灵 边界值处理无效，界面显示问题 操作界面错误，提示信息错误 光标定位错误
4	S4较小	不影响主要功能， 用户交互性不好	字符串显示不统一 拼写对齐类错误 问题描述不清晰 区域划分不明确 错别字，文字排列
2	S5建议	功能不够方便	界面不太友好 操作不习惯 其他建议