软件测试的重要性及其对软件质量的好坏的预意是非常重要的。下面这段话引自Deutsch[DEU79]：
　　软件系统的开发包括一系列生产活动，其中由人带来的错误因素非常多。错误可能出现在程序的最初…，其时目标可能是错误的或描述不完整，也可能在后期的设计和开发阶段…，因为人们不能完好无缺地工作和交流，软件开发过程中必须伴有质量保证活动。
　　软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。
　　软件作为系统元素的可见性不断增加软件故障带来的代价太高使得人们注重于规划良好的彻底测试，软件开发组织将30%—40%的项目精力花在测试上并不为怪。另一方面，人命悠关的软件(如飞行控制和核反应堆)测试所花的时间往往是其他软件工程活动时间之和的三到五倍。
　　以下讨论软件测试基础和设计软件测试用例的技术。软件测试基础定义了软件测试的目标，测试用例的设计讨论符合整体目标的测试用例创建技术。

1.1软件测试基础

　　测试为软件工程师带来了很有趣的意外。在软件过程的早期，软件工程师试图由抽象概念到具体实现来建立软件，现在来了测试，工程师创建测试用例试图“摧毁”已经建立的软件。事实上，在软件工程过程中，测试可以看成(至少心理上)摧毁性的而不是建设性的。
　　软件开发者就其本性而言是建设者，测试要求开发者放弃刚开发的软件是正确的观念，并克服发现错误时的心理矛盾。Beizers［BEI90］如下描述了这种情况：
　　如果我们真正擅长编程，就应当不会有错误，但这只是一个神话。如果我们真的很认真，如果每个人都使用结构化方法，自顶向下设计而且使用决策表，如果程序是用SQUISH写的，如果我们有合适的银弹，就不会有错误了，这样，神话就不存在。因为我们并不擅长所做的事，所以有错误，如果不擅长，就应当感到内疚。因此，测试和测试用例设计是对失误的承认，它注入了一针内疚剂。测试的枯燥是对我们错误的处罚，为什么处罚？为了人？为什么内疚？为了没能达到人类的完美境界？为了没有区别另一个程序员所想的和所说的？为了没有心灵感应？为了没有解决人类四千年来尚未解决的相互通信问题？
　　测试真的应当注入内疚感？测试真的是摧毁性的？这些问题的回答是“不！”，然而，测试的目标可能和我们所期待的不同。
　　1.1.1测试目标
　　Glen Myers［MYE79］在他的软件测试著作中陈述了一系列关于测试目标的规则：
　　1.测试是一个为了寻找错误而运行程序的过程。
　　2.一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。
　　3.一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。
　　上述目标蕴含了一个观点上的戏剧性变化，他们转向通常的观点，即一个成功的测试是指没有找到错误的测试。我们的目标是设计这样的测试，它们能够系统地揭示不同类型的错误，并且耗费最少时间与最小工作量。
　　如果成功构造了测试(根据上述目标)，则能够在软件中揭示错误。测试的第二个好处在于它证实了软件依据规约所具有的功能及其性能需求，此外，构造测试时的数据收集提供了软件可*性以及软件整体质量的一些信息。但是，有一件事测试无法完成：
　　测试无法说明错误不存在，它只能表示软件错误已经出现。
　　在构造测试时必须牢记这一点。
　　1.1.2测试原则
　　在设计有效的测试用例之前，软件工程师必须理解软件测试的基本原则。Davie［DAV95］提出了一组①测试原则：
　　●所有的测试都应追溯到用户需求。正如我们所知，软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。
　　●应该在测试工作真正开始的前较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始，因此，所有测试可以在任何代码被产生前进行计划和设计。
　　● Pareto原则应用于软件测试。简单而言， Pareto原则暗示着测试发现的错误中的80％很可能起源于程序模块中的20％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
　　●测试应从“小规模”开始，逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
　　●穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
　　●为了达到最佳效果，应该由独立的第三方来构造测试。“最佳效果”指最可能发现错误的测试(测试的主要目标)。由于本章中已经介绍过、并将进一步讨论的那些原因，创建系统的软件工程师并不是构造软件测试的最佳人选。
　　1.1.3可测试性
　　在理想的情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性，这就使得负责测试的人能够更容易地设计有效的测试用例，但是，什么是“可测试性”呢？ JamesBach②这样描述可测试性：
　　软件可测试性就是一个计算机程序能够被测试的容易程度。因为测试是如此的困难，因此，需要知道做些什么才能理顺测试过程。有时，程序员愿意去做对测试过程有帮助的事，而一个包括可能的设计点、特性等等的检查表对他们是很有用的。
　　肯定存在可用于在很多方面测度可测试性的度量，有时，可测试性被用来表示一个特定测试集覆盖产品的充分程度。在军方还用它来表示工具被检验和修复的容易程度。这两种意义都略不同于“软件可测试性”。下面的检查表提供了一组可测试软件的特征：
　　可操作性。“运行得越好，被测试的效率越高。”
　　　●系统的错误很少(错误加上测试过程中的分析和报告开销)。
　　　●没有阻碍测试执行的错误。
　　　●产品在功能阶段的演化(允许同时的开发和测试)。
　　可观察性。“你所看见的就是你所测试的。”
　　　●每个输入有唯一的输出。
　　　●系统状态和变量可见，或在运行中可查询。
　　　●过去的系统状态和变量可见，或在运行中可查询(例如：事务日志)。
　　　●所有影响输出的因素都可见。
　　　●容易识别错误输出。
　　　●通过自测机制自动侦测内部错误。
　　　●自动报告内部错误。
　　　●可获取源代码。