測試用例自動生成方法和裝置的制造方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及軟件測試技術(shù)領(lǐng)域，特別是涉及一種測試用例自動生成方法和裝置。
【背景技術(shù)】
[0002]設(shè)計測試用例，是整個軟件測試工作的最核心部分。目前絕大多數(shù)的測試設(shè)計方法，都屬于測試設(shè)計“技巧”，如:等價類劃分、邊界值、因果圖等，都是在具體設(shè)計測試數(shù)據(jù)時候來考慮如何根據(jù)測試數(shù)據(jù)的不同來設(shè)計測試用例?；谶@些具體測試技巧，對整體測試用例設(shè)計水平的提升和幫助并不是很大。
[0003]基于前述所列方法，真正影響測試用例質(zhì)量的是測試設(shè)計人員對被測試系統(tǒng)需求的理解及業(yè)務(wù)層面的理解。目前，還沒有一種能夠通過標準化的輸入和處理來生成測試用例的方法，為此，本領(lǐng)域技術(shù)人員希望通過提供一種能夠自動生成測試用例的方法，以提高現(xiàn)有測試階段的測試效率。

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

[0004]鑒于以上所述現(xiàn)有技術(shù)的缺點，本發(fā)明的目的在于提供一種測試用例自動生成方法和裝置，用于解決現(xiàn)有生成測試用例質(zhì)量不穩(wěn)定以及測試效率不高的問題。
[0005]為實現(xiàn)上述目的及其他相關(guān)目的，本發(fā)明提供以下技術(shù)方案:
[0006]一種測試用例自動生成方法，所述方法包括以下步驟:對輸入的需求定義測試項，得到測試需求；對所述測試需求進行路徑掃描，對應(yīng)得到若干測試場景；依據(jù)所述測試場景生成對應(yīng)的測試數(shù)據(jù)，并將所述測試數(shù)據(jù)添加至與其對應(yīng)的所述測試場景中形成測試用例，并輸出所有所述測試用例。
[0007]優(yōu)選地，輸入的所述需求包括對所述需求采用UML形式來進行形式化表達得到的活動圖。
[0008]優(yōu)選地，所述對輸入的需求定義測試項的方法包括:定義需求內(nèi)容中需要進行測試的測試項；依據(jù)定義的所述測試項進行分析，判斷是否需要增加需求項:若是，則對所述需求對應(yīng)的活動圖增加檢測點，并轉(zhuǎn)化為測試活動圖后予以輸出；若否，則輸出測試活動圖。
[0009]優(yōu)選地，所述對需求對應(yīng)的活動圖增加檢測點的方法包括:增加查詢，并根據(jù)所述查詢的結(jié)果進行校驗，對應(yīng)得到增加檢測功能的所述檢測點。
[0010]優(yōu)選地，所述測試需求包括測試活動圖。
[0011]另外，本發(fā)明還提供了一種測試用例自動生成裝置，所述裝置包括:需求輸入模塊，適于輸入需求；測試需求生成模塊，適于對輸入的所述需求定義測試項，得到測試需求；測試場景生成模塊，適于對所述測試需求進行路徑掃描，對應(yīng)得到若干測試場景；測試用例生成模塊，適于依據(jù)所述測試場景生成對應(yīng)的測試數(shù)據(jù)，并將所述測試數(shù)據(jù)添加至與其對應(yīng)的測試場景中形成測試用例，并輸出所有所述測試用例。
[0012]優(yōu)選地，輸入的所述需求包括對所述需求采用UML形式來進行形式化表達得到的活動圖。
[0013]優(yōu)選地，適于對輸入的需求定義測試項的所述測試需求生成模塊還包括:測試項定義單元，定義需求內(nèi)容中需要進行測試的測試項；需求分析檢查單元，依據(jù)定義的所述測試項進行分析，判斷是否需要增加需求項:若是，則對所述需求對應(yīng)的活動圖增加檢測點，并轉(zhuǎn)化為測試活動圖后予以輸出；若否，則輸出測試活動圖。
[0014]優(yōu)選地，還包括用于對所述需求對應(yīng)的活動圖增加檢測點的需求增加檢查單元，適于增加查詢，并根據(jù)所述查詢的結(jié)果進行校驗，對應(yīng)得到增加檢測功能的所述檢測點。
[0015]優(yōu)選地，所述測試需求包括測試活動圖。
[0016]如上所述，本發(fā)明至少具有以下有益效果:本發(fā)明通過建立一套設(shè)計測試用例的流程，通過標準化的輸入、標準化的處理，生成更可靠的測試用例，提高了測試效率。
【附圖說明】
[0017]圖1顯示為測試用例自動生成方法在一實施方式中的實現(xiàn)流程圖；
[0018]圖2顯示為將需求轉(zhuǎn)換為測試需求方法在一實施方式中的實現(xiàn)流程圖；
[0019]圖3顯示為測試用例自動生成裝置在一實施方式中的原理圖；
[0020]圖4顯示為測試需求生成模塊的一種實施原理圖。
[0021]元件標號說明
[0022]300裝置
[0023]310需求輸入模塊
[0024]320測試需求生成模塊
[0025]321測試項定義單元
[0026]322需求分析檢查單元
[0027]323需求增加檢查單元
[0028]330測試場景生成模塊
[0029]340測試用例生成模塊
[0030]S101 ?S105 步驟
[0031]S201 ?S303 步驟
【具體實施方式】
[0032]以下通過特定的具體實例說明本發(fā)明的實施方式，本領(lǐng)域技術(shù)人員可由本說明書所揭露的內(nèi)容輕易地了解本發(fā)明的其他優(yōu)點與功效。本發(fā)明還可以通過另外不同的【具體實施方式】加以實施或應(yīng)用，本說明書中的各項細節(jié)也可以基于不同觀點與應(yīng)用，在沒有背離本發(fā)明的精神下進行各種修飾或改變。需說明的是，在不沖突的情況下，以下實施例及實施例中的特征可以相互組合。
[0033]需要說明的是，以下實施例中所提供的圖示僅以示意方式說明本發(fā)明的基本構(gòu)想，遂圖式中僅顯示與本發(fā)明中有關(guān)的組件而非按照實際實施時的組件數(shù)目、形狀及尺寸繪制，其實際實施時各組件的型態(tài)、數(shù)量及比例可為一種隨意的改變，且其組件布局型態(tài)也可能更為復(fù)雜。
[0034]實施例1
[0035]請參閱圖1，為一種測試用例自動生成方法在一實施方式中的實現(xiàn)流程圖，如圖所示，以下將對該方法所涉及的步驟進行詳細地說明。
[0036]步驟S101，對輸入的需求定義測試項，得到測試需求。
[0037]在具體實施中，進行功能測試的時候，輸入是需求。如果需要進行模型驅(qū)動，則需要對需求進行約束，也就是我們需要對需求進行形式化。需求的形式化是便于轉(zhuǎn)換為測試需求。
[0038]具體地，需求的形式化，就是需要對需求的表述，可以包括從自然語言轉(zhuǎn)換成為UML的形式。在測試中，主要采用UML的usecase圖和活動圖來表述。
[0039]此外，在對需求進行形式化以后，需要在輸入需求的時候，導(dǎo)入對應(yīng)的活動圖，否則就需要測試需求分析做更多的工作，由人為地來解決沒有必要需求，以及由人為來表述的問題。這樣會導(dǎo)致理解的偏差和測試的不足。簡單地來說，輸入的所述需求可以包括對所述需求采用UML形式來進行形式化表達得到的活動圖。
[0040]在具體實施中，將需求轉(zhuǎn)換為測試需求的具體方法可以參考圖2，為將需求轉(zhuǎn)換為測試需求方法在一實施方式中的實現(xiàn)流程圖，如圖所示，所述方法可以包括以下步驟:
[0041]步驟S201，定義需求內(nèi)容中需要進行測試的測試項；
[0042]步驟S203，依據(jù)定義的所述測試項進行分析，判斷是否需要增加需求項:
[0043]步驟S203-1，若是，則對所述需求對應(yīng)的活動圖增加檢測點，進入步驟S203-2 ；
[0044]步驟S203-2，若否，則將活動圖轉(zhuǎn)化為測試活動圖，并