不知不觉,2022年第一季度就要过完了,作为智能驾驶领域的一枚软件测试人员,在部门做自动化有小一年时间了,从早前的懵懂无知,到现在稍稍清晰,也还在谨慎的前进着,很庆幸能够从事自动驾驶相关的测试工作,于是想着结合自己的历程精简出一些经验。
其实也谈不上经验,就算是一种经历吧,如果有更深认识的朋友,欢迎互相讨论,谢谢。
近年来电动汽车发展的如火如荼,各大企业争相进入造车领域,这使得自动驾驶有了一个很好的载体,智慧出行必然是接下来智慧生活乃至人工智能领域最为重要的发展方向之一,并且由于方兴未艾,各方力量纷纷涌入,造手机、造无人机、做房地产以及传统车企也被迫向新能源汽车转型,如:极狐阿尔法S(北汽)、极氪001(吉利)、智己(上汽/阿里)、奔驰EQS……
一款比一款吸引人眼球,甚至福特的图腾车型野马Mustang也开始电动化、智能化……大有逐鹿中原之势,下面就聊一聊智能驾驶。
像华为、百度费那么大劲研发自动驾驶功能,并不是为了单独给一家车企使用的,因为他们不造车,所以对于他们来说,最理想的情况就是这个市场上所有的品牌都用他们的技术,这样不但收入最高,研发的成本也可以分摊得很低。
而像特斯拉、小鹏等车企为代表的自研智能驾驶技术芯片的公司的优势在于后期将不存在“受制于人”这种短板(就像当前手机上的的“芯片荒”)。
今天的文章中会向大家介绍一下小编在项目中运用到的持续集成(CI)思想。
什么是CI?
首先要明确两个概念:何为持续?何为集成?持续就是每完成一个完整的部分,就向下个环节交付,发现问题马上调整,不会放大到其他部分和后面的环节。
集成就是软件个人研发的部分向软件整体部分交付,以便尽早发现个人开发部分的问题。
总而言之,对于测试团队来讲,CI是一种将被测代码频繁的集成到项目稳定分支的做法,包括构建、测试等,以保证新代码和原有代码能正确地集成在一起,此处所说的“被测代码”指的是单独分支上开发的功能,这部分代码会被测试然后集成到主线上。
一般的开发团队都拥有自己的源代码版本控制库来存储其项目(一般为git或者SVN)。稳定的分支(master)通常是作为主线分支,新功能的开发一般很少会在主线上完成。开发人员在开发自己模块的新功能时,会创建自己的分支。
当代码开发完毕,开发人员push了自己的代码到自己的branch后,会执行pull请求,此时一些基本的自动化测试会针对这个分支执行。
以本人所在的智能驾驶项目为例,自动驾驶的原理首先是通过摄像机、激光雷达、毫米波雷达、超声波等车载传感器来感知周围的环境信息(相当于人类眼睛的作用),比如车辆轮廓、地面上的车道线(道路结构认知)等信息,然后依据所获取的信息由适当的工作模型来制定相应的策略,如预测自车与其他车辆、行人等在未来一段时间内的运动状态,并进行避免碰撞路径规划。
在规划好路径之后,由控制系统控制车辆沿着期望的轨迹行驶。自动驾驶涉及到传感器环境感知,高精地图/GPS定位系统,多种数据融合,决策与规划算法运算,运算结果的电子控制与执行等过程。基于以上的多个模块,便产生了不同的分支模块,不同分支测试过后的代码就会不断集成到主干上。
为什么要做持续集成?
在软件工程里,有一个指标叫做质量成本,即项目出现质量问题的修复成本。
相信所有刚接触软件测试学习的人应该都听说过这个理论:随着时间的推移,质量成本以指数级趋势增加。所以我们做持续集成的根本目的就是为了尽可能早地发现、解决质量问题。
......
查看更多精彩内容,请点击下载:
版权声明:本文出自《51测试天地》第六十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。