软件测试缺陷管理规范.docx
《软件测试缺陷管理规范.docx》由会员分享，可在线阅读，更多相关《软件测试缺陷管理规范.docx（7页珍藏版）》请在冰点文库上搜索。
目录
1背景 2
1.1推行目的 2
1.2适用范围 2
1.3术语定义 2
2缺陷分类标准 2
2.1缺陷类型 2
2.2缺陷严重程度 3
2.3缺陷优先级 3
2.4缺陷状态 3
2.5缺陷来源 4
2.6缺陷复现率 4
3缺陷提交规范 4
3.1缺陷所属 4
3.2缺陷标题 5
3.3缺陷内容 5
3.4缺陷指派 5
3.5缺陷类型 6
3.6缺陷严重程度和优先级 6
3.7缺陷来源 6
4缺陷管理规范 6
4.1缺陷所属管理 6
4.2缺陷时效化 6
4.3未关闭缺陷的处理 7
4.4非系统测试缺陷的处理 7
1背景
1.1推行目的
缺陷是产品与规定要求不相符的部分，会存在于软件产品的整个生命周期中，本文规范
软件测试过程中的出现的缺陷，通过测试活动及早发现软件系统中的缺陷，并确保缺陷被有效标识、跟踪、和修改，保证软件系统能够达到要求的质量。
1.2适用范围
本文档适用于公司项目研发以及项目运行过程中的缺陷管理。
1.3术语定义
名词
描述
软件缺陷
软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
严重程度
指缺陷引起的故障对软件产品的影响程度。
优先级
修复缺陷的紧急程度。
2缺陷分类标准
2.1缺陷类型
缺陷类型
说明
功能问题
影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。
并且设计文档需要正式的变更。
如指针循环，递归，功能等缺陷。
接口问题
与其他组件、模块或设备驱动程序、调动参数、控制块或参数列表相互影响的缺陷。
用户界面问题
人机交互特性：
屏幕格式，确认用户输入，功能有特性，页面排版等方面的缺陷。
性能问题
不满足系统可测量的属性值，如：
执行时间，事物处理速率等缺陷。
配置问题
由于配置库、变更管理或版本控制引起的错误。
安全问题
所存在安全方面的问题
兼容问题
软件之间不能正确的交互和共享信息。
设计缺陷
软件需求设计考虑不全。
其他
以上问题所不包含的问题
2.2缺陷严重程度
严重级别
对应缺陷
严重等级
说明
致命
P0
1、阻碍测试的bug和生产环境中影响主业务的问题。
2、系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机等问题。
严重
P1
1、功能未能实现的bug和生产环境中影响使用的问题。
2、产生错误的结果，导致系统不稳定运行时好时坏等。
一般
P2
1、功能虽实现、但存在一些瑕疵。
2、次要功能没有实现，但不影响用户正常使用。
轻微
P3
1、用户操作起来不方便或者麻烦，但是不影响功能的运行和结果。
2、有需要优化改进的地方。
2.3缺陷优先级
缺陷优先级
对应缺陷严重等级（大概率）
说明
非常紧急
P0
产品研发环节时效性要求：
上午提交的bug，当天解决；下午提交的bug，最晚第二天下班前解决
生产环境时效性要求：
当天解决
紧急
P1
产品研发环节时效性要求：
解决周期≤5天
生产环境时效性要求：
解决周期≤3天
高优先级
P2
产品研发环节时效性要求：
解决周期≤15天
如遇版本计划发版节点，需在正式定版前解决
一般优先级
P3
产品研发环节时效性要求：
解决周期≤20天
如遇版本计划发版节点，需在正式定版前解决
2.4缺陷状态
缺陷状态
说明
激活
测试人员提交新的缺陷到库。
确认/修复中
开发人员或者是其他人员已经收到缺陷，并在修复的过程中。
拒绝
拒绝“提交的缺陷”：
不需要修复或不是缺陷或缺陷已经被其他的软件测试人员发现。
已解决
已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证。
重新打开
经过测试人员验证，缺陷还存在，故激活缺陷为重新打开，开发人员需要再次修复。
设计如此
经开发人员、产品经理评估，缺陷的内容为设计如此，无需修复。
重复缺陷
经开发人员评估，此缺陷以存在于缺陷库中。
无法重现
按照缺陷内容中的操作步骤，无法重新缺陷。
延期处理
经过开发人员和项目经理评估，此缺陷当前暂不修复，延期修复。
关闭
开发已解决，经过测试人员回归验证顺利解决，由测试人员关闭缺陷。
2.5缺陷来源
缺陷来源
说明
系统测试
由测试人员进行的集成测试、系统测试、回归测试产生的缺陷。
UI还原度测试
由UI设计师进行的UI还原度测试发现的缺陷。
客户验收测试
由客户验收时发现的缺陷。
线上运行
软件已运行状态，再由用户、客户、体验人员发现的缺陷。
2.6缺陷复现率
缺陷复现率
说明
必现
100%复现
大概率
按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%—90%
小概率
按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30%—50%
极小概率
按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1%—5%
3缺陷提交规范
3.1缺陷所属
在提交缺陷时，需要严格按照缺陷所属的产品、项目、版本、模块进行填写，不能不进行填写，此举是为了在后续进行总结时进行缺陷分析。
3.2缺陷标题
注意：
在提交一条缺陷前，应检查缺陷库是否已经存在此缺陷，避免重复提交。
缺陷标题应该尽量简洁明了，以最少的文字描述出缺陷结果，标题应该避免长篇大论、文字过多，具体复现步骤和补充说明可以放在缺陷内容描述中。
必要时缺陷标题中可以加入约定好的标签信息，如模块、类别等。
以下为缺陷标题举例：
3.3缺陷内容
缺陷内容主要包括操作步骤、实际结果、预期结果。
操作步骤：
按照分步的方式描述复现缺陷的操作以及数据、环境等信息。
实际结果：
描述按照操作步骤得出的缺陷实际结果，必要时可以截图、录屏。
预期结果：
描述根据需求应该表现的预期结果。
以下为缺陷内容举例：
3.4缺陷指派
缺陷应按照约定正确指派给对应的负责人，可以是前端负责人、后端负责人、项目经理等，不能无指派人。
3.5缺陷类型
提交缺陷时，需要根据实际情况选择缺陷所属类型，类型说见“2.1缺陷类型”
3.6缺陷严重程度和优先级
提交缺陷时，需要根据实际情况选择缺陷的严重程度和优先级，严重程度划分标准见“2.2缺陷严重程度”，缺陷优先级见“2.3缺陷优先级”。
以“禅道”举例：
3.7缺陷来源
提交缺陷时，需要根据实际情况选择缺陷来源，来源说明见“2.5缺陷来源”：
4缺陷管理规范
4.1缺陷所属管理
在提交缺陷前，测试负责人应预先创建好提交缺陷时所需要的字段内容，包括项目、版本、模块等，并要求缺陷提交人在提交缺陷时严格按照实时进行内容选择或填写，做好缺陷的分类化。
4.2缺陷时效化
缺陷提交后，测试人员、项目经理、开发负责人需要注意缺陷的截止日期，督促修复人员需要在截止日期前进行缺陷的修复。
4.3未关闭缺陷的处理
对于设计如此、延期处理、无法重现等非关闭状态缺陷，需要由测试人员找产品经理和项目经理进行确认，得到确认不修复的结果后，再到缺陷备注中添加说明做好记录，以免在后续忘记处理结果。
对于确认后还是得出需要修复的缺陷，应及时重新打开，指派给对应的负责人进行修复处理。
4.4非系统测试缺陷的处理
对于非系统测试缺陷（即UI还原度测试缺陷、客户验收测试缺陷、用户线上使用缺陷），需要由测试人员经过复验后再确定是否提交至缺陷库。
因此，非系统测试缺陷应先指派给测试负责人（或者由其他方式收集后交由测试负责人），由测试负责人指派复验人员，复验后确认是缺陷才提交至缺陷库，复验后确认不是缺陷的则对情况进行说明并反馈给缺陷提出人。
升级会员 