★北京廣利核系統工程有限公司張海濱，高慶怡，黃太新，孔艷

關鍵詞：核安全重要軟件；單元測試；單元測試對象

軟件單元測試在源代碼級采用“X光”的方式測試代碼，可以發現深層次的軟件缺陷，是保障軟件產品質量的重要驗證活動。核電屬于高安全領域，核安全重要儀控系統中的軟件（以下簡稱核安全重要軟件）不僅要實現軟件需求文檔的規定，而且要符合法規標準對軟件的要求。核電相關標準都提出了對軟件開展驗證與確認（V&V）的要求，其中軟件單元測試是軟件V&V活動的重要組成部分，但對“單元”大小的定義及單元測試要求各標準描述不一致。

美國核管會（NRC）在導則RG1.168-2013認可的IEEE1012-2004中使用了術語“componenttest”，即component是“組成系統的部件，可以是硬件或軟件也可以細分為其他組件”，并進一步說明了組件測試要確認軟件組件正確實現了組件要求^[1]。NRC通過導則RG1.171-2013認可的IEEE1008-1987（R2002）闡述了對單元測試的要求，其中明確了unit是一個包括一個或多個計算機程序模塊及相應控制數據（例如表格）、使用規程、操作規程的模塊集合^[2]，同時RG1.171-2013要求單元測試需滿足安全功能要求覆蓋和模塊結構覆蓋^[3]。歐洲核標準IEC60880-2006要求模塊驗證應該表明每個模塊執行其預期功能，不執行非預期功能^[4]，但未給出模塊module的具體定義。國內能源行業標準“NB/T20054-2011核電廠安全重要儀表和控制系統執行A類功能的計算機軟件”由IEC60880轉化而來，兩者要求相同。

“component”“unit”“module”各標準使用不同的“單元”術語定義，目前國際上尚未統一。各標準也提出了對軟件單元測試的要求，本文認為RG1.171-2013高度概括了所有核標準對軟件單元測試的要求，即滿足安全功能要求覆蓋和模塊結構覆蓋^[3]。安全功能要求覆蓋是指必須全面驗證所有與核安全相關的功能需求，確保其在設計基準事故、預計運行事件及極端工況等情況下的正確執行，故在軟件單元測試中需要針對安全功能完整性、邊界條件、失效模式覆蓋等開展測試。模塊結構覆蓋要求軟件模塊化設計滿足功能內聚性、低耦合性、層次化架構的原則，在測試開展中需要針對模塊接口、控制流覆蓋、數據流覆蓋進行測試。

因標準要求較為概括，通常國內核行業軟件測試參考“GB/T15532-2008,計算機軟件測試規范”中對單元測試的要求開展核安全重要軟件單元測試活動。GB/T15532-2008規定軟件單元測試的對象是可獨立編譯和匯編的程序模塊（或稱為軟件構件或面向對象設計中的類）^[5]。軟件單元測試的目的是檢查每個軟件單元能否正確實現設計說明中的功能、性能、接口和其他設計約束等要求，發現單元內可能存在的各種差錯^[4]，并且在其技術要求中提出了對軟件結構覆蓋（如分支覆蓋100%）的要求。

1　核安全重要軟件單元測試現狀

1.1　單元測試常規方法

國內核行業綜合考慮RG1.168-2013（認可IEEE1012-2004）、RG1.171-2013（認可IEEE1008-1987）、IEC60880-2006（等同NB/T20054-2011）的要求，參考中國軟件行業推薦標準GB/T15532-2008，通常把標準中提到的不同術語的“單元”解讀為“函數”（因函數是軟件模塊代碼實現的最小粒度對象），并基于“函數”開展單元測試活動。

圖1軟件模塊組成

一個完整的計算機程序通常由多個程序功能模塊組成，每一個可獨立編譯的程序功能模塊又通常由多個函數組成。某個功能模塊示意圖如圖1所示，其中包括函數f1（）～f11（）。

按照國內核安全重要軟件測試領域基于“函數”的單元測試方法，當需要對該程序功能模塊開展單元測試時，通常會把該程序模塊拆分成一個個獨立的函數，根據詳細設計文檔設計測試用例、執行動態單元測試。例如對圖1所示程序結構中要測試的指定函數f3（），創建驅動單元（driver）以調用函數f3（），對被f3（）調用的函數f6（）、f7（），用樁函數（stub）替換，如圖2所示。

圖2軟件單元測試方法

核安全重要軟件基本上都運行在現場控制設備中，是嵌入式軟件；軟件單元測試依據軟件詳細設計文檔設計測試用例，在測試工具輔助下在主機上以仿真方式開展測試，其過程是通過分析被測試程序源代碼，對被測試程序源代碼進行插裝，即插入收集控制流和數據流信息的探針代碼。使用軟件單元測試工具自動生成驅動函數和樁函數，根據執行測試用例的需要修改和補充測試驅動代碼和樁代碼，之后調試并仿真運行測試代碼。在驅動函數和樁函數的配合下對被測試函數進行測試時探針代碼被執行，探針代碼通過某種方式輸出測試結果和測試覆蓋率信息。最后，通過界面把測試結果及代碼覆蓋情況呈現給測試人員，測試人員根據覆蓋情況補充測試用例滿足測試完備性和充分性要求，即達到要求的測試覆蓋率。

使用該方法的優點是不受硬件的約束和限制，因為以單個獨立的函數為對象，被測試函數里的幾乎所有被調用函數都被打樁了，所以容易通過分析代碼的處理邏輯，滿足判定、條件為真為假的情況，從而達到高的結構測試覆蓋率。1.2　單元測試常規方法的不足（1）測試工作量大常規方法對單個函數開展軟件單元測試，需要花費大量的時間編寫調試測試代碼以完成單元測試，有時測試代碼量會數倍于被測試代碼，測試工作量大。（2）易導致片面追求高的結構覆蓋率常規軟件單元測試方法以達到具體的覆蓋率為結束條件（比如100%MC/DC），以函數為對象較容易達到覆蓋率要求，結果造成部分測試人員認為函數覆蓋率達到了單元測試就完成了，軟件單元測試就是覆蓋率測試；其實，單個函數雖然達到了較高的覆蓋率，但安全功能要求、邏輯實現仍可能存在缺陷。（3）難以全面覆蓋真實用戶場景樁函數是人為定義的，其函數返回值具有極強的目的性和針對性。常規軟件單元測試時通過封裝的樁函數返回預先定義的特定值來驗證被測函數是否執行目標分支，這雖然能有效驗證被測函數代碼邏輯中路徑分支的正確性，但人工模擬的方法難以全面覆蓋真實用戶應用場景下的各類復雜情況。

2　核安全重要軟件單元測試新方法

2.1　基本原理

本單元測試方法以獨立編譯的程序功能模塊為單元測試對象，對其不再拆分成單個的函數，而是使用單元測試工具對整個程序模塊插裝（instrument，即插入探針），然后對插入探針后的代碼編譯成為測試可執行程序，通過在真實環境中整體運行可執行程序，執行測試用例生成測試結果記錄和覆蓋率數據，然后通過查看代碼覆蓋情況補充測試用例完善測試，從實際用戶使用的角度測試功能模塊，在單元測試階段關注安全功能要求的驗證，暴露實際使用中可能存在的問題，可以在測試的早期階段提高軟件質量，減少缺陷遺留。

2.2　測試用例設計過程

遵循以上原理，為滿足安全功能要求覆蓋和結構覆蓋，本方法測試用例設計過程與常規方法略有不同，分三步完成：

（1）首先，根據模塊的安全功能要求設計測試用例。

（2）其次，根據設計文檔中的設計細節補充基于設計的測試用例。

（3）最后，執行測試用例，根據測試覆蓋情況，參考代碼實現補充測試用例。

安全功能要求是代碼實現的依據，根據模塊安全功能要求設計的測試用例能夠覆蓋大部分代碼，可以確保軟件實現滿足對模塊的安全功能要求，避免設計和實現問題導致的副作用，并通過三步的測試用例設計與完善過程保證測試的充分性和完備性，這也是NRC認可的IEEE1008的附錄B所建議的測試的增量式測試用例設計方法。

2.3　實施過程

本單元測試方法具體實施過程如圖3所示。

圖3 單元測試過程

本方法與常規方法的不同之處是，使用軟件單元測試工具分析被測試程序源代碼完成“代碼插裝”后，直接把包含探針信息的源代碼編譯“生成測試可執行程序”，以正常使用該功能模塊的方式運行程序“執行測試用例”，即從該程序模塊的外部接口進行測試數據的輸入輸出，以整體的方式開展測試活動。因為源代碼是經過插裝處理的，所以測試執行過程中探針代碼就會把測試結果和覆蓋信息輸出。當測試用例執行完畢后使用單元測試工具分析測試結果和覆蓋率信息，“查看覆蓋率”判斷覆蓋率是否滿足要求，如果發現代碼覆蓋率不滿足要求，則分析代碼沒有覆蓋的原因，然后補充相應的測試用例，直到達到要求的覆蓋率。可見覆蓋率只是測試充分性和完備性的指示器，并不是直接測試目標和目的。

2.4　新方法的優勢

（1）真實驗證模塊安全功能要求

軟件功能模塊是作為有機整體對外交互的，不再是單個的孤立函數，是功能模塊使用時的真實應用場景，測試的是功能模塊的真實功能、性能等特性，從而能發現真實使用時可能出現的絕大多數缺陷。

（2）覆蓋真實的調用接口

當以整個功能模塊為單元測試對象，軟件單元測試時就會覆蓋代碼原有的真實函數調用關系，減少接口問題的遺留。

（3）減少了測試工作量

因以整體的方式開展測試用例的設計和執行，執行頂層函數的一個用例就能覆蓋其下層多個被調用函數，在保證測試覆蓋的條件下，減少了測試用例的數量，而且以真實使用模塊的方式進行輸入輸出，節省了大部分的測試代碼編寫、調試的工作，提高了測試工作效率。

（4）促進測試過程優化

當單元測試的粒度擴大后，可以探索把單元測試和集成測試，甚至產品確認測試（配置項測試）進行合并融合。尤其是對單一組件或組件較少的程序模塊，可在一個測試階段中完成多個階段的動態測試工作，促進測試過程的優化。

該方法以比函數更大的功能模塊為單元測試對象，在目標機上運行，能夠完整覆蓋所有的功能、性能等特性要求，滿足安全功能要求覆蓋和模塊結構覆蓋要求。當函數調用層次較多時，分析覆蓋底層函數的難度提高，底層函數達到的最終結構覆蓋率可能不及以單個函數為對象時高，但這是模塊實際使用時真實能達到的結構覆蓋率，更能反映實際運行中可能出現的情況，單元測試更有實際意義。

3　方法實驗

以一個在QNX6.5操作系統下運行的示例程序模塊為例進行說明，該程序完成根據輸入的命令類型進行不同數據處理的功能，示例程序的調用結構如圖4所示。

圖4實驗程序示意圖

根據單元測試需要設計的試驗環境如圖5所示。

圖5實驗環境配置圖

使用軟件單元測試工具插入探針后，可通過某種方式輸出測試結果和測試覆蓋率信息，比如通過網絡、串口等通信方式或者記錄并輸出到特定的文件中。本實驗設置把測試執行結果信息和覆蓋率信息輸出到文件中。

建立上圖所示的虛擬主機和虛擬目標機，主機使用Momentics4.7加上單元測試工具C++TestV9.6插件版，對C++Test的測試配置“Build test executable”腳本進行修改讓其只生成插入探針后的測試可執行程序，通過測試配置生成測試可執行文件，然后復制測試可執行文件到QNX6.5的目標機上運行，給可執行程序不同的輸入以測試不同情況并核對結果正確性。用例執行完畢停止程序運行后，把測試可執行程序生成的測試結果記錄文件cpptest_results.tlog和覆蓋率結果文件cpptest_results.clog放到C++Test工具指定的目錄下，使用C++TestV9.6自帶的“Load Test Results（Files）”工具菜單成功獲取到了代碼執行的覆蓋率，可見該方法是有效可行的。

在真實環境中運行插入探針后的可執行程序，不斷迭代查看代碼覆蓋情況補充測試用例完善測試這一過程，觀察覆蓋率輸出值，發現覆蓋率的增長逐漸趨于一穩定值但無法達到100%。經分析得出，由于不同軟件的需求、設計、實現方式不同，可能存在部分軟件功能無法從真實場景中制造的情況，使得軟件運行始終無法觸發某些代碼，導致覆蓋率穩定在某個非100%的值。這也表明該方法還存在一定局限性。

4　結論

本文以多函數組成的程序功能模塊為軟件單元測試的對象，基于模塊安全功能要求和設計要求，參考代碼實現設計測試用例，對代碼插裝編譯成為測試可執行程序，在真實目標環境中驗證功能模塊滿足核安全重要軟件安全功能要求和結構覆蓋要求，既降低了常規方法以函數為對象的軟件單元測試的工作量，又以用戶使用模塊的角度真實驗證了模塊的安全功能和內部接口，從而提高了單元測試的價值，并提出了對單元測試和集成測試，甚至產品確認測試（配置項測試）進行融合的可能性，為優化軟件測試過程提供了思路。

在測試工具C++Test的支持下，本文對單元測試新方法的可行性進行了實驗，對無操作系統的軟件的單元測試的適用性需要進一步研究；同時需要進一步研究使用專門的測試工具改進插裝和讀取覆蓋率的便利性，以提高整個單元測試過程的自動化程度。

本文還提出了單元測試新方法存在的局限性，對于軟件功能無法從真實場景制造的情況，會導致插入探針后代碼覆蓋率始終達不到100%。這也為后續研究提供了方向，研究人員將進一步研究解決特殊功能場景無法從真實環境制造導致代碼覆蓋率無法實現100%的問題，如開展采用新方法與傳統方法相結合的可行性評估、結合指標的研究等，以進一步提高單元測試新方法的適用范圍。

作者簡介：

張海濱（1974-），男，河南開封人，工程師，碩士，現就職于北京廣利核系統工程有限公司，主要從事核電儀控系統軟件測試驗證、軟件質量評價工作。

參考文獻：

[1] IEEE1012-2004, IEEE standard for software verification and validation[S].

[2] IEEE1008-1987(R2002), IEEE standard for software unit testing[S].

[3] RG1.171-2013, Software unit testing for digital computer software used in safety systems of nuclear power plants[S].

[4] IEC60880-2006, Nuclear power plants-Instrumentation and control systems important to safety-Software aspects for computerbased systems performing category A functions[S].

[5] GB/T15532-2008, 計算機軟件測試規范[S].

摘自《自動化博覽》2025年10月刊