基于因果圖法的CTCS-3級列控系統測試案例完備性驗證方法

穆建成，辛　未，馬連川,3，曹　源,3

(1.國家鐵路局 科技與法制司，北京　100891；2.北京交通大學 電子信息工程學院，北京　100044；3.北京交通大學 軌道交通運行控制系統國家工程研究中心，北京　100044)

對列控系統進行測試是檢驗其是否符合功能需求的必要過程，而測試案例是這一過程的基礎和標準[1]，并且測試案例的完備性是測試過程能夠充分驗證系統是否滿足列控系統要求的關鍵。CTCS-3級列控系統的測試案例采用基于功能特征的方法生成[1-2]，對設計人員要求較高，如果對系統功能需求的理解不夠深入，則可能導致測試案例設計錯誤或遺漏[3]。為確保測試能夠覆蓋全部系統需求規范，需要驗證測試案例的完備性。

對CTCS-3級列控系統測試案例進行完備性驗證，就是考察其對于《CTCS-3級列控系統需求規范(SRS)》[4]的覆蓋程度。目前，針對測試案例的完備性驗證主要采用靜態或動態需求跟蹤方法，通過建立需求跟蹤關系確定[5]。

靜態需求跟蹤方法主要是利用需求跟蹤矩陣[5]、需求管理工具(DOORS[6]和Rational Requistepro[7])等由人工手動建立需求跟蹤關系。例如文獻[1]利用DOORS人工關聯SRS與測試案例，形成鏈接關系并輸出需求跟蹤報表，最終通過人工審核，驗證CTCS-3級列控系統測試案例的完備性。但由于該方法對人工依賴程度較高，如果驗證人員對SRS和測試案例的理解有偏差，則可能導致驗證結果并不能說明測試案例的完備性。特別是對于規模較大的系統，應用靜態需求跟蹤方法存在著需求跟蹤關系創建困難并且容易出錯等問題[8-9]。

動態需求跟蹤方法則主要是利用信息檢索技術[10]、動態跟蹤工具RETRO[11]等自動生成需求跟蹤關系。但目前應用動態需求跟蹤方法生成的需求跟蹤關系一般會存在錯誤，并可能漏掉部分正確關系，導致驗證過程存在精度問題，難以滿足對安全性要求較高項目的驗證需要。

此外，CTCS-3級列控系統的SRS和測試案例均用自然語言描述。由于自然語言本身具有的矛盾、二義性等問題[12]，造成SRS和測試案例間存在表述不一致、對應關系不明確的問題，不能滿足準確驗證測試案例完備性的要求。

針對列控系統測試案例完備性驗證方法目前存在的問題，本文基于因果圖法提出CTCS-3級列控系統測試案例完備性驗證的新方法；并以CTCS-3級列控系統車載設備待機模式下的模式轉換功能測試案例為例，通過對該案例完備性的驗證，證明本文方法的有效性。

1　基本思路

對CTCS-3級列控系統測試案例進行完備性驗證，需要解決以下3個主要問題。

(1)SRS與測試案例間的對應關系不明確、描述內容不統一；

(2)SRS和測試案例均采用自然語言描述，無法進行自動驗證；

(3)缺少有效衡量測試案例完備性的依據。

因果圖法[13-16]是一種通過描述系統的邏輯條件和相應動作，從而生成測試案例的方法。使用因果圖可以形式化描述結構復雜、接口眾多、安全苛求系統的SRS，確定復雜系統狀態和外部輸入信息間的依賴關系，然后利用回溯算法生成判定表，最終基于判定表設計測試案例。由于判定表能夠強化系統邏輯描述的嚴密性，因而基于判定表生成的測試案例是全部功能測試方法中最嚴格的[17]。因此，本文基于因果圖法研究能夠解決以上3個主要問題的CTCS-3級列控系統測試案例完備性的驗證方法。

本文方法的主要流程如圖1所示。首先建立SRS因果圖，然后使用改進的遍歷式回溯算法生成SRS判定表；利用SRS判定表內的事件建立測試案例因果圖，進而生成測試案例判定表；根據設計的測試充分性準則，通過SRS判定表導出測試覆蓋域，確定完備性的衡量依據；最終，對測試覆蓋域和測試案例判定表進行對比，從而驗證CTCS-3級列控系統測試案例的完備性。

圖1　基于因果圖的測試案例完備性驗證流程

2　基于因果圖的驗證方法

2.1　建立SRS因果圖并生成SRS判定表

1)建立SRS因果圖

基于《CTCS-3級列控系統需求規范(SRS)》和《CTCS-3級列控功能需求規范(FRS)》[18]的條文和說明，參照文獻[15]建立CTCS-3級列控系統的SRS因果圖。為了降低建立SRS因果圖的復雜程度，可針對CTCS-3級列控系統的不同功能分別建立系統各功能的SRS因果圖。在建模過程中，需要根據需求規范所描述的系統狀態或外部輸入信息的性質(原因或結果)，確定該系統狀態或外部輸入信息為原因事件或結果事件，并為每個事件定義唯一的標識。需要注意的是，某些結果事件同時又構成了其他系統功能需求的原因事件，在建模過程中需要對此類事件所具有的邏輯關系進行完整的描述[15]。此外，由于CTCS-3級列控系統的系統狀態和外部輸入信息間具有復雜的相關性，因此在建模過程中需要相應地利用約束關系[15]對相關性進行描述，以保證SRS因果圖的正確性。

2)生成SRS判定表

建立SRS因果圖后，再根據SRS因果圖并應用啟發式或遍歷式回溯算法生成SRS判定表，從而將SRS中描述的系統功能需求轉化為判定表內的事件組合，表中的每行，即每組事件組合描述1項系統功能需求。但是，在利用啟發式回溯算法[15]生成SRS判定表的過程中可能會遺漏部分系統功能需求，從而無法滿足完備描述SRS的要求；而用傳統的遍歷式回溯算法[13,15]生成SRS判定表，雖然可以保證對SRS描述的完備性，但在回溯完與當前結果事件存在依賴或約束關系的事件后，會對其他與當前結果事件不存在依賴和約束關系的事件進行統一的置值處理，從而導致對SRS的描述存在偏差，這不利于后續驗證。因此，為了完備且準確地描述SRS，本文通過引入“未明確規定”概念，對遍歷式回溯算法進行改進。

對于1個包含m個結果事件的因果圖G0，定義：i為結果事件索引，且i=1，2，…，m；ei為索引i下的結果事件；Ri是與ei存在依賴關系的原因事件的集合；Si是與ei和Ri中事件存在約束關系的事件的集合；Pi是可以使ei發生的事件組合集合；pik∈Pi是導致ei發生的事件組合，其中k=1，2，…；Vi是其他與ei不存在依賴和約束關系的事件的集合。改進后的遍歷式回溯算法步驟如下。

(1)初始化各變量，置i,k=1，構造空的SRS判定表D0；

(2)選定未被回溯的結果事件ei，將其狀態設置為“真”，根據G0描述的依賴和約束關系，確定Ri和Si中各事件的狀態，從而確定導致ei發生的全部事件組合，得到Pi；

(3)對Pi中的事件組合進行處理，選定未被處理的事件組合pik，將Vi中的全部事件視作SRS“未明確規定”，用“-”表示，并添加入pik中，然后再將pik補充到SRS判定表D0內的后序行中；

(4)執行k=k+1，循環執行步驟(3)，直至Pi中的全部事件組合均被加入D0內；

(5)執行i=i+1，循環執行步驟(2)、步驟(3)和步驟(4)，直至i>m；

(6)回溯完全部結果事件后算法結束，即可得到采用改進遍歷式回溯算法生成的SRS判定表D0。

2.2　建立測試案例因果圖并生成測試案例判定表

由《CTCS-3級列控測試案例》[19]可知，用自然語言描述的測試案例主要由5個部分構成，即測試的系統內部初始狀態SC、接口初始狀態SA、測試步驟Ts、系統內部結束狀態EC和接口結束狀態EA。其中，SC和EC分別描述了測試的初始和結束狀態下系統的運行等級、運行模式、行車許可等內部狀態；SA和EA分別描述了初始和結束狀態下無線鏈接、人機交互界面等系統接口的具體狀態；TS描述了測試過程中外部輸入信息的具體內容，包括接收信息、接收報告、列車的位置變化以及司機的確認操作等。

由于上述5個部分表示的系統狀態及外部輸入信息均在SRS中有對應的描述。因此，可基于SRS判定表內的全部事件并參照文獻[15]的方法建立測試案例因果圖，并利用改進的遍歷式回溯算法生成與SRS判定表對應的基于相同事件的測試案例判定表，從而統一SRS和測試案例的描述方式，以保證兩者具有明確的對應關系。

在測試案例因果圖中，原因事件應包括SC，SA和TS所描述的系統內部狀態、接口狀態以及外部輸入信息；結果事件應包括EC和EA所描述的系統內部狀態及接口狀態。

對于給定的測試案例T0，定義：C和E分別為該測試案例的原因事件集合和結果事件集合，在初始狀態下，上述兩集合均為空集；CS為由SRS判定表D0內全部事件構成的集合。利用CS內的事件建立測試案例因果圖的過程如下。

(1)構造初始測試案例的事件集合C和E；

(2)從測試案例T0中選定1個要描述的系統內部狀態、接口狀態或外部輸入信息，進而從CS中查找與其對應的事件；

(3)根據該系統內部狀態、接口狀態或外部輸入信息所對應事件的性質(原因事件或結果事件)，將其補充至C或E內；

反應堆壓力容器算例模型如圖5所示，因壓力容器是對稱的，取其1/4模型來分析法蘭與壓力容器之間的接觸，該模型僅受螺栓預緊力的作用。材料參數為：彈性模量為200 GPa、泊松比為0.3。

(4)循環執行步驟(2)和步驟(3)，直至處理完測試案例T0中描述的全部系統內部狀態、接口狀態及外部輸入信息。

(5)根據C和E內的事件以及測試案例描述的事件間依賴和約束關系，建立測試案例因果圖。

根據完成的測試案例因果圖，同樣應用改進的遍歷式回溯算法，即可得到測試案例判定表。

2.3　確定衡量測試案例完備性的依據

衡量測試案例完備性的依據是，基于對應測試目的的測試充分性準則及測試覆蓋域[15]。根據列控系統的測試目的，設計測試充分性準則為：測試案例應覆蓋SRS判定表內的全部事件組合。

基于測試充分性準則，利用SRS判定表導出測試覆蓋域。在設計測試案例時，設計人員需要對某些系統功能需求進行延伸理解，以設計多種測試場景進行測試；但該延伸理解的差異性可能會導致在某些測試案例的描述中存在著與其對應的SRS判定表中未包含的其他SRS事件。因此，在利用SRS判定表導出測試覆蓋域時，需先將SRS判定表中未包含的其他SRS事件全部補充至該SRS判定表內，并將其他SRS事件的狀態視為“未明確規定”，在SRS判定表內用“-”表示。之后將SRS判定表內的每一行作為測試覆蓋域中的1個元素，由此得出測試覆蓋域。

2.4　測試案例完備性對比驗證流程的設計

在確定測試覆蓋域后，根據測試案例對測試覆蓋域中所有元素的覆蓋情況，可以得到測試案例完備性的驗證結果。當測試覆蓋域中的所有元素全部被覆蓋，則可判定測試案例的設計滿足測試充分性準則的要求，即測試案例是完備的。測試案例與測試覆蓋域的對比驗證流程如圖2所示。

由圖2可知，首先要根據列控系統的特點，將事件按重要程度分為關鍵事件、測試條件事件以及其他事件3個部分。然后，依次選定測試覆蓋域中的元素，并與測試案例進行逐個事件的對比。當發現某關鍵事件錯誤時，則表示測試案例未能覆蓋SRS規定的某項系統功能需求，應針對該功能需求補充設計測試案例。當發現某測試條件事件錯誤時，則表示該事件描述的測試條件與SRS的規定不相符，說明雖然測試案例覆蓋了關鍵事件所對應的功能需求，但其測試條件的設計，例如接口所處狀態、外部輸入信息的內容等存在不足，應進行修改或完善。當發現其他事件不符時，表示測試案例包含了SRS中“未明確規定”的事件，其主要原因是設計人員對SRS中的規定進行了延伸理解，可利用文獻[4,18]判定該延伸理解是否正確，根據判定結果對測試案例或SRS中的不明確內容進行修改或說明。

圖2　測試案例與測試覆蓋域的對比驗證流程

3　實例驗證

以CTCS-3級列控系統車載設備在待機模式(SB)下的模式轉換功能為例，應用本文方法對其測試案例的完備性進行驗證。

為了下面闡述的方便，首先定義事件的標識及其所描述的內容，見表1。

表1　SB模式下模式轉換功能的事件內容

本文所使用因果圖中的基本關系[15]包括蘊含關系、非關系、與關系和要求約束關系，如圖3所示。其中，ca，cb，cc表示原因事件，ea表示結果事件。在因果圖中，蘊含關系表示當ca為真時，則其對應的結果事件ea也為真；非關系表示當ca為真時，則其對應的結果事件ea為假；與關系表示當ca，cb和cc同時為真時，則其對應的結果事件ea為真，并用“∧”標識；另外當與關系中存在3個或3個以上的原因事件時，則在結果事件端再加入弧線表示，否則可不再加弧線；要求約束關系表示當ca為真時，則cb必為真，并且僅可將要求約束關系用于描述二元約束關系。

圖3　本文因果圖中使用的基本關系

3.1　建立SB模式下模式轉換功能的SRS因果圖及判定表

根據《CTCS-3級列控系統需求規范(SRS)》和《CTCS-3級列控功能需求規范(FRS)》中給出的SB模式下模式轉換功能需求規范，建立該功能的SRS因果圖。其中，對SB轉換為IS，SB轉換為CO以及SB轉換至SH和SL的轉換優先級建立的SRS因果圖如圖4所示。

在圖4中，利用因果關系描述了列控系統車載設備由SB模式轉換至其他工作模式時的轉換條件，并利用約束關系描述了不同轉換條件間具有的屏蔽和依賴關系。圖中的m1—m6是為了便于建模而建立的中間結點，無實際含義。

圖4　SB模式下模式轉換功能的SRS因果圖(部分)

根據得到的SB模式下各模式轉換功能的SRS因果圖，應用改進的遍歷式回溯算法生成對應各模式轉換功能的SRS判定表，并對所得到的全部SB模式下各模式轉換功能SRS判定表進行整合，得到SB模式下模式轉換功能的SRS判定表，見表2。在該表中，用“1”和“0”分別表示相應的事件為真和假，用“-”表示該事件在SRS中“未明確規定”。

表2　SB模式下模式轉換功能的SRS判定表

3.2　建立SB模式下模式轉換功能測試案例的因果圖及判定表

基于SRS判定表內的全部事件和《CTCS-3級列控測試案例》[19]，建立SB模式下模式轉換功能的測試案例因果圖。其中，對CTCS-3級列控系統功能特征549的測試案例1以及功能特征558的測試案例1建立的因果圖如圖5所示。在圖5中，m7—m10同樣為中間結點。

對SB模式下模式轉換功能的測試案例因果圖進行回溯，并整合后得到其測試案例判定表，見表3。其中，事件c17，c18，c19，c20，c21和e8為不包含在SB模式下模式轉換功能SRS判定表中的其他SRS事件。

圖5　SB模式下模式轉換功能的測試案例因果圖(部分)

表3　SB模式下模式轉換功能的測試案例判定表

3.3　確定SB模式下模式轉換功能的測試覆蓋域

根據測試充分性準則，利用SB模式下模式轉換功能的SRS判定表確定其測試覆蓋域。將SRS判定表內每一行，即每一組事件組合確定為測試覆蓋域的1個元素，而將該SRS判定表內未涉及的全部其他SRS事件表示為“-”，得到SB模式下模式轉換功能所包含19個元素的測試覆蓋域，見表4。由于篇幅所限，在表4中僅列出了與本實例相關的事件狀態。

表4　SB模式下模式轉換功能的測試覆蓋域

3.4　完備性驗證結果及分析

選定運行模式，即c1和e1—e7為關鍵事件，c2—c16為測試條件事件，其余SRS事件(包括c17—c21和e8)全部為其他事件。利用作者編制的自動驗證工具對測試覆蓋域和測試案例判定表進行對比，輸出驗證結果見表5。

表5　SB模式下模式轉換功能測試案例完備性驗證結果

根據驗證結果，對文獻[4]和文獻[19]中的相關內容進行對比分析，可以發現：

(1)未對SB模式轉入TR模式設計相應的測試案例；

(2)未針對SB模式轉入其他工作模式時的模式轉換優先級功能設計測試案例；

(3)在SB模式轉入SH模式和SL模式的測試案例中，存在著SRS中“未明確規定”的其他事件。利用文獻[4,18]進行核對，該事件屬于正確的人為擴充，應在測試案例中給出說明。

4　結束語

本文針對既有列控系統測試案例完備性驗證方法存在的問題，基于因果圖法設計了CTCS-3級列控系統測試案例完備性驗證方法。為了確保SRS和測試案例兩者描述方式統一、對應關系明確，并且便于自動驗證的實現，本文通過引入“未明確規定”的概念對現有的遍歷式回溯算法進行了改進，使其可以生成滿足驗證需求的判定表，并提出利用SRS判定表內的事件建立測試案例因果圖；另外，為了明確測試案例完備性的衡量依據，還設計了基于SRS判定表的測試充分性準則，并據此提出了基于SRS判定表確定測試覆蓋域。

以CTCS-3級列控系統車載設備在SB模式下的模式轉換功能為例，對本文方法的有效性進行了檢驗。結果表明，現有測試案例基本實現了對SRS的覆蓋，能夠較好地驗證系統的功能，但也發現一些缺失和不足，需要進行補充和改善；本文方法可以有效地對現有測試案例進行完備性驗證，為進一步完善CTCS-3級列控系統測試案例、確保測試過程覆蓋全部SRS提供了新的方法。

[1]季學勝,李開成,張勇,等.CTCS-3級列控系統測試案例生成方法的研究[J].鐵道通信信號,2009,45(10):1-5.

(JI Xuesheng,LI Kaicheng,ZHANG Yong,et al.Test Case Producing Manner of CTCS Level 3 Train Control System[J]. Railway Signaling & Communication,2009,45(10):1-5.in Chinese)

[2]張勇,王超琦.CTCS-3級列控系統車載設備測試序列優化生成方法[J].中國鐵道科學,2011,32(3):100-106.

(ZHANG Yong, WANG Chaoqi.The Method for the Optimal Generation of Test Sequence for CTCS-3 On-Board Equipment[J].China Railway Science,2011,32(3):100-106.in Chinese)

[3]談敏.CTCS-3級車載設備測試平臺研究[D].北京：北京交通大學,2008.

(TAN Min.Research on the Test Platform of CTCS-3 Onboard Equipment[D].Beijing:Beijing Jiaotong University, 2008.in Chinese)

[4]中華人民共和國鐵道部. 科技運[2008]127號 CTCS-3級列控系統需求規范(SRS)[S].北京：中國鐵道出版社,2008.

[5]李引,李娟,李明樹. 動態需求跟蹤方法及跟蹤精度問題研究[J]. 軟件學報,2009,20(2):177-192.

(LI Yin,LI Juan,LI Mingshu.Research on Dynamic Requirement Traceability Method and Traces Precision[J]. Journal of Software,2009,20(2):177-192.in Chinese)

[6]IBM.DOORS(Dynamic Object Oriented Requirements System) [DB/OL]. [2015-03-21]http://www.telelogic.com/index/cfm.

[7]IBM.Rational RequisitePro[DB/OL].[2015-03-21]http://www.306.ibm.com/software/awdtools/reqpro.

[8]HAYES J H, DEKHTYAR A, SUNDARAM S K,et al. Helping Analysts Trace Requirements:an Objective Look[C]//Proceedings of the 12thInternational Requirements Engineering Conference. Washington: IEEE Computer Society,2004:249-259.

[9]HAYES J H, DEKHTYAR A, SUNDARAM S K. Advancing Candidate Link Generation for Requirements Tracing: the Study of Methods[J]. IEEE Transaction on Software Engineering, 2006,32(1):4-19.

[10]ANTONIOL G,CANFORA G,CASAZZA G,et al. Recovering Traceability Links between Code and Documentation [J].IEEE Transaction on Software Engineering,2002,28(10): 970-983.

[11]HAYES J H,DEKHTYAR A,SUNDARAM S K,et al.Requirement Tracing on Target(RETRO): Improving Software Maintenance through Traceability Recovery [J]. Innovations System Software Engineering,2007,3(3):193-202.

[12]古天龍.軟件開發的形式化方法[M].北京：高等教育出版社,2005.

[13]胡巍巍.CBTC車載系統測試案例設計及優化方法研究[D].北京：北京交通大學,2010.

(HU Weiwei.Research on the Method of Test Cases Generation and Optimization for CBTC Onboard System[D].Beijing：Beijing Jiaotong University，2010.in Chinese)

[14]劉暢,王軼辰,劉斌,等.軟件邊界組合測試的典型案例分析[J].計算機工程與應用,2009,20(2):74-77.

(LIU Chang,WANG Yichen,LIU Bin,et al.Analysis of Representative Case in Software Boundary Combination Testing[J]. Computer Engineering and Applications, 2009,20(2):74-77.in Chinese)

[15]MATHUR A P.Foundations of Software Testing[M]. New Jersey:Addison-Wesley Professional,2008.

[16]李文波,楊穎. 因果圖測試法在地鐵網絡應用軟件合格性測試中的應用[J].機車電傳動,2013 (3): 43-45,48.

(LI Wenbo,YANG Ying.Application of Causality Diagram Test Method for Metro Network Application Software Approval Test[J].Electric Drive for Locomotive，2013 (3): 43-45,48.in Chinese)

[17]JORGENSEN P C.Software Testing:A Craftsman’s Approach[M].Boca Raton:CRC Press,2001.

[18]中華人民共和國鐵道部.科技運[2008]113號 CTCS-3級列控功能需求規范(FRS)[S].北京：中國鐵道出版社,2008.

[19]中華人民共和國鐵道部.科技運[2009]59號 CTCS-3級列控測試案例[S].北京：中國鐵道出版社,2009.