基于C語(yǔ)言的軟件潛在分析工具的設(shè)計(jì)與實(shí)現(xiàn)

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

關(guān)鍵詞： 軟件潛在分析； 軟件可靠性； 軟件安全性； 故障樹分析； 調(diào)試器

中圖分類號(hào)： TN915.04?34； TM417 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 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 引 言

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

1 需求分析

1.1 設(shè)計(jì)目標(biāo)

首先，系統(tǒng)能夠提供以XML為接口的缺陷導(dǎo)入，并對(duì)工程項(xiàng)目代碼的靜態(tài)分析結(jié)果進(jìn)行處理，對(duì)代碼的安全缺陷進(jìn)行等級(jí)劃分，實(shí)現(xiàn)層次化的缺陷識(shí)別，統(tǒng)一缺陷類型。其次，該平臺(tái)能夠建立準(zhǔn)確的故障分析模式和故障樹分析方法，在測(cè)試過程中提高軟件故障分析及安全性測(cè)試的高效性和全面性，實(shí)現(xiàn)全數(shù)字仿真測(cè)試環(huán)境的無(wú)縫集成[3]。并提供便利的輔助功能，實(shí)現(xiàn)測(cè)試腳本的生成、測(cè)試用例的生成、測(cè)試報(bào)告單的生成。

1.2 業(yè)務(wù)流程

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

1.3 功能分析

系統(tǒng)是在全數(shù)字仿真測(cè)試環(huán)境采用軟件仿真技術(shù)的基礎(chǔ)上構(gòu)建的，仿真平臺(tái)能夠模擬SPARCV7處理器以及其他片上與片外設(shè)備的功能和時(shí)序關(guān)系，為最終的測(cè)試腳本運(yùn)行提供仿真的運(yùn)行平臺(tái)[5]。在此基礎(chǔ)上，本平臺(tái)包含下述4個(gè)系統(tǒng)，為軟件的潛在問題分析與處理提供服務(wù)，功能結(jié)構(gòu)如圖2所示。

1.4 靜態(tài)分析結(jié)果處理

靜態(tài)分析結(jié)果處理需要具備的功能包括項(xiàng)目管理、缺陷分析處理、測(cè)試用例管理、問題報(bào)告單管理和測(cè)試結(jié)果分析。其中，項(xiàng)目管理的作用是對(duì)每個(gè)軟件程序可以在該模塊建立相應(yīng)的項(xiàng)目來(lái)管理該軟件項(xiàng)目的問題；缺陷分析處理用于提供工具輔助測(cè)試人員對(duì)缺陷結(jié)果進(jìn)行處理；測(cè)試用例管理主要管理測(cè)試用例，對(duì)缺陷對(duì)應(yīng)測(cè)試用例的管理，包括添加、刪除和查詢?nèi)毕轀y(cè)試用例的功能；能夠通過提供的測(cè)試用例模板輔助生成測(cè)試用例。

1.5 故障模式及故障樹分析

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

2 系統(tǒng)設(shè)計(jì)

2.1 硬件整體架構(gòu)

缺陷分析工具的設(shè)計(jì)采用基于服務(wù)器?客戶端的設(shè)計(jì)方案。其中服務(wù)器主要提供靜態(tài)分析服務(wù)和測(cè)試數(shù)據(jù)的存儲(chǔ)。靜態(tài)分析服務(wù)一般由靜態(tài)分析軟件提供，包括靜態(tài)分析服務(wù)、數(shù)據(jù)存儲(chǔ)服務(wù)?？蛻舳酥饕?fù)責(zé)進(jìn)行實(shí)際的測(cè)試，包含：靜態(tài)分析結(jié)果處理、故障模式及故障樹分析、基于故障注入的動(dòng)態(tài)測(cè)試功能。軟硬件的整體架構(gòu)如圖3所示。

2.2 軟件設(shè)計(jì)

客戶端軟件實(shí)現(xiàn)了平臺(tái)的主要功能，其設(shè)計(jì)分為三層，其結(jié)構(gòu)見圖4。其中用戶層為用戶提供直接的服務(wù)；功能層實(shí)現(xiàn)了本安全性測(cè)試平臺(tái)的主要功能，供用戶層模塊使用。

軟件是基于EclipseRCP進(jìn)行開發(fā)的，采用GEF框架進(jìn)行建模。

2.3 功能設(shè)計(jì)

根據(jù)系統(tǒng)的需求，將工具的功能劃分為靜態(tài)分析結(jié)果處理、故障模式及故障樹分析、動(dòng)態(tài)測(cè)試調(diào)試器和基礎(chǔ)數(shù)據(jù)管理。

靜態(tài)分析結(jié)果包括項(xiàng)目管理、缺陷分析模塊、測(cè)試用管理模塊、問題報(bào)告單模塊和測(cè)試結(jié)果分析。

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

動(dòng)態(tài)測(cè)試調(diào)試器包括工程管理、斷點(diǎn)管理、調(diào)試過程控制及調(diào)試信息管理。

基礎(chǔ)數(shù)據(jù)管理的劃分包括用戶管理、角色管理、缺陷分級(jí)管理及故障模式的管理。

3 系統(tǒng)實(shí)現(xiàn)

3.1 功能實(shí)現(xiàn)

3.1.1 靜態(tài)分析結(jié)果處理

靜態(tài)分析結(jié)果處理需要具備的功能包括項(xiàng)目管理、缺陷分析處理、測(cè)試用例管理、問題報(bào)告單管理和測(cè)試結(jié)果分析[7]。

缺陷分析處理：按文件劃分顯示缺陷通過SQL的group by file查詢實(shí)現(xiàn)。

測(cè)試用例管理：根據(jù)測(cè)試用例模板輔助生成測(cè)試用例時(shí)，首先要根據(jù)缺陷代碼查詢其對(duì)應(yīng)的所有用例模板，點(diǎn)擊模板后，將模板內(nèi)容填充至界面中，點(diǎn)擊添加即可添加。另外，測(cè)試用例模板的字段與測(cè)試用例的字段相同。

問題報(bào)告單管理：?jiǎn)栴}報(bào)告單和測(cè)試用例的導(dǎo)出通過iText完成。問題報(bào)告單和測(cè)試用例的表現(xiàn)形式為word中的表格，生成報(bào)告的核心是表格的創(chuàng)建。在表格的創(chuàng)建過程中，需根據(jù)用戶的處理自動(dòng)填寫至相應(yīng)位置。

測(cè)試結(jié)果分析：首先按照給定條件查詢數(shù)據(jù)，再使用JfreeChart包繪制餅圖或柱狀圖。

3.1.2 故障模式及故障樹分析

故障樹建模采用GEF實(shí)現(xiàn)，GEF是一個(gè)圖形編輯框架。根據(jù)實(shí)際需要，系統(tǒng)提供了事件節(jié)點(diǎn)、門節(jié)點(diǎn)、轉(zhuǎn)入轉(zhuǎn)出三類節(jié)點(diǎn)和節(jié)點(diǎn)間的連線。

輔助建立故障樹，該模塊的實(shí)現(xiàn)涉及較多的數(shù)據(jù)庫(kù)操作，故障樹采用Sftree類描述，其包括多個(gè)表示節(jié)點(diǎn)的SftElement類，節(jié)點(diǎn)之間的關(guān)系為SftRelation類。

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

3.1.3 基礎(chǔ)數(shù)據(jù)管理

基礎(chǔ)數(shù)據(jù)管理模塊用于數(shù)據(jù)庫(kù)管理員對(duì)輔助測(cè)試數(shù)據(jù)的編輯，系統(tǒng)在與數(shù)據(jù)庫(kù)進(jìn)行交互過程中采用了Hibernate包[8]。對(duì)于數(shù)據(jù)庫(kù)表的增刪改，本系統(tǒng)采用了Common框架的實(shí)現(xiàn)方式。Common框架的流程如圖5所示。

3.2 SNMP協(xié)議網(wǎng)絡(luò)設(shè)備管理模塊的實(shí)現(xiàn)

3.2.1 最小割集生成算法

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

（1） 創(chuàng)建保存最小割集的列表cutset，cutset保存了若干個(gè)AnalysisNode對(duì)象，該對(duì)象保存了一個(gè)最小割集，包括這個(gè)最小割集中的所有節(jié)點(diǎn)nodes及每個(gè)節(jié)點(diǎn)到達(dá)根節(jié)點(diǎn)的路徑path；

（2） 從頂事件root開始，若root為1，則返回結(jié)束；不為1，則將創(chuàng)建AnalysisNode對(duì)象set，將root加入set的節(jié)點(diǎn)列表，并設(shè)置root的path為root，將set加入cutset列表；

（3） 獲得最小割集cutset中不全為根節(jié)點(diǎn)的currentset，若其為1，則轉(zhuǎn)步驟（7），否則轉(zhuǎn)步驟（4）；

（4） 將currentset從cuteset中移除，獲得currentset的首個(gè)非葉節(jié)點(diǎn)dealnode及門節(jié)點(diǎn)gatenode。若gatenode為“與門”，轉(zhuǎn)步驟（5）；若為“或門”，轉(zhuǎn)步驟（6）；

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

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

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

3.2.2 混編文件生成算法

數(shù)字仿真測(cè)試平臺(tái)記錄了源代碼與混編碼的對(duì)應(yīng)方式，需要根據(jù)接口生成源代碼與匯編代碼的混合代碼，其中一條源代碼可能對(duì)應(yīng)著多個(gè)匯編代碼塊，需要一次讀取源文件，查找其相應(yīng)的混編文件并進(jìn)行顯示。生成混編文件的步驟如下：

（1） 獲得源文件，將其路徑添加到數(shù)組，保證創(chuàng)建混編文件的線程只有一個(gè)；

（2） 創(chuàng)建混編文件輸出流及源文件的輸入流；

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

（4） 根據(jù)源碼行對(duì)應(yīng)的目標(biāo)碼代碼的數(shù)組，獲得代碼塊的數(shù)組，遍歷代碼塊，獲得起始目標(biāo)碼地址m_start_address，設(shè)置address_temp為m_start_address，轉(zhuǎn)步驟（5）；

（5） 遍歷代碼塊，根據(jù)PC地址address_temp獲取該行匯編文件，加入混編文件輸出流，并設(shè)置address_temp為下條指令的地址（因?yàn)榇嬖诙鄺l代碼塊時(shí)為call指令）；

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

4 測(cè)試與驗(yàn)證

4.1 測(cè)試準(zhǔn)備

（1） 測(cè)試環(huán)境包括服務(wù)器和客戶端兩個(gè)部分，硬件環(huán)境和軟件環(huán)境如表1所示。

（2） 在服務(wù)器上安裝數(shù)據(jù)庫(kù)系統(tǒng)，采用Klocwork作為靜態(tài)分析軟件，因此也需要安裝Klocwork的服務(wù)器端軟件。在客戶端上，需要安裝本系統(tǒng)和Klocwork的客戶端。

4.2 測(cè)試實(shí)例

（1） 靜態(tài)分析結(jié)果處理部分的驗(yàn)證

如采用Klocwork9進(jìn)行靜態(tài)代碼分析，對(duì)其加入了支持GJB9369的擴(kuò)展規(guī)則，分析結(jié)果通過K9提供商提供的軟件，已經(jīng)轉(zhuǎn)為本工具可接受的XML文件。導(dǎo)入后發(fā)現(xiàn)存在源代碼缺陷的文件共有4個(gè)，總計(jì)10個(gè)缺陷。由于在基礎(chǔ)數(shù)據(jù)中設(shè)置代碼為“UNINIT.STACK.MUST”的缺陷嚴(yán)重度為等級(jí)1，對(duì)其進(jìn)行缺陷確認(rèn)并填寫問題報(bào)告單，對(duì)于等級(jí)2的確認(rèn)為非缺陷，等級(jí)3的缺陷忽略。

在對(duì)靜態(tài)分析結(jié)果進(jìn)行處理后，可通過兩種途徑對(duì)處理結(jié)果進(jìn)行驗(yàn)證，一是通過打印問題報(bào)告單和測(cè)試用例與填寫內(nèi)容進(jìn)行比較確認(rèn)；二是通過數(shù)據(jù)統(tǒng)計(jì)進(jìn)行。經(jīng)過對(duì)比和驗(yàn)證，靜態(tài)分析出的源代碼缺陷處理結(jié)果正確的生成了報(bào)告和統(tǒng)計(jì)圖。

（2） 故障模式和故障樹分析驗(yàn)證

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

（3） 動(dòng)態(tài)調(diào)試的驗(yàn)證

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

源代碼缺陷可能導(dǎo)致內(nèi)存變量發(fā)生故障，因此，需要對(duì)靜態(tài)分析處理中構(gòu)建的測(cè)試用例進(jìn)行確認(rèn)。在動(dòng)態(tài)測(cè)試結(jié)束之后，還需要根據(jù)結(jié)果對(duì)測(cè)試用例進(jìn)行確認(rèn)，即確認(rèn)靜態(tài)分析或故障樹分析的軟件缺陷的測(cè)試用例是否通過。通過基于故障注入的動(dòng)態(tài)測(cè)試，可在測(cè)試過程或其記錄的文件中觀察出故障發(fā)生時(shí)系統(tǒng)的運(yùn)行狀態(tài)，從而保證系統(tǒng)的安全性。而其他分析，如源代碼缺陷的分析和故障模式及故障樹分析可以在安全性缺陷分析采用的基于故障注入的動(dòng)態(tài)測(cè)試中進(jìn)行驗(yàn)證，驗(yàn)證過程即跟蹤了缺陷的產(chǎn)生到故障的出現(xiàn)。

5 結(jié) 論

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

參考文獻(xiàn)

[1] 陳靜.Klocwork在嵌入式軟件靜態(tài)測(cè)試中的應(yīng)用[J].電子與電腦，2013，38（5）：89?92.

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

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

[4] 仉俊峰，洪炳，喬永強(qiáng).基于軟件方法故障注入系統(tǒng)[J].哈爾濱工業(yè)大學(xué)學(xué)報(bào)，2011，38（6）：873?876.

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

[6] 姜興杰，楊峰輝.軟件可靠性分析與設(shè)計(jì)[J].現(xiàn)代電子技術(shù)，2011，34（7）：135?137.

[7] 張瑋，陳為.基于Struts+Spring+Hibernate框架的探討與研究[J].長(zhǎng)春大學(xué)學(xué)報(bào)，2011，16（6）：75?80.

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