一種航天器測試需求自動生成系統(tǒng)及其方法
【技術領域】
[0001] 本發(fā)明屬于系統(tǒng)測試領域，涉及一種在航天器測試中的測試需求自動生成的系統(tǒng) 與方法。
【背景技術】
[0002] 航天器是一種安全攸關的實時系統(tǒng)。對于航天器的測試需求必須既可以描述被測 系統(tǒng)的功能、性能特征，也能夠描述系統(tǒng)的約束。測試需求模型是用來指導測試人員開展后 續(xù)測試活動、方便測試人員與設計人員之間的溝通的工具。測試需求文檔是測試人員通過 《開發(fā)需求說明書》、《接口控制文檔》、《設計文檔》和《用戶手冊》整理得來，幫助測試人員設 計出更貼近需求的測試的文檔。也可以幫助測試人員準確的了解需求的變化從而快速更改 測試方案。
[0003] 由于航天器系統(tǒng)作為高集成度復雜電子系統(tǒng)的典型，其測試需求達到上萬項?，F(xiàn) 有的測試需求生成方法集中在如何獲取被測系統(tǒng)的靜態(tài)需求，而在獲取動態(tài)需求方面現(xiàn)有 方法則過于復雜，不便于測試人員理解和使用。因此在目前的工程實踐中，由于系統(tǒng)過于復 雜，測試人員通常依據(jù)其測試經(jīng)驗人工編寫測試需求文檔。這極大的延長了測試工作的時 間。為了減少重復性工作，加快測試進度，實現(xiàn)測試需求的自動生成是非常有必要的。
[0004] 目前關于測試需求模型的主要研宄有面向UUT (Unit Under Test，被測模塊）的測 試需求模型，和基于模型測試需求模型。其中面向UUT的測試需求模型主要面向的是測試 設備和測試單元，通過分析被測系統(tǒng)的邏輯給出測試所需要的激勵信號，是從硬件層面對 被測單元進行測試需求建模。基于模型特別是基于UML(Unified Modeling Language，標準 建模語言）的測試需求模型，其主要是通過狀態(tài)圖和類圖描述被測系統(tǒng)，對被測系統(tǒng)的靜 態(tài)結(jié)構(gòu)和動態(tài)結(jié)構(gòu)進行測試需求建模。但是這些工作都是以理論研宄為主，僅給出一種測 試需求建模方法，測試人員仍然需要通過人工的方式生成測試需求。而如何從測試需求模 型生成真正滿足實際的測試需求的技術和方法卻很少。

【發(fā)明內(nèi)容】

[0005] 本發(fā)明為了減少測試人員選取測試需求的時間，提高測試效率。提供了一種面向 航天器的測試需求自動化獲取系統(tǒng)及方法。本發(fā)明通過分析被測系統(tǒng)基于UML的狀態(tài)轉(zhuǎn)換 圖和交聯(lián)圖的測試需求模型，并根據(jù)被測系統(tǒng)級別和一種遍歷算法，找出被測系統(tǒng)的測試 需求。被獲取的測試需求可以根據(jù)用戶要求轉(zhuǎn)變成不同格式的文本輸出。
[0006] 本發(fā)明提供了一種航天器測試需求自動生成系統(tǒng)，包括測試需求庫、UML模型讀取 模塊、被測目標抽取模塊和測試需求構(gòu)建模塊。針對被測航天器按照模塊級、單機級、分系 統(tǒng)級和系統(tǒng)級分別繪制基于UML的狀態(tài)轉(zhuǎn)換圖和交聯(lián)圖。
[0007] 所述的測試需求庫是經(jīng)過積累的各型號被測系統(tǒng)、分系統(tǒng)、單機和模塊所需的測 試需求，包含環(huán)境測試需求庫、總線測試需求庫和接口測試需求庫。測試需求庫的數(shù)據(jù)結(jié)構(gòu) 包括：被測產(chǎn)品名稱，被測產(chǎn)品類型，被測產(chǎn)品測試需求，被測產(chǎn)品的接口名稱和接口類型， 以及被測產(chǎn)品關聯(lián)的總線名稱和總線類型。
[0008] 所述的UML模型讀取模塊對基于UML的狀態(tài)轉(zhuǎn)換圖和交聯(lián)圖抽取對應的XML存儲 結(jié)構(gòu)，并將狀態(tài)轉(zhuǎn)換圖和交聯(lián)圖轉(zhuǎn)換為XML格式的模型存儲。在XML格式的交聯(lián)圖模型中， 將被測產(chǎn)品以類視圖來描述，類視圖包含被測類、交聯(lián)類、類之間的連接方式和接口數(shù)據(jù)； 交聯(lián)圖模型的屬性中包括是否為被測類、類的ID、類名和類的類型，與被測類連接的總線的 屬性包括總線ID、總線名稱和總線類型，類的接口數(shù)據(jù)包括接口 ID、接口名稱和接口類型。
[0009] 所述的被測目標抽取模塊的功能包括被測目標測試環(huán)境抽取和被測目標測試環(huán) 境測試需求查詢。被測目標測試環(huán)境抽取具體是：當測試需求為模塊級或者單機級時，從 交聯(lián)圖模型中選取所有被測產(chǎn)品，從中抽取被測產(chǎn)品對應的類名以及被測產(chǎn)品的各個接口 的接口名稱；當測試需求為系統(tǒng)級和分系統(tǒng)級時，遍歷模型中所有被測產(chǎn)品，抽取與被測產(chǎn) 品相關聯(lián)的總線名稱，抽取被測產(chǎn)品對應的類名以及被測產(chǎn)品的各個接口的接口名稱；根 據(jù)抽取到的被測產(chǎn)品名稱、總線名稱和接口名稱從測試需求庫中篩選出所需的接口測試需 求、總線測試需求和環(huán)境測試需求。被測目標測試環(huán)境測試需求查詢是：根據(jù)類名和總線名 稱從測試需求庫中查找對應的產(chǎn)品名稱，選出所需要的環(huán)境測試需求。
[0010] 所述的測試需求構(gòu)建模塊用于構(gòu)建靜態(tài)測試需求和動態(tài)測試需求；構(gòu)建靜態(tài)測試 需求是指將被測目標抽取模塊獲取的接口測試需求、總線測試需求和環(huán)境測試需求輸出。 構(gòu)建動態(tài)測試需求的過程是：讀取狀態(tài)轉(zhuǎn)換圖模型，遍歷所有狀態(tài)迀移路徑，對每個狀態(tài)迀 移路徑，從起始狀態(tài)開始，依次找出各個狀態(tài)的后續(xù)狀態(tài)和迀移條件，對選擇的每個狀態(tài)添 加已訪問過的標記，列出所有實現(xiàn)轉(zhuǎn)移的狀態(tài)形成功能測試需求，列出所有迀移條件形成 約束測試需求，輸出功能測試需求和約束測試需求。
[0011] 本發(fā)明提供了一種航天器測試需求自動生成方法，主要包括如下步驟：
[0012] 步驟一：針對航天器測試，定義系統(tǒng)、分系統(tǒng)、單機和模塊四個級別的測試需求，對 被測航天器按照模塊級，單機級，分系統(tǒng)級和系統(tǒng)級分別繪制基于UML的狀態(tài)轉(zhuǎn)換圖和交 聯(lián)圖，抽取狀態(tài)轉(zhuǎn)換圖和交聯(lián)圖對應的XML存儲結(jié)構(gòu)，并將狀態(tài)轉(zhuǎn)換圖和交聯(lián)圖轉(zhuǎn)換成XML 格式的模型存儲。
[0013] 在XML格式的交聯(lián)圖模型中，將被測產(chǎn)品以類視圖來描述，類視圖包含被測類、交 聯(lián)類、類之間的連接方式和接口數(shù)據(jù)；交聯(lián)圖模型的屬性中包括是否為被測類、類的ID、類 名和類的類型，與被測類連接的總線的屬性包括總線ID、總線名稱和總線類型，類的接口數(shù) 據(jù)包括接口 ID、接口名稱和接口類型。
[0014] 將被測系統(tǒng)的邏輯結(jié)構(gòu)轉(zhuǎn)換成由串行，并行，選擇和循環(huán)等單元構(gòu)成XML格式的 狀態(tài)轉(zhuǎn)換圖模型；將被測系統(tǒng)的物理結(jié)構(gòu)轉(zhuǎn)換成由黑盒、接口和總線等單元構(gòu)成的XML格 式的交聯(lián)圖模型。
[0015] 步驟二：判斷當前測試需求級別，若級別為模塊級或單機級，則讀取交聯(lián)圖模型， 遍歷交聯(lián)圖模型中所有被測產(chǎn)品，從中抽取被測產(chǎn)品對應的類名和被測產(chǎn)品的各個接口的 接口名稱；若級別為系統(tǒng)級或分系統(tǒng)級，則讀取交聯(lián)圖模型，遍歷模型中所有被測產(chǎn)品，從 交聯(lián)圖模型中抽取與被測產(chǎn)品相關聯(lián)的總線名稱，抽取被測產(chǎn)品對應的類名以及被測產(chǎn)品 的各個接口的接口名稱。
[0016] 步驟三：根據(jù)抽取到的被測產(chǎn)品對應的類名、總線名稱和接口名稱從已有的測試 需求庫中篩選出接口測試需求、總線測試需求和測試環(huán)境測試需求。
[0017] 步驟四：讀取狀態(tài)轉(zhuǎn)換圖模型，具體是：從狀態(tài)轉(zhuǎn)換圖中的起始狀態(tài)開始，依次找 出各個狀態(tài)的后續(xù)狀態(tài)和迀移條件，當選擇一個后續(xù)狀態(tài)時在該狀態(tài)上添加已訪問過的標 記。若一個狀態(tài)有兩個以上的后續(xù)狀態(tài)，則隨機選取一個沒有被標記已訪問過的狀態(tài)繼續(xù)， 直至遇到終止狀態(tài)，然后執(zhí)行步驟五。
[0018] 步驟五：判斷終止狀態(tài)是否還有未遍歷的路徑。若存在未遍歷的路徑，則返回距離 終止狀態(tài)最近的分支狀態(tài)，執(zhí)行步驟四；若不存在未遍歷的路徑，執(zhí)行步驟六。
[0019] 步驟六：在功能測試區(qū)域列出每一個實現(xiàn)轉(zhuǎn)移的狀態(tài)，形成功能測試需求，列舉完 成后執(zhí)行步驟七。
[0020] 步驟七：在約束測試區(qū)域依次列出約束測試需求，列舉完成后執(zhí)行步驟八。
[0021] 步驟八：將接口測試需求、總線測試需求、環(huán)境測試需求、功能測試需求和約束測 試需求合并成為測試需求分析表輸出。
[0022] 相比現(xiàn)有技術，本發(fā)明的優(yōu)點和積極效果在于：
[0023] (1)完備性：本發(fā)明通過航天器各類型的測試需求字段的完備定義，實現(xiàn)了對航 天器測試需求模型中所包含信息完備的抽取。通過自動化的測試需求文檔生成方法保障了 測試需求文檔內(nèi)容的完備性；
[0024] (2)易用性：本發(fā)明所給出的測試需求自動生成系統(tǒng)及其方法簡單易用，具有可 視化模塊，可在圖形界面進行操作，操作簡單易用，方法接口調(diào)用易用性強，方便與其它模 塊集成；
[0025] (3)通用性：本發(fā)明提出的一種航天器測試需求自動生成系統(tǒng)及其方法，在實際 應用中針對特定領域工程，采用此方法對交聯(lián)圖獲取和狀態(tài)轉(zhuǎn)換圖模型讀取接口進行適當 修改即可滿足本領域需求；
[0026] (4)實用性：在航天器測試中，由于實際工程的結(jié)構(gòu)特點，大量的靜態(tài)測試需求具 有通用性，而動態(tài)測試需求可以由系統(tǒng)功能實現(xiàn)進行分析，本發(fā)明提出的一種航天器測試 需求自動生成系統(tǒng)及其方法，可以根據(jù)測試需求模型自動生成測試需求，對幫助測試人員 對被測系統(tǒng)的理解，減少重復工作，方便測試需求編寫，提高工作效率具有重大意義，可以 滿足工程實際需求，具有一定的實用性；
[0027] (5)兼容性：本發(fā)明在設計時已經(jīng)考慮到在不同測試層級，并應用在不同型號系 統(tǒng)下使用，實現(xiàn)不同型號下的測試需求自動抽??；同時可以依照不同的項目，不同的安全等 級選擇不同的測試需求庫文件進行測試需求抽取。
[0028] (6)可復用性：本發(fā)明在設計時采用了 UML來描述被測產(chǎn)品，通過將UML轉(zhuǎn)換成為 XML文件進行讀取，由于UML和XML都是標準化的建模方法，該測試需求自動獲取方法具有 可復用性。
[0029] (7)可維護性：本發(fā)明采取接口類型和被測產(chǎn)品類型對測試需求庫中的測試需求 進行管理，可以方便測試人員測試需求庫。針對不同的型號，將通過測試經(jīng)驗獲得的新的測 試需求知識添加入測試需求庫。
[0030] (8)可擴展性：本發(fā)明通過定義被測產(chǎn)品ID和類型為后續(xù)的測試需求文檔管理提 供了文檔管理依據(jù)。
【附圖說明】
[0031] 圖1為本發(fā)明的測試需求自動生成系統(tǒng)的結(jié)構(gòu)示意圖；
[0032] 圖2為本發(fā)明的測試需求自動生成方法的整體流程圖。
[0033] 具體實施方法
[0034] 下文中將參考附圖并結(jié)合實施來詳細說明本發(fā)明。
[0035] 根據(jù)航天器測