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