本文關(guān)鍵詞：軟件測試技術(shù)

  更多相關(guān)文章： 一種專利、基于專利、模型專利、軟件專利、測試專利、方法專利、說明書、專利查詢網(wǎng)、專利下載網(wǎng)

一種基于模型的軟件測試方法有效

申請?zhí)枺篊N201310455252.9 (進(jìn)入下載頁) 申請日：2013-09-27

申請/專利權(quán)人：西安電子科技大學(xué) 公開/公告號：CN103530228A

發(fā)明/設(shè)計人：段振華;苗俊磊;張南;田聰;王小兵;羅玲 公開/公告日：2014-01-22

主分類號：G06F11/36

分類號：G06F11/36

搜索關(guān)鍵詞：

 

該專利技術(shù)資料僅供研究查看技術(shù)是否侵權(quán)等信息，商用須獲得專利權(quán)人授權(quán)。該專利全部權(quán)利屬于西安電子科技大學(xué)，未經(jīng)西安電子科技大學(xué)許可，擅自商用是侵權(quán)行為。如果您想購買此專利、獲得商業(yè)授權(quán)和技術(shù)合作，請聯(lián)系【】

【說明書】：

技術(shù)領(lǐng)域

本發(fā)明涉及測試技術(shù)領(lǐng)域，具體來講是一種基于模型的軟件測試方法。

背景技術(shù)

近幾年來，隨著計算機軟硬件技術(shù)的迅猛發(fā)展，各種各樣的軟件系統(tǒng)應(yīng)運而生，社會各行各業(yè)對軟件系統(tǒng)的依賴越來越強，軟件系統(tǒng)的規(guī)模越來越大，復(fù)雜性也越來越高，對軟件系統(tǒng)的質(zhì)量要求也顯得更為重要。軟件測試和驗證，是保證軟件正確性和提高軟件可靠性的最基本、最重要的手段。為了盡量減少花費在軟件產(chǎn)品測試上的時間和精力，大量研究機構(gòu)開始投入到軟件測試方法與測試工具的研究上。目前，軟件測試領(lǐng)域中的一個關(guān)鍵的、同時也是極為困難的問題就是：如何設(shè)計和生成有效的測試用例。

隨著面向?qū)ο筌浖_發(fā)技術(shù)的廣泛應(yīng)用和軟件測試自動化的要求，基于模型的軟件測試逐漸得到重視。目前，軟件測試技術(shù)大體上可分為兩大類：一類是白盒測試技術(shù)，另一類是黑盒測試技術(shù)。

白盒測試技術(shù)是把程序看成裝在一個白盒子里，即完全了解程序的內(nèi)部結(jié)構(gòu)和處理過程，按照程序內(nèi)部的邏輯結(jié)構(gòu)，檢驗程序中的每條通路是否都按照預(yù)定要求正確工作。白盒測試從考察程序的結(jié)構(gòu)和邏輯出發(fā)，驗證所構(gòu)造的程序是否符合設(shè)計要求，白盒測試包括邏輯覆蓋、域測試、符號測試、路徑分析、程序插樁及程序變異等。

白盒測試技術(shù)的缺點在于，白盒測試只根據(jù)程序的內(nèi)部結(jié)構(gòu)進(jìn)行測試，而不考慮程序的外部特征，如果程序結(jié)構(gòu)本身有問題，比如程序邏輯有誤或是有紕漏，就無法發(fā)現(xiàn)錯誤。另外，即使將程序中的每條路徑都測試了仍然可能有錯誤，原因在于：第一，窮舉路徑測試不能查出程序違反了設(shè)計規(guī)范；第二，窮舉路徑測試不可能查出程序中因紕漏路徑而出現(xiàn)的錯誤；第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。

黑盒測試技術(shù)，又稱為功能測試技術(shù)，與白盒測試技術(shù)恰恰相反，它把程序看成一個黑盒子，完全不用考慮程序的內(nèi)部結(jié)構(gòu)和處理過程。黑盒測試是在程序接口進(jìn)行的測試，它只檢查程序功能是否按照預(yù)先的要求正常工作，即接收輸入數(shù)據(jù)是否產(chǎn)生正確的輸出結(jié)果。黑盒測試技術(shù)包括邊界值分析技術(shù)、等價分類技術(shù)及因果圖技術(shù)等。

黑盒測試技術(shù)的缺點在于，黑盒測試是一種窮舉輸入的測試方法，不僅要窮舉所有合法的輸入，還要窮舉那些不合法但是可能的輸入進(jìn)行測試。但是根據(jù)軟件測試的局限性，不太可能完全覆蓋所有的輸入情況，測試代價太大。黑盒測試的研究重點在于如何從輸入域中選擇適當(dāng)數(shù)量的、對發(fā)現(xiàn)錯誤具有代表性的測試輸入來有效的進(jìn)行測試。

白盒測試方法是從開發(fā)者的角度在源代碼級使用軟件分析和理解技術(shù)，對程序的內(nèi)部邏輯結(jié)構(gòu)進(jìn)行分析來測試系統(tǒng)，而黑盒測試方法通過從用戶的角度測試軟件系統(tǒng)是否符合需求規(guī)格，這兩類方法各有側(cè)重，在測試的實踐中是互補的。但它們又各有缺點，并且不能在方法內(nèi)部進(jìn)行完善來解決，而且在面向?qū)ο笳Z境下，軟件的設(shè)計思路和軟件的結(jié)構(gòu)，與傳統(tǒng)的面向過程的軟件相比有了很大的變化，而傳統(tǒng)的軟件測試方法不能適應(yīng)這樣的變化。

發(fā)明內(nèi)容

針對現(xiàn)有技術(shù)中存在的缺陷，本發(fā)明的目的在于提供一種基于模型的軟件測試方法，通過UML（unified爉odeling爈anguage，統(tǒng)一建模語言）模型圖自動生成滿足一定覆蓋準(zhǔn)則的測試用例，從而快速有效的完成軟件測試，適應(yīng)軟件的設(shè)計思路和軟件的結(jié)構(gòu)、與傳統(tǒng)的面向過程的軟件之間的變化，彌補白盒測試和黑盒測試的不足。

為達(dá)到以上目的，本發(fā)明采取的技術(shù)方案，一種基于模型的軟件測試方法，其特征在于，包括如下步驟：

S1.分析被測試軟件，根據(jù)測試目的，確定測試對象和測試特征；

S2.選擇和構(gòu)造UML模型，該UML模型表述了需求所表述的所有可能行為；

S3.對UML模型進(jìn)行驗證，排查UML模型構(gòu)造時可能出現(xiàn)的有界性、安全性、死鎖和狀態(tài)可達(dá)性，確保UML模型的正確性；

S4.通過深度優(yōu)先搜索算法遍歷UML模型，自動生成測試用例，根據(jù)充分性準(zhǔn)則計算相關(guān)的覆蓋率，完成對測試用例的評估；

S5.根據(jù)待測程序和所述UML模型得到的測試用例生成測試腳本，自動執(zhí)行所述測試腳本，并保存執(zhí)行測試腳本得到的實際輸出結(jié)果；

S6.根據(jù)測試用例的實際輸出與預(yù)期輸出的比較，得出測試結(jié)果，再根據(jù)測試目標(biāo)與預(yù)先設(shè)定好的停止準(zhǔn)則，決定是否需要修改模型或修改待測程序。

在上述技術(shù)方案的基礎(chǔ)上，所述充分性準(zhǔn)則包括：

基于控制流的充分性準(zhǔn)則：語句覆蓋準(zhǔn)則、條件覆蓋準(zhǔn)則和判斷覆蓋準(zhǔn)則；

基于數(shù)據(jù)流的充分性準(zhǔn)則：定義引用覆蓋準(zhǔn)則、上下文覆蓋準(zhǔn)則；

基于故障的充分性準(zhǔn)則：弱變異覆蓋準(zhǔn)則、強變異覆蓋準(zhǔn)則。

在上述技術(shù)方案的基礎(chǔ)上，所述覆蓋率用來度量測試完整性和充分性，其包括：邏輯覆蓋、函數(shù)覆蓋以及功能覆蓋，其中邏輯覆蓋包括：語句覆蓋、判定覆蓋、條件覆蓋以及路徑覆蓋。

在上述技術(shù)方案的基礎(chǔ)上，所述S1中分析被測試軟件包括：被測試軟件是面向?qū)ο蟮拈_發(fā)技術(shù)或者是面向過程的開發(fā)技術(shù)、被測試軟件所采用的開發(fā)語言、被測試軟件開發(fā)的系統(tǒng)環(huán)境。

在上述技術(shù)方案的基礎(chǔ)上，所述UML模型為機器可讀的模型，用于對被測試軟件進(jìn)行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)的文檔。

在上述技術(shù)方案的基礎(chǔ)上，所述S3中，對UML模型進(jìn)行有界性、安全性、死鎖及狀態(tài)可達(dá)性驗證。

在上述技術(shù)方案的基礎(chǔ)上，所述停止準(zhǔn)則包括實際輸出結(jié)果與測試用例的預(yù)期輸出結(jié)果相同，程序所具有的功能與UML模型所具有的功能一致。

在上述技術(shù)方案的基礎(chǔ)上，所述測試用例主要包括三部分：測試場景、測試輸入數(shù)據(jù)和預(yù)期輸出序列，，測試用例的生成方法主要針對所述三部分相關(guān)信息的獲取。

在上述技術(shù)方案的基礎(chǔ)上，所述測試腳本為可以被自動化測試工具執(zhí)行的指令，所述測試腳本可以被創(chuàng)建，或使用測試自動化工具自動生成，或用編程語言編程來完成，或通過創(chuàng)建、用測試自動化工具自動生成及用編程語言編程共同完成。

在上述技術(shù)方案的基礎(chǔ)上，所述測試腳本包括以下功能：

a.驅(qū)動程序執(zhí)行，包括編譯程序執(zhí)行和運行程序執(zhí)行；

b.檢測程序的執(zhí)行過程；

c.向程序傳遞所需的輸入，并得到程序的執(zhí)行輸出。

本發(fā)明的有益效果在于：

1、本發(fā)明基于模型的軟件測試方法，使得基于UML的用例生成方法的流程更加規(guī)范，更加易于生成滿足高覆蓋要求的測試用例。

2.所述生成測試用例均是通過UML模型得到的，并且可以通過結(jié)合待測程序自動執(zhí)行測試，故而大大提高了測試的自動化水平。

3、在基于模型的軟件測試中，測試用例的生成僅僅依賴于UML模型，并不依賴于被測試的軟件，因此測試用例的生成可以在軟件開發(fā)完成前進(jìn)行。

4、系統(tǒng)的模型是根據(jù)系統(tǒng)功能需求構(gòu)建的，所以通過模型生成的測試用例可以直接覆蓋系統(tǒng)的需求，減少測試用例的冗余。

5、當(dāng)需求或者系統(tǒng)發(fā)生更改時，基于模型的軟件測試只需要根據(jù)改變后的模型重新生成測試用例，易于維護。

附圖說明

圖1為本發(fā)明實施例基于模型的軟件測試方法流程圖。

圖2為本發(fā)明步驟S4流程圖；

圖3為本發(fā)明步驟S5流程圖；

圖4為本發(fā)明步驟S6流程圖。

具體實施方式

以下結(jié)合附圖及實施例對本發(fā)明作進(jìn)一步詳細(xì)說明。

如圖1所示，本發(fā)明為一種基于模型的軟件測試方法，所述方法包括以下步驟：

S1：充分了解軟件需求規(guī)范和設(shè)計文檔、用戶手冊，了解被測系統(tǒng)，根據(jù)測試目標(biāo)確定被測組件及其功能特征。分析被測試軟件，根據(jù)測試目的，確定測試對象和測試特征；

S2：選擇和構(gòu)造UML模型，該UML模型表述了需求所表述的所有可能行為；通過軟件的系統(tǒng)特征和各個模型的特征，選擇并建立合適的模型作為測試用例生成的模型。

S3：模型驗證：

基于形式化方法與可視化UML相結(jié)合的建模思想，設(shè)計一套從UML模型到Promela模型的轉(zhuǎn)換規(guī)則，開發(fā)由UML模型自動生成Promela代碼的轉(zhuǎn)換工具。在轉(zhuǎn)換工具中通過調(diào)用SPIN自動驗證Promela代碼，來驗證UML模型，排查模型構(gòu)造時可能出現(xiàn)的問題，以確保UML模型正確性。

S4：測試用例自動生成：具體請參考圖2，測試用例主要包含了測試場景、測試輸入數(shù)據(jù)和預(yù)期輸出序列這三部分內(nèi)容，測試用例的生成主要針對自動獲取這三部分的相關(guān)信息。在生成測試用例時，我們首先需要將由步驟S2、S3得到的UML模型轉(zhuǎn)化為形式化模型，通過深度優(yōu)先搜索算法，得到所有的測試場景，再由測試人員根據(jù)軟件系統(tǒng)的需求在測試場景上添加輸入數(shù)據(jù)等所需的信息，完成測試用例的生成。

在生成測試用例的過程中，需要對于選擇和循環(huán)等進(jìn)行處理，找出形式化模型上所有的路徑，每條路徑即是一個測試場景。

S5：請參考圖3，測試用例自動執(zhí)行：測試用例的自動執(zhí)行是軟件測試自動化的關(guān)鍵步驟，以下為具體實施過程：

分析由S4得到的測試用例，若能從UML模型得到的測試用例中得到輸入數(shù)據(jù)和預(yù)期輸出，則采用由UML模型得到的測試數(shù)據(jù)，否則根據(jù)被測程序建立約束系統(tǒng)，然后通過隨機法、靜態(tài)法、動態(tài)法或者試探法，求解約束系統(tǒng)，得到測試數(shù)據(jù)。

為您推薦 專利分類

G 物理

G06 計算；推算；計數(shù)
G06F 電數(shù)字?jǐn)?shù)據(jù)處理
G06F11-00 錯誤檢測；錯誤校正；監(jiān)控
G06F11-07 .響應(yīng)錯誤的產(chǎn)生，例如，容錯
G06F11-22 .在準(zhǔn)備運算或者在空閑時間期間內(nèi)，通過測試作故障硬件的檢測或定位
G06F11-28 .借助于檢驗標(biāo)準(zhǔn)程序或通過處理作錯誤檢測、錯誤校正或監(jiān)控
G06F11-30 .監(jiān)控
G06F11-36 .通過軟件的測試或調(diào)試防止錯誤

 

本文編號：1174461