一、缺陷常用字段说明
二、缺陷管理流程图
三、开发人员修改缺陷填写规范
四、项目经理决定延期修改缺陷
一、缺陷常用字段说明
1、摘要
对缺陷的简单描述。摘要包括该缺陷所属的模块名称-子模块名称，以及简单说明缺陷情况。
2、描述
详细描述重现该缺陷的步骤，错误现象和期待结果。必要时可以上传附件辅助说明。
3、状态
序号 | 缺陷状态英文名称 | 缺陷状态中文名称 | 缺陷状态描述 | 备注 |
1 | New | 新建 | 测试中提出报告缺陷，普通开发人员无权修改状态为“新建”的缺陷，只能修改状态为“打开”或者“重新打开”的缺陷。“新建”的缺陷需要项目经理确认并将状态置为“打开” | |
2 | Open | 打开 | 被确认并分配给相关人员处理 | |
3 | Fixed | 修复 | 开发人员已完成修正,等待测试人员验证 | |
4 | Closed | 关闭 | 缺陷已被修复 | |
5 | Reopen | 重新打开 | 缺陷未被修复 | |
6 | Rejected | 否决 | 拒绝修改缺陷，该缺陷可能由于测试人员理解错误，或者项目经理认为不需要修改 | |
7 | 延期 | 延期 | 不在当前版本修复的错误,下一版本修复 | |
8 | 无法解决 | 无法解决 | 以目前的技术水平、经济因素或修改此缺陷的代价过大等原因而不能解决的缺陷 | |
9 | Tester Agree | 测试同意 | 测试人员同意开发对缺陷做出的处理(这种处理可能是一种折衷的方法) | |
10 | Duplicate | 重复 | 由于测试重叠工作或者不同测试人员重复提交等原因,出现相同描述的缺陷重复报告. | |
4、分配给
记录该缺陷分配给谁去修改。一般来说，登记时都是统一分配给项目经理，再由项目经理确认并分配给相关开发人员。
5、缺陷严重程度和优先级
缺陷严重级程度与优先级别原则上是有一一对应的关系，在填写缺陷选择这两项时，可先参照该对照表：
缺陷严重程度中文名称 | 缺陷严重程度描述 | 对应的缺陷优先级选项 | 缺陷优先级描述 |
5-紧急 | 阻碍流程、系统崩溃导致重大任务不能正常进行的缺陷,例如: 1. 由于程序所引起的死机,非法退出 2. 死循环 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类。
1）功能问题：软件功能未实现或实现不完整、不正确等情况下的缺陷。
2）界面问题：用户操作界面中存在的不合理、不正确、不美观等方面的缺陷。
3）数据问题：录入的数据错误。
4）易用性问题：用户操作使用过程中存在的不符合使用习惯或操作复杂等方面的缺陷。
5）兼容性问题：系统在不同的测试环境中产生的缺陷。
6）性能问题：系统性能未达到性能需求所要求的各项指标。
7）安全性问题：系统存在安全方面的隐患一类的缺陷。
11、可重现
记录缺陷是否可重现。根据缺陷描述操作，是否可以发现缺陷所描述的问题，Y表示可以重现，N表示无法重现。例如有些问题是在特定条件下才出现的，当条件改变后问题随之消失，根据所描述的步骤操作，不会再出现缺陷所描述的问题，这类就是属于无法重现的缺陷。
12、项目
记录缺陷所属的项目。
二、缺陷管理流程图
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿
三、开发人员修改缺陷填写规范
1、不论是简单还是复杂的缺陷，开发人员都要在修改了代码并确保代码提交到服务器后，再将缺陷状态由“打开”置为“修复”。
2、对于非常简单明了的缺陷（例如界面上的一个错别字），可以在注释中加简单的注释说明：（如：已修改）但对于复杂的缺陷，必须要注明以下几点：
1）缺陷产生的原因
2）缺陷解决的方法：（该项描述主要是方便以后遇到同类问题的同事，可以查看当时的解决办法，如果该缺陷的修改引发了其他的缺陷产生，则开发人员可以查看一下当 时的修改情况）
3）这个改动引起了哪些变动：（方便测试人员在进行回归测试时，测试的深度和广度的把握）
3、如果缺陷是由于测试人员理解错误导致，或者开发人员认为不需要修改的，开发人员可以将缺陷状态设置为“否决”，但是必须在【注释】栏中填写拒绝修改的原因。
4、如果开发人员认为该缺陷与其他缺陷重复，也需要在【注释】栏中填写与之重复的缺陷ID，例如注释内容可以填写：与缺陷10重复。目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。
小提示：在新增注释说明时，可以直接点击页面右下方的（添加注释）按钮，QC可以直接添加你的登录帐号在“注释”中，省去自己填写的麻烦！如图12.请大家在填写时养成加入自己信息的习惯，方便测试人员在回归测试时可以看到是谁回复的，有问题方便直接沟通！
四、项目经理决定延期修改缺陷
1、项目经理决定延迟修改缺陷时，先在注释中写明延迟修改的原因，再将缺陷状态置为“延期”。
2、项目经理需填写如图13中蓝色框圈出的“计划关闭的版本号”和“估计修复时间”两项内容。（计划关闭的版本号可以是正式版本，如Beta_v1.0，也可以是计划在今后的一个候选版本中填写，如Beta_v1.0.RC12）。由于目前版本管理还不完善，该项暂时可以不填写。
