9.3.4  贯穿始终的缺陷分析

　　小艾完成调查表后，就去找凯文看是否有下一步任务。看到凯文正在画花花绿绿的表格，他就很好奇地问："这是什么？"

　　凯文抬起头说："我正在做项目最终缺陷分析，你来得正是时候，我正想给你详细介绍一下缺陷分析，好让你做个帮手。"

　　在凯文图文并茂地认真讲解下，小艾对缺陷分析有了深刻的了解。

　　在整个项目测试过程中，会不间断地做一些缺陷分析，来帮助监控在开发和测试中是否存在问题和漏洞，并根据分析结果来调整测试范围和策略。在最终测试完成后，会系统做一次缺陷分析，并以此总结经验教训以便在今后的项目中做出改进。

　　不同测试类型会有不同的缺陷分析侧重点。比如安装测试和迁移测试，会专注于分析产品安装在不同操作系统及数据库上出现的问题，所以会专门分析不同操作系统，不同数据库上出现的缺陷，看是否这个问题只发生在特定系统或数据库上。

　　一般来讲，所有测试类型都会对以下方面进行分析。

　　1、有效缺陷和无效缺陷的比率

　　前面的章节中详细介绍了缺陷管理模型中的缺陷生命周期状态及相关信息。 简而言之，缺陷从被发现到最终解决存在下列典型状态：关闭状态，开启状态，工作状态，验证状态，退回状态，取消状态。

　　其中，在关闭状态和取消状态下的缺陷称为完结缺陷，除此之外状态的缺陷称为活跃缺陷。项目结束时，理论上所有缺陷都应处在关闭状态或取消状态。当然由于时间原因，还存在极少量开启状态下的缺陷被延缓到补丁版本或新版本里修复。我们把关闭状态缺陷和延缓缺陷称为有效缺陷。而把取消状态下的缺陷称为无效缺陷。在测试过程中，应尽量提高有效缺陷比率，避免开出无效缺陷。

　　如图9-2所示，测试过程共发现103个缺陷，其中有效缺陷85个，占总缺陷的83%，无效缺陷18个，占总缺陷的17%。一般来讲，有效缺陷在80%以上就算是比较良好的。

　　造成无效缺陷的原因大致有以下几点：

　　重复缺陷：是指在系统里相同原因的缺陷已经被其他人报告。在此缺陷被作为重复缺陷返回时，先不要立即取消。必须等到核查修复后，才在系统里取消。这是因为有些缺陷被误认为是重复缺陷，实际上是不同原因造成的问题。我们只有在核查修复代码后，才能确认这是否是无效缺陷。

　　用法错误：是指测试人员在测试过程中有一些操作错误或对功能的错误理解而造成测试案例失败，由此开出的缺陷是无效缺陷。

　　符合设计：是指测试人员在测试过程中主观上认为测试结果是有问题的，并开出缺陷。但实际上产品设计就是应该如此表现。如果测试人员也同意如此设计是有道理的，就应取消所开缺陷，并视之为无效缺陷。

　　产品局限性：是指所开缺陷由于产品本身设计框架等局限性而无法修复。这样的缺陷通过改动代码是无法修复的，一般来讲最好转变为修改文档，通过文档来告诉用户这些局限性。如果既不能修改代码又不能修改文档，那么只好取消缺陷，并视之为无效缺陷。

　　未来功能：是指所开缺陷实际上是要求产品增加新功能。如果新功能不能在当前版本里实现，就应记录在未来版本的新功能候选名单上，并取消此缺陷且视之为无效缺陷。

　　不可重现：是指所开缺陷无法在相同场景中重现。有时可能由于网络，机器等问题而使测试案例无法正常运行，但重新测试很多遍也无法重现当时的问题。这种情况会建议取消缺陷，一旦同样问题再次发生，就需重开缺陷。

　　一般应该对无效缺陷进行分析，找出导致无效缺陷比例高的原因并提出相应的改进计划。