软件测试的重要性及分类

软件测试是保证软件质量的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段。大量统计资料证明，目前软件测试所花费用已经超过软件开发费用的30％。

1.软件测试基础

（1）软件测试的目的

软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要指程序）中的错误和缺陷。

为了发现程序中的错误，应竭力设计能暴露错误的测试用例。测试用例是由测试数据和预期结构构成的。一个好的测试用例是极有可能发现至今为止尚未发现的错误和测试用例。一次成功的测试是发现了至今为止尚未发现的错误的测试。

（2）软件测试准则

·应该尽早地、不断地进行软件测试，把软件测试贯穿于开发过程的始终。

·所有测试都应该能追溯到用户需求，从用户的角度看，最严重的错误是导致软件不能满足用户需求的那些错误。

·应该从“小规模”测试开始，并逐步进行“大规模”测试。

·应该在测试之前就制定出测试计划。

·根据Pareto原理，80％的错误可能出现在20％的程序模块中，测试成功的关键是如何成功找出这20％的模块。

·应该由独立的第三方来从事测试工作。

·对非法和非预期的输入数据也要像合法的预期的输入数据一样编程测试用例。

·检查软件是否做了应该做的事仅是成功的一半，另一半是看软件是否做了不该做的事。

·在规划测试时不要设想程序中不会查出错误。

·测试只能证明软件中有错误，不能证明软件中没有错误。

（3）软件测试分类

·从测试阶段划分，可分为单元测试、集成测试、确认测试、系统测试。

·从测试方法划分，可分为白盒测试、黑盒测试。

在实际应用中，一旦纠正了程序中的错误后，还应选择部分或全部原先已测试过的测试用例，对修改后的程序重新测试，这种测试称为回归测试。

2.V模型

V模型是一个著名的、以测试为驱动的开发模型，该模型强调开发过程中测试贯穿始终。如下图所示，单元测试的测试计划在编码阶段完成；集成测试计划在详细设计阶段完成；确认计划在概要设计阶段完成，如图8-4所示。

图8-4　V模型

3.单元测试

单元测试（Unit Testing），也称模块测试，通常可放在编程阶段，由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法。单元测试主要发现编程和详细设计中的错误，单元测试计划应该在详细设计阶段制定。

单元测试期间着重从以下几个方向对模块进行测试：模块接口、局部数据结构、重要的执行通路、出错处理通路、出错处理通路、边界条件等。

测试一个模块时需要为该模块编写一个驱动模块和若干个桩（Stub）模块。驱动模块用来调用被测模块，它接收测试者提供的测试数据，并把这些数据传送给被测模块，然后从被测模块接收测试结果，并以某种可以看见的方式（例如显示或打印）将测试结果返回给测试者。桩模块用来模拟被测模块所调用的子模块，它接受被测模块的调用，检验调用参数，并以尽可能简单的操作模拟被调用的子程序模块功能，把结果送回被测模块。顶层模块测试时不需要驱动模块，底层模块测试时不需要桩模块。

模块的内聚程度高可以简化单元测试过程。如果每一个模块只完成一种功能，则需要测试的方案数目将明显减少，模块中的错误也更容易预测和发现。

4.集成测试

集成测试（Integration Testing），也称组装测试，它是对由各模块组装而成的程序进行测试，主要目标是发现模块间的接口和通信问题。例如，数据穿过接口可能丢失；一个模块对另一个模块可能由于疏忽而照成有害影响；把子功能组合起来可能不产生预期的主功能；个别看来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有问题等。集成测试主要发现设计阶段产生的错误，集成测试计划应该在概要设计阶段制定。

5.确认测试

确认测试（Validation Testing）主要依据软件需求说明书检查软件的功能、性能以及其他特征是否与用户的需求一致。确认测试计划应该在需求分析阶段制定。

软件配置复查是确认测试的另一项重要内容。复查的目的是保证软件配置所有成分都已齐全，质量符号要求，文档与程序完全一致，具有完成软件维护所必需的细节。

如果一个软件是作为产品被许多客户使用的，不可能也没有必要由每个客户进行验收测试。绝大多数软件开发商都使用被称为（Alpha）测试和（Beta）测试的过程来发现那些看起来只有最终用户才能发现的错误。

测试由用户在开发者的场所进行，并且在开发者的指导下进行测试，开发者负责记录发现的错误和使用中遇到的问题。也就是说，测试是在“受控的”环境中进行的。

测试是在一个或多个用户的现场由该软件的最终用户实施的，开发者通常不在现场，用户负责记录发现的错误和使用中遇到的问题并把这些问题报告给开发者。也就是说测试是在“非受控的”环境中进行的。

经过确认测试之后软件通常可以交付使用了。

6.系统测试

系统测试的对象是完整的、集成的计算机系统，系统测试的目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。系统测试技术依据是用户需求或开发合同，除应满足一半测试的准入条件外，在进行系统测试钱，还应确认被测系统的所有配置项已通过测试，对需要固化运行的软件还应提供固件。

一般来说，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能性测试与性能测试。功能测试主要采用黑盒测试方法，性能测试主要验证软件系统在承担一定负载的情况下所表现处理的特性是否符号客户的需要，主要指标有响应时间、吞吐量、并发用户数和资源利用率等。

7.回归测试

回归测试的目的是软件发生变更后，变更部分的正确性和对变更需求的符合性以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。回归测试的对象主要包括以下4个方向。

·未通过软件单元测试的软件，在变更之后，应对其进行单元测试。

·未通过配置项测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试和配置测试。

·未通过系统测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试、配置项测试和系统测试。

·因为其他原因进行变更之后的软件单元，也首先应对变更的软件单元进行测试，然后再进行相关的软件测试。(www.xing528.com)

8.白盒测试

白盒测试，又称结构测试，主要用于单元测试阶段。它的前提把程序看作装在一个透明的盒子里，测试者完全知道程序的结构和处理算法。这种方法安装程序内部逻辑设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作。

白盒测试主要对程序模块进行如下检查：

·对程序模块的所有独立的执行路径至少测试一遍；

·对所有的逻辑判定，取‘真’或取‘假’两种情况都能至少测一遍；

·在循环的边界和运行的界限内执行循环体；

·测试内部数据结构的有效性。

白盒测试常用的技术是逻辑覆盖，即考查用测试数据运行被测试程序时对程序逻辑的覆盖程度。主要是覆盖标准有6种：语句覆盖，判断覆盖，条件覆盖、判定/条件覆盖、组合条件覆盖和路径覆盖。

（1）语句覆盖

语句覆盖是指选择足够多的测试用例，使得运行这些测试用例时，被测试程序的每个语句至少执行一次。很显然，语句覆盖是一种很弱的覆盖标准。

（2）判定覆盖

判定覆盖又称分支覆盖，它的含义是，不仅每个语句至少执行一次，而且每个判断的每种可能的结果（分支）都至少执行一次。判定覆盖比语句覆盖强，但对程序逻辑覆盖的程序仍然不高。

（3）条件覆盖

条件覆盖的含义是，不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。条件覆盖不一定包含判断覆盖，而判定覆盖也不一定包含条件覆盖。

（4）判定/条件覆盖

同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定/条件覆盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。

（5）条件组合覆盖

条件组合覆盖的含义是，选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。显然，满足条件组合覆盖的测试用例，也一定满足判定。条件覆盖。因此，条件组合覆盖上述5种覆盖标准种最强的一种。然而，条件组合覆盖还不能保证出现中所有可能的路径都至少经过一次。

（6）路径覆盖

路径覆盖的含义是，选取足够的测试用例，使得出现的每条可能执行到的路径都至少经过一次（如果程序中有环路，则要求每条环路至少经过一次）。径覆盖实际上考虑了程序中各种判定结果的所有可能组合，因此是一种较强的覆盖标准。但路径覆盖并未考虑判定中的条件结果的组给，并不能代替条件覆盖和条件组合覆盖。

9.黑盒测试

黑盒测试，又称功能测试，主要用于集成测试和确认测试阶段。它把软件看作是一个不透明的黑盒子，完全不考虑（或不了解）软件的内部结构和处理算法，它只检查软件功能是否安装软件需求说明书的要求正常使用，软件是否能适当地接收输入数据并产生正确的输出信息，以及在软件运行过程中能否保持外部信息（例如文件和数据库）的完整性等。

主要是为了发现几类错误：

·是否有不正确或遗漏的功能；

·接口处的输入输出是否正确；

·是否有数据结构错误或外部信息访问错误；

·性能是否满足实际要求；

·是否有初始化或终止性错误。

常用的黑盒测试技术包括等价类划分、边值分析、错误推出和因果图等。

（1）等价类划分

在设计测试用例时，等价类划分是用的最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合，对于一个等价类中的输入值来说，他们揭示程序中错误的作用是等效的，也就是说，如果等价类中的一个对湖人数据能检测出一个错误，那面等价类中的某个错误，那么等价类中的其他输入数据也不能检测出这一错误（除非这个等价类的某个子集同时还属于另一个等价类）。

如果一个等价类内部的数据是符号（软件需求说明）要求的、合理的数据，则称这个等价类位有效等价类。有效等价类主要用例检验软件是否实现了软件需求说明书中规定的功能。

如果一个等价类内部的数据是不符合（软件需求说明）要求的、不合理或非法的数据，则称这个等价类位无效等价类。无效等价类主要用来检验软件的容错性。

黑盒测试中，理由等价类划分方法设计测试用例的步骤如下：

·根据软件的功能说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类，并为每个有效等价类和无效等价类编号。

·设计一个测试用例，使其覆盖尽可能多的尚未覆盖的有效等价类。重复这一步，直至所有的有效等价类均被覆盖。

·设计一个测试用例，使其覆盖尽可能多的尚未覆盖的无效等价类。重复这一步，直至所有的无效等价类均被覆盖。

应特别注意的是，无效等价类用例测试非正常的输入数据，因此每个无效等价类都有可能查出软件中的错误，所有要位每个无效等价类设计一个测用例。

（2）边界分析

经验表明，软件在处理边界情况时最容易出错。设计一些测试用例，使软件恰好运行在边界附近，暴露出软件错误的可能性会更大一些。通常每一个等价类的边界都应着重测试，选取的测试数据应该恰好等于，稍小于或稍大于边界值。将等价类划分法和边界分析法结合使用，更有可能发现软件中的错误。

（3）错误推测

使用等价类划分和边值分析技术，有助于设计出具有代表性的、容易暴露软件错误的测试方案。但是，不同类型不同特征的软件通常又有一些特殊的容易出错的地方，错误推测法注意依靠测试人员的经验和直觉，从各种可能的测试方案选出一些最可能引起程序出错的方案。

（4）因果图

因果图是根据输入条件与输出结果之间的因果关系来设计测试用例的，它首先检测输入条件的各种组合情况，并找出输出结果对输入条件的依赖关系，然后为每种输出条件的组给设计测试用例。