软件测试的基本概念

6.2.1　软件测试的基本概念

一、软件测试的发展历史及趋势

Edward Kit在他的《Software Testing In The Real world：Improving The Process》（1995，ISBN：0201877562）一书中将整个软件测试的发展历史分为三个阶段：

第一个阶段是20世纪60年代及其以前，那时软件规模都很小、复杂程度低，软件开发的过程随意。开发人员发现Debug的过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试，而只是排查软件错误的调试过程，当然这一阶段也还没有专门的测试人员出现。

第二个阶段是20世纪70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程问题，并提出软件工程的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻，而且测试活动仅出现在整个软件开发流程的后期，虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。

第三个阶段是20世纪80年代及其以后，软件和IT行业进入了大发展时期，软件趋向大型化。与之相应，人们为软件开发设计了各种复杂而精密的流程和管理方法（比如CMM和MSF），并将“质量”的概念融入其中。软件测试已有了行业标准（IEEE/ANSI），它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。

在这一历史发展过程中，最值得注意的是测试与开发流程融合的趋势。比如测试活动的早期开展，让测试人员参与用户需求的验证，参加功能设计和实施设计的审核。再如测试人员与开发人员的密切合作，随着开发进展而逐步实施单元测试、模块功能测试和系统整合测试。的确，这些都是测试与开发融合的表现形式，而且初期的融合也只反映在这个层次上。20世纪90年代以后，软件的规模和复杂程度迅速提高，这种形式上的融合也迅速走向更深层次，更具实际意义。具体地说，这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目管理离开了测试也从根本上失去了依据。

二、有关软件测试的一些基本术语

1.软件测试

不同时期关于软件测试（Software Testing）的定义有：

①为了发现错误而执行程序的过程。

②确认程序做了它应该做的事情。

③确认程序正确实现了所要求的功能。

④以评价程序或系统的属性、功能为目的的活动。

⑤对软件质量的度量。

⑥验证系统满足要求，或确认实际结果与预期结果之间的差别。

定义①强调寻找错误是软件测试的目的，定义②③侧重于用户满意程度，定义④⑤强调评估软件质量，而定义⑥则将重点放在预期结果上。这些对软件测试的定义，只描述了其中的一个或几个方面的内容，并没有全面地描述软件测试。

关于软件测试的标准定义如下：

软件测试是使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

该定义是1983年IEEE（国际电子电气工程师协会）提出的软件工程标准术语中给软件测试下的定义，比较全面地反映了软件测试的重点与难点。

2.软件缺陷

对于软件存在的各种问题，我们都用“软件缺陷”这个术语，英文中用来描述软件缺陷的单词很多，比如Bug，Defect，Fault，Error，Failure，Incident，Va－riance等，不同的公司对其中的部分术语做了严格的定义，不过我们习惯统一使用Bug来描述软件缺陷。

关于软件缺陷的标准定义如下：

从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需实现的某种功能的失效或违背。

该定义是IEEE软件工程（1983）的标准术语，比较全面，但缺乏指导性。Ron Patton从软件行业的角度，给出了以下五条规则作为软件缺陷的具体表现：

①软件未达到需求规格说明书中指明的功能。

②软件出现了需求规格说明书中指明不会出现的错误。

③软件功能超出了需求规格说明书中指明的范围。

④软件未达到需求规格说明书中虽未指出但应达到的目标。

⑤软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

3.测试用例

测试用例（Testing Case）简单地来讲是指执行条件和预期结果的集合，完整地来说是针对要测试的内容所确定的一组输入信息，是为达到最佳的测试效果或高效地揭露隐藏的错误而精心设计的少量测试数据。

IEEE Standard 610（1990）给出的定义为：测试用例是一组测试输入、执行条件和预期结果的集合，目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求。

从以上定义来看，测试用例设计的核心有两方面，一是要测试的内容，即与测试用例相对应的测试需求；二是输入信息和对应的预期结果，即按照怎样的操作步骤，对系统输入哪些必要的数据，系统应该有哪些相应的响应。测试用例设计的难点在于如何通过少量测试数据来有效揭示软件缺陷。

三、软件测试的重要性

在软件业较发达的国家，软件测试不仅早已成为软件开发的一个有机组成部分，而且在整个软件开发的系统工程中占据着相当大的比重。统计表明，软件测试的工作量通常占软件开发总工作量的40％以上，开发费用的近l/2用在软件测试上，对于一些与人的生命安全相关的软件，如飞行控制、核反应堆监控软件等，其测试费用可能相当于软件工程其他步骤总成本的3～5倍。由此可见，软件测试在软件开发中是非常重要的一个过程，具体体现在以下几个方面。

1.寻找软件错误，以便进行修正

这是保证软件质量的重要一环，也是测试人员需要持续不断地做的工作。特别是通过回归测试可以防止无意识的行为引入一些将来可能出现的错误。

2.证明软件符合要求，是可用的

这主要是指从开发方的角度出发，希望通过测试向用户证明，其所开发的软件正确地实现了用户需求，树立用户对软件质量的信心，为用户选择与接受软件提供有利的依据。这主要是指α测试。

3.验证软件是否符合用户要求

这主要是指从用户的角度出发，他们希望通过测试来核实开发方交付的软件是否符合自己的真实需求，系统运行在真实的应用环境下是否存在关键功能或关键性能上的缺陷。这主要是指β测试。

4.指导软件的开发过程

从宏观上看，不同的软件开发过程，有不同的测试模型与之对应，以此能够更好地指导开发与测试实践。从微观上看，测试可以保证对需求和设计的理解与表达的正确性、实现的正确性以及运行的正确性。通过分析缺陷的分布和产生原因可以帮助发现当前软件开发的缺陷，有助于过程改进；通过对测试结果的分析整理，可以进一步修正软件的开发规则。

5.提供软件的相关特征

软件测试是对软件质量的度量与评估。GB/T6583－ISO8404（1994版）将质量定义为“反映实体满足明确的和隐含的需要的能力的特性的总和”。测试可以提供测试数据及结果来对软件质量进行细化和量化，并为软件的可靠性分析提供依据。

四、软件测试的分类

1.按照是否需要查看代码分类

按照是否需要查看代码可将软件测试分为黑盒测试和白盒测试。

黑盒测试（Black－box Testing）是将被测软件看成一个黑盒子，只考虑系统的输入和输出，完全不考虑程序内部的逻辑结构和处理过程。黑盒测试的依据是开发各阶段的需求规格说明。

白盒测试（White－box Testing）是将黑盒子打开，研究源代码和程序内部的逻辑结构。白盒测试的依据是程序源代码。

2.按照是否需要执行被测软件分类

按照是否需要执行被测软件可将软件测试分为静态测试和动态测试。

静态测试（Static Testing）又称静态分析，是不实际运行被测软件，而是直接分析软件的形式和结构，查找缺陷。主要包括对源代码、程序界面和各类文档及中间产品（如产品规格说明书、技术设计文档等）所做的测试。

动态测试（Dynamic Testing）又称动态分析，是指需要实际运行被测软件，通过观察程序运行时所表现出来的状态、行为等发现软件缺陷，包括在程序运行时，通过有效的测试用例来分析被测程序的运行情况或进行跟踪对比，发现程序所表现的行为与设计规格或客户需求不一致的地方。

3.按照测试阶段分类

按照测试的阶段可将软件测试分为单元测试、集成测试、确认测试、系统测试、验收测试等。

单元测试（Unit Testing）又称模块测试，是指对软件中的最小可测试单元进行测试，目的是检查每个单元是否能够正确实现详细设计说明中的功能、性能、接口和设计约束等要求，发现各个模块内部可能存在的各种缺陷。

集成测试（Integration Testing）又称组装测试，是在单元测试的基础上，按照设计要求，将通过单元测试的单元组装成系统或子系统而进行的有序的测试，目的是检验不同程序单元或部件之间的接口关系是否符合概要设计的要求，能否正常运行。

确认测试又称有效性测试，此时经过集成测试后，单元模块组装成为完整的软件系统，消除了接口的错误。主要由使用用户参加测试，检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准，是保证软件质量的关键环节。

系统测试（System Testing）是为了验证系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试，是在真实或模拟系统运行的环境下，检查完整的程序系统是否能和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。

验收测试（Acceptance Testing）又称接受测试，是一种正式的测试，以用户测试为主，或由测试人员等质量保证人员共同参与的测试，是一般由用户、客户或其他权威机构来决定是否可以接受一个产品（系统或组件）的测试过程。验收测试是软件正式交付给用户使用的最后一个测试环节，并决定用户是否最终验收签字和结清所有应付款。

4.按测试执行时是否需要人工干预分类

按照测试执行时是否需要人工干预可将软件测试分为手工测试和自动测试。

手工测试是完全由人工完成测试工作，包括测试计划的制订，测试用例的设计和执行，以及测试结果的检查和分析等。传统的测试工作都是由人工来完成的。

自动测试是指各种测试活动的管理和实施，都是使用自动化测试工具或自动化测试脚本来进行的测试，包括测试脚本的开发与执行等，以某种自动测试工具来验证测试需求。这类测试在执行过程中一般不需要人工干预，通常在功能测试、回归测试和性能测试中使用较为广泛。

5.其他测试类型

其他重要的测试类型包括冒烟测试、随机测试、回归测试和基线测试等。限于篇幅原因，请大家自行查找相关介绍资料。

五、软件测试的基本原则

人们为了提高测试的效率，在长期测试实验中积累了不少经验，下面列出了人们在实践中总结的主要基本原则：

1.尽早地并不断地进行软件测试

实际问题的复杂性、软件本身的复杂性与抽象性以及开发期间各层人员工作的配合关系等各种错综复杂的因素使得软件开发的各个阶段都可能存在错误及潜在的缺陷。所以，软件开发的各阶段都应当进行测试。错误发现得越早，后阶段耗费的人力、财力就越少，软件质量相对就高一些。

2.程序员或程序设计机构应避免测试自己设计的程序

测试是为了找错，而程序员大多对自己所编的程序存有偏见，总认为自己编的程序问题不大或无错误存在，因此很难查出错误。此外，设计机构在测试自己程序时，由于开发周期和经费等问题的限制，要采用客观的态度是十分困难的。从工作效率来讲，最好由与原程序无关的程序员和程序设计机构或者专门的测试人员进行测试。

3.测试用例中不仅要有输入数据，还要有与之对应的预期结果

测试前应当设定合理的测试用例。测试用例不仅要有输入数据，而且还要有与之对应的预期结果。如果在程序执行前无法确定预期的测试结果，由于人们的心理作用，可能把实际上是错误的结果当成是正确的。

4.测试用例的设计不仅要有合法的输入数据，还要有非法的输入数据

在设计测试用例时，不仅要有合法的输入测试用例，还要有非法的输入测试用例。在测试程序时，人们常忽视不合法的和预想不到的输入条件，倾向于考虑合法的和预期的输入条件。而在软件的实际使用过程中，由于各种因素的存在，用户可能会使用一些非法的输入，比如，常会按错键或使用不合法的命令。对于一个功能较完善的软件来说，不仅当输入是合法的时候能正确运行，而且当有非法输入时，也应当能对非法的输入拒绝接受，同时给出对应的提示信息，使得软件便于使用。

5.在对程序修改之后要进行回归测试

在修改程序的同时时常又会引起新的缺陷，因而在对程序修改完之后，还应使用以前的测试用例进行回归测试，有助于发现因修改程序而引起的新的缺陷。

6.程序中尚未发现的错误的数量通常与该程序中已发现的错误的数量成正比

经验表明：一段程序中若发现错误的数目越多，则此段程序中残存的错误数目也较多。例如，在美国的IBM/370的一个操作系统中，47％的错误（由用户发现的错误）仅与该系统的4％的程序模块有关。据此规律，在实际测验时，为了提高测试效率，要花较多的时间和代价来测试那些容易出错及出错多的程序段。而不要以为找到了几个错误，就认为问题已解决，不再需要继续测试了。

7.妥善保留测试计划、全部测试用例、出错统计和最终分析报告，并把它们作为软件的组成部分之一，为维护提供方便

设计测试用例要耗费相当大的工作量，若测试完随意丢弃，以后一旦程序改错后需重新测试时，将重复设计测试用例，这会造成很大的浪费，因而妥善保留与测试有关的资料，能为后期的维护工作带来方便。

8.应当对每一个测试结果做全面检查

这条重要的原则时常被人们忽视。不仔细、全面地检查测试结果，就会使得有错误征兆的输出结果被漏掉。

9.严格执行测试计划，排除测试的随意性

测试计划内容应包括：所测软件的功能、输入和输出、测试内容、各项测试的进度安排、资源要求、测试资料、测试工具、测试用例的选择、测试的控制方式和过程、系统组装方式、跟踪规程、调试规程、回归测试的规定以及评价标准等。