项目缺陷管理 服务器,QC缺陷管理操作－细说

三、开发人员修改缺陷填写规范

1、不论是简单还是复杂的缺陷，开发人员都要在修改了代码并确保代码提交到服务器后，再将缺陷状态由“打开”置为“修复”。

2、对于非常简单明了的缺陷(例如界面上的一个错别字)，可以在注释中加简单的注释说明：(如：已修改)但对于复杂的缺陷，必须要注明以下几点：

1)缺陷产生的原因

2)缺陷解决的方法：(该项描述主要是方便以后遇到同类问题的同事，可以查看当时的解决办法，如果该缺陷的修改引发了其他的缺陷产生，则开发人员可以查看一下当  时的修改情况)

3)这个改动引起了哪些变动：(方便测试人员在进行回归测试时，测试的深度和广度的把握)

3、如果缺陷是由于测试人员理解错误导致，或者开发人员认为不需要修改的，开发人员可以将缺陷状态设置为“否决”，但是必须在【注释】栏中填写拒绝修改的原因。

4、如果开发人员认为该缺陷与其他缺陷重复，也需要在【注释】栏中填写与之重复的缺陷ID，例如注释内容可以填写：与缺陷10重复。目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。

小提示：在新增注释说明时，可以直接点击页面右下方的(添加注释)按钮，QC可以直接添加你的登录帐号在“注释”中，省去自己填写的麻烦！如图12.请大家在填写时养成加入自己信息的习惯，方便测试人员在回归测试时可以看到是谁回复的，有问题方便直接沟通！

四、项目经理决定延期修改缺陷

1、项目经理决定延迟修改缺陷时，先在注释中写明延迟修改的原因，再将缺陷状态置为“延期”。

2、项目经理需填写如图13中蓝色框圈出的“计划关闭的版本号”和“估计修复时间”两项内容。(计划关闭的版本号可以是正式版本，如Beta_v1.0，也可以是计划在今后的一个候选版本中填写，如Beta_v1.0.RC12)。由于目前版本管理还不完善，该项暂时可以不填写。

44/4<1234