5年经验测试人浅尝新领域,持续集成在智能驾驶项目中的应用

不知不觉,2022年第一季度就过完了,作为智能驾驶领域的一枚软件测试人员,在部门做自动化有小一年时间了,从早前的懵懂无知,到现在稍稍清晰,也还在谨慎的前进着,很庆幸能够从事自动驾驶相关的测试工作,于是想着结合自己的历程精简出一些经验。

其实也谈不上经验,就算是一种经历吧,如果有更深认识的朋友,欢迎互相讨论,谢谢。

近年来电动汽车发展的如火如荼,各大企业争相进入造车领域,这使得自动驾驶有了一个很好的载体,智慧出行必然是接下来智慧生活乃至人工智能领域最为重要的发展方向之一,并且由于方兴未艾,各方力量纷纷涌入,造手机、造无人机、做房地产以及传统车企也被迫向新能源汽车转型,如:极狐阿尔法S(北汽)、极氪001(吉利)、智己(上汽/阿里)、奔驰EQS……

一款比一款吸引人眼球,甚至福特的图腾车型野马Mustang也开始电动化、智能化……大有逐鹿中原之势,下面就聊一聊智能驾驶。

目前市面上做智能驾驶的主要部分为两大类,一类是以华为、百度、大疆、滴滴等为代表的智能驾驶技术供应商,一类是以特斯拉、小鹏等车企为代表的自研智能驾驶技术。

像华为、百度费那么大劲研发自动驾驶功能,并不是为了单独给一家车企使用的,因为他们不造车,所以对于他们来说,最理想的情况就是这个市场上所有的品牌都用他们的技术,这样不但收入最高,研发的成本也可以分摊得很低。

而像特斯拉、小鹏等车企为代表的自研智能驾驶技术芯片的公司的优势在于后期将不存在“受制于人”这种短板(就像当前手机上的的“芯片荒”)。

今天的文章中会向大家介绍一下作者在项目中运用到的持续集成(CI)思想。

什么是CI?

首先要明确两个概念:何为持续?何为集成?持续就是每完成一个完整的部分,就向下个环节交付,发现问题马上调整,不会放大到其他部分和后面的环节。

集成就是软件个人研发的部分向软件整体部分交付,以便尽早发现个人开发部分的问题。

总而言之,对于测试团队来讲,CI是一种将被测代码频繁的集成到项目稳定分支的做法,包括构建、测试等,以保证新代码和原有代码能正确地集成在一起,此处所说的“被测代码”指的是单独分支上开发的功能,这部分代码会被测试然后集成到主线上。

一般的开发团队都拥有自己的源代码版本控制库来存储其项目(一般为git或者SVN)。稳定的分支(master)通常是作为主线分支,新功能的开发一般很少会在主线上完成。开发人员在开发自己模块的新功能时,会创建自己的分支。

当代码开发完毕,开发人员push了自己的代码到自己的branch后,会执行pull请求,此时一些基本的自动化测试会针对这个分支执行。

以本人所在的智能驾驶项目为例,自动驾驶的原理首先是通过摄像机、激光雷达、毫米波雷达、超声波等车载传感器来感知周围的环境信息(相当于人类眼睛的作用),比如车辆轮廓、地面上的车道线(道路结构认知)等信息,然后依据所获取的信息由适当的工作模型来制定相应的策略,如预测自车与其他车辆、行人等在未来一段时间内的运动状态,并进行避免碰撞路径规划。

在规划好路径之后,由控制系统控制车辆沿着期望的轨迹行驶。自动驾驶涉及到传感器环境感知,高精地图/GPS定位系统,多种数据融合,决策与规划算法运算,运算结果的电子控制与执行等过程。基于以上的多个模块,便产生了不同的分支模块,不同分支测试过后的代码就会不断集成到主干上。

为什么要做持续集成?

在软件工程里,有一个指标叫做质量成本,即项目出现质量问题的修复成本。

相信所有刚接触软件测试学习的人应该都听说过这个理论:随着时间的推移,质量成本以指数级趋势增加。所以我们做持续集成的根本目的就是为了尽可能早地发现、解决质量问题。

我所在的项目如何做持续集成?

持续集成是为了让整个项目运转更加高效,所以必须保证工程的构建和测试运行效率足够高。

首先是工程的构建,相信很多人应该听说过Jenkins,Jenkins在主要的功能就是版本的构建,因为项目中每个分支每天会在凌晨进行版本构建并触发冒烟测试任务,所以小编运用Jenkins的情况较少,只是在手动构建版本中偶尔使用过。

由于目前掌握的不多,也在慢慢的学习中,后续或许会专门出一篇进行实例讲解,感兴趣的读者也可以了解一下这方面的知识,毕竟Jenkins在业内也是一个很常用工具,在此只讲一下每日构建流水线的基本流程:拉取代码——>编译——>构建——>代码扫描——>打包部署——>自动化测试——>测试报告——邮件发送。

其次就是精准的测试,为了保证工程的高效运行,采用的是冒烟测试,如果每次只跑与这次代码相关的测试用例是最好不过的,不过这种做法很难实现,因为相关性不好评估,所以通常是筛选出N条测试用例(通常为三四百,具体根据版本特性进行增删)。

每次持续集成就定期去跑全量的这些测试用例,一般会在凌晨对指定的分支调度冒烟测试用例集,第二天来公司查看测试报告就行了。

这样每天冒烟测试都能保证基本功能可以被验证,对于智能驾驶,这部分用例主要就是一些诸如红绿灯、环岛、并线等不同的道路场景。

我所在的ADS(Autonomous Driving Solution)自动驾驶解决方案是由华为自研的自动驾驶系统,测试产品是MDC(Mobile Data Center),作为一种移动数据中心,可以把它看成计算机中的CPU。

每天的基本任务就是上文所说的daily版本冒烟测试结果分析,保证各分支版本无阻塞问题以及业务问题的定位跟踪等。

前文有提到每天凌晨会自动构建daily版本并启动冒烟测试任务,当然也可以使用postman来手动调度任务,请求体中包含所需创建的任务名称、目标版本号、版本构建(buid)号、自动化用例集名称以及自动化脚本所需的环境集群等,post请求发送成功后便可在任务管理平台上查看当前所创建的自动化任务。

自动化用例结果的分析及问题修复

最后就是测试用例结果的分析,如果有问题,及时推进修复,这也是整个过程中最主要的工作内容。

自动化用例其实就是拿实际路测的数据包跑MDC最新的感知等模块,完成体验分析,如碰撞风险/S型轨迹等。

任务执行过程中每跑完一条脚本都会将测试结果保存在本地工作站中,通过Linux命令去查看失败用例相关信息,如用例名称、失败原因、数据连接等。

根据失败原因以及数据链接中的日志等信息去定位具体导致失败的原因,将失败用例结果反馈给开发推动解决,问题解决后会由分支同步推送主干,并验证主干是否解决。

Ps:可能在很多人的认知里,自动化脚本是由测试人员编写的,其实不然,本项目就是个例外,自动化脚本是由开发用Python写的。

脚本内容基本相同,最大的区别就是存放的数据片段不同,每条用例都是由test_script.py格式的脚本及config.json配置文件组成,测试脚本中主要包含以下内容:

①环境准备

②把包copy到相应目录

③订阅输出的topic

④播包

⑤结果判断

json格式的配置文件里存放的是需要播的包,如数据片段名称等内容,测试脚本基于Pytest框架(关于Python自带的Unitest框架和第三方Pytest框架区别简单的做了一个总结放在文末附表中,各位可以对照参考)。

============================= 强化技术 ==========================

点击下面卡片关注本博主个人公众号可以获取更多技术干货,包括自动化测试学习资料,知识体系大纲,40篇面试经验文章和项目案例源码、笔记等等资料。具体详细内容可自行查看哦!

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值