一.缺陷常用字段说明
二.缺陷管理流程图
三.开发人员修改缺陷填写规范
四.项目经理决定延期修改缺陷
1.缺陷常用字段说明
1.摘要
对缺陷的简单描述。摘要包括该缺陷所属的模块名称-子模块名称,以及简单说明缺陷情况。
2.描述
详细描述重现该缺陷的步骤,错误现象和期待结果。必要时可以上传附件辅助说明。
3.状态
缺陷状态英文名称 | 缺陷状态中文名称 | 缺陷状态描述 | 备注 |
New | 新建 | 测试中提出报告缺陷,普通开发人员无权修改状态为“新建”的缺陷,只能修改状态为“打开”或者“重新打开”的缺陷。“新建”的缺陷需要项目经理确认并将状态置为“打开” | |
Open | 打开 | 被确认并分配给相关人员处理 | |
Fixed | 修复 | 开发人员已完成修正,等待测试人员验证 | |
Closed | 关闭 | 缺陷已被修复 | |
Reopen | 重新打开 | 缺陷未被修复 | |
Rejected | 否决 | 拒绝修改缺陷,该缺陷可能由于测试人员理解错误,或者项目经理认为不需要修改 | |
延期 | 延期 | 不在当前版本修复的错误,下一版本修复 | |
无法解决 | 无法解决 | 以目前的技术水平、经济因素或修改此缺陷的代价过大等原因而不能解决的缺陷 | |
Tester Agree | 测试同意 | 测试人员同意开发对缺陷做出的处理(这种处理可能是一种折衷的方法) | |
Duplicate | 重复 | 由于测试重叠工作或者不同测试人员重复提交等原因,出现相同描述的缺陷重复报告. | |
4.分配给
记录该缺陷分配给谁去修改。一般来说,登记时都是统一分配给项目经理,再由项目经理确认并分配给相关开发人员。
5.缺陷严重程度和优先级
缺陷严重级程度与优先级别原则上是有一一对应的关系,在填写缺陷选择这两项时,可先参照该对照表:
缺陷严重程度中文名称 | 缺陷严重程度描述 | 对应的缺陷优先级选项 | 缺陷优先级描述 |
5-紧急 | 阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷,例如: 1. 3. 4. 5. 6. 7. | 5-紧急 | 1 当缺陷所引发的问题没有达到紧急的级别,但当该缺陷出现后,影响到了后续的测试工作进行 2 客户无法容忍的页面,如页面上显示其他公司名称 3 当前操作方式与客户使用习惯背道而驰。 4 严重不合理,核心功能完全违反软件规范或业务规范,可能导致用户强烈的反感 5系统响应时间过长(例如WEB响应时间超过10s) 6模块提供的数据不合理,例如(查询“录入人”的下拉项提示为非用户名字段) 7负载测试、压力测试结果和用户需求不符 |
4-非常高 | 缺陷导致失去系统主要功能,基本功能不能完整使用例如: 1. 2. 3. 数据流错误 4. | 4-非常高 | 1 快捷方式不正确,如能够回车直接进入下一步的设计成了空格直接进入下一步 2 严重的逻辑错误 3常用操作平台不能正常使用功能(WIN XP/WIN 2000/WIN VISTA) 4常用浏览器不能正常使用(IE6.0/IE7.0/FireFox) 5超时限制的时间设置不合理 6未登录即可浏览页面 7给客户演示等过程中客户重点指出的,严重级别却不是很高的BUG,建议级别定义至少是非常高 |
3-高 | 操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现,例如: 1. 2. 3. 4. 5. | 3-非常高 | 1 提示信息不明确,并且非常容易误导用户做出错误操作或判断。 2 软件功能的实现过程中弹出未控制的系统错误提示,导致流程中断 3 Cookies没有正常保存 4服务器和客户端的脚本修改未被记录和 5非法操作等Urgent程度的bug,如果不具有普遍性而是在极端环境下出现,例如特定的操作环境。建议级别定义为High。 |
2-中 | 错别字、罕见故障等不影响执行工作或功能实现,例如: 1. 2. 3. | 2-中 | 1 提示信息不明确,不正确或不合理 2 界面设计存在缺陷、凌乱或不友好 3整体风格不统一 |
1-低 | 建议,不影响使用的瑕疵或更好的实现等 | 1-低 | 1 虽有不尽人意之处,但不影响用户操作或用户使用频率较低,并且不会造成错误 2 局部界面不够美观 |
0-建议 | 对软件各方面提出的更好的改进性的意见。 |
6.主题
记录该缺陷属于哪个模块中。主题字段设置对应为用户需求的各个模块\子模块下,方便将来统计各个模块的缺陷密度。
7.检测者
记录该缺陷的登记者,系统会自动获取当前用户的帐号,不需要手工录入。
8.检测日期
记录该缺陷的登记日期,通常系统会自动获取当前时间,不需要手工录入。
9.检测于版本
记录发现该缺陷软件版本号,测试负责人员在每次获取到新的测试程序包时,按照程序包上的版本标签号,在QC的自定义管理中版本号一栏增加对应的版本号(注:程序包的版本号与QC中增加的版本号一致)。
10.缺陷类型
记录缺陷的类型,暂时分为7类。
11.可重现
记录缺陷是否可重现。根据缺陷描述操作,是否可以发现缺陷所描述的问题,Y表示可以重现,N表示无法重现。例如有些问题是在特定条件下才出现的,当条件改变后问题随之消失,根据所描述的步骤操作,不会再出现缺陷所描述的问题,这类就是属于无法重现的缺陷。
12.项目
记录缺陷所属的项目。
2.缺陷管理流程图
3.开发人员修改缺陷填写规范
1、不论是简单还是复杂的缺陷,开发人员都要在修改了代码并确保代码提交到服务器后,再将缺陷状态由“打开”置为“修复”。
2、对于非常简单明了的缺陷(例如界面上的一个错别字),可以在注释中加简单的注释说明:(如:已修改)但对于复杂的缺陷,必须要注明以下几点:
3、如果缺陷是由于测试人员理解错误导致,或者开发人员认为不需要修改的,开发人员可以将缺陷状态设置为“否决”,但是必须在【注释】栏中填写拒绝修改的原因。
4、如果开发人员认为该缺陷与其他缺陷重复,也需要在【注释】栏中填写与之重复的缺陷ID,例如注释内容可以填写:与缺陷10重复。目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。
小提示:在新增注释说明时,可以直接点击页面右下方的(添加注释)按钮,QC可以直接添加你的登录帐号在“注释”中,省去自己填写的麻烦!如图12.请大家在填写时养成加入自己信息的习惯,方便测试人员在回归测试时可以看到是谁回复的,有问题方便直接沟通!
4.项目经理决定延期修改缺陷
1、项目经理决定延迟修改缺陷时,先在注释中写明延迟修改的原因,再将缺陷状态置为“延期”。
2、项目经理需填写如图13中蓝色框圈出的“计划关闭的版本号”和“估计修复时间”两项内容。(计划关闭的版本号可以是正式版本,如Beta_v1.0,也可以是计划在今后的一个候选版本中填写,如Beta_v1.0.RC12)。由于目前版本管理还不完善,该项暂时可以不填写。
一.缺陷常用字段说明
二.缺陷管理流程图
三.开发人员修改缺陷填写规范
四.项目经理决定延期修改缺陷
1.缺陷常用字段说明
1.摘要
对缺陷的简单描述。摘要包括该缺陷所属的模块名称-子模块名称,以及简单说明缺陷情况。
2.描述
详细描述重现该缺陷的步骤,错误现象和期待结果。必要时可以上传附件辅助说明。
3.状态
缺陷状态英文名称 | 缺陷状态中文名称 | 缺陷状态描述 | 备注 |
New | 新建 | 测试中提出报告缺陷,普通开发人员无权修改状态为“新建”的缺陷,只能修改状态为“打开”或者“重新打开”的缺陷。“新建”的缺陷需要项目经理确认并将状态置为“打开” | |
Open | 打开 | 被确认并分配给相关人员处理 | |
Fixed | 修复 | 开发人员已完成修正,等待测试人员验证 | |
Closed | 关闭 | 缺陷已被修复 | |
Reopen | 重新打开 | 缺陷未被修复 | |
Rejected | 否决 | 拒绝修改缺陷,该缺陷可能由于测试人员理解错误,或者项目经理认为不需要修改 | |
延期 | 延期 | 不在当前版本修复的错误,下一版本修复 | |
无法解决 | 无法解决 | 以目前的技术水平、经济因素或修改此缺陷的代价过大等原因而不能解决的缺陷 | |
Tester Agree | 测试同意 | 测试人员同意开发对缺陷做出的处理(这种处理可能是一种折衷的方法) | |
Duplicate | 重复 | 由于测试重叠工作或者不同测试人员重复提交等原因,出现相同描述的缺陷重复报告. | |
4.分配给
记录该缺陷分配给谁去修改。一般来说,登记时都是统一分配给项目经理,再由项目经理确认并分配给相关开发人员。
5.缺陷严重程度和优先级
缺陷严重级程度与优先级别原则上是有一一对应的关系,在填写缺陷选择这两项时,可先参照该对照表:
缺陷严重程度中文名称 | 缺陷严重程度描述 | 对应的缺陷优先级选项 | 缺陷优先级描述 |
5-紧急 | 阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷,例如: 1. 3. 4. 5. 6. 7. | 5-紧急 | 1 当缺陷所引发的问题没有达到紧急的级别,但当该缺陷出现后,影响到了后续的测试工作进行 2 客户无法容忍的页面,如页面上显示其他公司名称 3 当前操作方式与客户使用习惯背道而驰。 4 严重不合理,核心功能完全违反软件规范或业务规范,可能导致用户强烈的反感 5系统响应时间过长(例如WEB响应时间超过10s) 6模块提供的数据不合理,例如(查询“录入人”的下拉项提示为非用户名字段) 7负载测试、压力测试结果和用户需求不符 |
4-非常高 | 缺陷导致失去系统主要功能,基本功能不能完整使用例如: 1. 2. 3. 数据流错误 4. | 4-非常高 | 1 快捷方式不正确,如能够回车直接进入下一步的设计成了空格直接进入下一步 2 严重的逻辑错误 3常用操作平台不能正常使用功能(WIN XP/WIN 2000/WIN VISTA) 4常用浏览器不能正常使用(IE6.0/IE7.0/FireFox) 5超时限制的时间设置不合理 6未登录即可浏览页面 7给客户演示等过程中客户重点指出的,严重级别却不是很高的BUG,建议级别定义至少是非常高 |
3-高 | 操作性错误、错误结果、遗漏功能等影响系统要求或基本功能的实现,例如: 1. 2. 3. 4. 5. | 3-非常高 | 1 提示信息不明确,并且非常容易误导用户做出错误操作或判断。 2 软件功能的实现过程中弹出未控制的系统错误提示,导致流程中断 3 Cookies没有正常保存 4服务器和客户端的脚本修改未被记录和 5非法操作等Urgent程度的bug,如果不具有普遍性而是在极端环境下出现,例如特定的操作环境。建议级别定义为High。 |
2-中 | 错别字、罕见故障等不影响执行工作或功能实现,例如: 1. 2. 3. | 2-中 | 1 提示信息不明确,不正确或不合理 2 界面设计存在缺陷、凌乱或不友好 3整体风格不统一 |
1-低 | 建议,不影响使用的瑕疵或更好的实现等 | 1-低 | 1 虽有不尽人意之处,但不影响用户操作或用户使用频率较低,并且不会造成错误 2 局部界面不够美观 |
0-建议 | 对软件各方面提出的更好的改进性的意见。 |
6.主题
记录该缺陷属于哪个模块中。主题字段设置对应为用户需求的各个模块\子模块下,方便将来统计各个模块的缺陷密度。
7.检测者
记录该缺陷的登记者,系统会自动获取当前用户的帐号,不需要手工录入。
8.检测日期
记录该缺陷的登记日期,通常系统会自动获取当前时间,不需要手工录入。
9.检测于版本
记录发现该缺陷软件版本号,测试负责人员在每次获取到新的测试程序包时,按照程序包上的版本标签号,在QC的自定义管理中版本号一栏增加对应的版本号(注:程序包的版本号与QC中增加的版本号一致)。
10.缺陷类型
记录缺陷的类型,暂时分为7类。
11.可重现
记录缺陷是否可重现。根据缺陷描述操作,是否可以发现缺陷所描述的问题,Y表示可以重现,N表示无法重现。例如有些问题是在特定条件下才出现的,当条件改变后问题随之消失,根据所描述的步骤操作,不会再出现缺陷所描述的问题,这类就是属于无法重现的缺陷。
12.项目
记录缺陷所属的项目。
2.缺陷管理流程图
3.开发人员修改缺陷填写规范
1、不论是简单还是复杂的缺陷,开发人员都要在修改了代码并确保代码提交到服务器后,再将缺陷状态由“打开”置为“修复”。
2、对于非常简单明了的缺陷(例如界面上的一个错别字),可以在注释中加简单的注释说明:(如:已修改)但对于复杂的缺陷,必须要注明以下几点:
3、如果缺陷是由于测试人员理解错误导致,或者开发人员认为不需要修改的,开发人员可以将缺陷状态设置为“否决”,但是必须在【注释】栏中填写拒绝修改的原因。
4、如果开发人员认为该缺陷与其他缺陷重复,也需要在【注释】栏中填写与之重复的缺陷ID,例如注释内容可以填写:与缺陷10重复。目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。
小提示:在新增注释说明时,可以直接点击页面右下方的(添加注释)按钮,QC可以直接添加你的登录帐号在“注释”中,省去自己填写的麻烦!如图12.请大家在填写时养成加入自己信息的习惯,方便测试人员在回归测试时可以看到是谁回复的,有问题方便直接沟通!
4.项目经理决定延期修改缺陷
1、项目经理决定延迟修改缺陷时,先在注释中写明延迟修改的原因,再将缺陷状态置为“延期”。
2、项目经理需填写如图13中蓝色框圈出的“计划关闭的版本号”和“估计修复时间”两项内容。(计划关闭的版本号可以是正式版本,如Beta_v1.0,也可以是计划在今后的一个候选版本中填写,如Beta_v1.0.RC12)。由于目前版本管理还不完善,该项暂时可以不填写。