基于ＵＭＬ的嵌入式軟件測試用例生成方法研究

收稿日期：2007-09-12；修回日期：2007-12-07

基金項目：國家“十一五”國防預研基金資助項目（513190701）

作者簡介：殷永峰(1978-)，男，山東濰坊人，博士，主要研究方向為軟件可靠性、嵌入式軟件測試技術(yyf@buaa.edu.cn)；劉斌(1967-)，男，教授，博士，主要研究方向為軟件可靠性、嵌入式軟件測試技術；姜同敏(1949-)，男，教授，博導，主要研究方向為系統工程、環境工程.*

(北京航空航天大學 工程系統工程系，北京 100083)

摘 要：基于嵌入式軟件實時性、嵌入式和反應式等特點，對UML進行了實時性擴展，運用多種UML視圖描述嵌入式系統的結構和行為，提出了如何從基于UML的模型中自動生成測試用例的設計思路。

關鍵詞：統一建模語言；面向對象；嵌入式軟件；測試場景；測試用例

中圖分類號：TP311

文獻標志碼：A

文章編號：1001-3695(2008)10-3018-04

Test cases generation of embedded software testing based on UML technique

YIN Yong-feng，LIU Bin，JIANG Tong-min

(Dept. ofSystem Engineering of Engine Technology， Beihang University， Beijing 100083， China)

Abstract:To consider the feature of embedded software， such as real-time and interactive， this paper made real-time extension to UML， and used many kinds of UML diagrams to describe the structure and action of embedded software， further more， addressed some ideals to the process of how to generate test cases from the UML models automatically.

Key words:UML(unified modeling language);object-oriented；embedded software;test scenario;test case

0 引言

目前，國內外提出了很多基于UML模型自動生成測試用例的解決方法。Cavarra等人提出了用UML對測試過程進行建模，需要考慮結合測試意圖、測試約束以及一些覆蓋準則[1]；I-Logix公司開發的Rhapsody，是一個基于UML支持實時嵌入式系統全過程面向對象開發的CASE工具，能根據模型自動生成嵌入式系統代碼。國內也有提出用UML活動圖來描述復雜系統的操作流以及轉換成用例模型的三級轉換過程[2]，還有基于UML狀態圖的實時嵌入式軟件測試用例生成技術[3]。采用有效的建模方法描述問題域，并選擇合適的測試策略，是自動化生成高質量測試用例的關鍵。由于實時嵌入式軟件日益龐大和復雜，傳統的測試技術已經不堪重負了，面向對象的軟件測試技術引入以及應用UML對測試過程建模成為了解決嵌入式軟件測試難題的重要環節。

本文提出了一種基于UML的測試用例生成方法，針對嵌入式軟件測試的需要給出了具體的UML擴展思路和建模方法，并且探討了生成測試用例的過程以及依據的準則。

1 UML實時擴展

11 UML擴展機制

盡管UML提了很多豐富的視圖來對系統建模，但也很難表示諸多領域的種種模型，這些模型可能有著細微的差別，用已有的模型來描述，可能使測試和開發人員對系統的理解也產生偏差。UML提供了擴展機制來根據實際的項目定制自己的UML。UML的擴展機制包括構造型、標記值和約束三個部分[4]。UML的這些擴展機制方便用戶構造更復雜的模型，或者描述某些細微的語義，所以這種擴展可以應用到各種領域，如嵌入式系統、Web應用或測試等領域。

12 嵌入式系統的特點

嵌入式系統往往具有小型化、實時性、并發性、可靠性高等特點，而且有很多交聯子系統，因此嵌入式軟件系統的開發與測試要比非嵌入式系統困難得多，一般的工具難以對其進行系統測試。目前比較公認的方法是軟件仿真測試環境，但該方法的測試輸入主要還是靠人工輸入或人工編寫腳本來完成。因此能否將UML建模的自動化測試技術應用到嵌入式軟件測試中是一件有意義的事情。

13 實時擴展方案

盡管UML具有強大的描述能力，但它畢竟不是專門針對嵌入式領域的，因此在描述嵌入式系統時，有一些不足之處。針對實時系統的特點，ObjectTime和Rational公司合作開發了實時UML。實時UML主要引入了以下三個概念：

a）封裝體。一種特殊的類，它與類的區別在于通信機制，每個封裝體上至少有一個端口與外界通信。

b）端口。位于封裝體邊界的接口，可以用于發送和接收消息。

c）連接器。以信號為基礎的協議的信道，用于連接兩個不同的端口。在UML中，連接器由關聯表示。

基于實時UML提出的這三個概念可以很好地對嵌入式系統的結構進行靜態建模。根據嵌入式軟件實時性的特點和系統動態建模的需要，提出了以下擴展方案：引入時鐘，時鐘與系統的活動密切相關，并且根據系統的運行剖面的不同分全局時鐘和局部時鐘。全局時鐘從測試開始計時，而局部時鐘記錄了測試執行過程中某個活動或調用某個功能開始經歷的時間，系統進入到每個活動都會重置局部時鐘一次。為了解決受時間約束的活動，引入了時間服務（定時器）。定時器將時間需求轉換成以信號為基礎的事件來觸發一定的動作。當一個任務需要啟動一個時間相關的活動時(外部激勵、內部事件、超時事件、延時動作)，它向時間服務器發送一個特殊的定時消息，包括一次性定時器和周期性定時器兩種。

2 基于UML的嵌入式軟件測試用例設計過程

測試用例是指根據某個測試要求設計的用于驅動系統執行某個特定動作所需要的操作和輸入數據的集合。通常測試用例包括一個特定的測試場景和與之相對應的一組輸入數據。測試場景描述了系統的一個特定的執行流程，測試時往往需要根據一定的測試要求設計所有可能的測試場景。測試數據是對測試場景中那些外部請求或內部交互賦予具體的值。為此，需要從靜態和動態兩個方面來考慮建模，生成構成測試用例必需的兩個部分。

對嵌入式軟件測試進行建模時，除了要分析系統的軟件需求規格說明之外還要參照接口控制文檔（interface control document，ICD）文檔，ICD文檔中說明了被測系統有哪些交聯的I/O設備和I/O參數，ICD文檔是嵌入式系統靜態建模的主要依據。圖1給出了基于UML的測試用例設計過程。其中對被測系統(software under test，SUT)的建模中，動態建模生成所有的測試場景，靜態建模生成與測試場景對應的所有輸入操作的測試數據集。根據一定的優化組合策略生成最終的測試用例集。

3 基于UML的嵌入式軟件測試建模方法研究

31 靜態建模

類圖是面向對象系統建模中最常用的圖，它展示了一組類、接口、協作和它們之間的關系。在需求分析中，類圖表述系統中對象與對象間的關系，主要表述軟件系統的靜態結構。

根據實時UML提出的三個概念，在類圖的基礎上定義如下兩個構造型：

a）<>構造型。用于對嵌入式系統硬件設備的通用元素建模，應用于類圖中的類。被測系統和其交聯設備都用此構造型進行建模。設備的特性、變量可以在屬性中配置。設備與設備、設備與外界的交互行為可以在操作中配置。

b)<>構造型。用于對嵌入式系統通信總線的通用元素建模，應用于類圖的泛化關系。設備與設備之間的所有通信總線都用此構造型進行建模，<>用帶箭頭的連線表示，用來連接兩個<>。箭頭的方向表示數據傳送的方向。如果設備之間存在多種連接，可以在兩個<>中引多根<>進行連接。為了表示總線傳遞的數據類型，加入了如下標記值：

connector.type=value

//用來表示通信的類型，如RS-422、MIL-STD-1553等

為了盡量不修改UML元模型的圖形元素，沒有定義端口的構造型，默認<>與<>的接觸點表示設備與外界的端口，根據<>的方向確定端口是用來接收還是發送數據的。

如圖2表示了基于擴展UML類圖表示的某自動取款機系統中被測系統（SUT）與三個交聯設備的靜態模型。通過這種靜態建模，可以很好地分析被測系統所有可能的輸入/輸出情況，得到測試時需要的輸入數據。

32 動態建模

UML順序圖展示了參與者與系統、系統與系統之間所進行的交互行為，因此順序圖可以作為系統級測試的測試模型。但是由于嵌入式系統的控制關系往往很復雜，順序圖在表示這種復雜的控制時顯得很困難。筆者提出通過活動圖與順序圖建模技術的組合方式來解決這個問題。其中活動圖的每個基本活動都是一個獨立的順序圖。結合活動圖的優點，就可以通過活動圖清楚地表示順序圖中的事件順序和復雜控制，同時也有利于自動提取測試場景。

為了盡量降低模型的復雜性，本文采用分層的方式來對系統進行動態建模。在頂層活動圖中，可以劃分一個活動節點表示一個系統級的功能，在每個活動節點上還能繼續展開子活動圖，表示子系統級、類級以及函數級的系統功能。如果某個活動節點不能再展開了，就稱它為基本活動節點。對于每個基本活動節點，都能用一個順序圖來表示。根據這個建模規則，根據活動圖生成的所有測試場景最終都能以一個順序圖序列來描述，從中可以看出系統執行某特定用例時預期的行為和交互順序。通過驗證模型表示的行為與軟件在運行時的行為的一致性就可以確定程序中是否存在缺陷。

為了能將時鐘和受時間約束的事件加入到動態建模中，在活動圖和順序圖的基礎上定義了以下幾個構造型：

a)<>構造型。用于對嵌入式系統定時和周期事件的基本元素建模，應用于活動圖的活動節點。為了描述嵌入式系統的這兩種基本事件的時間特征，以及為了防止多事件并行執行時可能引起的沖突，加入了以下標記值：

Task.ID=value//每個任務都有一個惟一的標志

Task.Period=value//事件周期性或定時性

Task.StartTime=value//事件開始時間(全局時鐘)

Task.EndTime=value//事件結束時間(全局時鐘)

Task.Interval=value//事件持續時間(全局時鐘)

Task.Priority=value//事件優先級，確定并發事件的處理順序

b)<>構造型。用于對嵌入式系統等待動作的基本元素建模，應用于活動圖的控制流，表示控制流后的活動是在控制流前活動結束后間隔一段時間開始的。為了表示具體的等待時間，加入標記值：

Wait.Time=value//等待時間

c)<>構造型。用于對嵌入式系統參與者與設備之間、設備與設備之間信號發送與接收的基本元素建模，應用于順序圖的消息和調用。嵌入式系統中的對象之間主要通過連接器傳遞信息，對象之間可以建立多種連接。為了表示傳遞的源與目標對象，約束傳遞動作的時間和數據特征，加入了以下標記值：

Transfer.Src=value//源設備

Transfer.Des=value//目的設備

Transfer.Time=value//傳遞發生時間(局部時鐘)

Transfer.Type=value//傳遞數據類型，如RS-422、MIL-STD-1553等

有了以上幾種擴展的構造型，就能對復雜的嵌入式系統的行為進行動態建模。圖3為一個自動取款機系統的動態建模的活動圖以及部分順序圖。

活動圖具有描述系統工作流程和并行活動的能力，并且能表達復雜的分支、循環邏輯關系。從圖3可以看出，該活動圖有三個條件判斷、兩個進程并發，提取其中一個成功交易的場景用順序圖表示的結果如圖4所示。

該場景的順序圖實際上是活動圖中一條特定的獨立路徑，順序經過的所有基本活動節點表示順序圖連接而成。由活動圖生成的每個測試場景均能由一個這樣的順序圖來表示。

4 基于UML的測試用例生成

41 生成測試場景

通過被測系統的動態模型，可按以下思路生成測試場景。

定義 從活動初始節點開始遍歷活動圖，按照DFS(depth first search method)，遇到分支拆分為不同的場景，環路最多執行一次，遇到子活動，進入子活動，在子活動圖中進行相同的遍歷過程，得到所有基本路徑，即測試場景。

測試場景是一個八元組SD=(N，s，e，A，T，Ect，Lct，P)。其中：N為節點的非空有窮集合；S為活動的起始節點；E為活動的終止節點；A={a1，a2，a3，…，al}為活動中的活動節點集合；T={t1，t2，…，ts}為活動圖的遷移集合;Ect，Lct是集合A到自然數集合N的映射(A→N)，表示是實時活動圖中的某個活動最早和最遲完成時間，滿足Ect(a)≤Lct(a)，a∈A，Ect(aI)=0且Lct(aI)=0；P表示是某個活動的優先級，P(a)=0，1，2，分別表示低、正常、高三種狀態。

嵌入式系統運行時，并發線程較多，這種情況下，并發的活動可以按照任意的順序排列，會導致場景數量爆炸。如有n個進程并發，每個進程包含的活動數為mn，則生成的基本場景數量為(nn=1mn)!/nn=1(mn!)，當n=3，mn=4的情況下就有34 650個場景了。因此得引入約束?？梢詮娜齻€方面來考慮并發活動的約束：a)設置活動的優先級，前面在動態建模擴展活動圖中提到了，目的就是為了約束并發活動的行為；b)活動之間的約束，有些活動的發生必須以另一個或幾個活動發生為前提；c)測試人員指定場景數量。

通過以上幾種約束規則，可以大大降低并發活動的場景數量，而且這些約束更能反映實際測試要求和目標，保證了生成場景的質量。

42 生成測試數據

測試輸入可以從SUT靜態模型中獲得，從以下幾個方面來描述測試過程中的輸入變量：

a）變量類型。對于嵌入式系統，除了包括一般的int、long、bool、block等常用變量類型之外，還存在結構體數據，對于這種復合型數據，最好采用一種規范化的語言來定義，便于后面的測試用例自動生成。

b）變量取值范圍。對于具有確定性的輸入變量很好選取，而對不確定性的輸入變量，如具有上下取值邊界的變量，或者滿足一定概率分布的變量，描述就比較復雜了。根據測試策略的不同，選取也會不同的，如等價類劃分方法、邊界值方法。為了盡可能地多發現錯誤，往往需要多種測試策略結合起來使用。

c）變量的時間要求。由于嵌入式系統的實時特性，輸入變量必須滿足一定的時間約束，才算是有效輸入數據。當然，不滿足時間約束的輸入數據也可以作為異常輸入來測試系統的容錯性和時間性能，如制造延時來測試系統的延時時間等。

此外輸入變量應該從合法的和非法的輸入空間生成。非法的輸入能夠測試系統的健壯性和容錯性。

43 生成測試用例

431 測試場景生成算法

一個測試用例實際上是測試用例模型中一個場景的實例，也就是選定一個測試場景，并且針對場景中的每一個輸入操作，從它的數據集中選擇一個輸入值，根據該輸入預測系統的輸出。由于測試場景在每個活動節點都能展開成順序圖，從一個測試用例執行過程可以通過一系列順序圖來表達，測試過程中的輸入主要通過對象之間的交互行為來加載。

下面給出測試場景的生成算法：

a） 設置一個堆棧來保存測試場景所經歷的節點和遷移的信息，同時設置一個哈希表來保存活動圖中從判定節點出發的已經被訪問的遷移信息。

b） 首先查找活動圖中的開始節點，復制到測試場景中，記錄當前節點為A，并將節點A入對象棧。

c） 檢查由節點A出發的遷移，目標節點可能會出現兩種情況：

(a)如果目標節點B是判定節點，則將節點B的訪問標志設為1，并從判定節點的多條輸出路徑中選擇一條尚未訪問的路徑（選擇訪問標志為0的路徑，選擇后將該路徑訪問標志設為1），將路徑的目標節點C復制到測試場景中，同時生成一條新的遷移來替代：A→B、節點B、B→C，將新生成的遷移保存到測試場景中，同時將A→B、節點B、B→C及節點C入對象棧。將遷移B→C保存到哈息表中并記錄節點C為當前節點A。

(b)如果目標節點非判定節點，則將A→B及目標節點復制到測試場景中，并將A→B、節點B入對象棧。記錄節點B為當前節點A。

d） 循環c)，直到當前節點為活動圖的終止節點。從當前對象棧中，按照棧底到棧頂方向輸出所有節點和遷移信息，就完成了一個測試場景提取。

e） 從對象棧中依次彈出測試場景的節點和遷移信息，系統檢查當前棧頂的對象是否為判定節點，如果是判定節點，則按照c)處理，再進行d)；否則直接彈出棧頂對象，如此以往直到對象棧中的對象全部彈出，就完成了所有分支路徑的遍歷過程，同時也生成了所有測試場景。

432 測試用例生成算法

在黑盒測試和白盒測試過程中，設計測試用例時都會依據一定的覆蓋準則來滿足測試充分性的要求。對于黑盒測試，會要求達到功能點的覆蓋。而基于白盒的測試方法，會用語句覆蓋、分支覆蓋、條件覆蓋和多重條件覆蓋的準則來保證測試充分性。

與黑盒測試和白盒測試相似，基于UML活動圖的功能測試，在生成測試用例時應滿足節點覆蓋準則、遷移邊覆蓋準則、邏輯路徑覆蓋準則等覆蓋準則，以保證測試用例的覆蓋。另外，活動圖上的所有分支路徑都要至少執行一次。對于循環邏輯需要作一定的限制，如可以考核不進入循環和進入循環至少一次兩種情況作為準則。

測試用例自動生成是對活動圖中的全部路徑進行遍歷，結合上述覆蓋準則，可獲取相應執行過程中的控制流、數據流，分支節點的條件，然后就能確定每一路徑所需要的輸入和狀態條件。當滿足該路徑條件時，系統就會沿著該路徑表示的活動序列執行。 下面給出了測試用例自動生成的算法描述：

算法：測試用例生成

輸入：TestScenario[n] （測試場景集）

輸出：Testcase[n] （測試用例集）

//算法開始

Declare InputInfoArray as Vector〈String〉;

//定義輸入信息序列：

Declare OutputInfoArray as Vector〈CString〉;

//定義輸出信息序列

Declare OperInfoArray as Vector〈CString〉;

//定義操作信息序列

For each Vertex in the Vertex Set

Switch Vertex’s StereoType

Case input:

For each variable in the Vertex

Get Constraint from Transition in Scenario;InputInfoArray.Append(makepair〈varable，constraints〉);

End for

Case output:

OutputInfoArray.Append(Vertex.-GetDocument());

Case Empty or Operation:OperinfoArray.Append(Vertex.GetSwim

laneName () +\".\"+Vertex.GetName);

EndSwitch

End for

5 結束語

為了將自動化測試運用在嵌入式軟件測試領域，本文通過對UML進行實時擴展，以及多種圖相結合的方式，從系統的靜態結構和動態行為兩個方面來考慮模型的構造，并且通過一定的轉換規則，能夠自動地生成測試用例。依據幾種覆蓋準則和約束條件，可防止測試用例數量組合爆炸問題，提高了生成測試用例的質量，大大提高了嵌入式軟件自動化測試的可行性。

參考文獻：

［1］CAVARRA A， CRICHTON C， DAVIES J.A method for the automatic generation of test suites from object models[C]//Proc of the 2003 ACM Symposium on Applied Computing. 2003:1104-1109.

[2]SCHINZ I， TOBEN T， MRUGALLA C，et al.The rhapsody UML verification environment[C]//Proc of SEFM’04. 2004.

[3]JIANG Bo，LONG Xiang， GAO Xiao-peng.MobileTest:a tool suppor-ting automatic black box test for software on smart mobile devices[C]//Proc of the 30th International Conference on Software Engineering (ICSE 2007).2007.

[4]OMG.Unified modeling language specification(version1.5)[S].

[5]SELIC B， RRMBAUGN J.Using UML for modeling complex real-time systems[C]//Proc of SCM SIGPLAN Workshop on Languages， Compilers，and Tools for Embedded Systems.1998.

[6]WANG Yi-chen，LIN Bin，RUAN Lian.Simulation testing framework for embedded software[C]//Proc of the 25th Digital Avionics Systems Conference. 2006.

[7]ADS2 user manual[K].Tech S A T GmbH， 2000.

[8]Cantata++ documentation support test reference manuals. IPL information[C]//Proc of Limited.1998.

[9]GAO Y.A testing framework for real-time object-oriented modelling dissertation for the degree of master of science[D].[S.l.]:Queen’s University，2002.

[10]RT-LAB/ATB:scalable test bench for avionics systems[EB/OL].(2004).http:www.opal-rt.com/products/engsim/rtlab_atb.

[11]張楣，劉超，孫昌愛.基于UML活動圖模型的測試用例生成技術研究[J].北京航空航天大學學報，2001，27(4):433-437.

[12]賴明志，尤晉元.使用時間化自動機形式化帶有時間擴展的UML狀態圖[J].計算機應用， 2003，23(8):4-6.

[13]張虹，阮鐮，劉斌.嵌入式軟件測試中的仿真建模方法研究[J].測控技術，2002，21(3):37-41.

[14]牟凱，顧明.基于UML活動圖的測試用例自動生成方法研究[J].計算機應用，2006，26(4):844-846.