劉振玉 任 軍
(北京全路通信信號研究設計院集團有限公司,北京 100073)
RSSP-II安全通信協議軟件的自動測試設計及實現
劉振玉 任 軍
(北京全路通信信號研究設計院集團有限公司,北京 100073)
RSSP-II安全通信協議軟件是鐵路通信領域安全產品,其軟件功能測試采用SDP專項測試工具實現自動化測試,從而提高了測試效率和測試規范性。提出RSSP-II軟件自動化測試框架,通過測試引擎和腳本的聯合設計來實現測試過程中的錯誤注入,對軟件產品進行了多輪次自動化測試,并將專項測試工具推廣應用于半實物軟硬件集成測試。
RSSP-II測試;錯誤注入;引擎和腳本聯合設計;半實物軟硬件集成測試
RSSP-II安全通信協議(UNISIG subset-098),作為適用于封閉傳輸系統和開放傳輸系統的基于以太網通信的安全通信傳輸協議,可廣泛應用于高速鐵路、城際鐵路、城市軌道交通信號控制系統中[1,2]。RSSP-II安全通信協議是SIL4級[3]安全軟件產品,定義為一套跨平臺、可移植、能實現RSSP-II安全通信協議功能的軟件功能庫,其功能測試是確認軟件滿足功能需求,具有足夠安全防護能力的重要手段[4]。
自動化的測試具有高效率、一致、可信的優點,尤其是基于腳本的自動測試更為靈活高效。為提高測試效率,增加測試規范性,RSSP-II安全通信的功能測試過程采用了信號系統設計開發平臺(SDP)的專項測試工具[5]。
根據RSSP-II安全通信協議軟件功能測試需要,參照SDP測試系統結構[5],設計RSSP-II安全通信協議軟件功能自動化測試框架,如圖1所示。在測試過程中,待測安全通信協議軟件通過適配層對外接原語接口分引擎(分引擎1)和對等協議棧分引擎(分引擎2)。原語接口分引擎用來模擬待測安全通信協議軟件的用戶應用層,對等協議棧分引擎用來模擬與待測安全通信協議軟件通信的對等實體。主引擎解析腳本命令之后,分別下達到分引擎1、2;同時,分引擎1、2將待測安全通信協議軟件反饋的實際執行結果信息報告給主引擎。測試腳本按照測試用案例進行編寫,采用基于Tcl的Expect腳本語言。對等協議棧分引擎與主引擎間以protobuf格式的消息進行通信,與待測安全通信協議棧以TCP或UDP格式的網絡數據進行通信。
分引擎2可接收待測安全通信協議軟件通過網絡傳送的數據,經過逐層解包和一些正常邏輯判斷的同時把數據送達到主引擎,主引擎通過和腳本的預期結果進行對比從而做出判斷;分引擎2還可以從主引擎接收正常邏輯指令,并與待測安全通信協議軟件進行通信交互;更為重要的是,主引擎可以通過分引擎2對真實協議棧進行測試過程中的錯誤注入,待測安全通信協議棧對于注入錯誤的響應會同時通過分引擎1和分引擎2傳遞給主引擎。因此,對等協議棧分引擎的設計是自動測試的關鍵,只要建立了對等協議棧分引擎的基本框架和通信流程,便可通過腳本控制發送不同指令或數據來實現各種類型的錯誤注入。

圖1 RSSP-II軟件自動化測試框架
參照上述的測試框架,RSSP-II自動測試的準備工作集中在測試分引擎1、分引擎2的設計實現以及測試腳本的編寫。其中,分引擎1的設計需要遵循RSSP-II應用原語接口規范。為了實現各種類型的錯誤注入,分引擎2的設計和測試腳本編寫之間的聯系更為緊密,下面加以著重闡述。
RSSP-II協議按功能從上至下可分為安全應用中間子層(SAI)、消息鑒定安全層(MASL)、適配及冗余管理層(ALE)。對等協議棧接收到的數據需要經過逐層解包,并且進行必要的邏輯判斷(CRC校驗和MAC校驗等),同時把每層的數據按照消息字段格式送達到主引擎用來和腳本的預期結果進行判定。由于在ALE層要實現CLASS D冗余通信,對等協議棧分引擎在雙通道接收時,需要在ALE層入口處比對兩通道的數據包內容是否完全一致。組包過程與解包過程相對應,在對等協議棧分引擎的每一層都要加上相應的包頭或包尾,才能滿足協議數據格式從而與待測安全通信協議棧進行通信。RSSP-II協議數據包結構如圖2所示,包頭和包尾的詳細邏輯字段格式可參照subset-098協議[1]。
錯誤注入是指通過注入不同的錯誤來測試安全協議棧對該錯誤的反應,這也是對等協議棧分引擎設計實現的重要目的。對等協議棧分引擎的任何一層收到數據后直接匯報給主引擎并繼續往上層傳送直至應用層,當對等協議棧分引擎未收到主引擎下發的動作消息時,其一直處于等待狀態。一般情況下,凡是對等分引擎的發送點都可以且應當成為相應的錯誤注入點,由此可推出關聯的測試功能點和對應的錯誤注入點,如表1所示。總結SAI層、MASL層和ALE層的功能點從而得到不同錯誤注入點的測試內容以及測試引擎及腳本設計實現要點,從而使測試案例的系統歸納和測試引擎腳本的聯合設計得以實現。錯誤注入后,待測協議棧的反應會通過引擎1和引擎2分別傳送到主引擎,最終通過腳本的預定邏輯進行判決。

圖2 RSSP-II協議棧數據包結構
經過多輪次的補充完善,RSSP-II協議的功能測試共包含300個不同的測試案例,功能測試共包含測試腳本286個(300個案例中有12個測試案例為非腳本執行案例且有兩個案例復用了之前的測試腳本)。案例之間沒有先后關系,對于可用腳本執行的測試案例,每次測試執行一個測試案例對應的腳本,逐次執行所有腳本。對于每個測試案例的腳本,會將主引擎從分引擎獲得的實際執行結果與預期結果進行比較做出邏輯判斷,而主引擎通過記錄各個腳本是否通過來統計測試案例的執行情況。
對于RSSP-II協議的前7輪功能測試,回歸測試結果如表2所示。在回歸測試過程中,案例數量和腳本數量呈不斷增多的趨勢,但是除了在案例數量比較穩定的2~5輪和6~7輪回歸測試之前,引擎和腳本的開發工作所占工時比較多之外,其余測試過程均可高效自動化回歸測試完成,而且由于自動化測試方法較好的一致性,這兩個階段之間腳本的復用率也比較高。因此,對于具有多輪次的回歸測試,采用SDP專項測試工具有利于提高測試效率,增強測試的一致性和可信度。

表1 測試功能點及錯誤注入實現

表2 RSSP-II 7輪回歸測試結果
采用SDP專項測試工具開展自動測試工作,所需要額外的知識儲備主要在于分引擎和腳本的設計與開發。RSSP-II安全通信協議軟件的功能測試,一開始就采用了自動化腳本測試的方法,因而在多輪次的回歸測試過程中,獲得了良好的時間、人力效率以及較好的自動測試覆蓋率。在回歸測試過程中值得注意的是,由于分引擎與主引擎網絡UDP通信的不可靠性,通信時延以及Expect腳本時延控制精度不足,部分腳本需要進行二次手動回歸才能通過,而有些需要精確測試定時器超時功能的案例,需要把待測協議棧超時值參數的顆粒度設置得較為粗大。此外,盡管自動測試案例的覆蓋率已經較高,但是對于部分測試案例(表1最后兩行),由于開發難度和靈活性的限制,還是不太適合編寫腳本進行自動化測試。
對于區域控制器(ZC)子系統專項測試,分引擎和腳本的結構設計可以相對簡化地按照應用接口協議進行開發[5]。而RSSP-II安全通信協議,作為與應用無關的通信協議類軟件產品,其測試案例更多偏重于考察軟件面對通信過程中的重復、插入、刪除、重排序、損壞、延遲、偽裝等安全通信威脅時的錯誤檢測和安全防護。在開發分引擎時,我們便充分考慮后期腳本開發的可行性和一致性。在測試案例不斷增加的過程中,通過擴充protobuf消息類型的方式實現用腳本控制對等協議棧分引擎向RSSPII軟件進行錯誤注入的新接口。這種引擎腳本聯合設計開發的思路,對于SDP專項測試工具在通信協議類軟件模塊測試領域的應用具有明顯的借鑒意義。
RSSP-II安全通信協議軟件,可以作為安全通信模塊移植到不同的安全平臺上。移植后需要進行目標平臺的性能測試和側重軟件接口的軟硬件集成測試。同時開發了針對平臺軟硬件集成測試的半實物測試環境,測試框架與圖1相同,所不同的是待測RSSP-II軟件已經編譯、運行在不同的硬件平臺上:部署在測試機上的分引擎1通過平臺的UDP端口向平臺安全通信協議軟件轉發腳本消息并收取上報給平臺主控邏輯的應用原語。實施平臺的軟硬件集成測試,可以確保RSSP-II軟件能夠在不同安全平臺硬件上得以正確運行,客觀上也推廣了SDP專項測試工具的應用領域。
本文提出基于SDP專項測試工具的RSSP-II安全通信協議軟件自動化測試設計和實現方法并將其應用于軟件功能測試。多輪次的回歸測試表明,采用專項測試工具有利于提高測試效率,增強測試的一致性和可信度。針對軟件自動測試,本文提出測試引擎和腳本的聯合設計與實現方法,并將SDP工具應用于半實物軟硬件集成測試。
[1] Subset-098,RBC-RBC Safe Communication Interface v1.0.0 [S].ERTMS,2007.
[2]運基信號[2010]267號.RSSP-II鐵路信號安全通信協議v1.0[S].
[3] EN50159:Railway applications-Communication,signaling and processing systems [S].ERTMS,2010.
[4] EN50128:Railway applications-Software for railway control and protection systems [S].ERTMS,2011.
[5]高強.專項測試工具在鐵路信號軟件測試中的試用與結果分析[J].鐵路通信信號工程技術,2013,10(增刊):131-136.
RSSP-II safety communication protocol software is a safety-related product in the field of railway communication. SDP testing tool is used to realize automatic testing in the functional test of RSSPII software, so the testing effi ciency and standardization are improved. The paper presents a structure of RSSP-II software testing system to achieve fault injection by joint design and implementation of engine and script. It introduces the several rounds of automatic tests of the software products, and proposes that SDP testing tool can be applied to semi-physical hardware/software integration testing.
RSSP-II test; fault injection; joint design of engine and script; semi-physical hardware/software integration test
10.3969/j.issn.1673-4440.2015.06.011
2014-09-25)