软件测试与质量保证 课件 第9、10章 单元测试、集成测试

第9章单元测试本章内容单元测试概述单元测试的内容单元测试策略单元测试过程单元测试计划单元测试工具2程序员的难题3开发的模块出现问题，很难定位，已经熬了几个通宵了！！！怎么办？刚改正了一个BUG，过没几天，又发现了新问题！！！程序总在出问题，联调了几个月，还是问题不断！！！高质量的程序高质量的程序取决于以下几个方面：高质量的设计规范的编码有效的测试4程序员的职责我是程序员，除了编码我还需要做些什么？5程序员的职责传统的开发观念：开发人员的任务是完成编码，让系统正确运行起来程序调式通过任务就完成了自信自己的程序不会出错6实际：1、开发人员的任务是完成程序，直到交付和维护2、人的失误是不可避免的，无论多小心，都会有错误你以前做程序开发时做过测试吗？如何进行对自己代码做测试的？效果如何？7现实中的发现编码阶段会引入大量的缺陷系统测试发现的缺陷很大一部分是编码缺陷测试版本频繁，测试和项目进度被无休止的拖延8开发部的压力现状：一个承担多个角色的团队参与或部分参与高层设计承担底层设计程序实现承担底层测试9设计编码测试开发部的测试效果不好：为什么？没有时间测试不知道怎样测试不好组织缺乏方法和工具这种情况下，往往把单元测试的任务堆积到系统测试阶段10问题如果把单元测试的任务堆积到系统测试阶段，将会怎样？大量的故障堆积在项目中后期：项目后10%的工作占用了项目90%的时间故障难以定位故障飘忽不定开发、测试人员疲于本命11软件缺陷的修复费用12著名测试专家BorisBeizer博士：

Voyager

的错误(将探测器发送到太阳)AT&T和DCS的错误(曾造成美国三分之一的电话瘫痪)Intel奔腾芯片错误13软件开发历史上最臭名昭彰的错误都是单元错误——即通过适当地单元测试就可以发现的错误。单元测试的优点最高的成本收益比减少联调和后续测试的时间缺陷更容易定位更有信心去修改老代码14业界单元测试工作量商业软件单元测试工作量

/总工作量=8.3%编码工作量/总工作量=16.6%军工软件单元测试工作量

/总工作量=10.1%编码工作量/总工作量=18.1%15业界标杆单元测试（25%）审查评审（20%）设计（17%）编码（7%）系统测试（4%）计划和跟踪（4%）发布后缺陷：0.06个/Kloc单元测试发现的缺陷密度：31个/Kloc16本章内容单元测试概述单元测试的内容单元测试策略单元测试过程单元测试计划单元测试工具17单元是什么？（IEEE）软件单元指软件设计中一个可独立测试的元素，是程序中一个逻辑上独立的部分，它不能再分解为其它软件成分（实践中）软件单元过程化编程：单个程序、函数、过程等面向对象编程：类、方法18单元测试是什么单元测试：针对软件单元来进行正确性或性能检测的测试如果把测试比作清洗一台机器：系统测试就是清楚机器外面的尘土集成测试就是保证机器各个部件的接头处干净单元测试就是清晰各个零件的内部19系统/集成测试20应用输入潜在错误对象单元测试21测试一个类Thatiseasy!单元测试原则应该尽早地进行软件单元测试应该保证单元测试的可重复性尽可能地采用测试自动化的手段来支持单元测试活动22单元测试（Who）单元测试可以是开发者本人执行也可以是独立的专业测试人员执行两者各有优势建议：开发人员必须完整地做单元测试同时测试人员对重点模块实施独立的单元测试2324单元测试

测单元的哪些方面？单元测试内容25模块出错处理局部数据结构独立路径边界条件模块接口功能26单元功能测试单元接口测试单元局部数据结构测试单元中重要的执行路径测试单元的各类错误处理路径测试单元边界条件测试单元功能测试单元功能测试主要测试被测单元的功能与详细设计说明是否一致单元功能测试步骤：分析详细设计说明选用合适的单元测试工具设计单元测试用例执行待测单元分析实际结果与预期结果差异27单元接口测试接口测试意味着测试模块的数据流接口测试主要测试以下项目：调用所测模块时实参与形参在个数、属性、顺序上是否匹配；所测模块调用子模块时，实参与形参在个数、属性、顺序上是否匹配；是否修改了只做输入用的形参；输出给标准函数的参数在个数、属性、顺序上是否匹配全局变量的定义在各模块中是否一致；限制是否通过形参来传送。28局部数据结构测试局部数据结构测试主要检查以下各种错误：检查不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的默认值；变量名拼写错误或书写错误；不一致的数据类型。29重要执行路径测试执行路径错误是由错误的控制流造成的因为单元规模小，单元中的执行路径错误发生率低一般只需测试重要执行路径，可测试出的缺陷包括：错误的计算算法错误初始化不正确….常见的比较和控制流错误不同数据类型比较不正确的逻辑运算符或优先次序……30本章内容单元测试概述单元测试的内容单元测试策略单元测试过程单元测试计划单元测试工具31各类错误处理路径测试完善的模块设计要求能预见出错的条件，并设置适当的出错处理对策错误处理路径有错误或缺陷的情况有：出错的描述难以理解；出错的描述不足以对错误定位和确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经因此系统的干预如果出错情况不予考虑，那么检查恢复正常之后模块可否正常工作。32边界条件测试边界上出现错误是常见的。边界条件测试主要检查：运算或判断中取最大值、最小值时是否有错误；数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误；在n次循环的第1次、第2次、第n次是否有错误。33单元测试环境34被测模块桩模块1桩模块2桩模块3驱动模块测试结果测试用例驱动模块（driver）：所测模块的主程序。桩模块（stub）：用来代替所测模块调用的子模块驱动与桩练习单元测试策略36开发测试设计评审代码走查单元测试集成测试面向单元的白盒测试（单元覆盖率测试）狭义的单元测试内容面向单元的黑盒测试（单元功能测试）内存和运行错误分析（内存泄漏、越界，异常）代码运行性能profile（函数效率和瓶颈分析）代码走查代码走查：程序员和测试员组成审查小组，通过逻辑运行程序。代码走查步骤：第一步（静态方法）：小组成员提前阅读设计规格书、程序文本等相关文档。第二步（动态方法）：利用测试用例，使程序逻辑运行，记录程序的踪迹，发现、讨论、解决问题代码走查列表范例：/view/e10f670f763231126edb11cd.html37代码走查检查表模板38单元测试策略选择三种有效的单元测试策略：代码走查、白盒测试、黑盒测试。代码走查费时短，成本低，依赖走查成员的经验和技术白盒测试通常采用工具，费时短，工具成本高黑盒测试代价高，测试用例数量大对于重要单元，时间允许情况下三种测试方法都用不重要单元，可选择一种或两种进行测试。39本章内容单元测试概述单元测试的内容单元测试策略单元测试过程单元测试计划单元测试工具40单元测试过程包括8个活动：确定单元测试计划确定待测特性制定单元测试规程设计测试套件构建测试套件执行测试套件检查终止条件评估测试结果41一、确定单元测试计划确定单元测试范围尽可能争取完全地覆盖原则上应该做到完全覆盖参考：通常以下情况必须安排单元测试新软件单元新增代码比例超过20%的软件单元核心软件单元42一、确定单元测试计划单元测试充分性要求例如：语句覆盖率

=100%；分支覆盖率

>85%43一、确定单元测试计划确定终止条件确定单元测试过程的正常终止条件。该终止条件应该包括了对测试充分性要求的满足。例如：100%语句覆盖，85%分支覆盖识别可能造成单元测试过程异常终止的条件例如：发现重大的设计错误，到达进度期限44一、确定单元测试计划确定单元测试资源考虑测试人员、硬件、通信或系统软件、测试工具和其它资源。45一、确定单元测试计划指明总体进度计划基于资源和项目计划等方面的要求，确定计划46二、确定待测特性研究待测特性要从研究软件单元的需求开始功能需求、非功能需求、与待测单元相关的任何使用或操作过程单元的状态机识别针对状态机测试，例如测试一个类时考虑对象状态变化单元的数据特性识别单元的输入输出数据分析47三、制定单元测试规程输入单元测试计划、待测特性分析结果、项目总体进度计划识别可重用技术通过待测特性分析，可从用例库中识别出可以重用的测试用例和测试规程，以减少重复工作资源详细列举所需资源进度计划详细的进度计划，包括风险分析和应对措施规程评审48四、设计测试套件测试套件（Testsuite）测试用例、脚本、驱动、桩、测试数据测试规程和测试用例的开发结合待测单元特性分析，充分考虑覆盖率测试工具的设计考虑所设计工具的通用性测试规程/用例的评审49单元测试数据单元测试数据应包括：正常数据边界数据错误数据50五、构建测试套件测试数据的准备测试工具的开发/调试构建测试环境51六、执行测试套件运行测试，确定单元是否通过测试。对测试过程中的异常进行分析，并根据情况处理：测试用例或测试数据的问题。修正并重新运行测试规程执行的问题。重新运行测试环境的问题。纠正测试环境并重新运行；或者异常终止测试，并汇报记录异常终止原因单元实现中的故障。纠正单元的故障，并运行所有的测试；或者异常终止测试，并汇报记录异常终止原因单元设计中的故障。纠正单元设计和实现中的故障，必要时修改测试设计和测试数据，并重新运行所有的测试52七、检查终止条件测试充分性检查检查是否达到覆盖率要求，包括测试用例执行/通过覆盖率和被测单元代码/分支覆盖率。以及其它测试充分性要求。异常终止条件检查补充测试套件以上条件不满足时，则需要补充测试套件，继续进行测试。53八、评估测试结果按照单元测试报告模块出具单元测试报告如有必要对单元测试报告进行评审将所有测试相关工作产品纳入配置管理54本章内容单元测试概述单元测试的内容单元测试策略单元测试过程单元测试计划单元测试工具55测试驱动开发测试驱动开发(即Test-drivendevelopment,简称TDD)，是一种测试方法，即在进行代码变更或新功能增加之前，先编写单元测试代码，再完善代码确保测试通过。56测试驱动开发测试驱动是一种开发形式：首先要编写测试代码除非存在相关测试，否则不编写任何的产品代码由测试来决定需要编写什么样的代码要求维护一套详尽的测试集57测试驱动开发流程58分析设计单元测试代码产品代码重构执行测试测试失败单元测试代码错误产品代码错误本章内容单元测试概述单元测试的内容单元测试策略单元测试过程单元测试计划单元测试工具59JUnitJunit概述由ErichGamma和KentBeck编写的测试框架ErichGamma:设计模式KentBeck:极限编程是开放源码软件，在下载是一种白盒测试法，是进行回归测试的工具JUnit自定义包、类框架结构和接口，可以参阅下载文件中的javadoc目录内容JUnit适用于Java开发人员在单元测试阶段，进行单个方法实现功能或者类本身的测试60测试驱动开发实例：计算器开发一个计算器，实现加减乘除的运算61测试驱动开发实例：计算器第一步：创建项目62测试驱动开发实例：计算器第二步：编写单元测试用例代码63publicclassCaculatorTestextendsjunit.framework.TestCase{}CaculatorTest将从junit.framework.TestCase获得或是继承所有的能力（行为）和数据（属性）必须指定该类为public类型，这样JUnit测试框架才能识别它测试驱动开发实例：计算器第三步：执行测试用例测试失败64测试驱动开发实例：计算器第四步：增加一个测试65

方法名testAdd，暗示这是一个测试方法。对Java而言，这不过是个方法名。但是JUnit根据名称来识别一个测试方法，所以测试方法的命名要遵从下面的标准：方法必须声明为public方法的返回值必须为void方法的名字必须以小写test为前缀方法不能接受任何参数测试驱动开发实例：计算器第五步：编译测试用例代码，执行测试66JUnit执行成功（显示一根绿条），对测试类CaculatorTest，JUnit显示成功地执行了一个测试方法，没有任何错误和失败。请记住在testAdd中没有任何代码。JUnit执行成功表明空的测试方法一定可以通过。测试驱动开发实例：计算器第六步：编写产品代码67故意制造一个缺陷。测试驱动开发实例：计算器第七步：测试中增加测试断言(assertion)断言：用于在代码中捕捉编写代码所做的假设断言表示为一些布尔表达式Junit提供的常用断言：assertEquals、assertFalse、assertNotNull、assertNotSame、assertNull、assertSame、assertTrue68测试驱动开发实例：计算器第八步：执行测试69测试不通过，需要判断失败原因测试驱动开发实例：计算器第九步：修改错误以使测试执行通过70测试驱动开发实例：计算器测试套件（Testsuite）包含了一组相关的TestCase如果你没有为你的TestCase定义一个suite，Junit会自动为你提供suite并将在TestCase中发现的所有测试都包含进来。和TestCase一样，作为JUnit的一个类实现Test接口TestSuite类的suite（）方法如同普通类中的main（）方法一样，JUnit用来执行测试71测试驱动开发实例：计算器应用测试套件（Testsuite）72Junit应用总结JUnit用于开发人员进行单元测试适合一边编程，一边测试，可尽早纠正编程错误，减小纠正代价在JUnit框架下，编写针对不同工作代码的测试代码，只需做部分修改，实现测试代码重用JUnit有特定的框架结构，只有多练习，才能熟练应用73驱动开发测试特点主要优点：提高代码质量改进设计为功能代码提供了良好的文档在一定程度上可替代程序调试有效的质量控制和项目管理74驱动开发测试特点主要不足：难以测试包含界面、数据库、通信等类型的代码不适合密码技术、容错等安全类型的应用软件单元与单元测试用例如果由同一开发人员编写，导致测试与开发产生共同的盲点测试代码将成为项目维护额外的负担单元测试的高通过率可能造成软件高质量的假象75MockitoMockito是一个开源的Java测试框架用于创建和管理mock对象（虚拟对象）。它可以帮助我们进行单元测试，并容易集成到我们现有的测试框架中。Mockito的作用在于模拟或者替代依赖项或难以设置的对象。使用Mockito可以使单元测试更简单、更容易理解和维护。Mockito主要提供了以下操作：创建Mock对象打桩（Stubbing）：定义模拟对象在给定参数时应该产生什么样的结果验证（Verification）：验证模拟对象的互动行为以及调用次数等真实对象的Spy：间谍（Spy）对象允许你使用真实的对象，但是还会跟踪对象的特定行为76JUnit与Mockito结合使用Mockito的应用场景一般包括：模拟接口，用于测试接口调用是否合理。模拟依赖，用于测试代码中的依赖关系是否正确。模拟外部系统，例如HTTP接口、数据库等，用于测试代码是否能够正确地与外部系统交互。77JUnit与Mockito结合使用78JUnit与Mockito结合使用79本章内容为什么做单元测试单元测试的概念和内容如何做单元测试测试驱动开发与JUnit单元测试的难点和对策80常见的单元测试难点没有时间做单元测试单元测试责任人不清楚测试代码难以管理覆盖率难以手工统计驱动和桩编写困难（可测试性）81对策：没有时间做单元测试单元测试计划在项目计划应该有体现。编写代码之前或同时，先设计测试用例。每个软件单元应该有什么功能？是否每个功能都有测试用例来验证它？82对策：单元测试责任人不清楚强调单元测试必须由类包的设计者负责编写，因为只有这样，测试才能保证对象的运行时态行为符合需求。让测试人员或第三方人员编写测试用例，将花费更多的工作量。（20>>1）执行测试用例可以让测试人员或自动构造系统。83对策：测试代码难以管理采用测试工具管理测试代码如：XUnit、C++Test、RTRT配置管理中建立配置项如，不同模块的一组代码，建立相应测试代码目录和配置项84对策：覆盖率难以手工统计利用各种工具：PureCoverage(C/C++/Java/.Net,Windows/UNIX)RTRT(C/C++/Java/Ada,嵌入式系统)C++Test(C/C++,Windows/UNIX)Discover(Delphi,Windows)Jacoco（Java）85对策：驱动和桩编写困难通常情形下，测试驱动难以编写，测试难以进行由以下几方面原因导致：被测试对象需要传入的参数过多。内部的逻辑判断过多（内部牵扯复杂）。和界面显示部分交互过于频繁（耦合性太强）。被测对象过多的调用了其他类或方法。需要构造的作为参数的对象本身过于复杂86提高可测试性提高可测试性策略坚持驱动设计的方法功能分解分层原则设计的分层思想，例如MVC抽象降低耦合度复杂参数对象表示为接口面向接口编程开发人员时刻想着测试重构8788欢迎提问和讨论谢谢

第10章集成测试本章内容集成测试概述集成静态测试集成动态测试集成测试流程集成测试计划持续集成工具Jenkins接口测试工具Postman90什么是集成测试？也叫做组装测试、联合测试、子系统测试和部件测试。是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，进行集成测试。91单元测试、集成测试与系统测试的差别92集成测试系统测试单元测试灰盒测试，采用较多黑盒方法构造测试用例黑盒测试大量采用白盒测试方法测试方法模块间的集成和调用关系整个系统，包括系统软硬件等模块内部程序代码对象找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题对整个系统进行一系列的整体、有效性测试消除局部模块逻辑和功能上的缺陷目的目标说明书需求说明书等程序结构设计模块详细设计模块外部说明测试依据集成测试关注的重点在把各个模块连接起来时，穿越模块接口的数据是否会丢失。各个子功能组合起来，能否达到预期要求的父功能。一个模块的功能是否会对另一个模块的功能产生不利的影响。全局数据结构是否有问题，会不会被异常修改单个模块的误差积累起来，是否会放大，从而达到不可以接受的程度。93集成测试的层次产品开发过程：一个分层设计和逐步细化的过程94系统结构图软件结构95软件结构图软件模块结构图集成测试的层次集成测试可分成3个层次——集成测试都应覆盖：模块内集成测试子系统内集成测试子系统间集成测试面向对象的应用系统来说，可分为2个层次：类内集成测试类间集成测试96本章内容集成测试概述集成静态测试集成动态测试集成测试流程集成测试计划持续集成工具Jenkins接口测试工具Postman97系统体系结构设计测试系统体系结构的“4+1”视图描述：

用例视图：用例视图定义系统的外部行为。逻辑视图：逻辑视图描述逻辑结构。实现视图：实现视图描述用于组建系统的物理组件。进程视图：进程视图描述将系统分解为过程和任务。部署视图：描述系统的物理网络布局及程序分布。系统体系结构设计测试主要验证系统各组件间的结构设计是否合理，属于模块间接口和交互的测试范畴。98数据结构设计测试数据结构设计确定软件涉及的文件系统的结构以及数据库的模式、子模式，进行数据完整性和安全性的设计。它包括以下几个方面：确定输入、输出文件的详细数据结构；结合算法设计，确定算法所必需的逻辑数据结构及操作；内部模块之间的接口数据格式设计；数据库设计合理性，具体见数据库专业书籍。数据结构设计测试主要验证数据结构设计文档的规范性、逻辑正确性与接口一致性。通过评审设计文档、检查数据模型、分析接口定义来发现潜在缺陷，确保设计符合需求且易于实现。99类图静态测试类图进行静态测试时主要关注的内容：完整性检查：验证类图中是否包含了所有必要的类，包括实体类、控制类和边界类等。正确性验证：确认类之间的关系是否准确表示了领域模型和系统设计。一致性检验：确保类图与系统的需求文档和设计文档相一致，没有遗漏或多余的元素。访问控制检查：检查类之间的访问权限是否合理。重用和代码质量：检查类的设计是否促进了代码的重用，例如通过继承和接口实现；评估类和类之间的关系是否遵循了良好的设计原则，如单一职责原则和开闭原则。设计模式的应用：确认类图是否正确地实现了设计模式，检查设计模式的应用是否提高了系统的灵活性和可维护性。关联和依赖检查：验证类之间的关联关系（如一对一、一对多、多对多）是否正确和必要；检查依赖关系是否合理，确保类之间的耦合度适中，不会导致过高的复杂性。抽象和具体类的平衡：评估类图中抽象类和具体类的比例，确保它们在设计中扮演了合适的角色；检查是否有过度使用抽象类或接口，导致设计过于复杂。100本章内容集成测试概述集成静态测试集成动态测试集成测试流程集成测试计划持续集成工具Jenkins接口测试工具Postman101集成测试策略非增量方式先测试好每一个软件单元，然后一次性组装在一起再测试整个程序。增量方式逐步把下一个要被组装的软件单元或部件，同已测好的软件部件结合起来测试。增量方式主要包括自顶向下、自底向上、自顶向下与自底向上相结合等方法。102大系统中较复杂、也是核心集成测试策略非增量方式

大爆炸（BigBang）增量方式自顶向下方法（Top-Down

）自底向上方法（Bottom-Up

）“三明治”方法（Sandwich）103大爆炸集成（BigBang）将所有系统组件一次性集成到被测系统中104d1、d2、d3、d4、d5是为单元测试时建立的驱动模块s1、s2、s3、s4、s5是为单元测试而建立的桩模块先测每一个思考：1）在基于Junit的单元测试中桩和驱动程序呢？集中测试中如何编写？在哪运行？大爆炸集成（BigBang）优点：可以迅速完成集成测试；并且只要极少数的驱动和桩模块；用例也是最少的（为什么？）；简单；资源利用率高缺点：一次试运行成功的可能性不大，问题定位和修改比较困难，许多接口错误很容易躲过测试。适应于一个维护型项目或被测试系统较小105增量测试测试单独的模块可能需要一个特殊的驱动模块和一个或多个桩模块驱动模块是为测试编写的一个小模块，用来将测试用例驱动或传输数据到被测模块。驱动模块还需要向测试人员显示被测模块的结果。桩模块充当被测模块调用的模块，模拟该模块的功能。例如测试模块B时需要一个驱动模块，和一个模拟模块E的桩模块ABDCFE非增量测试和增量测试107增量测试非增量测试使用前面测试过的模块来取代非增量测试中所需要的驱动模块或桩模块。要设计驱动模块和桩模块可以较早发现模块中与不匹配接口、不正确假设等编程错误。到了测试过程的最后阶段，模块之间才能“互相看到”容易进行调试，新出现的错误往往与最近添加的模块有关直到整个程序组装之后，模块之间接口相关的错误才会浮现，难以定位测试可以进行地更彻底，每个模块经受了更多的检验使用驱动模块和桩模块而非实际模块，对被测试模块的测试只影响自身在测试上花费的时间多，设计驱动模块和桩模块所用时间少测试时间少，但设计驱动模块和桩模块需要大量时间并行性差可以同时并行测试很多模块

自顶向下测试与自底向上测试自顶向下测试从最顶层模块开始，逐渐加入下层模块自底向上测试从最底层模块开始，逐渐加入上层模块ABDCFE自定向下方法从顶层控制开始，从程序的顶部模块开始测试。再选择后续模块添加进来进行增量测试添加的原则是：至少一个调用该模块的模块事先经过了测试。有多种可能的测试序列时，应该考虑先测试关键模块和I/O模块为测试上层模块，需设计桩模块，桩模块通常要向被测模块提供测试数据，如读取外部数据文件109ABDCFE集成的方式有两种：深度优先组装法按纵向考虑，层次多的分支优先测试广度优先组装法从横向考虑，总是先测试下一级的模块ABDCFE111深度优先组装方式112广度优先组装方式较复杂的情况图中共有12个模块A到L模块I包含IO的写操作模块J包含IO的读操作ACDBJIHGFLKE自顶向下的增量测试首先测试模块A，需要设计代表模块B,C,D的桩模块；如图接着用实际模块代替桩模块，如B，并添加B的桩模块；如图增量的序列有多种可能，例如：ABFJDICGEKHL，加入I后如图AstubCstubDstubBstubFstubEBJFDstubHI自顶向下的增量测试中的桩模块显示跟踪信息显示传递信息返回一个值根据输入返回一个值ABCD集成步骤（遍历算法）以主模块为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块对主模块进行测试采用深度优先或广度优先的策略，用实际模块替换相应桩模块，再用桩代替它们的直接下属模块，与已测试的模块或子系统集成为新的子系统。进行回归测试（即重新执行以前做过的全部测试或部分测试），排除集成过程中引起错误的可能判断是否所有的模块都已集成到系统中，是则结束测试，否则转到(2)去执行。116ABDCFE自顶向下的增量测试方法特点优点：较早地验证了主要控制和判断点；按深度优先可以首先实现和验证一个完整的软件功能；功能较早证实，带来信心；只需一个驱动，减少驱动器开发的费用；支持故障隔离。缺点：桩的开发量大；底层验证被推迟；底层组件测试不充分。117ABDCFE118适用范围产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产品控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。ABDCFE119自底向上方法从具有最小依赖性的底层组件开始，按照依赖关系树的结构，逐层向上集成，以检验系统的稳定性。选择下一个模块进行增量测试的原则是：该模块调用的所有的模块都已经事先经过了测试。为了测试低层模块，需要为它们设计驱动模块：即包含着有效的测试输入、调用被测模块且显示输出的模块。ABDCFE集成示意图自底向上方法121自底向上方法集成步骤（1）起始于模块依赖关系树的底层叶子模块，也可以把两个或多个叶子模块合并到一起进行测试（2）使用驱动模块对步骤１选定的模块（或模块组）进行测试（3）用实际模块代替驱动模块，与它已测试的直属子模块组装成一个更大的模块进行测试（4）重复上面的行为直到系统最顶层模块被加入到已测系统中ABDCFE122自底向上方法优缺点分析优点：对底层组件行为较早验证；工作最初可以并行集成，比自顶向下效率高；减少了桩的工作量；支持故障隔离。缺点：驱动的开发工作量大；对高层的验证被推迟，设计上的错误不能被及时发现。ABDCFE123自底向上方法适用范围：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。ABDCFE自底向上的增量测试第一步测试E,J,G,K,L和I中的部分或全部模块既可以串行也可以并行进行；需要设计驱动模块，有的驱动模块可以供几个测试模块使用ACDBJIHGFLKE自底向上的增量测试接着测试的模块序列有多种可能如果接下来是测试较关键的模块F,H，则用它们代替相应的驱动模块，并加入它们的驱动模块JDriverDriverLKIDriverFDriverDDriverH自底向上的增量测试中的驱动模块调用从属模块调用从属模块，并传递参数调用从属模块，并要求得到参数兼有B,C的功能ABCD自顶向下测试和自底向上测试的比较自顶向下优点如果主要缺陷发生在程序顶层将非常有利早期程序框架可以进行演示，即提早发现主要的控制问题缺点必须开发桩模块桩模块可能要比最初表现的更复杂创建测试环境可能很难，甚至无法实现观测测试输出比较困难自底向上优点如果主要的缺陷发生在程序的底层将非常有利提早发现程序当中的主要算法问题测试环境比较容易建立观测测试输出比较容易缺点必须开发驱动模块直到最后一个模块添加进去，程序才形成一个整体128“三明治”方法（Sandwich）混合式集成把系统划分成三层，中间一层为目标层，目标层之上采用自顶向下集成，之下采用自底向上集成129三明治集成策略集成步骤（1）首先对目标层之上一层使用自顶向下集成，因此测试A，使用桩代替B，C，D（2）其次对目标层之下一层使用自底向上集成，因此测试E，F，使用驱动代替B，D（3）其三，把目标层下面一层与目标层集成，因此测试（B，E），（D，F），使用驱动代替A（4）最后，把三层集成到一起，因此测试（A，B，C，D，E，F）130三明治集成策略优缺点优点：集合了自顶向下和自底向上两种策略的优点缺点：中间层测试不充分适用范围：适应于大部分软件开发项目ABDCFE131修改过的三明治集成面向对象的集成测试面向对象的集成测试特点结构集成测试功能集成测试集成测试方法继承关系的类集成测试类交互的集成测试132结构集成测试方法：静态测试测试对象：类继承、类容器、组件的接口目的：结构是否符合设计可逆性工程：ISA公司的Panorama-2、Rational公司的RoseC++Analyzer对照类关系图133功能集成测试方法：检查类间方法交互、组件间交互等；信息来源：系统的规约、系统设计、代码。其它信息：设计模型、功能调用结构图、类关系图或者实体关系图134类层次结构继承－>类交互－>组件－>应用类通过继承集成类通过交互集成类到组件的集成组件到应用系统的集成135交互集成对象交互通过消息传递实现通过参数引用136Wood和Flooring集成Flooring类137Wood和Surface单元测试Flooring集成测试其它类交互参数交互返回类对象类方法中创建对象类引用全局类对象138集成测试步骤选定检测的类，参考OOD分析结果，仔细分析类的状态和相应的行为，类或方法间传递消息，前置条件和后置条件的界定等；确定覆盖标准；利用结构关系图确定待测类的所有关联；根据程序中类的对象构造测试用例，确认使用什么输入激发类状态的改变，使用类的服务和期望产生什么行为等；进行集成测试，根据类的层次关系确定测试的先后顺序，尽量使测试用例能够复用。139集成测试原则首先测试公共类测试仅调用公共类的类有继承层次关系的先测试父类再测试子类集成时尽量一次添加一个被测试的类或组件形成组件的先单独测试组件再集成到子系统140实例：发布新闻141“发布新闻”用例的顺序图发布新闻，可上传附件实例：发布新闻集成测试先测试FileUpload、NewsDao，需要驱动类News类可以不测然后测试NewsService，需要Mock对象、驱动类，然后NewsDao对象替换Mock对象再测试NewsController，需要Mock对象、驱动类最后测AddNewsFrame，

需要Mock对象142本章内容集成测试概述集成静态测试集成动态测试集成测试流程集成测试计划持续集成工具Jenkins接口测试工具Postman143集成测试流程144制定集成测试计划集成测试分析与设计集成测试实现集成测试执行集成测试评估软件体系结构初步分析关键特性分析工作量估计资源安排进度安排集成测试对象分析集成策略选择集成测试工具选择和设计集成测试代码设计集成测试用例设计集成测试工具开发集成测试代码开发集成测试用例开发建立集成测试环境执行集成测试测试结果记录集成测试数据分析集成测试评估145(1)为系统运行设计用例——多角度设计测试用例

目的：测试各个模块的接口是否能用，验证系统最基本功能可使用的主要测试分析技术有（黑盒技术）：（1）等价类划分。（2）边界值分析。（3）基于决策表的测试。146(2)为正向测试设计用例目的：验证集成后的模块是否按照设计实现了预期的功能。可使用如下几种主要测试分析技术：（1）输入域测试。（2）输出域测试。（3）等价类划分。（4）状态转换测试。正向测试是指，当你输入一个有效的输入并且期望软件能够完成一些根据说明书规定的行为。147(3)为逆向测试设计用例目的：测试是否多余功能、接口遗漏、接口错误、接口异常。可使用的主要测试分析技术有：（1）错误猜测法。（2）基于风险的测试。（3）基于故障的测试。（4）边界值分析。（5）特殊值测试。（6）状态转换测试。逆向测试是指，当你输入无效的输入时并且期望得到一个错误的信息。148集成测试用例设计(4)为满足特殊需求设计用例。(5)为高覆盖设计用例可使用的主要测试分析技术有：（1）功能覆盖分析。（2）接口覆盖分析。149集成测试流程（思考各阶段IO）计划阶段设计阶段实现阶段执行阶段分析评估缺陷跟踪根据项目组提供设计模型和集成构建计划，制定出适合本项目的集成测试计划根据集成测试计划和设计模型设计集成测试用例及测试过程获取工作版本后，由测试设计员创建测试脚本(可选)、更新测试过程，由设计员负责设计驱动程序和桩，实施员负责实施驱动和桩测试人员根据测试脚本(可选)和工作版本执行集成测试，并记录测试结果依照集成测试计划和测试结果，由测试设计员负责会同集成员、编码员、设计人员评估此次测试，并生成测试评估摘要150计划阶段输入需求规格说明书概要设计文档产品开发计划输出集成测试计划151计划阶段活动步骤确定被测试对象和测试范围评估集成测试被测试对象的数量及难度确定角色分工和划分工作任务标识出测试各阶段的时间、任务、约束等条件考虑一定的风险分析及应急计划考虑和准备集成测试需要的测试工具、测试仪器、环境等资源考虑外部技术支援的力度和深度，以及相关培训安排定义测试完成标准152设计阶段输入需求规格说明书概要设计集成测试计划输出集成测试设计方案集成测试用例153