一種基于模型的軟件測試方法
【專利摘要】一種基于模型的軟件測試方法，包括如下步驟：S1.分析被測試軟件，確定測試對象和測試特征;S2.選擇和構(gòu)造UML模型；S3.對UML模型進行驗證，確保UML模型的正確性；S4.通過深度優(yōu)先搜索算法遍歷UML模型，自動生成測試用例，根據(jù)語句覆蓋準(zhǔn)則、判定覆蓋準(zhǔn)則、條件覆蓋準(zhǔn)則及路徑覆蓋準(zhǔn)則等充分性準(zhǔn)則計算相關(guān)的覆蓋率，完成對測試用例的評估；S5.根據(jù)待測程序和所述UML模型得到的測試用例生成測試腳本，自動執(zhí)行所述測試腳本，并保存執(zhí)行測試腳本得到的實際輸出結(jié)果；S6.根據(jù)測試用例的實際輸出與預(yù)期輸出的比較，得出測試結(jié)果，再根據(jù)測試目標(biāo)與預(yù)先設(shè)定好的停止準(zhǔn)則，決定是否需要修改模型或修改待測程序。
【專利說明】一種基于模型的軟件測試方法【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及測試【技術(shù)領(lǐng)域】，具體來講是一種基于模型的軟件測試方法。
【背景技術(shù)】
[0002]近幾年來，隨著計算機軟硬件技術(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è)計和生成有效的測試用例。
[0003]隨著面向?qū)ο筌浖_發(fā)技術(shù)的廣泛應(yīng)用和軟件測試自動化的要求，基于模型的軟件測試逐漸得到重視。目前，軟件測試技術(shù)大體上可分為兩大類:一類是白盒測試技術(shù)，另一類是黑盒測試技術(shù)。
[0004]白盒測試技術(shù)是把程序看成裝在一個白盒子里，即完全了解程序的內(nèi)部結(jié)構(gòu)和處理過程，按照程序內(nèi)部的邏輯結(jié)構(gòu)，檢驗程序中的每條通路是否都按照預(yù)定要求正確工作。白盒測試從考察程序的結(jié)構(gòu)和邏輯出發(fā)，驗證所構(gòu)造的程序是否符合設(shè)計要求，白盒測試包括邏輯覆蓋、域測試、符號測試、路徑分析、程序插樁及程序變異等。
[0005]白盒測試技術(shù)的缺點在于，白盒測試只根據(jù)程序的內(nèi)部結(jié)構(gòu)進行測試，而不考慮程序的外部特征，如果程序結(jié)構(gòu)本身有問題，比如程序邏輯有誤或是有紕漏，就無法發(fā)現(xiàn)錯誤。另外，即使將程序中的每條路徑都測試了仍然可能有錯誤，原因在于:第一，窮舉路徑測試不能查出程序違反了設(shè)計規(guī)范；第二，窮舉路徑測試不可能查出程序中因紕漏路徑而出現(xiàn)的錯誤；第三，窮舉路徑測試可能發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤。
[0006]黑盒測試技術(shù)，又稱為功能測試技術(shù)，與白盒測試技術(shù)恰恰相反，它把程序看成一個黑盒子，完全不用考慮程序的內(nèi)部結(jié)構(gòu)和處理過程。黑盒測試是在程序接口進行的測試，它只檢查程序功能是否按照預(yù)先的要求正常工作，即接收輸入數(shù)據(jù)是否產(chǎn)生正確的輸出結(jié)果。黑盒測試技術(shù)包括邊界值分析技術(shù)、等價分類技術(shù)及因果圖技術(shù)等。
[0007]黑盒測試技術(shù)的缺點在于，黑盒測試是一種窮舉輸入的測試方法，不僅要窮舉所有合法的輸入，還要窮舉那些不合法但是可能的輸入進行測試。但是根據(jù)軟件測試的局限性，不太可能完全覆蓋所有的輸入情況，測試代價太大。黑盒測試的研究重點在于如何從輸入域中選擇適當(dāng)數(shù)量的、對發(fā)現(xiàn)錯誤具有代表性的測試輸入來有效的進行測試。
[0008]白盒測試方法是從開發(fā)者的角度在源代碼級使用軟件分析和理解技術(shù)，對程序的內(nèi)部邏輯結(jié)構(gòu)進行分析來測試系統(tǒng)，而黑盒測試方法通過從用戶的角度測試軟件系統(tǒng)是否符合需求規(guī)格，這兩類方法各有側(cè)重，在測試的實踐中是互補的。但它們又各有缺點，并且不能在方法內(nèi)部進行完善來解決，而且在面向?qū)ο笳Z境下，軟件的設(shè)計思路和軟件的結(jié)構(gòu)，與傳統(tǒng)的面向過程的軟件相比有了很大的變化，而傳統(tǒng)的軟件測試方法不能適應(yīng)這樣的變化。
【發(fā)明內(nèi)容】

[0009]針對現(xiàn)有技術(shù)中存在的缺陷，本發(fā)明的目的在于提供一種基于模型的軟件測試方法，通過UML (unified modeling language,統(tǒng)一建模語言)模型圖自動生成滿足一定覆蓋準(zhǔn)則的測試用例，從而快速有效的完成軟件測試，適應(yīng)軟件的設(shè)計思路和軟件的結(jié)構(gòu)、與傳統(tǒng)的面向過程的軟件之間的變化，彌補白盒測試和黑盒測試的不足。
[0010]為達(dá)到以上目的，本發(fā)明采取的技術(shù)方案，一種基于模型的軟件測試方法，其特征在于，包括如下步驟:
[0011]S1.分析被測試軟件，根據(jù)測試目的，確定測試對象和測試特征；
[0012]S2.選擇和構(gòu)造UML模型，該UML模型表述了需求所表述的所有可能行為；
[0013]S3.對UML模型進行驗證，排查UML模型構(gòu)造時可能出現(xiàn)的有界性、安全性、死鎖和狀態(tài)可達(dá)性，確保UML模型的正確性；
[0014]S4.通過深度優(yōu)先搜索算法遍歷UML模型，自動生成測試用例，根據(jù)充分性準(zhǔn)則計算相關(guān)的覆蓋率，完成對測試用例的評估；
[0015]S5.根據(jù)待測程序和所述UML模型得到的測試用例生成測試腳本，自動執(zhí)行所述測試腳本，并保存執(zhí)行測試腳本得到的實際輸出結(jié)果；
[0016]S6.根據(jù)測試用例的實際輸出與預(yù)期輸出的比較，得出測試結(jié)果，再根據(jù)測試目標(biāo)與預(yù)先設(shè)定好的停止準(zhǔn)則，決定是否需要修改模型或修改待測程序。
[0017]在上述技術(shù)方案的基礎(chǔ)上，所述充分性準(zhǔn)則包括:
[0018]基于控制流的充分性準(zhǔn)則:語句覆蓋準(zhǔn)則、條件覆蓋準(zhǔn)則和判斷覆蓋準(zhǔn)則；
[0019]基于數(shù)據(jù)流的充分性準(zhǔn)則:定義引用覆蓋準(zhǔn)則、上下文覆蓋準(zhǔn)則；
[0020]基于故障的充分性準(zhǔn)則:弱變異覆蓋準(zhǔn)則、強變異覆蓋準(zhǔn)則。
[0021]在上述技術(shù)方案的基礎(chǔ)上，所述覆蓋率用來度量測試完整性和充分性，其包括:邏輯覆蓋、函數(shù)覆蓋以及功能覆蓋，其中邏輯覆蓋包括:語句覆蓋、判定覆蓋、條件覆蓋以及路徑覆蓋。
[0022]在上述技術(shù)方案的基礎(chǔ)上，所述SI中分析被測試軟件包括:被測試軟件是面向?qū)ο蟮拈_發(fā)技術(shù)或者是面向過程的開發(fā)技術(shù)、被測試軟件所采用的開發(fā)語言、被測試軟件開發(fā)的系統(tǒng)環(huán)境。
[0023]在上述技術(shù)方案的基礎(chǔ)上，所述UML模型為機器可讀的模型，用于對被測試軟件進行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)的文檔。
[0024]在上述技術(shù)方案的基礎(chǔ)上，所述S3中，對UML模型進行有界性、安全性、死鎖及狀態(tài)可達(dá)性驗證。
[0025]在上述技術(shù)方案的基礎(chǔ)上，所述停止準(zhǔn)則包括實際輸出結(jié)果與測試用例的預(yù)期輸出結(jié)果相同，程序所具有的功能與UML模型所具有的功能一致。
[0026]在上述技術(shù)方案的基礎(chǔ)上，所述測試用例主要包括三部分:測試場景、測試輸入數(shù)據(jù)和預(yù)期輸出序列，測試用例的生成方法主要針對所述三部分相關(guān)信息的獲取。
[0027]在上述技術(shù)方案的基礎(chǔ)上，所述測試腳本為可以被自動化測試工具執(zhí)行的指令，所述測試腳本可以被創(chuàng)建，或使用測試自動化工具自動生成，或用編程語言編程來完成，或通過創(chuàng)建、用測試自動化工具自動生成及用編程語言編程共同完成。[0028]在上述技術(shù)方案的基礎(chǔ)上，所述測試腳本包括以下功能:
[0029]a.驅(qū)動程序執(zhí)行，包括編譯程序執(zhí)行和運行程序執(zhí)行；
[0030]b.檢測程序的執(zhí)行過程；
[0031]c.向程序傳遞所需的輸入，并得到程序的執(zhí)行輸出。
[0032]本發(fā)明的有益效果在于:
[0033]1、本發(fā)明基于模型的軟件測試方法，使得基于UML的用例生成方法的流程更加規(guī)范，更加易于生成滿足高覆蓋要求的測試用例。
[0034]2.所述生成測試用例均是通過UML模型得到的，并且可以通過結(jié)合待測程序自動執(zhí)行測試，故而大大提高了測試的自動化水平。
[0035]3、在基于模型的軟件測試中，測試用例的生成僅僅依賴于UML模型，并不依賴于被測試的軟件，因此測試用例的生成可以在軟件開發(fā)完成前進行。
[0036]4、系統(tǒng)的模型是根據(jù)系統(tǒng)功能需求構(gòu)建的，所以通過模型生成的測試用例可以直接覆蓋系統(tǒng)的需求，減少測試用例的冗余。
[0037]5、當(dāng)需求或者系統(tǒng)發(fā)生更改時，基于模型的軟件測試只需要根據(jù)改變后的模型重新生成測試用例，易于維護。
【專利附圖】

【附圖說明】
[0038]圖1為本發(fā)明實施例基于模型的軟件測試方法流程圖。
[0039]圖2為本發(fā)明步驟S4流程圖；
[0040]圖3為本發(fā)明步驟S5流程圖；
[0041 ] 圖4為本發(fā)明步驟S6流程圖。
【具體實施方式】
[0042]以下結(jié)合附圖及實施例對本發(fā)明作進一步詳細(xì)說明。
[0043]如圖1所示，本發(fā)明為一種基于模型的軟件測試方法，所述方法包括以下步驟:
[0044]S1:充分了解軟件需求規(guī)范和設(shè)計文檔、用戶手冊，了解被測系統(tǒng)，根據(jù)測試目標(biāo)確定被測組件及其功能特征。分析被測試軟件，根據(jù)測試目的，確定測試對象和測試特征；
[0045]S2:選擇和構(gòu)造UML模型，該UML模型表述了需求所表述的所有可能行為；通過軟件的系統(tǒng)特征和各個模型的特征，選擇并建立合適的模型作為測試用例生成的模型。
[0046]S3:模型驗證:
[0047]基于形式化方法與可視化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模型正確性。
[0048]S4:測試用例自動生成:具體請參考圖2，測試用例主要包含了測試場景、測試輸入數(shù)據(jù)和預(yù)期輸出序列這三部分內(nèi)容，測試用例的生成主要針對自動獲取這三部分的相關(guān)信息。在生成測試用例時，我們首先需要將由步驟S2、S3得到的UML模型轉(zhuǎn)化為形式化模型，通過深度優(yōu)先搜索算法，得到所有的測試場景，再由測試人員根據(jù)軟件系統(tǒng)的需求在測試場景上添加輸入數(shù)據(jù)等所需的信息，完成測試用例的生成。[0049]在生成測試用例的過程中，需要對于選擇和循環(huán)等進行處理，找出形式化模型上所有的路徑，每條路徑即是一個測試場景。
[0050]S5:請參考圖3，測試用例自動執(zhí)行:測試用例的自動執(zhí)行是軟件測試自動化的關(guān)鍵步驟，以下為具體實施過程:
[0051]分析由S4得到的測試用例，若能從UML模型得到的測試用例中得到輸入數(shù)據(jù)和預(yù)期輸出，則采用由UML模型得到的測試數(shù)據(jù)，否則根據(jù)被測程序建立約束系統(tǒng)，然后通過隨機法、靜態(tài)法、動態(tài)法或者試探法，求解約束系統(tǒng)，得到測試數(shù)據(jù)。
[0052]測試腳本生成:根據(jù)軟件測試自動化系統(tǒng)的特點，編寫一個腳本生成工具。使用腳本生成工具，分析待測程序代碼，提取各模塊結(jié)構(gòu)信息，如類、函數(shù)(方法)、變量，提供簡單的選擇界面，便于用戶選擇測試模塊、輸入數(shù)據(jù)、期望結(jié)果等，由腳本生成工具生成測試腳本。
[0053]利用程序插樁技術(shù)，對待測程序進行插樁，以便在運行插樁后程序的過程中，提取插樁信息，獲得執(zhí)行的路徑信息和執(zhí)行結(jié)果信息，進而可以分析得到軟件的結(jié)構(gòu)。
[0054]執(zhí)行上述測試腳本，以驅(qū)動插樁后的待測程序執(zhí)行，獲得并且保存相關(guān)的執(zhí)行路徑信息和執(zhí)行結(jié)果信息。
[0055]所述測試腳本的任務(wù)主要是:
[0056]a)驅(qū)動程序執(zhí)行，包括編譯和運行；
[0057]b)檢測程序的執(zhí)行過程；
[0058]c)向程序傳遞所需的輸入，并得到程序的執(zhí)行輸出。
[0059]S6:請參考圖4，比較測試結(jié)果:將實際結(jié)果與預(yù)期結(jié)果相比較，若結(jié)果符合停止準(zhǔn)則，測試執(zhí)行結(jié)束；若結(jié)果不符合停止準(zhǔn)則，則檢查模型是否有問題。若模型存在問題，則修改模型；若模型沒有問題，則修改程序。所述停止準(zhǔn)則包括，實際輸出結(jié)果與測試用例的預(yù)期輸出結(jié)果相同，程序所具有的功能與UML模型所具有的功能一致。
[0060]本發(fā)明基于模型的軟件測試方法，使得基于UML的用例生成方法的流程更加規(guī)范，更加易于生成滿足高覆蓋要求的測試用例。生成測試用例均是通過UML模型得到的，并且可以通過結(jié)合待測程序自動執(zhí)行測試，故而大大提高了測試的自動化水平。在基于模型的軟件測試中，測試用例的生成僅僅依賴于UML模型，并不依賴于被測試的軟件，因此測試用例的生成可以在軟件開發(fā)完成前進行。系統(tǒng)的模型是根據(jù)系統(tǒng)功能需求構(gòu)建的，所以通過模型生成的測試用例可以直接覆蓋系統(tǒng)的需求，減少測試用例的冗余。當(dāng)需求或者系統(tǒng)發(fā)生更改時，基于模型的軟件測試只需要根據(jù)改變后的模型重新生成測試用例，易于維護。
[0061]本發(fā)明不局限于上述實施方式，對于本【技術(shù)領(lǐng)域】的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也視為本發(fā)明的保護范圍之內(nèi)。本說明書中未作詳細(xì)描述的內(nèi)容屬于本領(lǐng)域?qū)I(yè)技術(shù)人員公知的現(xiàn)有技術(shù)。
【權(quán)利要求】
1.一種基于模型的軟件測試方法，其特征在于，包括如下步驟: 51.分析被測試軟件，根據(jù)測試目的，確定測試對象和測試特征； 52.選擇和構(gòu)造UML模型，該UML模型表述了需求所表述的所有可能行為； 53.對UML模型進行驗證，排查UML模型構(gòu)造時可能出現(xiàn)的有界性、安全性、死鎖和狀態(tài)可達(dá)性，確保UML模型的正確性； 54.通過深度優(yōu)先搜索算法遍歷UML模型，自動生成測試用例，根據(jù)充分性準(zhǔn)則計算相關(guān)的覆蓋率，完成對測試用例的評估； 55.根據(jù)待測程序和所述UML模型得到的測試用例生成測試腳本，自動執(zhí)行所述測試腳本，并保存執(zhí)行測試腳本得到的實際輸出結(jié)果； 56.根據(jù)測試用例的實際輸出與預(yù)期輸出的比較，得出測試結(jié)果，再根據(jù)測試目標(biāo)與預(yù)先設(shè)定好的停止準(zhǔn)則，決定是否需要修改模型或修改待測程序。
2.如權(quán)利要求1所述的一種基于模型的軟件測試方法，其特征在于:所述充分性準(zhǔn)則包括: 基于控制流的充分性準(zhǔn)則:語句覆蓋準(zhǔn)則、條件覆蓋準(zhǔn)則和判斷覆蓋準(zhǔn)則； 基于數(shù)據(jù)流的充分性準(zhǔn)則:定義引用覆蓋準(zhǔn)則、上下文覆蓋準(zhǔn)則； 基于故障的充分性準(zhǔn)則:弱變異覆蓋準(zhǔn)則、強變異覆蓋準(zhǔn)則。
3.如權(quán)利要求1所述的一種基于模型的軟件測試方法，其特征在于:所述覆蓋率用來度量測試完整性和充分性，其包括`:邏輯覆蓋、函數(shù)覆蓋以及功能覆蓋，其中邏輯覆蓋包括:語句覆蓋、判定覆蓋、條件覆蓋以及路徑覆蓋。
4.如權(quán)利要求1所述的一種基于模型的軟件測試方法，其特征在于:所述SI中分析被測試軟件包括:被測試軟件是面向?qū)ο蟮拈_發(fā)技術(shù)或者是面向過程的開發(fā)技術(shù)、被測試軟件所采用的開發(fā)語言、被測試軟件開發(fā)的系統(tǒng)環(huán)境。
5.如權(quán)利要求1所述的一種基于模型的軟件測試方法，其特征在于:所述UML模型為機器可讀的模型，用于對被測試軟件進行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)的文檔。
6.如權(quán)利要求1所述的一種基于模型的軟件測試方法，其特征在于:所述S3中，對UML模型進行有界性、安全性、死鎖及狀態(tài)可達(dá)性驗證。
7.如權(quán)利要求1所述的一種基于模型的軟件測試方法，其特征在于:所述停止準(zhǔn)則包括實際輸出結(jié)果與測試用例的預(yù)期輸出結(jié)果相同，程序所具有的功能與UML模型所具有的功能一致。
8.如權(quán)利要求1所述的一種基于模型的軟件測試方法，其特征在于:所述測試用例主要包括三部分:測試場景、測試輸入數(shù)據(jù)和預(yù)期輸出序列，測試用例的生成方法主要針對所述三部分相關(guān)信息的獲取。
9.如權(quán)利要求1所述的一種基于模型的軟件測試方法，其特征在于:所述測試腳本為可以被自動化測試工具執(zhí)行的指令，所述測試腳本可以被創(chuàng)建，或使用測試自動化工具自動生成，或用編程語言編程來完成，或通過創(chuàng)建、用測試自動化工具自動生成及用編程語言編程共同完成。
10.如權(quán)利要求9所述的一種基于模型的軟件測試方法，其特征在于:所述測試腳本包括以下功能: a.驅(qū)動程序執(zhí)行，包括編譯程序執(zhí)行和運行程序執(zhí)行；b.檢測程序的執(zhí)行過程；c.向程序傳遞所需的 輸入，并得到程序的執(zhí)行輸出。
【文檔編號】G06F11/36GK103530228SQ201310455252
【公開日】2014年1月22日 申請日期:2013年9月27日 優(yōu)先權(quán)日:2013年9月27日
【發(fā)明者】段振華, 苗俊磊, 張南, 田聰, 王小兵, 羅玲 申請人:西安電子科技大學(xué)