基于VectorCAST平臺的鐵路信號軟件動態測試方法

武中奇，趙雅囡，李鳳嬌

(北京和利時系統工程有限公司，北京,100176)

1 鐵路信號安全軟件測試覆蓋率的要求

隨著中國高速鐵路的迅速發展，鐵路信號控制系統的自動化程度和復雜程度也成倍增長。其中，對鐵路信號安全相關軟件的質量屬性提出了更高要求。除了滿足功能性、可靠性、易用性、效率、可維護性、可移植性等要求外，特別強調軟件安全完整性的特有屬性。軟件測試是保證這些屬性得到實現的重要手段。對不同安全完整性等級（SIL）要求的鐵路信號系統軟件，其代碼測試覆蓋率及類型有不同的要求。SIL1/2等級的軟件要求做語句覆蓋（Statement），SIL3等級的軟件要求做語句+分支覆蓋（Statement + Branch），SIL4等級的軟件要求做語句+修正條件判定覆蓋（Statement+MC/DC）。《鐵路信號安全軟件測試暫行技術要求》（TJ/DW 231-2020）中對需達到SIL4級安全產品軟件測試覆蓋率的要求：

(1)軟件源代碼的每條語句都被至少一個測試用例覆蓋，語句100%覆蓋；

(2)軟件源代碼的每個分支都被至少一個測試用例覆蓋，分支100%覆蓋；

(3)軟件源代碼的每個分支的每個條件都被獨立起作用的測試用例覆蓋，即MC/DC100%覆蓋。

通常的覆蓋率統計在單元測試中完成，例如使用C++TEST工具進行單元測試，得到該單元的覆蓋率。不同單元的測試覆蓋率數據綜合在一起，得到系統軟件的總體覆蓋率。但是單元測試不同于系統動態測試，模塊的接口和行為在系統功能中的表現不同于其單獨作為被測對象的表現。例如，該模塊在當前系統功能的測試用例中不會被調用到，或者其中部分分支由于條件不具備而無法執行到。出現此類情況的可能原因包括：

(1)該模塊執行了非預期的行為或者與軟件功能需求規格書的要求不一致。

(2)測試案例設計不夠充分，沒能覆蓋到該模塊。

(3)測試環境或條件限制當前模塊被調用。

與之對應的解決方法是：

(1)該模塊是非必要的，因而刪除。

(2)分析該模塊的功能和接口，豐富動態測試用例集，使其得到完全執行。

(3)基于分析的測試可以作為對測試用例無法執行到的模塊代碼覆蓋率的補充。

單元測試無法判斷在系統動態測試過程中某個特定模塊的執行情況，因而無從判斷該模塊語句覆蓋率、分支覆蓋率以及MC/DC代碼覆蓋率的具體度量數值。這里，引入一種自動測試的工具-VectorCAST，是由第三方開發的商用自動測試平臺。它可以執行單元測試，亦可對動態測試的代碼覆蓋率進行分析和統計（QA）。支持的測試覆蓋類型包括語句覆蓋，語句+分支覆蓋，語句+MC/DC覆蓋，函數覆蓋，函數調用覆蓋，代碼執行路徑覆蓋等。

2 VectorCAST QA（以下簡稱VCAST QA）應用方法

VCAST QA對軟件的測試覆蓋率度量有很好的支持，主要包括的測試覆蓋率類型有：

(1)語句覆蓋（Statement）：用于描述特定動態測試用例運行時每個可執行語句占整個單元語句總數的比例。

(2)分支覆蓋（Branch）：用于描述特定動態測試用例運行時每個可執行分支占整個單元分支總數的比例。

(3)函數覆蓋（Function）：用于描述特定動態測試用例運行時所執行到的函數。

(4)修正條件判定覆蓋(MC/DC，Modified Condition/Decision Coverage)：一個MC/DC對是一對真值向量，這對真值向量使得判定語句有不同的結果，但結果的不同是由于真值向量中一個條件值的變化引起的。

另外還包括由以上覆蓋類型組合而成的覆蓋類型，這些組合覆蓋類型的執行結果會統一合成在一份測試報告中。主要的組合覆蓋類型有：

(5)函數+函數調用覆蓋（Function + Function Call）。

(6)語句 +MC/DC覆蓋（Statement + MC/DC）。

(7)語句+分支覆蓋（Statement + Branch）。

通常的動態測試對語句執行覆蓋率以及函數調用情況很難做出定量的描述，更為困難的是對MC/DC覆蓋率有要求的系統動態測試，尤其難以測量。這是因為對于具有 N 個條件的布爾表達式，其完備的測試用例有2N組。很難針對具體的條件判定設計出符合MC/DC要求的100%代碼覆蓋率的測試用例集。即便設計出來，執行成本也會很大。VCAST QA提供了一種可行的方法，在軟件系統動態集成測試中同步統計MC/DC測試覆蓋率，進而分析沒有達到100%MC/DC代碼覆蓋率是由于什么原因導致的。根據經驗，可能的原因包括但不限于：

(1)動態測試用例集不完備。

(2)當前的測試環境受限導致無法執行到相應的真值對。

第2）種情況可以使用基于分析的測試（CBA）作為動態測試的補充實現MC/DC100%覆蓋率。

通過VCAST QA分析系統動態測試覆蓋率，首先需要對被測軟件做一系列預處理。被測軟件可以是嵌入式軟件，也可以是運行在Windows系統的上位機軟件。一致的處理流程大致可以概括為：

(1)在VCAST QA環境中新建工程。

(2)對新建的工程進行適當地配置，例如選擇編譯器、選擇嵌入式CPU類型（Windows程序無需做此操作）等。

(3)加載被測源代碼文件。

(4)對源文件進行插樁，插樁指以某種測試覆蓋率類型對源文件進行預處理，但不會影響源文件的內部邏輯。插樁會導致源文件發生膨脹，這對內存較小的嵌入式軟件會有較大影響，甚至導致編譯后的可執行程序無法燒寫進目標板。并且插樁后的源文件由于增加了VCAST QA的附加代碼，可能會影響到嵌入式軟件的時序。因此，對嵌入式軟件進行插樁處理時要綜合考慮哪些代碼需要插樁。例如對變更的代碼進行插樁會顯著減小代碼的膨脹率。需要說明的是對于嵌入式軟件插樁后的源代碼應進行處理。不同于Windows軟件，動態測試結果數據可以自動保存在被測軟件的工程目錄下。嵌入式軟件則需要修改部分源代碼。目的是在特定時刻或條件下，利用嵌入式目標板的對外接口，例如串口或者網口，將內存區域內VCAST QA數據發送到PC機接收端，接收方式可以是超級終端或者Wireshark等。如果嵌入式系統有記錄卡，也可將VCAST QA數據存放在記錄卡內，通過讀卡器讀取。

(5)對經過插樁的源代碼進行編譯，運行，采集輸出數據并存儲為*.DAT格式。

(6)將*.DAT數據導入到VCAST QA環境中，觀察并分析系統動態測試代碼覆蓋率。

3 VCAST QA應用舉例（以Windows環境中C++程序為例）

對C++例程進行Function + Function Call插樁和Statement + MC/DC插樁，并對結果進行分析。

3.1 例程進行Function+Function Call插樁后用例動態測試的運行結果

圖1說明：

圖1 運行結果

(1)Unit顯示了被測文件的名稱，本例為brass.cpp。

(2)Subprogram列舉本文件的所有函數模塊。

(3)Complexity顯示了對應模塊的代碼復雜度。

(4)Functions顯示了函數被調用的狀態，100%為被調用，0%為未被調用。

(5)Function Calls顯示了特定函數被執行的語句數量占該函數可執行語句總數的比例。例如BrassPluss::withdraw函數的執行比例是85%，14條可執行語句中2條未被執行。

(6)TOTALS是對總體的統計，Functions列90%是由于BrassPluss類的另一個重載構造函數未被執行導致。

函數及函數調用覆蓋率統計可以顯示某個文件中函數被執行的情況。實際系統動態測試中，關注的焦點是軟件功能是否滿足系統功能需求規格說明書，發現并消除軟件BUG，以證明軟件產品是否具備發布條件。而往往忽視了代碼的簡潔，模塊功能的安全防護，是否能被執行到等維度。Function+Function Call覆蓋率對此問題進行了定量描述，為代碼優化指明了方向。體現在：

(1)動態執行全部測試用例集后分析哪些函數未被執行到。若此函數對應了軟件需求規格說明書，則說明測試用例集不夠完備，需補充。若此函數未對應軟件需求功能規格說明書，也未對應軟件隱含需求，此函數需刪除。

(2)由于鐵路信號軟件的高度復用性，通用模塊經常對應于實際運營場景中的某種邏輯場景。若沒被用例集執行到，則可反推軟件設計規格說明書對軟件功能描述是否有遺漏，即作為驗證軟件設計規格說明書的一種方法。

3.2 例程進行Statement+MC/DC插樁以及CBA分析后，用例動態測試的運行結果

圖2說明(圖1介紹過的內容不再重復)：

圖2 運行結果

(1)Statements列顯示了對應函數模塊被執行語句占該函數可執行語句的比例。Brass::Withdraw方法的可執行語句為7條，且全部被執行。覆蓋率為100%。

(2)Branches列顯示了被執行到的分支占該函數總分支數的比例。

(3)Pairs列顯示了MC/DC真值對的統計描述，點擊圖3第32行左側的紅色箭頭，出現如圖4的界面。

圖3

圖4

圖4顯示了圖3條件判定3.1中所有的MC/DC真值對，其中3、4真值對被測試用例執行，未被執行的真值對是2、4。因而MC/DC覆蓋率是50%。

3.3 基于分析的用例覆蓋(Covered By Analysis(CBA))

圖4中Row 2紅色表示Ca條件沒有被執行到，由于例程中實際變量amt取值不可能為負數，因而這個條件不會被執行到。CBA提供一種基于分析的測試，作為測試覆蓋率的補充。若經人工確認此條件為真時，函數的行為符合預期，則認為這個測試通過。CBA執行結果如圖5所示。此時真值對的覆蓋率是100%。圖6展示了結合CBA結論的測試覆蓋率報告。

圖5

圖6

Statement+MC/DC測試實現100%覆蓋，是安全級軟件產品滿足SIL4要求的必要條件。實際動態測試中，動態測試用例集執行往往以黑盒測試的方式的為主，關注軟件功能的實現以及軟件缺陷的消除。沒有有效途徑深入軟件結構內部分析軟件動態執行的情況。VCAST QA提供了這樣一種有效方法。通過對源代碼進行插樁，實現對軟件結構內部執行情況的追蹤和測量。用于幫助開發和測試人員分析：

(1)哪些語句沒有執行到，原因是什么，進而采取相應措施。

(2)哪些分支沒有執行到，這些分支是否存在執行到的可能？若有可能被執行到，則通過豐富用例集或借助CBA進行補充測試。若任何場景都無法執行到，則此分支屬于無用代碼，應予以刪除，以減小軟件規模。

(3)哪些MC/DC真值對沒有被執行到，這些真值對是否存在執行到的可能？分析過程同2)。

(4)Statement+MC/DC測試是優化軟件系統的重要手段。尤其對于嵌入式系統，目標板資源有限，精簡后的軟件代碼執行效率更高，安全性和可靠性可得到進一步提升。

4 總結

VCAST QA是鐵路信號系統軟件集成測試代碼覆蓋率測量的有效工具，對動態測試用例的完備性提供了間接的量化描述。同時，也為代碼的復雜程度及有效性評估提供了重要依據，尤其適合在Windows環境中運行的C或者C++程序。對于嵌入式軟件，由于目標板資源的限制，需要綜合考慮代碼插樁的類型以及被插樁代碼的數量，防治插樁后的代碼因體量太大而無法燒寫進目標板的情況出現或者嚴重影響到目標程序的執行效率。