數(shù)據(jù)靜態(tài)分析技術(shù)及其在安全軟件測試中的應(yīng)用

孫志科

（北京全路通信信號研究設(shè)計院集團(tuán)有限公司，北京 100070）

1 概述

對于應(yīng)用在列車運行控制系統(tǒng)中的鐵路信號安全軟件（以下簡稱安全軟件）來說，除了軟件邏輯以外，工程數(shù)據(jù)的質(zhì)量同樣直接影響著系統(tǒng)的安全性和可用性。特別是在高密度、高速度的干線鐵路及大型樞紐中，即使是單個信號系統(tǒng)的某一個數(shù)據(jù)錯誤，其影響范圍也會隨著時間的推移而迅速擴(kuò)大，給鐵路運輸秩序帶來嚴(yán)重的影響。

2 常見的數(shù)據(jù)錯誤模式

在構(gòu)成列車運行控制系統(tǒng)的各類安全軟件制作過程中，常見的數(shù)據(jù)錯誤模式及其典型特征如表1所示。

表1 安全軟件常見數(shù)據(jù)錯誤模式及其典型特征Tab.1 Common data error patterns and their typical characteristics of safety software

為保證交付給用戶的列車運行控制系統(tǒng)的功能、性能及安全性符合要求，必須采用適當(dāng)?shù)姆椒?，在安全軟件發(fā)布前將各類錯誤數(shù)據(jù)全部檢出并修正。特別是各類多余數(shù)據(jù)，一旦在安全關(guān)鍵數(shù)據(jù)中出現(xiàn)，有可能對鐵路運輸安全造成極大威脅。

3 常用軟件測試技術(shù)

根據(jù)測試對象是否包含軟件內(nèi)部的邏輯結(jié)構(gòu)和工作機(jī)制，軟件測試技術(shù)可以分為兩大類：白盒測試（White-box Testing）、黑盒測試（Black-box Testing）。

白盒測試是側(cè)重于系統(tǒng)或部件內(nèi)部工作機(jī)制的測試。

黑盒測試是忽略系統(tǒng)或部件的內(nèi)部工作機(jī)制，只集中于響應(yīng)所選擇的輸入和執(zhí)行條件后所產(chǎn)生的輸出，用于評價系統(tǒng)或部件與規(guī)定的功能需求遵循性的一種測試。

根據(jù)在測試過程中是否運行被測軟件，白盒測試技術(shù)又可以分為兩大類：

靜態(tài)分析技術(shù)：不運行被測軟件；

動態(tài)測試技術(shù)：運行被測軟件。

白盒測試技術(shù)的適用對象，及其在被測對象定位方面的能力如表2所示。

表2 白盒測試技術(shù)的適用對象及定位能力Tab.2 Applicable objects and positioning ability of white box testing technology

為了使軟件的安全完整度達(dá)到SIL4級，對于涉及安全的配置數(shù)據(jù)，其測試覆蓋率應(yīng)當(dāng)達(dá)到100%。

因此，在進(jìn)行安全軟件的數(shù)據(jù)測試時，應(yīng)當(dāng)選擇能夠準(zhǔn)確定位被測數(shù)據(jù)所在位置的測試技術(shù)，才能在此基礎(chǔ)上實現(xiàn)數(shù)據(jù)測試覆蓋率的統(tǒng)計。

黑盒測試技術(shù)的適用對象，及其在被測對象定位方面的能力如表3所示。

表3 黑盒測試技術(shù)的適用對象及定位能力Tab.3 Applicable objects and positioning ability of black box testing technology

從表2及表3的對比可以看出，只有采用白盒測試技術(shù)中的靜態(tài)分析技術(shù)進(jìn)行工程數(shù)據(jù)測試，才能在數(shù)據(jù)測試過程中得到測試覆蓋率統(tǒng)計結(jié)果。

4 安全軟件測試技術(shù)應(yīng)用現(xiàn)狀

4.1 現(xiàn)狀及原因

目前，在列車運行控制系統(tǒng)的集成過程中，對安全軟件的功能及數(shù)據(jù)測試以黑盒測試技術(shù)為主，很少應(yīng)用白盒測試技術(shù)，原因主要有以下幾點：

1）白盒測試技術(shù)只適用于基本的軟件單元或小型的功能模塊，無法對軟件的整體功能進(jìn)行測試，不能滿足列車運行控制系統(tǒng)集成測試的需求；

2）白盒測試（主要是動態(tài)白盒測試）需要耗費大量的時間和人力。在列車運行控制系統(tǒng)的集成過程中，受工期和人力資源的限制，很難開展白盒測試工作；

3）當(dāng)安全軟件定型后，在列車運行控制系統(tǒng)的集成過程中，通過版本管理、配置管理等管理過程，并借助適當(dāng)?shù)墓ぞ哕浖С郑ɡ纾号渲霉芾砉ぞ哕浖?，可以保證在集成過程中使用正確版本的安全軟件，不需要對每個項目的軟件進(jìn)行白盒測試；

4）現(xiàn)有的所有商業(yè)化軟件靜態(tài)分析工具（例如：Testbed、Cantata等）都只能用于軟件代碼的靜態(tài)分析，無法對配置數(shù)據(jù)進(jìn)行分析。由于安全軟件的配置數(shù)據(jù)的數(shù)量通常十分巨大，沒有工具軟件的支持無法實現(xiàn)完整的分析。

4.2 黑盒測試技術(shù)的優(yōu)點

黑盒測試技術(shù)是軟件測試領(lǐng)域中應(yīng)用最廣泛的技術(shù)，其原因主要包括：

1）技術(shù)門檻低，測試方法和步驟易于測試工程師學(xué)習(xí)和掌握；

2）測試環(huán)境、操作步驟及使用場景與被測對象的實際運行環(huán)境比較接近，測試結(jié)果的可視性及可信度比較高。

在列車運行控制系統(tǒng)的集成過程中，采用黑盒測試技術(shù)進(jìn)行安全軟件的功能和數(shù)據(jù)測試時，整個測試過程與被測系統(tǒng)的實際運行過程比較接近，測試過程的可視性及可信度較高。

4.3 黑盒測試技術(shù)的不足

隨著國內(nèi)高速鐵路建設(shè)規(guī)模的迅速擴(kuò)大，用戶和市場對鐵路信號安全產(chǎn)品的安全性、可用性要求不斷提高的同時，對產(chǎn)品的集成、測試、交付的速度和成本也提出了越來越高的要求。在這種情況下，黑盒測試技術(shù)的不足之處越發(fā)凸顯出來。

1) 測試周期長，時間成本高

為保證鐵路信號安全產(chǎn)品的安全性及可用性，對每個產(chǎn)品的工程數(shù)據(jù)都應(yīng)當(dāng)進(jìn)行完整的測試，即涉及安全的數(shù)據(jù)的測試覆蓋率應(yīng)達(dá)到100%。

例如：在計算機(jī)聯(lián)鎖產(chǎn)品的工程數(shù)據(jù)測試過程中，聯(lián)鎖表中的每一條進(jìn)路都需要進(jìn)行測試，不允許有遺漏。而隨著車站的道岔數(shù)量、接發(fā)車口數(shù)量的增加，站內(nèi)進(jìn)路的數(shù)量會呈幾何級數(shù)增長，因而測試工作量的增長也非常迅速，這還不包括執(zhí)行其他測試項所需的時間。要完成一個車站的全部進(jìn)路數(shù)據(jù)測試，無論是采用人工測試還是自動化測試，所需的時間都要以小時、甚至以天為單位計算。

2) 測試針對性不強(qiáng)

任何一個軟件功能的實現(xiàn)都需要多個功能模塊和若干配置數(shù)據(jù)的共同作用才能完成。因此，任何一個黑盒測試案例都能夠同時覆蓋多個軟件功能模塊和配置數(shù)據(jù)。雖然從單個測試案例的角度看，其測試效率比較高，但從整體來看，各個測試案例的作用范圍存在不同程度的重疊，很難對某一個數(shù)據(jù)進(jìn)行針對性的測試，導(dǎo)致在整個測試過程中，很多數(shù)據(jù)會被重復(fù)測試，反而降低了整體的測試效率。

如果確切的知道某個功能點所對應(yīng)的數(shù)據(jù)，則只需要打開數(shù)據(jù)文件，直接核對數(shù)據(jù)配置的正確性，幾分鐘的時間就足夠。而這種直接檢查數(shù)據(jù)配置的測試方法就是典型的白盒測試技術(shù)中的靜態(tài)分析技術(shù)。

3) 對于某些類型的錯誤數(shù)據(jù)的檢出效率很低，甚至無法檢出

黑盒測試技術(shù)在測試過程中無法跟蹤和監(jiān)視被測軟件的內(nèi)部執(zhí)行路徑，也無法確認(rèn)被測對象的所有靜態(tài)數(shù)據(jù)中，哪些已經(jīng)被測試覆蓋，哪些還未被覆蓋。

例如：在北京全路通信信號研究設(shè)計院集團(tuán)有限公司的計算機(jī)聯(lián)鎖產(chǎn)品的工程數(shù)據(jù)測試過程中，對于聯(lián)鎖表中列出的進(jìn)路，測試工程師會100%測試。但是，對于聯(lián)鎖軟件中配置的超出聯(lián)鎖表范圍的進(jìn)路數(shù)據(jù)，測試工程師則無法進(jìn)行測試。這是因為，僅僅通過黑盒測試技術(shù)，測試工程師無法確切知道聯(lián)鎖軟件中配置了多少條進(jìn)路的數(shù)據(jù)，也無法知道究竟有哪些進(jìn)路的數(shù)據(jù)已被測試，哪些還未被測試。

即使采用白盒測試技術(shù)，也無法檢出多余數(shù)據(jù)。因為目前所有的白盒測試工具軟件都只能實現(xiàn)對軟件代碼執(zhí)行路徑的跟蹤和記錄，無法實現(xiàn)對靜態(tài)配置數(shù)據(jù)使用情況的跟蹤和記錄，因而無法統(tǒng)計靜態(tài)數(shù)據(jù)的測試覆蓋率。

再比如，對于以某一架進(jìn)站信號機(jī)為始端的所有進(jìn)路中，最多只有一條進(jìn)路能夠開放U燈顯示，其他進(jìn)路的信號顯示應(yīng)均為UU或USU。否則必然存在信號顯示升級的進(jìn)路數(shù)據(jù)。

要想確認(rèn)這一點，如果采用黑盒測試技術(shù)，則必須把所有以這架信號機(jī)為始端的進(jìn)路全部辦理一遍。對于大型樞紐車站，特別是變更進(jìn)路較多的車站，這個過程顯然需要耗費大量的時間。因此，黑盒測試技術(shù)對于某些類型的數(shù)據(jù)錯誤，其檢出效率是比較低的。

4) 依賴于特定的測試環(huán)境，測試成本高

對安全軟件進(jìn)行測試時，往往需要配置專用的軟件環(huán)境。如果需要在半實物仿真環(huán)境中進(jìn)行測試，還需要專用的硬件環(huán)境，例如：二取二架構(gòu)的安全計算機(jī)，各類專用的硬件板卡等。對于一些開通年限較長的車站，往往面臨現(xiàn)有的測試環(huán)境與早期軟件不兼容的困難，需要花費大量的人力、時間和費用才能恢復(fù)早期的測試環(huán)境。

5 在安全軟件數(shù)據(jù)測試中引入靜態(tài)分析技術(shù)

5.1 軟件靜態(tài)分析技術(shù)的概念

軟件靜態(tài)分析（Software Static Analysis）是指在不運行軟件的情況下，通過詞法分析、語法分析、控制流分析、數(shù)據(jù)流分析等技術(shù)對軟件代碼進(jìn)行掃描，驗證代碼是否滿足規(guī)范性、安全性、可靠性、可維護(hù)性等指標(biāo)的一種代碼分析技術(shù)。

軟件靜態(tài)分析工作既可以由程序員人工完成，即傳統(tǒng)意義上的軟件代碼審核，也可以使用專用的工具軟件完成，例如：Klocwork、LDRA Testbed等。軟件代碼規(guī)模較大，或結(jié)構(gòu)比較復(fù)雜時，僅靠人工審核無法充分的分析全部代碼，必須借助專業(yè)的工具軟件。

5.2 軟件靜態(tài)分析技術(shù)的優(yōu)勢

借助專業(yè)工具軟件對軟件代碼進(jìn)行靜態(tài)分析，與采用白盒動態(tài)測試及黑盒測試技術(shù)相比，有以下幾方面的突出優(yōu)勢。

1）執(zhí)行速度快、缺陷檢出效率高

使用靜態(tài)分析工具軟件可以快速的發(fā)現(xiàn)一些導(dǎo)致功能異?；蚴У能浖a缺陷，例如：內(nèi)存泄漏、指針越界等。

而如果想在動態(tài)測試過程中發(fā)現(xiàn)這些缺陷，往往需要經(jīng)過復(fù)雜、長時間的連續(xù)測試，甚至要靠運氣。

2）可以檢出潛在的缺陷或隱患

專業(yè)的靜態(tài)分析工具軟件都具備軟件編碼的質(zhì)量度量功能，可以發(fā)現(xiàn)軟件代碼中潛在的質(zhì)量缺陷或隱患，例如不可達(dá)分支、圈復(fù)雜度過高等。

3）可以靈活選擇分析范圍，針對性強(qiáng)

使用靜態(tài)分析工具軟件既可以對完整的軟件代碼進(jìn)行分析，也可以對某一個源代碼文件，甚至某一個最小的軟件單元進(jìn)行分析，針對性很強(qiáng)，從而可以在必要的時候節(jié)省大量的時間。

4）不依賴特定的測試環(huán)境，使用成本低

商品化的軟件代碼靜態(tài)分析工具軟件都可以運行在普通的桌面計算機(jī)中，不需要依賴特定的運行環(huán)境，使用成本很低。通過以上分析可以看出，靜態(tài)分析技術(shù)的優(yōu)勢恰恰是黑盒測試技術(shù)的不足之處。如果將靜態(tài)分析技術(shù)應(yīng)用到安全軟件的數(shù)據(jù)測試過程中，既可以解決多余數(shù)據(jù)難以檢出的難題，又可以提高數(shù)據(jù)測試的工作效率。

但是，現(xiàn)有的商業(yè)化靜態(tài)分析工具軟件針對的目標(biāo)都是軟件代碼，而不是配置數(shù)據(jù)，無法直接用于安全軟件的配置數(shù)據(jù)。

此外，安全軟件的配置數(shù)據(jù)數(shù)量通常非常龐大。以一個30組道岔的車站為例，其聯(lián)鎖軟件中的數(shù)據(jù)就超過3萬個。如此龐大的數(shù)據(jù)量，依靠人工審核的方式根本無法滿足列車運行控制系統(tǒng)集成項目的工期和成本要求。在以往的工程實踐中，通過黑盒測試的方式完成安全軟件的數(shù)據(jù)測試工作后，會對個別的關(guān)鍵數(shù)據(jù)進(jìn)行人工審核，以確認(rèn)其配置數(shù)值與實測結(jié)果一致，但是數(shù)量非常有限。

因此，要想在安全軟件的數(shù)據(jù)測試過程中應(yīng)用靜態(tài)分析技術(shù)，必須根據(jù)特定產(chǎn)品的數(shù)據(jù)結(jié)構(gòu)定義，開發(fā)專用的數(shù)據(jù)靜態(tài)分析工具軟件。

5.3 數(shù)據(jù)靜態(tài)分析技術(shù)的典型應(yīng)用場景

在安全軟件的數(shù)據(jù)測試過程中，有必要在以下場景中借助專用工具軟件的支持，應(yīng)用數(shù)據(jù)靜態(tài)分析技術(shù)。

1）檢出多余數(shù)據(jù)

有可機(jī)讀的電子化輸入文件（例如：Excel格式的電子聯(lián)鎖表及接口數(shù)據(jù)表）作為比對依據(jù)時，可以將配置數(shù)據(jù)與電子化輸入文件進(jìn)行直接比對，就能夠快速、準(zhǔn)確的發(fā)現(xiàn)超出輸入文件規(guī)定范圍以外的多余數(shù)據(jù)。

目前，各設(shè)計單位發(fā)布的列控工程數(shù)據(jù)表已經(jīng)實現(xiàn)電子化和標(biāo)準(zhǔn)化，但是聯(lián)鎖表仍然維持著發(fā)布紙質(zhì)工程圖的方式，導(dǎo)致計算機(jī)聯(lián)鎖產(chǎn)品在應(yīng)用數(shù)據(jù)靜態(tài)分析技術(shù)和自動化測試技術(shù)方面存在著根本性的障礙。要解決這個問題，需要行業(yè)主管部門和各設(shè)計單位共同努力推動。

沒有可機(jī)讀的電子化輸入文件作為比對依據(jù)時，可以通過數(shù)據(jù)靜態(tài)分析工具軟件將這些數(shù)據(jù)轉(zhuǎn)換為便于人工閱讀的按鈕名稱或繼電器名稱，在完成黑盒測試后，人工比對測試范圍和配置數(shù)據(jù)的一致性。通過這種方式，也可以實現(xiàn)對多余數(shù)據(jù)的有效、快速檢出。

例如：對于存在信號顯示關(guān)系的列車進(jìn)路，使用數(shù)據(jù)靜態(tài)分析工具軟件將相關(guān)的進(jìn)路數(shù)據(jù)轉(zhuǎn)換為辦理進(jìn)路的按鈕名稱及信號機(jī)名稱。完成信號顯示關(guān)系測試后，由測試工程師檢查顯示關(guān)系數(shù)據(jù)的配置是否與信號顯示關(guān)系圖或聯(lián)鎖表的要求一致。如果發(fā)現(xiàn)有超出設(shè)計范圍的顯示關(guān)系數(shù)據(jù)，則可以肯定為多余數(shù)據(jù)。

2）檢出與輸入文件不一致的數(shù)據(jù)

有可機(jī)讀的電子化輸入文件作為比對依據(jù)時，應(yīng)用數(shù)據(jù)靜態(tài)分析技術(shù)檢出多余數(shù)據(jù)的同時，還可以檢出缺失、錯誤、重復(fù)的數(shù)據(jù)。雖然這些類型的錯誤數(shù)據(jù)在進(jìn)行黑盒測試時通常也能夠發(fā)現(xiàn)，但使用數(shù)據(jù)靜態(tài)分析工具軟件可以大幅度的提高錯誤數(shù)據(jù)的檢出效率。

3）相關(guān)數(shù)據(jù)的邏輯一致性檢查

安全軟件中的各個數(shù)據(jù)結(jié)構(gòu)中配置的數(shù)據(jù)，相互之間是存在邏輯關(guān)系的。

例如：始端信號機(jī)相同的接車進(jìn)路，其進(jìn)路始端按鈕的代碼必然是相同的；構(gòu)成長調(diào)車進(jìn)路的各條基本調(diào)車進(jìn)路必然是首尾相接的；TCC需要向TSRS發(fā)送狀態(tài)的區(qū)段，其代碼應(yīng)當(dāng)在TCC區(qū)段代碼列表中存在。類似的例子還可以舉出很多。

如果某些相關(guān)的配置數(shù)據(jù)存在邏輯不一致的情況，采用靜態(tài)分析技術(shù)雖然不一定能直接檢出錯誤數(shù)據(jù)，但是可以將錯誤數(shù)據(jù)存在的范圍縮小到最低限度，再通過人工分析或測試就可以快速檢出錯誤的數(shù)據(jù)。

4）配置數(shù)據(jù)的規(guī)范性檢查

無論是從計算機(jī)編程語言的語法層面，還是安全軟件的故障-安全防護(hù)措施層面，配置數(shù)據(jù)都需要遵循一些固有的、強(qiáng)制性的規(guī)則。

例如：配置數(shù)據(jù)的數(shù)量超出數(shù)據(jù)結(jié)構(gòu)的定義長度時，在編譯的過程中會報錯，無法生成可執(zhí)行文件。但是，當(dāng)配置數(shù)據(jù)的數(shù)量小于數(shù)據(jù)結(jié)構(gòu)的定義長度，即存在空位時，編譯軟件并不會報錯，并且會將不足的數(shù)據(jù)自動補(bǔ)“0”。

但是，根據(jù)故障-安全防護(hù)措施的要求，“0”是不能作為占位數(shù)據(jù)的。因為在很多場景下，“0”本身是有效數(shù)據(jù)。為保證軟件流程的正確性和功能的安全性，在數(shù)據(jù)配置規(guī)則中往往要求使用特定的數(shù)據(jù)作為占位數(shù)據(jù)，例如：0xff或0xffff。

但是，面對海量的數(shù)據(jù)，檢查每個占位數(shù)據(jù)是否都配置為規(guī)定的數(shù)值，依靠人工是無法完成的，必須借助數(shù)據(jù)靜態(tài)分析工具軟件。

6 數(shù)據(jù)靜態(tài)分析技術(shù)的特點及不足

6.1 應(yīng)與黑盒測試技術(shù)配合使用

雖然數(shù)據(jù)靜態(tài)分析技術(shù)有上述的諸多優(yōu)點，但它也不是萬能的。數(shù)據(jù)靜態(tài)分析和軟件黑盒測試是互補(bǔ)的關(guān)系，而不是替代關(guān)系。

這是因為，數(shù)據(jù)靜態(tài)分析技術(shù)只能證明配置數(shù)據(jù)本身的完整性、正確性，以及與輸入文件的一致性，并不能證明配置數(shù)據(jù)與軟件代碼之間接口的正確性。即使配置數(shù)據(jù)本身是正確的，如果使用這些數(shù)據(jù)的軟件代碼的邏輯是錯誤的，甚至根本沒有使用這些正確的數(shù)據(jù)，那么最終實現(xiàn)的功能也不可能是正確的。

6.2 工具軟件開發(fā)及維護(hù)工作量較大

要在安全軟件的數(shù)據(jù)測試過程中應(yīng)用靜態(tài)分析技術(shù)，必須針對被測對象的數(shù)據(jù)結(jié)構(gòu)定義以及數(shù)據(jù)配置規(guī)則，開發(fā)專用的工具軟件。

而要開發(fā)這樣的工具軟件，需要解決以下幾個難點。

1) 需要詳細(xì)的數(shù)據(jù)配置手冊作為開發(fā)工程師實現(xiàn)數(shù)據(jù)檢查規(guī)則的依據(jù)。如果沒有詳細(xì)的數(shù)據(jù)配置手冊，就需要開發(fā)工程師能夠讀懂安全軟件使用這些數(shù)據(jù)結(jié)構(gòu)的代碼邏輯，或者在安全軟件開發(fā)工程師的支持下進(jìn)行開發(fā)。

2) 需要針對不同的數(shù)據(jù)結(jié)構(gòu)編制有針對性的數(shù)據(jù)分析和檢查需求，需求分析的難度和工作量較大。

3) 在發(fā)現(xiàn)錯誤數(shù)據(jù)后，工具軟件需要給出準(zhǔn)確、詳細(xì)的錯誤描述，幫助相關(guān)人員快速分析或定位錯誤數(shù)據(jù)。

4) 需要根據(jù)集成項目的數(shù)據(jù)缺陷信息，不斷擴(kuò)充工具軟件能夠檢查的數(shù)據(jù)錯誤模式，以持續(xù)滿足集成項目的測試需求。

5) 安全軟件升級后，可能增加新的數(shù)據(jù)結(jié)構(gòu)，原有數(shù)據(jù)結(jié)構(gòu)的定義或使用方式也可能發(fā)生變化，需要同時升級數(shù)據(jù)靜態(tài)分析工具，軟件的維護(hù)工作量比較大。

6.3 對測試人員素質(zhì)要求較高

測試工程師需要熟悉每個數(shù)據(jù)結(jié)構(gòu)中的每個數(shù)據(jù)項的定義和功能，熟悉數(shù)據(jù)的編制規(guī)則，才能對數(shù)據(jù)靜態(tài)分析工具軟件發(fā)現(xiàn)的數(shù)據(jù)錯誤進(jìn)行準(zhǔn)確的分析和定性。

與傳統(tǒng)的黑盒測試技術(shù)只關(guān)注被測軟件的輸入和輸出相比，對配置數(shù)據(jù)直接進(jìn)行分析和審核，顯然對測試工程師提出了更高的要求。

7 結(jié)束語

筆者所在的部門針對CBI、TCC產(chǎn)品的工程配置數(shù)據(jù)，應(yīng)用數(shù)據(jù)靜態(tài)分析技術(shù)，分別開發(fā)了專用的數(shù)據(jù)分析工具軟件，并已在系統(tǒng)集成項目中推廣使用，取得了良好效果。不僅顯著提高了典型數(shù)據(jù)缺陷的檢出效率，而且發(fā)現(xiàn)了很多采用黑盒測試技術(shù)難以發(fā)現(xiàn)的數(shù)據(jù)缺陷，有力保證了鐵路信號安全產(chǎn)品的軟件質(zhì)量和安全性。