2.2  软件测试遵循的基本原则

2.2.1  软件测试应追溯到用户需求

软件开发的最终目的是要满足最终用户的需求，测试员应始终站在用户的角度去看问题，系统中最严重的缺陷是那些导致程序无法满足用户需求的缺陷。用户是软件的最终使用者，同时往往也是软件的投资者，因此，不满足用户需求的软件是无法顺利交付和收回成本的。

2.2.2  应当把“尽早地和不断地进行软件测试”作为软件开发人员的座右铭

由于软件所涉及问题的复杂性、软件本身的复杂性和抽象性、软件开发各个阶段工作的多样性，以及参加开发各种层次人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。所以人们不应把软件测试仅仅看作是软件开发的一个独立阶段。而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段进行技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些发生错误的隐患，减少开发费用，提高软件质量。越早发现错误，则修改的代价越小，越迟发现错误，修复软件需要付出的代价就越高。

2.2.3  穷尽测试是不可能的

Good Enough原则是指测试的投入与产出要适当权衡，测试进行的不够充分是对质量不负责任的表现，但是投入过多的测试，则是资源浪费的表现。随着软件测试的投入，测试的产出随之增加；但是当测试投入增加到一定的比例后，其测试效果并不会明显地增加。

如果在一个测试项目中盲目地增加测试资源，如测试人员、测试工具等。并不一定能带来更高的效率和更大的收益。因为增加人员的同时，可能会增加沟通与培训的成本，增加工具则可能带来学习和培训的成本。尤其是在进度比较紧迫的测试项目中。为了加快测试进度盲目的增加资源，可能会带来相反的结果。

零缺陷是理想的追求，而Good Enough则是现实的追求，不能盲目追求最佳的测试效果而投入过多的测试资源，应该根据项目实际要求和产品的质量要求来考虑测试的投入。

2.2.4  具有良好的测试态度

1. 避免测试自己的程序

测试应由独立的第三方机构来完成。但国内的测试环境并不成熟，因此黑盒测试多由测试人员来测，而白盒测试则由开发人员通过交叉测试来完成。

让开发人员测试自己的代码是一件相当糟糕的事情，理由如下：

（1）不愿否定自己的工作。程序员一向认为测试人员总是在挑刺，让他们自己挑自己程序的毛病，更是难上加难。

（2）受到思维定式的局限。程序员对自己开发的程序很熟悉，测试时难以跳出自己的编码思路，若设计时就存在理解错误，或受不良编程习惯影响而导致缺陷，一般都很难发现。

（3）受进度压力的影响。程序员总是在赶进度，能在规定时间内写完代码就不错了，哪有时间去做测试。

( 4 ）程序员对程序的功能和接口很熟悉，这与最终用户的情况往往并不吻合，开发人员自己来测试程序难以具有典型性。

3. 测试应该分级别和重点

测试应该分级别。不同级别的测试，采用的测试活动、测试方法和测试重点等各有不同。

尽管测试应按一定级别进行，但受到资源和时间的限制，不可能无休止地测试下去。因此在有限的时间和资源下如何有重点地进行测试是测试管理者需充分考虑的事情。测试的重点选择需根据多方面考虑，包括测试对象的关键程度、可能的风险、质量要求等。这些考虑与经验有关，随着实践经验的增长，判断也会更准确。

4. 避免测试的随意性

软件测试是一项系统工程，是有组织、有计划、有步骤的活动。因此，测试应制定合理的测试计划。测试计划反映一个测试团队在正常情况下需完成的工作远景描述，一般包括测试需求、测试策略、资源、项目里程碑、可交付工作等关键内容。但通常情况下，将资源从测试计划中分离出来是一种更好的习惯。

2.2.5  同化效应

一名测试人员在同一个项目中待的时间越久，越可能忽略一些明显的问题。例如，对于界面操作，由于测试人员反复使用同一个软件而产生熟练感，因此可能会忽视一些易用性问题和用户体验问题。同化效应主要体现在以下两个方面。

（l）测试人员与开发人员一起在某个项目中工作较长一段时间后，容易受到开发人员对软件观点的影响，变得容易赞同开发人员的观点。

（2）测试人员对软件的熟悉程度越高，越容易忽略一些看起来较小的问题。这也是一些测试人员感觉越来越难发现缺陷的原因。

同化效应会造成缺陷的“免疫”效果。因此，在测试过程中需要通过轮换，或补充新的测试人员来避免同化效应。

2.2.6  对待缺陷的基本原则

1. 缺陷的群集现象

著名的“二八原理”也同样适用于缺陷。一般情况下，80％的软件缺陷集中在20％的模块中。例如，IBM 公司的OS/370 操作系统中，47％的缺陷仅与该系统4％的程序模块有关。造成这种缺陷群集现象的主要原因如下：

（l）程序员的疲劳。程序员长期疲劳工作，会造成大量代码缺陷，若让程序员进行12 小时或更长时间的持续编码，后期程序片段中出现的缺陷比例会呈直线上升。

（2）程序员的习惯。程序员可能因个人编程习惯，而反复犯同样的错误。

2. 缺陷有免疫力

Boris Beizer：曾描述了缺陷的“杀虫剂怪事”现象，即软件测试越多，缺陷的免疫力却越强的现象。因此，在测试中应使用不同的测试方法、针对程序的不同部分进行测试。

3. 缺陷关联和依赖

某个缺陷因其他缺陷而出现或消失，关闭某个缺陷必须先关闭其父类缺陷。这类“缺陷关联”现象表明缺陷之间存在着一定的依赖关系。