如何使用QC使测试和开发更有效

　　一个缺陷的生命周期简单的可以分为三步：

　　1、测试人员登记一个缺陷。

　　2、开发人员阅读缺陷，并作出处理结果。

　　3、测试人员进行验证，决定关闭或者打开。

　　在这3个过程中，开发人员和测试人员更多的时候是靠文字沟通的。因为在实际工作中，一个项目所产生的缺陷往往不会很少(这是由软件开发的特性所决定的，跟开发人员没有必然的联系)，所以不可能对于每一个bug都面对面的沟通，所以说，测试人员和开发人员之间给对方提供充足的信息是测试开发高效进行的保证。

　　一、 测试人员登记缺陷：

　　QC中需要测试人员填写的描述缺陷的字段主要有：摘要、严重程度、分配给、描述信息。

　　1、 摘要：部分最好简单一些，简明扼要的描述哪个地方出现了什么问题。比如：“无法登陆Sohu邮件系统”。

　　2、 描述：这个字段详细解释发生了什么问题及如何发生的。需要填写的内容则包括：前置条件、测试数据、操作步骤、结果。比如说：“使用帐户A和正确的密码****，登陆邮件时提示密码错误”。附加信息：把出错时的详细的问题表现，提供给开发人员更多的信息，很方便的找出问题所在。

　　总之，测试人员提交缺陷时，要根据开发人员的需求，提供更多、更有效的信息，提高开发人员定位bug的效率。

　　二、 开发人员处理缺陷。

　　开发人员处理缺陷的流程：

　　1. 阅读缺陷：开发人员在接到测试人员报告的bug后，第一件要做的事情是仔细阅读摘要和描述部分，确认自己理解了bug所描述的情况后，再决定是否做修改。还有一种情况测试人员的描述的有歧义或者根本不清楚，这时候开发人员可以在注释中说明此情况(请注意此时不必修改bug的状态)，接着处理下面bug。把所有不清楚的bug列出来，当面跟测试人员沟通。

　　2. 重现缺陷：测试人员提出的bug都是在测试环境下发现的。而开发人员本地都有自己的一套测试环境，对于每个缺陷，开发人员都必须首先本地的测试环境中重现。如果无法重现，最有可能的问题是代码不同步。如果可以重现，那么需要做的事情就是定位并修改了。

　　3. 处理缺陷：有三种结果 “已修复”、“不是问题”、“下一版本修复”。对于决定修改的bug，开发人员需要在本地测试通过后并保证本地编译通过后修改bug的状态为“已修复”;对于一些不影响用户使用的bug，经过与PD、测试人员沟通后可以把状态修改为“下一版本修复”;对于测试人员错误提交的bug，将其状态修改为“不是问题”。这类bug是不会统计到项目的bug数中的。

原文转自：http://www.ltesting.net