作者：季艳艳    

分享一篇关于软件测试疑难缺陷的文章，首先先看一段寓言故事，由此可以得到如何妥善处理软件疑难缺陷的一些有益启示。

小鸡住在森林里，一天突然有一个橡胶果掉在它头上。这可把它吓坏了，浑身瑟瑟发抖，连身上的毛都掉了一半。“救命啊！救命啊！天塌了！我一定要告诉国王！”小鸡说。

于是，小鸡满怀恐惧地去告诉国王。路上碰到了大公鸡。

“你要去哪儿，可爱的小鸡？”大公鸡问。

“啊，救命！天塌了！”小鸡怯怯地说。

“你怎么知道的？”大公鸡惊奇地问。

“我亲眼所见，亲耳所闻，有一块天掉到我头上了！”小鸡说。

“可怕，真是太可怕了！我们得赶紧报告国王。”大公鸡说。言罢，它们用最快的速度向国王的宫殿奔跑。

在这个寓言故事里，小鸡在意外事件发生时大吃一惊，然后就疯一般地逃跑，向全世界大声宣布臆想的事情发生了。而大公鸡听了小鸡的一面之词后，没有深入思考和检查确认，就听信了小鸡。想象一下，我们测试人员是否有时候因为发现了一个自认为非常严重的缺陷而会像小鸡一样大惊小怪。猜想一下，当开发和产品人员假如看到了小鸡和大公鸡这样逃跑会怎样做？

这个看似荒诞的寓言故事与软件测试存在很多有趣的类似之处。测试与开发人员对软件缺陷的确认、修正和验证等处理，可能经常出现不一致的认识，甚至可能引起激烈的辩论，这时候就更体现了处理某些具有争议缺陷的策略的重要性了。

1、 缺陷还是功能特征

软件测试过程中经常有这样的情况发生：测试人员报告的缺陷，但开发人员不认为是缺陷而是软件的特征，从而拒绝修正。遇到这种情况，站在测试人员的角度，该如何妥善的解决问题呢?

很显然，与那些固执的开发人员辩论、争吵是无济于事的，那样只会把关系弄糟。确定某个软件行为特征是否是缺陷，需要首先从分析软件的系统需求、设计文档以及用户的实际需要寻找答案。

最理想的情况是软件的设计文档中明确规定了软件特征和功能，但是有时候由于软件的需求和设计文档写得很粗，甚至没有文档，或者文档零散地以电子邮件、产品计划和市场材料的形式存在。在这种情况下，测试人员和开发人员之间对软件的某个表现特征是否属于软件缺陷，就可能产生分歧。

如果对于是否是缺陷的争议是由于团队内部交流不畅引起的，那么测试人员、开发人员和产品人员一起讨论和交流，测试人员首先要确认软件缺陷的具体现象是什么，为什么认为是软件缺陷。如果是由于测试人员对软件设计文档的错误理解引起的误报，则可以关闭错误。

如果每个人都理解软件测试人员描述的软件缺陷，但是开发人员仍然不承认是软件缺陷，应该如何处理呢？软件开发人员可能由于任务压力大，没有时间修正缺陷，或者认为这个缺陷不值得修正，或者坚持认为软件就是故意这样设计的，属于软件的特征之一。

但是作为测试人员是站在最终用户的角度看待软件缺陷，如果认为缺陷对最终用户的使用具有很大的不利影响，则测试人员需要坚持原则，召集更多的人员参与讨论.

2、不容易再现的缺陷

理论上，每个缺陷只要满足一定的条件，都可以100%地复现。但是，实际测试情况是，某些软件缺陷并不是每次都可以容易的复现，满足这些条件有时候是件很困难的事情，尤其在执行黑盒测试时，测试人员不了解程序的代码结构，而某些缺陷只有在满足多个组合条件时才能复现。缺陷修正人员在修正缺陷之前，首先确认该缺陷是可以复现的，这样才能尽快地找到产生缺陷的根源，如果不能100%复现缺陷，他们要么拒绝修正，要么要求测试人员添加更多的缺陷信息保证可以100%的复现。

对于软件测试人员来说，对于这些不能100%复现的缺陷，有两种选择：第一，报告缺陷，表明这个缺陷的复现频率百分比；第二，不报告缺陷。

根据测试的目的，任何缺陷都可能给用户造成损失，所以，对于这些缺陷，应该报告到缺陷跟踪数据库中。尤其对于那些造成操作系统崩溃，或者应用程序意外退出，或者引起数据丢失的功能缺陷，一定要设法提供足够多的复现缺陷的信息，针对重现几率较大的缺陷，则可以填写重现缺陷的百分比。

如果怕麻烦而忽略不报告，等到用户发现并抱怨产品质量，那就属于软件测试人员的失职了。报告不报告可能的缺陷是测试人员的工作态度问题，修正不修正缺陷是开发人员的问题。为了防患于未然，宁可报告多个可能的不是100%复现的缺陷，也不让一个严重的缺陷漏报。

另外一种不易复现的缺陷是原来报告的软件缺陷，没有经过任何针对该缺陷的代码修正，但是在新的软件版本中无法复现，好像缺陷被意外修正了。

造成这种情况的原因之一可能是在修正其他缺陷时，由于某些缺陷的关联性，修正一个缺陷后，其他缺陷也同时修正了。这种情况测试人员可以直接关闭缺陷。

另一种情况可能是该缺陷仍然隐藏在软件中，但是不能容易的复现出来，这种情况下，软件缺陷就需要保持“打开”状态，直到缺陷被真正修正。

实际测试过程中，软件测试人员很难确定软件缺陷是否真的被彻底修正了，还是不容易找到复现缺陷的条件，保守的做法是先把缺陷保持“打开”状态，添加必要的信息，告诉开发人员该缺陷可能仍然存在于软件中，需要在后续Build中继续察看和修正。如果到了软件发布前，仍然不能确定缺陷是否被修正，则提请产品人员或需求人员做最后的处理。

3、确定缺陷的严重性和优先级

缺陷的严重性（Severity）和优先级（优先级）是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。

缺陷的严重性顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

正确处理缺陷的严重性和优先级不是件非常容易的事情，对于经验不很丰富的测试和开发人员而言，经常犯的错误有以下两种情形：

第一，将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，经常给人“狼来了”的错觉，就像前面寓言中的小鸡报告天塌了的故事，这将影响软件质量的正确评估，也耗费开发人员辨别和处理缺陷的时间。

第二，将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。如果在项目发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修正，影响软件的正常发布。或者这些严重的缺陷成了“漏网之鱼”，随软件一起发布出去，影响软件的质量和用户的使用信心。

在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。而软件测试人员的测试活动就是站在客户的角度报告缺陷，所以缺陷数据库中的严重性字段应该由测试人员确定。

确定软件缺陷优先级，更多的要综合考虑这个缺陷对项目进度、质量、市场、以及修正耗费的时间和可能引入新缺陷的风险等的影响，因此，确定缺陷的优先级通常由软件开发人员或产品人员确认。

正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。