秦 昊,肖曼琳,王振宇,楊 霄,蔡燁玲
(上海工程技術(shù)大學(xué)城市軌道交通學(xué)院,上海 200000)
隨著中國(guó)城市化進(jìn)程的加快以及基礎(chǔ)設(shè)施建設(shè)的發(fā)展,城市軌道交通客運(yùn)里程以及客運(yùn)量不斷增加,保證城市軌道列車(chē)的安全運(yùn)行成為相關(guān)行業(yè)和社會(huì)越來(lái)越關(guān)注的任務(wù)。
目前,國(guó)內(nèi)大部分列車(chē)均搭載基于MVB 標(biāo)準(zhǔn)的網(wǎng)絡(luò)控制系統(tǒng),即實(shí)時(shí)采集列車(chē)運(yùn)行情況,并將這些信息通過(guò)MVB 網(wǎng)絡(luò)數(shù)據(jù)顯示出來(lái),并加以分析和處理,從而完成對(duì)車(chē)輛運(yùn)行系統(tǒng)的參數(shù)監(jiān)測(cè),并且最后通過(guò)上位機(jī)軟件,即車(chē)輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件,動(dòng)態(tài)顯示以告知司機(jī)列車(chē)當(dāng)前的各種狀態(tài)。車(chē)輛運(yùn)行系統(tǒng)參數(shù)監(jiān)測(cè)系統(tǒng)工作流程如圖1 所示。
圖1 車(chē)輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)工作流程示意圖
本文介紹了車(chē)輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件單元測(cè)試的方法以及研究過(guò)程,但是由于該軟件的功能單元數(shù)量巨大,并且每個(gè)單元中設(shè)計(jì)的函數(shù)運(yùn)算數(shù)量龐大、邏輯復(fù)雜,軟件工作時(shí)輸入信號(hào)多變,所以設(shè)計(jì)合理的軟件單元測(cè)試方法,完整并高效地完成功能單元測(cè)試,具有很強(qiáng)的軟件工程實(shí)踐意義。本文主要研究了車(chē)輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件單元測(cè)試的方法以及過(guò)程,其具體內(nèi)容安排如下:第1 節(jié)敘述了單元測(cè)試的背景,第2 節(jié)介紹了單元測(cè)試原理以及測(cè)試方法,第3節(jié)分析了軌道交通車(chē)輛信號(hào)軟件單元測(cè)試的基本要求并設(shè)計(jì)了測(cè)試步驟,第4 節(jié)展示了車(chē)輛運(yùn)行參數(shù)監(jiān)測(cè)系統(tǒng)軟件單元測(cè)試流程及測(cè)試結(jié)果,第5 節(jié)總結(jié)。
對(duì)自己書(shū)寫(xiě)代碼的檢測(cè)往往會(huì)被工程師忽視,且代碼檢測(cè)存在粗略、不規(guī)范等諸多特點(diǎn),如文獻(xiàn)[1]僅僅介紹了計(jì)算機(jī)軟件的黑盒測(cè)試這一種方法。在文獻(xiàn)[2]中采用了C++test 動(dòng)態(tài)測(cè)試來(lái)測(cè)試軟件函數(shù)運(yùn)行中存在的問(wèn)題,用函數(shù)覆蓋率體現(xiàn),具體點(diǎn)就是通過(guò)函數(shù)調(diào)用的檢測(cè)來(lái)快速準(zhǔn)確找到具體的問(wèn)題函數(shù),卻無(wú)法確定整體函數(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è)試中的問(wèn)題解決方法與實(shí)際操作。文獻(xiàn)[4]采用底層模擬技術(shù)優(yōu)化了打樁技術(shù),因?yàn)榇蟛糠周壍肋\(yùn)行的軟件都是嵌入式的,與電腦的操作系統(tǒng)不同,有著獨(dú)立的無(wú)法識(shí)別的函數(shù),這個(gè)時(shí)候就需用打樁技術(shù)來(lái)解決,但又不是所有的函數(shù)都需要進(jìn)行,所以不具有普遍性。對(duì)比以上文獻(xiàn)中所提到的測(cè)試方法,本文所包含的測(cè)試方法更加全面,而對(duì)于檢測(cè)工具的合理使用也使測(cè)試效率大幅提升,也能更加直觀地發(fā)現(xiàn)未被覆蓋的代碼,便于測(cè)試人員以及開(kāi)發(fā)人員后續(xù)修改和檢測(cè)?,F(xiàn)在還不存在一套對(duì)各類軟件都通用的測(cè)試方法和流程,所以本文旨在保證被測(cè)軟件正常運(yùn)行,研究和設(shè)計(jì)一套測(cè)試方法和測(cè)試流程,并完成對(duì)該軟件的單元代碼全面和嚴(yán)格的測(cè)試,保證軟件良好運(yùn)行。
單元是由人指定要測(cè)試的最小的功能模塊。單元測(cè)試是軟件開(kāi)發(fā)過(guò)程中最低層次的測(cè)試活動(dòng)。獨(dú)立的軟件單元將與程序的其他部分分開(kāi)進(jìn)行測(cè)試。根據(jù)軟件源代碼程序和軟件設(shè)計(jì)說(shuō)明書(shū),了解輸入輸出范圍的功能限制和代碼邏輯原理,測(cè)試分析軟件編碼是否正確,并確定軟件界面和單元功能是否滿足軟件設(shè)計(jì)規(guī)范的要求。
2.2.1 靜態(tài)測(cè)試
靜態(tài)測(cè)試指不需要軟件代碼運(yùn)行即可進(jìn)行的測(cè)試[5]。可用來(lái)檢測(cè)軟件代碼的基本質(zhì)量,檢測(cè)是否存在簡(jiǎn)單錯(cuò)誤,包括定義的沖突或歧義,它進(jìn)一步測(cè)試的前提,可以為之后的測(cè)試排除基礎(chǔ)錯(cuò)誤,也可以檢測(cè)軟件代碼的完整性以及是否一致,代碼編寫(xiě)是否符合規(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è)無(wú)法打開(kāi)的黑盒子,不需要考慮內(nèi)部結(jié)構(gòu),是一種主要面對(duì)軟件界面以及軟件功能的測(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è)試通過(guò)準(zhǔn)則為BUG 數(shù)等于0,對(duì)于錯(cuò)誤較多的函數(shù),應(yīng)進(jìn)行多次測(cè)試;最后,組合條件覆蓋率應(yīng)達(dá)到100%,特殊情況下,組合覆蓋率不能達(dá)到100%,應(yīng)經(jīng)過(guò)人工驗(yàn)證代碼,并給出合理解釋和說(shuō)明[7]。
根據(jù)認(rèn)證標(biāo)準(zhǔn)以及行業(yè)規(guī)范總結(jié)了以上要求,并以此作為測(cè)試規(guī)范。
根據(jù)軟件測(cè)試的易錯(cuò)性和單一性,筆者們選擇C++Test 9.5 以及Keil uVision5 作為單元測(cè)試的工具。C++Test 是面向C 語(yǔ)言的單元測(cè)試工具,該軟件能夠自動(dòng)進(jìn)行白盒測(cè)試、黑盒測(cè)試和回歸測(cè)試。因此,該軟件可以高效完成對(duì)軟件的底層測(cè)試,能夠有效降低軟件錯(cuò)誤率,提升軟件運(yùn)行穩(wěn)定性。Keli uVsion5 主要用于嵌入式單片機(jī)編程。
設(shè)計(jì)針對(duì)被測(cè)軟件的測(cè)試方法和測(cè)試流程,并完成對(duì)被測(cè)軟件的具體測(cè)試?;镜能浖y(cè)試大致流程如圖2 所示。
圖2 軟件測(cè)試基本流程示意圖
代碼質(zhì)量測(cè)量、控制流、數(shù)據(jù)流和編碼規(guī)則檢查是通過(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è)試。
第一階段為基于C++Test 的軟件靜態(tài)分析。代碼質(zhì)量度量、控制流、數(shù)據(jù)流和編碼規(guī)則檢查是通過(guò)C++測(cè)試來(lái)執(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ò)誤整理出來(lái),包括錯(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è)試。通過(guò)分析測(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è)試。通過(guò)4 步完成黑盒測(cè)試:①明確函數(shù)代碼結(jié)構(gòu)中所包含的輸入、輸出變量,以及輸入輸出邊界值,如圖8 所示,分析輸入輸出判斷是否為無(wú)效等價(jià)類數(shù)據(jù);②建立測(cè)試用例,需在測(cè)試工具中建立外部數(shù)據(jù)庫(kù),手動(dòng)建立測(cè)試用例庫(kù);③添加測(cè)試用例數(shù)據(jù),同時(shí),對(duì)函數(shù)內(nèi)部調(diào)用的其他函數(shù)進(jìn)行打樁處理,生成樁函數(shù);④對(duì)樁函數(shù)輸入值進(jìn)行修改,以滿足軟件運(yùn)行需求,在樁函數(shù)與測(cè)試用例都無(wú)誤后,進(jìn)行測(cè)試。
圖8 函數(shù)代碼的輸入輸出值
目前,在軟件測(cè)試領(lǐng)域,單元測(cè)試的重要性正在被逐漸發(fā)現(xiàn),但往往由于項(xiàng)目時(shí)間短、資金缺乏等原因?qū)е铝塑浖卧獪y(cè)試工作難以開(kāi)展,測(cè)試質(zhì)量不能被保證。因此了解單元測(cè)試的優(yōu)點(diǎn),并研究一種高效準(zhǔn)確的測(cè)試方法有著重要的意義。本文在理論方法的研究和實(shí)際軟件測(cè)試的基礎(chǔ)上,對(duì)軌道交通車(chē)輛信號(hào)軟件單元測(cè)試方法進(jìn)行了研究,并對(duì)系統(tǒng)中重要組成部分進(jìn)行測(cè)試與分析,能夠高效地找出軟件開(kāi)發(fā)過(guò)程中存在的缺陷,并提醒開(kāi)發(fā)人員及時(shí)糾正,確保軌道交通車(chē)輛信號(hào)軟件的穩(wěn)定性和可靠性,進(jìn)一步提高信號(hào)系統(tǒng)的安全性。