曲延羽 鄧琬云 熊鐸程 林智桂 冉毅德

關鍵詞：軟件測試;軟件開發(fā);邏輯驗證

0 引言

隨著智能駕駛技術的快速發(fā)展，目前智能駕駛輔助系統(tǒng)產(chǎn)品已占了汽車市場的一席之地并快速迭代[1]。為了保證智能駕駛輔助系統(tǒng)軟件的質量及安全性能，相應需求的軟件測試成為軟件開發(fā)過程中必不可少的一部分[2]。

不同平臺開發(fā)的軟件代碼，測試模式也不盡相同。目前，常見的開發(fā)模式是基于Matlab 數(shù)字軟件平臺搭建Simulink模型開發(fā)，或基于Microsoft Visual Studio（VS）編譯環(huán)境使用C++ 語言進行編程開發(fā)。對于Simulink 開發(fā)的模型，可以在Matlab 平臺上完成單元模塊的部分測試和仿真驗證[3] ;但對于C++ 語言編程開發(fā)的軟件，需要通過借助不同工具進行測試和仿真驗證。

智能駕駛輔助系統(tǒng)軟件代碼具有嚴密的邏輯性，需要完善的測試手段對各源代碼模塊進行充分驗證，最大限度地提高軟件性能。單一的單元測試不能滿足對控制模塊內(nèi)部邏輯結構的完整測試。而集成測試需采用黑盒模型且過程較長，這種驗證過程耗費大量的時間，會降低開發(fā)與測試效率。

因此，針對C++ 語言編程的智能駕駛輔助系統(tǒng)軟件，本文提出了一種基于VS 編譯環(huán)境，以模塊作為測試單元，對模塊邏輯功能進行測試的方法。本方法結合白盒測試與黑盒測試的方式對模塊的算法進行測試與驗證，快速精準定位到源代碼中的問題代碼和邏輯漏洞，提高了代碼開發(fā)與測試效率。

1 智能駕駛軟件測試系統(tǒng)設計原理及架構

1.1 智能駕駛軟件測試系統(tǒng)設計原理

智能駕駛軟件測試系統(tǒng)的設計原理，是使用數(shù)據(jù)文件或實車數(shù)據(jù)的輸入信號，形成輸入?yún)?shù)，在測試驅動程序中建立讀取測試數(shù)據(jù)與選取測試模塊的接口。再通過確定讀取的測試數(shù)據(jù)及選取的測試模塊，將相應的輸入?yún)?shù)傳入測試驅動程序，測試驅動程序調用相應的待測模塊工作函數(shù)執(zhí)行測試程序。待執(zhí)行測試程序結束后，將測試結果輸出，并在測試結果模塊中，將預期輸出結果與實際輸出結果進行比較。之后，系統(tǒng)對不符合預期結果的部分進行標記，提示開發(fā)人員對不符合預期結果的部分進行檢查或修正（圖1）。

1.2 智能駕駛軟件測試系統(tǒng)設計架構

智能駕駛軟件測試系統(tǒng)架構主要由測試數(shù)據(jù)存儲、測試執(zhí)行程序和輸出結果處理三大功能模塊組成（圖2）。待測模塊代表具有相對獨立且邏輯結構完整的源代碼模塊，其中小模塊1、小模塊2 等代表具有不同邏輯判斷的模塊。整個測試執(zhí)行過程維持待測模塊源代碼“黑盒”狀態(tài)，確保待測模塊與測試執(zhí)行程序模塊間的相對獨立性。這樣既保證了測試的可執(zhí)行性，又保證源代碼的安全性。智能駕駛軟件測試系統(tǒng)的主要功能模塊如下。

1.2.1 測試數(shù)據(jù)存儲模塊

測試數(shù)據(jù)存儲模塊存儲讀取的輸入?yún)?shù)與預期結果變量數(shù)據(jù)信息，可接收實車采集數(shù)據(jù)與模擬數(shù)據(jù)兩種數(shù)據(jù)模式。這些數(shù)據(jù)傳輸?shù)綔y試執(zhí)行程序模塊，作為模擬運行的輸入?yún)?shù)。

1.2.2 測試執(zhí)行程序模塊

測試執(zhí)行程序調用待測模塊工作函數(shù)，對輸入信號進行循環(huán)讀取執(zhí)行，模擬多幀連續(xù)運行模式，再將每次讀取運行后的輸出結果變量傳輸給結果處理模塊。除了待測模塊固定的測試值外，可以依據(jù)功能需求將模塊類成員變量的測試值同時輸出。整個測試執(zhí)行過程不涉及開發(fā)模塊內(nèi)部源代碼的改動，既保證測試的可執(zhí)行性，又保證源代碼的安全性。

1.2.3 數(shù)據(jù)結果處理模塊

測試得到的運算輸出變量（測試值）逐幀存儲到結果處理模塊，并與測試數(shù)據(jù)存儲模塊的預期輸出變量（期望值）進行逐一比對，將測試值與期望值的比對結果作為源代碼測試驗證的最終結果。

2 智能駕駛軟件測試系統(tǒng)策略

智能駕駛軟件測試系統(tǒng)策略如下：編寫測試用例數(shù)據(jù)文件，讀取測試用例數(shù)據(jù)文件的輸入信號，對待測試模塊進行測試。測試系統(tǒng)根據(jù)每幀的模塊輸出信號、中間值信號與數(shù)據(jù)文件的期望值之間產(chǎn)生的差異，對當前幀的計時器信號進行標記。

測試人員通過計時器信號的標記進行定位查找，找出導致測試失敗的輸出信號與中間值信號。然后通過觀察測試值與期望值之間的差異，再梳理待測模塊中包含導致測試時報的輸出信號與中間值信號的部分代碼邏輯，縮小搜索代碼邏輯漏洞的范圍，快速定位待測試模塊問題，提高更正代碼的效率（圖3）。

3 智能駕駛軟件測試系統(tǒng)的應用

本次測試采用符合LKA 按鍵邏輯功能規(guī)范的實車測試數(shù)據(jù)真實信號，作為測試數(shù)據(jù)文件的輸入信號與期望值信號。LKA按鍵是是車道保持功能的物理開關被按下時，從CAN 總線傳過來的信號。通過選擇測試用例，將實車測試數(shù)據(jù)文件導入測試系統(tǒng)中，點擊開始測試，則對LKA 按鍵邏輯模塊進行邏輯測試。

整個測試結果如圖4 所示，其中，紅色點線為輸入數(shù)據(jù)（LKA按鍵狀態(tài)），藍色點線與黑色點線，分別表示LKA 功能狀態(tài)是否激活的預期輸出變量信號和測試輸出變量信號。除此之外，在測試結束后，可輸出數(shù)據(jù)測試報告（圖5）。

圖5 中標出了LKA 按鍵幀數(shù)及功能狀態(tài)在2.00 ～ 2.26 s 的相關數(shù)據(jù)?？梢钥闯觯?.00 s 時，LKA 開關按鍵被按下，持續(xù)時間為0.14 s，大于0.10 s（0.10 s 為功能開啟的時間范圍最小值），LKA 功能狀態(tài)信號從0 跳變至1，LKA 功能狀態(tài)激活;3.52 s 時，LKA 開關按鍵被按下的持續(xù)時間為2.14 s，小于3.00 s（3.00 s 為功能開啟的時間范圍最大值），LKA 功能狀態(tài)信號從1 跳變至0，LKA 功能狀態(tài)關閉;7.62 ～ 8.04 s 時，LKA 開關按鍵按下，持續(xù)時間為0.42 s，因此，隨著按鍵抬起，LKA 功能狀態(tài)激活;9.44 s 時，LKA 開關按鍵被按下，12.94 s 時LKA 開關按鍵抬起，持續(xù)時間為3.50 s（大于3.00 s），LKA 功能不會被關閉，仍保持激活狀態(tài)。

從圖4 可以看出，在2.14 s、5.68 s 和8.04 s，LKA 功能狀態(tài)信號期望值與測試值的信號跳變狀態(tài)完全一致，表明此測試系統(tǒng)對LKA 按鍵模塊邏輯條件的測試結果符合測試用例中提出的預期結果，模塊代碼邏輯符合預期設計，測試成功。另外，通過利用實車采集信號作為輸入信號進行模塊邏輯測試，還可應用于測試用例外其他多種真實輸入場景模塊代碼的測試驗證手段。

本測試系統(tǒng)應用場景不僅應用于實車信號，通過智能駕駛軟件測試系統(tǒng)驗證修改軟件算法，縮減集成及上車驗證時間;還可以更多應用于符合功能規(guī)范設計的測試用例信號，在軟件集成前期使用此方法來驗證軟件算法的邏輯性是否符合功能規(guī)范。

4 結束語

綜上所述，對于C++ 語言編程開發(fā)的智能駕駛系統(tǒng)軟件測試方法，具有同一編譯環(huán)境不需要移植源代碼的優(yōu)勢，可使部分模塊測試參與到代碼開發(fā)過程中，實現(xiàn)源代碼的部分自測自驗，提高開發(fā)效率。通過與智能駕駛軟件測試系統(tǒng)的設計用例與實車測試數(shù)據(jù)對比說明，此測試系統(tǒng)能夠有效自檢模塊源代碼的邏輯結構，可以作為輔助開發(fā)人員更高效開發(fā)源代碼的手段。通過每幀預期結果與運算結果對應比較，可以實現(xiàn)智能駕駛軟件算法的驗證，解決查找源代碼問題時效慢的問題。