秦 昊，肖曼琳，王振宇，楊 霄，蔡燁玲

（上海工程技術(shù)大學(xué)城市軌道交通學(xué)院，上海 200000）

隨著中國(guó)城市化進(jìn)程的加快以及基礎(chǔ)設(shè)施建設(shè)的發(fā)展，城市軌道交通客運(yùn)里程以及客運(yùn)量不斷增加，保證城市軌道列車的安全運(yùn)行成為相關(guān)行業(yè)和社會(huì)越來越關(guān)注的任務(wù)。

目前，國(guó)內(nèi)大部分列車均搭載基于MVB 標(biāo)準(zhǔn)的網(wǎng)絡(luò)控制系統(tǒng)，即實(shí)時(shí)采集列車運(yùn)行情況，并將這些信息通過MVB 網(wǎng)絡(luò)數(shù)據(jù)顯示出來，并加以分析和處理，從而完成對(duì)車輛運(yùn)行系統(tǒng)的參數(shù)監(jiān)測(cè)，并且最后通過上位機(jī)軟件，即車輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件，動(dòng)態(tài)顯示以告知司機(jī)列車當(dāng)前的各種狀態(tài)。車輛運(yùn)行系統(tǒng)參數(shù)監(jiān)測(cè)系統(tǒng)工作流程如圖1 所示。

圖1 車輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)工作流程示意圖

本文介紹了車輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件單元測(cè)試的方法以及研究過程，但是由于該軟件的功能單元數(shù)量巨大，并且每個(gè)單元中設(shè)計(jì)的函數(shù)運(yùn)算數(shù)量龐大、邏輯復(fù)雜，軟件工作時(shí)輸入信號(hào)多變，所以設(shè)計(jì)合理的軟件單元測(cè)試方法，完整并高效地完成功能單元測(cè)試，具有很強(qiáng)的軟件工程實(shí)踐意義。本文主要研究了車輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件單元測(cè)試的方法以及過程，其具體內(nèi)容安排如下：第1 節(jié)敘述了單元測(cè)試的背景，第2 節(jié)介紹了單元測(cè)試原理以及測(cè)試方法，第3節(jié)分析了軌道交通車輛信號(hào)軟件單元測(cè)試的基本要求并設(shè)計(jì)了測(cè)試步驟，第4 節(jié)展示了車輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件單元測(cè)試流程及測(cè)試結(jié)果，第5 節(jié)總結(jié)。

1 單元測(cè)試背景

對(duì)自己書寫代碼的檢測(cè)往往會(huì)被工程師忽視，且代碼檢測(cè)存在粗略、不規(guī)范等諸多特點(diǎn)，如文獻(xiàn)[1]僅僅介紹了計(jì)算機(jī)軟件的黑盒測(cè)試這一種方法。在文獻(xiàn)[2]中采用了C++test 動(dòng)態(tài)測(cè)試來測(cè)試軟件函數(shù)運(yùn)行中存在的問題，用函數(shù)覆蓋率體現(xiàn)，具體點(diǎn)就是通過函數(shù)調(diào)用的檢測(cè)來快速準(zhǔn)確找到具體的問題函數(shù)，卻無法確定整體函數(shù)的運(yùn)行模式等，即不完整的動(dòng)態(tài)測(cè)試。文獻(xiàn)[3]是從單元測(cè)試中動(dòng)態(tài)測(cè)試方法與規(guī)范方面引入，是一篇理論指導(dǎo)方面的論文，側(cè)重于動(dòng)態(tài)測(cè)試的闡述與分析，缺少在動(dòng)態(tài)情況下函數(shù)調(diào)用獨(dú)立運(yùn)行、靜態(tài)測(cè)試等在軟件測(cè)試中的問題解決方法與實(shí)際操作。文獻(xiàn)[4]采用底層模擬技術(shù)優(yōu)化了打樁技術(shù)，因?yàn)榇蟛糠周壍肋\(yùn)行的軟件都是嵌入式的，與電腦的操作系統(tǒng)不同，有著獨(dú)立的無法識(shí)別的函數(shù)，這個(gè)時(shí)候就需用打樁技術(shù)來解決，但又不是所有的函數(shù)都需要進(jìn)行，所以不具有普遍性。對(duì)比以上文獻(xiàn)中所提到的測(cè)試方法，本文所包含的測(cè)試方法更加全面，而對(duì)于檢測(cè)工具的合理使用也使測(cè)試效率大幅提升，也能更加直觀地發(fā)現(xiàn)未被覆蓋的代碼，便于測(cè)試人員以及開發(fā)人員后續(xù)修改和檢測(cè)?，F(xiàn)在還不存在一套對(duì)各類軟件都通用的測(cè)試方法和流程，所以本文旨在保證被測(cè)軟件正常運(yùn)行，研究和設(shè)計(jì)一套測(cè)試方法和測(cè)試流程，并完成對(duì)該軟件的單元代碼全面和嚴(yán)格的測(cè)試，保證軟件良好運(yùn)行。

2 軟件單元測(cè)試

2.1 單元測(cè)試原理

單元是由人指定要測(cè)試的最小的功能模塊。單元測(cè)試是軟件開發(fā)過程中最低層次的測(cè)試活動(dòng)。獨(dú)立的軟件單元將與程序的其他部分分開進(jìn)行測(cè)試。根據(jù)軟件源代碼程序和軟件設(shè)計(jì)說明書，了解輸入輸出范圍的功能限制和代碼邏輯原理，測(cè)試分析軟件編碼是否正確，并確定軟件界面和單元功能是否滿足軟件設(shè)計(jì)規(guī)范的要求。

2.2 單元測(cè)試方法

2.2.1 靜態(tài)測(cè)試

靜態(tài)測(cè)試指不需要軟件代碼運(yùn)行即可進(jìn)行的測(cè)試[5]?？捎脕頇z測(cè)軟件代碼的基本質(zhì)量，檢測(cè)是否存在簡(jiǎn)單錯(cuò)誤，包括定義的沖突或歧義，它進(jìn)一步測(cè)試的前提，可以為之后的測(cè)試排除基礎(chǔ)錯(cuò)誤，也可以檢測(cè)軟件代碼的完整性以及是否一致，代碼編寫是否符合規(guī)范[6]。

2.2.2 白盒測(cè)試

白盒測(cè)試又名邏輯驅(qū)動(dòng)測(cè)試，是一種對(duì)代碼結(jié)構(gòu)的測(cè)試，運(yùn)用白盒測(cè)試前需要了解代碼的邏輯以及代碼如何運(yùn)作，白盒法是窮舉路徑測(cè)試。

2.2.3 黑盒測(cè)試

黑盒測(cè)試是一種關(guān)注軟件外部結(jié)構(gòu)的測(cè)試，是將軟件代碼看做一個(gè)無法打開的黑盒子，不需要考慮內(nèi)部結(jié)構(gòu)，是一種主要面對(duì)軟件界面以及軟件功能的測(cè)試。

3 軌道交通車輛信號(hào)軟件單元測(cè)試

3.1 軌道交通車輛信號(hào)軟件單元測(cè)試基本要求

目前，軌道交通信號(hào)軟件測(cè)試的標(biāo)準(zhǔn)規(guī)范主要為ISO 29119-3《軟件測(cè)試國(guó)際標(biāo)準(zhǔn)》和MISRA-C：2004《Guidelines for the use of the C language in critical systems》等文件。

軌道交通信號(hào)軟件單元測(cè)試一般應(yīng)滿足以下要求：首先，要保證軟件的行為和性能滿足對(duì)應(yīng)測(cè)試規(guī)格的要求，軟件測(cè)試應(yīng)遵循先靜態(tài)再動(dòng)態(tài)的測(cè)試原則；其次，測(cè)試用例應(yīng)包含輸入、輸出2 部分，能驗(yàn)證函數(shù)的正確性，測(cè)試通過準(zhǔn)則為BUG 數(shù)等于0，對(duì)于錯(cuò)誤較多的函數(shù)，應(yīng)進(jìn)行多次測(cè)試；最后，組合條件覆蓋率應(yīng)達(dá)到100%，特殊情況下，組合覆蓋率不能達(dá)到100%，應(yīng)經(jīng)過人工驗(yàn)證代碼，并給出合理解釋和說明[7]。

根據(jù)認(rèn)證標(biāo)準(zhǔn)以及行業(yè)規(guī)范總結(jié)了以上要求，并以此作為測(cè)試規(guī)范。

3.2 軌道交通車輛信號(hào)軟件單元測(cè)試方法步驟

根據(jù)軟件測(cè)試的易錯(cuò)性和單一性，筆者們選擇C++Test 9.5 以及Keil uVision5 作為單元測(cè)試的工具。C++Test 是面向C 語言的單元測(cè)試工具，該軟件能夠自動(dòng)進(jìn)行白盒測(cè)試、黑盒測(cè)試和回歸測(cè)試。因此，該軟件可以高效完成對(duì)軟件的底層測(cè)試，能夠有效降低軟件錯(cuò)誤率，提升軟件運(yùn)行穩(wěn)定性。Keli uVsion5 主要用于嵌入式單片機(jī)編程。

4 車輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件單元測(cè)試過程

4.1 測(cè)試流程研究

設(shè)計(jì)針對(duì)被測(cè)軟件的測(cè)試方法和測(cè)試流程，并完成對(duì)被測(cè)軟件的具體測(cè)試。基本的軟件測(cè)試大致流程如圖2 所示。

圖2 軟件測(cè)試基本流程示意圖

代碼質(zhì)量測(cè)量、控制流、數(shù)據(jù)流和編碼規(guī)則檢查是通過C++測(cè)試、結(jié)合工具和手動(dòng)檢查完成的。采用人工方法分析編碼規(guī)范的一致性以及編碼與詳細(xì)設(shè)計(jì)的一致性。流程如下：首先對(duì)被測(cè)代碼進(jìn)行解讀，根據(jù)代碼的運(yùn)行流程與復(fù)雜程度從而制定相應(yīng)的檢查單，分為軟件分析與人工走查2 類，分別進(jìn)行測(cè)試，再將軟件測(cè)試中出現(xiàn)錯(cuò)誤的代碼進(jìn)行人工走查，人為修改約束條件，進(jìn)行針對(duì)性測(cè)試。

4.2 測(cè)試過程及結(jié)果

第一階段為基于C++Test 的軟件靜態(tài)分析。代碼質(zhì)量度量、控制流、數(shù)據(jù)流和編碼規(guī)則檢查是通過C++測(cè)試來執(zhí)行的。檢查內(nèi)容為MISRA-C：2004 規(guī)則、度量指標(biāo)規(guī)則、最優(yōu)化規(guī)則等規(guī)則，規(guī)則搭建方法如圖3所示，目的是找出欠缺和可疑之處，測(cè)試流程如圖4所示。結(jié)果將展示被測(cè)代碼中有多少行代碼違反了何種規(guī)則，測(cè)試結(jié)果如圖5 所示，并將靜態(tài)分析中產(chǎn)生的錯(cuò)誤整理出來，包括錯(cuò)誤代碼發(fā)生的位置及內(nèi)容。

圖3 靜態(tài)測(cè)試規(guī)則搭建

圖4 靜態(tài)測(cè)試流程

圖5 靜態(tài)測(cè)試結(jié)果

單元測(cè)試菜單如圖6 所示，在C++Test 任務(wù)欄里發(fā)現(xiàn)，有30 行代碼違反了規(guī)則，其中25 行代碼違反了MISRA-C： 2004 規(guī)則，3 行代碼違反了度量指標(biāo)規(guī)則，2 行代碼違反了最優(yōu)化規(guī)則。

圖6 單元測(cè)試菜單

第二階段為基于覆蓋率分析的白盒測(cè)試。通過分析測(cè)試系統(tǒng)軟件模塊內(nèi)部的路徑執(zhí)行和邏輯分支，選擇覆蓋分析的方法，使軟件的4 個(gè)覆蓋率達(dá)到100%。具體測(cè)試流程如下：建立單元測(cè)試、建立樁函數(shù)、收集樁函數(shù)信息、運(yùn)行單元測(cè)試。以上流程均由圖7 所示菜單完成，由測(cè)試結(jié)果可以得出被測(cè)代碼的各種覆蓋率。由此可以對(duì)代碼的質(zhì)量進(jìn)行分析，并判斷該代碼是否需要進(jìn)行人工走查。

圖7 單元測(cè)試結(jié)果（被測(cè)軟件覆蓋率）

第三階段為基于等價(jià)類和邊界值的黑盒測(cè)試。通過4 步完成黑盒測(cè)試：①明確函數(shù)代碼結(jié)構(gòu)中所包含的輸入、輸出變量，以及輸入輸出邊界值，如圖8 所示，分析輸入輸出判斷是否為無效等價(jià)類數(shù)據(jù)；②建立測(cè)試用例，需在測(cè)試工具中建立外部數(shù)據(jù)庫，手動(dòng)建立測(cè)試用例庫；③添加測(cè)試用例數(shù)據(jù)，同時(shí)，對(duì)函數(shù)內(nèi)部調(diào)用的其他函數(shù)進(jìn)行打樁處理，生成樁函數(shù)；④對(duì)樁函數(shù)輸入值進(jìn)行修改，以滿足軟件運(yùn)行需求，在樁函數(shù)與測(cè)試用例都無誤后，進(jìn)行測(cè)試。

圖8 函數(shù)代碼的輸入輸出值

5 結(jié)束語

目前，在軟件測(cè)試領(lǐng)域，單元測(cè)試的重要性正在被逐漸發(fā)現(xiàn)，但往往由于項(xiàng)目時(shí)間短、資金缺乏等原因?qū)е铝塑浖卧獪y(cè)試工作難以開展，測(cè)試質(zhì)量不能被保證。因此了解單元測(cè)試的優(yōu)點(diǎn)，并研究一種高效準(zhǔn)確的測(cè)試方法有著重要的意義。本文在理論方法的研究和實(shí)際軟件測(cè)試的基礎(chǔ)上，對(duì)軌道交通車輛信號(hào)軟件單元測(cè)試方法進(jìn)行了研究，并對(duì)系統(tǒng)中重要組成部分進(jìn)行測(cè)試與分析，能夠高效地找出軟件開發(fā)過程中存在的缺陷，并提醒開發(fā)人員及時(shí)糾正，確保軌道交通車輛信號(hào)軟件的穩(wěn)定性和可靠性，進(jìn)一步提高信號(hào)系統(tǒng)的安全性。