基于C語言的軟件潛在分析工具的設計與實現

摘 要： 目前，在C語言軟件潛在分析的過程中，往往忽略了對缺陷過程的管理，同時缺陷分析工作進展緩慢。針對上述問題，設計并開發了基于C語言的軟件潛在分析工具，將C語言軟件缺陷從發生源到造成事故的過程進行了分解，并采用靜態分析方法查找源代碼缺陷、故障模式和故障樹方法分析可靠性缺陷、動態測試跟蹤安全性缺陷。確定分析方法后，設計并實現了相應的工具。最后，通過實例對該工具進行了測試和驗證，驗證結果表明，該工具在缺陷的各個階段均可對潛在缺陷進行有效的分析和管理，提高了軟件潛在分析的效率，為安全關鍵軟件的質量提供了保障。

關鍵詞： 軟件潛在分析； 軟件可靠性； 軟件安全性； 故障樹分析； 調試器

中圖分類號： TN915.04?34； TM417 文獻標識碼： A 文章編號： 1004?373X（2016）15?0081?05

Abstract： In the process of C programming language software potential analysis， the management of the defect generating process is often neglected， and the progress of the defect analysis work is slow. In order to solve the above problems， the software potential analysis tool based on C programming language was designed and developed. In the paper， the process from the generation source causing C programming language software defect to accident occurrence is decomposed， in which the static analysis method is used to find out the source code defect， the reliability defect is analyzed with failure modes and fault tree method， and the security defect is tracked with dynamic test. The corresponding tool was designed and implemented after the determination of analysis method. The tool was tested and verified with an instance. The verification results show that the tool， in each stage of the defect， can manage and analyze the potential defects effectively and improve the efficiency of the software potential analysis， and provides the guarantee for the quality of critical software safety.

Keywords： software potential analysis； software reliability； software security； fault tree analysis； debugger

0 引 言

在航空、航天等安全關鍵領域，軟件承擔的任務包括數據采集、導航控制和通信指揮等任務。隨著科技的發展，軟件已經成為這些系統的神經中樞，發揮著越來越重要的作用。在安全關鍵系統的運行過程中，若其軟件一旦發生故障，就可能造成十分嚴重的后果[1]。然而，目前的軟件缺陷分析方法及工具均從某個單一的角度檢測軟件缺陷。在實際的可靠性和安全性測試中，不可能只采用其中的一種分析方法來斷定軟件的缺陷，而需要將多種分析方法有效結合，在最大程度上保證安全關鍵軟件的質量[2]。

1 需求分析

1.1 設計目標

首先，系統能夠提供以XML為接口的缺陷導入，并對工程項目代碼的靜態分析結果進行處理，對代碼的安全缺陷進行等級劃分，實現層次化的缺陷識別，統一缺陷類型。其次，該平臺能夠建立準確的故障分析模式和故障樹分析方法，在測試過程中提高軟件故障分析及安全性測試的高效性和全面性，實現全數字仿真測試環境的無縫集成[3]。并提供便利的輔助功能，實現測試腳本的生成、測試用例的生成、測試報告單的生成。

1.2 業務流程

基于C語言的潛在分析工具共有兩條主線流程，如圖1所示。靜態分析結束后，通過XML接口將缺陷導入本系統，可以查看缺陷所在的源文件、根據已整理完成的缺陷分級獲得缺陷嚴重等級、對缺陷進行處理并填寫問題報告單、編寫測試用例等。使用系統提供的工具在故障模式輔助下的故障樹建模，并計算故障樹的最小割集，生成測試用例[4]。以上2個步驟生成測試用例后，在全數字仿真測試平臺的基礎上編寫測試腳本，使用調試器進行動態測試，在測試過程中可進行單步跳過和單步進入等，并觀察寄存器狀態、內存值和變量值，測試結束后分析測試數據。

1.3 功能分析

系統是在全數字仿真測試環境采用軟件仿真技術的基礎上構建的，仿真平臺能夠模擬SPARCV7處理器以及其他片上與片外設備的功能和時序關系，為最終的測試腳本運行提供仿真的運行平臺[5]。在此基礎上，本平臺包含下述4個系統，為軟件的潛在問題分析與處理提供服務，功能結構如圖2所示。

1.4 靜態分析結果處理

靜態分析結果處理需要具備的功能包括項目管理、缺陷分析處理、測試用例管理、問題報告單管理和測試結果分析。其中，項目管理的作用是對每個軟件程序可以在該模塊建立相應的項目來管理該軟件項目的問題；缺陷分析處理用于提供工具輔助測試人員對缺陷結果進行處理；測試用例管理主要管理測試用例，對缺陷對應測試用例的管理，包括添加、刪除和查詢缺陷測試用例的功能；能夠通過提供的測試用例模板輔助生成測試用例。

1.5 故障模式及故障樹分析

靜態分析結果處理需要具備的功能包括故障樹建模、輔助建立故障樹及故障樹分析。其中故障樹建模提供用戶繪制故障樹的平臺，包括建模、導入保存節點屬性的編輯和故障樹工具集管理等。輔助建立故障樹指故障樹建模過程中，使用知識庫中已經保存的故障模式及其對應的故障樹，輔助用戶使用故障樹分析方法建立故障樹模型，該功能模塊分為故障樹對齊、完整性檢查、根據故障樹節點搜索故障樹、根據故障模式搜索故障樹、保存節點對應的故障模式。故障樹分析是分析可靠性缺陷的主要模塊，是故障樹分析方法最核心的部分，包括：生成最小割集、計算事件概率、故障樹解析和測試用例生成[6]。

2 系統設計

2.1 硬件整體架構

缺陷分析工具的設計采用基于服務器?客戶端的設計方案。其中服務器主要提供靜態分析服務和測試數據的存儲。靜態分析服務一般由靜態分析軟件提供，包括靜態分析服務、數據存儲服務。客戶端主要負責進行實際的測試，包含：靜態分析結果處理、故障模式及故障樹分析、基于故障注入的動態測試功能。軟硬件的整體架構如圖3所示。

2.2 軟件設計

客戶端軟件實現了平臺的主要功能，其設計分為三層，其結構見圖4。其中用戶層為用戶提供直接的服務；功能層實現了本安全性測試平臺的主要功能，供用戶層模塊使用。

軟件是基于EclipseRCP進行開發的，采用GEF框架進行建模。

2.3 功能設計

根據系統的需求，將工具的功能劃分為靜態分析結果處理、故障模式及故障樹分析、動態測試調試器和基礎數據管理。

靜態分析結果包括項目管理、缺陷分析模塊、測試用管理模塊、問題報告單模塊和測試結果分析。

故障模式及故障樹分析包括故障樹建模、輔助建立故障樹及故障樹分析。

動態測試調試器包括工程管理、斷點管理、調試過程控制及調試信息管理。

基礎數據管理的劃分包括用戶管理、角色管理、缺陷分級管理及故障模式的管理。

3 系統實現

3.1 功能實現

3.1.1 靜態分析結果處理

靜態分析結果處理需要具備的功能包括項目管理、缺陷分析處理、測試用例管理、問題報告單管理和測試結果分析[7]。

缺陷分析處理：按文件劃分顯示缺陷通過SQL的group by file查詢實現。

測試用例管理：根據測試用例模板輔助生成測試用例時，首先要根據缺陷代碼查詢其對應的所有用例模板，點擊模板后，將模板內容填充至界面中，點擊添加即可添加。另外，測試用例模板的字段與測試用例的字段相同。

問題報告單管理：問題報告單和測試用例的導出通過iText完成。問題報告單和測試用例的表現形式為word中的表格，生成報告的核心是表格的創建。在表格的創建過程中，需根據用戶的處理自動填寫至相應位置。

測試結果分析：首先按照給定條件查詢數據，再使用JfreeChart包繪制餅圖或柱狀圖。

3.1.2 故障模式及故障樹分析

故障樹建模采用GEF實現，GEF是一個圖形編輯框架。根據實際需要，系統提供了事件節點、門節點、轉入轉出三類節點和節點間的連線。

輔助建立故障樹，該模塊的實現涉及較多的數據庫操作，故障樹采用Sftree類描述，其包括多個表示節點的SftElement類，節點之間的關系為SftRelation類。

最小割集的生成是根據用戶構建的故障樹進行分析，查找導致頂事件發生的所有基本事件的集合。其步驟大致為：輸入故障樹，判斷故障樹是否合法，若不合法則直接返回，否則進行下一步；利用“下行法”求該故障樹的最小割集；輸出得到的最小割集，并顯示在對話框中。

3.1.3 基礎數據管理

基礎數據管理模塊用于數據庫管理員對輔助測試數據的編輯，系統在與數據庫進行交互過程中采用了Hibernate包[8]。對于數據庫表的增刪改，本系統采用了Common框架的實現方式。Common框架的流程如圖5所示。

3.2 SNMP協議網絡設備管理模塊的實現

3.2.1 最小割集生成算法

故障樹完整性檢查完畢，需要求出最小割集，采用“下行法”進行計算，其步驟如下：

（1） 創建保存最小割集的列表cutset，cutset保存了若干個AnalysisNode對象，該對象保存了一個最小割集，包括這個最小割集中的所有節點nodes及每個節點到達根節點的路徑path；

（2） 從頂事件root開始，若root為1，則返回結束；不為1，則將創建AnalysisNode對象set，將root加入set的節點列表，并設置root的path為root，將set加入cutset列表；

（3） 獲得最小割集cutset中不全為根節點的currentset，若其為1，則轉步驟（7），否則轉步驟（4）；

（4） 將currentset從cuteset中移除，獲得currentset的首個非葉節點dealnode及門節點gatenode。若gatenode為“與門”，轉步驟（5）；若為“或門”，轉步驟（6）；

（5） 創建一個新的最小割集newset，遍歷currentset和“與”門的所有子節點inode，若其為dealnode則continue；將inode加入到newset的節點中，其路徑不變；遍歷gatenode的子節點gnode，將gnode加入到newset的節點中，并設置其路徑為dealnode的path與gnode之和，將newset加入到最小割集列表cutset中，轉步驟（3）；

（6） 遍歷“或”門的所有子節點snode，并創建一個新的最小割集newset，遍歷currentset的所有子節點inode，將其加入到newset的節點中；并獲得inode的路徑path，也加入到newset的path中；遍歷結束后將snode加入newset節點中并設置其path為dealnode路徑，將newset加入最小割集列表cutset，轉步驟（3）；

（7） 返回cutset，cutset即為該故障樹的最小割集列表。

3.2.2 混編文件生成算法

數字仿真測試平臺記錄了源代碼與混編碼的對應方式，需要根據接口生成源代碼與匯編代碼的混合代碼，其中一條源代碼可能對應著多個匯編代碼塊，需要一次讀取源文件，查找其相應的混編文件并進行顯示。生成混編文件的步驟如下：

（1） 獲得源文件，將其路徑添加到數組，保證創建混編文件的線程只有一個；

（2） 創建混編文件輸出流及源文件的輸入流；

（3） 遍歷源碼行號[i，]根據文件名和行號得到自[i]開始合理的第一條源碼行號[j，]若[j=0]或[i=j+1，]則將[i][到]lineSum行源文件寫入混編文件輸出流，轉步驟（6）；否則，將[i]至[j]行內容寫入混編文件輸出流中；

（4） 根據源碼行對應的目標碼代碼的數組，獲得代碼塊的數組，遍歷代碼塊，獲得起始目標碼地址m_start_address，設置address_temp為m_start_address，轉步驟（5）；

（5） 遍歷代碼塊，根據PC地址address_temp獲取該行匯編文件，加入混編文件輸出流，并設置address_temp為下條指令的地址（因為存在多條代碼塊時為call指令）；

（6） 將混編文件輸出流寫入文件，混編文件生成過程完成。

4 測試與驗證

4.1 測試準備

（1） 測試環境包括服務器和客戶端兩個部分，硬件環境和軟件環境如表1所示。

（2） 在服務器上安裝數據庫系統，采用Klocwork作為靜態分析軟件，因此也需要安裝Klocwork的服務器端軟件。在客戶端上，需要安裝本系統和Klocwork的客戶端。

4.2 測試實例

（1） 靜態分析結果處理部分的驗證

如采用Klocwork9進行靜態代碼分析，對其加入了支持GJB9369的擴展規則，分析結果通過K9提供商提供的軟件，已經轉為本工具可接受的XML文件。導入后發現存在源代碼缺陷的文件共有4個，總計10個缺陷。由于在基礎數據中設置代碼為“UNINIT.STACK.MUST”的缺陷嚴重度為等級1，對其進行缺陷確認并填寫問題報告單，對于等級2的確認為非缺陷，等級3的缺陷忽略。

在對靜態分析結果進行處理后，可通過兩種途徑對處理結果進行驗證，一是通過打印問題報告單和測試用例與填寫內容進行比較確認；二是通過數據統計進行。經過對比和驗證，靜態分析出的源代碼缺陷處理結果正確的生成了報告和統計圖。

（2） 故障模式和故障樹分析驗證

故障模式和故障樹分析驗證中，將“火箭發動機誤點火”作為頂事件進行分析，造成頂事件發生的事件是外部因素或提前點火，其中外部因素不做分析，僅對提前點火事件進行分析。提前點火事件可能由硬件故障或軟件故障造成，硬件故障的原因有蓄電池接通和點火電路允許，而軟件故障可能是由內存溢出或線程非法造成。在故障樹的分析過程中，可根據節點名稱或故障模式輔助建模，在建模結束后，為每個基本事件設置發生的概率。建模結束后對故障樹進行完整性檢查后即可進行故障樹分析，分析結果如表2所示。

（3） 動態調試的驗證

首先需要針對前兩步添加的測試用例編寫相應的測試腳本。在源代碼缺陷分析中遇到的未初始化變量 unsigned int [x，]對于該缺陷的驗證可通過兩種方式：一是在非故障注入的腳本運行過程中，可通過單步調試查看[x]變量的變化；二是通過針對該問題編寫測試腳本，需按上述格式填寫，再從調試器中打開運行，觀察測試記錄文件。首先，在 rs232.c的第36行加入斷點，點擊run運行至該行號后，單步跳過至37行。然后，下文為腳本的片段，首先在2～3內取變量[x]的值，再通過故障注入改變[x]的值，再次取出變量[x]的指令。

源代碼缺陷可能導致內存變量發生故障，因此，需要對靜態分析處理中構建的測試用例進行確認。在動態測試結束之后，還需要根據結果對測試用例進行確認，即確認靜態分析或故障樹分析的軟件缺陷的測試用例是否通過。通過基于故障注入的動態測試，可在測試過程或其記錄的文件中觀察出故障發生時系統的運行狀態，從而保證系統的安全性。而其他分析，如源代碼缺陷的分析和故障模式及故障樹分析可以在安全性缺陷分析采用的基于故障注入的動態測試中進行驗證，驗證過程即跟蹤了缺陷的產生到故障的出現。

5 結 論

航天航空等關鍵領域，軟件缺陷直接影響著整個系統。本文由缺陷產生到發生故障的過程著手，進行了全程跟蹤，并對這些安全關鍵軟件測試中使用的分析方法進行了深入的整合。工具采用接口化的方法，使得各種分析方法能夠靈活組合；并模型化數據，建立了統一的數據管理平臺，使得分析數據以標準化形式表示，增加了數據使用的延展性，便于多領域的故障數據管理；建立了多階段的分析概念，把缺陷分析流程化，多維化。在可靠性和安全性測試流程中輔助分析人員針對C語言缺陷進行完整的分析和記錄。

參考文獻

[1] 陳靜.Klocwork在嵌入式軟件靜態測試中的應用[J].電子與電腦，2013，38（5）：89?92.

[2] 樊林波，吳映程，趙明.軟件可靠性與安全性的區別分析及其證明[J].計算機科學，2008，35（9）：285?288.

[3] 何鑫，鄭軍，劉暢.軟件安全性測試研究綜述[J].計算機測量與控制，2011，19（3）：493?496.

[4] 仉俊峰，洪炳，喬永強.基于軟件方法故障注入系統[J].哈爾濱工業大學學報，2011，38（6）：873?876.

[5] 漆蓮芝，張軍，謝敏.故障樹分析測試用例生成技術研究與應用[J].信息與電子工程，2010（8）：594?597.

[6] 姜興杰，楊峰輝.軟件可靠性分析與設計[J].現代電子技術，2011，34（7）：135?137.

[7] 張瑋，陳為.基于Struts+Spring+Hibernate框架的探討與研究[J].長春大學學報，2011，16（6）：75?80.

[8] 李明，高勇，李祥和.基于語法的軟件安全檢測[J].信息安全與通信保密，2010（8）：86?87.