为什么一定要做集成测试?

931 篇文章 26 订阅
646 篇文章 0 订阅

集成测试,我们都不陌生,几乎我们产品每天都在进行。但是我们真的有好好思考:为什么一定要做集成测试吗?只是为了简单的将“积木”搭起来就行,还是有什么其他的深意?

深意可能不一定会有,但是意义是肯定存在的。

如何看待集成测试?

James Bach认为,集成测试的动机是挖掘与集成相关的潜在风险,是专门为评估与整合相关的风险而设计的测试。而我认为,集成测试是检验一个产品是否初具雏形的关键。

试想一下,如果一个生产,多个部门负责生产车轮、轴承、发动机等零件,如果零件各自生产出来了,但不经过组装测试,而直接等待最终组装成整车,这会是一个多么大的风险?

为什么要集成测试?

我们先来看看整体的意义。

我们还是采用汽车生产这个比喻,很容易就能发现:对于一个产品整体来说,在某种程度上和某种程度上它由部分组成,为各部分创造一个内部环境,整体拥有部分不具有的属性。

我们分别来理解上面所说的三个观点。

整体由部分组成

例如:我们汽车由车轮、发动机、轴承、车架、方向盘等部分组成,而每个部分可能有不同的来源(不同的部门或者不同的提供者)。

各部分是为不同的目的而生产,比如车轮是为了行驶,发动机是为了提供动力来源,方向盘是为了方便使用者掌握方向。它们具有不同的属性,还有可能不是同时间周期创造,比如,车轮可能通过第三方购买,而第三方是早前存货。

整体为各部分创造一个内部环境

这个创造或割离出来的内部环境可以使各部分相互作用,相互依存,以及与外部环境的相互作用,而这个内部环境从外部是看不见的。

例如:汽车点火按钮与发动机之间的联系,这就属于一个内部环境。

整体拥有部分不具有的属性

整体依赖于部分,但又与部分不同,拥有他们不具有的属性。例如:汽车可以很方便的切速形势,但单独的车轮不行。又比如,一个简单的例子是三脚架的稳定性,它不是在它的任何一个单独的腿上,而是在所有的腿一起工作时。

由此可见,仅仅通过观察一个积分的各个部分,你可能无法分辨出你想知道的关于它的一切。这就是集成风险存在的原因。在复杂或重要的系统中,集成测试将是极其重要的,特别是在进行了更改之后。

集成测试时的启发性关注点?

既关注整体,也要关注部分

“整体”由“部分”构成,但并意味着一定先存于整体之前,或者在集成的过程中没有改变。

这意味着我们需要我们可以富有成效地思考产品的各个部分,以及它们如何与其他部分相互作用。

既关注集成,也要关注解体

“解体也会带来整合”,当你把某部分拿走,或者把产品拆开,你最终会得到一个新的整合,这个时候也会有风险存在。

举个例子:集成过程中某个组件延迟集成,对整个产品造成的风险。

要关注集成的程度和种类

“融合不是全或无——有不同的程度和种类“。

一个产品可能会意外地集成,因为它使用的是没有人意识到它拥有的部分。它可能是松散集成的,比如一只可以丢弃尾巴的壁虎,或者一个带有插件的浏览器,它可能是紧密集成的。

再举个例子:当我们从一个产品中获取代码,并将其添加到另一个产品的不同位置时,我们可以边走边编辑,它可能会保留其部件的现有接口,或违反它们,或重新设计它们,或消除它们。

特别是在集成测试时,我们往往重心在正向集成上,而忽略了解体时存在的一些风险。举例:常见来说,产品多组件安装,我们常关注安装是否成功,而容易忽略部分卸载或整体卸载时的风险。

怎么进行集成测试?

本节我们要说的是怎么拆分集成测试。

从整个产品来说,我们可以做两层或更多层的集成测试。例如:我们可以对发动机这个组件设置一个集成测试,因为放大来看,发动机也是由许多小组件构成。同样的,还可以对车轮设置一个集成测试。

而从整体来说,汽车本身也可以设置一个集成测试,因为它是一个对外交付的产品。

有的人可能就会说,到汽车应该是系统测试了!这两者的差异主要在于你的关注点是什么:

  • 如果你关注的是组件间的接口是否合理可用,那么你可以把这个环节叫做集成测试;

  • 如果你关注的是整车的可用性和功能性,你可以叫它系统测试。

不同的人可能会将不同的事物识别为部件、环境或产品,没关系,我们也可以自由地移动镜头,尝试不同的视角。所以说,我们集成测试设置的粒度取决于我们的关注范围,并没有一个一成不变的标准。

因此,我们可以从产品层面划分集成测试,也可以从团队层面划分集成测试。

产品层面划分

假如产品P由组件C1、C2、…、C7组成,我们可以针对单个组件设置一级集成测试。

如,ItergrationTest1、ItergrationTest2、…、ItergrationTest7,再往上,交互组件C1和C2,C3和C4、…、C7之间可以设置二级集成测试ItergrationTest12、ItergrationTest34567,直到产品级集成测试ItergrationTestP。

团队层面划分

根据不同团队划分集成测试。一个团队可能会负责多个组件,组件的集成测试交由团队考虑。因此,从团队层面考虑,我们可以划分为团队集成测试TeamItergrationTest1、TeamItergrationTest2……,以及项目级集成测试ProjectItergrationTest。

最后说一说

从上面描述我们可以看出集成测试在产品研发过程中的重要性,以及我们在设计集成测试和分层集成测试时容易忽略的一些思考点。希望能够帮助正在阅读的你有所收获~

最后: 下方这份完整的软件测试视频学习教程已经整理上传完成,朋友们如果需要可以自行免费领取【保证100%免费】

在这里插入图片描述

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值