谁来执行测试、测试什么、什么时候测试、怎样进行测试、测试停…

（2）测试什么
很显然，表现在程序中的故障，并不一定是编码所引起的。很可能是详细设计、概要设计阶段，甚至是需求分析阶段的问题引起的。
即使针对源程序进行测试，所发现故障的根源也可能在开发前期的各个阶段。解决问题、排除故障也必须追溯到前期的工作。
实际上，软件需求分析、设计和实施阶段是软件故障的主要来源，因此，需求分析、概要设计、详细设计以及程序编码等各个阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象。

当因进度、人力、物力等原因，不可能对软件的每一部分进行完全测试时，
应采取什么策略来设计测试用例呢？是随机生成测试用例？还是测试软件中常用的功能或高风险的部分？
不言而喻，将精力花在系统的常用功能或高风险的部分是适当的。

（3）什么时候测试
测试是一个与开发相并行的过程，还是当开发取得一定阶段性成果之后的活动或是开发结束之后的活动？
也就是说，模块开发结束之后可以进行测试，也可以推迟至各模块装配成一个完整的程序之后再进行测试。
实践表明，随着开发的深入，未进行测试的模块对整个软件的潜在破坏作用就越明显。

那么应该在什么时候进行测试才是恰当的呢？有时测试只需要在开发过程即将结束时进行，
也就是说，系统测试或验收测试是对软件的惟一正式的测试。在开发者的数量相对少的时候，这种方法还可行。
但对大多数开发过程来说是不适合的。人们已经开始认识到：测试开始得时间越早，测试执行得越频繁，所带来的整个软件开发成本的下降就会越多。
测试的另一个极端是每天都进行测试，一旦软件的模块开发出来就对它们测试，这样显然又会延缓早期开发的进度。
不过，它能够大大减少将所有模块装配到项目中以后出现问题的可能性。

（4）怎样进行测试
软件“规范”说明了软件本身应该达到的目标，程序“实现”则是一种对应各种输入如何产生输出结果的算法。
简言之，规范说明一个软件要做什么，而程序实现则规定了软件应该怎样做。
对软件进行测试就是根据软件的功能规范说明和程序实现，利用后续各章介绍的各种测试方法，生成有效的测试用例，对软件进行测试。

（5）测试停止的标准是什么
从现实和经济的角度来看，对软件进行完全测试是不可能的。那么，什么时候停止测试呢？
因为无法判断当前查出的故障是否为最后一个故障，所以决定什么时候停止测试是一件很困难的事。
测试完成的传统标准是分配的测试时间用完了或完成了所有的测试又没有检测出故障。
但这两个完成标准都没有什么实用价值。

实用的停止测试标准应该基于以下几个因素：
成功地采用了具体的测试用例设计方法。
每一类覆盖的覆盖率。
故障检测率（即每一单元测试时间内检测出的故障数）低于指定的限度。基于故障检测数量的标准必须注明故障的严重性程度。
检测出故障的具体数量（估计存在故障总量的比率）或消耗的具体时间等。

居然没一个人来顶的，
看来要沉了。。。