1.1 软件测试的定义及发展

软件测试是对软件产品和阶段性工作成果进行质量检验，力求发现其中的各种缺陷，并督促缺陷得到修正，从而控制软件产品的质量。这里面涉及两个基本概念，即“软件缺陷”和“软件质量”，具体定义将在1.2及1.3节中给出。

软件测试定义的发展是在正反两方面的争辩中形成的。1973年，软件测试领域的先驱Bill Hetzel博士给出了软件测试的第一个定义：“软件测试就是为程序能够按预期设想运行而建立足够的信心”。1983年，Bill Hetzel博士对该定义进行了修订，即：“软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期效果”。

这个阶段对软件测试的认识体现了正向思维方式：软件测试以人们的“设想”或“预期的结果”为依据，用于验证软件产品是否正确工作以及是否符合事先定义的要求。这里的“设想”或“预期的结果”是指需求定义、软件设计的结果。

Bill Hetzel的软件测试定义是“正向”的，它强调测试以需求和设计为出发点，在需求和设计所描述的环境下充分地验证软件的所有功能。这种“正向”的测试定义有利于规范化与标准化测试活动，有利于指导测试工作的重点。Bill Hetzel的软件测试定义也得到了国际标准组织的认可，例如，1983年，电气与电子工程师协会（Institute of Electrical and Electronics Engineers，IEEE）在IEEE Standard 729中对软件测试下了一个标准的定义：使用人工或自动的手段来运行或测量软件系统的过程，目的是检验软件系统是否满足规定的要求，并找出与预期结果之间的差异；软件测试是一门需要经过设计、开发和维护等完整阶段的软件工程。这里明确地提出了软件测试是以检验软件产品是否满足需求为目标。

同一时期，Glenford J. Myers则认为，软件测试不应该专注于验证软件是工作的，相反，应该用逆向思维去发现尽可能多的错误。他认为，从心理学的角度看，如果将“验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。他认为应该将验证软件是不工作的作为重点，假定软件总是有错误的，测试就是为了发现缺陷，而不是证明程序无错误。如果发现了问题则说明程序有错，但如果没有发现问题，也并不能说明问题就不存在，而是至今未发现软件中所潜在的问题。1979年，Glenford J. Myers在其经典著作《软件测试的艺术》（The Art of Software Testing）中给出了软件测试的定义：“测试是为了发现错误而执行一个程序或者系统的过程”。

Glenford J. Myers的软件测试定义受到了业界的普遍认同，但是如果只强调测试的目的是寻找错误，就可能使测试人员忽视软件产品的某些基本需求或客户的实际需求，测试活动可能会存在一定的随意性和盲目性，也容易使开发人员产生错误的印象，认为测试人员的工作就是挑毛病。同时，Glenford J. Myers的软件测试定义强调测试是执行一个程序或者系统的过程，也就是说，测试活动是在程序代码完成之后进行的，而不是贯穿于整个软件开发过程的活动，即软件测试不包括软件需求评审、软件设计评审和软件代码静态检查等一系列活动，从而使软件测试的定义停留在“动态测试”（dynamic testing）层面，即需要运行软件才能完成测试。如果在此时发现功能设计不合理或性能不好，就需要修改需求或修改设计，从而不得不返工到需求定义或系统设计阶段，会付出很大的返工代价，并很有可能导致项目进度延期。所以，有必要将软件测试延伸到需求、设计阶段，即对软件半成品（阶段性成果）—需求定义文档、设计技术文档进行验证，从而将动态测试延伸到静态测试（static testing），尽早地发现问题，把问题消灭在萌芽之中，将每个阶段产生的缺陷及时清除，以极大地提高产品的质量，有效地降低企业的成本。静态测试就是不需要运行软件系统，而对软件的半成品（如需求文档、设计文档、代码）进行评审，即开展需求评审、设计评审、代码评审等活动。静态测试还只是对产品进行评审，不包括流程评审、管理评审，以区别于“质量保证”（Quality Assurance，QA）。

软件测试从“动态测试”延伸到“静态测试”，是从狭义的软件测试发展到广义的软件测试，也使“软件测试”不再停留在编程之后的某个阶段上，而是贯穿于整个软件开发生命周期（Software Development Life Cycle，SDLC）的质量保证活动。有了广义软件测试的概念，在敏捷开发（agile development）中，软件测试就能被解释为对软件产品质量的持续评估。在敏捷方法中，不仅提倡持续集成，而且提倡持续测试。

2014年，在SWEBOK 3.0发布的软件工程知识体系中，将软件测试定义为“从一个通常是无限的执行域（集合）中选择合适的、有限的测试用例，对程序所期望的行为进行动态验证的活动过程”。该定义强调测试是对程序行为的动态验证，而把静态验证（主要是评审活动）归为质量管理，这里的软件测试是一种狭义的软件测试。而广义的软件测试包含静态测试（静态验证）和动态测试（动态验证），而且测试中的静态验证也不仅局限于对需求（文档）、设计（文档）等过程文档的评审活动，还包括对代码和数据的评审、分析和测试。这里的评审不仅包含对产品的评审，而且包含对流程、管理和技术的评审。这里的动态测试和SWEBOK 3.0的概念是一致的，属于动态验证，带有一定“试验”的性质，不包括静态的评审。

因为没有办法证明软件是正确的，软件测试本身总是具有一定的风险性，所以软件测试被认为是对软件系统中潜在的各种风险进行评估的活动。从风险的观点看，软件测试就是对风险的不断评估，从而引导软件开发的工作，进而将最终发布的软件所存在的风险降到最低。基于风险的软件测试可以被看作一个动态的监控过程，对软件开发全过程进行检测，随时发现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括回归测试。这时，软件测试可以被完全看作软件质量控制的过程。

测试的经济观点就是以最小的代价来获得最高的软件产品质量，这正是风险观点在软件开发成本上的体现，通过风险的控制来降低软件开发成本。经济观点也要求软件测试尽早开展工作，发现缺陷的时间越早，修复缺陷的工作量就越小，所造成的损失就越小。所以，从经济观点出发，测试不能在软件代码写完之后才开始，而是从项目启动的第一天起，测试人员就参与进去，尽快、尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。软件测试的经济学观点可以从Boehm的著作《软件工程经济》（Software Engineering Economics，1981）中得到进一步的印证。