网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
*首先对目标层上面的一层采用自顶向下的测试策略,对主模块A进行测试,对A调用的子模块(目标层)用桩单元代替。
*其次对目标层下面的一层采用自底向上的测试策略。
*最后将三层集成在一起。
(4)优点:集合了自顶向下和自底向上的两种集成策略的优点。
(5)缺点:中间层在被集成前测试不充分。
(6)适用范围:大部分软件开发项目都可以使用这种集成策略。
基干集成(Backbone Integration)
(1)概念:在很多系统中,尤其在嵌入式系统中,一般可以划分成两个部分:内核部分(基干部分)和外围应用部分,这两部分经常会被不同的项目组并发开发。
(2)目的:结合自顶向下,自底向上和大爆炸集成的元素,以验证紧密耦合的子系统间的互操作性。
(3)策略:
*对基干中的每个模块进行单独的充分的测试,必要时使用驱动和桩。
*对基干中所有的模块进行大爆炸集成,形成基干子系统,并使用一个驱动模块检查经过大爆炸的基干。
*对应用的控制子系统进行自顶向下的集成。
*把基干和控制子系统进行集成,重新构造控制子系统。
*对个应用子系统采用自底向上的集成策略。
*集成基干子系统,控制子系统和各应用子系统形成整个系统。
(4)优点:具有三明治集成的优点,更适合于大型复杂项目的集成。
(5)缺点:
*必须对系统的结构和相互依存性进行仔细的分析。
*必须开发桩和驱动模块,并且由于被测系统的复杂性导致这些模块开发工作量的加大,可以通过复用技术在一定程度上降低成本。
*由于局部采用了大爆炸的策略,所以有些接口可能测试不完整。
(6)适用范围:适合大型复杂的项目
*具有多层协议的嵌入式系统。
*操作系统产品
分层集成(Layers Integration)
(1)概念:分层模型在通讯系统中很常见,分层集成就是针对这个特点使用的一种集成。
(2)目的:通过增量式集成的方法验证一个具有层次性体系结构的应用系统的稳定性和互操作性。
(3)策略:
*划分系统的层次。
*确定每个层次内部的集成策略,该策略可以使用大爆炸集成,自顶向下集成,自底向上集成和三明治集成中的任何一种策略,一般对于顶层可能还有第二层的内部采用自顶向下的集成策略;对于中间采用自底向上的集成策略,对于底层主要采用进行单独测试。
*确定层次间的集成策略,该策略可以使用大爆炸集成,自顶向下集成,自底向上集成和三明治集成中的任何一种策略。
(4)优缺点:因为每个层次间和层次内部采用的策略不同,所以优缺点也就是和它采用的测试策略相对应。
(5)适用范围:有明显线性层次关系的产品系统。
基于功能的集成(Function-Based Integration)
(1)概念:在开发过程中,尽早的看到系统主要功能的实现,对于谈对来说也是很有必要的,基于功能的集成是从功能角度出发,按照功能的关键程度对模块的集成顺序进行组织。
(2)目的:采用增值的方法,尽早的验证系统关键功能。
(3)策略:
*确定功能的优先级别。
*分析优先级别最高的功能路径,把该路径上的所有模块集成到一起,必要时使用桩模块和单元模块。
*增加一个关键功能,继续上面一个步骤,直到所有模块都被集成到被测系统中。
(4)优点:
*采用该方法,可以尽快的看到关键功能的实现,并验证关键功能的正确性。
*由于该方法在验证某个功能的时候,可能会加入多个模块,因此在进度上,比自顶向下和自底向上还有三明治的集成策略要快一点。
*接口的覆盖使用的测试用例比较少。
*可以减少驱动模块的开发
(5)缺点:
*对于复杂的系统,功能之间的相互关联性可能是错综复杂并难以分析的。
*对有些接口的测试不充分,会丢失许多接口错误。
*一些初始的集成需要使用桩模块。
*可能会有比较大的冗余测试。
(6)适用范围:
*关键功能具有较大风险的产品。
*技术探索性的项目,其功能的实现远比质量更关键。
*对于功能的实现没有把握的产品。
基于进度的集成(Schedule-Based Integration)
(1)概念:进度压力在我们实际的工作中,每个软件开发项目都会遇到,。
为了完成进度,有可能会牺牲质量,基于进度的集成就是在兼顾质量和进度两者之间寻找了一个均衡点。
(2)目的:尽可能早的进行集成测试,提高开发与集成的并行性,有效的缩短进度。
(3)策略:这个集成的策略就是把最早可获得的代码拿来激励进行集成,必要的时候开发桩模块和驱动模块,子啊最大程度上保持与开发的并行性,从而缩短了项目集成的时间。
(4)优点:
*具有比较高的并行度。
*有效缩短项目开发的进度。
(5)缺点:
*可能最早拿到的模块之间缺乏整体性,只能进行独立的集成,导致许多接口必须等到后期才能验证,但此时系统可能已经很复杂,往往无法发现有效的接口问题。
*桩模块和驱动模块的工作量可能会变得很庞大。
*由于进度的原因,模块可能很不稳定且会不断变动,导致测试的重复和浪费。
(6)适用范围:进度优先级高于质量的项目。
集成测试策略
集成测试是一种正规测试过程,必须精心计划,并与单元测试的完成时间协调起来。在制定测试计划时,应考虑如下因素:
1、是采用何种系统组装方法来进行组装测试;
2、组装测试过程中连接各个模块的顺序;
3、模块代码编制和测试进度是否与组装测试的顺序一致
4、测试过程中是否需要专门的硬件设备;
解决了上述问题之后,就可以列出各个模块的编制、测试计划表,标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
在缺少软件测试所需要的硬件设备时,应检查该硬件的交付日期是否与集成测试计划一致。例如,若测试需要数字化仪和绘图仪,则相应测试应安排在这些设备能够投入使用之时,并需要为硬件的安装和交付使用保留一段时间,以留下时间余量。此外,在测试计划中需要考虑测试所需软件(驱动模块、桩模块、测试用例生成程序等)的准备情况。
单元测试后,有必要进行集成测试,发现并排除在模块连接中可能发生的上述问题,最终构成要求的软件子系统或系统。对子系统,集成测试也叫部件测试。
任何合理地组织集成测试,即选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常,有两种不同的组装方式:一次性组装方式和增值式组装方式。
集成测试完成标准
怎样判定集成测试过程完成了,可按以下几个方面检查:
1、成功地执行了测试计划中规定的所有集成测试;
2、修正了所发现的错误;
3、测试结果通过了专门小组的评审。
集成测试应由专门的测试小组来进行,测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
在完成预定的组装测试工作之后,测试小组应负责对测试结果进行整理、分析,形成测试报告。测试报告中要记录实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出不能解决、还需要管理人员和开发人员注意的一些问题,提供测试评审和最终决策,以提出处理意见。
软件测试中的集成测试到底是什么?集成的方法又有哪些?
已剪辑自: https://blog.csdn.net/weixin_67553250/article/details/126650989
小编热衷于收集整理资源,记录踩坑到爬坑的过程。希望能把自己所学,实际工作中使用的技术、学习方法、心得及踩过的一些坑,记录下来。也希望想做软件测试的你一样,通过我的分享可以少走一些弯路,可以形成一套自己的方法,并应用到实际中。
目录
前言
综合测试整合测试非常复杂,需要一些开发和逻辑技能。的确如此!那么把这个测试整合到我们的测试策略中的目的是什么呢?这个问题我们先不着急回答,让我们一步步往下看你就知道了。
为什么要进行集成测试?
以下是一些原因:
①实际上,当开发一个应用程序时,它被分成更小的模块,并将其分配给每个开发者一个模块。一名开发者实现的逻辑与其他开发者完全不同,因此有必要检查开发人员实现的逻辑是否符合预期,并按规定的标准提供正确的值。
②大多数情况下,当数据从一个模块移动到另一个模块时,数据的表面或结构会发生变化。添加或删除某些值会导致后续模块出现问题。
③该模块还与某些第三方工具或应用编程接口互动,这些工具或应用编程接口也需要测试,以确保应用编程接口/工具接收的数据正确,并且产生的响应是预期的。
④测试中一个非常常见的问题——频繁改变需求!:)许多时间开发者在没有单元测试的情况下部署和改变。那时候,集成测试变得很重要。
基本概念:将软件集成起来后进行测试。集成测试又叫子系统测试、组装测试、部件测试等。集成测试主要是针对软件高层设计进行测试,一般来说是以模块和子系统为单位进行测试。
集成测试包含的层次:
\1. 模块内的集成,主要是测试模块内各个接口间的交互集成关系;
\2. 子系统内的集成,测试子系统内各个模块间的交互关系;
\3. 系统集成,测试系统内各个子系统和模块间的集成关系;
**集成测试的本质:**都是测试接口之间的关系。
**补充:**集成测试既有白盒测试的成分,也有黑盒测试的成分,结合了白盒测试和黑盒测试的特点,一般把他归入灰盒测试。
集成测试和软件概要(高层)设计的关系
软件概要(高层)设计又叫架构设计,架构设计中极重要的一个部分就是接口关系图,集成测试大体上就是依赖接口关系图和模块接口来进行测试。在一个设计良好的系统中,软件的接口关系图应该是一个无环有向图(分层的图)。
集成测试是必须的吗?
集成测试一般说来是必需的,但是实际情况中往往由于时间进度上的问题,没有足够的时间做集成测试,还有许多原因导致人们不愿意做集成测试。但是一下几种情况是一定要做集成测试的:
\1. 对软件质量要求较高的软件系统,如:航天软件、电信软件、系统底层软件等。
\2. 使用范围比较广、用户群数量较大的软件。
\3. 使用类是C/C++这种带指针的语言开发的软件。
\4. 类库、中间件等产品。
注:集成测试是一种测试范围很广的测试,当集成测试向下继续细化时就成了单元测试。
集成测试与单元测试的区别:
1. 测试的单元不同
单元测试是针对软件的基本单元(如:函数)所做的测试,而集成测试则是以模块和子系统为单元进行的测试,主要测试接口间的关系。
2. 测试的依据不同
单元测试是针对软件的详细设计做的测试,测试用例的主要依据也是详细设计。而集成测试是针对软件的概括设计做的测试,测试用例的主要依据则是概括设计。
3. 测试空间不同
集成测试主要测试的是接口层的测试空间,单元测试主要测试的是内部实现层的测试空间。
4. 集成测试使用的方法和单元测试不同
集成测试关注的是接口的集成,和单元测试只关注单个单元,因此在具体测试方法上也不同。
集成测试的集成方法:
集成方法主要有大爆炸集成、自底向上集成、自顶向下集成和三明治集成等方法。它们都是基于接口调用关系图的集成方法。
集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成一个完整的系统进行的测试,故也称组装测试或联合测试。
实践证明,单个模块能正常工作,组装后不见得仍能正常工作,这是因为:
(1)单元测试使用的驱动模块和桩模块,与它们所代替的模块并不完全等效,因此单元测试有不彻底、不严格的情况。
(2)各个模块组装起来,穿越模块接口的数据可难会丢失。
(3)一个模块的功能可能会对另一个模块的功能产生不利的影响。
(4)各个模块的功能组合起来可能达不到预期要求的主功能。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
W-1715624586905)]
[外链图片转存中…(img-ftlb6JGX-1715624586905)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新