專利名稱：一種系統(tǒng)測試的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及中國列車運行控制系統(tǒng)，尤其涉及一種系統(tǒng)測試的方法。
背景技術(shù)：
隨著計算機技術(shù)的飛速發(fā)展，自動化測試技術(shù)也越來越趨于成熟。針對軟件的測 試已普遍采用了自動測試技術(shù)，并且已取得了顯著的成就。
目前，我國采用的CTCS-3級列控系統(tǒng)，其結(jié)構(gòu)和功能都十分復雜，對正式投入運 營的設(shè)備安全性要求十分苛刻。所以，在正式投入使用前需進行完整的功能測試。而針對 CTCS-3級列控系統(tǒng)的測試，大多采用傳統(tǒng)的人工測試的方式，問題產(chǎn)生后，需要人工去查找 問題產(chǎn)生的原因，耗時耗力且效率不高。針對有些偶然發(fā)生的故障，若沒及時捕捉到，事后 很難再復現(xiàn)當時的場景，給工作帶來了很大的困擾。而且無論是現(xiàn)場測試還是實驗室測試， 最終均依靠用戶根據(jù)經(jīng)驗判斷結(jié)果，導致對系統(tǒng)的測試沒有一個衡量的標準，同時也會引 入由人為因素引起的判斷結(jié)果不穩(wěn)定等問題，嚴重影響測試質(zhì)量。
現(xiàn)有技術(shù)中，對CTCS-3級列控系統(tǒng)進行測試有如下幾種方法
(I)通過從存儲測試數(shù)據(jù)的數(shù)據(jù)庫中查詢對CTCS列控子系統(tǒng)進行測試的測試序 列中的測試變量的信息，來顯示CTCS列控車載子系統(tǒng)的運行情況。但是該方法僅是針對列 控車載子系統(tǒng)進行測試，無法應用到整個列控系統(tǒng)，而且僅對列車運行狀態(tài)進行顯示，對于 產(chǎn)生問題的原因還是需要用戶進行分析判斷，沒有一個標準的衡量方法，并且采用預先編 寫測試序列的方式，只能針對固定的線路進行測試，檢查系統(tǒng)是否按照已有的序列正常響 應，并且若要對全新的線路進行測試，仍需要先編寫測試序列，因此，降低了系統(tǒng)的可移植 性。
(2)通過對測試案例進行分類及對應，得到與互聯(lián)互通相關(guān)的測試案例集合，并按 照特定方法串聯(lián)成測試序列，生成測試序列期望結(jié)果數(shù)據(jù)庫；利用測試平臺對被測設(shè)備進 行測試，記錄測試中傳輸?shù)娜繑?shù)據(jù)，將測試序列執(zhí)行結(jié)果與期望結(jié)果進行比對分析，以統(tǒng) 計結(jié)果方式生成缺陷數(shù)據(jù)庫。但是從該方法生成的缺陷數(shù)據(jù)庫中無法判斷缺陷產(chǎn)生的原 因，還需要用戶進行分析判斷；并且該方案為預先組織測試序列，然而若造成遺漏現(xiàn)象，將 導致測試不全面。發(fā)明內(nèi)容
本發(fā)明的目的是提供一種系統(tǒng)測試的方法，提高了測試案例的執(zhí)行效率，改善了 測試質(zhì)量，減少了測試的依賴性，節(jié)省了人力物力資源。
一種系統(tǒng)測試的方法，包括
監(jiān)測系統(tǒng)各個接口，若一接口的報文數(shù)據(jù)能觸發(fā)一測試案例，則判定該報文數(shù)據(jù) 與該測試案例的觸發(fā)條件匹配成功，且當觸發(fā)條件匹配成功后該測試案例進入執(zhí)行隊列；
獲取測試案例的執(zhí)行結(jié)果，并根據(jù)該測試案例的標識判斷是否為正向測試；若是， 則將執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果進行匹配，否則執(zhí)行失?。?br> 當測試案例為正向測試時，若所述執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果匹配成功，則案例 執(zhí)行成功，否則執(zhí)行失敗。
由上述本發(fā)明提供的技術(shù)方案可以看出，通過觸發(fā)條件對測試案例進行全面搜索 匹配，提高了測試案例的執(zhí)行效率及系統(tǒng)的可移植性，并減少了系統(tǒng)的依賴性，提高了測試質(zhì)量。


為了更清楚地說明本發(fā)明實施例的技術(shù)方案，下面將對實施例描述中所需要使用 的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本 領(lǐng)域的普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他 附圖。
圖1為本發(fā)明實施例一提供的一種系統(tǒng)測試的方法的流程圖2為本發(fā)明實施例二提供的又一種系統(tǒng)測試的方法的流程圖。
具體實施方式
下面結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整 地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。基于本 發(fā)明的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施 例，都屬于本發(fā)明的保護范圍。
實施例一
圖1為本發(fā)明實施例所提供的一種系統(tǒng)測試的方法，該方法可以包括如下步驟
步驟101、監(jiān)測系統(tǒng)各個接口，若一接口的報文數(shù)據(jù)能觸發(fā)一測試案例，則判定該 報文數(shù)據(jù)與該測試案例的觸發(fā)條件匹配成功，且當觸發(fā)條件匹配成功后該測試案例進入執(zhí) 行隊列。
其中，該報文數(shù)據(jù)可以是測試數(shù)據(jù)也可以是實際數(shù)據(jù)。換言之，本發(fā)明可以用于實 驗室測驗(例如，對特定功能進行測試)，也可用于實際工作中對系統(tǒng)運行狀態(tài)進行檢測。
對于接收到的報文數(shù)據(jù)是否能夠觸發(fā)測試案例主要判斷報文數(shù)據(jù)是否能夠搜索 到匹配的觸發(fā)條件。觸發(fā)條件一般包括記錄單元(JRU)消息、無線閉塞中心RBC消息、車 載設(shè)備人機界面DMI消息、其它相關(guān)信息包和/或相關(guān)變量。解析所述接收到的報文數(shù)據(jù)， 確定消息類型、對應的消息編號、信息包編號和相關(guān)變量；將所述消息編號作為該消息的取 值，從知識庫中篩選出與該取值對應的S (S為大于I的自然數(shù))個測試案例；從所述S個 測試案例中查找出與該消息的信息包編號及相關(guān)變量相匹配的測試案例。
步驟102、獲取測試案例的執(zhí)行結(jié)果，并根據(jù)該測試案例的標識判斷是否為正向測 試；若是，執(zhí)行步驟103，否則執(zhí)行步驟105。
大多數(shù)的測試案例均為正向測試，但某些案例正向測試很難進行，為保證測試的 準確性則進行反向測試，即在規(guī)定的時間或距離內(nèi)發(fā)生某事件則認為案例執(zhí)行失敗。
步驟103、當測試案例為正向測試時，若所述執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果匹配成 功，則轉(zhuǎn)入步驟104 ;否則，轉(zhuǎn)入步驟104。
步驟104、測試案例執(zhí)行成功。
當測試案例執(zhí)行成功后，生成測試案例執(zhí)行結(jié)果數(shù)據(jù)庫，并根據(jù)需要可對案例測 試結(jié)果進行分類統(tǒng)計。
步驟105、測試案例執(zhí)行失敗。通過上述內(nèi)容可知，測試案例執(zhí)行失敗可能有多種 情況反向測試時，即在規(guī)定的時間或距離內(nèi)發(fā)生某事件；正向測試時，執(zhí)行結(jié)果與預定的 結(jié)果匹配失敗。此時，通過包含測試案例執(zhí)行失敗的各種原因的推理機對執(zhí)行結(jié)果進行故 障分析，生成對應的測試報告，并存儲該分析結(jié)果。
本發(fā)明實施例通過觸發(fā)條件對測試案例進行全面搜索匹配，提高了測試案例的執(zhí) 行效率及系統(tǒng)的可移植性，并減少了系統(tǒng)的依賴性，提高了測試質(zhì)量。
實施例二
為了更具體的介紹本發(fā)明，下面結(jié)合附圖2對本發(fā)明做進一步描述。如圖2所示， 包括以下步驟
步驟201、建立知識庫。本實施例以用于中國列車運行控制系統(tǒng)CTCS-3級列控系 統(tǒng)的測試為例做介紹，因此，需建立與其對應的知識庫。
該知識庫的主要目的是用于驗證系統(tǒng)是否滿足CTCS-3級列控系統(tǒng)總體技術(shù)方案 和系統(tǒng)需求規(guī)范，即驗證系統(tǒng)功能是否完善，設(shè)備之間是否已達到互聯(lián)互通的要求，因此最 終判定的依據(jù)是系統(tǒng)功能需求規(guī)范。
《CTCS-3級列控系統(tǒng)測試案例》依據(jù)《CTCS-3級列控系統(tǒng)系統(tǒng)需求規(guī)范(SRS)))和 《CTCS-3級列控系統(tǒng)總體技術(shù)方案》進行編制，是CTCS-3級列控系統(tǒng)實驗室仿真測試、現(xiàn)場 試驗及聯(lián)調(diào)聯(lián)試的基礎(chǔ)性文件，因此本實施例的知識庫的主要來源于《CTCS-3級列控系統(tǒng) 測試案例》。即將《CTCS-3級列控系統(tǒng)測試案例》中的測試案例進行整理，生成程序所能識 別的描述語言，并將測試案例提取出關(guān)鍵字段，整理成表格形式，其中主要字段有，案例編 號、觸發(fā)條件和預定的執(zhí)行結(jié)果。觸發(fā)條件為觸發(fā)一個測試案例的先決條件，預定的執(zhí)行結(jié) 果作為判斷測試案例是否執(zhí)行成功的依據(jù)。其中，復雜的案例可劃分為若干個子案例，前一 個案例作為后一個案例的關(guān)聯(lián)案例，只有關(guān)聯(lián)案例執(zhí)行成功后才能執(zhí)行此案例，當案例執(zhí) 行失敗時，便于查找問題的根源。
通過上述內(nèi)容可以得知，知識庫中包含了若干的測試案例，而為了提供系統(tǒng)的可 移植性以及針對測試情況不同，需要設(shè)計測試案例的組織方式。
(I)當需要針對某些特定的功能進行測試時，可以直接將對應的測試案例提取并 按照某種特定的順序串聯(lián)在一起，形成測試序列。該測試序列的設(shè)計和執(zhí)行都是按照步驟 來執(zhí)行的，測試序列以步驟形式將所有測試案例關(guān)聯(lián)起來，只有當上一個測試案例執(zhí)行成 功后才會執(zhí)行下一個測試案例。并且所設(shè)定的測試序列需覆蓋所有的測試案例，以便能夠 針對所有功能特征進行測試。
(2)當需要對系統(tǒng)的運行狀態(tài)進行檢測時，則可以檢測系統(tǒng)的各個接口，從接口獲 取報文數(shù)據(jù)來觸發(fā)測試案例。而通過接口傳輸?shù)膱笪臄?shù)據(jù)用戶無法預先得知與其對應的測 試案例，因此，需對知識庫中的測試案例進行全面搜索。優(yōu)選的，為了實現(xiàn)測試案例的快速 匹配，可在存儲測試案例時將案例分類進行存儲，然后根據(jù)收到的數(shù)據(jù)，搜索特定案例的分 支子樹，提高搜索的效率。
步驟202、監(jiān)測系統(tǒng)各個接口，若一接口的報文數(shù)據(jù)能觸發(fā)一測試案例，則判定該 報文數(shù)據(jù)與該測試案例的觸發(fā)條件匹配成功，且當觸發(fā)條件匹配成功后該測試案例進入執(zhí)行隊列。本步驟主要針對上述第2種測試案例的組織方式進行介紹。
在對CTCS-3級列控系統(tǒng)的測試時，可以在現(xiàn)有接口上進行，從接口獲得數(shù)據(jù)后， 搜索對列控系統(tǒng)進行測試的知識庫中每條測試案例的信息。
接口一般分為兩大類(1)與無線閉塞中心RBC相關(guān)的接口 包括RBC本地操作 終端(含MMI和記錄器)，RBC與RBC接口、RBC與車站聯(lián)鎖設(shè)備接口、RBC與調(diào)度集中CTC接 口、RBC與臨時限速服務器接口、RBC與GSM-R網(wǎng)絡(luò)之間的接口、RBC與集中監(jiān)測系統(tǒng)的接 口。(2)與車載設(shè)備相關(guān)的接口 包括車載設(shè)備與人機界面(DMI)、車載設(shè)備與記錄單元接 口(JRU)、車載設(shè)備與GSM-R接口(RTM)、車載設(shè)備與動車組接口(TIU)、車載設(shè)備與應答器 接口(BTM)、車載設(shè)備與軌道電路接口(TCR)。
監(jiān)測系統(tǒng)各個接口(例如JRU、TIU及DMI等)，當接收到數(shù)據(jù)后，進入測試案例的搜 索匹配過程，下述以接收到JRU接口的數(shù)據(jù)為例進行介紹
JRU接口接收到的數(shù)據(jù)是行車過程中交互的主要信息，其數(shù)據(jù)是以固定格式打包 的信息幀，系統(tǒng)通過車載設(shè)備接收JRU報文數(shù)據(jù)，并根據(jù)協(xié)議解析數(shù)據(jù)幀，得到關(guān)鍵信息， 從而確定消息類型；由DMI顯示行車過程中的模式、等級和速度等一些輔助信息，再通過模 式識別軟件(PR)，攝取DMI的圖像信息，提取有用數(shù)據(jù)；然后查詢知識庫，搜索該數(shù)據(jù)能夠 觸發(fā)的測試案例。具體的本實施例中JRU報文數(shù)據(jù)包括車到地消息(RBC消息)、地到車消 息(RBC消息)、應答器報文(JRU消息)與司機操作(JRU消息)等，將該報文解析后若得知該 報文為車到地消息或地到車消息，則可確定該報文為RBC消息，隨即對該消息進行解析，得 到RBC編號、信息包編號和相關(guān)變量，將該編號作為該RBC消息的取值，從知識庫中篩選出 與該取值對應的S個測試案例；從所述S (S為大于I的自然數(shù))個測試案例中查找出與該 消息的信息包編號及相關(guān)變量相匹配的測試案例。若對報文數(shù)據(jù)解析后得知該報文為應答 器報文或司機操作，則為JRU消息，其查找測試案例的過程與上述查找過程類似。并且，系 統(tǒng)的其他接口(例如，TIU及DMI)接收到數(shù)據(jù)后的處理過程與上述處理過程類似，因此，不 再贅述。
進一步的，為了能夠更好的對測試結(jié)果進行分析，本發(fā)明還實現(xiàn)了對測試結(jié)果進 行回放的功能，從接口接收數(shù)據(jù)的同時，將數(shù)據(jù)存儲成特定格式的文件，在測試結(jié)束后，讀 取文件數(shù)據(jù)，即可實現(xiàn)系統(tǒng)的回放功能。
步驟203、獲取測試案例的執(zhí)行結(jié)果，并根據(jù)該測試案例的標識判斷是否為正向測 試；若是，執(zhí)行步驟204，否則執(zhí)行步驟206。
大多數(shù)的測試案例均為正向測試，但某些案例正向測試很難進行，為保證測試的 準確性則進行反向測試，即在規(guī)定的時間或距離內(nèi)發(fā)生某事件則認為案例執(zhí)行失敗。
步驟204、當測試案例為正向測試時，若所述執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果匹配成 功，則轉(zhuǎn)入步驟205 ;否則，轉(zhuǎn)入步驟206。測試案例執(zhí)行結(jié)果的匹配相對于觸發(fā)條件的匹配 而言較為簡單，如步驟203所述，反向測試則不需要進行執(zhí)行結(jié)果的匹配，即滿足觸發(fā)條件 匹配即可；而正向測試需要匹配執(zhí)行結(jié)果，當執(zhí)行結(jié)果與當前測試案例的預定的執(zhí)行結(jié)果 一致時，則表不案例執(zhí)行成功。
存在以下幾種情況1對1，即在某一時間點上滿足測試案例的觸發(fā)條件，且執(zhí)行 結(jié)果與預定的執(zhí)行結(jié)果匹配成功，則案例執(zhí)行成功，否則案例執(zhí)行失敗。
I對多，即某一段時間均滿足測試案例的觸發(fā)條件，此時需先確定該測試案例的起止時間，若在該起止時間內(nèi)匹配到對應的預定的執(zhí)行結(jié)果則案例執(zhí)行成功，否則案例執(zhí)行 失敗。例如，超速防護(測試案例):當速度超過允許速度時，滿足觸發(fā)條件；此時應確定該測 試案例的起止時間，當司機在該段時間內(nèi)降速或采用最大常用制動或緊急制動時，使得速 度小于允許速度，則案例執(zhí)行成功，否則案例執(zhí)行失敗。
優(yōu)選的，為避免測試案例的重復搜索比對，或由于觸發(fā)條件的重復判斷造成一段 時間內(nèi)系統(tǒng)的開銷量增大，影響測試效率。因此，在對于I對I的情況時，即在某一時間點上 滿足觸發(fā)條件，但在匹配到對應的預定的執(zhí)行結(jié)果之前，又接收到包含該觸發(fā)條件的報文 數(shù)據(jù)時，則當前測試案例執(zhí)行失敗。例如，當前測試案例為請求MA，但是在收到MA之前，又 接受到包含該測試案例觸發(fā)條件的報文數(shù)據(jù)時，則判定當前測試案例執(zhí)行失敗。在I對多 的情況下，即在某一時間段內(nèi)滿足觸發(fā)條件，則判斷該觸發(fā)條件對應的測試案例是否已經(jīng) 進入預定的執(zhí)行結(jié)果匹配階段，若處于預定的執(zhí)行結(jié)果匹配階段，則在預設(shè)的時間結(jié)束前， 不再對該測試案例的觸發(fā)條件進行匹配。
顯然，通過上述介紹可知，知識庫中的測試案例處于兩種狀態(tài)就緒狀態(tài)與執(zhí)行狀 態(tài)。就緒狀態(tài)的測試案例一旦觸發(fā)條件滿足即進入預定的執(zhí)行結(jié)果匹配隊列；而執(zhí)行狀態(tài) 的案例則存在兩種情況允許重復的，即測試案例允許重復執(zhí)行，以I對I的情況居多，但若 重復次數(shù)超出預設(shè)值(例如，1、2)，并且當前案例還未執(zhí)行成功，則認為案例執(zhí)行失??；不允 許重復的，只有當測試案例再次變?yōu)榫途w狀態(tài)才能進行觸發(fā)條件的匹配。
步驟205、測試案例執(zhí)行成功。當前案例執(zhí)行成功，則可生成測試案例執(zhí)行結(jié)果 數(shù)據(jù)庫，并根據(jù)需要可對案例測試結(jié)果進行分類統(tǒng)計，具體的將測試案例的執(zhí)行結(jié)果以圖 形化方式顯示，可按案例的執(zhí)行時間組織，顯示案例的起始時間、結(jié)束時間以及整個執(zhí)行時 長，方便查找特定時間發(fā)生的案例；如若想要查看案例的統(tǒng)計信息，可以生成測試報告，其 中包括案例的分類統(tǒng)計信息以及條形圖顯示，清晰直觀。
步驟206、測試案例執(zhí)行失敗。當測試案例執(zhí)行失敗時，通過包含測試案例執(zhí)行失 敗的各種原因的推理機分析其可能導致失敗的原因后，存入結(jié)果數(shù)據(jù)庫，作為下次產(chǎn)生相 同故障時的分析依據(jù)。
推理機可以模擬人類專家進行推理和判斷，但需要長期積累和學習的階段。在測 試案例整理初期，需要具有專門知識的用戶給出可能導致測試案例執(zhí)行失敗的原因，作為 一個初始推理依據(jù)。測試結(jié)束后，分析執(zhí)行失敗的測試案例，分析不同情況下執(zhí)行失敗的原 因，分析結(jié)果存入推理機，豐富推理機的知識儲備，通過這樣不斷的學習積累、充實推理機， 使其具有豐富的案例故障分析的經(jīng)驗，能夠自動分析案例執(zhí)行結(jié)果、判斷故障起因等。
本發(fā)明實施例通過觸發(fā)條件對測試案例進行全面搜索匹配，提高了測試案例的執(zhí) 行效率及系統(tǒng)的可移植性；同時，通過推理機進行故障分析，減少了人為因素引起的判斷結(jié) 果不穩(wěn)定等問題，并減少了系統(tǒng)的依賴性，提高了測試質(zhì)量。
通過以上的實施方式的描述，本領(lǐng)域的技術(shù)人員可以清楚地了解到上述實施例可 以通過軟件實現(xiàn)，也可以借助軟件加必要的通用硬件平臺的方式來實現(xiàn)?；谶@樣的理解， 上述實施例的技術(shù)方案可以以軟件產(chǎn)品的形式體現(xiàn)出來，該軟件產(chǎn)品可以存儲在一個非易 失性存儲介質(zhì)(可以是⑶-R0M，U盤，移動硬盤等)中，包括若干指令用以使得一臺計算機設(shè) 備(可以是個人計算機，服務器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本發(fā)明各個實施例所述的方法。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明披露的技術(shù)范圍內(nèi)，可輕易想到的變化或替換， 都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范 圍應該以權(quán)利要求書的保護范圍為準。
權(quán)利要求
1.一種系統(tǒng)測試的方法，其特征在于，包括 監(jiān)測系統(tǒng)各個接ロ，若一接ロ的報文數(shù)據(jù)能觸發(fā)ー測試案例，則判定該報文數(shù)據(jù)與該測試案例的觸發(fā)條件匹配成功，且當觸發(fā)條件匹配成功后該測試案例進入執(zhí)行隊列； 獲取測試案例的執(zhí)行結(jié)果，并根據(jù)該測試案例的標識判斷是否為正向測試；若是，則將執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果進行匹配，否則執(zhí)行失??； 當測試案例為正向測試時，若所述執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果匹配成功，則案例執(zhí)行成功，否則執(zhí)行失敗。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，該方法還包括 預先建立包括若干所述測試案例的知識庫，每ー個測試案例設(shè)置有對應的觸發(fā)條件及預定的執(zhí)行結(jié)果。
3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述觸發(fā)條件包括 JRU消息、無線閉塞中心RBC消息、車載設(shè)備人機界面DMI消息、信息包和/或相關(guān)變量。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，確定所述ー接ロ的報文數(shù)據(jù)能觸發(fā)ー測試案例的步驟包括 解析接收到的報文數(shù)據(jù)，確定消息類型、對應的消息編號、信息包編號和相關(guān)變量； 將所述消息編號作為該消息的取值，從知識庫中篩選出與該取值對應的S個測試案例； 從所述S個測試案例中查找出與該消息的信息包編號及相關(guān)變量相匹配的測試案例，其中S為大于I的自然數(shù)。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，該方法還包括 若某一時間點上滿足測試案例的觸發(fā)條件，且執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果匹配成功，則測試案例執(zhí)行成功，否則，則測試案例執(zhí)行失??； 或，若在某一時間段內(nèi)滿足測試案例的觸發(fā)條件，則先確定該測試案例的起止時間，在該起止時間內(nèi)匹配到對應的預定的執(zhí)行結(jié)果，則測試案例執(zhí)行成功，否則執(zhí)行失敗。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，該方法還包括 若在某一時間點上滿足測試案例的觸發(fā)條件，但在匹配到對應的預定的執(zhí)行結(jié)果之前，又接收到包含該觸發(fā)條件的報文數(shù)據(jù)時，則當前測試案例執(zhí)行失??； 或，若在某一時間段內(nèi)滿足測試案例的觸發(fā)條件，則判斷該觸發(fā)條件對應的測試案例是否已經(jīng)進入預定的執(zhí)行結(jié)果匹配階段，若處于預定的執(zhí)行結(jié)果匹配階段，則直至當前測試案例執(zhí)行完畢前，忽略接收到包含該觸發(fā)條件的數(shù)據(jù)。
7.根據(jù)權(quán)利要求1或5或6所述的方法，其特征在干，當測試案例執(zhí)行失敗后包括 通過包含測試案例執(zhí)行失敗原因的推理機進行故障分析；根據(jù)執(zhí)行的結(jié)果判斷故障的起因，生成對應的測試報告，并存儲該分析結(jié)果。
8.根據(jù)權(quán)利要求1所述的方法，其特征在于，該方法還包括將測試案例進行串聯(lián)，構(gòu)成測試序列；該測試序列中相鄰的兩個測試案例存在因果關(guān)系，當上一個測試案例執(zhí)行成功后則執(zhí)行下一個測試案例。
全文摘要
本發(fā)明公開了一種系統(tǒng)測試的方法，包括監(jiān)測系統(tǒng)各個接口，若一接口的報文數(shù)據(jù)能觸發(fā)一測試案例，則判定該報文數(shù)據(jù)與該測試案例的觸發(fā)條件匹配成功，且當觸發(fā)條件匹配成功后該測試案例進入執(zhí)行隊列；獲取測試案例的執(zhí)行結(jié)果，并根據(jù)該測試案例的標識判斷是否為正向測試；若是，則將執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果進行匹配，否則執(zhí)行失敗；當測試案例為正向測試時，若所述執(zhí)行結(jié)果與預定的執(zhí)行結(jié)果匹配成功，則案例執(zhí)行成功，否則執(zhí)行失敗。通過采用本發(fā)明公開的方法提高了測試案例的執(zhí)行效率，改善了測試質(zhì)量，減少了測試的依賴性，節(jié)省了人力物力資源。
文檔編號G06F11/36GK103049379SQ201210555438
公開日2013年4月17日 申請日期2012年12月19日 優(yōu)先權(quán)日2012年12月19日
發(fā)明者楊志杰, 徐寧, 呂旌陽, 王財進, 王瑞, 萬林, 王丁, 劉佳 申請人:中國鐵道科學研究院, 中國鐵道科學研究院通信信號研究所, 北京市華鐵信息技術(shù)開發(fā)總公司, 北京銳馳國鐵智能運輸系統(tǒng)工程技術(shù)有限公司