1.1.2测试原则
在设计有效的测试用例之前，软件工程师必须理解软件测试的基本原则。Davie［DAV95］提出了一组①测试原则：
●所有的测试都应追溯到用户需求。正如我们所知，软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。
●应该在测试工作真正开始的前较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始，因此，所有测试可以在任何代码被产生前进行计划和设计。
● Pareto原则应用于软件测试。简单而言， Pareto原则暗示着测试发现的错误中的80％很可能起源于程序模块中的20％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
●测试应从“小规模”开始，逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
●穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
●为了达到最佳效果，应该由独立的第三方来构造测试。“最佳效果”指最可能发现错误的测试(测试的主要目标)。由于本章中已经介绍过、并将进一步讨论的那些原因，创建系统的软件工程师并不是构造软件测试的最佳人选。
1.1.3可测试性
在理想的情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性，这就使得负责测试的人能够更容易地设计有效的测试用例，但是，什么是“可测试性”呢？ JamesBach②这样描述可测试性：
软件可测试性就是一个计算机程序能够被测试的容易程度。因为测试是如此的困难，因此，需要知道做些什么才能理顺测试过程。有时，程序员愿意去做对测试过程有帮助的事，而一个包括可能的设计点、特性等等的检查表对他们是很有用的。
肯定存在可用于在很多方面测度可测试性的度量，有时，可测试性被用来表示一个特定测试集覆盖产品的充分程度。在军方还用它来表示工具被检验和修复的容易程度。这两种意义都略不同于“软件可测试性”。下面的检查表提供了一组可测试软件的特征：
可操作性。“运行得越好，被测试的效率越高。”
●系统的错误很少(错误加上测试过程中的分析和报告开销)。
●没有阻碍测试执行的错误。
●产品在功能阶段的演化(允许同时的开发和测试)。
可观察性。“你所看见的就是你所测试的。”
●每个输入有唯一的输出。
●系统状态和变量可见，或在运行中可查询。
●过去的系统状态和变量可见，或在运行中可查询(例如：事务日志)。
●所有影响输出的因素都可见。
●容易识别错误输出。
●通过自测机制自动侦测内部错误。
●自动报告内部错误。
●可获取源代码。
文章来源于领测软件测试网 https://www.ltesting.net/
