靜態分析技術在裝備軟件驗收中的應用

陳麗 于霞 余俊 李曉利

（1.電子信息系統復雜電磁環境效應國家重點實驗室 河南省洛陽市 471003）

（2.中國兵器工業導航與控制技術研究所 北京市 100000）

“軟件定義裝備”，軟件是信息化裝備的靈魂。隨著軟件密集型裝備比重日趨提高、更新換代周期不斷縮短，確保軟件質量、提升裝備戰備完好率成為當前首要任務。經過充分測試的裝備軟件能夠消除軟件潛在風險，降低裝備故障率，提升用戶使用信心。

靜態分析技術是靜態測試的一個分支，它不需要實際運行軟件程序和編寫測試用例，通過分析代碼來發現程序中潛在的錯誤。本文在分析靜態分析技術內涵及優勢的基礎上，從裝備軟件測試角度設計了靜態分析規則集，并依托測試工具LDRA Testbed，以某雷達軟件為例，闡述靜態分析技術在裝備軟件驗收中的應用。

1 靜態分析技術

靜態分析是一種對程序代碼進行機械性、程式化的特性分析方法，一般包括控制流分析、數據流分析、接口分析、表達式分析、編碼規范審核。雖然在編譯代碼時能發現一些程序錯誤，但其數量是非常有限的，不能完全替代靜態分析。因此程序編譯通過后，還應當對其進行靜態分析測試。

經過編譯和測試，每千行代碼中平均有10-20 個缺陷[1]。按經驗估算，靜態分析一般能夠發現30%～70%的邏輯設計和編碼錯誤[2]。在實際使用中，靜態分析測試比動態測試效率更高，能快速找到并定位缺陷。

1.1 控制流分析

控制流分析是使用控制流程圖系統地檢查被測程序的控制結構的工作[3]。控制流分析能夠查找程序中是否調用不存在的子程序、是否存在不可達語句、是否存在死循環、是否存在轉向并不存在的語句標號等問題。

1.2 數據流分析

數據流分析通過建立數據流程圖來對程序中的數據進行分析。數據流分析能夠查找程序中存在的異常情況，如引用了未定義的變量、使用了未初始化的變量等。這些異常情況常規的動態測試很難發現。

1.3 接口分析

接口分析是對程序的接口進行分析，發現接口設計方面錯誤的一種靜態分析技術[4]。接口分析能夠發現子程序之間、函數之間接口一致性問題，包括形式參數與實際參數的類型、數量、維數、順序、使用一致性，以及是否遵循了預先定義的規則或原則。

1.4 表達式分析

表達式分析是通過檢查程序代碼中的表達式，發現其中潛在的錯誤，如：數組引用錯誤、除數變量可能為零的情況、浮點數變量比較時產生錯誤、括號使用不正確等。

1.5 編碼規范審核

編碼規范審核是指依據相關標準對編程語言的規范性進行審核。遵循統一的編程規范，從形式上對編程進行約束，可保證不同開發人員開發的程序能較好地集成在一起，便于二次開發人員快速理解程序，也方便測試人員對程序的理解和測試。

2 裝備軟件靜態分析規則集

規則集是針對編程語言預先設計好的一組編碼規則，包括編碼規范和度量指標要求。裝備軟件作為特殊用途的軟件，除了實現必須的功能性能要求外，對安全性、可靠性和可維護性尤其關注[5]。

目前主流的測試工具都支持用戶定制靜態分析規則集，如C++Test、Klocwork和LDRA Testbed等，每種測試工具都有其強項[6]。本文以C++編程語言為例，依托LDRA Testbed 測試工具，針對裝備軟件特性要求，制定裝備軟件靜態分析規則集,如表1所示。

表1：裝備軟件靜態分析規則集

該規則集主要從提高軟件安全性、可靠性和可維護性方面考慮。在裝備軟件驗收測試時，看似功能實現都沒問題，但有些潛在風險通過短時間測試無法發現，需要利用一些規則集從源代碼層面上進行深入分析。如：程序中存在不可達語句，若該語句是某項功能的實現，則在驗收測試中能容易發現；但如果該語句只在某種特殊情況下才會執行，常規驗收測試就很難發現。此外，一些可維護性方面的要求，如注釋率、圈復雜度、表達式要求等編程風格方面的規范，在驗收測試時也很少考慮。

使用工具進行靜態分析設置的規則越多，發現的問題就越多，誤報和漏報的機率就越大，人工復核的工作量就越大。所以在實際測試中，需和被測方充分溝通，根據被測件特性確定所需規則集。

3 實例應用

以某雷達軟件為例，借助LDRA Testbed 8.5.0 對軟件進行靜態分析。

3.1 選擇分析文件

Testbed 可以進行單文件分析和多文件分析（set），為了從整體上給被測件一個質量評估，選擇set 方式。

set 屬性設置時有兩種模式：Group（default）和System。前者把set 中多個文件孤立的分析，后者把多個文件作為一個工程來分析。本文采用System 模式，能夠分析文件間的代碼關聯關系。

3.2 分析前配置

分析前配置主要包括被測件頭文件的設置和編碼規則集的設置。設置頭文件時，建議選擇“Analysis the first instance of each found include”，表示當頭文件被包含多次時，只分析第一個被包含的實例。進行編碼規則集設置時，可使用默認選項，或者用戶自定義規則，如圖1所示，在“Customer Sample”列表下選擇被測件關注的規則。

圖1：編碼規則集設置

3.3 分項選擇與分析過程

點擊菜單Analysis →Select Analysis，選擇要執行的分析項開始分析。通常選擇對話框中的前六項，可根據實際需求修改。

3.4 分析結果查看

點擊Testbed 的菜單System Results，在下拉項Text results，Graphical results 分別以文本形式和圖形化形式顯示分析結果。Testbed 生成的報告是英文版，如果要生成中文報告，需使用TBAudit2009 插件。

利用Testbed 進行靜態分析，除了給出源代碼遵守編碼規則情況外，還根據軟件度量模型對代碼質量進行評價。

3.5 人工復核

人工復核是根據測試報告指出的問題逐一進行核查。根據中文報告進行核查時，可能遇到找不到這個問題的情況，這時需參考英文報告來定位問題。當中文報告與英文報告個別問題存在出入時，以英文報告為主。

4 結束語

靜態測試理論上可在代碼編寫完成后的任意時段開展，但測試需要成本，尤其對靜態測試結果進行人工復核時所需人力較多。為了充分發揮靜態分析的作用，建議在編碼完成后，做單元測試時優先考慮開展靜態測試，這樣可以把很多問題消除在編碼階段。

對裝備軟件進行靜態分析，應根據裝備軟件特性制定合適的靜態分析規則集，使用工具能夠提高靜態測試的效率，但測試結果不能直接采納，需要人工進行復核，確保測試結果準確、可靠。在軟件驗收階段開展靜態測試使裝備軟件驗收工作更加有的放矢。