缺陷管理的基本流程
1、测试人员填写bug并提交，此时bug的状态为new2、、开发负责人确定bug是否有效，是的话，bug的状态为open，并分配给开发人员，否的话，bug的状态为rejected
3、开发人员修改bug，修改完成并进行单元测试后，bug的状态变为fixed，同时说明修改方法
4、当bug的状态变为fixed时，测试人员打开该bug，开始对该bug进行回归测试，如果该bug回归测试通过，则状态变为closed。否则bug的状态变为reopen，同时说明reopen、closed状态变化的原因或者操作过程
5、如果回归测试通过，可是修改的同时又引入新的bug，则重新提交bug，状态为open，开发人员修改bug，省略了开发负责人的确认，因为既然是回归测试说明之前已经确定是bug了
基本都是这个流程。 HAODE open：新建，测试人员发现缺陷，确认该缺陷没有提交过（以免造成重复提单），新建缺陷，状态为open，并指给项目经理（如果测试人员清楚该模块的
开发人员，则可直接指给开发人员）；
Assigned：分配，项目经理将新建状态的缺陷分配给相应的开发人员，状态为assigned；
not a bug：开发人员收到缺陷后检查该缺陷是否有效，若无效，则修改该缺陷的状态为not a bug，在comment中注明原因并返回给测试人员，测试人员
确认后选择重新打开或关闭该缺陷；
won't fix：若开发人员认为该缺陷不需要修复，则修改状态为won't fix，注明原因并返给测试人员，测试人员确认后选择重新打开或关闭该缺陷；
duplicate：若开发人员认为该缺陷是一个重复缺陷，则修改状态为duplicate，关联重复缺陷返给测试人员，测试人员确认后选择重新打开或关闭该缺陷；
can't reproduce：当开发人员无法重现该缺陷时，则修改状态为can't reproduce，注明原因并返给测试人员，测试人员确认无法重现则关闭，否则需在
comment中详述重现的环境、条件及步骤，必要时提供能复现该缺陷的环境给相应的开发人员，并修改状态为reopen；
pending：如果开发人员确认是问题，但因为它可能只在极端情况才出现，或需要对系统架构进行改动，或优先级低而暂时不需要修复，则可将状态改为
pending，等待后续版本修复；
invalid：后续版本可能因为需求变更导致某些功能或模块不存在，或者之前的bug不存在了，则可修改状态为invalid；
need more info：如果该bug描述不完整，需要提供更多的信息进行定位，则修改状态为need more info，在comment中注明返回给测试人员，测试人员
提供相应信息后reopen；
in progress：当开发人员认为该缺陷有效，需要修复，则修改状态为in progress，开始分析缺陷并修复；
Fixed（Resolved）：开发人员修复完缺陷后，修改缺陷状态为fixed，在comment中描述缺陷出现的原因，修复方法，影响范围，并指给测试人员或测试负责人；
wait for verification：测试负责人指给测试人员时修改状态为wait for verification；
Reopen：测试人员对已修复的缺陷进行验证，验证不通过，则修改状态为Reopen，开发人员重新修复，直到缺陷验证通过；
Closed：测试人员对已修复的缺陷进行验证，验证通过后，修改状态为closed。
页:
[1]
