《8 集成测试和系统测试》由会员分享，可在线阅读，更多相关《8 集成测试和系统测试（34页珍藏版）》请在金锄头文库上搜索。
1、集成测试和系统测试软件测试过程v1、单元测试v2、集成测试v3、系统测试v4、验收测试v5、回归测试集成测试(Integration Testing)v别名：组装测试、联合测试、子系统测试，v测试对象：多个模块 v测试目的： 检验组成系统的模块接口有无错误 代码实现的系统设计与需求定义是否吻合v集成方式：一次性集成、自下向上或自上向下。v测试技术：黑盒v测试人员：一般由编程人员和测试人员共同完成 ，以测试 人员为主集成测试v1集成测试前的准备v2集成测试模式v3 自底向上和自顶详下集成v4 大棒与三明治集成方法v5持续集成 1集成测试前的准备v人员安排集成测试及要求参与的人熟悉单元的内部细节，
2、有要求能 够从足够高的层次上观察整个系统。一般由测试工程师和 软件工程师共同完成。集成测试前要求单元测试已经通过。v测试计划集成测试计划在系统设计阶段就开始制定，随着系统设计 、开发过程不断细化，最终在系统实施集成之前完成。v测试内容重点测试内容包括各个单元的接口是否吻合，代码是否符 合规定的标准，界面风格是否统一。v集成模式v测试方法测试方法随测试进行选用不同的测试方法，但主要是应用 黑盒测试技术。2集成测试的模式v非渐增式模式先分别测试各个模块，再把所有模块按设计要求一次集成在一起组 合成所需要的程序，典型如大棒模式。v渐增式模式把下一个要测试的模块同已经测试好的模块结合起来进行测试，测
3、试通过后，再把下一个被测模块结合进来测试。v两种模式的比较渐增式模块需要编写的软件较多(驱动模块或桩模块)，工作量较大 。渐增式测试发现错误早，非渐增式发现错误晚。渐增式错误定位相对容易。渐增式模式测试更彻底。渐增式模式需要更多的机器时间。使用非渐增式模式，可以并行测试。3自底向上和自顶详下集成方法v1.自顶向下法自顶向下法( (Top-down integration)Top-down integration)n对主控模块进行测试，测试时用桩模块代替所有直接附属于主 控模块的模块。n根据选定的结合策略(深度优先或广度优先),每次用一个实际模 块代替对应的桩模块.n在结合下一个模块的同时进行测
4、试(新结合进来的模块也许又需 要新的桩模块).n为保证加入的模块没有引进新的错误,可能需要进行回归测试.n从2开始不断重复上述过程,直至完成.主要优点:不需要驱动程序早期验证系统主要功能早期发现上层模块的接口错误主要缺点:需要大量的桩模块底层模块的错误发现较晚早期不能充分展开人力v适用范围产品控制结构比较清晰和稳定产品的高层接口变化比较小产品的底层接口经常可能被修改产品的控制规模具有较大的技术风险，需要尽早进行验证希望尽早能够看到产品的系统功能行为在极限编程(Extreme Programming)中经常采用这种策略v2. 自底向上法自底向上法( (Bottom-up integration)
5、Bottom-up integration)1)把底层模块组合成实现某个特定软件子功能的簇(Cluster).2)开发一个驱动程序,协调测试数据的输入和输出.3)对由模块组成的子功能簇进行测试.4)去掉驱动程序,沿软件结构自下向上移动,把子功能簇组合起来形成更 大的子功能簇.5)从2开始不断重复上述过程,直至完成.v优点对底层模块行为的早期验证,较早发现底层模块错误在初期可能会并行进行,提高效率减少了桩模块的工作量驱动模块额外编写,对被测模块的可测性要求较低便于故障定位v缺点驱动模块工作量非常大对高层的验证被推迟到了最后,设计上的错误不能被及时发现v适用范围底层接口比较稳定的产品高层接口变化比
6、较频繁的产品底层模块较早完成的产品v3. 混合策略混合策略(Modified Top-Down integration)(Modified Top-Down integration)改进的自顶向下法:基本使用自顶向下法,但在测试早期,使用自底向 上法测试少数关键模块.混合法:对软件结构中较上层使用自顶向下;对软件结构中较下层使用 自底向上法,两者相结合.Test BTest ATest CTest DTest ABCDTest ETest FTest GTest ABCDEFGABCDEFG4大棒与三明治集成方法v1.大棒(Big-bang integration)集成方法在对每一个子模块进行
7、测试(单元测试阶段)后,然 后将所有模块全部集成起来一次性进行集成测试.目的:在最短时间内把系统组装出来,并且通过少量 的测试来验证整个系统ABCDEFGTest ATest BTest CTest DTest E Test FTest GTest ABCDEFGv优点 迅速完成集成测试 只需要极少桩模块和驱动模块 需要的测试用例也最少 简单易行 测试人员可以并行进行v缺点 组装时一次成功的可能性很小 错误定位和修改都比较困难 即使能够一次性集成,但还有很多接口错误不容易被测试到v适用范围 维护性项目(或功能增强型项目),因为以前的产品很稳定,只是 新增或修改了少数几个组件. 被测系统很小,并
8、且它的每个组件都经过了充分的单元测试v2.三明治集成方法(sandwich integration)两头向中间集成优点:v将自顶向下和自底向上的集成方法有机的结合起来,不 需要写桩程序.缺点:v真正集成前每一个独立的模块没有完全测试过.ABCDEFGTest ETest FTest ATest DGTest GTest BEFTest ABCDEFGv2.改进的三明治集成方法(modified sandwich integration)不仅两头向中间集成,而且保证每个模块得到单独 的测试,使测试进行的比较彻底.适用范围:大部分软件项目ABCDEFGTest ETest BTest FTest
9、GTest ATest CTest BEF Test D Test DGTest ABCDEFG名称自底向上自顶向 下混合策 略大棒三明 治改进三明 治 集成早早早晚早早基本程序能工作 时间时间晚早早晚早早需要驱动驱动 程序是否是是是是需要桩桩程序否是是是是是工作并行性中低中高中高特殊路径测试测试容易难难容易容易中等容易计计划与控制容易难难难难容易难难难难5持续集成v通常系统会采用持续集成策略,软件开发中各个模块不是 同时完成,根据进度将完成的模块尽可能早的进行集成, 有助于尽快发现缺陷,避免集成中大量缺陷涌现,同时提 高了工作效率,最终提高了软件开发的质量和效率。v持续集成也叫做基于进度的集
10、成。v缺点模块之间缺乏整体性，导致很多接口必须到后期才能验证，但 此时系统已经很复杂，往往无法有效地发现接口问题。桩模块和驱动模块的工作量可能会变得很庞大。由于进度的原因，模块可能很不稳定，导致测试的重复和浪费v适用范围：进度优先级高于质量的项目其他集成方法v基干集成(Backbone Integration)v分层集成(Layer Integration)v基于风险的集成(Risk-Based Integration)v基于事件(消息)的集成v基于使用的集成v高频集成v基于功能的集成(Functions-Based Integration)冒烟测试v 冒烟测试一般用于每日构建(Nightly
11、 build)， 构建服务器首先从CVS服务器上，下载最新的 源 代码，然后编译单元测试，运行单元测试通过后 ，编译可执行文件，可执行文件若可运行，并能 执行最基本的功能，则认为通过了冒烟测试，这 时，构建服务器会 把程序打包成安装文件，然后 上传到内部网站，第二天一早，测试人员来了以 后，会收到构建服务器发来的邮件提示昨晚是否 构建成功。2系统测试(System Testing)v与集成测试的区别系统测试所测试的对象是整个系统以及与系统交互的 硬件和软件平台,系统测试更多程度上是站在用户的角 度上对整个系统做功能性的验证,同时还对系统进行一 些性能测试,系统测试的依据来自于用户的需求规格说
12、明书集成测试所测试的对象是模块间的接口,目的是找出模 块接口和整体体系结构上的问题.系统测试v别名：无，包括功能测试，性能测试，安全测试，恢复测 试、安装测试等v测试对象：组装好的软件 v测试目的：v检验组成整个系统的代码、以及系统的软硬件配合有无错误v代码实现的系统与用户需求是否吻合v检验系统的文档等各种是否完整、有效v模拟验收测试的要求，检查系统是否符合用户的验收标准v测试技术：黑盒v测试人员：测试人员，部分开发人员，质量保证人员系统测试的内容v系统测试的内容包括功能测试压力测试性能测试容量测试安全测试容错测试兼容性测试验收测试(Accepting Testing)验收测试是软件开发结束后
13、，用户对软 件产品投入实际应用前，进行的最后一次质 量检验活动。它要回答开发的软件产品是否 符合预期的各项要求，以及用户能否接受的 问题。v 验收测试主要是验证软件是否满足合 同规定的所有功能和性能，文档资料是否完 整，人机界面是否今用户满意等。验收测试v验收测试人员验收测试一般在测试组的协助下，由用户代表 执行。测试组长负责保证在合理的质量控制和 监督下使用合适的测试技术执行充分测试。测 试人员在验收测试工作中将协助用户代表执行 测试，并和测试观察员一起向用户解释测试用 例的结果。验收测试v验收测试的主要内容 1. 配置复审 2. 合法性检查 3. 软件文档检查 4. 软件代码测试 5. 软
14、件功能和性能测试 6. 测试结果交付内容验收测试验收测试技术和测试数据验收测试完全采用黑盒测试技术，主要是用户代表通 过执行其在平常使用系统时的典型任务来测试软件系 统，根据业务需求分析，检验软件是否满足功能、行 为、性能和系统协调性等方面的要求。测试数据应采用用户日常的实际数据，如果不能使用 真实数据，应该考虑使用真实数据的一个拷贝。拷贝 数据的质量、精度和数据量必须尽可能地代表真实的 数据。 验收测试v、测试软件开发设计人员在软件开发设计时，不可能 完全预见用户实际使用软件系统的情况。一个软件产品可能拥有众多用户，不可能由每 个用户验收，此时多采用称为、测试的过程 ，以发现那些似乎只有最终
15、用户才能发现的问 题。验收测试v测试是在软件开发公司内模拟软件系统的 运行环境下的一种验收测试，即软件开发公 司组织内部人员，模拟各类用户行为对即将 面市的软件产品（称为版本）进行测试， 试图发现并修改错误。验收测试v测试是指软件开发公司组织各方面的典型 用户在日常工作中实际使用版本，并要求 用户报告异常情况，提出批评意见。然后软 件开发公司再对版本进行改错和完善。4回归测试v回归测试是指修改了旧代码后，重新进行测试以确 认修改没有引入新的错误或导致其他代码产生错误 。自动回归测试将大幅降低系统测试、维护升级等 阶段的成本。v目的：回归测试的目标是保证被测应用在系统被修 改或扩充后，各项功能依
16、然正确 所作的修改达到了预定目的，如错误得到改正， 新功能得到实现，能够适应新的运行环境等。 不影响软件原有功能的正确性。v回归测试特别适用于使用自动化测试工具v严格地讲回归测试不是一个测试阶段，而是一种测 试技术v在增量开发和迭代开发中应用尤其广泛v回归测试方法选择回归测试方法时应该兼顾效率和有效 性两方面v再测试全部用例v基于风险选择测试v基于操作剖面选择测试v再测试修改的部分v回归测试的组织和实施n识别出软件中被修改的部分n从原基线测试测试用例库中T中，排除不适用的 测试用例，其结果是建立一个新的基线测试用例 库T0n依据一定的策略从T0种选择测试用例测试被修改 的软件。n如果回归测试包不能达到所需的覆盖要求，必须 补充测试用例使覆盖率达到规定的要求，
