互聯網軟件測試，能跨到車企做測試麼？
這是我之前在某個羣裏划水看到一位小夥伴提出過的問題，當時我並沒有回答，不過這個主題我倒是記在了草稿裏，因爲我自己就是這樣的經歷，留着後面有時間寫一些內容分享一下。
今天是週末，依舊是烈日炎炎，既然宅在家裏，那麼就來聊聊我從互聯網轉到車企做測試的一些體會。一是算作自己的階段小結，二也可以給有相關想法的盆友做個參考。
一、互聯網能跨到車企做測試麼
首先來回答開篇的問題：能。
常言道，隔行如隔山。的確，遠的不說，就說幾年前吧，乘用車智能化還沒興起的時候，一個互聯網軟件的外行人是很難進入到車企工作的。那會的車子普遍都是功能傳統，開發層面也不是玩的互聯網那套，自然機會不多。
但是現在不一樣，得益於最近幾年，各種造車新勢力的入場造車，把“龍捲風”也刮到了車企。新勢力的車子在宣傳上最大的賣點就是各種智能、各種大屏，車輛支持的花裏胡哨是功能也是越來越多。車輛現在都是能聯網的，與互聯網雲端服務交互的地方非常多，所以有了車聯網。許多的大屏、儀表顯示屏也是基於安卓來的，嗯？是不是有點熟悉了。是的，隨着汽車功能的形態越來越豐富多樣，隨之帶來的也是人才方向的轉變。這時候，互聯網軟件相關的人才就在車企有了用武之地，當然了，這相關的人才肯定包含了軟件測試。
不過，雖然是能進來，但是依舊不是很容易。因爲車企通常還是對於以往的工作經驗有一定的要求，比如曾經在車企工作經歷。另一方面，上面提到的車聯網測試、大屏測試也只是車企測試工作的一部分，還有許多像智能座艙、自動駕駛等更需要車端方面知識支撐的專業測試崗位，對於這種崗位，外行想進入應該是難上加難了。
二、互聯網軟件測試技能棧在車企好用麼
站在車聯網測試的角度來看，之前的技能還是好用的。
因爲對於車聯網來說，車輛就相當於一個移動設備，更多的是各種請求的入口，而服務的實現依舊是在服務器。
所以在車聯網服務裏，依舊可以看到熟悉的微服務架構、以及像kafka、es等各種中間件、還有大家熟悉的mysql等等。測試內容也涵蓋了業務測試、服務端測試、性能測試、APP小程序等移動端測試，一應俱全。既然測試的內容沒變，那麼用來提效的各種技能，比如自動化測試、腳本開發、測試平臺肯定也是少不了了。
哦對了，最重要的測試思維，是不變的。
三、在車企中你還需要哪些其他技能
雖然之前的技能在這裏可以無縫使用，但是還不夠。
既然是車企，那自然跟車離不開關係。拿我們團隊來說，雖然是主要負責服務端、移動端、以及性能相關，但是依舊有大量的測試是依賴於實車測試的。
既然上了實車測試，你就不可能只顧着自己的那一畝三分地，發現問題，抓幾個接口請求提bug就完事了，因爲涉及到車輛功能的業務一般鏈路會比較長，涉及到的端也很多。
舉個栗子：我測試APP上的遠程車控開車門的功能，發現APP頁面toast提示響應超時。那麼我如果僅憑着一個接口的請求和響應就扔掉bug裏作爲證據，開發是很難查出問題根因的。
因爲從APP到雲端後，雲端還要再到車端，車端再返回結果給雲端，再由雲端返回給APP，這其中很多問題都是出在了車端。
由於車端鏈路上一條指令還會經過好幾個ECU，所以相關鏈路上的信號報文，如果有條件，都是要抓取的。
所以，爲了滿足實車測試需求，對於車輛的電子電氣架構圖、域控制器圖的理解是必不可少的。另外，如果你對於你負責的業務模塊想要做的更好，除了熟悉APP的PRD文檔，相關車端中定義了信號交互的SSTS文檔也是要了解的。軟的理解了，還得學會相關車載測試工具的使用，比如各種CAN工具。
總之一句話，你可以不會，但是你不能一直不會。如何快速學習，這也是對於一個職場人的能力考驗。
當然了，上述也只是基於我個人工作範圍，所涉及到的技能拓展，僅供參考，get到思路就行。
四、車企與互聯網企業的異同
你想問我車企與互聯網有什麼相同和不同之處？
先說相同之處吧，我覺得互聯網企業裏存在的問題，在這裏也會有。比如，流程不規範（這個可能只適用於新公司），項目管理混亂，不懂的人瞎指揮等等。
不同之處給我最大的感受，還是來自於團隊合作吧，起碼從目前我負責的業務範疇裏，沒有一個業務是能從頭到尾順暢的進行下去的。
我大概歸納了三點：
- 一是因爲鏈路很長，涉及到的團隊多，自然會存在磨合、推諉之類的事情。
- 二是鏈路上的許多人來自其他傳統車企，工作和思維方式和我這種常年在互聯網公司的人存在偏差。
- 三是許多功能也是由外部供應商提供的，所以又增加了溝通和處理成本。
所以，在這種情況下，測試要做的事情就不能只是關注業務功能的本身了，還需要更好的把控項目進度、存在的風險。分析出來的問題點，在自己的能力範圍內如何更好地推動解決。
或許你會問，我就是個測試，咋啥都幹？是的，這就涉及到另一個我想聊的話題，關於測試是否要做本職以外的事情，今天就不展開了。
ok，今天的分享就都到這裏了，以上都是我一家之言，僅供參考，也歡迎小夥伴們一起談談相關感受，我們下期再見。