2.3  软件测试的分类

2.3.1  按测试策略分类

2.3.1.1  静态测试与动态测试

1. 静态测试

静态测试是不运行被测程序本身而寻找程序代码中可能存在的错误或评估程序代码的过程。静态测试不需要运行代码，也不需要对代码编译、链接、生成可执行文件。它是通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出欠缺和可疑之处，例如不匹配的参数、不适当的分支嵌套和循环嵌套、未使用过的变量、空指针的引用等。

静态测试具有以下特点：

Ø  静态测试不必动态地运行程序，也不必进行测试用例设计和结果判断等工作。

Ø  静态测试可以由人工进行，充分发挥人的逻辑思维优势。

Ø  静态测试实施不需要特别的条件，容易开展。

静态测试包括如下一些要点：

Ø  代码审查：CodeInspection或Code Review。

Ø  代码走查：Walkthrough。

Ø  桌面检查。

Ø  技术评审（软件需求分析和设计评审）。

Ø  静态分析（使用软件工具进行，包括控制流分析、数据流分析、接口分析和表达式分析等）。

2. 动态测试

动态测试是实际运行被测程序，输入相应的测试实例，检查运行结果与预期结果的差异，判定执行结果是否符合要求，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能。动态测试由3部分组成：构造测试实例、根据测试实例运行程序、分析程序的输出结果。动态测试有两种主要的方法：黑盒测试和白盒测试。

动态测试具有以下特点：

Ø  实际运行被测试程序，取得程序运行的真实情况、动态情况，进而进行分析。

Ø  必须生成测试数据来运行程序，测试质量依赖于测试数据。

Ø  生成测试数据、分析测试结果工作量大，使开展测试工作费时、费力、费人。

Ø  动态测试中涉及多方面工作，人员多、设备多、数据多，要求有较好的管理和工作规程。

2.3.1.2  黑盒测试与白盒测试

1. 黑盒测试(Black-boxTesting)。如图2-4所示。

图2-4 黑盒测试示意图

黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试。它注重于测试软件的功能性需求。

采用这种测试方法，测试者把被测程序看成一个黑盒，完全不要考虑程序的内部结构和特性，只需知道该程序输入和输出之间的关系或程序功能，依赖能够反映这一类程序功能的需求规格说明书，来确定测试用例和推断测试结果的正确性。例如，Windows计算器程序，如果输入3.14159并按sqrt键，就会得到结果1.772453102341。使用黑盒子测试方式，不管软件计算圆周率的平方根要经历多少复杂运算，都只关心它的运行结果。

2. 白盒测试(White-boxTesting)，如图2-5所示。

图2-5 白盒测试示意图

白盒测试又称结构测试、逻辑驱动测试或基于程序本身阶段测试。测试者把被测试程序看成一个盒子，白盒测试是打开箱子，根据程序的内容来设计测试数据。采用这种测试方法，测试人员需要对被测试程序的内部结构非常清楚。从程序的内部逻辑结构入手，按照一定的原则设计测试用例，对软件的逻辑路径进行测试，在程序的不同点检查程序的状态，来判定其实际情况是否和预期的状态相一致。

白盒测试的依据是程序源代码。最常见的程序结构覆盖如下：

Ø  语句覆盖：程序中每条语句至少被执行一次，这是最弱的逻辑覆盖准则。

Ø  分支覆盖或判断覆盖：程序中的每一个分支至少走查过一次，即每一条分支语句的真值至少执行一次，假值也至少执行一次。

Ø  条件覆盖：当判定式中含有多个条件时，要求每个条件的取值均得到检验。

Ø  判断/条件覆盖：同时考虑条件的组合值及判定结果的检验。

Ø  路径覆盖：使程序沿所有可能的路径执行。

黑盒测试盒白盒测试方法的对比如下：

可以说，黑盒测试和白盒测试是从完全不同的起点出发的，并且这两个出发点在某种程度上是完全对立的，反映了测试思路的两个极端情况。这两类方法在长期的软件实践过程中已经被证明是有效和实用的，它们各自具有自己的优缺点，构成互补关系，如表2-1所示，我们在规划测试时需要把黑盒测试和白盒测试结合起来。通常，在进行单元测试时采用白盒测试，而在确认测试和系统测试中大都采用黑盒测试。

表2-1 白盒测试与黑盒测试对比

注意：无论是黑盒测试还是白盒测试，都不可能对程序进行完整的、彻底的测试。黑盒测试从考虑输入数据出发验证功能，除非进行穷举，否则不可能进行完全测试。白盒测试从程序结构出发，由于程序结构的复杂性，路径数本身有时是不能确定的，所以要测试程序的全部结构也是不现实的。测试只能证明错误的存在，但不能证明错误不存在。 

2.3.1.3  手工测试与自动测试

1. 手工测试

手工测试是传统的测试方法，也是现在大多数公司都使用的测试形式。它由测试人员来执行测试用例，然后根据实际的结果去和预期的结果相比较并记录测试结果。

2. 自动测试

提到软件自动测试，很多人都会直接想到自动测试工具，认为只要购置一种流行的自动测试工具，执行记录手工测试过程，然后在需要时回放录制过程就完成了自动测试。但是，通过实践发现，事实并非如此简单。正如编写软件比学习编程语言困难一样，自动测试要比学习使用自动测试工具困难得多。

2.3.2  按测试阶段分类

在现实测试中，测试环节可分为明显的、同等重要的3个阶段，即单元测试、集成测试和系统测试。测试工作中的第4个阶段是验收测试阶段，验收测试无论在规模上和性质上都和系统测试很相似，它们的根本区别在于：前者是内部的，而后者则是受客户控制的。

在软件交付周期的不同阶段，通常需要对不同类型的目标应用测试。这些测试及阶段是从测试小的构件（单元测试）到测试整个系统（系统测试）不断向前发展的。对RUP测试阶段的划分如图2-7所示。

图2-6 RUP(统一软件开发过程)的4个测试阶段

下面通过表2-2来看看这4个阶段间的差别。

表2-2 各阶段测试的比较

2.3.3  其他常见测试方法

1. 冒烟测试(Smoke Test)

最后软件在经过修改后，要对其重要的部分先进行大概的测试，看一下系统重要的功能是否正确，再进行彻底的测试。因此，冒烟测试主要是对应用程序关键的功能进行测试，一般来说是在版本下来投入正式测试之前，对一些重点部分功能进行确认，以决定此版本是进入正式测试阶段，还是打回开发组。所以，冒烟测试不是手动地返测所有已知的缺陷，也不是反复执行所有功能的测试，而是有针对性地通过验证软件中的主要功能是否能够正常运行，来确认是否有必要将测试人员的测试工作都转移到对新版本的测试中。

2. 回归测试(Regression Test)

简单地说，回归测试就是过一段时间以后再回过头来对以前修复过的缺陷重新进行测试，看该缺陷是否会重新出现。

在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能遗漏对这些错误的修改；而开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，以而造成修改失败；修改还有可能产生副作用，从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响，就需要进行回归测试。

回归测试在软件生命周期中扮演着重要角色，因忽视回归测试而造成严重后果的例子不计其数，导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。

3. 功能测试(Function Testing)

功能测试又称正确性测试，它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素，所以其测试也最重要，功能测试的基本方法是构造一些合理输入，检查是否得到期望的输出。在测试中通常使用的技术有等价类划分、边界值分析法、因果图法等，我们将在后面的章节中中具体介绍这些技术。

4. 性能测试(Performance Testing)

检测系统是否满足在需求说明书中规定的性能，主要测试软件处理事务的速度，包括：用户响应时间，系统响应时间，外部接口响应时间，CPU的使用，内存的使用等。性能测试通常要使用自动化测试工具来进行。

5. 压力测试(Stress Testing)

压力测试的主要任务就是获取系统正确运行的极限，检查系统在瞬间峰值负荷下正确执行的能力。例如，对服务器做压力测试时就可以增加并发操作的用户数量或者不停地向服务器发送请求；或一次性向服务器发送特别大的数据等。看看服务器保持正常运行所能达到的极限状态。人们通常使用测试工具来完成压力测试，如模拟上万个用户从终端同时登录，这是压力测试中常常使用的方法。

6. 负载测试(Volume Testing)

用于检查系统在使用大量数据的时候正确工作的能力，即检验系统的能力最高能达到什么程度。例如，对于信息检索系统，让它使用频率达到最大，对于多个终端的分时系统，让它所有的终端都开动。在使整个系统的全部资源达到“满负荷”的情形下，测试系统的承受能力。

“负载测试”和“压力测试”经常被混淆，有一个关于打字的比喻可以帮助大家区分这两种测试技术：负载测试将确定一个打字员可以处理多大的文档：压力测试将确定这个打字员每分钟可以键入多少个单词。

7. 易用性测试(Usability Testing)

主要从使用的合理性和方便性等角度对软件系统进行检查，发现人为因素或使用上的问题。在保证足够详细的程度下，用户界面要便于使用，对输入的响应时间和响应方式合理，输出有意义、正确，出错信息能够引导用户去解决问题，文档全面，确切等。易用性测试多数情况下没有一个量化的指标，主观性较强。

8. 安装测试(Installation Testing)

对软件的全部、部分或升级安装/卸载处理过程的测试。保证正确安装硬件和软件，创建所必需的问题和连接，加载所有适当的数据文件，正确设置默认值，与其他系统都能正常工作。

9. 界面测试

界面测试是满足用户需求的最基本测试。主要包括：窗口测试，下拉式菜单和鼠标操作，数据项测试，界面美观性测试等。

10. 配置测试(Configuration Testing)

主要检查计算机系统内各个设备或各种资源之间的相互连接和功能分配中的做法。主要包括：验证全部配置命令的可操作性，软件配置，硬件配置，利用手动或自动方式进行配置状态间的转换。

11. 文档测试 (Documentation Testing)

文档测试主要检查文档的正确性、完备性和可理解性。用户文档中所使用的例子必须在测试中一一试过，确保叙述正确无误。通常使用文档评审和交叉引用检查。

12. 兼容性测试(Compatibility Testing)

兼容性测试就是要检验被测软件与其他软件和硬件相互是否能够正确的交互和实现信息共享。如验证软件产品在不同版本之间的兼容性，包括向下兼容和交错兼容，向下兼容是测试软件新版本保留它早期版本的功能的情况，交错兼容是验证共同存在的两个相关但不同的产品之间的兼容性。

13. 安全性测试(Security Testing)

检查系统对非法侵入的防范能力，检验系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。在进行安全测试时，测试人员假扮非法入侵者，采用各种办法试图突破防线。系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。

14. 恢复测试(Recovery Testing)

主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并恢复“正常”状态，不对系统造成任何伤害。恢复测试首先要通过各种手段，让软件强制性地发生故障，然后验证系统是否能尽快恢复。对于自动恢复，需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性，对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。