學習筆記 基于UML順序圖的場景測試用例生成方法
本節向大家介紹一下基于UML順序圖的場景測試用例生成方法，該方法完全基于UML，而且生成的測試用例數量少，減少了測試工作量。下面就讓我們一起來看一下詳細介紹吧。
基于UML順序圖的場景測試用例生成方法
摘要本文提出了一個基于UML順序圖的場景測試方法，它以UML順序圖為主要測試模型，結合類圖和狀態圖生成所有的測試場景，然后找到與每一場景相關的環境條件并將它與方法序列、輸入、輸出合理組合作為覆蓋該場景的測試用例。該方法完全基于UML，而且生成的測試用例數量少，減少了測試工作量。
0引言
本文提出了一個基于UML模型圖來測試場景的方法，它以順序圖為主要測試模型，結合類圖和狀態圖導出所有的場景，并將與場景相關的環境條件與方法序列、輸入、輸出合理組合作為覆蓋該場景的測試用例。我們的工作具有兩方面的優點：測試方法完全基于UML模型，以便已經使用UML的軟件系統能方便地采用,另一方面生成的測試用例數量少，減少工作量。
1實例
本文以DHCP[2]作為一個實例，使用UML的類圖、狀態圖和UML順序圖[3]來說明我們提出的一個場景測試用例生成方法。DHCP是由IETF進行標準化的一個協議，提供一種動態指定IP地址和配置參數的機制。我們選取了DHCP協議的一個子集，協議的一般過程如下：
1．客戶端廣播一個DHCP_DISCOVER消息。
2．每個具有網絡地址的服務可能響應一個DHCP_OFFER消息，如果都沒有響應，則表示超時失敗。
3．如果客戶端接收到一個或多個DHCP_OFFER消息，則選擇其中一個，然后廣播一條DHCP_REQUEST消息給所有的服務器，并附上選擇參數及指明哪一個服務器。
4．所有服務器接收到客戶的廣播信息，只有被選中的服務器才綁定地址給這個客戶，并發送確認消息DHCP_ACK，連接成功；如果要求的地址不可得（可能分配給其它用戶），則服務器發送一個DHCP_NAK給客戶，連接失敗。
圖1顯示了DHCP協議的部分類圖。 圖2是實例中請求IP的順序圖 圖3是DHCP中Server類的狀態圖
圖1DHCP的部分類圖 圖2請求IP的順序圖 圖3DHCP-Server狀態圖
2UML順序圖的一個形式化定義
為了能在測試中找出所有的場景，下面給出順序圖的形式化定義：
定義1（順序圖）順序圖SD可以表示為一個六元組：SD=<O,M,E,→,msg,obj>,其中：
●O={O1,O2,…,Om}，是對象的集合。O1,O2,…,Om都是順序圖中的對象。
●Mguard´message´name´parameter_list,是消息的集合。順序圖中的每一個消息都形如：“[衛士條件]消息名(參數)”。
●E=M{s,r}，是事件集合。事件是指消息的發送和接收。對于消息msg，發送事件用<msg,s>表示，接收事件用<msg,r>表示。順序圖中所有發送消息事件的集合記為S，所有接收消息事件的集合記為R。SÇR=Æ,SÈR=E。
●→是消息集合M上的一個全序關系，表示順序圖中的消息在縱向時間軸上的先后關系。
●msg是從E到M的一個函數關系，msg(e)M表示事件e所對應的消息。
●Obj是從E到O的一個函數關系，obj(e)O表示時間e所對應的對象。對象Oi上所有事件的集合記為Ei，Ei＝{e|eEÙobj(e)=Oi}。
在如圖4所示的順序圖中：
O={obj1,obj2,obj3};M={m1,m2,m3};
E={(m1,s),(m1,r),(m2,s),(m2,r),(m3,s),(m3,r)};
→=m1→m2→m3.
圖4一個簡單的UML順序圖
UML順序圖主要描述了對象間發送消息的時間順序。我們用符號‘<<’來表示事件間的先后關系，它滿足如下三個性質：
1．對同一消息而言，發送事件先于接收事件。
2．在同一對象的生命線上，若事件e1出現在發送事件e2的上方，則e1先于e2。
3．在同一個對象的生命線上，如果接收事件e1出現在e2的上方，并且它們分別對應的發送事件也位于同一個對象的生命線上，則e1先于e2。
‘<<’順序關系是強制順序關系，那么即使它們在順序圖的時間軸上存在先后關系，這兩個事件實際發生的先后順序也是不確定的。例如圖4中，盡管（m1,r）在（m3，r）的上方，但是在系統實際運行中，由于m1,m2,m3都是異步消息，因此（m1,r）并不一定先于（m3,r）發生，這是由于圖形表示的局限性造成的。
一個簡單順序圖（不包括分支）刻畫了系統運行的一個場景，其運行過程表現為一個事件的序列（e1,e2,…,em）,其中事件ei+1在事件ei后發生（1≤i≤m－1）。由于事件之間存在強制順序關系‘<<’，因此并不是所有事件序列都是順序圖允許的。而且，由于‘<<’并不是一個全序關系，所以一個順序圖的場景可能允許多個事件序列。可以用一個有向無環圖（DAG）來表示‘<<’關系，對于任意兩個事件ei，ei∈E，如果ei<<ei，則畫一條從ei指向ei的邊，直到所有事件都在這個有向圖上。
通過遍歷所得的DAG圖，可以很容易的得到順序圖中的每一個有效的事件序列。在圖4的例子中，<(m1,s),(m2,s),(m2,r),(m3,s),(m3,r),(m1,r)>和<(m1,s),(m1,r),(m2,s),(m2,r),(m3,s),(m3,r)>就是兩個有效的事件序列。
定義2（順序圖的場景）對于順序圖SD=<O,M,E,→,msg,obj>，場景定義為一個消息序列<M1,M2,…,Mm>，并且滿足下面兩個條件：
（1）所有M中的事件在序列中出現且僅出現一次，也就是說{M1,M2,…,Mm}=M且對于所有的ij，MiMj。
（2）對于任意兩個消息序列Mi,MjÎM，如果（Mi,s）<<(Mj,s),那么序列中Mi在Mj的前面。
根據場景的定義，通過所找到的合法的事件序列就可以確定與該事件序列相應的場景。如圖4，<m1,m2,m3>就是一個有效的場景。#p#
3基于UML順序圖生成場景測試用例的方法
順序圖中的場景設計可能與實現不一致，例如由于消息名的編碼錯誤、不正確的或缺少輸出等，那么通過執行順序圖中的所有可能場景，至少能在其中的一個場景的執行過程中達到該錯誤，因此只要從順序圖中生成覆蓋所有場景的測試用例就能有效地找出存在的錯誤。在測試用例的生成過程中，我們將環境條件與輸入，方法調用序列和預期輸出作為最終的測試用例，最后將系統測試后的實際輸出和方法調用序列與預期的輸出和方法調用序列進行比較，從整體上驗證系統的最終實現是否與設計一致，從而完成順序圖的場景測試。
3.1測試衡量方法
測試的主要評測方法包括覆蓋和質量，測試覆蓋是對測試完全程度的評測，質量是對測試對象（系統或測試的應用程序）的可靠性、穩定性以及性能的評測。對于順序圖的場景測試，最基本的評測方法就是測試覆蓋，即要求針對每一個場景都至少生成一個測試用例。但是順序圖本身并不能充分地對系統交互行為進行建模，僅通過順序圖并不能生成充分地場景測試用例。所以我們將順序圖與交互對象的狀態圖相結合，生成更充分的測試用例。為此，定義如下評測方法：
1)順序圖中的每個場景至少被測試一次。
2)如果順序圖中的對象存在狀態圖，那么與場景相關的每個狀態至少要被測試一次。
3.2UML順序圖場景測試用例生成方法的步驟
第一步，檢查順序圖中的每一個對象，如果其存在狀態圖，就將對象狀態加入到順序圖中。以DHCP-Server對象為例，其狀態圖如圖3所示，HasfreeIPaddresses和HasnofreeIPaddresses是Server可能處于的兩種狀態，我們將這兩個狀態加入順序圖。
第二步，使用第3節介紹的方法通過遍歷順序圖中的事件序列從而找出所有的場景。在圖5中，消息4和消息7、消息10和消息12分別構成了分支，處理分支時，可以為順序圖構造多個DAG圖，每個圖包含其中一條分支。這樣就將復雜順序圖化簡成多個簡單的順序圖來進行處理，遍歷每個DAG圖就可以得到所有場景。圖5中，得到3個場景如下：
A：1,2,3,4,5
B：1,2,3,6,7,8,9,10
C：1,2,3,6,7,8,11,12
第三步，選定一個場景，根據其消息序列在順序圖中遍歷該場景，記錄場景的輸入和最終輸出。以場景B為例：
輸入：用戶調用connect操作。
預期輸出：返回“nak”消息，表示申請IP不成功。
第四步，確定每個場景的環境條件。首先從UML順序圖中找出所有的測試單元，在順序圖中，每一個交互的對象就是一個測試單元。本例中的DHCP_Client和DHCP_Server就是兩個測試單元；其次對每一個測試單元，從類圖中導出相應的環境設置（包括對象屬性、操作和消息中的參數）。結果如表1所示。
表1DHCP的測試單元與環境
測試單元
DHCP-Server
DHCP-Client
環境設置
Offer:Boolean
hasFreeIP:Boolean
無
找出環境設置之后，再為每一個場景找出相應的選擇，從而確定其環境條件，如場景B中，Offer=true，hasFreeIP=false。
第五步，測試用例生成一個測試用例包括4個部分：環境條件、輸入、方法調用序列、預期輸出。對于場景B，所有這些信息已從前面的四步中生成，只要將它們組合在一起就可以了。場景B的測試用例為：
環境條件：DHCP-Server：offer=true，hasFreeIP=false
輸入：用戶調用connect操作。
方法調用序列：
Client.discover,Server.isServeroffer,
Client.request,Server.hasFreeIP,
Server.nak,user.notConnected
預期輸出：返回”nak”消息，表示申請IP不成功。
在這個測試用例中，方法調用序列就是該場景中的消息序列。
可用同樣的方法為所有場景生成測試用例。
4結束語
文[4]出現了一個基于UML順序圖設計的面向對象的軟件的自動測試的概念和相應的實現工具SeDiTeC，該方法提出了一個可測試的順序圖的規則，并在SeDiTeC中實現了完整的測試過程，但是沒有詳細描述如何從順序圖中生成測試用例。文[5]指出了多態性對順序圖測試場景的影響，提出了相應的對策，有效地解決了測試消息序列中多態消息的測試問題，但沒有說明測試用例如何生成。文[6]同樣提出了一個順序圖生成測試用例的方法，但是該方法沒有給出場景的分析，而且生成的用例數太多，工作量大。
本文提出的基于UML順序圖生成場景測試用例的方法，包括找出場景和生成測試用例，改進了這類方法生成測試用例數多、工作量大的缺點，減少了測試用例的重復生成。
【編輯推薦】
