羅峰 徐金鵬

（同濟大學，上海 201804）

主題詞：單元測試 時鐘同步協(xié)議 開源單元測試框架 軟件質量

1 前言

隨著微控制器技術的發(fā)展，軟件開發(fā)在車載應用中的重要性逐漸提高[1]。基于控制器的功能和安全等級等要求，不同控制器的軟件規(guī)模、開發(fā)難度和測試方法存在較大差異。傳統(tǒng)嵌入式軟件質量受開發(fā)人員水平制約，其可靠性難以驗證。同時，受開發(fā)人員的流動性影響，軟件在交接過程中可能引入更多漏洞，從而不能滿足要求或有缺陷[2]。為了解決以上問題，汽車開放系統(tǒng)架構（AUTOmotive Open System Architecture，AUTO?SAR）[3]組織提出了開放的軟件架構，汽車工業(yè)軟件可靠性聯(lián)會（the Motor Industry Software Reliability Associa?tion，MIRSA）和HIS（Hersteller Initiative Software）等組織提出的規(guī)范提供了更嚴格的代碼檢查規(guī)則。開發(fā)者可以采用商用軟件進行代碼生成、檢查和測試，從而減少或避免開發(fā)過程中軟件帶來的問題。

商用軟件既帶來了開發(fā)上的優(yōu)勢，也帶來了成本上的增加，因此難以適用于按鍵、開關等低成本控制器。由于整車廠的設計要求也可能存在變化，因此部分零部件制造商依然采用傳統(tǒng)嵌入式軟件開發(fā)方法以便于靈活修改軟件。為了保證零部件質量，整車廠針對零部件進行測試并反饋存在的問題。由于制造商在軟件修改時可能引入新的漏洞，因此增加了整車廠的測試成本。同時由于整車廠測試環(huán)境與制造商開發(fā)環(huán)境不同，開發(fā)人員可能難以復現存在的問題，從而帶來軟件維護的困難。

為了減少以上問題，本文引入開源單元測試框架Cpputest[4-5]，并以時間同步協(xié)議代碼為例提出針對車載控制器軟件的開發(fā)方法。通過對軟件模塊引入特定的測試用例，可以有效規(guī)范軟件模塊接口、減少缺陷出現幾率并提高多個開發(fā)者之間合作與交接的效率，從而催生出設計優(yōu)良和結構緊湊的代碼。盡管測試用例的編寫增加了開發(fā)階段工作量，該方法提高了軟件質量，減少了后期維護難度，從而降低了軟件實際開發(fā)成本。

2 單元測試開發(fā)方法

嵌入式開發(fā)過程中底層與應用程序邊界不清晰甚至混編導致軟件和硬件設計過程需相互協(xié)調和反饋。此時軟件功能與硬件緊密相連，因此缺乏繼承性并需隨著硬件升級重新開發(fā)，開發(fā)完成后還需整體聯(lián)調才能確認功能是否滿足要求[6]。如圖1a所示，常規(guī)開發(fā)流程中，開發(fā)人員參考設計需求和接口開展代碼編寫工作，受硬件功能和數量的限制，代碼中存在部分問題難以在調試和測試過程發(fā)現，從而造成交付風險。交付后的漏洞通常采用打補丁的方法修復，此時設計人員必須在有限的時間內修改代碼并搭建測試環(huán)境進行完整測試，而人工測試存在回歸性、效率、覆蓋率、數據的重用性等問題[7]，因此修改過程中又可能引入新的漏洞，造成后期維護難度與成本增加。

圖1 開發(fā)流程對比

與常規(guī)開發(fā)流程相比，基于單元測試框架的代碼編寫過程中增加了測試用例的開發(fā)內容，如圖1b所示，該開發(fā)流程中測試用例的制定總是執(zhí)行在代碼編寫之前，代碼更新和重構后均可通過測試，從而保障輸出代碼總是滿足預定義的邏輯要求。測試用例的運行借助了編程語言的特性。嵌入式代碼采用C語言編寫，由于C語言是跨平臺的，軟件模塊可以在主機上編譯運行。通過特定參數輸入，觀察模塊輸出行為，可以測試軟件行為是否達到期望要求。由于測試在主機平臺上運行，開發(fā)前期不需要硬件介入，因此可以有效減少與其他開發(fā)人員的資源矛盾[8]。

Cpputest是基于C++的測試框架，可以運行在Visual Studio、eclipse和MinGW等環(huán)境中，被測模塊作為C代碼模塊鏈接到C++工程。如圖2所示，被測示例代碼的目的是將add的值加到p指針所指向的數據中。其開發(fā)過程為：

a.為了使整個C++工程完成編譯，將被測函數作為空函數加入工程中。

b.編寫并執(zhí)行測試用例1，由于空函數并不對指針p進行操作，因此通過測試。

c.編寫測試用例2并執(zhí)行測試，由于空函數中p指向的數據沒有更新，測試失敗，此時程序顯示如圖3所示，測試結果顯示當前2號用例第33行判斷出錯。

d.添加賦值代碼，再運行測試，測試用例2通過而測試用例1由于存在空指針訪問失敗。

e.被測代碼增加空指針保護，并重新運行測試用例，通過測試。

f.繼續(xù)添加測試用例和修改被測代碼。

圖2 單元測試示例

圖3 空函數運行結果

被測代碼在每一次修改后均可快速執(zhí)行所有測試用例，因此開發(fā)者可以立即發(fā)現新的代碼帶來的漏洞并及時修改，從而避免了函數復雜度提高后調試帶來的額外工作量。由于測試用例在主機上運行，因此測試具有以下優(yōu)點：

a.速度快。如圖3所示，兩條測試用例的運行時間小于1 ms，測試過程由CPU執(zhí)行，其速度遠高于人工手動測試。

b.可重復性高。每一次代碼修改后均可完整運行所有測試用例，不會出現人為失誤導致的錯誤結果。

c.無須硬件支持。當實際硬件數量較少或者調試環(huán)境復雜時，單元測試可以有效減少實際調試時間，從而降低調試成本。

d.測試更全面。對于部分偶發(fā)性或者由于器件老化帶來的故障（例如FLASH驅動寫入數據失?。?，實物測試很難達到實際故障條件，而軟件可以模擬任意故障。

3 車載時鐘同步協(xié)議開發(fā)

盡管Cpputest提供了良好的開發(fā)框架，實際開發(fā)過程中依然存在例如文件依賴、接口定義、寄存器訪問和中斷處理等問題。這些問題可能導致代碼處于不可測狀態(tài)，從而使得基于單元測試的開發(fā)工作無法進行。本節(jié)以車載時鐘同步協(xié)議軟件模塊為例，描述解決方法。

3.1 合理的依賴關系

在主機上運行代碼時，首要條件即是編譯成功，這要求被測代碼支持在嵌入式和主機端均能編譯通過。盡管C語言具有一致性，代碼文件的依賴性可能導致編譯失敗。如圖4a所示，大部分驅動代碼會引用交叉編譯器提供的寄存器描述文件，而主機編譯器并不提供該文件，從而導致文件缺失。

圖4 文件依賴關系

單片機在制造過程中普遍將寄存器映射到部分內存地址，因此，對于軟件代碼而言，內存和寄存器并沒有差別。如圖4b所示，通過將描述硬件模塊寄存器的結構體存入模塊私有頭文件中，再在模塊初始化時傳入寄存器基地址，可以有效減少對交叉編譯器的依賴。同時，在單元測試過程中，測試代碼可以引用該私有頭文件，即可任意操作寄存器行為，從而模擬實際工作條件下難以出現的故障。

除編譯器依賴外，軟件模塊常調用其他組件，因此，測試時需依據測試用例需求使用或替換被依賴的組件。如圖5所示，被測時鐘同步模塊有多個依賴組件，而測試用例通過輸入帶有不同時間戳的報文，查看同步模塊是否通過正確參數將本地時鐘頻率和相位的誤差傳遞給鐘修正模塊。為了截取函數調用參數，采用仿冒的方法替換部分實際模塊，從而可以在每條測試用例中檢查實際時鐘修正值。

圖5 同時使用實際和仿冒模塊

通過合理的依賴關系設計，被測代碼可以盡可能獨立于其他模塊，從而增加代碼可測性并減少自動化測試成本。這將花費設計人員更多時間，但可以使得依賴關系更加明確并增加代碼可復用性。同時由于被測代碼可以獨立編譯，因此更容易采用PC-Lint等工具執(zhí)行靜態(tài)檢查。

3.2 可測的接口定義

在引入單元測試框架后，代碼接口定義的合理性變得更加重要。如果被測模塊所有函數均沒有參數，則該模塊可測性降低，而代碼編寫過程中部分函數名稱、參數、返回值和功能定義發(fā)生變化，則需修改所有與該部分相關的測試用例，從而導致工作量增加。

被測時鐘同步模塊的接口定義如表1所示，其中，接口分別與主程序、底層報文收發(fā)驅動和時鐘模塊交互，從而達到校準本地時鐘的目的。盡管全局變量也可用于模塊間交互并進行單元測試，但實際使用中導致程序的狀態(tài)不可預測，因此，時鐘同步的接口均為函數或函數指針，防止模塊變量被意外訪問。

表1 時間同步模塊函數接口

函數指針的另一個優(yōu)勢在于模塊內部無需引用固定頭文件。例如，不同硬件平臺有不同的本地時鐘模塊，其頭文件名稱、函數定義均存在區(qū)別，如果直接引用則會出現文件依賴現象，導致移植時出現困難。函數指針可以有效減少依賴關系、降低耦合度并使接口與實現分開，因此更適合需要單元測試的代碼模塊。

3.3 測試用例設計

完成接口設計后，首先制定測試用例。測試用例的具體內容與函數定義、模塊功能需求有關，一般涉及接口、局部數據結構、邊界條件、獨立路徑和錯誤處理路徑等5類[9]。通過總結時間同步模塊的測試用例，可以得到如表2所示的用例類型。其中，測試對象可以是單個函數或整個模塊，通過正確或錯誤的調用檢查模塊行為是否滿足預期。由于每一次代碼改動均會運行所有用例，因此可以保障模塊行為總是滿足預期要求。

表2 測試用例類型

盡管測試用例可以有效約束模塊行為，但應避免濫用。例如，測試過程中可以通過自定義函數返回模塊內部變量進一步監(jiān)視模塊狀態(tài)。然而代碼迭代開發(fā)過程中，內部狀態(tài)邏輯可能發(fā)生變化，因此該測試用例反而限制了代碼的進一步開發(fā)。通常，模塊對外接口不變，而模塊使用者也只關心接口，因此，測試用例應當類似于黑盒測試，其測試對象為實際使用中涉及到的真實接口，從而避免測試對開發(fā)的約束。良好的測試用例易于發(fā)現程序的錯誤和缺陷，也易于實現代碼測試的完全覆蓋，因此其優(yōu)劣對軟件質量的保證起著關鍵作用[10]。

3.4 單元測試的問題

盡管單元測試為代碼帶來好處，其工作模式依然存在問題，例如平臺差異和中斷處理。前者可以通過更具通用性的編碼方式解決，而后者則需要開發(fā)人員人工判斷。

3.4.1 編譯平臺差異

單元測試運行在主機環(huán)境中，因此，其編譯平臺與嵌入式工作平臺存在差別，例如支持的語言特性、基本數據類型大小、字節(jié)序、數據對齊和中斷標志位處理等，因此可能導致測試通過的代碼在實際運行中出現問題。然而，該問題也說明了代碼通用性不足，模塊在移植到其它平臺時也可能遇到。因此，在初次實際調試中需注意平臺相關問題并盡可能解決，例如：對于數據類型長度，可以采用固定長度類型；對于大小端模式，可以加入宏定義判斷等。盡管代碼工作效率和內存利用率可能降低，但修改后的代碼更適于運行在多個平臺上，從而提高代碼可移植性，延長使用壽命。

3.4.2 無法覆蓋的用例

盡管測試用例可以測試正常和故障情況下模塊的行為，它并不能解決所有問題。最常見的不可測用例來源于中斷或者嵌入式操作系統(tǒng)任務調度。以表1中的函數為例，底層收發(fā)模塊調用P8021AS_rx_frame函數匯報收到的報文，而主函數周期調用P8021AS_tick函數處理收到的報文。兩個函數均會對接收緩沖區(qū)進行操作，如果兩者運行在不同優(yōu)先級，則可能出現搶占行為，從而導致函數間公有的變量工作不正常，造成報文丟失等偶發(fā)故障。在模塊設計過程中并不能預測實際使用情況，因此圖5中引入隊列管理模塊，通過受到保護的先入先出隊列保證兩個函數之間不會出現搶占問題。除調度搶占外，對于同一函數，由于操作系統(tǒng)調度也可能出現函數重入現象，如果代碼不可重入，則會導致工作異常。

Cpputest并不支持測試中斷搶占，因此測試用例運行時并不會出現函數中斷和重入問題，而實際運行過程中該問題出現的時機可能是隨機的，從而進一步增加了調試難度。設計人員必須在設計階段減少模塊內全局變量，分析每一個全局變量是否存在搶占的風險，并對存在重入風險的代碼進行保護以避免不可測問題帶來的影響。

4 時鐘同步模塊測試運行實例

時鐘同步模塊完成后單元測試結果如圖6所示，整個工程存在41條測試用例，而執(zhí)行一次的時間為2.29 s。整個執(zhí)行過程中有1 000 842次邏輯判斷，因此手動測試難以覆蓋所有的測試需求。

由于測試時間較短，因此每一次修改完成后均可執(zhí)行所有測試用例。如圖7所示，假設代碼修改過程中開發(fā)人員偶然引入漏洞，將報文格式不正確時返回值AS_NOK改為了AS_OK，運行時可以立即發(fā)現該漏洞并在輸出報告中指出失敗測試用例以及實際判斷代碼地址。由于有2條測試用例均會檢查該返回值，因此兩者均測試失敗。通過分析代碼、單步調試等手段可以很快定位到錯誤點并及時修正。隨著被測模塊代碼量的增長，開發(fā)人員可能在被測模塊中加入代碼后卻沒有在任何測試用例中執(zhí)行。此時，所有測試依然可以通過但未執(zhí)行代碼可靠性存在風險。此時可借助OpenCppCoverage等第三方覆蓋率檢查工具查看被測模塊在整個測試過程中沒有執(zhí)行的代碼。如果存在此類代碼，則可以通過刪除代碼或者增加測試用例的方式修改開發(fā)工程，從而保障單元測試的完整性。

圖6 時間同步模塊運行測試

圖7 錯誤修改后立即報錯

5 結束語

本文為車載嵌入式控制器軟件開發(fā)引入開源單元測試框架Cpputest，從而使模塊開發(fā)過程與代碼單元測試相結合。通過合理的文件依賴關系和可測的代碼接口，軟件模塊可以脫離實際硬件平臺運行。在測試用例的幫助下，每一次代碼改動均可完整驗證其可靠性，從而避免漏洞引入。實際硬件調試過程中遇到的問題也可轉化為測試用例，從而避免已經修改的漏洞反復出現并提高了代碼質量。盡管開發(fā)過程中初期工作量更大，該方法強制開發(fā)者使用更合理的軟件架構，減少了后期維護難度與成本。而測試用例亦可用于形成文檔化的軟件說明，從而減少模塊的交接、移植等工作帶來的影響，延長了軟件壽命。