專利名稱：利用馬爾可夫鏈根據(jù)uml規(guī)范生成性能測試的制作方法
技術(shù)領(lǐng)域：
本發(fā)明通常涉及軟件測試的領(lǐng)域，并且更特別地涉及一種用于將確定性狀態(tài)測試方法用于已經(jīng)使用統(tǒng)一建模語言(UML)用例(use case)和活動圖(activitydiagram)來建模的系統(tǒng)的技術(shù)和系統(tǒng)。
背景技術(shù)：
本申請要求于2005年3月30日提交的序列號為60/666,399的美國臨時申請的權(quán)益，該申請在此全文引入作為參考。
統(tǒng)一建模語言是在軟件工程中被用于對象建模和規(guī)范的語言。UML的重要特點是使用標(biāo)準(zhǔn)化的圖形符號來創(chuàng)建系統(tǒng)的抽象模型。UML被最廣泛地用來對軟件集約型系統(tǒng)進(jìn)行規(guī)范化、可視化、結(jié)構(gòu)化和文檔化。
UML用例建模和活動圖是由對象管理組(OMG)、即國際標(biāo)準(zhǔn)委員會來定義的。該規(guī)范的當(dāng)前和過去的版本可以從http://www.uml.org/處的OMG在線中得到。
一組UML圖被用來表示一系統(tǒng)。每個圖都是系統(tǒng)的模型的部分圖形表示。典型地，UML模型還包含文本文檔、諸如驅(qū)動該模型元素的所寫的用例和圖。
經(jīng)常用于以UML模型表示系統(tǒng)的一個圖是用例圖。UML用例圖被用于從自頂向下的觀點來表示該系統(tǒng)的功能性。每個用例都提供一個或多個場景來實現(xiàn)特定的商業(yè)目標(biāo)，這些場景傳達(dá)該系統(tǒng)應(yīng)當(dāng)如何與終端用戶或其他系統(tǒng)進(jìn)行交互作用。
一用例可以包含或擴(kuò)充(extend)其它用例。當(dāng)一個用例被包括在另一個用例中時，用“包含”關(guān)系。當(dāng)一個用例可能或可能沒有被包括在另一個用例中時，用“擴(kuò)充”關(guān)系。最終的層次可以跨越多個用例圖。
圖1的實例用例圖100表示能夠運行各種成分的多個實例的立體聲系統(tǒng)軟件，諸如可以用于客機(jī)機(jī)艙娛樂系統(tǒng)中，其中每個乘客部可以優(yōu)選不同配置的虛擬立體聲系統(tǒng)。頂層用例110立體聲系統(tǒng)“包含”開機(jī)用例120。設(shè)置選項用例130、無線電用例140和CD播放器用例150都“擴(kuò)充”了該立體聲系統(tǒng)用例110。
用例提供了一種自然的方式來分解大的對象。部分地出于那個原因，已經(jīng)根據(jù)用例生成軟件測試用例。具有用例層次允許在不同的級別上對測試用例生成進(jìn)行初始化。
當(dāng)對于測試用例生成進(jìn)行建模時，每個活動優(yōu)選地具有其自己的活動圖。如果用例已經(jīng)包含或擴(kuò)充了另一個用例，則所包含的或所擴(kuò)充的用例必須在該圖中被表示為與其相對應(yīng)的用例名字相同的活動。那提供了關(guān)于以其來執(zhí)行用例的次序的信息，并由此允許自動化。
圖2是實例活動圖200，該活動圖200表示圖1的用例圖100的頂層用例立體聲系統(tǒng)。因為該用例立體聲體統(tǒng)“包含”該開機(jī)用例，所以在該活動圖200的每條路徑中都有開機(jī)活動210。
“擴(kuò)充”該立體聲系統(tǒng)用例的無線電、設(shè)置選項和CD播放器用例分別通過活動240、250、260來表示。那些活動出現(xiàn)在該活動圖200的不同路徑上。代表該立體聲系統(tǒng)用例的給定實例的路徑在選擇源決策230中被確定。所有路徑終止于塊270。
OMG已完成擴(kuò)展UML以便實現(xiàn)性能建模的工作。參見http://www.omg.org處找到的OMG，RFPUML Profile for Scheduling Performance，and Time(OMGDocument formal/99-03-13，1999年3月)。
其他工作則集中于對用于性能分析的UML活動圖的增強(qiáng)。在C.Lindemann等人的Performance Analysis of Time-Enhanced UML Diagrams Based on StochasticProcesses(Proc.3rd Int’l Workshop on Software and Performance(WOSP)，意大利羅馬，pp.25-34(2002年7月))中，時間事件和變遷概率(transition probability)被添加到活動圖中，以致該活動圖能夠被映射到通用的半馬爾可夫過程，該通用的半馬爾可夫過程使用數(shù)值法來解決。
一種用于生成和執(zhí)行性能測試的已知方法是確定性狀態(tài)測試(DST)。例如，DST被描述在Alberto Avritzer和Elaine J.Weyuker的The Automatic Generation ofLoad Test Suites and the Assessment of the Resulting Software(21 IEEE Transactions onSoftware Engineering 705(1995年))中以及被描述在Alberto Avritzer和Brian Larson的Load Testing Software Using Deterministic State Testing(Proceedings of the 1993 Int’lSymposium on Software Testing and Analysis(ISSTA)的第82-88頁(ACM出版社，1993年6月))中，在此整體引入上述每篇論文的內(nèi)容。DST利用高級狀態(tài)定義和解析近似來識別代表在測試中的系統(tǒng)的連續(xù)時間馬爾可夫鏈中的最可能的狀態(tài)。因為那些最可能的狀態(tài)包含了在生產(chǎn)中最可能出現(xiàn)的問題，所以那些狀態(tài)表示要由性能測試運用的最佳狀態(tài)。
目前，不存在處理驅(qū)動DST工具的UML用例的自動方法。相反，通過人工指定場景來生成性能測試用例。這種操作模式需要人工評估系統(tǒng)需求，以便提取性能需求。對于大規(guī)模的甚至是中等規(guī)模的系統(tǒng)來說，這種模式是勞動密集型的和低效的。
因此目前需要提供一種用于生成測試軟件系統(tǒng)的性能測試用例的方法和系統(tǒng)。該技術(shù)應(yīng)該能夠處理具有多種可能執(zhí)行路徑和配置的系統(tǒng)，并且該技術(shù)在執(zhí)行實際范圍內(nèi)的測試硬件上應(yīng)該是可執(zhí)行的。該技術(shù)應(yīng)當(dāng)有助于實現(xiàn)自動化。就本發(fā)明人所知，目前還沒有這樣的技術(shù)可用。

發(fā)明內(nèi)容
本發(fā)明通過提供一種用于生成軟件系統(tǒng)的性能測試用例的方法來解決上述需求，該軟件系統(tǒng)包括形成狀態(tài)S＝(U1、U2、…、UN)的N個獨立類型的用例，其中UN是類型N的用例的數(shù)目。在本發(fā)明的一個實施例中，該方法包括使用確定性狀態(tài)測試來識別那些具有大于最小概率ε的出現(xiàn)的穩(wěn)態(tài)概率的狀態(tài)S；對于每個所識別的狀態(tài)S，定義活動圖；利用變遷概率對活動圖中的邊沿進(jìn)行標(biāo)記；以及搜索每個活動圖，以便將那些具有大于ε的出現(xiàn)概率的路徑識別為性能測試用例。
利用確定性狀態(tài)測試來識別那些具有大于最小概率ε的出現(xiàn)的穩(wěn)態(tài)概率的狀態(tài)S的步驟進(jìn)一步包括以下步驟；貫穿所有類型的用例遞增用例類型N；對于每個遞增的用例類型N，遞增起始于1的用例類型的數(shù)目UN；對于通過遞增數(shù)目UN所達(dá)到的每個狀態(tài)，通過遞歸地應(yīng)用確定性狀態(tài)測試來生成性能測試用例，該狀態(tài)具有大于ε的出現(xiàn)概率或者具有比率λN/μN≥1，其中λN表示當(dāng)有UN個用例時用例類型N的到達(dá)率，且μN表示當(dāng)有UN個用例時用例類型N的完成率；并且，如果通過遞增數(shù)量UN所達(dá)到的狀態(tài)并不具有大于ε的出現(xiàn)概率或者比率λN/μN≥1，以及所有用例類型N已經(jīng)不被遞增時，則繼續(xù)下一個用例類型N。
生成性能測試用例的步驟可以包含通過確定導(dǎo)致該狀態(tài)的狀態(tài)變遷的概率的結(jié)果(product)來確定該狀態(tài)的出現(xiàn)概率。
該方法可以進(jìn)一步包括啟發(fā)式地確定該最小概率ε的步驟。啟發(fā)式地確定該最小概率ε的步驟可以基于預(yù)定數(shù)目的性能測試用例。
搜索每個活動圖的步驟進(jìn)一步包括對于每個活動圖應(yīng)用廣度優(yōu)先搜索(breadth first search)算法。針對每個所識別的狀態(tài)S定義活動圖的步驟進(jìn)一步包括定義統(tǒng)一建模語言(UML)的活動圖。
該方法還可以包括執(zhí)行所識別的性能測試用例的步驟，該步驟是通過對于使用確定性狀態(tài)測試所識別的每個狀態(tài)S，對每個用例類型的用例數(shù)目UN進(jìn)行初始化；執(zhí)行與狀態(tài)S相關(guān)聯(lián)的最可能的路徑的所分類的列表中的路徑；以及驗證已達(dá)到該狀態(tài)S。
本發(fā)明的另一個實施例是一種計算機(jī)程序產(chǎn)品，該計算機(jī)程序產(chǎn)品包括其上記錄有計算機(jī)程序的計算機(jī)可讀記錄介質(zhì)，該計算機(jī)程序包括當(dāng)在計算機(jī)上執(zhí)行時用于指示所述計算機(jī)來控制該方法中的步驟的代碼裝置，該方法是用于針對包括形成狀態(tài)S＝(U1、U2、…UN)的N個獨立類型的用例的軟件系統(tǒng)來生成性能測試用例，其中UN是類型N的用例的數(shù)目，該方法包括步驟利用確定性狀態(tài)測試來識別那些具有大于最小概率ε的出現(xiàn)的穩(wěn)態(tài)概率的狀態(tài)S；對于每個所識別的狀態(tài)S，定義活動圖；利用變遷概率來標(biāo)記活動圖中的邊沿；以及搜索每個活動圖來將那些具有大于ε的出現(xiàn)概率的路徑識別為性能測試用例。
利用確定性狀態(tài)測試來識別那些具有大于最小概率ε的出現(xiàn)的穩(wěn)態(tài)概率的狀態(tài)S的步驟進(jìn)一步包括以下步驟貫穿所有類型的用例遞增用例類型N；對于每個遞增的用例類型N，遞增起始于1的用例類型的數(shù)目UN；對于通過遞增數(shù)目UN所達(dá)到的每個狀態(tài)，通過遞歸地應(yīng)用確定性狀態(tài)測試來生成性能測試用例，該狀態(tài)具有大于ε的出現(xiàn)概率或者具有比率λN/μN≥1，其中λN表示當(dāng)有UN個用例時用例類型N的到達(dá)率，且μN表示當(dāng)有UN個用例時用例類型N的完成率，；并且，如果通過遞增數(shù)量UN所達(dá)到的狀態(tài)并不具有大于ε的出現(xiàn)概率或者比率λN/μN≥1，以及所有用例類型N已經(jīng)不被遞增時，則繼續(xù)下一個用例類型N。
生成性能測試用例的步驟可以包含通過確定導(dǎo)致該狀態(tài)的狀態(tài)變遷的概率的結(jié)果來確定該狀態(tài)的出現(xiàn)概率。
該方法可以進(jìn)一步包括啟發(fā)式地確定該最小概率的步驟。啟發(fā)式地確定最小概率ε的步驟可以基于預(yù)定數(shù)目的性能測試用例。
搜索每個活動圖的步驟進(jìn)一步包括對于每個活動圖應(yīng)用廣度優(yōu)先搜索算法。針對每個所識別的狀態(tài)S定義活動圖的步驟還包括定義統(tǒng)一建模語言(UML)活動圖。
該方法還可以包括通過以下方式來執(zhí)行該所識別的性能測試用例的步驟對于每個使用確定性狀態(tài)測試所識別的狀態(tài)S，對每個用例類型的用例數(shù)目UN進(jìn)行初始化；執(zhí)行與狀態(tài)S相關(guān)聯(lián)的最可能的路徑的所分類的列表中的路徑；以及驗證已達(dá)到該狀態(tài)S。


圖1是示例性的UML用例圖，其示出被用作該本說明書中的實例的立體聲系統(tǒng)。
圖2是圖1的用例圖的系統(tǒng)的UML活動圖。
圖3是適于執(zhí)行根據(jù)本發(fā)明的方法的計算機(jī)系統(tǒng)的框圖。
圖4A示出包含針對圖1的用例圖的示例性路徑概率的表格。
圖4B是根據(jù)本發(fā)明的一個實施例的帶注釋的UML活動圖。
圖5是示出根據(jù)本發(fā)明的一個實施例的確定性狀態(tài)測試方法的流程圖。
圖6是示出根據(jù)本發(fā)明的一個實施例的方法的流程圖。
圖7是示出根據(jù)本發(fā)明的一個實施例的方法的流程圖。
具體實施例方式
本發(fā)明人已經(jīng)發(fā)現(xiàn)了一種用于當(dāng)使用UML用例模型和活動圖對應(yīng)用進(jìn)行建模時自動生成性能測試的定量方法。以下提出一種用于將UML用例模型和活動圖與DST結(jié)合的方法論。另外，針對系統(tǒng)的性能測試用例生成和執(zhí)行提出集成方法論，該系統(tǒng)是使用UML用例和UML活動圖來建模的。
本發(fā)明是一種模塊框架和方法并且被部署為如有形地被包含程序存儲裝置上的應(yīng)用程序那樣的軟件。通過圖形用戶接口(GUI)來訪問該應(yīng)用。用于執(zhí)行的應(yīng)用代碼可以駐留在本領(lǐng)域技術(shù)人員所公知的多個不同類型的計算機(jī)可讀介質(zhì)上。用戶通過計算機(jī)訪問該GUI來訪問該框架。
在圖3中示出了執(zhí)行本發(fā)明的實施例的指令的計算機(jī)21的實施例。描述了具有代表性的硬件環(huán)境，該環(huán)境表明了計算機(jī)的典型硬件配置。計算機(jī)21包含CPU23、存儲器25、用于讀取計算機(jī)可讀介質(zhì)上的計算機(jī)可執(zhí)行指令的讀取器27、通用通信總線29、帶有外部端口33的通信套件31、帶有外部端口37的網(wǎng)絡(luò)協(xié)議套件35和GUI39。
通信總線29允許在計算機(jī)21的部件之間進(jìn)行雙向通信。通信套件31和外部端口33允許在計算機(jī)21、其他計算機(jī)21以及外部兼容裝置(諸如采用諸如IEEE1394(火線或者i.LINK)、IEEE802.3(以太網(wǎng))、RS(推薦標(biāo)準(zhǔn))232、422、423，USB(通用串行總線)以及其它通信協(xié)議的膝上型計算機(jī)等)和其它裝置之間進(jìn)行雙向通信。
當(dāng)通過網(wǎng)絡(luò)進(jìn)行通信時，網(wǎng)絡(luò)協(xié)議套件35和外部端口37允許物理網(wǎng)絡(luò)連接和協(xié)議收集。協(xié)議可以包含TCP/IP(傳輸控制協(xié)議/網(wǎng)際協(xié)議)套件、IPX/SPX(網(wǎng)間分組交換/順序分組交換)、SNA(系統(tǒng)網(wǎng)絡(luò)結(jié)構(gòu))及其它協(xié)議。該TCP/IP套件包括IP(網(wǎng)際協(xié)議)、TCP(傳輸控制協(xié)議)、ARP(地址解析協(xié)議)、和HTTP(超文本傳輸協(xié)議)。網(wǎng)絡(luò)協(xié)議套件內(nèi)的每個協(xié)議都具有特定的功能，以便支持被耦合到網(wǎng)絡(luò)的計算機(jī)之間的通信。該GUI39包含圖形顯示器，諸如CRT、固定像素顯示器或者其它裝置41、輔助鍵盤(key pad)、鍵盤或觸摸屏43以及諸如鼠標(biāo)、跟蹤球、光筆或其它裝置等的指示裝置45，以便為本發(fā)明提供易使用的用戶接口。
計算機(jī)21可以是傳統(tǒng)的個人計算機(jī)，諸如基于PC、Macintosh或者UNIX的、運行其合適的OS(操作系統(tǒng))的工作站，該OS能夠通過有線(引導(dǎo)的)或是無線(未引導(dǎo)的)通信介質(zhì)與計算機(jī)進(jìn)行通信。CPU23執(zhí)行被存儲在存儲器25中的兼容的指令或軟件。那些本領(lǐng)域技術(shù)人員將會認(rèn)識到，本發(fā)明可在不同于那些所提及的平臺和操作系統(tǒng)上實踐。
本發(fā)明人建議利用到達(dá)率和離開率來注釋該用例模型，并自動地根據(jù)活動圖生成測試場景。隨后，該測試場景被用來測試由DST所生成的每個狀態(tài)。
總的方法包括為UML用例模型的每個成分分配到達(dá)率和離開率，并應(yīng)用DST算法來生成和執(zhí)行用于性能測試的測試用例。對于由DST算法所生成的每個狀態(tài)S，本發(fā)明的技術(shù)使用以下總的方法論來驗證狀態(tài)S1、每個狀態(tài)S＝(U1、U2、…、UN)是通過對類型1的用例U1、類型2的用例U2、和類型N的用例UN進(jìn)行初始化來形成的。例如，參見圖1的示例性客機(jī)機(jī)艙立體聲系統(tǒng)，該立體聲系統(tǒng)的狀態(tài)S＝(30)表示執(zhí)行該開機(jī)用例的30個乘客。
2、每個用例都被提煉成UML活動圖。
3、每個活動圖通過利用變遷概率標(biāo)記每個邊沿來轉(zhuǎn)換。針對利用來自(圖4A中所示的)表格400的變遷概率所標(biāo)記的頂層用例立體聲系統(tǒng)，圖4B示出活動圖401。例如，立體聲系統(tǒng)活動圖401的每條路徑都調(diào)用所包含的開機(jī)用例410，因此那個用例的概率405是1.0。另一方面，根據(jù)表格400中所示的概率，給定的路徑只調(diào)用無線電、CD播放器和設(shè)置選項用例440、450、460中的一個。那些概率在441、451、461處被標(biāo)記。
4、對于每個活動圖，利用廣度優(yōu)先搜索算法來提取覆蓋直至總概率(1-ε)的活動圖的最可能的路徑的所分類的列表，其中ε是描述總的放棄路徑概率的小數(shù)。ε是啟發(fā)式地計算出的概率。典型地，最初選擇ε的小值。該值被逐漸向上調(diào)節(jié)，直到測試用例的數(shù)目近似等于要執(zhí)行的由測試者指示為可行的數(shù)目為止?？梢允褂枚M(jìn)制搜索來完成ε的調(diào)節(jié)。
只要用例要求執(zhí)行，就選擇(與該用例相關(guān)聯(lián)的)最可能路徑的所分類的列表中的下一條路徑。
本發(fā)明的方法使用測試用例生成和執(zhí)行的分解方法?；谠撚美Ｐ投x，DST算法被用于測試用例生成和執(zhí)行。針對每個用例所生成的活動圖中的每個邊沿利用變遷概率來標(biāo)記。因此，針對每個活動圖，使用廣度優(yōu)先搜索算法來生成最可能的場景。在測試用例執(zhí)行期間，只要某一用例被規(guī)定在測試中的狀態(tài)的部分，那么一次一個地測試最可能的場景。
在前，在Avritzer和Weyuker中描述了一種適用于本發(fā)明的示例性的確定性狀態(tài)測試(DST)算法。該算法所采用的策略是生成具有大于ε的穩(wěn)態(tài)概率的所有狀態(tài)。
圖5中所示的算法500生成測試用例列表，該測試用例開始于軟件狀態(tài)S并通過每個用例類型遞增直至用例類型N。通過將表示用例類型的索引x設(shè)置為1以及將狀態(tài)S設(shè)置為(0、0、…、0)來對該算法進(jìn)行初始化(步驟510)。隨后開始該算法DST(S)(步驟510)。
最初將類型x的用例的數(shù)目N也設(shè)置為1加上狀態(tài)S中明顯是類型x的用例的數(shù)目(步驟520)。針對狀態(tài)S的算法的每一次迭代而遞增該數(shù)目。
接著通過添加用例類型x的多個實例來確定，是否達(dá)到了之前未達(dá)到的狀態(tài)(判斷步驟530)。如果沒有，則放棄該狀態(tài)并且該方法繼續(xù)進(jìn)行到下一個用例類型。
如果達(dá)到了之前未達(dá)到的狀態(tài)(判斷步驟530)，則判斷如此生成的狀態(tài)的穩(wěn)態(tài)概率P是否大于ε或者所生成的狀態(tài)是否具有比率λN/μN≥1(判斷步驟540)，其中λN表示當(dāng)有N個激活的類型x的用例時的到達(dá)率，以及μN表示當(dāng)有N個激活的類型x的用例時的完成率。如果兩種情況都滿足，則該算法繼續(xù)進(jìn)行到如下所述的步驟550。如果兩種情況都不滿足，則放棄該狀態(tài)并且該方法繼續(xù)進(jìn)行到下一個用例類型(步驟580)。因為根據(jù)那些狀態(tài)生成的所有狀態(tài)都保證具有小于ε的概率，所以描述了具有小于ε的概率并具有比率λN/μN≥1的狀態(tài)。如果比率λN/μN≥1，但是，與狀態(tài)相關(guān)聯(lián)的、小于ε的概率并不一定意味著接下來的狀態(tài)都將具有小于ε的概率，則那些狀態(tài)也不會被放棄。
對于其中滿足以上標(biāo)準(zhǔn)的狀態(tài)，通過添加一個或多個類型x的用例根據(jù)S生成用于所達(dá)到的軟件狀態(tài)的測試用例S’(步驟550)。通過在S’上遞歸地執(zhí)行DST算法來生成測試用例的列表(步驟560)。
如果有更多的用例類型(判斷步驟570)，則用例類型計數(shù)器x被遞增(步驟580)，并且繼續(xù)該方法。如果所有用例類型都已經(jīng)被考慮到了，則結(jié)束該方法(步驟590)。
如此處參考圖6的技術(shù)600所描述的那樣，本發(fā)明人已經(jīng)利用了以上用于根據(jù)UML用例圖和所注釋的活動圖來生成性能測試用例的DST算法。首先識別N個獨立的用例類型(步驟610)。該用例可以被編入索引以用于識別，諸如(1、2…、N)。利用到達(dá)率和離開率來注釋每個用例(步驟620)。例如，在客機(jī)機(jī)艙立體聲系統(tǒng)的用例中，可以在乘客選擇該無線電用例的情況下利用每小時30個實例來注釋無線電用例，以及在乘客終止無線電用例的情況下利用每小時25個實例來注釋該無線電用例。處于滿容量時，到達(dá)率和離開率是相等的。
定義高級狀態(tài)S＝(U1、U2、…、UN)(步驟630)。通過對類型1的用例U1、類型2的用例U2、…、以及類型N的用例UN進(jìn)行初始化來形成狀態(tài)S。
諸如以上描述的DST算法被用于(步驟640)生成形成S的、具有大于憑經(jīng)驗規(guī)定的ε的概率的最可能的狀態(tài)。利用DST算法生成的N個獨立的用例模型中的每個用例模型被提煉成N個活動圖(步驟650)。
如以上參考圖4A和4B所討論的那樣，那些活動圖的邊沿利用變遷概率來標(biāo)記(步驟660)。針對N個活動圖中的每個活動圖，應(yīng)用廣度優(yōu)先搜索(BFS)算法來生成具有大于ε的概率的K條最可能的路徑的列表(步驟670)。因此，對于活動圖I，將生成K_I條最可能的路徑。
在利用上述技術(shù)生成性能測試用例之后，利用圖7中所示的方法700來完成性能測試的測試用例執(zhí)行。通過上述DST算法所生成的最可能的狀態(tài)S＝(U1、U2、…、UN)中的每個狀態(tài)通過對類型1的用例U1、類型2的用例U2、…、以及類型N的用例UN進(jìn)行初始化來驗證(步驟710)。
為了對類型j的Uj操作進(jìn)行初始化，用例j的Uj實例按如下方式進(jìn)行初始化(步驟720)執(zhí)行(與用例模型j相關(guān)聯(lián)的)K_j條最可能的路徑的所分類的列表中的接下來的Uj條路徑(步驟730)。K_j條最可能的路徑的所分類的列表被組織為循環(huán)表(步驟740)。隨后驗證(步驟750)，已準(zhǔn)確達(dá)到了狀態(tài)S＝(U1、U2、…、UN)。
本發(fā)明能實現(xiàn)全部自動的性能測試生成過程。本技術(shù)與活動圖相結(jié)合并因此也允許執(zhí)行過程的全部自動化。目前，軟件工程中的大多數(shù)應(yīng)用領(lǐng)域均開發(fā)了對包括用例模型和活動圖的UML的需求。本發(fā)明因此能夠被應(yīng)用到各種領(lǐng)域中，如傳送帶、醫(yī)療系統(tǒng)、運輸系統(tǒng)、發(fā)電和輸電系統(tǒng)。
本發(fā)明可以通過使用證明已準(zhǔn)確達(dá)到了狀態(tài)S的不同方式來被概括。例如，在本發(fā)明的一個實施例中，由DST所生成的馬爾可夫鏈中的狀態(tài)S的所有路徑都被測試。另外，測試每個狀態(tài)時超出的時間可以通過要求每狀態(tài)下不同的測試工作來改變。
在本發(fā)明的另一個實施例中，每次以一狀態(tài)調(diào)用用例模型j的時候均測試(與用例模型j相關(guān)聯(lián)的)K_j條最可能的路徑的所分類的列表中的所有路徑。那個版本比其它所述實施例需要更多的工作，但是對于測試簡單的活動圖是經(jīng)濟(jì)的。
本發(fā)明可以被用于自動生成和執(zhí)行性能測試，該性能測試可以被用來驗證后勤和裝配產(chǎn)品的性能需求。
本發(fā)明的自動性能測試用例生成是一種比現(xiàn)有操作模式更有效的方法，該自動性能測試用例生成是根據(jù)UML用例模型驅(qū)動DST測試；即，對需求進(jìn)行人工評估以識別性能測試。與現(xiàn)有的操作模式相比，這能夠以一種更有效的方式被結(jié)合為標(biāo)準(zhǔn)軟件開發(fā)過程。
前述的細(xì)節(jié)描述應(yīng)當(dāng)被理解為是對本發(fā)明各個方面的說明和示例，但不是限制，并且在此所公開的本發(fā)明的范圍并不能根據(jù)本發(fā)明的說明書來確定，而是根據(jù)如根據(jù)由專利法所允許的充分的范圍所解釋的權(quán)利要求來確定。例如，雖然在此所公開的方法與軟件系統(tǒng)的測試結(jié)合，但是該方法也可以被用于其它復(fù)雜的系統(tǒng)中，諸如用于不必以軟件代碼來實施的商業(yè)或制造系統(tǒng)，同時也保留在本發(fā)明的范圍內(nèi)。應(yīng)當(dāng)理解，在此所示和所述的實施例只是用于說明本發(fā)明的原理，而且本領(lǐng)域技術(shù)人員在不脫離本發(fā)明的范圍和精神的情況下可以實現(xiàn)各種修改。
權(quán)利要求
1.一種用于生成軟件系統(tǒng)的性能測試用例的方法，該軟件系統(tǒng)包含形成狀態(tài)S＝(U1、U2、…UN)的N個獨立類型的用例，其中UN是類型N的用例的數(shù)目，該方法包括以下步驟利用確定性狀態(tài)測試來識別那些具有大于最小概率ε的出現(xiàn)的穩(wěn)態(tài)概率的狀態(tài)S；針對每個所識別的狀態(tài)S，定義活動圖；利用變遷概率對活動圖中的邊沿進(jìn)行標(biāo)記；以及搜索每個活動圖，以便將那些具有大于ε的出現(xiàn)概率的路徑識別為性能測試用例。
2.根據(jù)權(quán)利要求1所述的方法，其中，利用確定性狀態(tài)測試來識別那些具有大于最小概率ε的出現(xiàn)的穩(wěn)態(tài)概率的狀態(tài)S的步驟進(jìn)一步包括以下步驟；貫穿所有類型的用例遞增用例類型N；針對每個遞增的用例類型N，遞增起始于1的用例類型的數(shù)目UN；針對通過遞增數(shù)目UN所達(dá)到的每個狀態(tài)，通過遞歸地應(yīng)用確定性狀態(tài)測試來生成性能測試用例，該狀態(tài)具有大于ε的出現(xiàn)概率或者具有比率λN/μN≥1，其中λN表示當(dāng)有UN個用例時用例類型N的到達(dá)率，且μN表示當(dāng)有UN個用例時用例類型N的完成率；以及如果通過遞增數(shù)量UN所達(dá)到的狀態(tài)并不具有大于ε的出現(xiàn)的概率或者比率λN/μN≥1，并且所有用例類型N已經(jīng)不被遞增時，則繼續(xù)下一個用例類型N。
3.根據(jù)權(quán)利要求2所述的方法，其中生成性能測試用例的步驟包含通過確定導(dǎo)致一狀態(tài)的狀態(tài)變遷的概率的結(jié)果來確定該次態(tài)的出現(xiàn)概率。
4.根據(jù)權(quán)利要求1所述的方法，還包括以下步驟啟發(fā)式地確定最小概率ε。
5.根據(jù)權(quán)利要求5所述的方法，其中，基于預(yù)定數(shù)目的性能測試用例來啟發(fā)式地確定最小概率ε。
6.根據(jù)權(quán)利要求1所述的方法，其中，搜索每個活動圖的步驟還包括對于每個活動圖應(yīng)用廣度優(yōu)先搜索算法。
7.根據(jù)權(quán)利要求1所述的方法，其中，針對每個所識別的狀態(tài)S定義活動圖的步驟還包括定義統(tǒng)一建模語言(UML)活動圖。
8.根據(jù)權(quán)利要求1所述的方法，還包括通過以下方式執(zhí)行所識別的性能測試用例的步驟針對每個使用確定性狀態(tài)測試所識別的狀態(tài)S，對每個用例類型的用例數(shù)目UN進(jìn)行初始化；執(zhí)行與狀態(tài)S相關(guān)聯(lián)的最可能的路徑的所分類的列表中的路徑；以及驗證已達(dá)到該狀態(tài)S。
9.一種計算機(jī)程序產(chǎn)品，其包括其上記錄有計算機(jī)程序的計算機(jī)可讀記錄介質(zhì)，該計算機(jī)程序包括用于當(dāng)在計算機(jī)上執(zhí)行時指示所述計算機(jī)來控制該方法中的步驟的代碼裝置，該方法用于針對包括形成狀態(tài)S＝(U1、U2、…、UN)的N個獨立類型用例的軟件系統(tǒng)來生成性能測試用例，其中UN是類型N的用例的數(shù)目，該方法包括以下步驟利用確定性狀態(tài)測試來識別那些具有大于最小概率ε的出現(xiàn)的穩(wěn)態(tài)概率的狀態(tài)S；針對每個所識別的狀態(tài)S，定義活動圖；利用變遷概率對活動圖中的邊沿進(jìn)行標(biāo)記；以及搜索每個活動圖，以便將那些具有大于ε的出現(xiàn)概率識別為性能測試用例。
10.根據(jù)權(quán)利要求9所述的計算機(jī)程序產(chǎn)品，其中，利用確定性狀態(tài)測試來識別那些具有大于最小概率ε的出現(xiàn)的穩(wěn)態(tài)概率的狀態(tài)S的步驟進(jìn)一步包括以下步驟貫穿所有類型的用例遞增用例類型N；對于每個遞增的用例類型N，遞增起始于1的用例類型的數(shù)目UN；對于通過遞增數(shù)目UN所到達(dá)的每個狀態(tài)，通過遞歸地應(yīng)用確定性狀態(tài)測試來生成性能測試用例，該狀態(tài)具有大于ε的出現(xiàn)概率或者具有比率λN/μN≥1，其中λN表示當(dāng)有UN個用例時用例類型N的到達(dá)率，且μN表示當(dāng)有UN個用例時用例類型N的完成率；以及如果通過遞增數(shù)量UN所達(dá)到的狀態(tài)并不具有大于ε的出現(xiàn)概率或者具有比率λN/μN≥1，并且所有用例類型N已經(jīng)不被遞增時，則繼續(xù)下一個用例類型N。
11.根據(jù)權(quán)利要求10所述的計算機(jī)程序產(chǎn)品，其中，生成性能測試用例的步驟包含通過確定導(dǎo)致狀態(tài)的狀態(tài)變遷的概率的結(jié)果來確定該狀態(tài)的出現(xiàn)概率。
12.根據(jù)權(quán)利要求9所述的計算機(jī)程序產(chǎn)品，其中，該方法還包括以下步驟啟發(fā)式地確定最小概率ε。
13.根據(jù)權(quán)利要求12所述的計算機(jī)程序產(chǎn)品，其中，啟發(fā)式地確定最小概率ε的步驟基于預(yù)定數(shù)目的性能測試用例。
14.根據(jù)權(quán)利要求9所述的計算機(jī)程序產(chǎn)品，其中，搜索每個活動圖的步驟還包括對于每個活動圖應(yīng)用廣度優(yōu)先搜索算法。
15.根據(jù)權(quán)利要求9所述的計算機(jī)程序產(chǎn)品，其中，對每個所識別的狀態(tài)S定義活動圖的步驟還包括定義統(tǒng)一建模語言(UML)活動圖。
16.根據(jù)權(quán)利要求9所述的計算機(jī)程序產(chǎn)品，其中，該方法進(jìn)一步包括通過以下方式執(zhí)行所識別的性能測試用例的步驟對于每個使用確定性狀態(tài)測試所識別的狀態(tài)S，對每個用例類型的用例數(shù)目UN進(jìn)行初始化；執(zhí)行與所述狀態(tài)S相關(guān)聯(lián)的最可能的路徑的所分類的列表中的路徑；以及驗證已達(dá)到該狀態(tài)S。
全文摘要
在軟件開發(fā)過程初期，當(dāng)UML用例模型及其活動圖提煉被規(guī)定時，一種自動生成性能測試的測試用例的方法被用于測試用例規(guī)劃。在該系統(tǒng)被開發(fā)之后，所規(guī)劃的性能測試稍后在軟件開發(fā)過程中被執(zhí)行。利用操作到達(dá)率和離開率來注釋該用例模型。確定性狀態(tài)測試(DST)生成和執(zhí)行被用于性能測試生成和執(zhí)行。此外，描述了一種技術(shù)來生成最可能的測試場景，利用變遷概率對該活動圖中的每個邊沿進(jìn)行標(biāo)記，并且應(yīng)用廣度優(yōu)先搜索算法，以便針對由DST算法所生成的每個狀態(tài)選擇要被測試的最可能的路徑。
文檔編號G06F11/36GK1866206SQ20061009164
公開日2006年11月22日 申請日期2006年3月30日 優(yōu)先權(quán)日2005年3月30日
發(fā)明者A·阿夫里策爾, M·E·R·維拉 申請人:西門子共同研究公司