TWI262383B - A generic software testing system and method - Google Patents

Description

1262383 玖、發明說明 (發明說明應敘明：發明所屬之技術領域、先前技術、内容、實施方式及圖式簡單說明） 發明所屬之技術領域： 本發明係有關於一種通用型軟體測試系統與方 法，特別是有關於一種供分散式物件導向系統使用， 並可同步進行軟體製作與測試規劃步驟之通用型軟體 測試系統與方法。 先前技術： 一般軟體發展程序主要包括了五個階段：需求分 析、物件導向分析（Objected-Oriented Analysis ； 00A)、物件導向設計（0bjected-Oriented Design ; 00D)、系統實作、及系統整合與測試。其中系統整合 與測試這個階段主要的任務係在於進行系統整合並測 試之，以便評估於系統實作階段所完成的軟體程式是 否符合系統的需求。如果測試的結果不理想，則系統 開發者必須重新回到物件導向分析的階段，再根據開 發的程序做一些必要的修改。 然而，前述之反覆測試修改的過程常需要耗費大量 的時間和成本。加上，測試人員通常需花費許多時間 來與程式設計師進行溝通，以暸解系統實作的内容， 而且往往需等待系統實作完成後，始能進行測試計晝 與測試程式的撰寫，更會延宕軟體開發的完成。因此， 為了能讓測試工作簡化並儘早進行，必須讓測試人員 不必花費過多時間來與程式設計師溝通，便能充分地 1262383 瞭解待測系統的内容；並且，可在進行系統實作階段 製作軟體程式時，同時進行測試計晝與測試程式的撰 寫，藉以在軟體程式製作完成之後，可立即進行軟體 程式的測試並產生測試結果，以評估此軟體之功鈮正 確性與性能優劣。 於現有已申請之專利中，應用於製造業的美國專 利案號 6，4 2 1，8 2 2，提出一個對自動化程序產生測試 碼的方法，此專利係使用測試物件資料庫來進行測 試；應用於軟體開發的美國專利案號 6，3 5 3，8 9 7，提 出一種測試物件導向軟體的方法，此方法包括了一個 或多個軟體測試驅動程式的軟體測試架構，每個軟體 測試驅動程式有一或多個測試案例，使程式設計師可 以根據需要的案例進行測試而不需要熟練的測試工 程師；應用於圖形使用者介面（Graphic User Interface ; GUI)測試上的美國專利案號5,7 81，720，提 出一種測試使用者介面的方式，模擬使用者對GUI作 輸入的動作，以測試GUI的回應；應用於物件導向程 式類別測試的美國專利案號 5，7 9 4，0 4 3，提出使用一 測試器來測試類別中每個方法（method)的功能，並根 據測試器輸入的參數來測試方法的輸出結果；應用於 軟體測試的美國專利案號 6，1 8 2，2 4 5，提出一種利用 在伺服端（S e v e r )提供測試案例資料庫，以讓客戶端 (Client)取用來進行軟體測試的方法，此方法使用一 測試案例伺服器來儲存和管理測試案例；應用於網路 12 1262383 軟硬體測試的美國專利案號6，16 3，8 0 5 ’提出一種利 用網際網路（I n t e r n e t)提供使用者進行軟硬體測試的 方法，此方法使用使用者介面（u s e r 1 n te r f a c e )來提供 使用者選擇測試參數’並將測試資料封包送到使用者 的電腦；應用於軟體測試的美國專利案號5,7 9 9，2 6 6， 提出一種利用測試驅動程式產生器產生測試驅動程 式來測試函數的方法，此方法將函數的參數及執行順 序輸入測試驅動程式產生器’並藉由測試驅動程式來 測試。然而，上述之專利係針對個別應用的特性而提 出的測試方法或裝置，缺乏泛用性；無法簡化測試人 員與程式設計師間的溝通；更難以同時進行系統實作 以及測試計晝與測試程式的撰寫。 另一方面，目前已有數位學者對於利用統一模型語 言（Unified Model Language; UML)之設計模型，於測 試活動的可利用性進行研究，這些研究包含有： Chevalley(P. Chevalley， “Automated Generation of Statistical Test Cases from UML State Diagram，” in Proc. 2 5th Annual International Computer Software and Applications Conference, Chicago, U.S.A·， p p · 2 0 5 - 2 1 4，0 c t 2 0 0 1 ·)提出以機率概念設計一個功能 性測試方法來進行測試，其中此方法定義一自動化理 論，經由U M L的狀態圖（S t a t e D i a g r a m s )，自動產生測 試案例以供測試使用 ；Jean Hartmann et a 1. (J. Hartmann, C. Imoberdorf， and M. Meisinger， 13 1262383 “UML-Based Integration Testing，” in Proc. 2000 ACM International Symposium on Software Testing and Analysis， Volume 25, Issue 5, Portland, U.S.A., pp.60-7 0，Sep 2000.)提出：為了能利用狀態圖來進行 測試，需先選擇一套溝通語法（C 〇 m m u n i c a t i ο η Semantic)，再利用此語法將個別元件的狀態圖經過正 規化處理後，建立一個描述全系統的整體行為模型 (Global Behavioral Model)，再從此模型中找出進行整 合測試時所需的測試案例，以進行測試；Y · - G . K i m e t al.(Y.-G. Kim, H.-S. Hong, D.-H. Bae? and S.-D. Cha? “Test Cases Generation from UML State Diagrams，” in 1 9 9 9 Software，IE E Proceedings-，Volume 146，Issue 4，p p · 1 8 7 -1 9 2，A u g 1 9 9 9 ·)提出參考傳統測試理論中的 路徑測試 （Path Testing)相關方法，其係利用於狀態 圖中所找出的資料流（Data Flow)及控制流（Control Flow)，來進行測試。上述之研究普遍著重在如何利用 狀態圖，並參考物件可能之狀態轉變，來產生測試案 例。由於在UML的定義中，狀態圖係用於顯示某一物 件或類別在其生命週期中，對於事件的反應所發之一 連串的狀況變化。其目的為強調狀態與狀態之間的控 制流程。對於單一物件或類別而言，可由狀態圖產生 測試案例來進行測試。然而，對於物件與物件之間的 互動關係，或系統内元件與元件之間的訊息流程’則 無法以狀態圖來表示。因此，前述之測試機制雖可對 14 1262383 於單一類別或物件進行測試，但無法支援分散式系統 所需要的系統整合測試。 因此，非常迫切需要發展出一種供分散式物件導 向系統使用之通用型軟體測試系統與方法，藉以簡化 測試人員與程式設計師間的溝通；具有泛用性，小至 單一元件或模組，或大至整個分散式物件導向系統皆 可適用；同時進行系統實作以及測試計晝與測試程式 的撰寫，來提高軟體開發效率與降低開發成本。

鑒於上述習知之軟體測試技術缺乏泛用性；無法 簡化測試人員與程式設計師間的溝通；難以同時進行 系統實作以及測試計晝與測試程式的撰寫；無法支援 分散式系統所需要的系統整合測試。 因此，本發明的主要目的為提供一種通用型軟體 測試系統，藉以同時進行測試計晝和待測系統實作， 使待測系統實作一完成，便能立即進行測試工作，因 而縮短整個軟體開發生命週期，達到提高生產效率之 S 的。 本發明之又一目的為提供一種通用型軟體測試系 統與方法，藉以適用於各式分散式物件導向軟體與系 統整合產業，因而降低測試成本，提升整體開發效率。 本發明之再一目的為提供一種通用型軟體測試系 統與方法，藉以進行系統之功能性與非功能性測試。 15 1262383 根據以上所述之目的，本發明提供一種通用型軟 體測試系統，藉以供分散式物件導向系統進行測試， 其中此通用型軟體測試系統至少包括：測試計晝精靈 (Te st-Plan Wizard)，其中此測試計畫精靈根據類別圖 相關資料和循序圖相關資料，產生測試計晝執行碼 (Test Plan Execution Codes )和測試結果樣板 (Test-Result Template);受測軟體元件/系統，其 中此受測軟體元件/系統執行前述之測試計晝執行 碼，以產生測試結果；以及比較器，其中此比較器比 較前述之測試結果和前述之測試結果樣板，以產生測 試報告。 另外，本發明更提供一種通用型軟體測試方法， 藉以供分散式物件導向系統進行測試，其中此通用型 軟體測試方法至少包括：輸入類別圖相關資料至測試 計晝精靈，以作為測試的依據；自循序圖相關資料選 擇測試循序圖作為測試用，並輸入此測試循序圖的資 料至測試計晝精靈；針對測試循序圖填入複數個參考 輸入值和複數個參考輸出值；由測試計晝精靈產生内 含這些參考輸入值和這些參考輸出值的測試結果樣 板；將測試結果樣板送至比較器；由測試計晝精靈產 生測試計晝執行碼；由受測軟體元件/系統執行前述之 測試計畫執行碼，進行測試以產生測試結果；將測試 結果送至比較器；以及由比較器產生測試報告。 16 1262383 實施方式： 當物件導向設計階段完成時，會產生關於欲製作 之軟體的類別圖（Class Diagrams)與循序圖（Sequence

Diagrams)，而類別圖與循序 給程式設計師，來進行軟體 之技術常需待軟體實作完成 測試計晝與測試執行檔，因 產成本。 由於類別圖與循序圖所 人員製作測試計晝與測試執 要特徵係在於：讓測試人員 與循序圖，在程式設計師進 擬定測試計晝/測試執行檔。 試計晝與測試執行檔亦已就 測系統之各模組進行測試並 各模組或全系統之功能正確 本發明針對以物件導向 之分散式系統，提出有關於 由物件導向開發程序所使用 設計通用型軟體測試系統與 行測試活動。 請參照第1圖，第1圖為 測試系統與方法之訊號流程 通用型軟體測試系統主要係 圖主要係提供足夠的資訊 的實作。如上所述，習知 後，測試人員方開始製作 而曠日廢時，增加許多生 包含的資訊實已足夠測試 行檔，因此，本發明的主 與程式設計師利用類別圖 行軟體實作時，同時進行 故當軟體實作完成時，測 緒，可立即針對實作之待 產生測試結果，藉以評估 性與性能優劣。 開發程序為軟體開發準則 軟體測試程序之需求，藉 之UML塑模語言的特性， 方法，來輔助測試人員進 繪示本發明之通用型軟體 與功能示意圖。本發明之 由測試計晝精靈1 〇 〇、受測 17 1262383 軟體元件/系統2 Ο 0和比較器3 Ο 0所組成，藉以提供 試人員1 9以類別圖相關資料1 0為基礎，並根據循 圖相關資料20為劇本，分別以模組功能測試、系統 合測試、和性能測試等為目的，編輯測試計晝，並 生測試結果樣板4 0。測試計晝精靈1 0 0並藉由測試 畫的内容，產生測試計晝執行碼3 0。然後，受測軟 元件/系統2 0 0使用測試計晝執行碼3 0來執行軟體 試，而產生測試結果5 0。然後，將測試結果5 0與測 結果樣板4 0中的預期輸出值一起輸入比較器3 0 0中 以進行比較而產生測試報告6 0。 請繼續參照第1圖，其中各元件的詳細說明如Τ (1) 類別圖相關資料 1 〇至少包括複數個已經設 好的類別圖，以作為測試計晝精靈1 0 0設計受測系 之測試計畫的主要依據。如果要進行分散式系統的 合測試，則亦需要輸入受測系統中之各模組的輸出 入（I/O)介面的定義。 (2) 循序圖相關資料 20至少包括複數個已經設 好的循序圖，作為測試計晝精靈1 〇 〇設計受測系統 測試計晝的主要依據，並依實際需求先將循序圖分 幾個大小適當的情節（S c e n a r i 〇 s )，再依序進行測試 (3 )測試計晝精靈1 〇 〇係本發明之核心方法，用 將類別圖相關資料1 〇與循序圖相關資料2 0的資訊 換為測試計晝執行碼3 0，與供測試輸出比較用的標 測試結果樣板40。 測 序 整 產 計 體 測 試 計 統 整 輸 計 之 成 ► 來 轉 準 18 1262383 (4)測試結果樣板4 0係由測試計晝精靈1 Ο 0所產生 的標準參考值，用來和測試計晝執行碼3 0測試受測軟 體後所產生之測試結果5 0進行比較。 (5 )測試計畫執行碼3 0係由測試計畫精靈1 0 0依 據類別圖相關資料1 〇與循序圖相關資料2 0所產生， 用來測試受測軟體。 (6 )受測軟體元件/系統2 0 0係用來執行測試計畫 執行碼3 0，以進行測試並產生測試結果5 0。 (7 )測試結果 5 0存放有受測軟體的實際測試結果 值，作為與測試結果樣板40的標準參考值比較用。 (8 )比較器3 0 0係用來比較測試結果樣板4 0的標準 參考值與測試結果5 0的實際測試結果值，並產生測試 報告6 0。 (9)測試報告6 0係用來提供測試人員1 9參考之軟 體測試報告。 請繼續參照第1圖，其中各步驟之執行程序的敘 述如下： 首先，如步驟4 1 0所示，輸入類別圖相關資料1 0， 以作為測試的依據。在測試人員1 9選擇一張測試循序 圖（未標示）作為測試用（步驟4 2 0)之後，進行步驟4 3 0 以輸入所需的循序圖相關資料2 0。然後，測試人員1 9 針對測試循序圖填入參考輸入值和參考輸出值（步驟 4 4 0)。接著，如步驟 4 5 0所示，測試計晝精靈 1 〇 〇根 據類別圖相關資料1 〇、循序圖相關資料2 0、參考輸入 19 1262383 值和參考輸出值，產生内含參考輸入值和參考輸出值 的測試結果樣板4 0。然後，進行步驟4 6 0以將測試結 果樣板4 0送至比較器3 0 0。同時，如步驟4 7 0所示， 測試計畫精靈1 0 0根據類別圖相關資料1 0與循序圖相 關資料2 0，產生測試計畫執行碼3 0。 然後，受測軟體元件/系統2 0 0依據測試計晝執行 碼3 0，來進行測試（步驟4 8 0 )，而產生測試結果5 0 (步 驟 490)，其中此測試可為軟體元件或系統的測試，而 測試結果5 0包含有如測試時程紀錄、實際輸出值、錯 誤訊息等資料。接著，如步驟 5 0 0所示，將測試結果 5 0送至比較器3 0 0，並輸入至測試結果樣板4 0中，以 進行實際輸出與參考輸出的比對。然後再根據比較結 果產生測試報告6 0 (步驟5 1 0 )。 請參照第2圖，第2圖為繪示本發明之通用型軟 體測試系統與方法之使用案例圖（U s e C a s e D i a g r a m )。 依據上述之通用型軟體測試系統與方法的基本需求與 功能分析，如第 2圖，與本發明之通用型軟體測試系 統與方法有所互動關係的角色（Actors)有：測試人員 1 9，即操作本發明之通用型軟體測試系統的人；受測 軟體元件/系統2 0 0。而本發明之通用型軟體測試系統 所含有之使用案例（Use Case)有··輸入UML之類別圖 與循序圖；指定參考輸入輸出資料；產生測試計晝執 行碼；分析測試結果。 請參照第1圖和第3圖，第3圖為繪示本發明之測 20 1262383 試計晝精靈的功能方塊圖。以下將配合第 1圖和第 3 圖來詳細介紹各使用功能的機制： (1 ) 輸入U M L 之類別圖與循序圖 目前業界最普遍使用的UML編輯軟體為美商瑞里 (R a t i ο n a 1)公司所開發之R a t i 〇 n a 1 R 〇 s e開發工具。此軟 體提供使用者以視覺化繪圖介面根據UML之規範進行 00A及00D之工作。Rational Rose並將編輯結果以文 字檔格式儲存成延伸檔名為mdl之文件檔。 請參照第4圖和第5圖，第4圖為繪示本發明所 分析出之類別圖的文件結構圖，第5圖為繪示本發明 所分析出之循序圖的文件結構圖。為了讓本發明之通 用型測試系統能與較普遍化之UML編輯軟體整合，達 成通用化之目的，本發明參考0MG(0bject Management G r o u p )所公布的U M L規範，分析出類別圖文件結構9 1 0 (如第 4圖所示）和循序圖文件結構 9 4 0 (如第 5圖所 示）。請參照第3圖，根據前述之兩種文件（類別圖和 循序圖）的結構，本發明依所欲支援的編輯軟體不同 (如 Rational Rose 或其他支援 UML 塑模之編輯軟 體），設計了 UML文件的類別圖解析器（Parser)101和 循序圖解析器1 〇 3，使得測試人員1 9可將完成設計之 類別圖相關資料1 〇與循序圖相關資料2 0，輸入至測試 計晝精靈1 〇 〇來進行分析，並將所需要的資料取出以 便在後續工作中使用。以下係以對R a t i 0 n a 1 R 0 s e的支 援為範例來說明類別圖與循序圖的解析器。 21 1262383 (a)類別圖的讀取過程： 如第3圖所示，對於類別圖的解讀，測試人員} 9 首先將.mdl槽案之類別圖位置的資料，輸入至類別圖 解析器1 0 1 (步驟6 1 0)’以針對· m d丨檔案進行所有類別 資料的建立。然後’類別圖解析器1 〇 1進行類別圖解 析（步驟62 0)，如第4圖所示，對於一個類別而言，首 先，從如第3圖所示之類別圖相關資料1 〇中解析出類 別編號 （Class Number ) >並將其填入“類別 (Class)一N”攔位中。然後，讀出此類別的名稱（Name) 中之專屬名稱（theName)、型別（theStereoType)與父類 別（theSuperClass)， 接下來讀取類別的屬性 (Attribute)， 這屬性中包含 了 屬性名稱 (theAttributeName)、屬性型別（theAttributeType)、初 始 值 （t h e I n i t i a 1V a 1 u e) 與 屬 性 可 視 性 (theAttributeVisibility)等四個資料攔位。屬性解讀完 成後，繼續讀取操作方法（Operations)資料。對於操作 方法所具有 的 資 料 包括 有 方 法名 稱 (theOperationName) 、 回 傳 資 料 型 態 (theOperationReturnType) 方 法 可 視 性 (theOperationVisibility) 與 方 法 參 數 (theOperationParameter) 等四 個資料 欄 位〇 其中方 法 參數之下又包含了參數名稱（theParameterName)、參數 型另 |J (theParameterType)、初始值（thelnitialValue)與參 數可視性（theParameterVisibility)等四個資料欄位。依 22 1262383 此過程即可將類別圖之又’1干結構 <、> 第 J 圖所；）解鉍 ίΖ 來 (b)循庠圖的讀取過程： 對於循序圖之解謂：先將、ill d. i .標案中所.有的循序 圖名稱取出I以供測試人員1 9選取$測試人員i ίί可 選擇一或多張描述相關工作流程之測試循序圖：並輸 入測試循序圖至測試計晝產生器1 0 5 (步驟6 4 0 )，以進 行測試。將，m d 1檔案之測試循序圖位置的資料輸入至 循序圖解析器1 〇 3 (步驟6 5 0 )之後，再進行循序圖解析 (步驟6 6 0)。以下僅以單一循序圖來解釋解析程序，然 而，本發明並不在此限。

如第5圖所示，首先從循序圖相關資料2 0中解 析出情節編號（S c e n a r i ο N u m b e r)並將其填入“情節 (Scenario)_N”攔位中。然後根據情節編號解析出每 個情節使用到的物件（object)，並讀取此物件的專屬 名稱（theName)、型另(theStereoType)與父類另 >J (t h e S u p e r C 1 a s s ); 接著解析物件間的合作關係 (C ο 11 a b o r a t i ο η)，物件的每一個合作關係都有一個合 作 名 稱（theCollaborationName)、 循 序 號 碼 (theSequenceNumber) 、 受 觸 發 端 類 另1J (theSupplierClass)、 合作關係的方向（theDirection) 與方法資訊（Operationlnformation)。而合作關係的方 向（theDirection)可能從客戶（Client ; gp物件本身）到 供應者（S u p p 1 i e r)或是從供應者到客戶。因為合作關係 23 1262383 事實上是供應者的物件或類別的一個操作方法，所以 只需要知道此供應者類別的名稱和操作方法的名稱 即可，如果需要更詳細的方法資訊，只需參考類別圖 之文件結構（如第 4 圖所示），即可取得如方法名稱 (theOperationName) 、 回 傳 資 料 型 態 (theOperationReturnType) 、 方 法 可 視 性 (theOperationVisibility) 與 方 法 參 數 (theOperationParameter)等運作資料。 通常，一張循序圖可用來描述一個事件的一或多 個情節，而一個情節内可能含有一個以上之步驟。一 旦某個情節的參數被指定並且初始化之後，此情節中 的每一個步驟將依序執行直到輸出產生，所以測試計 晝將依照每一個情節來設計，而且循序圖解析器1 0 3 必須要能確認循序圖中的所有情節。在得到了類別圖 及循序圖的相關資訊後，然後，類別圖解析器1 0 1將 解析出之類別圖資訊傳至測試計畫產生器 1 0 5 (步驟 6 3 0)，循序圖解析器1 0 3將解析出之循序圖資訊傳至 測試計畫產生器1 0 5 (步驟6 7 0)。下一階段將根據類別 圖與循序圖編寫測試計晝及測試所使用之參考輸出 入值0 (2)指定參考輸入輸出資料： 測試計晝產生器1 〇 5根據每一張循序圖及其中的 情節設計測試計晝，以每張循序圖對應一個測試計 晝，且每個情節為一測試案例的方式，進行映對編輯 24 1262383 訊息的工作（步驟6 8 Ο)。並將產生出來的測試 交由參考輸出入值編輯器107來處理（700)。 入值編輯器1 〇 7根據測試計晝内容找出與計 類別，並參考此類別所需用到的操作資訊， 輸入輸出介面（步驟7 1 0)，再要求測試人員1 考輸入值（及操作參數）和參考輸出值（即ΐ 值）（步驟7 2 0)。 為了確保將來之測試程式能順利執行， 員1 9進行各項資料之輸入後，參考輸出入值激 將根據各項資料值所應具有之資料型態進行 輸入資料之資料型態不符（如應輸入整數， 串），則要求測試人員重新輸入。最後，參考 交由測試碼產生器1〇9(步驟740)，來產生測試 碼30(步驟750)，並由輸出入值編輯器107建立 步驟及參考輸出入值等資料之測試結果樣击 7 3 0)，待與實際進行的測試結果比對之用。 (3 )產生測試計晝執行碼3 0 : 在測試計晝產生器1 〇 5決定要對哪一條 進行測試後，測試計畫產生器1 〇 5會將相關 程資訊送往測試碼產生器1 〇 9 (步驟6 9 0 )，以 測試計晝執行碼。待測試碼產生器1 〇 9得到 入值編輯器送來的參考輸入值後（步驟740)， 生器 109 開始建立產生測試計晝執行碼 7 5 0)，以執行實際測試。 計晝内容 參考輸出 晝有關之 產生資料 9鍵入參 頃期回傳 在測試人 高輯器107 檢驗。若 卻輸入字 輸入值將 計畫執行 包含測試 i 4 0 (步驟 訊息流程 的訊息流 準備產生 參考輸出 測試碼產 3 0 (步驟 25 1262383 (4 )分析測試結果： 由於已經有了包含測試步驟及參考輸出 料之測試結果樣板4 0，以及測試計晝執行碼： 試後所產生的測試結果5 0，故比較器3 0 0 (如 示）可比較參考輸出跟實際輸出内容，產生 60 〇 值得一提的是，針對分散式系統軟體 同，本發明可分別適用於元件測試和系統整 對於元件測試，測試標的為元件内部的類別 測試劇本為描述此元件動態行為之循序圖； 整合測試，測試標的為各元件之輸入輸出 義，測試劇本為描述各元件間訊息架構的循 設將一個元件視為一個物件，那麼元件的介 就類似於類別圖。另外，如果分散式i C ORB A (Common Object Request Broker Arc 來作為其通訊基礎架構，那麼用來表示各元 定義的介面定義語言（Interface Definition IDL)檔案就相當於類別圖中的.mdl檔案。因 使用UML為工具來描述各種系統層次的物件 循序圖，就可運用本發明之通用型軟體測試 法來進行小至各個元件，大至整個分散式物 統的功能性與非功能性測試。 以下再以一具有三層式架構之應用實例 入值等資 3 0執行測 第1圖所 測試報告 的層次不 合測試。 結構圖， 對於系統 介面的定 序圖。假 面定義圖 ^統使用 hitecture) 件間介面 Language, 此，只要 類別圖與 系統與方 件導向系 來進一步 26 1262383 說明本發明。 請參照第 6圖，第 6圖為繪示本發明之實施例之 物件導向設計階段的類別圖。其中此類別圖中設計了 一個角色（即客戶端）和三個類別，即通用月艮務代理 者 （genericServiceAgent) 、 服 務 代 理 者 (ServiceAgent)、和資料處理者（DataHandler)，其中客 戶端為提出需求者。通用服務代理者定義了一般的伺 服端元件接受呼叫時所需具有的基本功能，如客戶端 向伺服端提出服務要求，則伺服端需先進行註冊之動 作。服務代理者繼承自通用服務代理者，具有通用服 務代理者所有之功能，並提供伺服端所具有之服務的 内容。資料處理者根據服務代理者的要求，至資料庫 中取資料供服務代理者使用。 請參照第7圖，第7圖為繪示本發明之實施例之 物件導向設計階段之循序圖。整個循序圖有四個步 驟，並且被分為兩個情節，情節的劃分是以所要測試 的程式功能作為分割依據。一張循序圖可以被劃分為 一或數個欲測試的功能，每個功能是由一或數個步驟 所組成，依序將各個功能規劃成一個情節進行測試。 以本應用實例來說，當客戶端向伺服端提出服務請求 時，首先需由客戶端向伺服端之服務代理者提出要求 服務之註冊，即服務代理者中的r e g i s t e r ()(步驟8 1 0 ); 等到註冊成功後，客戶端才可以向服務代理者提出服 務要求，所以將其劃分為第一個情節（即 Scenario 27 1262383

Number = 1 )，以測試其註冊功能。待註冊成功後， 客戶端即可向服務代理者提出服務要求，即服務代理 者中的 requestService()。 服務代理者執行 requestService()(步驟 820)，並根據 requestService() 中的需求，向資料處理者執行queryData()(步驟830)， 以取得相關資料。在收到回應的資料後，服務代理者 執行processData()(步驟840)， 以進行客戶端所要求 的服務，步驟8 2 0、8 3 0和8 4 0這三個步驟組成一個回 應客戶端請求的服務功能，因此將其劃分為第二個情 節（即S c e n a r i ο N u m b e r = 2 )以測試其服務功能。 以下為本實施例之測試計晝的建構步驟： 步驟一： 輸入UML 之類別圖與循序圖 (a)類別圖讀取過程 請參照第8圖，第8圖為繪示本發明之實施例之 類別圖解析器解析· m d 1檔案中之類別圖資訊的過程示 意圖。Rational Rose UML Model 檔案 900 即為第 6 圖 中之服務代理者在.m d 1檔案中的相關文件。此文件經 由類別圖解析器1 〇 1參考如第4圖所示之類別圖文件 結構9 1 0的描述，解析出類別資訊圖（C 1 a s s I n f 〇 r m a t i ο η D i a g r a m ) 9 2 0。配合設計之範例，解釋詳細操作過程敘 述如下。

Rational Rose UML Model 檔案 9 00 為.mdl 檔案中 有關於服務代理者類別的資料段落。根據前述之類別 圖解析器1 〇 1的讀取方式，在輸入· m d 1檔後，類別圖 28 1262383 解析器 1 Ο 1先根據“ o b j e c t C 1 a s s ，，（類別名稱）之關鍵 字，找出該.mdl檔案中所有之類別，並擷取出有關之 資料段落。如第8圖所示之段落中，行1 - 5敘述了關 於服務代理者的Class名稱（行1)、stereotype (行2)、 superclass (行 3-5)等資料，將解析出來的 Class名 稱”ServiceAgeIlt”（行l)參考類別圖文件結構910，填入 名稱項目的專屬名稱攔位；將stereotype: “control”（行 2)填入名稱項目的型別欄位；並將 superclass: “吕61161：丨〇861：¥1〇6人86 111：’’填入名稱項目的父類別欄位。

ClassAttribute:“agentID”（行 36)包含了三個屬性 “string”、“Service一 1”與 “Public”（行 37_39)，依照類別 圖文件結構 9 1 0，填入屬性項目下的四個攔位（如類別 資訊圖 920 所示）。最後將 Operation: “requestService” (行 7)及其下所包含的兩個資料“Integer”與 “Pub lie”（行 1 7、1 8)填入操作方法—1項目下的三個攔 位。依相同的解析原則，有關操作方法_ 1之下的兩個 參數 “theParameter_l ”和 “theParameter_2” 的資料亦能 依序填入。 (b)循序圖讀取過程 請參照第9圖，第9圖為繪示本發明之實施例之 循序圖解析器解析.mdl檔案中之循序圖資訊的過程示 意圖。Rational Rose UML Model 檔案 930 為如第 7 圖 戶斤示之循序圖以.mdl檔表示之部分資料。此文件經由 循序圖解析器1 〇 3 如第5圖所示之參考循序圖文件結 29 1262383 構 940 的描述，解析出循序資訊圖（Sequence I n f 〇 r m a t i ο n D i a g r a m ) 9 5 0例之設計，詳細操作過程敘 述如下。 為了讓循序圖解析器 1 〇 3 能夠辨認出每一個情 節，我們在循序圖文件結構 940中增加設計了一個 S c e n a r i 〇 — N 的欄位，以紀錄一合作關係所代表的情節 編號，同時S c e n a r i 〇 — N值的存在代表此合作關係為一 情節的起點。另一方面，測試人員以註解（Note)的形 式，利用 UML所定義的註解“Note”，在循序中的每一 個情節的第一個合作關係加上一個註解，並在該註解 的内容中寫入 “ScenarioNumber = N”的字串，其中N 代表各情節在循序圖中發生的先後順序。循序圖解析 器1 0 3讀取出合作關係的情節號碼“ S c e n a r i ο N u m b e r = 2” （行2)填入上述的Scenario—N欄位中，測試計畫產 生器將可依據該情節號碼編輯測試計畫中各合作關係 在測試計晝中的執行順序。 請參照第 9圖之Rational Rose UML Model檔案 9 3 0,在.mdl檔案中，循序圖解析器1 03搜尋“ Scenario Number = 2’’的字串（行 2)，得到此字串是位於 以’’（object Note View @50”為首的資料段落中（行1)， 其中“ 50”代表其在.mdl 檔中的圖形編號，此為獨二 的號碼，在同一 .mdl檔中不會重複出現為其他圖示的 編號。根據編號5 0，搜尋編號（5 0 + 1 )即5 1的點線連 結（行3 )，此點線連結描述上述註解圖示（@ 5 0 )與 30 1262383 合作關係圖示（@ 4 2 )(請參照第7圖）的連結參考； 行4、5記錄了此連結兩端的圖示編號即@50和@42， 其中@ 5 0即為上述之註解圖示，@ 4 2則為受到連結的 合作關係，client @42與supplier @50代表這兩個圖 示（請參照第7圖）之間的關係（@5 1 )是由@42連接 到@50。因此可以得到上述註解所註明的 Scenario Number的測試執行點是在.mdl檔案中所描述的編號為 @42的合作關係，於是根據@42，從.mdl檔案中找到 的關於此合作關係的資訊（行 6 )。行 7 : requestService(Integer，String )為描述此合作關係的 操作方法，再根據此操作方法解析出.mdl檔案中有關 於說明此操作方法之物件的資料段落（行3 0 )。 將解析出來的Object :“〇 Client”（行30)填入第9圖 之循序資訊圖 9 5 0的物件下之專屬名稱攔位，此物件 的型別攔位資料可從類別圖文件結構中取得。此外， 由於此物件沒有父類別，因此不需填寫父類別攔位。 而此物件與其他物件之合作關係，即 operation: “ r e q u e s t S e r v i c e () ”則建立於合作關係之項目内，並將 object Message :“requestService”（行 35、36)填入合作 名稱欄位，將 S e q u e n c e : “ 2 ”（行 3 8 )填入循序號碼欄 位，將 supplier: “oServiceAgent”（行 33)填入受觸發 類別攔位，將 d i r : “ F r 〇 m C 1 i e n t T 〇 S u p p 1 i e r ”（行 3 7 )填 入合作關係的方向攔位。至於方法資訊欄位之資訊可 從類別圖文件結構内關於 Service Agent 的解析中取 31 1262383 得。由於測試程式在執行步驟820的requestService() 操作方法時，會自動呼叫步驟8 3 0的q u e r y D a t a ()操作 方法與步驟 8 4 0的 p r o c e s s D a t a ()操作方法，並將結果 傳回步驟8 2 0的r e q u e s t S e r v i c e ()操作方法，因此測試 本情節時並不需要解析步驟8 3 0與步驟8 4 0的資訊。 步驟二：指定參考輸入輸出資料 請參照第1 〇圖，第1 〇圖為繪示本發明之實施例 包含參考輸出入值之測試結果樣板的示意圖，其中測 試計晝執行碼3 0是由測試碼產生器1 0 9所產生。測試 碼產生器1 〇 9依序將如第7圖中之第一個情節和之第 二個情節的操作方法塡入測試結果樣板4 0。為了知道 需要哪些參考輸入資料，參考輸出入值編輯器107首 先從如第8圖所示之類別資訊圖9 2 0和如第9圖所示 之循序資訊圖9 5 0中尋找所需執行的操作方法及其相 關的輸入資料。例如：第一個情節（第 7圖）中所需執 行的操作方法為通用服務代理者類別的 register()， register^)的參數名稱是ID 和Passwd，其資料型態為 string 〇 所有測試所需要的輸出入值資訊都經由參考輸出 入值編輯器1 〇 7產生，並顯示在測試結果樣板4 0，測 試工程師再分別將參考值填入相對應的欄位中，例如： ID 的參考輸入值為“ime”，Passwd 的參考輸入值為 “ 6 3 9 0 6 ”，並將預期的輸出結果填入相對應的輸出欄位 中，例如：r e g i s t e r ()的預期輸出值型態為“ Β ο ο 1 e a η ’’ ’ 32 1262383 其值為“True”。若預期輸出值為數值型態，如 registerService()的預期輸出值型態為“Integer”，亦可 填入預期輸出值的容忍誤差範圍如“士 1 5 ”。此外，在測 試結果樣板40中設計了一個重複（Repetition)攔位，供 測試人員填入測試程式執行的次數，假設填入值為η， 代表該情節將會被執行η次。 步驟三：產生測試計畫執行碼 根據物件導向分析與物件導向設計階段所產生的 測試計畫執行碼3 0的内容（第1 0圖），係分為兩部分， 進行測試程式與受測軟體連結之程式碼；以及是實際 執行測試計晝之測試程式。 產生測試計晝執行碼3 0的過程中，首先測試碼產 生器1 0 9得知此單元測試的受測類別有服務代理者與 資料處理者兩者，故首先在測試計晝執行碼 3 0 中建 立宣告該類別之實作物件的程式碼（如第 1 〇圖之測試 計畫執行碼 3 0中之行 4 - 5 )，以供之後的測試程式使 用。然後根據每個測試步驟建立測試程式，如測試計 晝執行碼3 0中之行6 -1 2，測試碼產生器1 0 9先從具有 參考輸入輸出值之測試結果樣板4 0中得到第一個情節 的輸出型態，其内容描述register之輸出值（回傳資料） 型態為 Boolean 資料型態，故建立行 8 中 Boolean Output_l 的程式段落。 從第1 0圖左側之類別資訊圖9 2 0 (請參照第8圖） 得知，操作方法名稱f e g i s t e r之P a r e n t C 1 a s s 為服務 33 1262383 代理者，於是利用行 4所建立之服務代理者的物件 oServiceAgent進行此操作方法之執行，並將參考輸入 值填入參數值中，完成此功能之測試計畫執行碼（行 8 - 9)。測試碼產生器1 0 9並產生時間記錄程式（行 7 : start_time = TestExec.getTime() 及行 10 · end — time = TestExec.getTime())，以供測試程式於執行 過程中之時間記錄使用。最後，再將資料寫入測試結 果樣版4 0中（行 1 1 -1 2)。同樣地，情節2之執行碼， 亦是依此相同之法則產生。 步驟四：分析測試結果 請參照第1 1圖，第1 1圖為繪示本發明之實施例 之測試結果的不意圖。在測試完成後’測試程式將執 行結果填入結果樣版 40 _ ，其内容包含執行時間 (Execution Time)及實際輸出（Actual Output)兩攔資 料。比較器將以實際輸出與參考輸出（Reference Output) 提供之容許值進行比較，若實際輸出值在容許範圍 中，則為通過測試（GO)，若非，則未通過測試（NG)。 另外，本發明可提供功能性與非功能性測試，因 為測試結果樣板中之參考輸出入欄位可依測試目的之 不同，而改變其攔位設計，故可經由修改攔位内容來 增加其對於各種測試之需求與彈性。對於軟體功能性 測試（F u n c t i ο n a 1 T e s t s )而言，因採用U M L循序圖為測 試依據，故可用類別中的屬性及操作參數為參考輸出 34 1262383 入資料設定之依據進行功能性測試工作。對於軟體非 功能性測試（Ν ο η - f u n c t i ο n a 1 T e s t s ) 而言，如壓力測試 及性能測試等，則可提供測試人員以新增或使用如重 複執行次數、重複執行時間間隔、執行時間記錄等欄 位於測試結果樣板的方式，搭配以循序圖的方式編輯 測試劇本，再匯入系統進行非功能性測試。 因此，本發明的優點為提供一種通用型軟體測試 系統與方法。本發明只需要類別圖（或介面定義）與循序 圖即可進行測試，故可同時進行測試計畫和待測系統 實作，使待測系統實作一完成，便能立即進行測試工 作，因而縮短整個軟體開發生命週期，達到提高生產 效率之目的。 本發明之又一優點為提供一種通用型軟體測試系 統與方法。本發明具有通用性，可適用於各式分散式 物件導向軟體與系統整合產業，小至各個元件或模 組，大至整個分散式物件導向系統，只要是以類別圖 (或介面定義）與循序圖的方式來表達功能與運作的系 統，都能運用本發明來進行測試計晝，因而可降低測 試成本，提升整體開發效率。 本發明之又一優點為提供一種通用型軟體測試系 統與方法。本發明不僅可以做元件測試，也可以進行 系統測試，只要將各元件之間的介面定義清楚，使用 例如介面定義語言（IDL)的方式來描述各元件之間的 35 1262383 介面，即可利用本發明來進行測試。 本發明之再一優點為提供一種通用型軟體測試系 統與方法，藉以進行系統之功能性與非功能性測試。 如熟悉此技術之人員所暸解的，以上所述僅為本 發明之較佳實施例而已，並非用以限定本發明之申請 專利範圍；凡其它未脫離本發明所揭示之精神下所完 成之等效改變或修飾，均應包含在下述之申請專利範 圍内。 圖式簡單說明： 本發明的較佳實施例已於前述之說明文字中輔以 下列圖形做更詳細的闡述，其中： 第1圖為繪示本發明之通用型軟體測試系統與方 法之訊號流程與功能示意圖； 第2圖為繪示本發明之通用型軟體測試系統與方 法之使用案例圖； 第3圖為繪示本發明之測試計畫精靈的功能方塊 圖； 第4圖為繪示本發明所分析出之類別圖的文件結 構圖， 第5圖為繪示本發明所分析出之循序圖的文件結 構圖， 第6圖為繪示本發明之實施例之物件導向設計階 段的類別圖， 36 1262383 第 7圖為繪示本發明之實施例之物件導向設計階 段之循序圖； 第8圖為繪示本發明之實施例之類別圖解析器解 析.m d 1 檔案中之類別圖資訊的過程示意圖； 第9圖為繪示本發明之實施例之循序圖解析器解 析.m d 1檔案中之循序圖資訊的過程示意圖； 第 1 0圖為繪示本發明之實施例包含參考輸出入 值之測試結果樣板的不意圖，以及 第 11圖為繪示本發明之實施例之測試結果的示 意圖。 圖號對 照說明： 10 類別圖相關資料 19 測試人員 20 循序圖相關資料30 測試計畫執行 碼 40 測試結果樣板 50 測試結果 60 測試報告 100 測試 計 m Μ. 101 類別圖解析器 1〇3 循序圖解析器 105 測試計晝產生器 107 參考輸出入值編輯器 109 測試碼產生器 200 受測軟體元件/系統 300 比較器 900 Rational Rose UML Model 檐案 37 類別圖文件結構 類別資訊圖

Rational Rose UML Model 槽案 循序圖文件結構 循序資訊圖 輸入類別圖相關資料 選擇一張測試循序圖作為測試用 輸入所需的循序圖相關資料 針對測試循序圖填入參考輸入值和參考輸出值 產生内含參考輸入值和參考輸出值的測試結果樣 板 將測試結果樣板送至比較器 產生測試計晝執行碼 進行測試 產生測試結果 將測試結果送至比較器 產生測試報告 將.mdl檔案之類別圖位置的資料輸入至類別圖解 析器 類別圖解析 選擇測試循序圖，並輸入測試循序圖至測試計晝產 生器 將.mdl檔案之測試循序圖位置的資料輸入至循序 38 1262383 660 670 680 690 700 710 720 730 740 750 810 820 830 840 圖解析器 循序圖解析 將解析出之循序圖資訊傳至測試計晝產生器 映對編輯訊息 將相關的訊息流程資訊送往測試碼產生器 將產生出來的測試計晝内容交由參考輸出入值編 輯器 產生資料輸入輸出介面 鍵入參考輸入值（及操作參數）和參考輸出值 建立包含測試步驟及參考輸出入值等資料之測試 結果樣板 測試碼產生器得到參考輸出入值編輯器送來的參 考輸入值 建立產生測試計晝執行碼 執行 register(); 執行 requestService() 執行 queryData() 執行 processData()

Claims (1)

1262383 向 相 少 至 循 件 中 人 測 值 和 受 果 測 同 統 94H丨 1. 一種通用型軟體測試系統，藉以供一分散式物件導 系統進行測試，其中該通用型軟體測試系統至少包括： 一測试計晝精靈（Test-Plan Wizard)，係根據一類別圖 關資料和一循序圖相關資料，其中該類別圖相關資料至 包括複數個類別圖（Ciass Diagrams)，該循序圖相關資料 少包括選自複數個循序圖（SeqUence Diagrams)之一測試 序圖；該測試計晝精靈解析出該些類別圖中所紀錄的物 屬性（Attributes )與函數内容，並解析出該測試循序圖 所記錄之物件間之每一運作流程的步驟，並根據一測試 員於該測試循序圖中所指定之需要測試的步驟，以及該 试人員所輸入之複數個參考輸入值和複數個參考輸出 ，來產生一測試計晝執行碼（Test Plan Execution Codes ) 一測試結果樣板（Test-Result Template ); 一受測軟體元件/系統，其中該受測軟體元件/系統接 該測試計晝執行碼之測試，以產生一測試結果；以及 一比較器，其中該比較器比較該測試結果和該測試結 樣板中之該些參考輸出值，以產生一測試報告，其中該 試報告係用以告知該測試結果是否該些參考輸出值相 2·如申請專利範圍第1項所述之通用型軟體測試系 ，其中該類別圖相關資料至少包括複數個輸出輸入（I/O) 40 1262383 介面定義，該些輸出輸入介面定義係定義該分散式物件導 向系統之複數個模組的輸出輸入介面。 3 ·如申請專利範圍第1項所述之通用型軟體測試系 統，其中該些類別圖係由美商瑞里（Rational)公司所開發 之Rational Rose開發工具所產生。 4 ·如申請專利範圍第1項所述之通用型軟體測試系 統’其中該測試循序圖係由美商瑞里（Rational)公司所開發 之Rational Rose開發工具所產生。 5 ·如申請專利範圍第1項所述之通用型軟體測試系 統，其中該測試計晝精靈更至少包括： 一類別圖解析器（parser)，其中該類別圖解析器自包含 該類別圖相關資料之統一模型語言（UML)檔案中解析出有 關該些類別圖的資訊並建立該些類別圖之文件結構而得一 類別資訊圖，該類別圖解析器係對該些類別圖中之複數個 類別分別讀出每一該些類別的名稱（theName)、型別 (theStereotype)與父類別（theSuperClass);讀取每一該些類 別的一屬性’該屬性至少包括有屬性名稱 (theAttributeName) > 屬性型別（theAttributeType)、初始 值 （thelrxitialValue) 與 屬性可 視 性 (theAttributeVisibility);讀取每一該些類別的一操作方法 41 1262383 (Operation) ’該操作方法所具有的資料至少包括有方法名 稱 （theOperationName) 、 回傳資 料 型 態 (theOperationReturnType) 、 方法 可視性 (theOperationV isibility) 與方 法參數 (theOperationParameter) ’其中該方法參數至少包括有參數 名稱（theParameterName)、參數型別（theParameterType)、 初始值 （thelnitialValue) 與 參 數 可 視 性 (theParameterVisibility)； 一循序圖解析器，其中該循序圖解析器自包含該循序 圖相關資料之統一模型語言（UML)檔案中解析出有關該測 試循序圖的資訊並建立該測試循序圖之文件結構而得一循 序資訊圖，該循序圖解析器從該測試循序圖中解析出一情 節編號（Scenario Number)，並根據該情節編號解析出每一 情節使用到的複數個物件（Objects)，且讀取每一該些物件 的名稱（theName)、 型另1J (theStereoType)與父類別 (theSuperClass)，並解析每一該些物件間的一合作關係 (Collaboration)， 該 合 作 關 係 具 有 名 稱 (theCollaborationName)、循序號碼（theSequenceNumber)、 受觸發端類別（theSupplierClass)，與合作關係的方向 (theDirection)； 一測試計晝產生器，其中該測試計晝產生器根據該類 別資訊圖、該循序資訊圖及其中的情節，來設計一測試計 晝； 一參考輸出入值編輯器，其中該參考輸出入值編輯器 42 1262383 根據該測試計晝產生一資料輸入輸出介面，以輸入該些參 考輸入值和該些參考輸出值，該輸出入值編輯器再根據該 測試計晝、該些參考輸入值和該些參考輸出值，來建立該 測試結果樣板，以及 一測試碼產生器’其中該測試碼產生器根據該測試計 晝、該些參考輸入值和該些參考輸出值，來產生該測試計 晝執行碼以執行實際測試。 6. 如申請專利範圍第 5項所述之通用型軟體測試系 統，其中該分散式物件導向系統係由複數個元件所組成，該 分散式物件導向系統係使用 C ORB A( Comm on Object Request Broker Architecture)來作為通訊基礎架構，而該些 元件的介面定義圖資料和該些元件間的關係圖資料係使用 介面定義語言（Interface Definition Language，IDL)樓案來 表示。 7. 如申請專利範圍第 5項所述之通用型軟體測試系 統，其中該測試結果樣板更至少包括複數個欄位，藉以供 該分散式物件導向系統進行非功能性測試。 8. 如申請專利範圍第 7項所述之通用型軟體測試系 統，其中該些欄位更至少包括一重複執行次數的攔位、一 重複執行時間間隔的攔位以及一執行時間記錄的欄位，該 測試人員可透過該參考輸出入值編輯器輸入一測試步驟的 43 1262383 該重複執行次數以及重複該執行時間間隔，而該測試計晝 執行碼便會依照所填的該執行時間間隔去重複執行該測試 該步驟，直到達到所填的該重複執行次數為止，並產生該 測試報告。 9. 一種通用型軟體測試方法，藉以供一分散式物件導向 系統進行測試，其中該通用型軟體測試方法至少包括： 輸入一類別圖相關資料至一測試計晝精靈，以作為測試 的依據； 自一循序圖相關資料選擇一測試循序圖作為測試用，並 輸入該測試循序圖的資料至該測試計晝精靈； 針對該測試循序圖填入複數個參考輸入值和複數個參 考輸出值； 由該測試計晝精靈產生内含該些參考輸入值和該些參 考輸出值的一測試結果樣板； 將該測試結果樣板送至一比較器； 由該測試計晝精靈產生一測試計晝執行碼； 由與該類別圖相關資料和該循序圖相關資料所對應之 一受測軟體元件/系統執行該測試計晝執行碼，進行測試以 產生一測試結果； 將該測試結果送至該比較器；以及 由該比較器產生一測試報告。 1 0.如申請專利範圍第9項所述之通用型軟體測試方 44 1262383 法，其中該類別圖相關資料至少包括複數個輸出輸入介面 定義，該些輸出輸入介面定義係定義該分散式物件導向系 統之複數個模組的輸出輸入介面。 1 1.如申請專利範圍第9項所述之通用型軟體測試方 法，其中該類別圖相關資料至少包括複數個類別圖。 1 2.如申請專利範圍第1 1項所述之通用型軟體測試方 法，其中該些類別圖係由使用統一模型語言之一開發工具 所產生。 1 3 .如申請專利範圍第12項所述之通用型軟體測試方 法，其中該開發工具為美商瑞里公司所開發的 Rational Rose開發工具。 1 4.如申請專利範圍第 9項所述之通用型軟體測試方 法，其中該測試循序圖係選自複數個循序圖。 15.如申請專利範圍第14項所述之通用型軟體測試方 法，其中該些循序圖係由使用統一模型語言之一開發工具 所產生。 1 6.如申請專利範圍第1 5項所述之通用型軟體測試方 45 1262383 法，其中該開發工具為美商瑞里公司所開發的 Rational Rose開發工具。 1 7.如申請專利範圍第 9項所述之通用型軟體測試方 法，其中更至少包括： 由該測試計晝精靈之一類別圖解析器，來對該類別圖 相關資料進行解析而得一類別資訊圖； 由該測試計晝精靈之一循序圖解析器，來對該循序圖 相關資料進行解析，而得一循序資訊圖； 由該測試計晝精靈之一測試計晝產生器根據該類別資 訊圖、該循序資訊圖和該循序資訊圖中之複數個情節，來 產生一測試計晝； 由該測試計晝精靈之一參考輸出入值編輯器根據該測 試計晝產生一資料輸入輸出介面，以輸入該些參考輸入值 和該些參考輸出值； 由該輸出入值編輯器根據該測試計晝、該些參考輸入 值和該些參考輸出值，來建立該測試結果樣板；以及 由該測試計晝精靈之一測試碼產生器根據該測試計晝 和該些參考輸入值，來產生該測試計晝執行碼。 1 8.如申請專利範圍第 9項所述之通用型軟體測試方 法，其中該分散式物件導向系統係由複數個元件所組成，該 類別圖相關資料係為該些元件的介面定義圖資料’該循序 圖相關資料係為該些元件間的關係圖資料。 46 1262383 1 9 .如申請專利範圍第1 0項所述之通用型軟體測試方 法，其中該分散式物件導向系統係使用CORBA來作為通訊 基礎架構，而該些元件的介面定義圖資料和該些元件間的 關係圖資料係使用介面定義語言檔案來表示。 20.如申請專利範圍第 9項所述之通用型軟體測試方 法，其中該測試結果樣板更至少包括複數個攔位，藉以供 該分散式物件導向系統進行非功能性測試。 2 1.如申請專利範圍第20項所述之通用型軟體測試方 法，其中該些攔位更至少包括一重複執行次數的欄位、一 重複執行時間間隔的欄位以及一執行時間記錄的欄位。 47