缺陷提交管理规范.docx
《缺陷提交管理规范.docx》由会员分享，可在线阅读，更多相关《缺陷提交管理规范.docx（7页珍藏版）》请在冰豆网上搜索。
缺陷提交管理规范
缺陷提交管理规范
编写说明
版本
编写
日期
修改说明
审核
缺陷提交管理规范1
目录2
一、概念3
二、目的及作用3
三、操作步骤4
四、三量标准5
五、检查、抽查5
六、缺陷级别定义6
七、缺陷管理工具7
八、注意事项7
九、组织纪律9
一、概念
缺陷管理是在软件生命周期中识别、管理、沟通任何缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失。
二、目的及作用
指导测试团队日常提交bug的规范说明，主要侧重缺陷流程各环节之间的控制，明确缺陷提交规则及各个状态测试团队应完成的工作。
三、操作步骤
1、开发经理：
对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：
需求、开发、测试共同确定）。
问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。
有可能是需求的问题，分配给需求人员。
2、测试经理：
审核测试人员提交的Bug。
定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。
编写测试计划、测试总结报告
3、开发人员：
分析Bug，写出问题原因，修改Bug后要在bug库中进行注释；实行Bug严重优先原则，1级以上优先处理。
4、测试人员：
提交Bug并验证Bug是否已被解决
四、三量标准
1、时量标准：
所有测试用例执行通过。
2、数量标准：
1）执行用例时，一条功能用例对应一个Bug，对于流程用例可对应多个Bug；
2）Bug验证通过关闭时要结束对应执行的测试用例。
3、质量标准：
1）每个Bug必须对应相关用例；
2）Bug数量统计；
3）Bug所属模块与严重程度
五、检查、抽查
1、问题描述一般格式：
问题描述时，建议分几步描述：
模块或功能点=>步骤=>期望=>结果=>其它信息，可依实际情况调整；
2、单一：
尽量一个报告只针对一个软件缺陷，报告形式应方便阅读。
在主报告之后应注明不同的条件；
3、简洁：
每个步骤的描述应尽可能简洁明了。
只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；
4、再现：
问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；
5、复杂的问题应附截图补充说明或直接通知指定的修改人；截图的文件格式建议用JPG或GIF。
6、报告中不允许使用抽象词句：
比如“有错误”之类；
7、有关操作系统/浏览器兼容性问题：
应在不同操作系统/浏览器上进行操作，看是否能重现，并在Bug报告中标识。
六、缺陷级别定义
严重级别
状态描述（从用户观点）
举例说明
Level1
不能执行正常基本流程，或者重要功能没有实现，使系统崩溃或资源严重不足。
无法正常使用系统的问题
1）由于系统所引起的死机
2）错误操作导致的程序中断
3）严重的计算错误
4）数据通讯错误，与数据库连接错误
5）功能与需求严重不符
6）重要功能未实现
7）由于产品功能或者性能造成80%以上用户无法使用的问题
8）低严重级别的错误，但是出现频度特别大，或者出现在使用者是角色权限级别较高的功能上
Level2
影响其他模块功能不能正常操作，导致一些流程无法进行
1）较大功能未实现或实现有错误
2）系统所提供的功能或服务受明显的影响
3）用户可以使用系统，但性能非常不稳定，经常出现服务中断
4）一般的数值计算错误
5）系统刷新错误
6）数据流错误 ，数据的准确性，一致性
7）程序接口错误
Level3
次要功能丧失，不太严重，可通过变通方案解决
1）边界值的处理无效，输入输出check
2）提示信息错误（包括未给出信息，信息提示错误等，无法给用户正确引导）
3）长时间操作无进度提示（程序代码未设等待时长）
4）系统未优化（性能问题）
5）快捷键操作
6）浏览器、系统、数据兼容性
Level4
易用性和建议性的功能，不影响使用的瑕疵，更好的实现方式
1）用户界面不太友好
2）使用不习惯
3）好的操作建议等
4）操作时未给用户提示
5）个别不影响产品理解的错别字
6）文字排列不整齐等一些小问题
7）拼写、对齐类的错误、UI图标、文字性错误
P1-致命
主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。
比如：
1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。
P2-严重
影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。
比如：
1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。
P3-一般
界面、性能缺陷。
比如：
1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。
P4-建议
易用性及建议性问题
比如：
1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。
七、缺陷管理工具
禅道Pro6.7.3
访问地址：
http:
//123.206.65.202:
8080/zentao
八、注意事项
1、Bug标题和内容描述要求分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）；
2、Bug中操作步骤与结果成对出现；
3、Bug严重程度和优先级定义严格按照如下标准：
1
错误导致了死机（“崩溃”）、系统挂起无法操作，如出现404，502页面等；
2
功能未实现或导致一个特性不能运行并且不可能有替代方案；
3
错误导致了一个特性不能运行但可有一个替代方案；
4
错误是表面化或微小的（提示信息不太准确友好、错别字、UI布局等），对功能几乎没有影响，产品及属性仍可使用等建议性问题；
附：
优秀的Bug报告应满足以下几方面的要求：
1）无歧义：
结构清晰，语言明确；
2）复测：
复现故障再写报告；
3）归纳：
是否其他模块也有相同的Bug；
4）比较：
其他测试用例是否使用到此Bug；
5）总结：
报告的开头有Bug的总结；
6）精简：
不要有多余的步骤和语言；
7）中立：
无批评性语言；
8）讨论：
将要发出的报告送其他测试人员讨论。
九、组织纪律
1、通过执行测试用例发现并提交Bug；
2、所有Bug必须全部提交禅道系统统一管理；
3、Bug从提交到关闭，提交人员必须全程跟踪解决；
4、修改和验证Bug后需要进行注释，按照Bug严重程度原则，2级以上优先处理。
升级会员 