列控中心產品功能測試技術研究與應用

朱耘燕

(北京全路通信信號研究設計院集團有限公司，北京 100070)

1 概述

列控中心（Train Control Center，TCC）是CTCS-2和CTCS-3級列控系統的地面核心設備，列控中心根據其管轄范圍內聯鎖進路、軌道占用狀況（各列車位置）、以及臨時限速狀態等信息，向軌道電路發送編碼信息，向有源應答器發送報文信息，向列車傳輸運行許可，從而實現列車控制系統的功能[1]。

隨著我國鐵路建設事業的高速發展，TCC作為客運專線和高速鐵路列控系統地面信號控制的關鍵設施，為高速運行的列車提供了可靠的安全保證。在客運專線建設和既有線改造過程中，隨著站場類型的日益復雜、業主需求的不斷增加，既有的列控中心軟件已無法通過車站配置數據修改滿足全部需求，必須對軟件的實現邏輯進行修改和添加。

在軟件發布現場前，需要對列控中心進行嚴格的測試，包括產品功能測試（Product Function Test，PFT）、產品數據測試（Product Data Test，PDT）、系統測試（System Data Test，SDT）3個過程。PDT的側重點在于配置數據正確性的驗證，PFT的側重點在于驗證軟件功能修改的正確性，PFT的實質是根據開發階段的需求分析、詳細設計以及代碼結構，設計出全覆蓋軟件修改的測試用例，并按照測試用例驅動仿真/真實模擬測試環境中運行的列控軟件，觀察執行結果，分析可能出現的故障。通過代碼走查、功能測試，能很好的驗證列控軟件修改的正確性。

2 產品功能測試技術概述

列控中心設備適用于客運專線上的聯鎖車站、中繼站和線路所[1，2]，TCC接口配置如圖1所示。

TCC的設備接口組成如圖2所示。

列控軟件由基礎代碼和配置數據共同編譯生成，基礎代碼完成列控中心的基礎功能，配置數據用于適配各站的特殊站型、設備數量?；A代碼修改包括基礎代碼升級和工程變更，基礎代碼升級是定期維護并完善基礎代碼功能，不同站場的特殊需求由工程變更實現。產品功能測試針對基礎代碼修改，測試重點關注軟件功能修改，滿足以下要求：1）完成需求；2）不影響既有功能的實現；3）符合故障-安全原則。全覆蓋的功能測試對于驗證列控基礎代碼修改的正確性，提高列控中心應用軟件的可靠性有著非常重要的意義。

目前，列控中心數據測試的標準站場的標準功能部分已通過測試序列生成的方法實現自動測試。列控中心產品功能測試由于每次軟件功能修改不同的特殊性，由人工采用灰盒測試形成的一套驗證基礎代碼修改正確性的行之有效的測試方法?；液袦y試即結合黑盒測試和白盒測試對列控中心軟件修改功能進行驗證。軟件代碼走查和功能測試是列控中心產品功能測試的兩個重要組成部分。前者從代碼實現角度直接分析軟件修改的合理性，后者從功能實現角度間接驗證軟件修改的正確性和安全性。

列控中心產品功能測試不是一個線性工作流程，而是在上述工作中不斷循環，直至尋找到所有可發現的缺陷，并回歸測試驗證缺陷修復的正確性，其執行流程如圖3所示。

3 列控中心軟件代碼走查

白盒測試又稱基于代碼的測試。在TCC-PFT測試中的白盒測試主要對代碼進行邏輯覆蓋，針對不同的模塊分別采用語句覆蓋、判斷覆蓋和條件覆蓋[3]。

代碼走查，指開發測試人員針對軟件輸入，進行代碼人工走讀，從而發現缺陷的一種測試方法。代碼走查能充分發揮開發測試人員的主觀能動性，多方面綜合各種輸入，找到測試軟件無法發現的缺陷。

開發測試人員在代碼走查過程中，必須綜合考慮列控項目實施說明書、列控系統集成設計輸入審核單、列控軟件修改詳細設計等輸入，判斷走查的函數是否符合上述輸入的要求。代碼走查的特殊性，要求開發測試人員必須對《列控中心技術條件》和《信號安全系統C語言編寫規范》等原則有充分的理解，并且具備對復雜輸入進行分析、判斷、運行的能力，這也是代碼走查無法由軟件自動完成的直接原因。

列控中心的代碼走查，重點關注兩方面的內容：1）代碼符合語言編寫標準，無邏輯漏洞；2）代碼完成的功能符合設計輸入，無安全問題。當然，如果代碼走查的項目過多，會加重測試人員的工作負擔，以致無法凸顯代碼走查的優勢。為提高工作效率，在實際工作中不斷對走查項目進行刪減，最終形成的檢查項如表1所示。

表1 列控中心軟件走查檢查項Tab.1 Terms of TCC software walkthrough

實踐證明，運用表1的檢查項進行代碼走查，能有效發現列控中心軟件修改導致的缺陷。而且，代碼走查已成為最有效的缺陷發現方式。統計筆者一定工作時期內的缺陷發現量，代碼走查的缺陷發現量占比高達67.7%，如表2所示。

4 列控中心軟件功能測試

功能測試，指開發測試人員對修改后的列控中心軟件進行功能驗證，從而發現缺陷的一種測試方法。功能測試不僅局限于驗證修改需求是否得到滿足，更為重要的是確認軟件修改沒有引入新的問題，并且所做的軟件修改都符合故障-安全原則。

表2 列控中心軟件走查發現缺陷占比Tab.2 Percentage of defects detected by TCC software walkthrough

功能測試的測試環境包括列控中心仿真測試系統（Train Control Center Test，TCCT）[4]和 真實設備。列控中心仿真測試系統是針對客專列控中心接口開發的基于PC及Windows操作系統的列控中心軟件調試及測試平臺，實現列控中心對外通信接口單元和外部通信設備邏輯，以及列控中心主機單元設備的仿真[5]。真實設備指列控中心真實雙系主機，以及真實聯鎖、真實CTC、真實TSR等外部設備。

根據測試環境的搭建方法，列控中心軟件功能測試分為仿真功能測試和真實設備功能測試兩大類。兩類功能測試之間沒有明顯的使用界限。功能測試工作開展過程中，一般根據實際情況，是否涉及雙系、平臺交互等修改，選擇合適的測試方法。

4.1 測試方法概述

黑盒測試也稱功能測試,列控中心軟件黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法[6，7]。

當以上方法不能夠全覆蓋軟件修改時，通過代碼注入打樁，觸發被測語句，通過灰盒測試實現代碼修改的全覆蓋。

4.1.1 劃分等價類

常用的案例設計方法采用劃分等價類。等價類是指某個輸入域的子集合，在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的，并合理地假定：測試某等價類的代表值就等于對這一類其它值的測試。因此，可以把全部輸入數據合理劃分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據，取得較好的測試結果。等價類劃分可有兩種不同的情況：有效等價類和無效等價類。

例如區間改方相關功能測試。有效等價類有區間正方向、反方向和無方向的情況。無效等價類為各種組合條件不滿足時改方不成功。

4.1.2 邊界值分析

常用的邊界值分析是通過選擇等價類邊界的測試用例。邊界值分析法不僅重視輸入條件邊界，而且也必須考慮輸出域邊界。它是對等價類劃分方法的補充。長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤[6-8]。

以臨時限速覆蓋標志測試為例。分別選擇在臨時限速管轄范圍邊界上、邊界外1 m、邊界內1 m的限速，驗證跨邊界限速只有在起點反向覆蓋和終點正向覆蓋是能夠驗證并執行成功。

4.1.3 錯誤推測法

常用的錯誤推測法是基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。錯誤推測方法的基本思想：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例。

以網絡通信中斷案例為例。驗證當TCC和CBI、CTC、相鄰TCC、TSRS等外圍設備單、雙通道中斷時，能夠正確向集中監測輸出報警。

綜上，結合代碼走查，通過劃分等價類、邊界值分析、錯誤推測法對列控中心軟件修改進行驗證測試。例如對條件覆蓋，通過劃分等價類對代碼中的每一個條件語句進行功能覆蓋測試。例如對判定覆蓋，通過劃分等價類對代碼中的每一個判斷語句進行覆蓋測試，采用錯誤推測法對else的情況進行覆蓋測試。

4.2 測試環境搭建

4.2.1 全仿真功能測試

列控中心單主機仿真測試使用TCCT仿真軟件，在單臺仿真模擬機上運行，具體的實施方案如圖4所示。

4.2.2 真實設備功能測試

列控中心設備與外圍設備間連接方式、宕機重啟、中斷處理等修改需搭建真實環境，通過以太網、CAN通信數據包截取的方式確認設備間數據傳輸的正確性，保證列控中心軟件功能安全執行。真實環境搭建如圖5所示。

5 結論

列控中心產品功能測試，是列控中心軟件功能修改具備安全性、正確性、合理性的重要保障。作為獨立第三方參與軟件修改工作，產品功能測試人員有效發現軟件缺陷，為產品數據測試提供相對可靠的軟件輸入，并一定程度上提高了產品數據測試的工作效率。

隨著哈大、寧杭、向莆、成綿樂、鄭徐、云桂、淮蕭、石濟、白烏等客運專線的開通，列控中心產品功能測試已在實踐中證明其巨大的應用價值。

今后隨著測試技術的不斷提高，如測試案例庫的建立、標準站腳本自動測試技術的完善，列控中心產品功能測試一定能越來越高效地發現軟件缺陷，為列控中心設備的運行提供安全可靠的保證。