软件测试是每一个软件项目生命周期必不可少的一个部分，每个程序开发人员都要面对这个不可避免的事实。可是关于测试的一些观点，也许不是每个人都能理解的。

　　针对公司的BUG数不断修改，公司发布了一道政令：“每个程序开发人员必须对自己开发的程序负责；若测试小组发现一个Bug，开发人员扣二十块大洋；若客户发现Bug，测试人员扣三十块大洋。”政令一出，全体程序开发人员和测试人员反对。可是老板的意志是不可改变的，政令还是照常执行。刚好一个从政令开始时开始运作，三个月后，项目结束顺利上线，项目的一主要程序员发现自己的项目奖金全部用来换取Bug所扣的罚款。以后的几个月时间内后，公司的软件质量大幅提高，但项目进度远远、远远落后于以前的同等项目计划。在第六个月的某一天，公司取消了这道政令，进度跟上，BUG数大幅提高。为什么会出现这样的情况呢？

　　这里不得不提测试的几个重要的观点（个人观点，仅供参考）。

　　一、软件测试的定义和目的

　　软件测试是根据软件的规格说明书和实际应用，设计一批测试案例，查找程序是否有存在错误（其中错误是泛称，可以是功能性，也可以是指性能或者是说和用户的交互性差等诸多方面）。那么，软件测试的目的是什么呢，是用测试案例来发现程序的错误还是用测试案例验证程序正确呢？其实，一个好的测试案例，就是可以重现程序中没有发现过的错误；那么测试就是发现程序有错，而不是验证正确。这一点对测试很重要，因为它会指导测试人员去设计测试案例的方向性原则。假若测试人员意识形态中是验证程序正确，那么他/她设计的测试用例带有很多虚假的成份，考虑不全面或者说设计一些不容易暴露问题的测试案例。

　　软件测试的目的是发现尚未找到的错误。

　　二、程序员要不要参于测试

　　测试人员要不要参加测试呢？可能各个人持有不同的看法。有人主张，有人反对。

　　现实生活中情形可能是这样的，程序员，特别是经验不是很丰富的年轻程序员，对自己设计的程序，测试了好多次，都没有发现问题。程序打包提交给测试人员或用户，操作时发现了有Bug，更严重的情况是程序运行不下去。程序员当然不服气，气冲冲地来进行操作演示，竟然没有Bug，为什么呢？是不是程序很怕他的主人（程序员）？那倒不是，分析一下，原因很简单，程序开发人员已经习惯于自己的逻辑思维方法，下意识中避免了或绕开了其它逻辑判断的条件，程序当然不会出错。而用户或测试人员可能有别于程序人员的逻辑思维，当两者的逻辑思维不相同时，程序就可能出差啦，而且几率相当高。

　　所以，我个人认为，程序开发人员不应对自己的开发程序进行系统测试。

　　三、测试的原则

　　1）要把“尽早地不断地测试”作为测试的座右铭；

　　2）测试只能证明错误存在，而不能证明问题不存在；

　　3）如果程序中查出的错误越多，则未查出的错误也越多。

　　4）测试应当运用实际数据进行测试，而不是测试人员进行想象中的数据；

　　5）测试要细心，更要有无情的心；

　　四、测试、质量、进度之间的关系

　　有人认为持久的测试和修改可以提高软件的开发质理。其实未必然。假若有一个粗心的天才和一个细心的白痴做一份试卷，粗心的天才可以通过检查（测试）来提高成绩，而细心的白痴再如何细心，再如何检查（测试），也不会做试题。

　　所以说软件的质量是设计出来的，而不是测试出来的。

　　有人认为只要我的时间足够多，软件就会出现零错误。虽然多测试会发现并解决一些问题。但时间并不能解决全部的问题。一个稍微复杂一点的系统，无认通过什么样的手法，通过什么先进的测试理论来指导测试，想彻底消来错误，那是不可能的。君不同微软天天在发布软件升级包，是不是微软的技术不行，设计的测试案例不够多，还是测试的人数不多（全部上网的用户全部在帮他测试），这样算来微软的测试时间并不短，为什么还要天天升级，因为程序的错误是不可能预见式的消灭的。

　　那如何来平衡这测试和时间之间的关系呢，软件开发的成本以及程序所应用的领域等多个方面来进行综合考虑。对于一般的应用系统（对于上天下海有关人命的系统另当论处），界定一个相对的测试标准，告之程序开发人员和测试人员，让他们进行遵循其游戏规则，不要让程序员老觉得没有修改完错误，测试人员老是认为自己的测试进行得不够。这个游戏规则就是设计足够好而多的测试用例，让用户可以将程序运行起来。毕竟，设计软件最终的目的是程序在基本满足要求的情况下，合法地获取尽可能多的利润。