模板
教程
環境
性能
功能
管理
一個基于UML協作圖的集成測試用例生成方法
|
一個基于UML協作圖的集成測試用例生成方法 王林章 （南京大學計算機科學與技術系，南京市漢口路22號419信箱，210093，南京）摘要： UML協作圖描述了系統的一個協作中參與對象之間的結構關系和交互行為，確認它們是否被正確實現是集成測試的工作。本文提出了一個基于UML協作圖生成集成測試用例的方法，將表示設計的協作圖作為測試模型，并從中提取相關信息生成用于測試所描述的行為的集成測試用例。首先通過遍歷每條消息的直接后繼識別協作圖中的表示用例實現的所有可能的場景路徑，然后在遍歷每條場景路徑的過程中獲取相應協作執行的路徑條件、參數變量和預期方法調用序列，最后使用范疇－劃分方法確定場景路徑上的輸入、輸出、環境條件的合理組合作為覆蓋該場景路徑的測試用例，用于測試一個協作場景路徑上的交互行為。該方法完全基于UML，集合了白盒方法和黑盒方法，生成了較少的測試用例覆蓋所有的測試需求。本文將該方法應用于一個ATM建立會話的用例片斷實現的實例，證明了其可行性和實用性，并提出了一個用UML設計的工具框架，以實現該方法的自動化，使得其可以方便地集成到使用UML的軟件開發過程中。關鍵詞：測試用例生成，集成測試，UML協作圖，場景路徑
中圖分類號 :?。裕?11 文獻標識碼 : 文章編號 : An Approach to Generate Integration Test Cases based on UML Collaboration Diagrams Linzhang Wang, Xuandong Li,Guoliang Zheng (CS Department , Nanjing University, Hankou Road 22 P.O. Box 419, 210093, Nanjing) Abstract: UML collaboration diagrams represent the structure relationship and interactive behavior of the objects involving in a collaboration of the software system, whether they are correctly implemented or not can be validated by integration testing. This paper propose an approach to generate integration test cases based on UML collaboration diagrams, take collaboration diagram as test model, from which we can extract information to generate integration test cases for testing the behavior. Firstly, the method identifies all the scenario paths in the diagram which represent use case realization by traverse the direct successors of each message. Then it selects and traverses each scenario path to get the method call sequence, path condition and parameters. Lastly, it applies category partition method to generate rational combination of input parameters, environmental conditions, as well as the corresponding output and method call sequence, to form a test case for each scenario path, thus we can test the interactive behavior of the software. This method completely base on UML, combine white-box and black-box test method to generate fewer test cases to test the gray-box behavior. In this paper, we apply this approach to an example of constructing sessions between cardholder and the bank through ATM, proving its feasibility and practicability, also propose a corresponding tool framework to facilitate its automation, thus to easily be deployed into the UML –based software development process. Keywords: test cases generation, integration testing, UML collaboration diagram, scenario path 1、引言 面向對象的技術因為能夠解決傳統程序設計語言的問題，自提出后，一度成為研究熱點，事實上采用面向對象技術減少了不少錯誤的發生，對于提高軟件質量起到了很大的作用，但是面向對象技術本身在任何情況下都不會排除軟件測試的動機，同時面向對象語言的本質特征，如繼承、封裝、和多態等，也帶來了新的故障風險，并給軟件測試提出了新的挑戰。[1,2,9] 區別于傳統軟件的功能分解，面向對象軟件是通過合成來構造軟件的，因而集成是面向對象軟件開發中最重要的工作，面向對象軟件構造過程中有的不同層次的集成，包括：從方法到類的集成，類通過繼承集成，類通過容器集成，類到組件的集成，組件到應用系統的集成。在面向對象的迭代式增量開發過程中，通過不斷的集成產生系統的可執行的版本，但每一個集成的環節都可能引入錯誤，導致軟件中存在缺陷，為了能夠發現軟件集成中的問題，面向對象軟件的集成測試非常重要。[4] 對于傳統軟件的集成測試，可以根據設計階段形成的功能分解樹，采用自頂向下或自底向上逐步測試用經過測試的單元組裝成系統的過程中有無錯誤。[3]而面向對象軟件采用的是通過組合實現系統的功能，沒有一個功能分解樹可用，所以傳統的基于功能分解的集成測試策略不適合面向對象軟件。要檢驗最終實現中各種集成是否與設計的集成一致，則需要對每一個集成層次進行測試，而這里的集成分為結構集成和行為集成，所以面向對象軟件的集成測試包含結構集成測試和行為集成測試。結構集成測試主要測試類的繼承、類的容器、類的接口、組件的接口中有無錯誤；行為集成測試主要是類內方法交互、類間方法交互、組件間交互是否被錯誤地實現。測試工作的核心主要是生成測試用例，在面向對象軟件開發過程中系統的規約、設計、代碼是生成測試的信息來源，是軟件在其生命周期不同階段的變體，當然規約、設計、代碼在每一階段的測試中都起相應的作用，特別地，系統規約是生成系統測試的測試用例的基礎和系統測試的檢驗依據，軟件代碼是生成單元測試用例的基礎和單元測試的檢驗依據，系統設計是生成集成測試用例和集成測試的檢驗依據。系統的設計信息有助于理解系統功能和結構，設計模型包含規約和程序結構的信息，同時也描述了系統的相應功能片斷的行為，因此也被稱為灰盒?？梢越Y合白盒測試和黑盒測試方法，從設計信息生成集成測試用例，測試設計模型表示的軟件系統的灰盒行為。 UML是面向對象系統分析、設計的標準的建模語言，自從在1997年成為建模語言事實上的標準后，就得到學術界的推崇和工業界的支持，使得UML廣為使用，基于UML的方法和實用技術的研究成為將來的發展趨勢。UML對面向對象軟件開發全生命周期的支持也使得軟件開發人員優先用它來描述系統。[8]正像集許多優點的面向對象技術不能免除軟件測試一樣，使用UML進行面向對象軟件開發，在提高軟件質量的同時，仍然需要測試來確認軟件分析、設計、實現的一致性和正確性。同時基于UML開發的軟件系統，軟件開發的分析、設計階段工作成果多為各種模型圖，系統的可用信息都在這些模型圖中，給信息的提取帶來了新的問題，從而也給測試帶來新的課題。對測試而言，原先的基于規約或者是基于程序的方法都不能直接使用，對基于UML模型的測試，要將問題轉換到原來傳統測試方法可以處理的問題空間中加以解決，轉換工作主要解決信息提取問題，然后用常規測試方法生成測試。面向對象的軟件中，對象通過交互來實現行為，UML的交互圖[6,7]是描述一組對象間的結構關系和交互行為設計的最佳選擇，主要有順序圖和協作圖兩種，順序圖關注全局的時序，協作圖關注協作對象之間的關系，本文主要研究協作圖。UML協作圖描述了系統的一個協作中參與對象之間如何交互，集成測試正是要驗證這些對象是否正確交互，所以我們研究基于UML協作圖的集成測試用例生成方法。本文中我們使用UML協作圖作為系統功能片斷的高級描述，用來作為生成測試的基礎，使得在系統設計階段一開始就可以計劃集成測試階段的測試。在軟件開發早期準備軟件測試，在軟件的系統分析、設計階段,利用每一階段的人工制品(artifact)生成軟件測試各個階段所需的測試用例，在代碼階段結束后便可以開始測試工作，而且對分析設計模型進行分析的同時也能發現分析、設計本身的缺陷，以便及時排除，以防缺陷隨著軟件開發過程的進展而被放大。由于UML在工業界的使用越來越普遍，而相應支持在分析設計階段基于模型生成測試用例的實用方法和支持工具還不多見。我們希望能夠研究出僅從UML分析、設計模型圖自動生成測試用例的方法，而且不需要使用者的除UML外其他方面專業的知識，能夠實現自動化而不增加用戶額外的工作量，這樣的測試方法容易被已經使用UML的工業界采用。[8,10] 本文研究如何通過面向對象軟件設計階段的UML協作圖選擇合適的集成測試用例的方法，第2部分對協作圖的語法和語義作了詳細的介紹，并回顧了測試模型、協作集成測試模式、協作故障模型等知識；第3部分對基于協作圖生成測試用例的方法作了總體介紹，詳細描述了從協作圖生成測試用例的具體算法和支撐工具框架原型，第4部分是相關工作的介紹，最后是結束語和將來工作的構想。 |
| 2、協作圖與集成測試 2.1協作圖的語法和語義 UML協作圖[7]就是用來表示一組通過交互來實現某些行為的對象，可以用來可視化、詳細描述、構造和文檔化一個特定的對象群體的動態方面，也可以用來按交互中的角色及其關系對一個用例的特定的場景或控制流的實現進行建模。協作圖描述了特定行為的參與對象的靜態結構，以及參與對象之間的動態交互，可以用于不同的規約抽象級別，規約級協作圖表示了類元角色、關聯角色和消息，表示對象之間的可能的關系，而實例級協作圖表示對象、鏈和激勵，表示特定對象之間的關系。兩者都描述了協作參與者之間的結構關系。如果要表示可能事件，一般用規約級協作圖，其中沒有條件和循環，實例沒有取值范圍或有許多可能的路徑。實例級協作圖用于描述屬性或參量有具體的值的對象和鏈，可變大小多重性的對象和鏈的具體數目，或者是執行中的分支或循環的特定選擇。協作圖可以用來表示用例的實現或操作的實現，描述操作和用例的執行實現所處的語境、交互中行為序列。當協作圖用于表示用例的實現時，只描述外部可見的動作及其順序,用對象之間的消息交換來描述一個用例實現的場景。當協作圖用來表示一個對象的操作的實現時，提供了更詳細的信息，如操作的參數及其用途、參與變量的特征、關聯上的約束、操作實現過程中對象的創建和破壞等。本文主要研究用于表示用例實現的實例級協作圖，下面介紹實例級協作圖符號及其語義。 協作描述了在一定的語境中一組對象以及用以實現某些行為的這些對象之間的相互作用。協作由靜態部分和動態部分組成，靜態部分描述在協作實例中對象和鏈可能擔任的角色，是角色集合和其間關系，這些關系定義了結構方面的內容，動態部分是一個消息集合，包括一個和多個動態交互，表示在執行計算過程中不同時間里協作中的消息流, 這些消息定義了行為方面的內容。角色表示協作中對象和鏈的目的，類元角色定義了參與協作執行的對象在一個協作中扮演的角色，關聯角色定義了一個類元角色和其他角色之間的關系，是參與協作執行的關聯的描述，關聯角色是鏈的子集，鏈是兩個或多個對象之間的單向連接，是關聯的實例。對象必須是位于關聯相應位置的類的直接或間接實例。關聯是兩個或多個特定描述其實例間連接的類元之間的關系，參與關聯的類元在關聯內有有序的位置。在運行時，對象和鏈與協作中的角色綁定，在不同的協作中一個對象可以綁定到一個或多個角色。 交互是由在一個實現特定目標的協作內一組對象之間通信序列組成的行為規約。每個交互包含消息的偏序集，這些消息由類元角色通過關聯角色交換。消息是激勵的規約，是發送者和接受者之間的通信。消息指定了發送者對象和接受者對象扮演的角色，說明發送者對象對接受者對象應用何種操作。激勵是傳遞消息期望發生的兩個對象之間的通信，激勵導致一個操作被激活、發出一個信號、導致一個對象被創建或終止。 本部分介紹一個客戶通過ATM上驗證用戶卡和PIN有效性、建立會話的用例片斷[9]的實例級協作圖，如圖1所示。協作圖上存在條件消息說明考慮到許多不同的用例場景，涉及到多個對象之間的交互，其中每一個場景都對應協作圖上的一條執行路徑，這正是測試所要嘗試的。圖2表示了在這個協作中參與對象相應的類圖。
迭代過程調用 |
一個描述用例實現的實例級協作圖上用于建模的元模型包括：類元角色名、關聯角色名、對象符號、鏈接符號、消息符號、鏈上的約束等。對象框能夠表示參與協作中交互的對象，鏈表示這些對象之間的結構關系，消息的箭頭形狀表示協作對象間的通信模式和對象的執行特征, 消息標簽表示對一個對象的操作調用的允許順序的實例、操作的語義。在實際的建?；顒又杏行┰夭⒉辉谀Ｐ蜕戏从?，例如圖1的協作圖只表示了協作中參與的對象和對象之間的消息，這是表示對象交互的最小元素集。本文關注協作圖表示的動態行為的測試，前面提到協作圖上表示交互的主要元素是消息，下面詳細介紹消息。|
3、基于協作圖生成集成測試用例的方法 3.1研究假定 為了有針對性地解決從協作圖生成測試用例的問題，本文作出如下假定和要求： (1)假定協作圖描述的協作與用例圖描述的規約是一致的。模型本身的驗證是通過非形式化的復審和形式化的模型檢驗方法進行的，已超出本文的研究范圍；如果協作圖上的場景路徑集不能覆蓋所有消息，則說明協作圖本身有錯誤； (2)假定系統中的對象都是自行開發的，不包括第三方組件對象，文中的對象可以是不同粒度的對象（類的實例、類簇、組件、子系統、系統），也就是說我們在分析任意對象或類時，在必要的情況下都可以獲取其規約和內部詳細設計信息，包括功能和結構信息；對于第三方組件的集成測試，[13][17]介紹了詳細的測試方法； (3)我們研究的測試是針對檢錯進行的，確認軟件是否正確實現了設計，協作圖上的結構關系是否被正確實現，[15]中已有相應的靜態檢驗方法，所以本文只研究動態交互行為的測試； (4)本文為了明確解決問題，假定消息類型只有普通消息、條件消息、循環消息，而且只存在順序循環，不存在嵌套循環。 3.2方法概述 基于協作圖的集成測試（Collaboration diagram-based Integration Testing, CIT ）方法集合了傳統的白盒測試方法和黑盒測試方法，用于測試協作圖中參與協作的對象之間通過消息的交互，對每個協作圖處理一次，得到相應的測試用例集。首先分析協作圖，提取協作圖中表示的所有元素，根據消息的順序號和消息的條件，找到每一條消息的直接后繼消息，然后根據場景路徑的定義，使用深度優先方法遍歷消息及其直接后繼直至到達無直接后繼的消息從而生成場景路徑，然后回溯到沒有被訪問的直接后繼，重復上述方法找到所有的場景路徑；在訪問消息獲取場景路徑的同時，獲取該路徑的方法調用序列、參數和路徑條件，將這些集成測試的關鍵因素用范疇-劃分方法定義為方法序列、環境條件、系統輸入、系統輸出等范疇，結合該協作片斷的用例規約和類圖中的定義生成這些范疇的可能選擇，然后結合路徑約束條件在這些范疇的劃分中確定選擇項的合理組合，這樣我們就等到了該場景路徑完整的測試用例，包括外界輸入、交互輸入、預期方法調用序列、后條件、預期輸出。對協作圖中的所有場景路徑都構造了測試用例，就形成了協作集成測試用例集。這樣在實際執行集成測試時不但可以直接觀察到系統級的輸入作用下協作實現過程中的實際輸出，還能夠通過動態插裝方法在代碼中加入不影響軟件功能的觀察代碼[15]，使測試人員能夠觀察到實際協作執行時的方法調用序列和數據流的定義和使用，然后通過比較最終系統實際執行時輸出與預期輸出的一致性決定該協作實現的功能是否正確，通過比較應該發生的方法調用序列和實際執行時觀察到的方法調用序列是否一致，確定協作表示的交互行為是否正確，從而從整體上對協作圖描述的系統行為的實現是否與設計一致，從而完成協作的集成測試。 本方法可以以增量的方法進行，最終生成的測試用例的具體程度，與相應UML模型圖的設計精化程度相關，因為協作圖描述的場景的詳細程度與測試用例的表達能力直接相關。 3.3 UML協作圖生成測試用例的算法描述 本文的方法能夠從協作圖規約文檔直接生成測試用例，主要描述分析協作圖規約文檔提取集成測試需求信息并生成消息后繼表的算法UMLspecificationparser()，然后為每個消息確定其直接后繼消息的findsuccessor()算法，根據消息后繼表遍歷所有場景路徑獲取測試用例規約信息的spathgenerator()算法，以及從測試用例規約使用范疇劃分方法確定測試用例輸入值、預期輸出值、預期輸出行為的算法testcasegenerator()。UMLspecificationparser()算法從協作圖從獲取集成測試需求信息是通過對UML協作圖規約的文本文件（如Rational Rose 的MDL文件）進行分析完成的[11]，在我們的工具中實現相應的功能，本文對分析算法不作詳細描述。我們用鄰接表定義消息后繼列表，將分析結果信息按消息順序號升序記錄到messagelist的表頭中，以便下一步處理。我們定義消息后繼列表如下： messageitem{ mid:string;//消息順序號 mguardcondition:string;//消息衛式條件表達式 mlabel:string;//消息標簽 msender,mreciever:object;// 消息發送者對象，消息接收者對象 mmethod:method;//消息激活的方法 mtype:[flat flow, procdure call, call return];// 根據消息的箭頭及線型劃分的消息類型 link:pointer of msuccessor; } msuccessor{ mid:string;//后繼消息順序號 mscondition:string;//選擇該后繼的條件表達式 next:pointer of msuccesor } messagelist:messageitem[n]; findsuccessor()算法為消息生成直接后繼列表的并記錄到消息的后繼鏈表中，描述如下： findsuccessor(messagelist){ //找到所有消息的所有可能后繼和每個后繼條件 //輸入：消息后繼表messagelist //輸出：消息后繼表messagelist //出口準則：所有消息都處理完 for i:=1 to n do { if i= =n 或者messagelist[i]為端口輸出事件觸發消息 messagelist[i].link=nil；i:=i+1; //最后消息或觸發端口輸出事件的消息無后繼消息 else{ if messagelist[i+1]是普通消息 則messagelist[i]的直接后繼為messagelist[i+1]； else{ k:=1; do while messagelist[i+k]是條件消息{ messagelist [i+k]是messagelist [i]的直接后繼，且條件為messagelist [i+k]的條件取真 if messagelist [i+k]是循環或嵌套層次的第一個消息{ t:=該層次的消息數;messagelist [i+k+t]是messagelist [i]的直接后繼； 條件為messagelist [i+k]的條件取假; k:=k+t;}//條件取假時循//環或嵌套內的消息都不發送 else{ messagelist [i+k+1]是messagelist [i]的直接后繼; 條件為messagelist [i+1]的條件取假; k:=k+1;//不發送 }endif }enddo }endif i:=i+1; }endif }endfor; }endfindsuccessor; spathgenerator()通過訪問消息后繼表中消息及其直接后繼生成場景路徑，在遍歷場景路徑時同時記錄路徑上相應的控制流和數據流信息，執行完畢得到一個場景路徑集spath相應的控制流數據流測試規約。其算法描述如下： s-pathgenerator(m:msuccessorlist){ //輸入：messagelist; （消息后繼表） //輸出：spath;（場景路徑集） spath{ sid:integer;//場景路徑順序號 pathcondition: list of gardcondition; //場景路徑的實現條件 mlist:list of message;//場景路徑上的消息流列表 parameters:list of variable;//場景路徑上定義和使用的變量列表 userinputparameters: list of variable; //場景路徑上外界輸入參數列表 methodsequence:{objectname,methodname,next};場景路徑上由消息激活的方法序列 }[n]; i,j:integer; i:=1; j:=1; Sid:=j;//場景路徑序號 //遞歸訪問消息及其直接后繼 訪問消息m，在消息標簽中取出并記錄返回值、參數、調用的對象方法； 記錄消息條件到路徑條件中； if m的后繼消息為空 { 一條場景路徑結束；j:=j+1;return;}//回溯到m[i]的直接前驅繼續 else{ k:=1; while m.link<>nil do { //m的后繼消息列表不空 successor:=m.link； spathgenerator(successor) //深度優先遍歷該消息及其后繼消息 m.link:=successor->next;//下一后繼消息； }endwhile }endif; }endfind; testcasegenerator()選定遍歷一個場景路徑過程中生成的控制流和數據流，定義相關范疇，生成測試用例的規約。消息激活的方法序列正是我們要測試的對象間的交互，是軟件執行時表現出來的對象之間的控制流傳遞行為，是對象之間通過消息交互的結果，定義為交互范疇Interaction Category；輸入參數列表為測試該場景時外界的輸入，定義為輸入參數范疇input parameter Category；我們通過對參與協作對象的類圖的分析，以及用例描述，可以獲取我們所研究的交互行為定義、輸入參數的定義、其他影響消息執行的變量的定義、系統環境條件的定義等，從而可以獲取這些系統環境條件、輸入參數、方法行為的可能選擇，然后結合。 利用范疇-劃分思想，用相應場景路徑的路徑條件和加在消息上的約束、以及系統本身的屬性約束來限定這些選擇，排除無意義和有沖突的值，然后通過這些不同的范疇的不同選擇的可能組合作為一個場景路徑的測試用例，這樣每個場景路徑生成一個集成測試用例。具體算法描述如下： Testcasegenerator(){ //輸入：spath[n] //輸出：tcsuite[n]{ envirnmentpara,input(inputpara,paravaliue),expectoutput,postcondition} i:integer; for i:=1 to n do { tcsuite[i].postcondition:=spath[i].pathcondition; tcsuite[i].environmentpara:={滿足路徑條件的環境條件} tcsuite[i].input.inputpara=spath[i].userinputsparamenters; 選擇對本場景路徑條件有影響的參數確定其可能的取值； tcsuite[i].input.paravalue={符合路徑條件的輸入參數可能的取值}； 取出spath[i]的方法激活序列，分析每一個方法的定義，確定其可能的行為，選擇符合場景路徑條件的行為，并將方法序列的執行過程的輸出序列存到tcsuite[i].expectoutput中； i:=i+1; }endfor; }endtestcasegenerator; 為說明問題，我們選一條最長路徑spath[5]（消息序列為：1.1，1.2，2.1，2.2，2.3，4.1，4.2，4.3，5）來演示使用上述方法生成覆蓋該路徑的測試用例的過程。，從該路徑獲取相關范疇如下： Tcsuite[5] Pathcongdition:!notATMCard, !isStolen, !accountClosed, validPIN&&n=1,!declineFee Environmentcondition: ATM卡，非成員卡，卡沒有被盜，帳戶沒有關閉 parameter category： inputPIN //影響validPIN 123456 [property validPIN][if !notAtmCard] 564821 123258 …….. deClineFee //影響deClineFee T [property declineFee][if !isMemberCard]] F interaction behavior category： session.beginSession()， 插卡事件創建session對象 cardSlot.isATMCard()， 判斷是ATM卡，讀取卡號，定義cardNum，notATMCard=F[if !notATMCard] 判斷不是ATM卡，notATMCard=T screen.prompt()， 屏幕提示“please input PIN”，n=1[if !notATMCard][property n] 屏幕提示“please input PIN”，n=2[if !notATMCard] [property n] 屏幕提示“please input PIN”，n=3[if !notATMCard] [property n] numkeyPad.getEntry()， 輸入正確的PIN inputPIN=’123456’[if n=1] 輸入錯誤的PIN inputPIN<>’123456’[if n=1] 輸入正確的PIN inputPIN=’123456’[if n=2] and [if !validPIN&&n=1] 輸入錯誤的PIN inputPIN<>’123456’[if n=2] and [if !validPIN&&n=1] 輸入正確的PIN inputPIN=’123456’[if n=3] and [if !validPIN&&n=2] 輸入錯誤的PIN inputPIN<>’123456’[if n=3] and [if !validPIN&&n=2] bank.checkCard()， 為被盜ATM卡驗證PIN ，isStolen=T[if !notATMCard] 為帳戶關閉的ATM卡驗證PIN，accountClosed=T [if !notATMCard] 為合法ATM卡錯誤輸入PIN驗證身份，accountClosed=F, isStolen=F ,validPIN=F[if !notATMCard&n<4] 為合法ATM卡正確輸入PIN驗證身份，accountClosed=F, isStolen=F ,validPIN=T[if !notATMCard&n<4] bank.getFeeAmount()， 獲取非成員卡用戶交易服務費金額,定義feeAmount [if !notATMCard&&ValidPIN&&n<4 and !isMemberCard] screen.prompt() 屏幕提示“Fee Payed:XXX” numkeyPad.getEntry(), 輸入同意付費，declineFee=T 輸入拒絕付費，declineFee=F screen.prompt() 屏幕提示“please select transaction”[if !notATMCard&ValidPIN&&n<4] and [if isMemberCard or !isMembercard&!declineFee] 這樣我們符合spath[5]路徑條件的相應的一個測試用例tcsuite[5]的最后結果為： Test case 5： 外部事件：插卡 environmentcondtion： ATM卡，非成員卡，卡沒有被盜，帳戶沒有關閉 input category： inputPIN=’123456’ //輸入有效PIN declineFee=F //輸入同意付費 interaction behavior category： session.beginSession()， 為ATM卡合法持卡人建立會話 cardSlot.isATMCard()， 判斷是ATM卡，讀取卡號cardNum, notATMCard=F screen.prompt()， 屏幕提示“please input PIN”，定義n=1 numkeyPad.getEntry()， 輸入正確的PIN，inputPIN=’123456’ bank.checkCard()， 為合法ATM卡正確輸入PIN驗證身份，定義accountClosed=F, isStolen=F ,validPIN=T，ismemberCard=F; bank.getFeeAmount()， 獲取非成員卡用戶交易服務費金額,定義feeAmount=xxx screen.prompt() 屏幕提示“fee Payed XXX” numkeyPad.getEntry(), 輸入同意付費 定義declineFee=F screen.prompt() 屏幕提示“Please select transaction” 預期的方法調用序列：session.beginSession()，cardSlot.isATMCard() ，screen.prompt() ，numKeypad.getEntry() ，bank.checkCard() ，bank.getFeeAmount()，screen. prompt ()，numKeypad.getEntry()，screen. prompt () 后條件： inputPIN=’123456’,!notATMCard, !isStolen, !accountClosed, validPIN&&n=1, !declineFee 預期輸出： 屏幕提示“please input PIN” 屏幕提示“fee Payed XXX” 屏幕提示“Please select transaction” 我們可以用同樣方法為屬于同一個用例的其他協作圖構造了測試用例，則該用例的集成測試集構造完成。然后，可以用增量方式為組件、子系統、系統構造完整的集成測試用例集，而且可以用自動的方式進行?？梢杂肹15]中的插裝方法按照每一場景路徑上的方法調用順序，對待測試實現進行插裝，這樣在執行時可以觀察到軟件用相應測試用例運行的結果，并將觀察到的實際執行結果與測試用例中的預期結果進行比較，如果一致，說明相應場景的實現與設計是一致的，否則，存在錯誤，并且錯誤在協作圖的相應場景路徑上，可以通過實際結果與預期結果發生不一致的地方定位錯誤，然后調試修改。 3.3算法實現工具框架 為了支撐上述測試用例生成方法的自動化，我們設計一個基于UML設計模型圖的集成測試用例的自動生成工具UMLTGF，我們仍然使用UML為UMLTGF建模，本文給出UMLTGF的類圖，如圖3。相應的功能描述如下： 1、ＵＭＬ模型分析器。能夠直接讀取UML協作圖規約的文本文件（如MDL文件）[11]，進行解析，并獲取對象角色、對象的屬性和方法，鏈、約束，消息流和消息標簽，存入相應的中間表，以便測試用例生成器使用； 2、協作集成測試用例生成器。根據消息的順序號和條件，跟蹤消息流，生成每條消息的直接后繼，然后通過遍歷消息及其直接后繼的方法生成協作圖上每個用例場景對應的協作的場景路徑，同時可以獲取場景執行的控制流和數據流，并用范疇－劃分方法生成相應場景路徑對應的集成測試用例。輸入為從協作圖中提取的信息中間表，輸出為生成的測試用例集合； 3、測試用例管理。為使得生成的測試用例集可復用、可維護、無冗余，對每個測試用例設計了增加、修改、刪除操作，用來在測試用例生成過程中管理這些測試用例集。  圖3 UMLTGF類圖 |
|
4、相關工作 盡管UML在工業界和研究領域用得相當廣泛，關于UML生成測試的研究相對較少。一般測試生成都是將UML模型圖轉換到一個現成工具能夠處理的中間的形式化描述，從而可以處理UML規約?；赨ML分析、設計模型獲取系統的相關信息生成各個階段的測試用例的研究近年來有不少成果，從設計階段的模型圖生成集成測試用例的研究較少，[13]提出一個新的基于UML的測試模型生成集成測試的測試用例的方法，該方法首先分析軟件系統的順序圖和協作圖，提取組件間的事件流，根據組件之間的消息轉移將順序圖和協作圖劃分為一組原子系統功能(ASF)單元，以每個ASF為一個節點、消息流為邊構造測試模型，使用面向對象的集成測試方法在測試模型上生成測試用例。 [12]提出基于UML設計規約生成集成測試用例的方法，用UML狀態機圖建立軟件動態行為的模型，組件之間的交互用圖上注解表示，將設計規約模型轉化為與集成系統的動態行為相應的全局FSM，在FSM上基于一定的覆蓋準則使用常規的等價類劃分方法生成可用于單元和集成測試的測試用例。[14]提出一種不需要其他形式化知識、只在UML框架內完成測試用例生成的UIT方法，選擇實現和執行每個用例圖描述的功能的相應順序圖、協作圖以及類圖，分析圖中元素的語義，識別出作為測試單元的參與交互的對象和與其相關的消息的等價類，定義測試規約，從圖中找到消息順序，使用傳統的Category Partition Method分析消息順序，生成最終的測試用例。[15]分析了UML規約級和實例級協作圖中所能表示的信息，將信息進行分類，有些信息可以用于對最終程序的靜態檢查，有些信息可用于動態測試；并設計了一個根據協作圖中信息對相應生成的程序進行插裝的算法，實現對測試滿足測試準則的程度的度量，但生成測試用例的方法還沒有給出。[16] 提出了一個基于UML順序圖設計的面向對象的軟件的自動測試的概念和相應的實現工具SeDiTeC。該方法提出一個可測試的順序圖的規則，凡是滿足可測試性需求的軟件系統的順序圖設計模型都可以作為測試規約，并介紹了從一個順序圖中生成測試用例的方法，在SeDiTeC中實現了完整的測試過程。 本文提出的從UML設計模型圖（協作圖、類圖）生成集成測試用例的方法，可以對表示復雜場景的協作圖進行處理，與上述方法是有一定區別，也是互補的。 5、總結和將來的工作 本文提出了一個基于UML協作圖，采用協作集成測試模式生成集成測試用例的方法，用基于線程執行的方法識別協作圖中的場景路徑，用控制流和數據流方法遍歷場景路徑獲取交互中的參數變量和方法調用序列，最后使用范疇－劃分方法找到場景路徑上的變量、方法、輸入、輸出、環境條件的合理組合作為覆蓋該場景路徑的測試用例；該方法的特點是：1、集合白盒方法和黑盒方法對協作圖描述的灰盒行為進行測試；2、完全基于UML；3、生成較少的測試用例；4、便于實現自動化。 對基于UML生成測試用例的研究還存在許多不足?；谠O計描述的形式化的測試準則相對還較少，基于UML模型圖生成測試用例的方法也在不停的研究與發展中，目前對UML模型圖作進一步精化或擴展其語義后，使用常規方法進行測試用例生成的情況較多，直接使用UML模型圖提供的信息的方法較少；把單個模型圖作為研究對象的較多，多個模型為同一測試用例生成提供信息的研究較少；針對測試過程中特定級別的測試（類級測試、集成測試）生成測試用例的方法較多，同一模型圖為多個級別測試生成測試用例的研究較少；在具體的方法研究中，假設的前提和約束太多，還不能夠達到實用的程度；對方法提供自動支持的工具大多是實驗室原型，還不能應用到工業界；可應用的領域還有許多局限；缺少整體的、系統的解決方法，還沒有能夠把待測試系統的所有能夠為測試用例生成提供信息的模型圖綜合利用，形成一個系統的測試用例生成方法，這也正是我們將來的研究方向。 我們將來的研究工作主要有幾個目標：第一，提出一種與面向對象軟件開發過程集成的測試過程，測試用例應以增量、系統的、與項目成本和進度相適應的可管理的數目的方法產生，利用業務模型生成用戶驗收測試的測試用例，利用UML分析模型生成系統測試的測試用例，利用UML設計模型生成集成測試的測試用例，利用實現模型生成單元測試的測試用例，能夠合理計劃測試資源，并能夠對軟件開發過程起到過程改進的作用；第二，針對UML單個模型圖，研究其在為不同層次測試生成測試用例的方法，提出相應可行的測試準則和評估方法，盡量能夠直接使用UML模型文檔；第三，針對某一層次測試的測試用例生成時，研究綜合利用待測試系統的各種模型圖生成該測試層次的測試用例的方法；第四，為上述方法提供自動的工具支持，并希望能夠與主流建模工具、測試工具集成。 參考文獻： |
原文轉自：http://www.anti-gravitydesign.com
