缺陷提交管理规范Word文档格式.docx
- 文档编号:15946201
- 上传时间:2022-11-17
- 格式:DOCX
- 页数:7
- 大小:35.81KB
缺陷提交管理规范Word文档格式.docx
《缺陷提交管理规范Word文档格式.docx》由会员分享,可在线阅读,更多相关《缺陷提交管理规范Word文档格式.docx(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级以上优先处理。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 缺陷 提交 管理 规范