基于模型驅動的Web應用自動化測試平臺設計與應用

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

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

0 引言

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

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

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

1 自動化測試平臺概述

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

1.1 自動化測試工作流程

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

圖1 模型驅動的自動化測試工作過程

1.2 自動化測試平臺構成

本文所述自動化測試平臺主要由服務器端和客戶端組成，其中主要的應用功能模塊可分為3個組成部分。

1.2.1 測試模型

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

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

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

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

1.2.2 測試用例及測試腳本

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

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

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

2 自動化測試平臺設計

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

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

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

圖2 測試用例生成流程圖

2.1.1 測試路徑生成方法

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

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

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

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

輸入：一個有向圖邊的鄰接矩陣matrix和點集合vertex;

輸出：路徑集合

P

={

P

(

v

,…,

v

),

P

,…,

P

};

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

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

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

Function getPaths(){;

For i -> countPathNumber():

path = {} ; //用于保存遍歷過的點;

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

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

End for;

}

//返回所有的路徑集合

Return P

End function

2)軟件產品風險與生成算法優(yōu)先級概要。

產品風險對應的名詞解釋如下。

Trunk：直接反映需求對應的軟件行為的狀態(tài)節(jié)點。

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

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

從基于風險的測試策略角度來看，trunk對應的是功能是否正常工作的直接風險；relation對應的是功能穩(wěn)定性，互操作性相關質量屬性的風險；normal對應的是功能可能相關的低級風險。

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

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

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

圖3 關鍵字驅動架構

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

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

2.1.2 測試覆蓋生成策略

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

圖4 測試框架圖

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

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

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

2.2 基于關鍵字驅動思想的框架設計

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

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

2.3 復雜多層的自動化測試框架

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

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

測試執(zhí)行層主要是通過測試腳本層的腳本運行調用相應瀏覽器驅動和相應的執(zhí)行邏輯對Web應用進行自動化操作，記錄其操作日志和收集執(zhí)行結果，并將其反饋給服務器端。

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

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

3 應用驗證

為了覆蓋上述的測試方法，驗證平臺的可行性和有效性，本文主要從3個方面來對該自動化測試平臺進行驗證。

1)選擇了一個在線教育平臺作為被測對象，進行測試驗證;

2)利用多維度測試覆蓋率和測試時間成本對該平臺進行分析，并與Spec Explorer工具進行對比;

3)給出該平臺做過的Web應用的自動化測試實驗和數(shù)據(jù)。

3.1 實驗案例

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

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

圖5 行為模型

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

圖6 關鍵字

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

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

3.2 實驗評估

為了驗證本文測試方法和測試平臺的研究成果，選擇了Spec Explorer工具進行對比實驗，主要從測試覆蓋率和測試流程時間兩個方面進行對比分析。

3.2.1 測試覆蓋率計算

基于文獻[7]提出的多維度軟件測試覆蓋率的評估概念：

(1)

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

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

(2)

圖7 測試報告

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

n

表示測試覆蓋率的維度，

C

表示第

i

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

C

≤1，1≤

i

≤

n

，

P

表示該維度覆蓋率的權重。

(3)

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

E

表示第

i

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

E

≤1，1≤

i

≤

n

。

3.2.2 實驗對比

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

對上述案例進行測試所需平均時間成本對比如表1所示。

表1 測試流程所需時間對比

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

表2 覆蓋率情況對比

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

表3 綜合覆蓋率和滿意度對比

3.3 綜合案例

為了驗證本平臺的適應性，選取5個不同大小，不同領域的Web應用進行了全流程自動化測試，根據(jù)Web應用實際情況建立模型，設計關鍵字，生成測試用例，最后生成測試報告，測試過程數(shù)據(jù)如表4所示。

表 4 Web應用自動化測試數(shù)據(jù)

4 結束語

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