14.2  项目中缺陷管理流程是怎样的 

在公司中，关注缺陷相关人员主要是测试组长、测试工程师、测试经理、程序员、产品经理、技术支持（售后服务）、工程实施人员、系统分析设计人员、项目经理、高级管理者等，他们在缺陷管理的职责分别如下。

Ø 测试组长：直接面对测试人员，对测试和缺陷报告的质量负责。

Ø 测试工程师：负责报告缺陷，并监控所报告的缺陷的解决。

Ø 测试经理：测试组长和测试工程师的领导，对测试工作的质量负责，监督测试人员。

Ø 程序员：软件实现代码的主要编写者，并负责缺陷修改。

Ø 产品经理：主要关心产品稳定性和技术支持成本；可能是最有力的质量支持人士；可能最关心产品能否按时发布；从市场的角度对一些特定问题特别感兴趣。

Ø 技术支持（售后服务）、工程实施人员：需要知道产品中有多少已知的缺陷；出现缺陷延期处理评审会，就那些会增加客户服务电话比率的问题提出反对延期处理建议；有时在关键的最后时刻报告缺陷；客户报告缺陷的接口。

Ø 系统分析设计人员：系统需求与设计修改者。

Ø 项目经理：负责开发高质量的软件；决定缺陷修正优先次序；最终决定缺陷修正的相关事项；分配给适当的程序员。

Ø 高级管理者：关心缺陷的统计数量、缺陷报告和修正图表；不关心单个缺陷，除非程序的行为使公司感到不安或一个非常大的吸引客户的特征出现了失败或程序的表现惹恼了用户。

图14-1给出了一个典型的软件企业中缺陷的管理流程。

 

图14-1 软件缺陷的管理流程

14.2.1  如何跟踪一个缺陷的生命周期

测试人员应该跟踪一个缺陷的整个生命周期，从Open到Closed的所有状态。通常一个典型的缺陷状态转换流程如图14-2所示。

Ø New：新发现的缺陷，未经评审决定是否指派给开发人员进行修改。

Ø Open：确认是缺陷，并且认为需要进行修改，指派给相应的开发人员。

Ø Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。

Ø Rejected：如果认为不是缺陷，则拒绝修改。

Ø Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。

Ø Closed：修改状态的缺陷经测试人员的回归测试验证通过，则关闭缺陷 。

Ø Reopen：如果经验证缺陷仍然存在，图14-2也是一个基本的缺陷状态变更流程，则需要重新打开缺陷，开发人员重新修改。

缺陷的跟踪以及状态变更应该遵循一些基本原则。

1） 测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。

2） 对于拒绝修改和延迟修改的缺陷，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。

 

图14-2 缺陷状态转换图

14.2.2  如何与开发人员沟通一个缺陷

能让开发人员解决最多Bug 的测试人员是最优秀的测试人员。如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的时候，这时候就需要测试人员主动与开发人员进行沟通了。如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者是很难用书面语言表达出来时，则应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug 描述的意思，而不要等待开发人员找自己了解更多的信息。

另外，应该让开发人员了解到缺陷对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改缺陷。

14.2.3  缺陷处理的技巧

管理人员、测试人员和开发人员需要掌握在软件缺陷生命周期的不同阶段处理软件缺陷技巧，从而尽快处理软件缺陷，缩短软件缺陷生命周期。以下列出处理软件缺陷的基本技巧。

（l）审阅

当测试人员在缺陷跟踪数据库中输入了一个新的缺陷时，测试员应该提交它，以便在它能够起作用之前进行审阅。这种审阅可以由测试管理员、项目管理员或其他人来进行，主要审阅缺陷报告的质量水平。

（2）拒绝

如果审阅者决定需要对一份缺陷报告进行重大修改，例如，需要添加更多的信息或者需要改变缺陷的严重等级，应该和测试人员一起讨论，由测试人员纠正缺陷报告，然后再次提交。

（3）完善

如果测试人员已经完整地描述了问题的特征并将其分离，那么审查者就会肯定这个报告。

（4）分配

当开发组接受完整描述特征并被分离的问题时，测试人员会将它分配给适当的开发人员，如果不知道具体开发人员，应分配给项目开发组组长，由开发组长再分配给对应的开发人员。

（5）测试

一旦开发人员修复一个缺陷，它就将进入测试阶段。缺陷的修复需要得到测试人员的验证，同时还要进行回归测试，检查这个缺陷的修复是否会引入新的问题。

（6）重新打开

如果这个修复没有通过确认测试．那么测试人员将重新打开这个缺陷报告。重新打开一个缺陷，需要加注释说明，否则会引起“打开一修复”多个来回，造成测试人员和开发人员不必要的矛盾。

（7）关闭

如果修复通过验证测试，那么测试人员将关闭这个缺陷。只有测试人员有关闭缺陷的权限，开发人员没有这个权限。

（8）暂缓

如果每个人都同意将确实存在的缺陷移到以后处理，应该指定下一个版本号或修改的日期。一旦新的版本开始时，这些暂缓的缺陷应该重新被打开。

测试人员、开发人员和管理人员只有紧密地合作，掌握软件缺陷处理技巧，在项目的不同阶段，及时地审查、处理和跟踪每个软件缺陷，加速软件缺陷状态的变换，不仅能提高软件质量，而且能促进项目的发展。

14.2.4  缺陷评审需要注意的问题

缺陷的管理目的是适当地保存缺陷的历史记录，以备将来的分析和统计，因此需要借助缺陷管理工具来管理，千万不要把缺陷保存在个人的计算机中，或者仅仅通过邮件来发送缺陷。缺陷的评审应该包括以下两个层面。

1）决定如何处理缺陷。

2）分析缺陷产生的原因，找出预防的对策。

对缺陷进行评审需要多方的代表参与，如图14-3所示。

 

图14-3 缺陷评审

1）决定如何处理缺陷

这一方面的评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开发代表和产品代表。

测试代表主要从缺陷的具体表现、严重程度等方面提供信息，并提出自己对缺陷的处理意见。需要注意的是，测试人员不应该一味地要求对缺陷进行修改，因为修改可能带来回归的风险，并增加回归测试的工作量。如果时间比较紧迫，修改后剩余的时间不足以作一次有效的回归测试的话，不进行修改可能是种明智的选择。

开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围和引发的风险等。如果决定要修改，还要讨论修改的初步方案。

产品代表主要从产品的整体计划、用户的要求等方面对缺陷修改的必要性、缺陷修改的时间和版本提出自己的意见。

在微软公司称之为“缺陷三方讨论会”的参加者一般是测试人员、开发人员和项目经理。

2）分析缺陷产生的原因，找出预防的对策

缺陷评审还应该包括原因分析，找出缺陷出现的原因，尤其是那些重复出现的缺陷。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的缺陷不再出现。有些缺陷出现的原因不是简单的“引用为空”之类的，而是开发人员的编码不规范或者编程习惯不好而导致的。这些才是真正的根源，必须建立正确的编程方式用来预防这些错误的出现，否则就是在玩无聊的重复发现相同缺陷的游戏。