功能测试——BUG处理流程
BUG处理流程在软件测试过程中，测试人员发现缺陷以后通常会提交到缺陷管理工具（QC）中。为规范技术部的BUG处理过程，特制定本规范要求，下面为正常的BUG处理流程：
1. 测试人员发现并提交一个BUG，此时BUG的状态为新建（NEW）状态，新增的BUG都提交给项目经理。
2. 项目经理确认是一个BUG后，将BUG的状态置为打开（OPEN）状态，并修改优先级，然后指定研发人员进行修复，并指定预修复时间。
3. 开发人员修改该BUG后，将BUG的状态变为已修复（FIXED），待系统BUG修复完成后，形成一个新的版本提交给测试人员。
4. 测试人员对新版本进行回归测试，如果该BUG确实已经修正，则将GUG状态修改为已关闭（CLOSDE）状态，如果仍有问题，则修改为重新打开（REOPEN）的状态，需要开发人员继续修改该项BUG。
上面是最基本也最常用的处理流程，在实际中我们还会有一些特殊情况，如：
1、如项目经理或开发人员认为测试人员提的某一个BUG不是问题，则修改状态为拒绝（REJECTED）状态，请一定加上注释说明。
2、如果有BUG开发人员采用延后处理的，开发人员在注释中要注明延后到什么时间进行处理，测试人员要进行跟踪。
3、如果项目经理不在，必须指定一位开发人员处理新增的BUG，原则上，新增BUG修改为其他状态的时间不能超过一周。 如果项目经理不在，必须指定一位开发人员处理新增的BUG，原则上，新增BUG修改为其他状态的时间不能超过一周。
我是觉得这个不能依赖项目经理，谁开发的我测试人员直接把缺陷切给谁，除非出现程序调用关系负责不知道是谁的责任才需要项目经理协调。
还有新增的BUG，根据严重等级和项目的紧张程度来缺人修改其他状态时间，例如阻碍测试进度的优先处理，当日处理，其他的根据情况而定。有些很严重的但是因为需求问题需要重新分析讨论这个就没办法规定具体时间修复。
以上只是个人的一些见解不一定正确 每个公司的细节不太一样的。 学习了 方法很多，执行力才是关键 跟我们公司的模式一致 规范性的操作是必须的。。。事在人为。特殊情况特殊处理就行。 规范性的操作是必须的。。。事在人为。特殊情况特殊处理就行。 规范性的操作是必须的。。。事在人为。特殊情况特殊处理就行。 规范性的操作是必须的。。。事在人为。特殊情况特殊处理就行。 项目经理下还有测试经理、开发组长、测试组长吧，一般BUG不用直接走项目经理的吧，两个组长就分配了，顶多到测试经理级 ;P
页:
[1]
