集成测试学习.pptx

《集成测试学习.pptx》由会员分享，可在线阅读，更多相关《集成测试学习.pptx（39页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1 单元测试单元测试集成测试集成测试 系统测试系统测试验收测试验收测试按阶段进行测试是一种基本的测试策略按阶段进行测试是一种基本的测试策略测试的4个阶段第1页/共39页2软件测试的层次与软件开发的关系需求分析设计编码单元测试集成测试确认测试系统测试第2页/共39页3本节要点集成测试的定义集成测试的目的系统集成的模式与方法集成测试思路第3页/共39页4集成测试的定义 集成测试（Integration Testing），也叫组装测试、联合测试、子系统测试或部件测试。集成测试是在单元测试的基础上，将所有模块按照设计要求（如集成方案）组装成为子系统或系统，进行测试。在集成测试之前，单元测试已经完成，并

2、且集成测试所使用的对象应当是已经经过单元测试保证了的单元。第4页/共39页5本节要点集成测试的定义集成测试的目的系统集成的模式与方法集成测试思路第5页/共39页6集成测试的目的实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。在某些局部反映不出的问题，在全局上很可能暴露出来，影响功能的实现。因此集成测试应当考虑以下问题：在把各个模块连接起来时，穿越模块接口的数据是否会丢失；各个子功能组合起来，能否达到预期要求的父功能；一个模块的功能是否会对另一个模块的功能产生不利的影响；全局数据结构是否有问题，会不会被异常修改；单个模块的误差累计起来，是否会放大，从而达到不可接受的程度。

3、第6页/共39页7集成测试的目的因此，在单元测试后，系统测试前，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的子系统或系统。一般可以把集成测试划分成三个级别：模块内集成测试子系统内集成测试子系统间集成测试第7页/共39页8本节要点集成测试的定义集成测试的目的系统集成的模式与方法集成测试思路第8页/共39页9系统集成的模式与方法软件集成测试前的准备人员安排测试计划测试内容集成模式测试方法第9页/共39页10集成测试的模式非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。渐增式测试模式：把下一个要测试的模块同已经测试好的

4、模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。第10页/共39页11两种测试方法的比较非渐增式测试方法需要编写的软件较多，工作量较大；渐增式测试方法开销小。渐增式测试方法发现模块间接口错误早；而非渐增式测试方法晚。非渐增式测试方法发现错误，较难诊断；而使用渐增式测试方法，如果发生错误则往往和最近加进来的那个模块有关。渐增式测试方法测试更彻底 渐增式测试方法需要较多的机器时间 使用非渐增式测试方法，可以并行测试。在实际测试中，应该将两种方法有机集合起来。第11页/共39页12渐增式测试当使用渐增式测试方法时，具体有自顶向下和自底向上两种方法。第12页/共39页13自顶向下

5、和自底向上集成方法 驱动程序驱动程序/驱动模块驱动模块（driver），用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。桩程序桩程序/桩模块桩模块（stub），），也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口第13页/共39页14自顶向下法从主控模块（“主程序”）开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。在组装过程中，可以使用深度优先的策略，或宽度优先的策略。第14页/共39页

6、15自顶向下法(Top-down Integration)第15页/共39页16自顶向下法(Top-down Integration)步骤：(1)对主控模块进行测试，测试时用存根程序代替所有直接附属于主控模块的模块。(2)根据选定的结合策略（深度优先或宽度优先），每次用一个实际模块代替一个存根程序（新结合进来的模块往往又需要新的存根程序）(3)在结合下一个模块的同时进行测试(4)为了保证加入模块没有引进新的错误，可能需要进行回归测试（即，全部或部分地重复以前做过的测试）。从第2步开始不断地重复进行上述过程，直至完成。第16页/共39页17自底向上法自底向上测试从“原子”模块（即在软件结构最低层

7、的模块）开始组装和测试，具体策略是：(1)把低层模块组合成实现某个特定的软件子功能的族。(2)写一个驱动程序（用于测试的控制程序），协调测试数据的输入和输出。(3)对由模块组成的子功能族进行测试。(4)去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能族。循环(2)-(4)步第17页/共39页18自底向上法(Bottom-up Integration)自底向上法的主要优缺点第18页/共39页19两种策略的比较“自顶向下”法的主要优点：不需要测试驱动程序，能够在测试阶段的早期实现并验证系统的主要功能，而且能在早期发现上层模块的接口错误。“自顶向下”法的主要缺点：需要存根程序

8、，可能遇到与此相联系的测试困难，低层关键模块中的错误发现较晚，而且用这种方法在早期不能充分展开人力。“自底向上”法的优缺点与“自顶向下”法刚好相反。第19页/共39页20混合策略在具体测试中，采用混合策略：(1)改进的自顶向下法：基本使用“自顶向下”法，但在测试早期，使用“自底向上”法测试少数的关键模块。(2)混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者相结合。第20页/共39页21混合策略(Modified Top-down Integration)混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向

9、上”法，两者相结合 第21页/共39页22大棒集成方法(Big-bang Integration)采用大棒集成方法,先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试。因为所有的模块一次集成的，所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用，适合在规模较小的应用系统中使用。第22页/共39页23三明治集成方法(Sandwich Integration)采用三明治方法的优点是：它将自顶向下和自底向上的集成方法有机地结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。采用这种方法的主要缺点是：在真

10、正集成之前每一个独立的模块没有完全测试过。第23页/共39页24改善的三明治集成方法改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底。第24页/共39页25几种集成方法性能的比较 自底向上 自顶向下 混合策略 大棒 三明治 改进三明治集成早早早晚早早基本程序能工作时间晚早早晚早早需要驱动程序是否是是是是需要桩程序否是是是是是工作并行性中低中高中高特殊路径测试容易难容易容易 中等容易计划与控制容易难难容易 难难第25页/共39页26本节要点集成测试的定义集成测试的目的系统集成的模式与方法集成测试思路第26页/共39页27集成测试思路是不是把两个模块

11、连在一起，然后采用单元测试的技术，测试这个更大的模块？第27页/共39页28集成测试思路集成测试关注的是模块之间的接口。那么可以将“接口”作为切入点 第28页/共39页29集成测试思路纵观模块之间的接口，我们可以归纳为以下几种类型 通信协议 调用关系 文件、数据库、队列、第三方中间件等 共享资源同步 第29页/共39页30集成测试思路通信协议：两个模块之间通信采用的是标准的或者自定义的（网络）协议；协议中即包含数据部分，又包含控制部分；有些实现将数据与控制分离，如FTP；而大部分实现将数据与控制通过一条链路来传递，往往通过不同的消息包进行分离。第30页/共39页31集成测试思路调用关系：模块A

12、调用模块B，实际上是由模块A向模块B发出了一条控制指令，这里数据传递体现的不是很明显，往往体现为参数与返回值，它们可以认为是控制的副本。第31页/共39页32集成测试思路文件、数据库、队列、第三方中间件等：表现的主要是数据的传递，其中的控制体现的不明显。第32页/共39页33集成测试思路共享资源：比如共享一段“存储区域”，其中涉及的关键资源主要是“锁”了；这样的两个模块在运行时往往分布到不同的进程或者线程中，表现为对资源的竞争，以及数据的共享。第33页/共39页34集成测试思路同步：一个模块的运行需要另外一个模块的触发，双方往往存在“信号”等通知机制，也可以理解为一种特殊的控制方式。第34页/

13、共39页35集成测试思路我们可以将被测系统归类（以上的分类），找出其中的数据接口与控制接口 第35页/共39页36集成测试思路首先，将数据接口与控制接口分解需要传递哪些数据？存在哪些控制指令？然后，找出数据与指令中的变数所在；如数据（协议包）中的字段的取值，指令的参数变化等；其次，将变数划分等价类，找出每类的代表，就是测试数据目标是：让每类数据流与控制流均通过接口一次，从而实现接口测试的完全性；最后，就是考虑如何生成这些测试数据了。往往需要对应到集成后“大模块”的输入与输出。第36页/共39页37集成测试思路上面的内容更多的关注了实现。下面要考虑另外一个侧面业务。模块之间的联系（接口）往往是为

14、了体现业务上的关联。关联本身也是有很多属性的。如关联点（每个模块）都存在一个角色，关联有多重性（multiplicity）即模块A在运行时可能对应多个模块B的实例。所以，测试的另外一个切入点：模块的集成能否准确体现业务上的关联？各个模块是否具备其角色的全部属性和接口，模块之间的关联关系如何打破？关联的多重性是否有效？第37页/共39页38集成测试思路当然，集成测试不会太关心业务或者需求，那是系统测试的事了。但此时想想，往往能够得到意外的收获。太多的关注功能，往往忽略其他。有时我们不得不考虑接口的性能，尤其对于系统关键接口。接口的性能测试越早进行越好。如果等到系统测试时做，可能接口外面封装了太多的代码，影响性能问题的精确定位。第38页/共39页39感谢您的观看！第39页/共39页