软件测试是软件生存周期中必不可少的环节，软件的典型生存周期可以用下图来形容：

软件测试的目的是尽可能早的发现软件缺陷并确保其得以修复，因此软件测试是提高软件质量的重要手段，大量的经验实践证明，软件测试越早参与到软件开发过程中，开发出来的软件质量相对越高，时间和物力也越经济。

根据软件工程的基本理论，多模块程序的测试共包括以下4个层次：

各阶段测试的具体内容会在以后章节具体介绍，下面介绍一下软件测试的经典技术。

软件测试的经典技术分为黑盒测试和白盒测试技术。其中黑盒测试技术忽略程序内部结构，看不到程序的代码细节，只针对程序的功能进行测试，黑盒测试的方法有：

具体方法会在以后章节中具体介绍，敬请期待。

说完黑盒测试，就该介绍白盒测试了，白盒测试也称结构测试，白盒测试深入程序内部结构，分析程序代码结构，因此学好白盒测试，首先要掌握必要的编程语言，比如说Java或者C/C++/C#等。白盒测试的方法有：

白盒测试的方法要涉及到程序图和流程图的设计，逻辑覆盖主要利用程序图，路径覆盖主要利用流程图，测试者必须能够根据程序的代码结构画出相应的程序图和流程图，白盒测试的方法也会在以后的章节中具体介绍。

本节主要介绍一下层次测试的第一步——单元测试。在了解单元测试之前先看一个简单的主程序树状模块图：

所谓模块测试就是在底层进行的测试，如上图，单元测试就是测试上图中紫色的模块。单元测试是整个测试的基础，单元测试中发现的错误约占程序总错误数2/3，单元测试的目标是通过对程序底层模块的静态和动态测试使底层模块达到模块说明的要求。

单元测试主要测试5方面的的问题：

模块的接口测试主要检查数据能否正确地通过模块；数据结构测试目的在于保持程序内部数据的完整性；重要路径测试是单元测试的一项基本任务，主要做好覆盖分析；程序最容易在边界上出错，因此边界条件测试是必不可少的；错误处理测试要点是在工作中发生了错误，其中的错误处理措施是否有效。

单元测试的一般步骤：

编译过程中主要检查对象就是代码中的语法错误；静态分析器检查使用专用工具来进行分析，代码审查主要依靠人工，第二步和第三步都是以检查结构性错误为主的静态分析；动态测试是单元测试的最后步骤，重点是发现单元的功能型错误，可采用白盒测试或者黑盒测试方法进行测试，白盒测试和黑盒测试会在以后进行详细介绍，这里知道有这两种方法即可。

代码评审有两类组织形式：一、办公桌检查，由程序员自己审查自己的代码，仅适用于规模很小的程序。二、以小组会的方式进行，又分为走查和代码会审两种，适用于各种规模的程序。

单元测试不是独立的程序，在多模块程序中，模块之间可以相互调用，单元测试时往往需要为被测模块编制若干模块替身，替身模块仅是真实模块的简化，仅需模拟与被测模块直接相关的一部分功能。

根据经验总结，在单元级发现问题时，问题肯定就在那个单元中，如果在多个单元模块集成时发现缺陷，那么它一定与模块之间的交互有关。在实际情况中，有很少的例外。

好的，本节到此结束，下一节将详细介绍层次测试的第二步——集成测试。

本节主要介绍一下层次测试的第二步——集成测试。上一节我们已经在一定程度上了解了单元测试，这一节我们要讲解的集成测试就是建立在单元测试的基础上，将所有模块按照设计要求组装成一个完整的系统而进行的测试，也称为联合测试或组装测试。

集成测试应由独立于开发人员的测试小组负责实施。集成测试重点测试所有模块的接口部分，需设计测试过程所使用的驱动模块和桩模块，在单元测试时为被测试模块做的上下级模块做的替身分别称为驱动模块和桩模块。测试方法以黑盒为主。集成测试的方案大致可分为有三种，分别是自顶而下、由底向上以及从两头逼近的混合模式。看下面程序模块：

1、自顶而下

自顶而下的测试从顶模块开始，沿被测程序的结构图逐步向下测试，按照移动路线的差异，又可区分为两种不同的实施步骤，分别是先广后深和先深后广两种，以上图为例，先广后深的组装顺序：

M1——M2——M3——M4——M5——M6——M7——M8

先深后广的组装顺序：

M1——M2——M5——M8——M6——M3——M4——M7

自顶而下的测试要使用桩模块，如下图显示了先深后广的测试步骤：

其中，S2、S3、S4、S5、S6和S8分别是M2、M3、M4、M5、M6和M8的替身。

2、由底而上

由底而上模式的典型步骤：

• 从下层找出一个没有下层模块作为开始模块，由下向上逐步添加新模块，组成程序中的一个子系统或模块群。

• 从另一子系统或模块群中选出另一个无下级模块开始，按步骤1进行组成一个新的子系统。

• 重复上一步，直到得出所有子系统，最后组装成完整的系统。

例图程序模块可能的组装顺序：

M8——M5——M6——M2

M7——M4——M3——M1

3、混合模式

混合模式是以上两种模式的综合，其一般步骤：

• 对上层模块采取自顶向下测试

• 对关键模块或子系统采取由底向上测试

此种模式兼有以上两种模式的优点，应用也最广泛。

以上三种模式是从一个模块开始，测一次添一个模块，组装程序类似于滚雪球，所以统称为渐增式。三种模式都有各自的优缺点，综合起来，混合模式正在与扬长避短，综合了两种模式的优点，建议多采用混合模式进行总装。

好的，本节到此结束，下一节将详细介绍层次测试的第三步——确认测试。

经过了单元测试和集成测试的学习，组装测试已经完成，接下来要进行的就是确认测试，那么本节就主要介绍确认测试。确认测试又称有效性测试或合格性测试，其任务是验证系统的功能、性能等特性是否符合需求规格说明。如下图：

有效性测试和软件配置审查是确认测试最重要的两项工作。

确认测试一般是在模拟的环境或者就是开发环境下运用黑盒测试法，按照需求说明书，验证软件功能、特性是否与用户需求一致。经过确认测试后，可能有以下两种情况：

• 软件的功能、性能及其他要求均已经满足需求说明书，可能被认为是合格的软件。

• 发现软件与需求说明书有较大的偏离，得到一个缺陷清单。这样的错误，工作量非常大，往往很难在交付期以前把发现的缺陷修复过来。此时需要开发部门和用户一起协商进行解决。

软件配置审查也称配置审计，指软件工程过程中所产生的所有信息项：文档、报告、程序、表格、数据等。此阶段主要复查SCI是否齐全，检查软件的所有文档资料的完整性和正确性，然后对发现的缺陷，进行修复，最后编排好目录，以便后期维护顺利进行。

确认测试继集成测试之后进行，其目的在于确认组装完毕的程序是否满足需求说明书。确认测试是由软件开发单位组织实施的最后一项开发活动，测试结束后，软件就交付验收了，因此开发单位必须十分重视这项工作，和集成测试一样，也应由独立测试小组负责实施。

好的，本节到此结束，下一节将详细介绍层次测试的第四步——系统测试。

经过了前面的总结，今天该到层次测试的最后一步——系统测试了，系统测试是验收工作的一部分，应由用户单位组织实施。软件开发单位应该为系统测试创造良好的条件，负责回答和解决测试中可能发现的一切质量问题。

系统测试是在更大范围内进行测试。除被测试程序外，系统还可能包括硬件和原有的其他软件。系统测试的目的在于把软件产品顺利安装到系统中以后，保证软件与系统其余部分协调工作，并且符合软件需求说明书的要求。

下面说一下集成系统的测试，下图是集成系统测试的测试内容：

其中：

功能测试主要检查软件功能是否符合需求说明的要求，基本方法是构造一些合理的输入，检查是否得到期望的输出，假如输入范围是无限的，关键在于寻找等价区间，还有一种有效的测试方法就是边界值测试，会在以后具体介绍。

性能测试是用来测试软件在集成系统中的运行性能，特别是针对实时系统和嵌入式系统，常常与强度测试结合起来进行。

安全性测试是为了保证安装在系统内的保护机制能在实际运行中保护系统不受非法侵入等非法行为的干扰，测试过程中需要设置一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。

恢复测试目的在于保证系统受到某些外部事故的破坏时能够重新恢复正常工作，可以通过各种手段，强制性地使软件出错而不能正常工作，进而检验系统恢复能力。

强度测试主要是在一些极限条件下，检查软件系统的运行情况，例如一些超常数量的输入数据、超常数量的用户、超常数量的网络连接，这对于了解软件系统的性能和可靠性、健壮性具有十分重要的意义。

文档测试主要检查文档的正确性、完整性和可理解性。正确性指不要把软件的功能和操作写错，也不允许文档内容前后矛盾；完整性是指文档不可以虎头蛇尾，更不允许漏掉关键内容；可理解性指文档内容让大众用户看得懂、能理解。

作者：6个小石头

原文链接：https://blog.csdn.net/LiuJiuXiaoShiTou/article/details/72808451