软件测试是任何一种旨在评价一个程序和系统的属性和能力的活动，以及判定程序或系统是否满足了所要求的结果。尽管测试对于软件质量是很关键的，且被程序员和测试工程师广泛使用，但是软件测试仍然还是一种艺术，其原因还是对于软件原理的理解有限。软件的测试的难处来自于软件的复杂性：我们甚至不能对一个中等复杂程度的程序进行完整的测试。测试不只是排错（debugging）。测试的目的可以是质量保证，验证和确认，或者可靠性估计。测试也可以用来作为通用的度量数据。纠错测试和可靠性测试是测试的两个主要方式。软件测试在预算、时间和质量要求上取得平衡。
一、概述
　　软件测试是这样的一个过程，它执行一个程序或一个系统，目的是发现错误。或者，它包括这样一些活动，只要这些活动是评价一个程序（或系统）的属性和能力、以决定程序或系统是否满足了要求。软件和物理加工不一样，物理加工接受了输入，就产生输出。软件不一样的地方在于它的失效方式不同。绝大部分物理系统以固定（通常比较少）的方式失效。然而，软件却有多种奇异的失效方式。检测所有的失效模式，通常是行不通的。
　　和大多数物理系统不同，软件中的大部分缺陷是设计的错误，不是制造上的缺陷。软件不会用坏，也不会磨损—一般地说，若不升级和退市，它就不会改变。所以，软件一旦发布了，设计上的缺陷或者叫bug就会埋入到软件之中并一直留在那里，直到有一天它会被触发而发作。
　　在一个中等大小的软件模块里，软件的bugs几乎总是存在的。这不是因为程序员的粗心和不负责任，而是因为软件的复杂性通常是不可处理的，人管理复杂性的能力是有限的。还有一点，对应复杂系统，设计的缺陷是不可能根除的。
　　同样由于复杂性，发现软件中设计的缺陷也是很困难的。因为软件和任何数字系统不是连续的，测试边界值对保证其正确性是不够的。所有可能的值都需要测试和验证，但是完全的测试是不可行的。对于一个简单不过的小程序，两个32位的整数相加，会有2的64次方个测试用例，即使每秒钟测试几千个用例，完全测试这个小程序也需要几百年。很显然，对于一个实际的软件模块，其复杂性远远超过刚才举的那个例子。如果输入来自真实世界，问题将变得更加糟糕，因为时间和不可预测的环境因素，以及人的交互，都有可能被考虑成为输入参数。
　　程序的动态性使问题更加复杂。如果在初步测试中发现了一个失效，给代码做了修改，软件可能现在通过了一个原来不能通过的测试用例。但是原来通过的测试用例现在不能再保证通过了。考虑到这种可能性，测试应该重新开始。可测试的费用成本可是有限制的。
　　一个和困难相类似的有趣现象是杀虫剂现象（PesticideParadox）。你使用的每一个避免和发现bug的方法都会在狡猾的bug面前逐步变得无效。Butthisalonewillnotguaranteetomakethesoftwarebetter,因为复杂性的屏障原理告诉我们：软件的复杂性（以及bug的复杂性）增长，超过了我们管理复杂性的能力。
　　尽管有这些限制，测试在软件开发中还是一个完整的部分。在软件开发的各个阶段都得到广泛运用。一般情况下，多于50%的软件开发时间都用在测试上。测试的目的通常是：
　　1）提高质量
　　在关键应用中用到计算机和软件，bug造成的结果是严重的。Bug可以造成巨大损失。关键系统中的bug已经造成了飞机失事，使太空飞行使命夭折，股票市场停止交易。所谓的2000年问题……在计算机化的世界里，软件的质量和可靠性关系到生和死。
　　质量意味着与规定的设计要求的符合性。在规定的环境下按照要求进行，这是最小的质量要求。调试（Debugging），是狭义的软件测试，主要是指程序员发现设计缺陷。人类的天性就不是完美无缺的，这一点使得一个中等复杂的程序在第一时间没有错误。发现这些问题并纠正它们，是程序设计阶段Debugging的目的。
　　2）验证和确认
　　就象VerificationandValidation那个话题所指出的那样，测试的另一个重要的目的是验证和确认。测试可以被看成度量。这个在V&V过程中被广泛采用。测试者可以在测试结果的基础上作出声明：软件在一定的情形下，要么能够工作，要么它不能工作。我们也可以在同样的规格说明之下用同样的测试用例，比较多个不同的产品。
　　我们不能直接测试质量，但我们可以通过测试相关因子，让人们看得见产品质量。质量有三个因子的集合：功能、工程和适应性。这三个因子集合可以软件质量空间的三个维度。每一维都可以在后续的较低层次上分解成它的模块因子。表1列举了一部分最常用的质量考虑。

　　好的测试能给所有相关因子的度量提供数据。任何一个特定因子的重要性随着应用系统的不同而不同。任何一个涉及到人身安全的系统必须强调可靠性和一致性的极端重要性。在一个有代表性的商业系统中，可用性和可维护性是关键的，而一个一次性使用的科学计算程序这两者都不很要紧的。我们的测试要做到充分有效，就必须度量每一个相关因子，让质量变得看得见、摸得着。
　　确认目的的测试也叫正面测试或干净测试（cleantest）。缺点是他仅能够确认软件在特定的条件下能够工作。有限的测试不能确认软件在所有的情形下都能正常工作。相反，仅仅一个未通过的测试就可以足够证明软件不能工作。脏测试（Dirtytest）也叫负面测试，是打破软件的，或者说是软件不能工作。一个软件的小片段必须有足够的异常处理能力，才能在相当程度上的脏测试过程中生存下来。
　　一个可以测试的设计是这样一个设计：它可以很容易地得到确认（或否认）和维护。因为测试是一个严格的工作，需要足够的时间和成本，在软件开发过程中，可测试性的设计也是一个重要的设计原则。