精华内容
下载资源
问答
  • 目标是把通过了单元测试的模块拿来,构造一个在设计中所描述的程序结构,应当避免一次性的集成(除非软件规模很小),而采用增量集成。 自顶向下集成:模块集成的顺序是首先集成主模块,然后按照控制层次结构向下...

    分享一个大牛的人工智能教程。零基础!通俗易懂!风趣幽默!希望你也加入到人工智能的队伍中来!请点击http://www.captainbed.net

    1、单元测试:完成最小的软件设计单元(模块)的验证工作,目标是确保模块被正确的编码,使用过程设计描述作为指南,对重要的控制路径进行测试以发现模块内的错误。通常情况下是白盒的,对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试,及早的发现和解决不易显现的错误。

    2、集成测试:通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来,构造一个在设计中所描述的程序结构,应当避免一次性的集成(除非软件规模很小),而采用增量集成。

    自顶向下集成:模块集成的顺序是首先集成主模块,然后按照控制层次结构向下进行集成,隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。

    自底向上集成:从原子模块开始来进行构造和测试,因为模块是自底向上集成的,集成时要求所有隶属于某个顶层的模块总是存在的,也不再有使用稳定测试桩的必要。

    3、系统测试:是基于系统整体需求说明书的黑盒类测试,应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不相符合或与之矛盾的地方。系统测试的对象不仅仅包括需要测试的产品系统的软件,还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此,必须将系统中的软件与各种依赖的资源结合起来,在系统实际运行环境下来进行测试。

    4、回归测试:回归测试是指在发生修改之后重新测试先前的测试用例以保证修改的正确性。理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再次出现。回归测试的目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。

    5、验收测试:验收测试是指系统开发生命周期方法论的一个阶段,这时相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括Alpha测试和Beta测试。

    Alpha测试:是由用户在开发者的场所来进行的,在一个受控的环境中进行。

    Beta测试:由软件的最终用户在一个或多个用户场所来进行的,开发者通常不在现场,用户记录测试中遇到的问题并报告给开发者,开发者对系统进行最后的修改,并开始准备发布最终的软件。

    展开全文
  • 单元测试

    万次阅读 2019-10-18 23:35:31
    一、什么是单元测试单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行...

    一、前言

    定义:单元测试(unit testing)是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作

    单元测试是在软件开发过程中要进行的最低级别的测试活动,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

    单元测试从长期来看,可以提高代码质量减少维护成本降低重构难度。但是从短期来看加大了工作量,对于进度紧张的项目中的开发人员来说,可能会成为不少的负担。

    二、哪些代码需要写单元测试?

    老板为我的代码付报酬,而不是测试,所以,我对此的价值观是——测试越少越好,少到你对你的代码质量达到了某种自信(我觉得这种的自信标准应该要高于业内的标准,当然,这种自信也可能是种自大)。如果我的编码生涯中不会犯这种典型的错误(如:在构造函数中设了个错误的值),那我就不会测试它。我倾向于去对那些有意义的错误做测试,所以,我对一些比较复杂的条件逻辑会异常地小心。当在一个团队中,我会非常小心的测试那些会让团队容易出错的代码。————StackOverflow上单元测试以及JUnit的创造者Kent Beck的回答

    小结:
    1. 逻辑复杂的。
    2. 容易出错的。
    3. 不易理解的。即使是自己过段时间也会遗忘的,看不懂自己的代码,单元测试代码有助于理解代码的功能和需求
    4. 公共代码。比如自定义的所有http请求都会经过的拦截器;工具类等。
    5. 核心业务代码。一个产品里最核心最有业务价值的代码应该要有较高的单元测试覆盖率。

    三、什么时候写单元测试?

    写单元测试的时机不外乎三种情况:

    1、在具体实现代码之前。这是测试驱动开发(TDD)所提倡的;

    2、与具体实现代码同步进行。先写少量功能代码,紧接着写单元测试(重复这两个过程,直到完成功能代码开发)。其实这种方案跟第一种已经很接近,基本上功能代码开发完,单元测试也差不多完成了。

    3、编写完功能代码再写单元测试。我的实践经验告诉我,事后编写的单元测试“粒度”都比较粗。对同样的功能代码,采取前两种方案的结果可能是用10个“小”的单测来覆盖,每个单测比较简单易懂,可读性可维护性都比较好(重构时单测的改动不大);而第三种方案写的单测,往往是用1个“大”的单测来覆盖,这个单测逻辑就比较复杂,因为它要测的东西很多,可读性可维护性就比较差。

    建议:推荐单元测试与具体实现代码同步进行这个方案的。只有对需求有一定的理解后才能知道什么是代码的正确性,才能写出有效的单元测试来验证正确性,而能写出一些功能代码则说明对需求有一定理解了。

    四、单元测试的好处?

    1)让我们对自己的代码有信心

    修改了代码后单测依然通过的,起码说明我们的修改没有破坏程序的正确性。这从主观上能增加我们对代码的信心。虽然单元测试通过了并不意味着程序就没有bug了,但我们也要了解到这可能不是单元测试的问题。单元测试顾名思义是测试一个”单元”,这个”单元”一般是类或方法,而不是整个系统。对整个系统的测试那是集成测试,功能测试的职责。单元测试追求的是快速反馈,频繁执行。集成测试虽然测“全局”,但成本较高,所以执行频率较少。两者使用场景不同,目的不同。

    2)为代码重构保驾护航

    看到代码很差劲,想重构,但又担心重构之后出问题,怎么办呢?如果有单元测试情况就不一样了,重构完代码,跑一遍单元测试,如果单元测试都通过,基本上可以保证我们的重构没有破坏原来代码逻辑的正确性。不过前提是之前的写的单元测试质量很好,覆盖率很高。当然这仅限于小范围的重构,比如重构一个类或者函数的实现,但对于大刀阔斧的重构(比如单体重构成微服务,面向库表模式重构成DDD),就不适用,那个时候要重写单元测试了。

    3)快速熟悉代码

    单元测试不仅起到了测试的作用,还是一种很好的“文档”,通过单元测试,我们不需要深入的阅读代码,便能知道这段代码做什么工作,有哪些特殊情况需要考虑,包含哪些业务。

    参考

    单元测试系列一-为什么要写单元测试,何时写,写多细

    展开全文
  • 因为此时单元测试和集成测试已经完成,系统测试能够对软件所有功能进行功能测试,能够覆盖系统所有联合的部件,是针对整个产品系统进行的测试,能够验证系统是否满足了需求规格的定义,因此系统测试最重要。

    分享一个大牛的人工智能教程。零基础!通俗易懂!风趣幽默!希望你也加入到人工智能的队伍中来!请点击http://www.captainbed.net

    这些测试步骤分别在软件开发的不同阶段对软件进行测试,个人认为对软件完整功能进行测试的系统测试最重要。因为此时单元测试和集成测试已经完成,系统测试能够对软件所有功能进行功能测试,能够覆盖系统所有联合的部件,是针对整个产品系统进行的测试,能够验证系统是否满足了需求规格的定义,因此系统测试最重要。

    展开全文
  • 单元测试与集成测试

    万次阅读 多人点赞 2019-09-17 08:25:00
    按测试策略和过程,软件测试分为单元测试、集成测试、确认测试和系统测试。 按软件系统工程,测试是软件质量保证的最后的一关。 高质量的程序取决于以下几个方面: 高质量的设计 规范的编码 有效的测试 开发部...

    软件测试分类

    • 按测试用例的设计方法,软件测试分为白盒测试黑盒测试
    • 按测试策略和过程,软件测试分为单元测试、集成测试、确认测试和系统测试
    • 按软件系统工程,测试是软件质量保证最后的一关

    高质量的程序取决于以下几个方面:

    1. 高质量的设计
    2. 规范的编码
    3. 有效的测试

    开发部的测试   效果不好:为什么?

    • 没有时间测试
    • 不知道怎样测试
    • 不好组织
    • 缺乏方法和工具    

    这种情况下,往往把单元测试的任务堆积到系统测试阶段。

    如果把单元测试的任务堆积到系统测试阶段,将会怎样?

    • 大量的故障堆积在项目中后期:项目后10%的工作,占用了项目90%的时间。
    • 故障难以定位
    • 故障飘忽不定
    • 开发、测试人员疲于奔命 

    软件缺陷的修复费用

    单元测试(why)

    • 最高的成本收益比
    • 减少联调和后续测试的时间
    • BUG更容易定位
    • 更有信心去修改老代码 

    单元测试(who)

    • 单元测试可以是开发者本人执行,也可以是独立的专业测试人员执行。
    • 两者各有优势。
    • 建议开发人员必须完整地做单元测试,同时测试人员针对重点模块实施独立的单元测试。

    1、单元测试的目标和任务

    测试的4个阶段:单元测试----->集成测试----->系统测试----->验收测试

    按阶段进行测试是一种基本的测试策略

    定义:     单元测试是对软件基本组成单元进行的测试。

    时机:     单元测试和编码是同步进行,但在TDD中,强调测试在先,编码在后。一般在代码完成后由开发人员完成,QA人员辅助。

    概念:     模块, 组件, 单元

    1.1 为何要进行单元测试?

    • 尽早发现错误   (错误发现越早,成本越低.    发现问题比较容易    修正问题更容易 )
    • 检查代码是否符合设计和规范

    为什么要进行单元测试?

    1.单元测试是不是太浪费时间了?

    • 不经过单元测试,直接进入集成测试,系统正常工作的可能性非常低,大量的时间被花费在跟踪那些简单的Bug上,会导致集成为一个系统时增加额外的工期。
    • 编写完整计划的单元测试和编写实际的代码所花费的精力大致相同。但是,一旦完成了这些单元测试工作,很多Bug将被纠正,在确信他们手头拥有稳定可靠的部件的情况下,开发人员能够进行更高效的系统集成工作,这才是真正意义上的进步。
    • 调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。

    2.单元测试仅仅是为了证明这些代码作了什么吗?

    • 这是那些没有首先为每个单元编写一个详细设计文档而直接跳到编码阶段的开发人员提出的一条普遍的抱怨。这样的测试完全基于已经写好的代码,这无法证明任何事情。
    • 单元测试基于详细设计文档,这样的测试可以找到更多的代码错误,甚至是详细设计的错误。
    • 因此,高质量的单元测试需要高质量的详细设计文档。

    3.我是一个很棒的程序员,是不是可以不进行单元测试呢?

    • 每个都可能犯错误
    • 真正的完整的系统往往是非常复杂的,不能寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。

    4.有集成测试就够了,集成测试将会抓住所有的Bug。

    • 系统规模愈来愈大,复杂度愈来愈高,没有单元测试,开发人员很可能会花费大量的时间仅仅是为了使系统能够运行。
    • 任何实际的测试方案都无法执行。
    • 在系统集成阶段,对单元功能全面测试的负载程度远远的超过独立进行的单元测试过程。
    • 最后的结果是测试将无法达到它所应该有的全面性,一些缺陷被遗漏,并且很多Bug被忽略过去。

    5.单元测试的成本效率不高?

    • 无论什么时候做出修改都要进行完整的回归测试。
    • 生命周期中尽早的对产品进行测试将使效率和质量得到最好的保证
    • Bug修改越晚,费用就越高,单元测试是一个在早期抓住Bug的机会。
    • 相比后阶段的测试,单元测试的创建简单维护容易,并且可以更方便的进行重复。
    • 从全程的测试费用来考虑,相比复杂且旷日持久的集成测试,或是不稳定的系统,单元测试所需的费用是最低的

    单元测试的重要性

    • 一个尽责的单元测试方法将会在产品开发的某个阶段发现很多的Bug,并且修改它们的成本也很低。
    • 系统开发的后期阶段,Bug的检测和修改将会变得更加困难,并要消耗大量的时间和开发费用。
    • 无论什么时候做出修改都要进行完整的回归测试,在生命周期中尽早的对产品代码进行测试将是效率和质量得到最好的保证。
    • 在提供了经过单元测试的情况下,系统集成过程将会大大的简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上,而不会陷入充满很多Bug的单元之中不能自拔。
    • 使测试工作的效率发挥到最大化的关键在于选择正确的测试策略,这包含了完全的单元测试的概念,以及对测试过程的良好的管理,还有适当的使用好工具来支持测试过程。

    单元测试的背景

    开发流程时间表与修改Bug代价的关系图

    • 编程过程中,每写1000行代码会犯几十个错误
    • 编程与编译运行结束后,每1000行代码中大约残留有2-6个Bug
    • 寻找与修改程序错误的代价占总体开发投资的30% -60%
    • Bug在整个研发流程中被发现的越早,修改的代价就越低

    单元测试是什么?

    单元测试,对单个的软件单元或者一组相关的软件单元所进行的测试,是代码级的测试。

    Unit:函数,源代码文件,类

    把测试比作是清洗一台机器:

    • 系统测试就是清除机器外面的尘土。
    • 集成测试就是保证机器各个部件的接头处干净。
    • 单元测试就是清洗各个零件的内部。

    单元测试原则

    • 应该尽早地进行软件单元测试。
    • 应该保证单元测试的可重复性。
    • 尽可能地采用测试自动化的手段来支持单元测试活动。

    1.2 单元测试的目标和要求

    目标: 单元模块被正确编码

    • 信息能否正确地流入和流出单元;
    • 在单元工作过程中,其内部数据能否保持其完整性,包括内部数据的形式、内容及相互关系不发生错误,也包括全局变量在单元中的处理和影响。
    • 在为限制数据加工而设置的边界处,能否正确工作。
    • 单元的运行能否做到满足特定的逻辑覆盖。
    • 单元中发生了错误,其中的出错处理措施是否有效。
    • 指针是否被错误引用、资源是否及时被释放。
    • 有没有安全隐患?是否使用了不恰当的字符串处理函数等。

    单元测试的一系列活动:

    1. 建立单元测试环境,包括在集成开发环境中安装和设置单元测试工具(插件);
    2. 测试脚本(测试代码)的开发和调试;
    3. 测试执行及其结果分析。

    单元测试的主要内容:

    • 目标:确保模块被正确地编码。
    • 依据:详细设计描述。
    • 过程:经过设计、脚本开发、执行、调试和分析结果等环节。
    • 执行者:由程序开发人员和测试人员共同完成。
    • 采用那些测试方法:包括代码控制流和数据流分析方法,并结合参数输入域的测试方法。
    • 测试脚本的管理:可以按照产品代码管理的方法进行类似的配置(并入代码库),包括代码评审、版本分支、变更控制等。
    • 如何进行评估:通过代码覆盖率分析工具来分析测试的代码覆盖率、分支或条件的覆盖率。

    单元测试的一般准则:

    • 软件单元功能与设计需求一致。
    • 软件单元接口与设计需求一致。
    • 能够正确处理输入和运行中的错误。
    • 在单元测试中发现的错误已经得到修改并且通过了测试。
    • 达成了相关的覆盖率的要求。 完成软件单元测试报告。

    任务1:模块独立执行通路测试

    检查每一条独立执行路径的测试。保证每条语句被至少执行一次。

    Checklist:

    • 误解或用错了算符优先级。
    • 混合类型运算。
    • 变量初始化错误、赋值错误。
    • 错误计算或精度不够。
    • 表达式符号错等。

    任务2:模块局部数据结构测试

    检查局部数据结构完整性

    Checklist:  

    • 不适合或不相容的类型说明。  
    • 变量无初值。  
    • 变量初始化或缺省值有错。
    •  不正确的变量名或从来未被使用过。  
    • 出现上溢或下溢和地址异常。

    任务3:模块接口测试

    检查模块接口是否正确

    checklist:  

    • 输入的实际参数与形式参数是否一致。 (个数、属性、量纲)
    • 调用其他模块的实际参数与被调模块的形参是否一致。 (个数、属性、量纲) 
    • 调用预定义函数时所用参数的个数、属性和次序是否正确  
    • 全程变量的定义在各模块是否一致。
    •  外部输入、输出   ( 文件、缓冲区、错误处理 )

    任务4:模块边界条件测试

    检查临界数据处理的正确性

    Checklist:  

    • 普通合法数据的处理。  
    • 普通非法数据的处理。
    •  边界值内合法边界数据的处理。
    •  边界值外非法边界数据的处理。  
    • 其它

    任务5:模块的各条错误处理通路测试

    预见、预设的各种出错处理是否正确有效。

    Checklist:  

    • 输出的出错信息难以理解。  
    • 记录的错误与实际遇到的错误不相符。
    •  在程序自定义的出错处理代码运行之前,系统已介入。  
    • 异常处理不当。  
    • 错误陈述中未提供足够的定位出错的信息。

    2、 静态测试

    静态测试技术:不运行被测试程序,对代码通过检查、阅读进行分析。

    三步曲:  走查(Walk Through)  审查(Inspection)  评审(Review)

    2.1 编码的标准和规范

    • 标准:建立起来必须遵守的规则
    • 规范:建议最佳做法,推荐更好方式

    实施代码规范的原因:  可靠性  可读性和可维护性  可移植性

    2.2 代码评审

    • 一次检查少于200~400行代码
    • 努力达到一个合适的检查速度:300~500LOC/hour
    • 有足够的时间、以适当的速度、仔细地检查,但不宜超过60~90分钟
    • 在审查前,代码作者应该对代码进行注释
    • 使用检查表(checklist)肯定能改进双方(作者和复审者)的结果
    • 验证缺陷是否真正被修复

    1.代码走查(Walk Through)

    定义:采用讲解、讨论和模拟运行的方式进行的查找错误的活动。

    注意:  

    • 引导小组成员在走查前通读设计和编码。
    •  限时,避免跑题。  
    • 发现问题适当记录,避免现场修改。
    •  检查要点是代码是否符合标准和规范,是否有逻辑错误。

    2.正式会议审查(Inspection)

    定义:采用讲解、提问方式进行,一般有正式的计划、流程和结果。主要方法采用缺陷检查表。

    注意:

    •  以会议形式,制定会议目标、流程和规则,结束后要编写报告。  
    • 按缺陷检查表逐项检查。  
    • 发现问题适当记录,避免现场修改。  
    • 发现重大缺陷,改正后会议需要重开。  
    • 检查要点是缺陷检查表,所以该表要根据项目不同不断积累完善。

    走查与审查的比较

     

    走   查

    审   查

    准备

    通读设计和编码

    应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表

    形式

    非正式会议

    正式会议

    参加人员

    开发人员为主

    项目组成员包括测试人员

    主要技术方法

    缺陷检查表

    注意事项

    限时、不要现场修改代码

    限时、不要现场修改代码

    生成文档

    会议记录

    静态分析错误报告

    目标

    代码标准规范,无逻辑错误

    代码标准规范,无逻辑错误

    3.评审(Review)

    定义:通常在审查会后进行,审查小组根据记录和报告进行评估。

    注意:  

    • 充分审查了所规定的代码,并且全部编码准则被遵守。
    •  审查中发现的错误已全部修改。

    3 、动态测试

    动态测试需要真正将程序运行起来,需要设计系列的测试用例保证测试的完整性和有效性。  

    白盒测试  黑盒(灰盒)测试

    驱动程序和桩程序

    运行单元程序有时需要基于被测单元的接口,开发相应的驱动模块和桩模块。

    •  驱动模块(drive):对底层 或子层模块进行测试所编写的 调用这些模块的程序。
    •  桩模块(stub):对顶层或 上层模块进行测试时所编写的 替代下层模块的程序。

    单元测试设计

    • 单元测试模型的设计。
    • 测试项目的设计。

    (1)单元测试模型设计

    • 构造最小运行调度系统,即驱动模块,用于模拟被测模块的上一级模块。
    • 模拟实现单元接口,即单元函数需调用的其他函数接口,即桩模块。
    • 模拟生成测试数据或状态,为单元运行准备动态环境。
    • 对测试过程的支持,对测试结果的保留,对测试覆盖率的记录等。

    单元测试环境的示意图如下:

    (2)测试项目设计

    • 测试项目是测试用例的一个总则,主要是根据测试需求设计测试点,不包含具体实践的用例。
    • 在测试项目的设计中,主要从功能覆盖和代码覆盖两个角度进行考虑。

                   功能覆盖属黑盒的范畴,用来指出测试用例是否已经覆盖了程序应该提供的功能。逻辑覆盖率是考核单元测试质量的一个关键指标。

                    代码覆盖也称逻辑覆盖,包括语句覆盖、分支覆盖、路径覆盖,是一种常用的白盒测试方法。

    • 覆盖率指标:核心代码覆盖率达到100%,共享资源库的代码覆盖率达到100%,非核心代码覆盖率达到90%。

    4、调试与评估

    调试与测试的对象及采用的方法有很大程度上的相似,调试还用到断点控制等排错方法,但其目的却完全不同。测试是为了找出软件中存在的缺陷,而调试是为了解决存在的缺陷。  

    • 软件单元功能与设计需求一致。  
    • 软件单元接口与设计需求一致。
    •  能够正确处理输入和运行中的错误。  
    • 在单元测试中发现的错误已经得到修改并且通过了测试。  
    • 达到了相关的覆盖率的要求。  
    • 完成软件单元测试报告

    5、单元测试的管理

    过程:

    • 在详细设计阶段完成单元测试计划。
    • 建立单元测试环境,完成测试设计和开发。
    • 执行单元测试用例,并且详细记录测试结果。
    • 判定测试用例是否通过。
    • 提交《单元测试报告》。

    单元测试的文档

    1. 《软件需求规格说明书》、《软件详细设计说明书》 -----> 《单元测试计划》
    2. 《单元测试计划》、《软件详细设计说明书》-----> 《单元测试用例》
    3. 《单元测试用例》文档及《软件需求规格说明书》、《软件详细设计说明书》-----> 《缺陷跟踪报告》/《缺陷检查表》   
    4. 《单元测试用例》、《缺陷跟踪报告》、《缺陷检查表》-----> 《单元测试检查表》
    5.   评估----->   单元测试报告》

    7、系统集成的模式与方法

    集成测试定义

    定义

    集成测试又称“组装测试”、“联合测试”。集成测试遵循特定的策略和步骤将已经通过单元测试的各个软件单元(或模块)逐步组合在一起进行测试,以期望通过测试发现各软件单元接口之间存在的问题。

    集成测试对象

    理论上凡是两个单元(如函数单元)的组合测试都可以叫做集成测试。实际操作中,通常集成测试的对象为模块级的集成和子系统间的集成,其中子系统集成测试称为组件测试。

    集成测试目的与意义

    考虑以下问题:

    • 在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;
    • 各个子功能组合起来,能否达到预期要求的总体功能;
    • 一个模块的功能是否会对另一个模块的功能产生不利的影响;
    • 全局数据结构是否有问题 单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。  
    • 共享资源访问的测试  (   要想发现并排除在模块连接中可能发生的上述问题,就需要进行 集成测试。)

    集成测试有以下不可替代的特点:

    • 单元测试具有不彻底性,对于模块间接口信息内容的正确性、相互调用关系是否符合设计无能为力。只能靠集成测试来进行保障。
    • 同系统测试相比,由于集成测试用例是从程序结构出发的,目的性、针对性更强,测试项发现问题的效率更高,定位问题的效率也较高;
    • 定位问题较快,发现问题后比较容易定位,所以能够有效地加快进度,减少隐患。

    集成测试(when)

    • 在开始体系结构设计的时候开始制定测试方案;
    • 在进入详细设计之前完成集成测试方案;
    • 在进入系统测试之前结束集成测试。

    集成测试(who)

    • 集成测试可以在开发部进行,也可以由独立的测试部执行。
    • 开发部尽量进行集成测试,测试部有选择地进行集成测试。

    集成测试原则

    • 集成测试是产品研发中的重要工作,需要为其分配足够的资源和时间。
    • 集成测试需要经过严密的计划,并严格按计划执行。
    • 应采取增量式的分步集成方式,逐步进行软件部件的集成和测试。
    • 应重视测试自动化技术的引入与应用,不断提高集成测试效率。
    • 应该注意测试用例的积累和管理,方便进行回归并进行测试用例补充。

    集成测试内容

    • 集成功能测试
    • 接口测试
    • 全局数据结构测试
    • 资源测试
    • 任务优先级冲突测试
    • 性能和稳定性测试

    集成测试、单元测试与系统测试的差别

    测试类型

    对象

    目的

    测试依据

    测试方法

    单元测试

    模块内部的程序错误

    消除局部模块的逻辑和功能上的错误和缺陷

    模块逻辑设计,模块外部说明

    大量采用白盒测试方法

    集成测试

    模块间的集成和调用关系

    找出与软件设计相关的程序结构,模块调用关系,模块间接口方面的问题

    程序结构设计

    结合使用白盒与黑和测试方法,采用较多黑盒方法构造测试用例 

    系统测试

    整个系统,包括系统中的硬件等

    对整个系统进行一系列的整体、有效性测试

    系统结构设计,目标说明书,需求说明书等

    黑盒测试

    由以上可以看出,整个软件系统的测试过程是:先对各个软件模块进行单元测试,然后把经过单元测试的各个模块组装起来进行集成测试,最后把经过集成测试的子系统合成软件版本,对照需求规格,在实际环境下,进行系统功能验证。 

    7.1 集成测试前的准备

    人员安排 、测试计划、测试内容 、集成模式、测试方法

    7.2 集成测试的模式

    渐增式测试模式与非渐增式测试模式:

    • 非渐增式测试模式:先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序,如大棒模式。
    • 渐增式测试模式:把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试。

    各自的优缺点

    • 非渐增式测试模式优缺点:工作量较小;发现模块间接口错误较晚;发现错误较难诊断,可以并行测试。
    • 渐增式测试模式优缺点:要编写的软件较多,工作量较大;发现模块间接口错误较早;测试执行更彻底;需要较多的机器时间。

    7.3 大棒集成方法(Big-bang Integration)

    采用大棒集成方法,先是对每一个子模块进行测试(单元测试阶段),然后将所有模块一次性的全部集成起来进行集成测试 。

    因为所有的模块一次集成的,所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用,适合在规模较小的应用系统中使用。  

     非增量式集成测试实例

     

    评述:模块d1、d2、d3、d4、d5是对各个模块做单元测试时建立的驱动模块,s1、s2、s3、s4、s5是为单元测试而建立的桩模块。这种一次性集成方式将所测模块连接起来进行测试,但是一次试运行成功地可能性并不大。其结果发现有错误,但茫然找不到原因,差错和改错都会遇到困难。    

    适应于一个维护型或被测试系统较小的项目。 

    非增量式策略——优缺点:

    • 优点: ①方法简单 ②允许多测试人员同时并行工作,人力物力资源利用率较高
    • 缺点: ①必须为每个模块准备相应的驱动模块和桩模块,测试成本较高 ②一旦集成后包含多种错误,难以纠正。

    7.4 自顶向下和自底向上集成方法

    驱动程序/驱动模块(driver),用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据,把相关的数据传送给被测模块,启动被测模块,并打印出相应的结果。

    桩程序/桩模块(stub),也有人称为存根程序,用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用,它们一般只进行很少的数据处理,例如打印入口和返回,以便于检验被测模块与其下级模块的接口。

    1.自顶向下法(Top-down Integration) 

    自顶向下法,从主控模块(主程序)开始,沿着软件的控制层次向下移动,逐渐把各个模块结合起来。

    组装过程可以采用深度优先策略和宽度优先策略

    • 深度优先:从最顶层单元开始,持续向下到下一层,选择一个分支,自顶而下一个一个的集成这条分支上的所有单元,直到最底层,然后转向另一个分支,重复这样的集成操作直到所有的单元都集成进来。
    • 广度优先:从最顶层单元开始,持续向下到下一层, 一个个完成下一层上所有单元集成后,再转向下面一层,重复这样的集成操作直到所有的单元都集成进来。

     

    自顶向下增量测试 

    自顶向下集成测试的整个过程由3个步骤完成:  

    1. 主控模块作为测试驱动器。   
    2. 根据集成的方式(深度或广度),下层的桩模块一次一次地被替换为真正的模块。
    3. 在每个模块被集成时,都必须进行单元测试。     重复第2步,直到整个系统被测试完成。  

    深度优先组装方式:

    广度优先组装方式:

    自顶向下法——优缺点

    优点:

    不需要测试驱动程序;

    能够在测试阶段的早期实现并验证系统的主要功能;

    能在早期发现上层模块中的接口错误。 

    缺点:

    需要桩程序,要使桩模块能够模拟实际子模块的功能十分困难;

    底层验证被推迟; 同时涉及复杂算法,真正输入/输出的模块一般在底层,

    他们是最容易出问题的模块,到测试和集成的后期才遇到这些模块,一旦发现问题导致过多的回归测试。

    自顶向下增量式集成适用范围:

    • 产品控制结构比较清晰和稳定;
    • 高层接口变化较小;
    • 底层接口未定义或经常可能被修改;
    • 产口控制组件具有较大的技术风险,需要尽早被验证;
    • 希望尽早能看到产品的系统功能行为。

    练习:

    (1)对如下结构采用自顶向下深度优先策略进行测试

     

    (2)一个按广度优先测试进行集成测试

    1. 首先,对顶层的模块A进行单元测试,这时需配以被调用子模块s1、s2、s3,以模拟被它调用的模块B、C和D。
    2. 其后,把模块B、C和D与顶层模块A连接起来,再对模块B和D配以被调用模拟子模块s4和s5以模拟对模块E和F的调用。
    3. 最后,去掉被调用模拟子模块s4和s5,把模块E和F集成后再对软件完整的结构进行测试。

    2.自底向上法(Bottom-up Integration)

    自底向上法,测试从原子模块(软件结构最底层的模块)开始集成以进行测试。自底向上进行集成和测试时,需要为所测模块或子系统编制相应的驱动模块。

    自底向上增量式集成测试步骤:

    1. 起始于模块依赖关系树的底层叶子模块,也可以把两个或多个叶子模块合并到一起进行测试
    2. 使用驱动模块对步骤1选定的模块(或模块组)进行测试
    3. 用实际模块代替驱动模块,与它已测试的直属子模块组装成一个更大的模块进行测试
    4. 重复上面的行为,直到系统最顶层模块被加入到已测系统中

    自底向上增量式测试

    一个自底向上增量式集成测试的典型例子

    1. 首先,(a)、(b)、(c)表示树状结构图中处于最下层的叶结点模块E、C和F,由于它们不再调用其他模块,对它们进行单元测试时,只需配以驱动模块d1、d2和d3,用来模拟B、A和D对它们的调用。
    2. 完成这3个单元测试后,再按(d)和(e)的形式,分别将模块B和E及模块D和F连接起来,再配以驱动模块d4和d5实施部分集成测试。
    3. 最后按图(f)的形式完成整体的集成测试。

    自底向上法——优缺点

    与自顶向下法刚好相反。

    优点:

    • 不需要桩程序
    • 同时由于涉及到复杂算法和真正输入/输出的模块最先得到集成和测试,可以把最容易出问题的部分在早期解决
    • 自底向上增值的方式可以实施多个模块的并行测试,提高测试效率。

    缺点:

    • “程序一直未能作为一个实体存在,直到最后一个模块加上去后才形成一个实体”。也就是说,在自底向上集成和测试的过程中,对主要的控制直到最后才接触到
    • 驱动的开发工作量大;

    自底向上增量式集成适用范围:

    适用范围:

    • 适应于底层接口比较稳定;
    • 高层接口变化比较频繁;
    • 底层组件较早被完成。

    3.混合策略(Modified Top-down Integration)

    混合法:对软件结构中较上层,使用的是“自顶向下”法;对软件结构中较下层,使用的是“自底向上”法,两者相结合。

    7.5 三明治集成方法(Sandwich Integration)

    • 混合式集成
    • 把系统划分成三层,中间一层为目标层,目标层之上采用自顶向下集成,之下采用自底向上集成

    三明治集成策略

     集成步骤

    • 首先对目标层之上一层使用自顶向下集成,因此测试A,使用桩代替B,C,D
    • 其次对目标层之下一层使用自底向上集成,因此测试E,F,使用驱动代替B,D
    • 其三,把目标层下面一层与目标层集成,因此测试(B,E),(D,F),使用驱动代替A
    • 最后,把三层集成到一起,因此测试(A,B,C,D,E,F)

    优缺点分析    

    优点: 集合了自顶向下和自底向上两种策略的优点

    缺点: 中间层测试不充分,在真正集成之前每一个独立的模块没有完全测试过

    适用范围: 适应于大部分软件开发项目

    改善的三明治集成方法

    改进的三明治集成方法,不仅自两头向中间集成,而且保证每个模块得到单独的测试,使测试进行得比较彻底 。

    集成策略框图

    几种集成方法性能的比较

     

    自底向上

    自顶向下

    混合策略

    大棒

    三明治

    改进三明治

    集成

    基本程序能工作时间

    需要驱动程序

    需要桩程序

    工作并行性

    特殊路径测试

    容易

    容易

    容易

    中等

    容易

    计划与控制

    容易

    容易

    集成策略选择

    7.6  持续集成

    • 通常系统集成都会采用持续集成的策略,软件开发中各个模块不是同时完成,根据进度将完成的模块尽可能早的进行集成,有助于尽早发现Bug,避免集成中大量Bug涌现。  
    • 而且容易定位Bug、修正Bug,最终提高软件开发的质量与效率。

    7.7 集成测试流程

    集成测试主要由系统部的系统设计人员、软件评测部完成,开发人员也参与集成测试。集成测试相对来说是挺复杂的,而且对于不同的技术、平台和应用差异也比较大,更多是和开发环境融合在一起。集成测试所确定的测试的内容,主要来源于设计模型。

    集成测试流程

     (1)集成测试计划

    输入 :需求规格说明书、概要设计文档、 产品开发计划路标

    输出:集成测试计划

    活动步骤

    • 确定被测试对象和测试范围
    • 评估集成测试被测试对象的数量及难度,即工作量
    • 确定角色分工和划分工作任务
    • 标识出测试各阶段的时间、任务、约束等条件
    • 考虑一定的风险分析及应急计划
    • 考虑和准备集成测试需要的测试工具、测试仪器、环境等资源
    • 考虑外部技术支援的力度和深度,以及相关培训安排
    • 定义测试完成标准

    (2)集成测试分析和设计

    集成测试分析和设计的主要目的是制定测试大纲(测试方案)。集成测试大纲规定了今后的集成测试内容、测试方法以及可测性接口,以后所有集成测试均在该大纲的框架下进行,所以,制定一份完善的集成测试大纲非常重要。

    输入:需求规格说明书 概要设计 集成测试计划

    输出:集成测试设计方案

    活动步骤

    • 被测对象结构分析
    • 集成测试模块分析
    • 集成测试接口分析
    • 集成测试策略分析
    • 集成测试工具分析
    • 集成测试环境分析
    • 集成测试工作量估计和安排

    (3)实施阶段

    输入:需求规格说明书 概要设计 集成测试计划 集成测试设计

    输出:集成测试用例 集成测试规程 集成测试代码、集成测试脚本、集成测试工具(如果有)

    活动步骤

    • 集成测试用例设计
    • 集成测试规程设计
    • 集成测试代码设计(如果需要)
    • 集成测试脚本(如果需要)
    • 集成测试工具(如果需要)

    (4)执行阶段

    输入

    • 需求规格说明书
    • 概要设计
    • 集成测试计划
    • 集成测试设计
    • 集成测试用例
    • 集成测试规程
    • 集成测试代码(如果有)
    • 集成测试脚本(如果有)
    • 集成测试工具(如果有)
    • 详细设计
    • 代码
    • 单元测试报告

    输出

    • 集成测试报告

    活动步骤

    • 执行集成测试用例
    • 回归集成测试用例
    • 撰写集成测试报告

    相应过程的测试文档

     

    展开全文
  • tag , 便签,广告: qt单元测试用法,qt测试例子,qt单元测试demo,qt单元测试简单例子,qt单元测试例程,qt单元测试简单例子, qt5单元测试例子,qt5单元测试代码,qt5单元测试工程例子,测试运行ok。 1. 建立工程...
  • IntelliJ IDEA单元测试入门

    万次阅读 多人点赞 2016-08-09 20:10:17
    参考文章地址地址:JUnit4单元测试入门教程 IDEA单元测试及代码覆盖率 IDEA添加jar包的三种方式 本文按以下顺序讲解JUnit4的使用 下载jar包单元测试初体验自动生成测试类执行顺序@Test的属性
  • Java的单元测试和集成spring单元测试

    千次阅读 2016-08-30 21:04:26
    今天我们来聊下junit(单元测试)。 为了后期测试基于spring的单元测试,我们直接新建spring工程。 新建之后,我们先讲一般在java项目中怎么去做单元测试。 我们先定义一个实体User 在service
  • 软件测试_单元测试和集成测试

    千次阅读 2019-11-25 19:39:27
    title: 软件测试_单元测试和集成测试 date: 2019-11-25 15:58:23 categories: 软件测试 tags: 单元测试和集成测试 什么是单元测试 单元测试就是对已实现的软件最小单元进行测试,以保证构成软件的各个单元的质量...
  • Maven单元测试

    万次阅读 2018-01-11 10:32:09
    Maven单元测试, maven配置,使用单元测试
  • 基础配置:Module:app中增加相关配置 defaultConfig中增加配置testInstrumentationRunner配置: ...单个类单元测试 ...单个类的单元测试比较简单,在类中右击选择Go To--->Test public class JUnitBean
  • 单元测试是什么 单元测试是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确,通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为1。 单元测试的好处 ...
  • JUnit单元测试

    千次阅读 2017-05-03 11:33:47
    软件测试很多分类,从测试的方法上可分为:黑盒测试、白盒测试、静态测试、动态测试等;...那么今天我们就来说说什么是单元测试,为什么要进行单元测试,以及如更好的何进行单元测试单元测试目的是什
  • golang 单元测试

    千次阅读 2018-01-31 22:31:04
    单元测试是质量保证十分重要的一环,好的单元测试不仅能及时地发现问题,更能够方便地调试,提高生产效率,所以很多人认为写单元测试是需要额外的时间,会降低生产效率,是对单元测试最大的偏见和误解 go 语言原生...
  • Qt单元测试-单元测试1

    千次阅读 2018-05-23 14:05:10
    转载:http://blog.51cto.com/9291927/2114179Qt高级——QTestLib单元测试...QTestLib提供了单元测试框架的基本功能,并提供了针对GUI测试的扩展功能。2、QTestLib特性QTestLib是为了简化QT程序或库的单元测试工作而...
  • 单元测试是对软件组成单元进行测试,目的是检验软件基本组成单元的正确性,测试对象是软件设计的最小单位 - 模块,又称为模块测试 单元测试的实质是代码测代码 测试阶段: 编码后或者编码前(TDD,编码前属于测试...
  • JavaScript单元测试

    千次阅读 2016-07-15 15:35:34
    编写代码时,以单元测试代码伴随正式的功能代码是很好的实践和习惯,不仅可以保证最终代码的质量,对用户负责,也可以让自己对写出的代码更信心和把握。JavaScript在现代Web开发中占的比重越来越大,早已不是在...
  • iOS单元测试之接口测试

    千次阅读 2017-03-02 09:49:08
    记得上篇关于单元测试的文章是2015年,当时刚买了芈君的《iOS测试指南》,作为启蒙书籍,将书中的知识点都尝试了一下,但是由于在项目中没有实施,自己对单元测试的重要性和了解并没有太深入。 为什么要推动单元...
  • Javascript单元测试及接口测试

    千次阅读 2018-09-30 16:15:25
    什么是单元测试 为什么要做单元测试 javascript测试框架对比 koa2中如何使用ava做单元测试 vue中如何使用ava做单元测试 koa2中如何使用ava做接口测试 单元测试是什么 单元测试(unit testing)指的是以软件的单元...
  • 单元测试规范

    千次阅读 2017-02-15 11:13:40
    单元测试规范
  • 单元测试、集成测试和功能测试

    万次阅读 2017-09-19 19:20:20
    一、单元测试 Unit Tests单元测试用于测试最小功能单元,比如单个方法(给定一个指定状态的类,然后调用该类的x方法,最后检查状态是否符合预期)。单元测试应该聚焦在一个特定的功能上(比如,在一个空的stack上调...
  • 单元测试有必要吗

    千次阅读 2015-10-08 17:18:47
    单元测试,是对程序中的最小单元进行测试,一般是函数。通过比较函数的返回值和期望值,来断定测试是否通过。
  • 单元测试任务包括哪些

    千次阅读 2013-10-07 16:06:48
    单元测试,处于软件测试初期阶段,任务主要包括:模块接口测试、模块局部数据结构测试、模块中所有独立执行通路测试、模块的各条错误处理通路测试、模块边界条件测试。 模块接口测试是单元测试的基础。只有在...
  • 单元测试计划

    2008-07-31 16:11:15
    单元测试计划:如何做单元测试
  • 单元测试和功能测试

    千次阅读 2018-01-06 11:33:47
    单元测试和功能测试区别 很多时候,系统开发好比建筑房屋。尽管这种类比不很恰当,但为了理解单元测试与功能测试的区别,我们可以扩充这种类比。单元测试好比房屋建筑现场的建筑监理员。他关心房屋的各个内部系统...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 604,225
精华内容 241,690
关键字:

单元测试有哪些