作者：JACK（來源：IND4汽車人）

在OEM打交道的過程中，ECU供應商常常會碰到類似“你們的軟件質量怎麼樣？你們怎樣來保證你們的軟件是可靠的？你們都做過了什麼樣的測試？”這樣的問題。

OEM聽到的回答往往是“我們在出廠之前會做大量的軟件測試、台架驗證和實車測試，保證所有功能都得到了實現；此外我們還會進行故障注入測試，保證當我們的系統在發生任何故障（當然是已經定義的故障）的情況下都是安全的。”

如此充其量隻能說是一個初級階段的回答，也隻是部分的符合了主機廠所期望的答案：

·功能測試和故障注入測試隻是軟件測試的一部分，即使測試用例100%覆蓋了所有的功能需求和安全需求（假設有這麼兩份文件的話），不能排除軟件中存在其它的分支導緻系統出現其它非預期的結果。

講個小小的故事吧：

某車燈控制的功能需求為開關1和開關2以或邏輯實現對燈的控制，該功能需求在某曆史項目的基礎上做了一點點改動（之前的功能需求為開關1/2/3三者以或邏輯實現對燈的控制）。在整個軟件修改過程中需求開發和測試開發的工程師都注意到了這條變動，更改了相關的需求規範和測試規範，唯獨在Coding和Implementation這個環節漏掉了這項更改。

于是測試人員按照下表Test Vectors進行測試：

由于在測試過程中，給switch3的輸入一直給的是一個0信号，因此所有測試都通過了，但這個BUG卻結結實實的流出去了，功能需求的改動根本就沒有得到執行，隻要Switch3信号為1，燈就被打開了。這種貌似非常低級的錯誤看起來相當可笑，甚至覺得是筆者牽強臆造出來的，但這實際上是真真實實發生過的事實。

·雖然主機廠不要求供應商提供軟件源碼，但主機廠期望有一個量化的數字能夠反映軟件的可讀性、可維護性和可測性，以上功能測試并不能回答上述問題。部分主機廠會要求供應商提供特定工具的檢測報告（如Coverity/QAC/Polyspace靜态分析後的缺陷報告，Defensics網絡漏洞檢測報告等）。

·軟件中是否有其它潛在的BUG？測試的覆蓋率有多少（這裡指的是針對軟件代碼的覆蓋率而不是針對功能需求的覆蓋率）？

其實說白了，這些問題都指向了軟件的健壯性（魯棒性），下面從方法論上簡單地講講怎樣控制并提高軟件的開發質量即軟件的魯棒性。

（一） 流程開發

一般來說我們需要按照如下的過程進行軟件的開發工作（僅作示例，尚未考慮Model based design部分，MBD的部分會包含建模規範檢查，模型Review， MIL， SIL等測試，用到的工具如MES model Examiner， BTC等）。

而實際上在軟件質量做的比較低的公司裡，往往隻做了軟件的Coding工作和testing工作，REVIEW做的很少 ，也沒有一個公司級别的完整的Checklist和代碼編寫規範。

RviewCheckList示例：無非從軟件開發的方方面面進行啟發式的提問，幫助發現問題。

代碼編寫規範示例：

（二） 軟件靜态分析

軟件靜态分析主要是利用一些專業的分析工具（如：Coverity，QAC，Polyspace等）對軟件代碼進行檢查。主要有三方面的檢查工作：

（2.1）對MISRA C規則的符合情況

MISRA C規則是由英國的汽車工業軟件可靠性協會（The Motor Industry Software Reliability Association）組織在對大量程序員及軟件代碼進行了調查的基礎上、結合了不同的編譯器的編譯規則，所總結出的一套C語言編碼規則。該規則與程序實現的功能無關，與程序運行效率無關，甚至有些程序要符合MISRA C規則會看上去非常的“傻氣”。但這個規則是基于“大數據”總結而來，遵守該規則将使得你的程序最大限度的減少潛在的Bug，并且有很好的可維護性和在不同平台之間的移植性。

（2.2）軟件Coding質量度量

軟件分析工具能給出數十個用來度量source code質量的指标數據。一般來說，常用的是下面幾個：

（2.3）代碼安全性、缺陷檢查

軟件的缺陷如并發缺陷、算數錯誤、變量未初始化、資源洩漏，控制流缺陷，非法内存訪問，内存崩潰等諸多缺陷；安全性會涉及到優先權擴張、保密數據洩漏、數據丢失、仲裁代碼執行、整型溢出、緩沖區溢出、安全編碼缺陷等。

（三） 軟件動态測試

動态測試是指通過給軟件一定的測試用例，檢查軟件執行以後的結果與期望輸出的符合情況,可以使用的軟件有SIMULINK/TESSY/BTC等等（參考前文《小議MIL/SIL/PIL/HIL（一）》）

同時軟件會對測試用例的覆蓋度進行分析。覆蓋度的分析參數有路徑覆蓋、條件覆蓋、判定覆蓋、修訂的條件/判定覆蓋（MCDC）等。對安全級别要求比較高的産品，一般都是要求MCDC達到100%的覆蓋率（如果因程序員從可靠性角度出發特意編寫了一些冗餘的代碼導緻某些代碼不可測，則需要在測試報告中撰寫justification進行聲明）。

回到文首我們講的switch logic的例子，看看我們用表格1所用的測試用例能達到多少的覆蓋度？

上圖顯示條件覆蓋度為83%，MCDC 覆蓋度為67%，針對這個代碼測試用例是不充分的。因此基于這個統計數據，在軟件的UnitTest階段就能發現Bug，從而不至于流到客戶。

最後，讓我們來看看，按照上述流程完成了軟件的測試及質量度量以後，我們可以這麼回答OEM:

“我們的軟件首先要做單元測試，我們的軟件符合絕大部分MISRA C規則的，不符合的部分我們經過了專門的分析，沒有潛在的風險；然後我們還要做軟件圈複雜度、軟件靜态路徑數等軟件質量度量分析，代碼質量和安全性分析，不合規的軟件即使實現了軟件功能我們也要做整改；我們單元測試的MCDC覆蓋度目标是100%，保證了使用足夠多的測試用例進行測試，單元測試以後，我們還要進行台架集成測試、整車驗證和故障注入測試，所有的功能需求和安全需求都得到了100%的驗證，所以請您放心，我們的軟件是可靠放心的。如果需要，我們可以提供測試工具的分析報告。”

這樣的回答，是不是很酷？

新課程，敬請關注IND4汽車人1

《擰緊扭矩的計算與測量》

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!