羊鈴霞,陳元松,仵林博,尚小虎,陳立偉

(1.西南科技大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，四川 綿陽 621010;2.中國工程物理研究院 計(jì)算機(jī)應(yīng)用研究所，四川 綿陽 621999)

0 引言

近年來，在計(jì)算機(jī)技術(shù)和互聯(lián)網(wǎng)技術(shù)飛快發(fā)展之下，B/S架構(gòu)的Web應(yīng)用因其操作簡單、快速、無需安裝等特點(diǎn)，占據(jù)了軟件市場的大量份額。隨著Web應(yīng)用的快速發(fā)展，Web應(yīng)用的架構(gòu)層次越來越復(fù)雜、質(zhì)量要求越來越高、測試難度也越來越大。Web應(yīng)用在測試過程中需要花費(fèi)大量的時(shí)間編寫測試用例，執(zhí)行測試用例，并且在新版本發(fā)布時(shí)，回歸測試也將花費(fèi)大量的物力人力，在這樣的形式下，需要一個(gè)可以提高測試效率、減少人力物力的Web應(yīng)用自動(dòng)化測試平臺(tái)。

目前，國內(nèi)外有許多針對(duì)基于模型的測試用例自動(dòng)生成和自動(dòng)化測試執(zhí)行的研究，文獻(xiàn)[1]提出了一個(gè)基于模型的測試平臺(tái)，稱為ModCon，依賴于用戶指定的模型來定義測試預(yù)言，指導(dǎo)測試生成和度量測試充足率，主要用于支持無權(quán)限和有權(quán)限的區(qū)塊鏈平臺(tái)。文獻(xiàn)[2]引入了一種新的基于模型的測試方法，根據(jù)需求和故障模式對(duì)測試用例進(jìn)行排序，在基于模型的測試方法中使用了失敗模式和效果分析方法，自動(dòng)生成一組成對(duì)的測試用例，利用優(yōu)先級(jí)編號(hào)來排序測試用例。文獻(xiàn)[3]引入了一種新的基于模型的IFML UI元素測試方法，使用形式化模型提供完整的導(dǎo)航測試，通過生成狀態(tài)轉(zhuǎn)換矩陣和詳細(xì)的UI測試用例文檔，將IFML模型轉(zhuǎn)換為必要的UI測試工件，實(shí)現(xiàn)了基于模型的用戶界面測試用例(MBUITC)生成器工具。文獻(xiàn)[4]研究活動(dòng)圖的建立規(guī)則，對(duì)循環(huán)結(jié)構(gòu)和并發(fā)結(jié)構(gòu)處理，提出了UML活動(dòng)圖和遺傳算法相結(jié)合的測試用例生成方法。文獻(xiàn)[5]提出了一種基序列圖和狀態(tài)圖關(guān)聯(lián)關(guān)系生成測試用例的方法，該方法有效發(fā)現(xiàn)軟件在處理多對(duì)象交互情景下的缺陷。文獻(xiàn)[6]針對(duì)目前Web測試費(fèi)時(shí)費(fèi)力，提出了一種基于WSDL文檔和形式化模型樹Web服務(wù)操作測試用例的自動(dòng)生成方法。文獻(xiàn)[7]針對(duì)Web應(yīng)用需求頻繁更改問題，研究了基于低耦合的Web自動(dòng)化測試框架，實(shí)現(xiàn)數(shù)據(jù)模塊、業(yè)務(wù)邏輯和結(jié)果顯示模塊相分離。文獻(xiàn)[8]針對(duì)回歸測試占用大量測試人力資源的現(xiàn)象，設(shè)計(jì)并實(shí)現(xiàn)了一種基于Selenium與Unittest的Web自動(dòng)化測試框架。

在上述自動(dòng)化測試技術(shù)研究中，大多數(shù)工具只針對(duì)某個(gè)方面的研究，如只關(guān)注測試用例自動(dòng)生成或自動(dòng)化的測試執(zhí)行，很少從測試需求分析、測試用例設(shè)計(jì)生成、測試用例執(zhí)行、測試報(bào)告生成等軟件測試的全流程給出研究方案，并且現(xiàn)在的工具沒有真正意義上的能夠普適各種Web應(yīng)用和全自動(dòng)化的結(jié)論性成果。本文針對(duì)軟件測試整體流程，設(shè)計(jì)了一套高適應(yīng)性的模型驅(qū)動(dòng)的Web應(yīng)用自動(dòng)化測試平臺(tái)，該平臺(tái)實(shí)現(xiàn)了測試用例自動(dòng)設(shè)計(jì)、測試腳本自動(dòng)生成、自動(dòng)化的測試執(zhí)行以及測試報(bào)告的生成，在保證Web應(yīng)用軟件質(zhì)量的同時(shí)，顯著提高了測試效率和測試覆蓋率。

1 自動(dòng)化測試平臺(tái)概述

該自動(dòng)化測試平臺(tái)主要包括被測系統(tǒng)建模、測試策略制定，測試用例生成，測試執(zhí)行等功能。該平臺(tái)是一個(gè)以UML模型為基礎(chǔ)的自動(dòng)化測試的Web平臺(tái)，其中用戶需求、測試策略以及測試用例均用UML模型進(jìn)行表示，整個(gè)測試過程都依賴UML模型。

1.1 自動(dòng)化測試工作流程

模型驅(qū)動(dòng)的自動(dòng)化測試是先使用UML狀態(tài)圖模型形式化地描述將要被測試的Web應(yīng)用的業(yè)務(wù)流程，再利用UML狀態(tài)圖模型的狀態(tài)和遷移動(dòng)作信息來自動(dòng)產(chǎn)生測試用例和測試腳本，然后，通過自動(dòng)執(zhí)行系統(tǒng)執(zhí)行生成的測試用例和測試腳本，最后，根據(jù)測試執(zhí)行結(jié)果生成最終的測試報(bào)告。模型驅(qū)動(dòng)的自動(dòng)化測試組成、工作過程如圖1所示。

圖1 模型驅(qū)動(dòng)的自動(dòng)化測試工作過程

1.2 自動(dòng)化測試平臺(tái)構(gòu)成

本文所述自動(dòng)化測試平臺(tái)主要由服務(wù)器端和客戶端組成，其中主要的應(yīng)用功能模塊可分為3個(gè)組成部分。

1.2.1 測試模型

測試設(shè)計(jì)人員通過需求分析，利用UML用例圖建立被測軟件的需求模型，清晰表達(dá)用戶的測試需求和測試重點(diǎn)，確定大致的測試策略和測試路徑；采用基于UML狀態(tài)圖的建模方式來對(duì)被測應(yīng)用的業(yè)務(wù)邏輯行為進(jìn)行抽象的描述，幫助梳理被測試應(yīng)用的業(yè)務(wù)邏輯，表達(dá)出被測對(duì)象的操作動(dòng)作和狀態(tài)，并為其綁定關(guān)鍵字；采用“業(yè)務(wù)模型+數(shù)據(jù)驅(qū)動(dòng)”的模式對(duì)特定場景中輸入數(shù)據(jù)和操作數(shù)據(jù)根據(jù)一些測試方法(如等價(jià)類劃分、邊界值等)編寫測試數(shù)據(jù)進(jìn)行建模，再根據(jù)模型生成不同組的測試數(shù)據(jù)；最后在對(duì)應(yīng)的模型中配置一組或幾組測試數(shù)據(jù)以及一些約束條件，完成整個(gè)被測應(yīng)用的業(yè)務(wù)行為模型。

根據(jù)上述，模型驅(qū)動(dòng)的自動(dòng)化測試平臺(tái)中的模型一般而言分為3種：用例模型，數(shù)據(jù)模型，行為模型。其中，數(shù)據(jù)模型和行為模型又被統(tǒng)稱為狀態(tài)圖模型。

用例模型：用于對(duì)用戶需求(如界面遷移圖，測試策略，用例說明，原型系統(tǒng)等)的表述。建立該模型主要為了：清晰直觀地捕捉用戶需求；迅速暴露測試計(jì)劃制定時(shí)可能的缺漏點(diǎn)；建立從需求到結(jié)果的雙向可追溯鏈條，使測試活動(dòng)呈現(xiàn)得更加明確；使得測試結(jié)果覆蓋的內(nèi)容能夠直觀的與需求聯(lián)系在一起。

狀態(tài)圖模型：主要用于對(duì)被測對(duì)象的期待的行為進(jìn)行描述。數(shù)據(jù)模型和行為模型分別描述了被測對(duì)象在被期待的行為進(jìn)行中所需的數(shù)據(jù)和動(dòng)作或狀態(tài)。利用該模型，能夠直接表述出期望的被測對(duì)象的動(dòng)作及狀態(tài)；填入測試腳本，使得動(dòng)作、狀態(tài)與行為能夠?qū)?yīng)；可以自動(dòng)生成測試用例，替代了人工的測試用例設(shè)計(jì)和編寫，提高了工作效率。

1.2.2 測試用例及測試腳本

測試用例及測試腳本是通過基于模型的分析方法自動(dòng)生成的，主要根據(jù)基于狀態(tài)圖在狀態(tài)和遷移的拓?fù)鋱D中枚舉出所有的測試路徑，綜合列舉出所有可能的操作與對(duì)應(yīng)操作數(shù)據(jù)參數(shù)，并對(duì)數(shù)據(jù)參數(shù)取值進(jìn)行組合產(chǎn)生測試用例。同時(shí)，為了生成自動(dòng)化測試執(zhí)行的測試腳本，需要編寫相應(yīng)被測系統(tǒng)的操作關(guān)鍵字實(shí)現(xiàn)業(yè)務(wù)邏輯封裝，即將人對(duì)被測應(yīng)用行為的操作、對(duì)界面元素的操作、輸入輸出操作，通過編寫操作關(guān)鍵字的形式進(jìn)行封裝。通過為UML狀態(tài)圖中各個(gè)遷移動(dòng)作和狀態(tài)全部綁定編寫的關(guān)鍵字，再結(jié)合枚舉出的測試路徑就可以生成可執(zhí)行的測試腳本。最后，調(diào)用自動(dòng)化測試執(zhí)行系統(tǒng)進(jìn)行執(zhí)行，即平臺(tái)生成的用例就可以利用測試腳本實(shí)現(xiàn)全部自動(dòng)化運(yùn)行。

1.2.3 自動(dòng)化測試執(zhí)行系統(tǒng)

自動(dòng)化測試執(zhí)行系統(tǒng)ATE(auto test executing)，該部分是對(duì)各個(gè)應(yīng)用領(lǐng)域的底層封裝，主要是利用關(guān)鍵字驅(qū)動(dòng)的思想對(duì)Selenium的二次開發(fā)再封裝，例如，把Selenium對(duì)瀏覽器驅(qū)動(dòng)和對(duì)Web應(yīng)用元素定位、操作原本的方法通過編寫Python腳本設(shè)計(jì)關(guān)鍵字的形式進(jìn)行封裝。利用二次封裝增加了測試腳本的可復(fù)用性，降低了測試腳本的編寫難度。最重要的是可以解析生成的測試腳本使得被測系統(tǒng)像被人工操作一樣的自動(dòng)運(yùn)行，該平臺(tái)生成的測試用例就可以調(diào)用ATE進(jìn)行7×24小時(shí)全自動(dòng)運(yùn)行，顯著地提高了測試效率。

2 自動(dòng)化測試平臺(tái)設(shè)計(jì)

模型驅(qū)動(dòng)的Web應(yīng)用自動(dòng)化測試特點(diǎn)是根據(jù)被測系統(tǒng)模型及其派生模型來產(chǎn)生測試用例和測試腳本，進(jìn)行測試自動(dòng)執(zhí)行，以及測試結(jié)果展示。在基于模型的測試中，被測應(yīng)用的測試模型和基于測試模型生成的測試用例是抽象的，并且是獨(dú)立于平臺(tái)，可重復(fù)使用的。測試執(zhí)行時(shí)通過對(duì)測試執(zhí)行平臺(tái)的動(dòng)態(tài)配置自動(dòng)產(chǎn)生實(shí)例化的可執(zhí)行的測試腳本。本平臺(tái)是將測試模型、測試用例平臺(tái)和自動(dòng)化測試執(zhí)行平臺(tái)分離實(shí)現(xiàn)，通過適配器模塊連接模型工具和執(zhí)行平臺(tái)，降低Web應(yīng)用的異構(gòu)性和動(dòng)態(tài)性所帶來的測試復(fù)雜性。因此，模型驅(qū)動(dòng)的自動(dòng)化測試主要用到的技術(shù)就是基于UML模型的測試用例生成、基于關(guān)鍵字驅(qū)動(dòng)思想的框架設(shè)計(jì)和復(fù)雜多層的自動(dòng)化測試框架。

2.1 基于UML模型的測試用例生成

基于UML模型的測試用例生成主要是按照被測系統(tǒng)的業(yè)務(wù)流程和需求規(guī)格說明對(duì)整個(gè)被測系統(tǒng)進(jìn)行UML狀態(tài)建模，然后根據(jù)建立的狀態(tài)圖的狀態(tài)和遷移將其轉(zhuǎn)化為有向圖，最后通過測試路徑生成方法、測試覆蓋生成策略結(jié)合一些測試數(shù)據(jù)得到相應(yīng)的測試用例集。測試用例生成基本流程如圖 2所示。

圖2 測試用例生成流程圖

2.1.1 測試路徑生成方法

測試模型本身是通過“圖”(拓?fù)鋱D)的實(shí)例體現(xiàn)，測試用例生成算法則可以基于圖論的各種經(jīng)典算法來達(dá)成對(duì)圖中各種路徑的枚舉，簡單的枚舉將可能造成測試用例數(shù)量爆炸和測試用例數(shù)量過少兩種極端的結(jié)果，為防止造成這樣的結(jié)果，將基于風(fēng)險(xiǎn)的測試方法融入到了測試用例生成算法之中。測試用例生成算法不僅僅在圖中枚舉路徑，而且是根據(jù)圖中的優(yōu)先級(jí)(與軟件需求的關(guān)系密切程度)來優(yōu)先生成排序。將風(fēng)險(xiǎn)高的，更為基礎(chǔ)的測試用例排列在生成的測試用例集合前面，而把風(fēng)險(xiǎn)相對(duì)較低的排列在稍后的位置上，從而在測試覆蓋和資源消耗之間找到一個(gè)平衡。本平臺(tái)使用了深度優(yōu)先遍歷算法對(duì)行為模型轉(zhuǎn)換的有向圖進(jìn)行枚舉遍歷得到所有的測試路徑以及使用軟件產(chǎn)品風(fēng)險(xiǎn)與生成算法優(yōu)先級(jí)對(duì)測試路徑進(jìn)行排序選擇。

1)基于深度優(yōu)先遍歷的測試路徑生成。

測試路徑生成采用深度優(yōu)先遍歷算法獲取有向圖開始點(diǎn)和結(jié)束點(diǎn)兩個(gè)之間的所有路徑。有向圖中各個(gè)邊通過鄰接矩陣方式進(jìn)行存儲(chǔ)。

基于深度優(yōu)先遍歷的測試路徑生成算法:

輸入：一個(gè)有向圖邊的鄰接矩陣matrix和點(diǎn)集合vertex;

輸出：路徑集合

P

={

P

(

v

,…,

v

),

P

,…,

P

};

//使用深度優(yōu)先遍歷找到所有路徑;

初始化P={}；//定義集合為空;

Function countPathNumber(){}; //計(jì)算路徑分支數(shù);

Function getPaths(){;

For i -> countPathNumber():

path = {} ; //用于保存遍歷過的點(diǎn);

DFS(0,path); //調(diào)用深度優(yōu)先遍歷算法;

P.add(path); //將遍歷過的路徑保存到路徑集合;

End for;

}

//返回所有的路徑集合

Return P

End function

2)軟件產(chǎn)品風(fēng)險(xiǎn)與生成算法優(yōu)先級(jí)概要。

產(chǎn)品風(fēng)險(xiǎn)對(duì)應(yīng)的名詞解釋如下。

Trunk：直接反映需求對(duì)應(yīng)的軟件行為的狀態(tài)節(jié)點(diǎn)。

Relation：與需求產(chǎn)生關(guān)聯(lián)的軟件行為的狀態(tài)節(jié)點(diǎn)。

Normal：系統(tǒng)中與對(duì)應(yīng)需求相關(guān)性低或無已知聯(lián)系的狀態(tài)節(jié)點(diǎn)。

從基于風(fēng)險(xiǎn)的測試策略角度來看，trunk對(duì)應(yīng)的是功能是否正常工作的直接風(fēng)險(xiǎn)；relation對(duì)應(yīng)的是功能穩(wěn)定性，互操作性相關(guān)質(zhì)量屬性的風(fēng)險(xiǎn)；normal對(duì)應(yīng)的是功能可能相關(guān)的低級(jí)風(fēng)險(xiǎn)。

軟件產(chǎn)品或者系統(tǒng)中，與功能需求直接對(duì)應(yīng)的軟件行為對(duì)應(yīng)了最高優(yōu)先級(jí)的風(fēng)險(xiǎn)，因?yàn)槿绻竟δ芏紵o法運(yùn)轉(zhuǎn)，則軟件產(chǎn)品完全失去了價(jià)值；功能的穩(wěn)定性，性能，在復(fù)雜場景下的互操作性等質(zhì)量屬性則是在滿足基本功能行為的基礎(chǔ)上，更高的質(zhì)量要求，即這些要求對(duì)應(yīng)的軟件行為和處理的風(fēng)險(xiǎn)相對(duì)于基本功能而言比較低一些；非功能需求對(duì)應(yīng)的軟件行為處于更低的風(fēng)險(xiǎn)級(jí)別。因此，根據(jù)上述可以人為的設(shè)置各種定量的風(fēng)險(xiǎn)級(jí)別計(jì)算，這里采用3級(jí)基本風(fēng)險(xiǎn):Trunk(主干)，Relation(關(guān)聯(lián))，Normal(普通)，并由這3種基本風(fēng)險(xiǎn)級(jí)別的組合來體現(xiàn)更多更豐富的產(chǎn)品風(fēng)險(xiǎn)級(jí)別。

由于模型圖中的任意節(jié)點(diǎn)都可以根據(jù)實(shí)際系統(tǒng)的情況標(biāo)記為“Trunk”，“Relation”，“Normal”的任意一種，故此，在模型圖中生成的測試用例所對(duì)應(yīng)的拓?fù)鋱D中路徑所包含的節(jié)點(diǎn)序列可以是多種節(jié)點(diǎn)集合的情況，比如：{起始節(jié)點(diǎn)，Normal節(jié)點(diǎn)集合一，Trunk節(jié)點(diǎn)集合一，Normal節(jié)點(diǎn)集合二，Relation節(jié)點(diǎn)集合一，Trunk節(jié)點(diǎn)集合二，結(jié)束節(jié)點(diǎn)}。所以，采用“模式”的方法來描述測試用例生算法將符合什么樣的模式。上例中的模式可以總結(jié)為：Start，Normal，Trunk，Normal，Relation，Trunk，End。如果在生成算法中僅關(guān)注關(guān)鍵模式，而忽略次要模式，則上例可歸納為：

Start->Trunk->Relation->Trunk->End

圖3 關(guān)鍵字驅(qū)動(dòng)架構(gòu)

上述模式中，我們忽略了序列中的Normal節(jié)點(diǎn)集合。原因是，在實(shí)際的優(yōu)先級(jí)設(shè)置時(shí)，與某個(gè)需求關(guān)聯(lián)的節(jié)點(diǎn)可能與拓?fù)鋱D中的起始節(jié)點(diǎn)不相鄰。故此，在生成時(shí)，將集中按模式關(guān)注點(diǎn)生成子路徑集合，然后再在起始節(jié)點(diǎn)與子路徑的第一個(gè)節(jié)點(diǎn)之間尋找一條最短路，以及在子路徑的結(jié)束節(jié)點(diǎn)到拓?fù)鋱D的終點(diǎn)節(jié)點(diǎn)之間尋找一條最短路徑。這樣可能會(huì)造成一種情況:即在起始節(jié)點(diǎn)到子路徑以及子路徑到終點(diǎn)節(jié)點(diǎn)之間的路徑中可能包含Trunk，Relation，Normal等各種可能的優(yōu)先級(jí)，實(shí)際上“->”這個(gè)符號(hào)將代表任意在模式中不關(guān)注的路徑內(nèi)容,其內(nèi)容在算法中不予關(guān)注，故此其可能重復(fù)。

綜上，將生成的測試路徑集合結(jié)合基于風(fēng)險(xiǎn)的測試方法就可以得到合適數(shù)量的測試路徑集合。

2.1.2 測試覆蓋生成策略

測試用例的自動(dòng)生成需要按照需求制定相應(yīng)的測試覆蓋生成策略，自動(dòng)生成滿足測試需求的測試用例集，其中基于UML狀態(tài)圖模型的測試用例生成的核心就是測試覆蓋生成策略的制定，本平臺(tái)主要用到兩個(gè)測試覆蓋生成策略：狀態(tài)全覆蓋生成策略和主輔功能優(yōu)先覆蓋生成策略。

圖4 測試框架圖

狀態(tài)全覆蓋生成策略本質(zhì)上是對(duì)UML狀態(tài)圖所建立的被測系統(tǒng)業(yè)務(wù)模型生成的所有測試場景，達(dá)到最全面的覆蓋。在此覆蓋下，將獲取到所有符合參數(shù)定義規(guī)約的測試路徑，因此，在這種測試覆蓋生成策略下，將產(chǎn)生非常龐大的測試用例集合。這種策略適用于早期初次的測試來確保滿足覆蓋。

主輔功能優(yōu)先覆蓋生成策略本質(zhì)上是UML狀態(tài)圖所建立的被測系統(tǒng)業(yè)務(wù)模型生成的滿足需求的測試場景，達(dá)到主要功能和場景的覆蓋。在此覆蓋下，將獲取到與需求有明確對(duì)應(yīng)關(guān)系的路徑和已知可能與需求發(fā)生交互影響的路徑和測試場景，最后再添加上影響不大或影響未知的行為路徑。這種策略適用于按照一定需求來測試主要功能與場景的測試。

同時(shí)，為了控制測試用例集的數(shù)量，該平臺(tái)還配置了最大測試用例數(shù)，狀態(tài)圖環(huán)大小，環(huán)次數(shù)以及用例的最大步長等參數(shù)來限制測試用例的數(shù)量。

2.2 基于關(guān)鍵字驅(qū)動(dòng)思想的框架設(shè)計(jì)

關(guān)鍵字驅(qū)動(dòng)是將業(yè)務(wù)邏輯、數(shù)據(jù)和腳本分離，提高代碼的可重用性，提高腳本的可維護(hù)性的思想。關(guān)鍵字驅(qū)動(dòng)測試的核心就是對(duì)關(guān)鍵字進(jìn)行設(shè)計(jì)與封裝，傳統(tǒng)的關(guān)鍵字封裝就是對(duì)瀏覽器的操作、被測對(duì)象、定位方式和值等情況進(jìn)行封裝，再結(jié)合單元測試框架Unittest和Pytest搭建相應(yīng)的測試框架。

本文針對(duì)被測應(yīng)用的常用操作和建立的UML狀態(tài)模型的業(yè)務(wù)流程，將關(guān)鍵字的思想應(yīng)用于平臺(tái)中，主要是對(duì)Web應(yīng)用的常用操作和根據(jù)被測應(yīng)用建立UML狀態(tài)模型的遷移和狀態(tài)，利用關(guān)鍵字思想設(shè)計(jì)了相應(yīng)的瀏覽器驅(qū)動(dòng)關(guān)鍵字、數(shù)據(jù)獲取關(guān)鍵字、斷言關(guān)鍵字和業(yè)務(wù)流程關(guān)鍵字等。同時(shí)，將設(shè)計(jì)的業(yè)務(wù)流程關(guān)鍵字綁定在狀態(tài)模型圖的狀態(tài)和遷移上，通過UML狀態(tài)模型圖和綁定的關(guān)鍵字就可以自動(dòng)生成關(guān)鍵字的測試腳本。最后，根據(jù)生成的測試腳本驅(qū)動(dòng)被測應(yīng)用進(jìn)行相應(yīng)的操作，實(shí)現(xiàn)被測應(yīng)用的自動(dòng)化測試。關(guān)鍵字驅(qū)動(dòng)框架如圖3所示。

2.3 復(fù)雜多層的自動(dòng)化測試框架

分層測試框架有助于測試設(shè)計(jì)和測試開發(fā)解耦，提高一些模塊的復(fù)用性以及測試的覆蓋率。本平臺(tái)是基于Selenium的Web應(yīng)用自動(dòng)化測試的擴(kuò)展與改進(jìn)框架，主要分為客戶端和服務(wù)器端，并從測試腳本層、測試執(zhí)行層、業(yè)務(wù)展示層3個(gè)層面出發(fā)。整個(gè)測試框架的整體設(shè)計(jì)如圖4所示。

測試腳本層主要是對(duì)Selenium操作進(jìn)行二次封裝，該層使用關(guān)鍵字驅(qū)動(dòng)的自動(dòng)化測試技術(shù)將用戶的執(zhí)行操作和業(yè)務(wù)邏輯封裝成關(guān)鍵字，為了降低腳本之間的耦合性，增加腳本的靈活性，根據(jù)關(guān)鍵字所在層次分為執(zhí)行層關(guān)鍵字、常用邏輯層關(guān)鍵字和常用業(yè)務(wù)層關(guān)鍵字。

測試執(zhí)行層主要是通過測試腳本層的腳本運(yùn)行調(diào)用相應(yīng)瀏覽器驅(qū)動(dòng)和相應(yīng)的執(zhí)行邏輯對(duì)Web應(yīng)用進(jìn)行自動(dòng)化操作，記錄其操作日志和收集執(zhí)行結(jié)果，并將其反饋給服務(wù)器端。

業(yè)務(wù)展示層主要是對(duì)被測應(yīng)用進(jìn)行建模、測試監(jiān)控和測試結(jié)果分析展示，其中測試建模是通過用例模型對(duì)用戶需求進(jìn)行建模；通過行為模型對(duì)被測應(yīng)用業(yè)務(wù)流程進(jìn)行梳理，描述被測對(duì)象期待的行為；通過數(shù)據(jù)模型建立被測對(duì)象行為所用到的數(shù)據(jù)。測試監(jiān)控對(duì)測試過程路徑進(jìn)行實(shí)時(shí)監(jiān)控，測試結(jié)果分析展示就是對(duì)測試用例和測試點(diǎn)的通過情況進(jìn)行展示。

綜上，通過復(fù)雜多層的測試框架將測試過程細(xì)化，并且實(shí)現(xiàn)測試數(shù)據(jù)與測試邏輯分離，降低了測試腳本的耦合性，提高了測試腳本的復(fù)用性，達(dá)到了一定的靈活性。

3 應(yīng)用驗(yàn)證

為了覆蓋上述的測試方法，驗(yàn)證平臺(tái)的可行性和有效性，本文主要從3個(gè)方面來對(duì)該自動(dòng)化測試平臺(tái)進(jìn)行驗(yàn)證。

1)選擇了一個(gè)在線教育平臺(tái)作為被測對(duì)象，進(jìn)行測試驗(yàn)證;

2)利用多維度測試覆蓋率和測試時(shí)間成本對(duì)該平臺(tái)進(jìn)行分析，并與Spec Explorer工具進(jìn)行對(duì)比;

3)給出該平臺(tái)做過的Web應(yīng)用的自動(dòng)化測試實(shí)驗(yàn)和數(shù)據(jù)。

3.1 實(shí)驗(yàn)案例

根據(jù)上述設(shè)計(jì)實(shí)現(xiàn)了自動(dòng)化測試平臺(tái)，并通過一個(gè)基于B/S架構(gòu)的在線教育學(xué)生端系統(tǒng)進(jìn)行應(yīng)用驗(yàn)證，主要通過模型建立、關(guān)鍵字設(shè)計(jì)、用例自動(dòng)生成和測試用例自動(dòng)執(zhí)行等幾個(gè)方面進(jìn)行應(yīng)用驗(yàn)證。

1)梳理整個(gè)被測系統(tǒng)的業(yè)務(wù)邏輯流程，如登錄、搜索、選課、直播等功能，并利用自動(dòng)化測試平臺(tái)的UML狀態(tài)圖建立其被測系統(tǒng)的行為模型，如圖5所示。

圖5 行為模型

2)根據(jù)建立的行為模型狀態(tài)圖的每個(gè)狀態(tài)和遷移動(dòng)作進(jìn)行定義相應(yīng)的關(guān)鍵字，如打開網(wǎng)頁、登錄成功、退出登錄等關(guān)鍵字，并將這些關(guān)鍵字與行為模型的元素進(jìn)行對(duì)應(yīng)綁定，如圖6所示。

圖6 關(guān)鍵字

3)在主要的行為模型建立完成之后，將使用UML用例圖根據(jù)測試需求建立相應(yīng)的需求模型，再設(shè)置行為模型中的主功能和輔功能的狀態(tài)，并與需求模型進(jìn)行關(guān)聯(lián)，然后配置相應(yīng)的測試策略，設(shè)置待生成的測試用例總數(shù)為“100”，生成所有大小的環(huán)為“是”，環(huán)允許包含的節(jié)點(diǎn)數(shù)為“0”，環(huán)重復(fù)的次數(shù)為“1”，單個(gè)測試用例最大步驟數(shù)為“100”，生成算法為“全覆蓋”，生成測試用例集合。

4)在測試用例集合生成之后，進(jìn)入測試用例執(zhí)行界面，選擇需要執(zhí)行的用例集合，點(diǎn)擊“執(zhí)行”，選擇執(zhí)行設(shè)備，開始自動(dòng)執(zhí)行測試用例，自動(dòng)化測試平臺(tái)對(duì)結(jié)果進(jìn)行反饋，如圖 7所示，測試反饋結(jié)果中，一共選擇了19個(gè)用例進(jìn)行執(zhí)行，包含了273個(gè)測試點(diǎn)，用例通過為17個(gè)，未通過2個(gè)，測試點(diǎn)通過為265個(gè)，未通過為8個(gè)。

3.2 實(shí)驗(yàn)評(píng)估

為了驗(yàn)證本文測試方法和測試平臺(tái)的研究成果，選擇了Spec Explorer工具進(jìn)行對(duì)比實(shí)驗(yàn)，主要從測試覆蓋率和測試流程時(shí)間兩個(gè)方面進(jìn)行對(duì)比分析。

3.2.1 測試覆蓋率計(jì)算

基于文獻(xiàn)[7]提出的多維度軟件測試覆蓋率的評(píng)估概念：

(1)

公式(1)中，需要從不同角度對(duì)item進(jìn)行統(tǒng)計(jì)，就是考慮不同側(cè)重點(diǎn)的測試覆蓋率情況。

根據(jù)文獻(xiàn)[7]的綜合測試覆蓋率和綜合滿意度的概念：

(2)

圖7 測試報(bào)告

公式(2)表示綜合覆蓋率，

n

表示測試覆蓋率的維度，

C

表示第

i

維度的測試覆蓋率，這是由式(1)得到，其中0≤

C

≤1，1≤

i

≤

n

，

P

表示該維度覆蓋率的權(quán)重。

(3)

公式(3)表示測試的綜合滿意度，

E

表示第

i

維度的測試覆蓋率的期望值，其中0≤

E

≤1，1≤

i

≤

n

。

3.2.2 實(shí)驗(yàn)對(duì)比

實(shí)驗(yàn)挑選5個(gè)從未用過本文平臺(tái)和Spec Explorer工具的測試人員，給他們一段時(shí)間熟悉這兩個(gè)工具，對(duì)兩個(gè)工具熟悉之后，這5個(gè)測試人員分別使用這兩個(gè)工具對(duì)實(shí)驗(yàn)案例進(jìn)行測試，統(tǒng)計(jì)出測試過程中每個(gè)環(huán)節(jié)所需要的時(shí)間，然后求出測試過程中每個(gè)環(huán)節(jié)的平均時(shí)間。

對(duì)上述案例進(jìn)行測試所需平均時(shí)間成本對(duì)比如表1所示。

表1 測試流程所需時(shí)間對(duì)比

實(shí)驗(yàn)過程中主要是對(duì)web應(yīng)用功能創(chuàng)建行為模型生成測試用例集，實(shí)驗(yàn)對(duì)生成的測試用例集中滿足需求覆蓋率情況進(jìn)行對(duì)比分析，主要從功能點(diǎn)覆蓋率、頁面提示覆蓋率、流程覆蓋率、功能組合覆蓋等情況根據(jù)公式(1)計(jì)算覆蓋率，對(duì)比情況如表 2所示。

表2 覆蓋率情況對(duì)比

根據(jù)表 2、公式(2)和公式(3)分別計(jì)算出綜合覆蓋率和綜合滿意度如表 3所示。

表3 綜合覆蓋率和滿意度對(duì)比

3.3 綜合案例

為了驗(yàn)證本平臺(tái)的適應(yīng)性，選取5個(gè)不同大小，不同領(lǐng)域的Web應(yīng)用進(jìn)行了全流程自動(dòng)化測試，根據(jù)Web應(yīng)用實(shí)際情況建立模型，設(shè)計(jì)關(guān)鍵字，生成測試用例，最后生成測試報(bào)告，測試過程數(shù)據(jù)如表4所示。

表 4 Web應(yīng)用自動(dòng)化測試數(shù)據(jù)

4 結(jié)束語

本文使用了基于UML模型的測試用例生成方法、基于關(guān)鍵字驅(qū)動(dòng)思想的框架設(shè)計(jì)和復(fù)雜多層的自動(dòng)化測試框架，搭建了模型驅(qū)動(dòng)的自動(dòng)化測試平臺(tái)，并通過相應(yīng)的實(shí)驗(yàn)驗(yàn)證。該平臺(tái)通過復(fù)雜多層的自動(dòng)化測試框架降低了測試框架的耦合性，增加了測試腳本的靈活性和復(fù)用性。全流程自動(dòng)化執(zhí)行，提高了測試人員的測試效率，增加了測試覆蓋率，并適用于各類的web應(yīng)用的自動(dòng)化測試。