在汽車行業的嵌入式軟體開發怎麼確保很低的bug發生率？

01-08

本人現在主要從事量產ECU軟體的測試和維護工作，正常的開發流程是按照具體功能變更的點按照V模型做測試，因為我們現在主要做功能增加和變更，實際代碼量很小。我的問題是在ECU軟體開發從0到1的階段，或者說代碼量比較大的階段是如何做測試的呢？同時國內現在很多公司開始做新能源汽車他們是怎麼做測試的呢？會按照流程嚴格執行嗎？

嵌入式軟體的質量保證，有人說是需求保證，有人說是測試保證。兩者都有不同的應用場景。

嵌入式軟體又分為應用層與底層。應用層的質量保證偏向需求保證，底層的質量保證偏向測試保證。

對於質量保證，每個公司有不同的流程，但是同時有一些公共的標準，ISO2626-雖然說是安全，但是也是對質量的一種保證。過程式控制制ISO15504,還有大家所熟悉的V模型！

那要先來說道說道bug產生的原因。

原因1. 客戶/系統/軟體需求不明確，不完整，軟體工程師對系統需求/軟體需求的理解不到位或者有誤解，造成軟體設計錯誤；

原因2.需求和設計變更引起的bug。變更影響分析不全面不到位，變更流程有缺陷，變更過程管理不到位，造成軟體變更錯誤或者遺漏；

原因3.軟體工程師自身能力所限，建模/編碼風格迥異，測試驗證方法不規範，工程經驗欠缺，例如對於時序的理解，資源的分配，任務的調度，不充分，造成軟體設計bug；

原因4.軟體硬體介面規範定義不清晰，軟硬體工程師交流溝通機制不完善，硬體設計對於軟體的需求未能正確充分的傳達給軟體工程師，造成軟體設計bug；

原因5.軟體開發和測試工具自身bug帶來的軟體設計bug.

知道了原因，就可以對症下藥.

一方面從流程入手，一方面從工程師自身能力入手。

我們只談流程。談談個人對流程的理解，我把流程廣義化了，即：

流程=過程流+工具鏈+方法論。

過程流就是定義清晰每個開發活動的輸入和輸出，責任人，過程活動的要求。

工具鏈包括管理工具鏈，開發工具鏈和測試工具鏈。

方法論指的是活動的模板和指南。

1. 運用專業需求管理工具，管理客戶需求、系統需求、系統架構設計、軟體需求、軟體架構設計、軟體詳細設計和單元實現整個開發過程，需求與設計的雙向傳遞，將客戶需求層層傳遞到設計層面。

2.運用專業的方法論，為保證需求的正確性完整性可實現性可驗證性，需要運用專業的需求分析方法例如use case，IPO等；為保證架構設計的可讀性、易理解、合適的顆粒度、介面的複雜程度等要求，運用半正式化語言來描述；詳細設計和單元實現，為避免手工代碼的弊端，可以採用建模和自動代碼生成。總之無論開發還是測試，都有一系列的專業方法論來避免系統性bug。

3.模塊化開發和復用，持續集成，這個不用多解釋。我不是干軟體的，也解釋不清

4.故障矩陣，軟硬體介面規範的重視。作為嵌入式開發中兩份最為重要的交互文檔，必須制定模板和指南來指導這兩份文檔的制定。

5.全面的測試，針對代碼的靜態動態測試，針對模型的MIL SIL PIL測試，針對架構的集成測試，針對需求的HIL測試，通過自底而上的系列化測試，在不同層面儘可能探測出軟體bug。

6.開發工具的使用。不要相信人，人總有犯困的時候。燒錢買工具，建立開發和測試工具鏈。當然還要買置信度高的軟體。

7.支持過程的完善，配置管理，變更管理，文檔管理，評審，等等，這一系列支持類流程，都要持續的改進和完善。

以上，都是ASPICE的要求吧

如果是新入汽車行業的公司，要建立第一個汽車電控產品的軟體基礎，必須按照流程開發，才能進入一流車企的供應商體系，車企才敢相信你讓你供貨。一旦建立了第一個產品軟體基礎，後續就是在現有架構上優化，刪減增加模塊，集成，後面會輕鬆很多。萬事開頭難，古人誠不欺我。

嚴格地按照V過程進行分層次的需求輸入，設計和驗證的閉環。

具體V過程，請自行百度或GOOGLE