3.2 测试的特性

　　3.2.1 测试是不完全的（测试不完全）

　　由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。

　　3.2.2 测试具有免疫性（软件缺陷免疫性）

　　软件缺陷与病毒一样具有可怕的“免疫性”，测试人员对其采用的测试越多，其免疫能力越强，寻找更多软件缺陷更加困难。在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试必须采用不同的测试方式和测试数据，应该尽可能的多采用多种途径进行测试。

　　3.2.3 测试是“泛型概念”（全程测试）

　　如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住“软件缺陷具有生育能力”。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。

　   3.2.4 软件缺陷具有空间聚集性（80-20 原则）

　　80%的软件缺陷常常生存在软件20%的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发“地段”。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

　　80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免80%的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的80%，后的5%的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

　　3.2.5 为效益而测试

　　为什么我们要实施软件测试，是为了提高项目的质量效益终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化。

　　3.2.6 缺陷的必然性

　　软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

　　3.3 测试组织管理不专业

　　1、测试人员不独立于开发者，测试人员独立于开发者的程度将影响测试结果。

　　人很容易用自己已经非常仔细地做过测试来欺骗自己，开发人员做测试容易受到个人的习惯性想法的影响，程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。如果是这种情况，当开发人员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。开发和测试是两种不同的活动，开发人员对自己的程序进行一定的审查、调试是必要的，但是一般情况下还需要另外的专业测试者进行测试。不过，由于有的企业中，人力有限，或者认为没有足够的资源或理由支持一支测试队伍，有时不得不由开发人员测试；那么，开发者对自己的程序的测试需要注意许多问题，或者应由另外的开发者对自己的程序进行测试。

　　2、测试时间安排往往计划不周，测试计划有时受制于开发计划。

　　3、测试等级以及在那个等级上的测试时间往往选择不当。

　　4、测试辅助设备和测试工具将影响开发者的测试效率及测试彻底性。

　　5、测试策略文档的普遍缺失。

　　6、测试范围的确认经常被其他文档或经验所取代。

　　7、测试任务应该像BUG 一样有明确的分级，不同类型的测试应该有相应的测试用例集合与之对应。

　　8、关键路径概念在测试规划时容易被项目经理弱化。

　　9、测试用例不科学，测试用例在实际中没有起多大作用；在实际测试时根本没有按用例执行；往往测试执行后没有把新的用例补充到用例库中。