软件测试方法和技术第5章单元测试与集成测试第五章单元测试与集成测试5.1单元测试的目标和任务5.2静态测试5.3动态测试5.4
代码评审案例5.5分层单元测试5.6单元测试工具5.7系统集成的模式与方法5.5分层单元测试Java常用的三个框架：St
ruts+Hibernate+SpringStruts：是一个在JSPModel2基础上实现的MVC框架，其主要的设计理念是通
过控制器将表现逻辑和业务逻辑解耦，以提高系统的可维护性、可扩展性和可重用复性。（1）视图：视图部分主要由JSP页面组成，其中没有流
程逻辑、业务逻辑和模型信息，只有标记。（2）控制器：Struts中的Controller主要是其自身提供的ActionServle
t。ActionServlet接收所有来自客户端的请求并根据配置文件(struts-config.xml)中的定义将控制转移到适当
的Action对象。（3）模型：Struts没有定义具体Model层的实现，Model层通常是和业务逻辑紧密相关的，有持续化的要求
。5.5分层单元测试Hibernate：对象关系映射框架，对JDBC使用进行了封装，这样可以随心所欲使用对象编程思维来操纵数据库
。5.5分层单元测试Spring：Spring是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是
其分层架构，分层架构允许您选择使用哪一个组件，同时为J2EE应用程序开发提供集成的框架。Spring框架是一个分层架构，由
7个定义良好的模块组成。Spring模块构建在核心容器之上，核心容器定义了创建、配置和管理bean的方式。5.5分层单元
测试当对依赖于其他外部系统的代码进行单元测试时，能有效地隔离测试对象和外部依赖，以便管理测试对象的状态和行为。使用Mock对象是
隔离外部依赖的一个有效方法。Mock就是模型，模拟被测试对象关联的对象及测试数据。5.5分层单元测试基于Struts框架的测试
：StrutsTestCase是JunitTestCase类的扩展。所有的StrutsTestCase单元测试类都源于模拟测试M
ockStrutsTestCase或容器内测试的CactusStrutsTestCase。（1）MockStrutsTestCas
e：是对JunitTestCase基类扩展，从而实现对StrutsAction对象的模拟测试。它借助Mock对象方法来模拟Se
rvlet容器、为ActionForm子类提供相应方法设置请求路径、请求参数。（2）CactusStrutsTestCase：是
对CactusServletTestCase基类的扩展，从而实现对StrutsAction对象的模拟测试。5.5分层单元测试
业务逻辑层，一般用于处理比较复杂的逻辑，也用于DAO层的数据操作。对于简单的业务逻辑，可以用Junit测试，而对于复杂逻辑，可以
用Mock对象来模拟测试。如果测试对象依赖于DAO的代码，可以采用mockobject方法。测试对象变成了DAO本身，可以使用D
bUnit。使用DbUnit，开发人员可以控制测试数据库的状态，包括准备好初始化数据以及将数据库状态恢复到测试前的状态。DbUn
it是为数据库驱动、对JUnit扩展的解决方法Servlet的单元测试HttpUnit可提供一个模拟的Servlet容器，让
Servlet代码不需要发布到Servlet容器（如tomcat）就可以直接测试使用HttpUnit测试Servlet时，先创建一
个ServletRunner的实例，负责模拟Servlet容器环境。如果只测试单个Servlet,可直接使用registerSer
vlet方法注册其Servlet，如果需要配置多个Servlet，需编写自己的web.xml，然后在初始化ServletRunne
r时将其作为参数传给ServletRunner的构造器示例：单元测试检查表关键测试项是否已纠正有无任何输入参数没有使用？有无任何
输出参数没有产生？有无任何数据类型不正确或不一致？有无任何算法与PDL或功能需求中的描述不一致？有无任何局部变量使用前没有初始化？
有无任何外部接口编码错误？即调用语句、文件存取、数据库错误。有无任何逻辑路径错误？该单元是否有多个入口或多个正常的出口？额外测试
项该单元中有任何地方与PDL与PROLOG中的描述不一致？代码中有无任何偏离本项目标准的地方？代码中有无任何对于用户来说不清楚的错
误提示信息？如果该单元是设计为可重用的，代码中是有可能妨碍重用的地方？第五章单元测试与集成测试5.1单元测试的目标和任务5.2
静态测试5.3动态测试5.4代码评审案例5.5分层单元测试5.6单元测试工具5.7系统集成的模式与方法集成测试的定义集
成测试的流程1集成测试的方法2集成测试策略345.7.1集成测试的定义集成测试（IntegrationTesting）又称为
组装测试，是将所有已经通过了单元测试（或者是假定已经通过了单元测试的前提下）的各个软件单元按照设计要求组装成系统或者子系统，然后对
这些系统或者子系统进行测试的测试阶段。集成测试就是测试这些软件单元之间是否能够正确地进行交互的测试。5.7.1集成测试的定义集成
测试主要任务:集成测试关注的是组装系统或者子系统的各个软件单元之间的交互，测试的主要任务是发现软件单元之间的接口、接口之间的数据传
递关系和其它与接口有关的各种错误，以及各个软件单元组合后是否实现预期的功能。5.7.1集成测试的定义集成测试遵循原则:（1）集成
测试的策略选择应当综合考虑质量、成本和进度之间的关系；（2）集成测试应当尽早开始，并以总体设计为基础；（3）在模块和接口的划分上，
测试人员应当和开发人员进行充分的沟通；5.7.1集成测试的定义集成测试遵循原则:（4）当测试计划中的结束标准满足时，集成测试才
能结束；（5）当接口发生修改时，涉及的相关接口必须进行再次测试；（6）集成测试应该根据集成测试计划和方案进行，不能随意测试；（7）
项目管理者应该保证测试用例经过审核；（8）测试执行结果应当如实记录。5.7.2集成测试流程一个测试从开始到执行要遵循一个过程，
不同的组织对这个过程的定义有所不同。根据集成测试不同阶段的任务，可以把集成测试划分成五个阶段，即：计划阶段、设计阶段、实施阶段、执
行阶段和评估阶段。5.7.2集成测试流程计划阶段：集成测试计划的制定对集成测试的顺利实施起着至关重要的作用。集成测试计划的制定
通常安排在概要设计确定之后，在制定集成测试计划时候，要参考需求规格说明书、概要设计文档以及软件开发的计划来制定。通常集成测试计划阶
段包括八个内容。5.7.2集成测试流程计划阶段：①确定被测对象和测试的范围；②评估集成测试的被测对象的数量以及难度，也就是
评估集成测试的工作量；③确定集成测试工作中角色分工和划分工作任务；④标识出集成测试中各个阶段的时间、任务、约束等条件；5.7.
2集成测试流程计划阶段：⑤考虑集成测试中可能会出现的风险和应急计划；⑥考虑和准备集成测试需要的测试工具、测试器、测试环境等资
源；⑦考虑外部技术支援的力度和深度，以及相关培训安排；⑧定义集成测试完成标准。5.7.2集成测试流程设计阶段：在制定了周密详
实的集成测试计划之后，通常在详细设计开始时就可以着手进行集成测试，把需求规格说明书，概要设计，集成测试计划文档作为参考依据。集成测
试的设计阶段包括以下七个内容。①被测对象结构分析；②集成测试模块分析；5.7.2集成测试流程设计阶段：③集成测试接口分析；
④集成测试策略分析；⑤集成测试工具分析；⑥集成测试环境分析；⑦集成测试工作量估计和安排。5.7.2集成测试流程实施阶段：
集成测试必须等到软件单元的编码完成之后才能够开始。在集成测试实施的过程中，需要参考需求规格说明书，概要设计，集成测试计划，集成测试
设计等相关文档来进行。集成测试实施的前提条件是软件详细设计阶段的评审已经通过，通常集成测试的实施阶段包括以下几个内容。5.7.2
集成测试流程实施阶段：①集成测试用例设计；②集成测试规程设计；③集成测试代码设计；④集成测试脚本开发；⑤集成测试工具开发
或选择。5.7.2集成测试流程执行阶段：测试人员在单元测试完成后就可以开始执行集成测试，这也是集成测试过程中一个比较简单的阶段。
当然，必须按照相应的测试规程，借助集成测试工具，并把需求规格说明书，概要设计，集成测试计划、集成测试设计，集成测试用例、集成测试规
程，集成测试代码、集成测试脚本作为测试执行的依据来执行集成测试用例。5.7.2集成测试流程执行阶段：测试执行的前提条件就是
单元测试已经通过评审。当测试执行结束后，测试人员要记录下每个测试用例运行后的结果，填写集成测试报告，最后提交给相关人员评审。5.7
.2集成测试流程评估阶段：当集成测试执行结束后，需要召集相关人员，如测试设计人员，编码人员，系统设计人员等对测试结果进行评
估，确定是否通过集成测试。5.7.3集成测试方法在开始集成测试时，首先要选择集成测试的方法，集成测试的方法有很多，例如：非增量
式集成测试、增量式集成测试、三明治集成测试、核心集成测试、分层集成测试和基于使用的集成测试等。在实际的应用中，常用的是非增量式集成
测试和增量式集成测试两种测试方法。5.7.3集成测试方法非增量式集成也称为大爆炸集成或一次性集成。采用这种方法，是在对所有的软
件单元进行了单元测试之后，一次性把所有这些软件单元集成在一起，组装成要求的软件系统或者是子系统来进行测试。基本的做法就是将所有已经
通过单元测试的软件单元，一次性的组装到被测的系统中，完全不考虑组成系统的软件单元之间可能会存在的联系和发生错误的风险。5.7.3
集成测试方法（1）非增量式集成测试的测试步骤例：采用非增量式集成测试方法对右侧程序结构进行集成测试。5.7.3集成测试方法（1）
非增量式集成测试的测试步骤①对软件单元A进行测试软件单元A调用了两个软件单元，它们是软件单元B和软件单元C，在对软件单元A进行测
试的时候，就需要为软件单元A设计开发两个桩程序（例如可以是S1和S2）。对软件单元A进行单元测试，直到测试通过。5.7.3集成测
试方法（1）非增量式集成测试的测试步骤②对软件单元B进行测试软件单元B调用了一个软件单元D，与此同时也被软件单元A调用，因此需
要给软件单元B设计开发一个驱动程序和桩程序（例如可以是S3和D1）。对软件单元B进行单元测试，直到测试通过。5.7.3集成测试方
法（1）非增量式集成测试的测试步骤③对软件单元C和软件单元D进行测试软件单元C被软件单元A调用，软件单元D被软件单元B调用，两
者都是只被一个软件单元调用，而且两者都没有调用其他的软件单元，因此需要给软件单元C和软件单元D分别设计开发一个测试用驱动模块。对软
件单元C和D进行单元测试，直到测试通过。5.7.3集成测试方法（1）非增量式集成测试的测试步骤5.7.3集成测试方法非增量式集
成测试优点：①非增量式集成测试可以并行地测试所有的软件单元，能够加快测试工作的速度，充分利用了人力和物力资源；②非增量式集成
测试需要用到测试用例数量较少，所以对设计测试用例的工作量相对较小；③非增量式集成测试的测试方法较为简单，容易执行。5.7.3集
成测试方法非增量式集成测试缺点：①非增量式集成测试是将软件单元一次性集成起来，如果集成的软件单元数量较多，集成测试过程中可能会
出现较多的错误，而且因为一次性集成，很难判断出现错误的位置。而且，在对某个软件单元的某处错误进行修改之后，可能会在系统的其它地方带
来新的错误，这样给整个系统的修正会带来较大的难度；5.7.3集成测试方法非增量式集成测试缺点：②非增量式集成测试因为是一次性
集成，各个软件单元之间的接口没有进行充分的测试，因此有可能会遗漏一些潜在的接口错误，即使在集成测试通过，这些接口可能也会存在问题。
5.7.3集成测试方法非增量式集成测试的适用范围①适用于功能单一、所组成的软件单元不多，运行逻辑较为简单的，并且每个软件单元
都经过充分的单元测试的小型软件项目；②适用于那些在前期已经有较为稳定的产品的项目，而且只需要修改增加为数不多的几个软件单元。5
.7.3集成测试方法（2）增量式集成自顶向下集成自底向上集成“三明治”集成5.7.3集成测试方法自顶向下集成自顶向下集成方法
是目前测试人员广泛应用的集成测试方法。采用这种方法是从主控制模块即顶层控制模块开始，按照与在被测系统设计时的相同的思路对被测的软件
系统进行测试，来验证被测系统的稳定性、可靠性。5.7.3集成测试方法基本的做法就是将被测系统从主控制模块开始，顺着程序的控制
层次向下移动，逐渐把各个模块组合起来，把所有附属于主控制模块的所有软件单元组装到整个程序结构中，在整个测试过程中或者使用深度优先的
策略，或者使用广度优先的策略。5.7.3集成测试方法深度优先集成是指顺着系统的层次结构的纵向方向，按照一个主线路径，自顶向下地把
所有模块集成到结构中进行测试，主线路径的选择可以是由测试人员任意选择。广度优先集成则是指顺着系统的层次结构的横向方向，把每一层中所
有直接隶属于上一层的所有模块逐渐集成起来进行测试，一直到系统的最底一层。5.7.3集成测试方法例:采用自顶向下的集成测试策略
，在测试过程中用深度优先的方法进行测试，并给出详细的测试过程。①确定所有的将要集成在一起的软件单元都已经通过了单元测试；②选择
的集成测试的主线路径，在这里我们选择从左至右的集成主线路径；5.7.3集成测试方法③对主控制软件单元A进行测试，使用桩程序S1
和S2来代替unitB和C，然后对软件单元A进行测试5.7.3集成测试方法④使用实际的软件单元B代替桩程序S1，并使用S3代替
软件单元D，然后对软件单元B进行测试；测试B5.7.3集成测试方法⑤使用实际的软件单元D代替被调用模拟子模块S3，然后对软件单
元D进行测试:5.7.3集成测试方法⑥使用实际的软件单元C代替被调用模拟子模块S2，然后对整个软件系统进行测试:5.7.3集
成测试方法自顶向下增量式集成测试优点:①在集成测试的过程当中，可以首先验证主要的控制和判断点，即主控软件单元，在功能划分合理的
程序模块结构中，对于较高层次中的主控软件单元，可以首先做出测试，能够提前发现问题，以便及时对程序作出相应的修改，减少人力资源消耗；
5.7.3集成测试方法自顶向下增量式集成测试优点:②选择深度优先的集成方式，可以首先实现和验证一个完整的软件功能，能够首先对
逻辑输入的分支进行组装和测试，检测出潜在的错误和缺陷，验证其功能的正确性，为之后的主要分支的组装和测试提供保证；③能够较早的验
证软件功能的可用性，给软件的开发者和软件的用户奠定了信心。5.7.3集成测试方法自顶向下增量式集成测试缺点：①采用自顶向下的
集成测试方法，在测试时需要针对每个软件单元的下层软件单元设计桩模块，对于桩模块的开发以及维护成本较大；5.7.3集成测试方法自顶
向下增量式集成测试缺点：②在当底层的软件单元的发生变更时（如：需求发生变化导致软件单元发生变化），这种变更可能会影响到整个软件
中的其他软件单元，可能会需要修改整个软件系统中的多个上层软件单元，进而容易破坏之前构造的已经构造好的测试包；5.7.3集成测试方
法自顶向下增量式集成测试缺点：③随着自顶向下集成测试的进行，新的底层软件单元不断加入，这会让整个系统的会变得越来越复杂，这可能会
导致之后加入的底层软件单元的测试不够充分;5.7.3集成测试方法自顶向下增量式集成测试缺点：④自顶向下增量式集成测试的适用
范围。对于大多数采用结构化编程方法的，并且体系结构相对简单的软件系统来说，自顶向下的增量式集成测试方法都是较为适用的。对于大型的复
杂的软件系统通常会使用多种集成测试的方法进行测试。5.7.3集成测试方法自顶向下增量式集成测试适用性判别:通过以下四个方面来
判断被测软件系统是否是适合使用自顶向下的增量式集成测试方法：①被测软件系统的结构较为清晰，控制结构较为稳定；②被测软件系统中
的高层模块接口定义较为准确，变化的可能性较小；5.7.3集成测试方法自顶向下增量式集成测试适用性判别:③被测软件系统中的低层模
块接口定义还未清晰或有较大可能会因为需求发生变更等原因而发生变化；④开发者和用户希望尽可能早看到被测软件系统较为完整功能。5.
7.3集成测试方法自底向上集成:自底向上集成：就是从被测系统的层次结构的最底层软件单元开始进行组装和集成的测试方式。从而验证被测
系统的稳定性和可靠性。在整个自底向上的集成测试过程中只需要设计开发相应的测试驱动程序即可。5.7.3集成测试方法自底向上集成用例
：例：采用自底向上的集成测试策略，在测试过程中仍然采用深度优先的方法进行测试，并给出详细的测试过程。5.7.3集成测试方法自底向
上集成用例:（1）确定所有的将要集成在一起的软件单元都已经通过了单元测试；（2）设计开发驱动模块D1，测试软件单元D及D1；5.7
.3集成测试方法自底向上集成用例:（3）用驱动模块D2，用来模拟软件单元A，模块B和模块D集成起来进行测试；（4）用驱动模块D3
，模拟软件单元A，测试C和D3；5.7.3集成测试方法自底向上集成用例:（5）把软件单元A与其他软件单元D一起集成，对整个系统进
行测试。5.7.3集成测试方法自底向上集成优点①能够尽早验证底层软件单元的功能。任何一个底层软件单元通过单元测试之后，就可以开
始进行集成测试；②在集成测试开始时，可以同时对系统层次结构中的每个分支集成测试，这样较大提高了测试的效率；③减少了设计开发测试
用被调用模拟子模块的工作量；④更容易对被测系统的错误进行定位。5.7.3集成测试方法自底向上集成缺点：①只有在被测系统的最顶
层的最后一个软件单元组装起来之后才能看到整个系统的框架；②测试用驱动模块的开发以及维护工作量大；③由于顶层的软件单元要到集成测
试的最后阶段才能进行测试，因此不能及时发现高层模块设计上的错误，对于那些在整个体系结构中控制结构非常关键的产品来说，受到的影响就更
大；5.7.3集成测试方法自底向上增量式集成测试的适用范围对于大多数采用结构化编程方法的，并且体系结构相对简单的软件系统来说自
顶向下的增量式集成测试方法都是较为适用的。5.7.3集成测试方法自底向上增量式集成测试适用性判别：通过以下几个方面来判断被测软
件系统是否是适合使用自底向上的增量式集成测试方法。①底层模块接口比较稳定的软件系统；②高层模块接口可能会存在变更比较频繁的软件
系统；③底层模块开发和单元测试工作完成较早的产品。5.7.3集成测试方法总结-自底向上式与自顶向下式比较自顶向下集成测试相比
自底向上集成方式，能够做到逐步求精，而且因为是按照被测系统的设计结构来进行测试的，因此在集成测试开始时测试人员就能了解到整个被测系
统的整个框架，但是在测试过程中需要进行桩程序的设计开发工作，桩程序中表示测试数据会较为困难，桩程序开发难度较大。5.7.3集成测
试方法总结-自底向上式与自顶向下式比较自底向上集成测试由于模拟了所有调用驱动模块以及调用的参数，因此在测试数据的生成上没有问题，
克服了自顶向下集成测试测试数据表示的问题，但这种测试方法是从被测系统的最底层开始测试，因此必须要等到最后一个顶层模块集成之后，才能
够得到整个系统的测试结果，这种测试方法更适用于关键模块在底部的系统。5.7.3集成测试方法以上学习的三种集成测试的方法都是在基
于对被测系统的功能分解上进行的。非增量式集成测试（大爆炸集成测试）方法简单易行，但不容易发现组装系统的各个软件单元之间接口中的错
误，很多缺陷可能在集成测试的最后阶段才会被发现。5.7.3集成测试方法增量式集成测试方法来说，由于缺陷是分布在不同的模块中的，
能够及早地发现错误，定位错误和修改错误，并且可以对模块反复验证。就以上所述的优点来说，增量测试的效果会比非增量式测试效果好，但是
增量式测试方法需要设计开发驱动程序和桩程序。5.7.3集成测试方法“三明治”集成“三明治”集成（也称为混合测试方法）是一种混合
增量式的测试方法，综合了自顶向下和自底向上两种集成方法的优点。5.7.3集成测试方法“三明治”集成测试方法基本步骤①确定以哪一
层作为运用“三明治”集成测试方法的分界层；②对分界层及其所在层下面的各个层次使用自底向上的集成测试方法；③对分界层上面的各个
层次使用自顶向下的集成测试方法；④对被测系统进行整体测试。5.7.3集成测试方法在应用“三明治”集成测试方法进行测试工作的时
候，应该注意尽量减少设计开发测试用驱动模块和测试用被调用模拟子模块的数量。5.7.3集成测试方法“三明治”集成用例例：使用“三明
治”集成测试的方法进行测试。5.7.3集成测试方法①确定以软件单元B所在层为分界层；②分别对软件单元E和软件单元F进行单元测
试；③对软件单元G进行单元测试；④对软件单元A进行测试；⑤把软件单元E、F同软件单元B集成；⑥把软件单元D、G集成到一起进
行测试；⑦对整个被测系统进行集成测试。5.7.3集成测试方法5.7.3集成测试方法“三明治”集成测试优缺点优点：①同时具
有自顶向下集成测试和自底向上集成策略的优点；②通过一定集成技巧，可以减少被调用模拟子模块和驱动模块的开发。缺点：在被集成之前
，中间层不能够尽早得到充分的测试。5.7.3集成测试方法“三明治”集成测试适用性范围“三明治”集成测试适用范围广泛，大多数的软
件开发项目都可以应用这种集成测试的方法。5.7.4集成测试策略（1）为系统运行设计测试用例为系统运行设计测试用例可使用的主要
测试方法有等价类划分、边界值分析法和基于决策表的测试。（2）为正向测试设计测试用例作为正向集成测试的一个重点就是验证这些集成后的
模块，是否按照设计实现了预期的功能。基于这样的测试目标，可以直接根据概要设计文档导出相关的用例。5.7.4集成测试策略（3）为
逆向测试设计测试用例在集成测试中的逆向测试包括分析被测接口是否实现了需求规格没有描述的功能，检查规格说明中可能出现的接口遗漏或者
判断接口定义是否有错误，以及可能出现的接口异常错误，包括接口数据本身的错误，接口数据顺序错误等。可使用的主要测试分析技术有错误猜测
法，基于风险的测试、基于故障的测试、边界值分析、特殊值测试和状态转换测试。5.7.4集成测试策略（4）为满足特殊需求设计测试用例在大部分软件产品的开发过程中，模块设计文档就已经明确地支出了接口要达到的安全性指标、性能指标等，在对模块进行单元测试和集成测试阶段就应该开展对满足特殊需求的测试，为整个系统是否能够满足这些特殊需求把关。5.7.4集成测试策略（5）为高覆盖设计测试用例与单元测试所关注的覆盖重点不同，在集成测试中我们关注的主要覆盖重点是功能覆盖和接口覆盖，通过对集成后的模块进行分析，来判断哪些功能以及哪些接口没有覆盖到来设计测试用例。可使用的主要测试分析技术有功能覆盖分析和接口覆盖分析。5.7.4集成测试策略（6）测试用例补充在软件开发的过程中，难免会因为需求变更等原因，有功能增加、特性修改等情况发生，因此不可能在测试工作的一开始就能百分之一百地完成所有的集成用例的设计，这就需要在集成测试阶段能够及时跟踪项目变化，按照需求增加和补充集成测试用例，保证进行充分的集成测试。5.7.4集成测试策略（7）注意事项在集成测试的过程中，要注意考虑软件开发成本，进度和质量这三个方面的平衡，不能故此失彼，也就是说要重点突出（在有限的时间内进行穷尽的测试时不可能的）。HyperSQLDatabaseEngine(HSQLDB)HSQLDB是一个轻量级的纯Java开发的开放源代码的关系数据库系统，其体积小，占用空间小，使用简单，支持内存运行方式等特点 |
|
