分布式復(fù)雜系統(tǒng)軟件測試建模方法與應(yīng)用研究

， ，，

(1.海軍研究院，北京 100161； 2.中國船舶工業(yè)綜合技術(shù)經(jīng)濟(jì)研究院，北京 100081)

0 引言

分布式復(fù)雜系統(tǒng)軟件一般由多個(gè)單位分別研制各子系統(tǒng)，再由系統(tǒng)設(shè)計(jì)及集成單位進(jìn)行集成組合為上一層系統(tǒng)。不同軟件研制單位在研發(fā)軟件時(shí)會(huì)使用不同的平臺(tái)、不同的實(shí)現(xiàn)技術(shù)，當(dāng)這些軟件在組合為上級(jí)系統(tǒng)時(shí)，就會(huì)遇到集成與信息交互的問題。如果每一個(gè)軟件在與其他軟件集成與信息交互時(shí)，都單獨(dú)定義一套業(yè)務(wù)規(guī)則，那么會(huì)使得整個(gè)系統(tǒng)開發(fā)變得難以維護(hù)且沒有可持續(xù)性。另一方面，很多軟件需要使用相同的信息，有些軟件具有相似功能模塊，如果只是因?yàn)槭褂貌煌脚_(tái)開發(fā)的因素，而對(duì)這些信息或者功能模塊進(jìn)行全新的設(shè)計(jì)開發(fā)，既浪費(fèi)精力，也無法滿足后續(xù)類似型號(hào)的研制周期縮短的要求。為了實(shí)現(xiàn)跨平臺(tái)集成、互操作和復(fù)用，以及更有效的對(duì)整個(gè)復(fù)雜系統(tǒng)進(jìn)行分析和設(shè)計(jì)，縮短開發(fā)周期，分布式復(fù)雜系統(tǒng)軟件模型輔助開發(fā)新模式逐步廣泛應(yīng)用。

分布式復(fù)雜系統(tǒng)軟件測試任務(wù)十分艱巨，測試時(shí)間成為了影響研制進(jìn)度的重要因素，其完成質(zhì)量是整個(gè)系統(tǒng)質(zhì)量的重要保證。在系統(tǒng)研制過程中，軟件配置項(xiàng)及系統(tǒng)測試的介入時(shí)間晚，測試時(shí)間不足，在最后的系統(tǒng)聯(lián)調(diào)試驗(yàn)階段，其中絕大部分是軟件問題。隨著新研裝備的交付使用，后續(xù)型號(hào)裝備會(huì)陸續(xù)進(jìn)入研制狀態(tài)，其包括的組成部分更多，功能也相應(yīng)更多，然而研制周期卻進(jìn)行了壓縮，軟件配置項(xiàng)及系統(tǒng)測試工作需更早、更高質(zhì)量、自動(dòng)化地開展。

然而，針對(duì)這兩方面需求和現(xiàn)狀，傳統(tǒng)的測試方法顯得效率不足：

1)傳統(tǒng)的軟件測試方法自動(dòng)化程度低，主要由測試人員根據(jù)軟件開發(fā)文檔，人工分析、手動(dòng)設(shè)計(jì)編寫測試用例，搭建測試環(huán)境。效率低下，測試人員沒有足夠的時(shí)間關(guān)注測試設(shè)計(jì)。產(chǎn)生大量的測試需求、測試用例等，維護(hù)起來也相當(dāng)不便。

2)傳統(tǒng)的軟件測試方法在配置項(xiàng)測試及系統(tǒng)測試階段主要是基于軟件規(guī)約測試方法，其思想是根據(jù)軟件需求規(guī)約、軟件設(shè)計(jì)規(guī)約等生成測試用例，構(gòu)建外部數(shù)據(jù)模擬器等測試環(huán)境，測試軟件功能、性能和外部接口，判斷輸出是否符合要求。在這個(gè)過程中，軟件規(guī)約是測試生成和評(píng)估檢驗(yàn)的依據(jù)。在模型輔助開發(fā)中，軟件規(guī)約表現(xiàn)為各種分析、設(shè)計(jì)模型，如UML用例圖、UML交互圖、UML類圖、UML狀態(tài)圖、UML活動(dòng)圖等。在這種情況下，使用規(guī)約測試無法直接使用這些軟件分析及設(shè)計(jì)模型，而需要將這些分析及設(shè)計(jì)模型轉(zhuǎn)換為具體的要求，再生成測試用例，構(gòu)建測試環(huán)境等，這樣勢必造成效率低下，影響研制周期。

本文針對(duì)分布式復(fù)雜系統(tǒng)軟件的測試需求和現(xiàn)狀，以及傳統(tǒng)測試方法的不足，開展基于模型的全過程自動(dòng)化測試技術(shù)研究，提出分布式復(fù)雜系統(tǒng)軟件測試建模方法，能顯著的提高配置項(xiàng)及系統(tǒng)測試的效率，提高測試質(zhì)量。

1 測試建模方法研究總體框架

1.1 相關(guān)技術(shù)概念

1)軟件設(shè)計(jì)模型，是指在軟件研制過程中，在系統(tǒng)分析、需求分析、設(shè)計(jì)、編碼過程中所產(chǎn)生的各類對(duì)軟件功能、結(jié)構(gòu)或行為的從開發(fā)角度的抽象描述。以UML模型舉例，包括用例圖、類圖、序列圖、活動(dòng)圖、交互圖、狀態(tài)圖等。

2)模型輔助開發(fā)，是指整個(gè)軟件開發(fā)過程中使用大量對(duì)軟件系統(tǒng)的建模進(jìn)行輔助，各個(gè)階段的工作成果為各種設(shè)計(jì)模型，即對(duì)系統(tǒng)的各種描述。在模型輔助開發(fā)中，系統(tǒng)的可用信息使用設(shè)計(jì)模型進(jìn)行描述，如以UML用例圖、UML交互圖來表示軟件需求，以UML類圖、UML狀態(tài)圖、UML活動(dòng)圖來表示軟件設(shè)計(jì)。

3)軟件測試模型，是指在軟件測試過程中，在測試分析、測試設(shè)計(jì)與實(shí)現(xiàn)過程中所產(chǎn)生的各類對(duì)軟件功能、結(jié)構(gòu)或行為的從測試角度的抽象描述。包括測試需求模型、測試用例模型、測試環(huán)境模型、測試數(shù)據(jù)模型等。

1.2 總體研究思路

開展基于模型的全過程自動(dòng)化測試技術(shù)研究是當(dāng)前提高分布式復(fù)雜系統(tǒng)軟件測試效率、提升測試質(zhì)量、進(jìn)而保證軟件質(zhì)量的重要方向。該技術(shù)涉及到眾多領(lǐng)域(包括軟硬件仿真技術(shù)、軟件測試框架技術(shù)、軟件測試腳本技術(shù)等)，其核心基礎(chǔ)是基于軟件開發(fā)模型構(gòu)建全過程的軟件測試模型，其研究方案如圖1所示。

圖1 測試建模方法研究總體框架

1.2.1 測試模型調(diào)研與分析

調(diào)研現(xiàn)有的測試模型，包括被測系統(tǒng)模型、測試環(huán)境模型、測試執(zhí)行模型以及測試建模語言，為分布式復(fù)雜系統(tǒng)軟件測試模型定義奠定理論基礎(chǔ)。現(xiàn)有的軟件測試模型一般是局部的某一方面的對(duì)測試的描述，或單純測試用例生成，或單純測試環(huán)境，難以全過程使用；且由于這些模型需要再次對(duì)軟件系統(tǒng)進(jìn)行全新的建模，而沒有充分考慮與開發(fā)過程模型的繼承性與一致性，使得工作量增加，模型難以維護(hù)，也難以在項(xiàng)目之間復(fù)用。

1.2.2 分布式復(fù)雜系統(tǒng)軟件測試模型定義

1)測試信息分析:分析分布式復(fù)雜系統(tǒng)軟件配置項(xiàng)/系統(tǒng)測試涉及到的測試需求、測試用例、測試環(huán)境、測試數(shù)據(jù)等信息。對(duì)這些信息進(jìn)行分解，得到底層要素，對(duì)底層要素進(jìn)行歸納分類。

2)測試原子模型建立:針對(duì)各類底層要素，提取結(jié)構(gòu)、功能和行為等特征，對(duì)各類底層要素建立測試原子模型，規(guī)定符號(hào)表示，給出文本存儲(chǔ)方法。

3)測試模型定義:針對(duì)配置項(xiàng)/系統(tǒng)測試，對(duì)測試過程各階段涉到的測試信息定義相應(yīng)類別的測試模型，包括測試需求模型、測試用例模型、測試環(huán)境模型、測試數(shù)據(jù)模型等。給出由測試原子模型組合為各類測試模型的方式，規(guī)定各類測試模型的符號(hào)表示，給出文本存儲(chǔ)方法。

1.2.3 分布式復(fù)雜系統(tǒng)軟件測試建模方法

1)測試模型建模方法分析:分析分布式復(fù)雜系統(tǒng)軟件開發(fā)中所使用到的各類設(shè)計(jì)模型，針對(duì)研究內(nèi)容(1)給出的各測試模型(包括測試需求模型、測試用例模型、測試環(huán)境模型、測試數(shù)據(jù)模型等)，分析各設(shè)計(jì)模型與之的關(guān)系，以及各類測試模型之間的關(guān)系，從而進(jìn)一步得出各模型的建模方法，包括：通過設(shè)計(jì)模型轉(zhuǎn)換得出、通過軟件系統(tǒng)分析人工構(gòu)建、通過測試模型之間相互轉(zhuǎn)換得出。

2)基于設(shè)計(jì)模型轉(zhuǎn)換的測試建模:此類模型至少包括測試需求模型。分析分布式復(fù)雜系統(tǒng)軟件設(shè)計(jì)模型和測試模型的聯(lián)系和差異，在此基礎(chǔ)上建立設(shè)計(jì)模型到測試模型轉(zhuǎn)換的映射規(guī)則，給出由映射規(guī)則和設(shè)計(jì)模型轉(zhuǎn)換為測試模型的方法。建立映射時(shí)主要考慮結(jié)構(gòu)、行為及約束三個(gè)方面的因素。

3)基于軟件系統(tǒng)分析的測試建模:此類模型至少包括測試需求模型、測試環(huán)境模型、測試數(shù)據(jù)模型。根據(jù)分布式復(fù)雜系統(tǒng)軟件測試目標(biāo)，依據(jù)常規(guī)測試分析過程，對(duì)軟件的功能、結(jié)構(gòu)等逐層分解，形成測試原子模型。根據(jù)軟件測試模型定義，將這些測試原子組合為各類測試模型。

4)基于測試模型轉(zhuǎn)換的測試建模:此類模型至少包括測試用例模型。針對(duì)配置項(xiàng)/系統(tǒng)測試的測試用例設(shè)計(jì)要求，研究測試用例生成策略。根據(jù)測試用例生成策略、測試需求模型，給出測試用例模型的建模方法，包括測試執(zhí)行邏輯、測試數(shù)據(jù)、前置條件、預(yù)期輸出的生成。給出生成測試用例模型的文本存儲(chǔ)方法。

1.2.4 分布式復(fù)雜系統(tǒng)軟件測試建模輔助工具研制與應(yīng)用

對(duì)分布式復(fù)雜系統(tǒng)軟件測試建模方法進(jìn)行前景分析，開發(fā)分布式復(fù)雜系統(tǒng)軟件測試建模輔助工具，包括測試需求建模工具、測試數(shù)據(jù)建模工具、測試環(huán)境建模工具、測試用例生成輔助工具。

2 測試建模技術(shù)基礎(chǔ)研究

2.1 被測系統(tǒng)模型

被測系統(tǒng)模型是根據(jù)系統(tǒng)的需求、功能規(guī)格說明對(duì)系統(tǒng)進(jìn)行建模，根據(jù)模型自動(dòng)生成測試用例。其一般過程包括：建立模型、生成輸入、生成期望輸出。目前被測系統(tǒng)模型主要包括：

1)有限狀態(tài)機(jī)模型。有限狀態(tài)機(jī)(FSM)利用圖的遍歷算法，基于狀態(tài)覆蓋、轉(zhuǎn)換覆蓋、分支覆蓋等覆蓋準(zhǔn)則，自動(dòng)產(chǎn)生輸入序列。擴(kuò)展有限狀態(tài)機(jī)(EFSM)增加了操作以及狀態(tài)遷移的前置條件[1]，降低由純FSM模型帶來的狀態(tài)爆炸問題，但增加了構(gòu)造測試輸入的復(fù)雜性。目前FSM缺乏自動(dòng)構(gòu)造的支持手段。

2)UML模型?；赨ML模型的測試主要集中于狀態(tài)圖和順序圖。狀態(tài)圖強(qiáng)調(diào)對(duì)復(fù)雜實(shí)時(shí)系統(tǒng)建模，提供了層次狀態(tài)機(jī)框架，并提供并發(fā)機(jī)制描述?；陧樞驁D生成測試用例，通常是將其轉(zhuǎn)化為流程圖，采用基于路徑的方法導(dǎo)出基本路徑集，每一條路徑即測試用例。UML是一種形式化和半形式化相結(jié)合的建模語言，利用可視化建模元素可方便建立系統(tǒng)的圖示模型，不同層次的模型可以重用?；赨ML的軟件測試成為研究熱點(diǎn)[2]。

3)馬爾可夫鏈模型。馬爾可夫鏈?zhǔn)且环N以統(tǒng)計(jì)理論為基礎(chǔ)的統(tǒng)計(jì)模型。基于馬爾可夫鏈的測試中比較有代表性的是基于使用剖面的可靠性測試用例自動(dòng)生成方法。馬爾可夫鏈實(shí)際上是一種有限狀態(tài)機(jī)，只是在對(duì)應(yīng)的遷移上標(biāo)有概率特征?？梢愿鶕?jù)狀態(tài)間的遷移概率自動(dòng)產(chǎn)生測試用例，分析測試結(jié)果對(duì)可靠性指標(biāo)進(jìn)行度量[3]。

4)Petri網(wǎng)模型。Petri網(wǎng)易于表示系統(tǒng)變化發(fā)生的條件和變化發(fā)生后的系統(tǒng)狀態(tài)，但不易表示系統(tǒng)中數(shù)據(jù)域或?qū)傩缘木唧w變化或運(yùn)算。Petri網(wǎng)支持描述離散事件系統(tǒng)的動(dòng)態(tài)行為，支持并發(fā)和異步性，既有嚴(yán)格的數(shù)學(xué)表述，又有直觀的圖形表達(dá)，在建模、性能分析以及測試中逐步得到應(yīng)用。也有研究者提出一種UML狀態(tài)圖和Petri網(wǎng)結(jié)合的測試用例生成方法[4]，但是總體來說，該方法理論性較強(qiáng)，欠缺支持工具。

2.2 測試環(huán)境建模仿真技術(shù)

測試環(huán)境建模仿真指的是對(duì)被測軟件的外圍測試環(huán)境進(jìn)行建模并仿真實(shí)現(xiàn)。測試環(huán)境建模方法有兩種：一是直接程序設(shè)計(jì)即手寫代碼，二是可視化圖形建模。采用直接程序設(shè)計(jì)方法要求建模者既要有較多的專業(yè)知識(shí)，又要有豐富的計(jì)算機(jī)編程經(jīng)驗(yàn)。而采用可視化圖形建模方法，則無需建模者具有較高編程水平，因其直觀、快速、高效而受到日益普遍的重視。

測試環(huán)境通常與仿真工具相集成，如Matlab/Simulink仿真工具、Tech S.A.T推出的第二代航電開發(fā)系統(tǒng)ADS-2、北京航空航天大學(xué)開發(fā)的嵌入式通用仿真測試環(huán)境GESTE、中船工業(yè)軟件質(zhì)量與可靠性測評(píng)中心研制的復(fù)雜系統(tǒng)軟件自動(dòng)化測試平臺(tái)SATP++等。

測試環(huán)境建模仿真工具提供了豐富的模型庫和可視化的建模環(huán)境，通常無需編程即可自動(dòng)生成模型代碼，具有通用化程度高、建模簡單方便等優(yōu)點(diǎn)。但缺點(diǎn)是通用仿真建模工具普遍價(jià)格昂貴，針對(duì)性較差，難以適用不同領(lǐng)域的專業(yè)知識(shí)，使其推廣利用受到一定的限制。如果能充分利用各領(lǐng)域內(nèi)的專業(yè)知識(shí)，針對(duì)特定的領(lǐng)域建立組件級(jí)的仿真測試環(huán)境模型，則可以進(jìn)一步提高仿真模型的構(gòu)建效率，并相應(yīng)地提高仿真模型的再利用率。

2.3 測試執(zhí)行驅(qū)動(dòng)建模技術(shù)

測試執(zhí)行驅(qū)動(dòng)建模指的是按照測試用例步驟推進(jìn)測試過程自動(dòng)執(zhí)行，加載測試輸入數(shù)據(jù)，并收集實(shí)際輸出數(shù)據(jù)。測試執(zhí)行驅(qū)動(dòng)模型一般分為兩類：數(shù)據(jù)源驅(qū)動(dòng)模型和數(shù)據(jù)加工驅(qū)動(dòng)模型。

1)數(shù)據(jù)源驅(qū)動(dòng)模型，在測試進(jìn)行中，由測試環(huán)境加載已生成好的測試數(shù)據(jù)，按照測試數(shù)據(jù)的時(shí)間標(biāo)簽，調(diào)用I/O服務(wù)模塊將其發(fā)送至被測系統(tǒng)。數(shù)據(jù)源驅(qū)動(dòng)模型適用于規(guī)律非常復(fù)雜且不便于數(shù)據(jù)建模，以及計(jì)算非常消耗CPU資源的測試數(shù)據(jù)。通過在時(shí)間上將測試數(shù)據(jù)的產(chǎn)生與測試相互分離，降低了測試環(huán)境的計(jì)算強(qiáng)度，有效地節(jié)省了CPU資源。這類測試驅(qū)動(dòng)方式的數(shù)據(jù)來源可以是長期積累下來的經(jīng)驗(yàn)數(shù)據(jù)，也可以是由專門的工具生成的數(shù)據(jù)。但是它也有一定局限性，會(huì)浪費(fèi)仿真測試環(huán)境的存儲(chǔ)資源；不能動(dòng)態(tài)的響應(yīng)測試進(jìn)行中的情況等。

2)數(shù)據(jù)加工驅(qū)動(dòng)模型，在測試過程中由該模型進(jìn)行運(yùn)算并實(shí)時(shí)產(chǎn)生數(shù)據(jù)，然后調(diào)用I/O服務(wù)模塊，將生成的測試數(shù)據(jù)發(fā)送到被測系統(tǒng)。由于該類模型需要根據(jù)外界提供的輸入采取相應(yīng)的計(jì)算來產(chǎn)生測試數(shù)據(jù)，就像一個(gè)數(shù)據(jù)加工廠，輸入的是“數(shù)據(jù)原料”，產(chǎn)生的是“數(shù)據(jù)成品”。數(shù)據(jù)加工驅(qū)動(dòng)有效的節(jié)省了測試環(huán)境的存儲(chǔ)資源。在軟件測試中，軟件正確性無法根據(jù)一次單獨(dú)的輸出來判斷，而是需要一組輸出和幾個(gè)時(shí)間段的輸出的時(shí)間特性關(guān)系來判斷，在該類系統(tǒng)中，在一個(gè)單獨(dú)輸出中的小“錯(cuò)誤”或是偏離會(huì)在一段時(shí)間內(nèi)被后面的輸出補(bǔ)償，無法確定一次獨(dú)立的輸出到底是否正確。因此就要求在能評(píng)估輸出結(jié)果之前，測試運(yùn)行必須持續(xù)相當(dāng)長的一段的時(shí)間。數(shù)據(jù)加工驅(qū)動(dòng)模型可以在線的生成大量的測試輸入數(shù)據(jù)，而不需要在測試運(yùn)行之前就生成大量的輸入數(shù)據(jù)。

2.4 測試建模語言研究

2.4.1 U2TP建模語言

自2001年起，OMG擴(kuò)展UML描述測試模型的領(lǐng)域無關(guān)的標(biāo)準(zhǔn)建模語言，提出UTP(UML Testing Profile)規(guī)范，規(guī)定了UTP的結(jié)構(gòu)、內(nèi)容、基于MOF(Meta Object Facility)的元模型定義、用例及使用方法。但新版的U2TP(UML 2.0 Testing Profile，2003年發(fā)布)仍然沒有完備的語義能夠描述各種測試相關(guān)的概念。

U2TP在UML元模型基礎(chǔ)上添加了與測試相關(guān)的一系列概念定義，豐富了UML在測試領(lǐng)域的建模與應(yīng)用。U2TP主要提出以下4個(gè)部分的測試概念來描述測試的共同特征：測試架構(gòu)(Test Architecture)、測試行為(Test Behavior)、測試數(shù)據(jù)(Test Data)和時(shí)間概念(Time Concepts)。

測試架構(gòu)是對(duì)系統(tǒng)測試的整體環(huán)境搭建以及測試平臺(tái)所包含的基本模塊的靜態(tài)描述[5]。包括：測試環(huán)境(Test context)、測試配置(Test configuration)、測試組件(Test Component)、被測系統(tǒng)(SUT)、裁決器(Arbiter)、調(diào)度器(Scheduler)、公用部分(Utility Part)。

測試行為定義的是測試平臺(tái)執(zhí)行測試過程的動(dòng)態(tài)描述。包括：測試控制(Test control)、測試用例(Test Case)、測試調(diào)用、測試目標(biāo)(Test objective)、激勵(lì)(Stimulus)、觀察(observation)、協(xié)作(Coordination)、缺省動(dòng)作(Default)、判定(Verdict)、驗(yàn)證行為(Validation Action)、記錄行為(Log Action)、測試記錄(Test Log)。

測試數(shù)據(jù)定義了測試過程中用于測試組件與被測系統(tǒng)交互的數(shù)據(jù)相關(guān)的概念。在實(shí)際測試中測試數(shù)據(jù)往往根據(jù)被測系統(tǒng)的需求而確定，因此無法進(jìn)行統(tǒng)一的定義。U2TP只對(duì)測試過程中與測試數(shù)據(jù)相關(guān)的一些公有概念進(jìn)行定義。包括：通配符(Wildcard)、數(shù)據(jù)池(DataPool)、數(shù)據(jù)分區(qū)(Data Partitions)、數(shù)據(jù)選擇(Data selector)、編碼規(guī)則(Coding Rule)。

為了能夠?qū)y試步驟執(zhí)行進(jìn)行時(shí)間管理與同步，需要對(duì)測試的操作與執(zhí)行定義時(shí)間上的約束關(guān)系。測試環(huán)境通過量化時(shí)間來管理單個(gè)測試步驟的執(zhí)行等待時(shí)間與判定。測試組件之間通過共同的時(shí)鐘保證測試步驟執(zhí)行的同步。時(shí)間概念包括定時(shí)器(Timer)、時(shí)區(qū)(Time Zone)。

2.4.2 TTCN-3

TTCN-3是ETSI(歐洲電信標(biāo)準(zhǔn)化組織)發(fā)布的針對(duì)測試的專用語言[6]。ETSI發(fā)布的有關(guān)TTCN-3的標(biāo)準(zhǔn)包含一系列文檔，此后TTCN-3發(fā)展迅速，得到了廣泛應(yīng)用，TTCN-3標(biāo)準(zhǔn)也頻繁的改進(jìn)迭代，目前的最新版是2009年的TTCN-3標(biāo)準(zhǔn)4.1。TTCN-3指的是測試及測試控制表示法，靈活且功能強(qiáng)大，具備豐富類型系統(tǒng)等，但最大的不足之處是對(duì)于測試概念是基于文本的描述形式，難以理解，使用不便。

3 分布式復(fù)雜系統(tǒng)軟件測試模型

3.1 分布式復(fù)雜系統(tǒng)軟件測試模型要素分析

分布式復(fù)雜系統(tǒng)軟件配置項(xiàng)/系統(tǒng)測試各種信息涉及的種類多，包括測試需求、測試環(huán)境、測試用例、測試數(shù)據(jù)等。各種測試信息逐層分解，又可包含更多的下層要素，這些要素之間存在一定的關(guān)聯(lián)關(guān)系，且各要素功能、結(jié)構(gòu)、行為上的特性存在多種表現(xiàn)方式。

測試環(huán)境包括測試組件(與被測系統(tǒng)交互的外圍節(jié)點(diǎn))、測試部署(測試組件之間以及測試組件和被測系統(tǒng)之間連接關(guān)系的集合)、測試調(diào)度器、測試裁決器等；測試部署包含各種交互接口及其連接關(guān)系，交互接口又包括以太網(wǎng)口、串口、CAN口等。

測試用例包括測試執(zhí)行邏輯(測試步驟及其關(guān)系)、測試數(shù)據(jù)、前置條件、預(yù)期輸出；測試邏輯中又包括順序、并發(fā)、反饋、周期執(zhí)行方式等；測試數(shù)據(jù)包括單變量、單一類型數(shù)組、復(fù)雜類型數(shù)組等；單變量又包括多種類型。

可以說，測試信息是非常復(fù)雜、繁多的，現(xiàn)有的各類基于模型的相關(guān)測試技術(shù)一般是局部的某一方面的對(duì)測試的描述，或單純測試用例，或單純測試環(huán)境，另外也沒有充分的考慮與開發(fā)過程模型的一致性。而測試模型是基于模型測試的核心，需要定義與開發(fā)過程模型相一致的、規(guī)范、完備的測試模型。

3.2 分布式復(fù)雜系統(tǒng)軟件測試模型定義

測試模型需完整、規(guī)范描述測試信息；另一方面測試模型不能脫離開發(fā)過程，應(yīng)與設(shè)計(jì)模型相一致，并且不能太復(fù)雜，可以工程應(yīng)用，也有利于測試用例生成，本文提出的定義策略如下：

1)模型完整性依賴于軟件測試信息分析是否完備。在分析軟件測試信息時(shí)，以歷史軟件測試項(xiàng)目的數(shù)據(jù)作為基礎(chǔ)，并參考軟件測試項(xiàng)目數(shù)據(jù)，對(duì)測試信息進(jìn)行自頂向下、層層細(xì)化的詳細(xì)分析，并通過測試人員及開發(fā)人員不同的視角進(jìn)行，從而得出各種分散的測試信息知識(shí)。對(duì)分析得出的分散知識(shí)點(diǎn)進(jìn)行歸納、提煉，得到完備詳細(xì)的測試信息分解體系，為抽象模型定義提供基礎(chǔ)。分解分析主要包括以下方面：

(1)測試需求包括分解測試項(xiàng)、測試項(xiàng)輸入、測試項(xiàng)輸出、測試項(xiàng)充分性要求等；

(2)測試環(huán)境包括測試組件、測試部署、測試調(diào)度器、測試裁決器等；

(3)測試部署包含各種交互接口及其連接關(guān)系；

(4)交互接口，包括CAN接口、以太網(wǎng)接口、RS232接口等；

(5)測試用例包括測試執(zhí)行邏輯(測試步驟及其關(guān)系)、測試數(shù)據(jù)、前置條件、預(yù)期輸出；

(6)測試執(zhí)行邏輯中包括順序、并發(fā)、反饋、周期執(zhí)行方式等；

(7)測試數(shù)據(jù)包括數(shù)據(jù)類型、數(shù)據(jù)長度、數(shù)據(jù)范圍等；

(8)數(shù)據(jù)類型包括單變量、單一類型數(shù)組、復(fù)雜類型數(shù)組等。

2)測試模型不能脫離開發(fā)過程，應(yīng)與設(shè)計(jì)模型相一致。在獲取完備詳細(xì)的測試信息分解體系后，盡量參考設(shè)計(jì)模型建立測試原子模型、定義測試模型，使得測試模型語義規(guī)范、清晰、準(zhǔn)確。在定義測試原子模型時(shí)，可以參考UML的模型元素、TTCN測試和測試控制語言的類型元素；在定義測試模型時(shí)，可參考各類UML設(shè)計(jì)模型(用例圖、交互圖、活動(dòng)圖等)、UML 2.0 Test Profile測試剖面。

3)為了避免測試模型過于復(fù)雜，采取一定的簡化措施。如對(duì)于測試數(shù)據(jù)模型，主要考慮數(shù)據(jù)字段的物理含義，而少考慮或不考慮字段長度、字段MSB等屬性信息，減少了復(fù)雜性，也保證了測試用例生成時(shí)具有足夠的信息可用。

4)可以考慮在測試模型中增加測試用例生成策略的相應(yīng)的模型元素屬性，以利于模型解析及測試用例生成[7]。如預(yù)置一定的設(shè)計(jì)策略，如等價(jià)類劃分、邊界值分析等，為以測試用例生成策略解析測試用例生成模型提供便利。

4 基于設(shè)計(jì)模型轉(zhuǎn)換的測試建模方法

4.1 設(shè)計(jì)模型與測試模型的相似性分析

設(shè)計(jì)模型和測試模型都體現(xiàn)了系統(tǒng)需求，但是應(yīng)用領(lǐng)域、應(yīng)用目的不同，導(dǎo)致設(shè)計(jì)模型與測試模型之間存在很多聯(lián)系和差異，分析其關(guān)聯(lián)和差異是模型轉(zhuǎn)換的必由之路。由于設(shè)計(jì)模型和測試模型的應(yīng)用領(lǐng)域都具有龐大的體系，設(shè)計(jì)模型和測試模型本身也非常復(fù)雜，特別是針對(duì)分布式復(fù)雜系統(tǒng)軟件這樣龐大的系統(tǒng)，包含多個(gè)分系統(tǒng)，分析兩種模型的關(guān)聯(lián)和差異具有非常大的難度。采用的解決途徑是分析設(shè)計(jì)模型與測試模型之間的區(qū)別和聯(lián)系，并在此基礎(chǔ)上實(shí)現(xiàn)從設(shè)計(jì)模型到測試模型的映射，從而構(gòu)建軟件測試模型。

4.1.1 設(shè)計(jì)模型與測試模型的相似點(diǎn)

設(shè)計(jì)模型和測試模型都體現(xiàn)了系統(tǒng)需求，建模都需考慮結(jié)構(gòu)、行為及約束三個(gè)方面，因此設(shè)計(jì)模型和測試模型可以從這三個(gè)方面考慮其相似之處。

1)結(jié)構(gòu)方面：設(shè)計(jì)模型中的結(jié)構(gòu)圖包括類圖、對(duì)象圖、構(gòu)件圖、包圖等；測試模型中需求模型指對(duì)軟件功能、性能等測試需求，可以體現(xiàn)在設(shè)計(jì)模型的類圖上；測試模型中測試環(huán)境模型指與被測軟件交互的類、對(duì)象、構(gòu)件等組成的測試配置，這些測試配置可以體現(xiàn)到設(shè)計(jì)模型中類、對(duì)象、構(gòu)件圖上。

2)行為方面：設(shè)計(jì)模型使用活動(dòng)圖、交互圖、狀態(tài)圖等描述系統(tǒng)的行為，這些行為可以體現(xiàn)在測試模型中測試用例模型上。

3)約束方面：測試模型的約束主要體現(xiàn)在測試數(shù)據(jù)模型上，測試數(shù)據(jù)模型可認(rèn)為是設(shè)計(jì)模型中行為視圖下的某個(gè)約束條件下的行為，測試數(shù)據(jù)是約束條件的等價(jià)劃分。

4.1.2 設(shè)計(jì)模型與測試模型的異同點(diǎn)

設(shè)計(jì)模型與測試模型描述的是不同領(lǐng)域內(nèi)的概念[8]。兩者除了上述相似的概念外，測試模型還需對(duì)設(shè)計(jì)模型進(jìn)行擴(kuò)展來描述測試域，測試模型特有的概念有：

1)測試目標(biāo)，測試目標(biāo)是生產(chǎn)測試用例的依據(jù)，通常測試設(shè)計(jì)策略，如測試用例設(shè)計(jì)方法，以方法覆蓋準(zhǔn)則。

2)判定是對(duì)測試用例執(zhí)行結(jié)果的判定，至少包括通過、測試結(jié)果與期望結(jié)果不一致兩種測試結(jié)果。

4.2 設(shè)計(jì)模型到測試模型的映射

設(shè)計(jì)模型和測試模型之間存在關(guān)聯(lián)，通過模型轉(zhuǎn)換將設(shè)計(jì)模型轉(zhuǎn)換為測試模型，可快速建立可復(fù)用、可擴(kuò)展、可演化的測試模型。直接使用這些開發(fā)模型，轉(zhuǎn)換為測試過程中所需要的測試需求、測試用例等，必定能大大提高測試的效率，實(shí)現(xiàn)全過程的自動(dòng)化測試。

對(duì)于相似點(diǎn)可以直接從設(shè)計(jì)模型演化到測試模型；對(duì)于不同點(diǎn)則建立測試策略完善測試模型。從設(shè)計(jì)模型到測試模型的具體映射過程如下：

1)測試結(jié)構(gòu)映射:設(shè)計(jì)模型中用例圖、類圖表示軟件需求，將用例圖、類圖直接映射為測試模型中需求模型；設(shè)計(jì)模型與測試模型中被測件交互的包、構(gòu)件、類映射到測試模型中的測試數(shù)據(jù)模型、測試環(huán)境模型。

2)測試行為映射:設(shè)計(jì)模型中狀態(tài)圖中的每個(gè)狀態(tài)、每個(gè)遷移，活動(dòng)圖中的每個(gè)活動(dòng)，交互圖中的執(zhí)行順序等映射為測試目標(biāo)，以及映射為測試用例模型中被測件與測試構(gòu)件間的交互序列；設(shè)計(jì)模型中狀態(tài)、活動(dòng)、交互的前置條件映射測試用例中的前置條件，后置條件映射測試期望結(jié)果；根據(jù)測試執(zhí)行中可能出現(xiàn)的結(jié)果與期望結(jié)果的比較，設(shè)置相應(yīng)的判定值。

3)測試數(shù)據(jù)映射:設(shè)計(jì)模型中行為圖的約束條件分解為數(shù)據(jù)劃分，與測試行為關(guān)聯(lián)，并根據(jù)不同測試策略映射為測試模型中測試數(shù)據(jù)模型。其中的測試策略如等價(jià)類劃分、隨機(jī)測試、邊界值等。

5 應(yīng)用前景分析

基于模型的全過程自動(dòng)化測試技術(shù)可以實(shí)現(xiàn)較高的經(jīng)濟(jì)與社會(huì)效益，一方面針對(duì)單個(gè)項(xiàng)目可以實(shí)現(xiàn)全過程的自動(dòng)化測試，大大提高測試效率；另一方面針對(duì)具有延續(xù)性的項(xiàng)目，可以實(shí)現(xiàn)測試資源復(fù)用，也間接提高了測試效率。

1)分布式復(fù)雜系統(tǒng)軟件研制過程中模型輔助開發(fā)逐步廣泛應(yīng)用，基于模型的全過程自動(dòng)化測試可以直接復(fù)用設(shè)計(jì)模型，轉(zhuǎn)換為測試模型，進(jìn)而利用自動(dòng)化手段生成測試用例、仿真測試環(huán)境、自動(dòng)驅(qū)動(dòng)測試執(zhí)行。提高了測試自動(dòng)化程度，也使配置項(xiàng)及系統(tǒng)測試可以盡早介入，幫助設(shè)計(jì)人員較早的發(fā)現(xiàn)設(shè)計(jì)中的缺陷以及模型本身的問題，提高系統(tǒng)開發(fā)與測試的效率。

2)單純的文檔形式的測試需求、測試用例集與測試數(shù)據(jù)可讀性不強(qiáng)，無法幫助測試人員很好的理解被測系統(tǒng)設(shè)計(jì)，而測試模型可以提供清晰準(zhǔn)確的系統(tǒng)設(shè)計(jì)，幫助測試人員了解被測系統(tǒng)，將時(shí)間花在重要的測試用例設(shè)計(jì)環(huán)節(jié)，而非湮沒在手工生成大量的測試用例工作中，提高測試的質(zhì)量與效率[9]。

3)測試模型源自于設(shè)計(jì)模型，當(dāng)軟件功能發(fā)生變化需要調(diào)整設(shè)計(jì)模型時(shí)(這種情況在分布式復(fù)雜系統(tǒng)軟件開發(fā)中經(jīng)常出現(xiàn))，測試模型也能隨之進(jìn)行相應(yīng)的修改來適應(yīng)新的測試需求。因此在測試過程中，只需維護(hù)測試模型，而無需直接維護(hù)測試需求及大量的測試用例，減少了維護(hù)工作量。

4)采用基于模型的全過程自動(dòng)化測試方法形成可復(fù)用、組件化的測試模型(尤其是面向特定應(yīng)用領(lǐng)域的專有測試模型)，以及相應(yīng)的測試工具集，這也為在后續(xù)型號(hào)軟件測試中復(fù)用前期測試成果提供了可能性和手段。

另外，對(duì)于軟件測試來說，長遠(yuǎn)目標(biāo)則是實(shí)現(xiàn)測試組件標(biāo)準(zhǔn)化、通用化、型譜化。針對(duì)分布式復(fù)雜系統(tǒng)軟件，由于其應(yīng)用特點(diǎn)，很多采用了面向?qū)ο蟪绦蛘Z言進(jìn)行設(shè)計(jì)開發(fā)，呈現(xiàn)出構(gòu)件化、分布式、跨平臺(tái)等特點(diǎn)，為解決跨平臺(tái)的通信、計(jì)算等問題，中間件技術(shù)逐步被廣泛應(yīng)用。為了實(shí)現(xiàn)不同中間件、平臺(tái)之間的集成和互操作，模型輔助開發(fā)模式被逐步廣泛采用。針對(duì)這種模式開發(fā)的軟件，也十分適合采用基于模型的全過程自動(dòng)化測試技術(shù)。因此，分布式復(fù)雜系統(tǒng)軟件測建模方法在軟件開發(fā)機(jī)構(gòu)及測試機(jī)構(gòu)中都具廣闊的應(yīng)用前景。

6 小結(jié)

分布式復(fù)雜系統(tǒng)軟件測試周期短、測試質(zhì)量要求高，自動(dòng)化測試及測試資源復(fù)用需求迫切。本文研究分布式復(fù)雜系統(tǒng)軟件測試模型，給出適合于分布式復(fù)雜系統(tǒng)軟件測試描述的各類軟件測試模型及建模方法，包括對(duì)測試需求、測試用例、測試環(huán)境、測試數(shù)據(jù)等的描述，為自動(dòng)化測試、提高測試效率提供方法和手段。針對(duì)分布式復(fù)雜系統(tǒng)軟件，相對(duì)于傳統(tǒng)的軟件測試方法，本文提出基于模型的全過程自動(dòng)化測試方法，能顯著的提高配置項(xiàng)及系統(tǒng)測試的效率，提高測試質(zhì)量，進(jìn)而保證型號(hào)軟件質(zhì)量，具有重大的經(jīng)濟(jì)與社會(huì)效益。