互联网软件测试,能跨到车企做测试么?
这是我之前在某个群里划水看到一位小伙伴提出过的问题,当时我并没有回答,不过这个主题我倒是记在了草稿里,因为我自己就是这样的经历,留着后面有时间写一些内容分享一下。
今天是周末,依旧是烈日炎炎,既然宅在家里,那么就来聊聊我从互联网转到车企做测试的一些体会。一是算作自己的阶段小结,二也可以给有相关想法的盆友做个参考。
一、互联网能跨到车企做测试么
首先来回答开篇的问题:能。
常言道,隔行如隔山。的确,远的不说,就说几年前吧,乘用车智能化还没兴起的时候,一个互联网软件的外行人是很难进入到车企工作的。那会的车子普遍都是功能传统,开发层面也不是玩的互联网那套,自然机会不多。
但是现在不一样,得益于最近几年,各种造车新势力的入场造车,把“龙卷风”也刮到了车企。新势力的车子在宣传上最大的卖点就是各种智能、各种大屏,车辆支持的花里胡哨是功能也是越来越多。车辆现在都是能联网的,与互联网云端服务交互的地方非常多,所以有了车联网。许多的大屏、仪表显示屏也是基于安卓来的,嗯?是不是有点熟悉了。是的,随着汽车功能的形态越来越丰富多样,随之带来的也是人才方向的转变。这时候,互联网软件相关的人才就在车企有了用武之地,当然了,这相关的人才肯定包含了软件测试。
不过,虽然是能进来,但是依旧不是很容易。因为车企通常还是对于以往的工作经验有一定的要求,比如曾经在车企工作经历。另一方面,上面提到的车联网测试、大屏测试也只是车企测试工作的一部分,还有许多像智能座舱、自动驾驶等更需要车端方面知识支撑的专业测试岗位,对于这种岗位,外行想进入应该是难上加难了。
二、互联网软件测试技能栈在车企好用么
站在车联网测试的角度来看,之前的技能还是好用的。
因为对于车联网来说,车辆就相当于一个移动设备,更多的是各种请求的入口,而服务的实现依旧是在服务器。
所以在车联网服务里,依旧可以看到熟悉的微服务架构、以及像kafka、es等各种中间件、还有大家熟悉的mysql等等。测试内容也涵盖了业务测试、服务端测试、性能测试、APP小程序等移动端测试,一应俱全。既然测试的内容没变,那么用来提效的各种技能,比如自动化测试、脚本开发、测试平台肯定也是少不了了。
哦对了,最重要的测试思维,是不变的。
三、在车企中你还需要哪些其他技能
虽然之前的技能在这里可以无缝使用,但是还不够。
既然是车企,那自然跟车离不开关系。拿我们团队来说,虽然是主要负责服务端、移动端、以及性能相关,但是依旧有大量的测试是依赖于实车测试的。
既然上了实车测试,你就不可能只顾着自己的那一亩三分地,发现问题,抓几个接口请求提bug就完事了,因为涉及到车辆功能的业务一般链路会比较长,涉及到的端也很多。
举个栗子:我测试APP上的远程车控开车门的功能,发现APP页面toast提示响应超时。那么我如果仅凭着一个接口的请求和响应就扔掉bug里作为证据,开发是很难查出问题根因的。
因为从APP到云端后,云端还要再到车端,车端再返回结果给云端,再由云端返回给APP,这其中很多问题都是出在了车端。
由于车端链路上一条指令还会经过好几个ECU,所以相关链路上的信号报文,如果有条件,都是要抓取的。
所以,为了满足实车测试需求,对于车辆的电子电气架构图、域控制器图的理解是必不可少的。另外,如果你对于你负责的业务模块想要做的更好,除了熟悉APP的PRD文档,相关车端中定义了信号交互的SSTS文档也是要了解的。软的理解了,还得学会相关车载测试工具的使用,比如各种CAN工具。
总之一句话,你可以不会,但是你不能一直不会。如何快速学习,这也是对于一个职场人的能力考验。
当然了,上述也只是基于我个人工作范围,所涉及到的技能拓展,仅供参考,get到思路就行。
四、车企与互联网企业的异同
你想问我车企与互联网有什么相同和不同之处?
先说相同之处吧,我觉得互联网企业里存在的问题,在这里也会有。比如,流程不规范(这个可能只适用于新公司),项目管理混乱,不懂的人瞎指挥等等。
不同之处给我最大的感受,还是来自于团队合作吧,起码从目前我负责的业务范畴里,没有一个业务是能从头到尾顺畅的进行下去的。
我大概归纳了三点:
- 一是因为链路很长,涉及到的团队多,自然会存在磨合、推诿之类的事情。
- 二是链路上的许多人来自其他传统车企,工作和思维方式和我这种常年在互联网公司的人存在偏差。
- 三是许多功能也是由外部供应商提供的,所以又增加了沟通和处理成本。
所以,在这种情况下,测试要做的事情就不能只是关注业务功能的本身了,还需要更好的把控项目进度、存在的风险。分析出来的问题点,在自己的能力范围内如何更好地推动解决。
或许你会问,我就是个测试,咋啥都干?是的,这就涉及到另一个我想聊的话题,关于测试是否要做本职以外的事情,今天就不展开了。
ok,今天的分享就都到这里了,以上都是我一家之言,仅供参考,也欢迎小伙伴们一起谈谈相关感受,我们下期再见。