軟體測試裁員後進入硬體行業做測試的過程和小感觸

我是個很囉嗦的人，內容比較多還是大致區分一下內容

我莽去硬體公司測試了----
“你不能只關注程式，程式必須燒錄在主機板之後才能執行”。。“你應該觀察板子這邊幾個風扇控制等等控制訊號的輸出的波形是否正確”
儲能 BMS 的 C 研發在我學習瞭解 BMS 測試時經常這麼說。公司劃分了硬體設計部門和軟體部門，BMS 是一個整體，脫離了硬體的程式就是所謂軟體，而我是研發部門目前第一個招聘入職的測試人員。
我瞭解嵌入式包括硬體相關和傳統軟體測試（我並沒有測試過手機平臺，都是各種 java 開發 B/S 架構的專案）差異很大，在最近一次裁員之後考慮到常州本地的 軟體服務市場可能並不好做了。毅然投入硬體廠商，因為我覺得無論是什麼測試，哪怕物件不是軟體其本質目標都是一致的，都是質量控制的一個環節。而公司目前情況特殊，畢竟如果一個公司告訴你我們當前測試崗你是第一個，其實有點經驗的工作人員會覺得這是天崩開局，而我正好不在乎。
我們這邊的研發團隊成員並不多，甚至沒有產品經理（硬體迭代比較少，特別是嵌入式程式經過一段時間迭代之後功能是很穩定的）。當研發經理希望我先了解 BMS 功能（一塊主機板，對的一塊板子）我挺蒙的。不管懂不懂把產品相關的文件能看的都看了，關鍵的測試方式，工作方式相關的內容其實還是需要相關研發人員手把手帶著做一遍的，這裡並沒有什麼慚愧的，測試工作本身就是從研發負責自測延申後獨立出來的。

最開始艱難的適應入手期-----
其實針對 BMS 主機板的測試有很多環節已經在其他部門測試過了。硬體團隊會對元件進行驗證，而生產部門已經有研發大佬搭建了整套的自動化測試 (UI 工具) 進行快速功能驗證。測試臺模擬了主機板所需的所有外部介面和上下游通訊，透過 PC 端的 UI 測試工具模擬上游程式對 BMS 進行主要功能的快速驗證。生產部的同事將主機板接入之後十幾秒就能完成一個主機板的基本功能驗證。（我尋思還要我幹嘛，UI 自動化工具都直接搞了）。
當然，那位研發大佬因為身兼數職 (老闆覺得好用所以使勁用所以壓力其實挺大）所以對於初入崗位啥都要問的測試人員來說脾氣並不好。對於新入行的測試人員來說需要的學習過程其實是公司的某種成本。我自然應該有自知之明，在學習和實踐過程輸出更多的人性化便於閱讀的-h 的操作說明文件、過程文件。
其實單純一個 BMS 相關嵌入式的學習阻塞頗多，在知道了一個產品應有的測試姿勢，也就等於找到了入口。那麼具體要測試什麼功能，有哪些功能以及如何去測試就成了問題。研發部推出了一個研發來負責編寫【功能說明文件】，我確實從中瞭解了功能骨架，但是文字描述太寬泛，需要深入到可以產出測試步驟始終缺少了一部分內容，而這部分內容在我硬著頭皮推進的時候還遇到了幾個研發踢皮球的情況。
研發人員提供的描述大致：當狀態機收到命令進入充電模式時，步驟 XX 進行引數校驗。
測試人員不知道進行了什麼引數，（實際測試在這裡不透過出現異常），於是研發進一步翻程式碼進行轉譯。引數校驗步驟內有 9 個校驗動作依次進行
然後測試人員不知道這些校驗的引數如何得到，又應該是多少才可以透過。
到這裡研發開始扯皮（似乎閱讀有難度，希望你去問其他研發，其他研發又繼續轉）。
最後當然解決了，因為我跟研發經理申請了原始碼許可權。以我七八年前二級 C 的了色水平嘗試直接閱讀理解，結合開發設計手冊還真能定位到對應模組最終完全解決了這個問題。
有點有意思的是，傳統的 java 上我一直認為研發在有程式碼許可權的情況不存在無法解答的程式碼邏輯。在嵌入式團隊碰到這種情況其實我有點兒意外，因為 java 開發會出現踢皮球的情況多數是因為缺陷難以定位，所以推給其他關聯模組嘗試想讓別人自證無誤先。結果在程式碼細節問答環節竟然能遇到需要自己繞一圈自己看程式碼的情況。
當然，上面繞了一大圈的解決的問題。只不過是在功能測試的環節完成了一個小小測試案例的測試資料準備環節。相當於為了一條測試案例的 1 個步驟的正常打通投入了數個人天。

入職階段小結-----
此前說到，BMS 也就是電池管理系統本身是一個整體，我負責的範圍主要是燒錄在控制板的程式。這個整體在產品的生產、驗收階段公司分別也有對應的冒煙和整機除錯測試工作來進行一定程度的驗證。但是疏漏就是在運維階段的系統更新會繞過上述質量流程而引發大問題（我初入公司就碰到了某個專案釋出的更新缺陷導致所有 BMS 無法遠端升級，然後全跑去專案現場頂著打太陽爬梯子擰螺絲然後刷修復程式）深刻體會到硬體相關缺陷撇開責任不談哪怕不影響核心那要修復的代價也很爆炸。所以 BMS 程式碼本身在內部需要補上測試驗證環節是必要的，而且就我的測試職責範圍不在硬體整體而是縮小到燒錄了程式的主機板也減輕了我的壓力（畢竟硬體是真不懂吶），我之前閱讀原始碼解讀的校驗邏輯等等，補充的其實是 BMS 下游被控子系統需要配合。對傳統軟體理解就是需要寫一個介面樁，這個介面樁需要一些處理邏輯。我在這期間文件化整理了 BMS 作為一個黑盒測試時，它的上游、下游對主要功能的配合協作關係，並編寫了一個小程式可以完全模擬下游系統響應。

除錯部門----
小公司的軟體開發也好測試也好大概都跑不掉和運維實施團隊一家親，然後就是出差啊之類幹一些自己討厭的事情。只是我目前業務瞭解太少，菜的沒有能力支撐罷了。公司現有一個除錯部門，他們的責任是對整個產品進行系統驗證，通常有一份驗證清單需要按次序執行，也是某種測試流程，特點是驗證內容十分固定無非是需準備工作各有不同。這個除錯工作是出廠前的整機功能驗證，其實類似於軟體系統釋出之前的系統測試或者驗收測試。只是我目前還沒有能力負責這類工作而已，我覺得作為一個測試人員從質量保證的角度考慮，這個產品相關的所有測試相關工作我應該是都深入瞭解，明白他們是如何保障整體產品質量以及是否存在可能的疏漏。只不過初來乍到屁都不懂還是聽從研發經理安排去做事情就好（畢竟狹義上的軟體測試服務於研發工作）。

嵌入式相關的一些小認知----
回憶起來有一位測試同事曾經在上海做過嵌入式測試的描述 “就是一堆指令碼挨個執行就完了”，我其實反覆在加深嵌入式的測試很有在完成構建之後因為產品本身變化不大，它的測試其實一直在進行某種主線迴歸測試的認知。我那位曾經做過嵌入式測試的同學會這麼說應該是因為那個公司測試的方案和產品等等都已經固化下來，對應的測試人員只是在框架內維護自動化指令碼，執行測試指令碼。自動化測試在 JAVA 開發的 B/S 架構產品也經常接觸，但是總覺得實用性不強，而在嵌入式這塊反而是很實在的東西，我自然也更願意去主動尋找好的自動化方案來減輕我的測試工作。
當然了，因為 BMS 其實涉及很多模擬訊號輸入。想要做全面覆蓋測試依賴各種模擬裝置（都得買或者討巧去湊合）其實並不容易。反而都是需要專項測試的內容。所謂使用自動化輕鬆快速驗證的內容有其侷限性。

後續-----
真真的天崩開局是要測試的產品別說沒幾個文件，連原始碼都沒幾個註釋。之前的 BMS 原始碼基本上每一行都有註釋啊！