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

发表于:2023-5-18 09:45

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:刘晓佳Rachel    来源:简书

分享:
  集成测试,我们都不陌生,几乎我们产品每天都在进行。但是我们真的有好好思考:为什么一定要做集成测试吗?只是为了简单的将“积木”搭起来就行,还是有什么其他的深意?
  深意可能不一定会有,但是意义是肯定存在的。
  如何看待集成测试?
  James Bach认为,集成测试的动机是挖掘与集成相关的潜在风险,是专门为评估与整合相关的风险而设计的测试。而我认为,集成测试是检验一个产品是否初具雏形的关键。
  试想一下,如果一个生产,多个部门负责生产车轮、轴承、发动机等零件,如果零件各自生产出来了,但不经过组装测试,而直接等待最终组装成整车,这会是一个多么大的风险?
  为什么要集成测试?
  我们先来看看整体的意义。
  我们还是采用汽车生产这个比喻,很容易就能发现:对于一个产品整体来说,在某种程度上和某种程度上它由部分组成,为各部分创造一个内部环境,整体拥有部分不具有的属性。
  我们分别来理解上面所说的三个观点。
  整体由部分组成
  例如:我们汽车由车轮、发动机、轴承、车架、方向盘等部分组成,而每个部分可能有不同的来源(不同的部门或者不同的提供者)。
  各部分是为不同的目的而生产,比如车轮是为了行驶,发动机是为了提供动力来源,方向盘是为了方便使用者掌握方向。它们具有不同的属性,还有可能不是同时间周期创造,比如,车轮可能通过第三方购买,而第三方是早前存货。
  整体为各部分创造一个内部环境
  这个创造或割离出来的内部环境可以使各部分相互作用,相互依存,以及与外部环境的相互作用,而这个内部环境从外部是看不见的。
  例如:汽车点火按钮与发动机之间的联系,这就属于一个内部环境。
  整体拥有部分不具有的属性
  整体依赖于部分,但又与部分不同,拥有他们不具有的属性。例如:汽车可以很方便的切速形势,但单独的车轮不行。又比如,一个简单的例子是三脚架的稳定性,它不是在它的任何一个单独的腿上,而是在所有的腿一起工作时。
  由此可见,仅仅通过观察一个积分的各个部分,你可能无法分辨出你想知道的关于它的一切。这就是集成风险存在的原因。在复杂或重要的系统中,集成测试将是极其重要的,特别是在进行了更改之后。
  集成测试时的启发性关注点?
  既关注整体,也要关注部分
  “整体”由“部分”构成,但并意味着一定先存于整体之前,或者在集成的过程中没有改变。
  这意味着我们需要我们可以富有成效地思考产品的各个部分,以及它们如何与其他部分相互作用。
  既关注集成,也要关注解体
  “解体也会带来整合”,当你把某部分拿走,或者把产品拆开,你最终会得到一个新的整合,这个时候也会有风险存在。
  举个例子:集成过程中某个组件延迟集成,对整个产品造成的风险。
  要关注集成的程度和种类
  “融合不是全或无——有不同的程度和种类“。
  一个产品可能会意外地集成,因为它使用的是没有人意识到它拥有的部分。它可能是松散集成的,比如一只可以丢弃尾巴的壁虎,或者一个带有插件的浏览器,它可能是紧密集成的。
  再举个例子:当我们从一个产品中获取代码,并将其添加到另一个产品的不同位置时,我们可以边走边编辑,它可能会保留其部件的现有接口,或违反它们,或重新设计它们,或消除它们。
  特别是在集成测试时,我们往往重心在正向集成上,而忽略了解体时存在的一些风险。举例:常见来说,产品多组件安装,我们常关注安装是否成功,而容易忽略部分卸载或整体卸载时的风险。
  怎么进行集成测试?
  本节我们要说的是怎么拆分集成测试。
  从整个产品来说,我们可以做两层或更多层的集成测试。例如:我们可以对发动机这个组件设置一个集成测试,因为放大来看,发动机也是由许多小组件构成。同样的,还可以对车轮设置一个集成测试。
  而从整体来说,汽车本身也可以设置一个集成测试,因为它是一个对外交付的产品。
  有的人可能就会说,到汽车应该是系统测试了!这两者的差异主要在于你的关注点是什么:
  如果你关注的是组件间的接口是否合理可用,那么你可以把这个环节叫做集成测试;
  如果你关注的是整车的可用性和功能性,你可以叫它系统测试。
  不同的人可能会将不同的事物识别为部件、环境或产品,没关系,我们也可以自由地移动镜头,尝试不同的视角。所以说,我们集成测试设置的粒度取决于我们的关注范围,并没有一个一成不变的标准。
  因此,我们可以从产品层面划分集成测试,也可以从团队层面划分集成测试。
  产品层面划分
  假如产品P由组件C1、C2、…、C7组成,我们可以针对单个组件设置一级集成测试。
  如,ItergrationTest1、ItergrationTest2、…、ItergrationTest7,再往上,交互组件C1和C2,C3和C4、…、C7之间可以设置二级集成测试ItergrationTest12、ItergrationTest34567,直到产品级集成测试ItergrationTestP。
  团队层面划分
  根据不同团队划分集成测试。一个团队可能会负责多个组件,组件的集成测试交由团队考虑。因此,从团队层面考虑,我们可以划分为团队集成测试TeamItergrationTest1、TeamItergrationTest2……,以及项目级集成测试ProjectItergrationTest。
  最后说一说
  从上面描述我们可以看出集成测试在产品研发过程中的重要性,以及我们在设计集成测试和分层集成测试时容易忽略的一些思考点。希望能够帮助正在阅读的你有所收获~
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号