汪祎然，張樹東

(首都師范大學(xué) 信息工程學(xué)院，北京 100048)

?

基于模型的測試在工作流應(yīng)用程序中的研究

汪祎然，張樹東

(首都師范大學(xué) 信息工程學(xué)院，北京 100048)

近年來，工作流技術(shù)越來越多的應(yīng)用于軟件程序中，與之相關(guān)的新工作流語言以及工作流引擎也得到了快速的發(fā)展;但是，目前輔助工作流應(yīng)用軟件的測試方法仍顯不足，特別是工作流引擎測試方面還存在著嚴(yán)重的局限性;為此，提出了基于模型測試的方法對工作流引擎進(jìn)行測試，此外，還引入了抽象測試框架的概念，將其應(yīng)用到工作流的測試上，它能夠?yàn)楣ぷ髁饕鏄?gòu)建測試環(huán)境和測試套件;最后，在Cumbia平臺上搭建的一個工作流引擎上進(jìn)行應(yīng)用，說明了基于模型的測試方法和抽象測試框架可以有效應(yīng)用于工作流引擎的測試。

基于模型的測試；工作流測試；基于跟蹤執(zhí)行分析；模型驅(qū)動工程

0 引言

工作流應(yīng)用程序憑借它自動進(jìn)行業(yè)務(wù)流轉(zhuǎn)、大大減少人力的優(yōu)勢，已經(jīng)滲透到了日常生活的各個領(lǐng)域，如何保證工作流應(yīng)用程序的可靠性和質(zhì)量成為了關(guān)鍵的問題。測試是提高軟件可靠性和保證質(zhì)量的最基本手段，目前工作流應(yīng)用程序的測試還沒有比較系統(tǒng)的方法，許多工作流在沒有得到充分測試的情況下投入生成環(huán)境中，質(zhì)量難以得到保證。因此，迫切需要對工作流應(yīng)用軟件進(jìn)行有針對性的測試。

基于模型的語言、模型驅(qū)動技術(shù)和以測試為中心的軟件開發(fā)技術(shù)逐步成熟，使基于模型的軟件測試方法與技術(shù)在近幾年得到了廣泛的應(yīng)用。該種模式帶來的好處，如靈活性和效率的提高，增加了對業(yè)務(wù)流程的控制和可視性。目前，國內(nèi)外有一些相關(guān)的研究正在開展。例如，為了更好的對Web端應(yīng)用程序進(jìn)行測試，Lsakowitz等人將關(guān)系管理方法論用于描述Web應(yīng)用的設(shè)計(jì)[1]；Coda等人給出了面向?qū)ο竽Ｐ蚖OOM[2]，用高等抽象的原始實(shí)體來描述Web應(yīng)用開發(fā)；Gellersen等人提出了一種Web復(fù)合方法來結(jié)構(gòu)化Web的開發(fā)過程[3]，擴(kuò)展UML對Web應(yīng)用的體系結(jié)構(gòu)進(jìn)行建模，以此建立Web應(yīng)用的抽象測試模型。

為了使工作流應(yīng)用軟件的測試更有針對性和實(shí)效性，本文提出了兩個研究成果：第一，提出了一種基于模型的工作流測試方案，并論述了基于Cumbia平臺的工作流測試過程。Cumbia是一個用來構(gòu)建基于可執(zhí)行模型的工作流應(yīng)用程序[4]。第二，提出了抽象測試框架技術(shù)。抽象測試框架是一種用來開發(fā)基于模型的測試環(huán)境和特定工作流應(yīng)用程序的測試套件。通過在Cumbia平臺上的應(yīng)用，證明了基于模型的測試方案和抽象測試框架可以有效應(yīng)用于工作流引擎的測試。

1 工作流中基于模型的測試

1.1 基于模型的測試

基于模型的測試(Model-Based Testing, MBT)是一個通過比較被測系統(tǒng)以及被測系統(tǒng)模型行為和輸出結(jié)果來測試的方法[5]?；谀Ｐ偷臏y試基本步驟如下：

首先需要創(chuàng)建一個機(jī)器可讀的模型，該模型表述了需求所表述的所有可能行為。當(dāng)模型成型以后，基于模型的測試工具就能夠通過分析模型自動生成測試用例。測試用例一旦生成，就可以在一個標(biāo)準(zhǔn)的單元測試框架中獨(dú)立于模型運(yùn)行。這些測試用例提供了測試序列去控制待測試系統(tǒng)，同時(shí)觀察待測試系統(tǒng)的返回值，并與生成預(yù)期值進(jìn)行比較，然后做出判定測試是通過還是失敗，如圖1所示。

圖1 基于模型的測試

其中對于測試用例的生成的環(huán)節(jié)，我們可以借鑒Chourouk Bourhfir提出的基于擴(kuò)展有限狀態(tài)機(jī)(Extended Finite State Machine, EFMS)測試的理論[6]以及Diego Latella提出的UML狀態(tài)圖測試框架來自動的生成測試用例[7]：

1)將實(shí)際的業(yè)務(wù)流程首先轉(zhuǎn)化為狀態(tài)圖，再將具有層次結(jié)構(gòu)的狀態(tài)圖展開為EFSM。

2)生成測試消息系列，對EFSM進(jìn)行遍歷，有向圖的遍歷可分為深度、廣度兩種遍歷方式。為使生成的測試消息序列最短，同時(shí)運(yùn)用兩種方法生成不同的測試樹，然后為每個狀態(tài)選取從初始節(jié)點(diǎn)達(dá)到該狀態(tài)的最短路徑作為測試消息序列。

3)在EFSM的基礎(chǔ)上為每個狀態(tài)找到最短的唯一輸入輸出序列(Unique Input Output Sequence, UIOS)，只要EFSM是連接的就可以保證為每個狀態(tài)找到最短的UIOS。

4)把每個狀態(tài)的測試消息序列和UIOS結(jié)合起來組成測試用例。

因此，由于測試消息序列和UIOS都是路徑最短的，所以測試用例也能保證是路徑最短的。

1.2 測試工作流引擎

一般測試工作流引擎必須考慮到特殊的需求[8]，比如測試工作流引擎首先是驗(yàn)證它是否遵循工作流語言語義。但是僅僅對于實(shí)現(xiàn)其正確性的輸出檢查是不夠的，重點(diǎn)是驗(yàn)證中間結(jié)果和涉及其中的每個元素是否正確執(zhí)行，因此有必要具備一套完整的測試套件和更簡易建成和發(fā)展的測試環(huán)境，以適應(yīng)新的需求。工作流引擎的關(guān)鍵是支持流程的多個并發(fā)實(shí)例[9]，擁有高度并發(fā)性，為此，我們提出了抽象測試框架來提供特殊的測試環(huán)境。

2 抽象測試框架中的定義和執(zhí)行測試用例

抽象測試框架(Abstract Test Framework, ATF)是用于開發(fā)基于模型的測試環(huán)境，為應(yīng)用工作流創(chuàng)建測試套件的一個框架[10]。每一個使用抽象測試框架的環(huán)境可以共享該框架提供的兩個事物。第一，它指定測試用例的結(jié)構(gòu)，并提供基本機(jī)制執(zhí)行它們。第二，它指定一個機(jī)制分析測試用例的執(zhí)行，并提供工具執(zhí)行這些分析。

2.1 測試用例的結(jié)構(gòu)

圖2 測試用例的元素

抽象測試框架的測試用例由5個元素組成，如圖2所示。工作流模型是在測試用例運(yùn)行時(shí)執(zhí)行的流程。實(shí)例化模式是指如何對測試用例中的每個工作流模型舉例和有多少個實(shí)例被創(chuàng)建。動畫程序是由動畫語言編寫的，控制工作流的執(zhí)行。觀察結(jié)構(gòu)用來實(shí)現(xiàn)執(zhí)行中的信息收集。斷言程序用于分析由觀察結(jié)構(gòu)收集來的數(shù)據(jù)。

2.2 執(zhí)行測試用例

一旦工作流測試用例的元素被定義，測試用例就可以在抽象測試框架中執(zhí)行[11]。工作流測試用例的執(zhí)行涉及4個階段，如圖3中所示。

圖3 抽象測試框架中的工作流測試用例執(zhí)行

在實(shí)例化階段，一個實(shí)例化模式被用作創(chuàng)建工作流模型實(shí)例，實(shí)例在這個階段創(chuàng)建觀察結(jié)構(gòu)。接下來在動畫階段，動畫程序被執(zhí)行。同時(shí)觀察階段也開始。一旦流程執(zhí)行完成，分析階段開始，斷言程序就被執(zhí)行[12]。在這一過程中，程序通過比較預(yù)先定義的預(yù)期結(jié)果與聚集在路徑的相應(yīng)信息，完成對一組斷言的驗(yàn)證，數(shù)據(jù)分析器用于分析斷言程序，從路徑獲得詳細(xì)的信息。

2.3 抽象測試框架的元素

抽象測試框架規(guī)定了3個主要的部分：測試裝載器、測試行為和測試運(yùn)行器，如圖4所示。

圖4 抽象測試框架的組成

測試裝載器是負(fù)責(zé)裝載測試用例的定義，其需要對裝載的每個元素展示接口，使得它可以自定義不同測試用例來進(jìn)行表示。測試行為是負(fù)責(zé)實(shí)施元素的行為，測試用例的執(zhí)行。測試運(yùn)行器使這兩個部分的執(zhí)行相協(xié)調(diào)。

由于測試行為對于每個使用抽象測試用例的工作流引擎均需定義，這個部分就不能包括一個默認(rèn)接口。反之，它只能向那些在用例執(zhí)行中動態(tài)使用的部分展示接口。第一個必須實(shí)施的接口是實(shí)例Ⅰ，它的兩個主要職責(zé)是初始化工作流引擎和創(chuàng)建所給工作流模型的實(shí)例。工作流模型的信息和其它接口需要的信息一樣，使用測試裝載器從測試用例的定義裝載。一旦實(shí)例Ⅰ被定義，動畫設(shè)計(jì)Ⅰ開始執(zhí)行。這個接口的職責(zé)是翻譯和執(zhí)行一個動畫程序。和動畫設(shè)計(jì)Ⅰ一起，追蹤器Ⅰ和傳感器Ⅰ兩個接口必須同時(shí)執(zhí)行。它們的職責(zé)包括在動畫執(zhí)行中對事件做出反應(yīng)、使事件和路徑聯(lián)合和處理那些事件的路徑。這些接口一旦執(zhí)行，測試Ⅰ接口就開始執(zhí)行。這個接口是利用一組數(shù)據(jù)分析器來翻譯和執(zhí)行斷言程序的，他們的職責(zé)是查詢聚集在元素中的信息，使追蹤器Ⅰ的接口執(zhí)行。最后，測試運(yùn)行器動態(tài)裝載一個工作流測試用例中必要的元素，并且使用這些元素執(zhí)行已給出的工作流測試用例定義。

3 測試開發(fā)路徑

測試開發(fā)路徑描述了構(gòu)建一個已給出的工作流引擎的測試套步驟，包括一個基于抽象測試框架的測試基礎(chǔ)架構(gòu)的建構(gòu)模型[13]。這個路徑是由兩個獨(dú)立部分組成的，如圖5所示。

圖5 測試開發(fā)路徑圖

左邊是設(shè)計(jì)、建造和運(yùn)行測試用例的操作。第一步，識別特性，工作流語言中所有可測試的特性均需要被識別。共同特性包括控制結(jié)構(gòu)，例如聯(lián)結(jié)、分裂和順序，還有不同種類的數(shù)據(jù)管理。第二步，建立特性依賴圖，將識別出的特性組成有向圖，在兩個節(jié)點(diǎn)直接用弧線顯示特性之間的依賴關(guān)系。第三步，設(shè)計(jì)測試用例，將所有需要為引擎創(chuàng)建一個全面的測試套件的活動進(jìn)行分組。為了在第一步中識別出的每個特性，至少要設(shè)計(jì)一個測試用例。第四步，建立測試用例，使測試用例的說明具體化。最后一步，運(yùn)行測試用例。這步使用一個來自特性依賴圖的測試腳本，使測試執(zhí)行自動化進(jìn)行，在日益增加的復(fù)雜性中按一定的次序促進(jìn)問題的檢測。

右邊是構(gòu)建基礎(chǔ)設(shè)施的操作，用來支持結(jié)構(gòu)和建構(gòu)和執(zhí)行那些測試用例，這些步驟不必以特定的順序執(zhí)行。設(shè)計(jì)動畫語言把需要的活動分組，設(shè)計(jì)用來編寫動畫程序的語法和語言語義；設(shè)計(jì)數(shù)據(jù)分析器把必要的任務(wù)分組，定義數(shù)據(jù)分析器所需的測試用例以及他們中的每一個如何收集必要的信息；設(shè)計(jì)斷言語言把需要的活動分組，設(shè)計(jì)一個可以被用于編寫斷言程序的語言。最后步驟是執(zhí)行具體的框架。

4 測試J-Cumbia：一個基于抽象測試框架和測試開發(fā)路徑的案例研究

4.1 XPM引擎及J-Cumbia測試框架

Cumbia-XPM(eXtensible Process Metamodel)是一個用于描述工作流過程的元模型[14]。這個元模型由一套開放對象的特殊化元素組成。這些開放對象其中包括一個實(shí)體、一個狀態(tài)機(jī)和一些與狀態(tài)機(jī)的轉(zhuǎn)換相關(guān)聯(lián)的動作。J-Cumbia測試框架是一個用來測試J-Cumbia 引擎的專業(yè)化抽象測試框架，其工作流模型是Cumbia-XPM模型。

4.2 遵循路線圖

下面就開始描述如何遵循測試開發(fā)路徑步驟，使用測試基礎(chǔ)步驟來測試J-Cumbia，具體的測試用例如下：

第一步，識別特征。在分析Cumbia-XPM之后，根據(jù)Cumbia-XPM的主要特征識別出的特征總結(jié)。

第二步，建立特征依賴圖。為確定Cumbia-XPM的特征組織為特征依賴圖，如圖6。每一個測試用例在第三步的設(shè)計(jì)中，將與特征依賴圖中的一個節(jié)點(diǎn)相關(guān)聯(lián)。

圖6 Cumbia-XPM特征依賴圖

第三步，設(shè)計(jì)測試用例。要詳細(xì)說明一個測試用例的設(shè)計(jì)[15]。所謂的“進(jìn)程1”包含3個活動，即活動1、活動2和活動3。當(dāng)這些活動執(zhí)行，他們的工作區(qū)可以被測試用例的動畫程序所控制。根據(jù)XPM的語義學(xué)和進(jìn)程的結(jié)構(gòu)，活動3只能在活動1和活動2執(zhí)行完成后被執(zhí)行。這個測試用例將檢車這個規(guī)則是否遵守。圖7在括號內(nèi)顯示數(shù)據(jù)在進(jìn)程中的活動之間流動。

圖7 F8的測試場景

對這個測試用例中的每一個執(zhí)行，我們只要有一個進(jìn)程的實(shí)例。因此，我們只要有一個動畫程序，便可以指定數(shù)據(jù)初始化進(jìn)程，指定命令控制活動1、活動2、活動3的工作區(qū)執(zhí)行。

下面則為測試用例設(shè)計(jì)的動畫程序：

animation{

init{

port(process1:pi){

var d1=”data1”;

var d2=”data2”;}

}

workspaces{

workspace(process1:ACT1:ws){

1:var e1=input(d1);

output(e1);}

workspace(process1:ACT2:ws){

1:var e2=input(d2);

output(e2);}

workspace(process1:ACT3:ws){

1:var t1=input(e1);

var t2=input(e2);

var e3=concat(t1,t2);

output(e3);}

}

}

這個程序的第一部分指定了進(jìn)程將使用一對數(shù)據(jù)來初始化：data1的值賦給d1，data2的值賦給d2?；顒?和活動2的工作區(qū)的行為是相似的：他們第一次被執(zhí)行，他們獲取了d1和d2的值，并用e1和e2給輸出命名。當(dāng)活動3被執(zhí)行，它的工作區(qū)串聯(lián)e1和e2的值，輸出結(jié)果作為e3。為了對這個測試用例描述一個成功的執(zhí)行，使用斷言語言編寫了4個斷言。

//斷言1：活動3的輸入端就只接收一次數(shù)據(jù)。

assertion(“1”){

let pwf=timeFull(process1.ip3) in

equal(pfw,1)}

//斷言2：活動1、活動2、活動3每一個就只被激活一次。

assertion(“2”){

let act1=timesActivated(process1.ACT1) &&

let act2=timesActivated(process1.ACT2) &&

let act3=timesActivated(process1.ACT3) in

equal(act1,1) &&

equal(act2,1) &&

equal(act3,1)}

//斷言3：活動3的輸入數(shù)據(jù)應(yīng)該為“data1”和“data2”。

assertion(“3”){

let inputE1= activityInput(process1.ACT3,1,e1) &&

let inputE2= activityInput(process1.ACT3,1,e2) in

equal(inputE1,”data1”) &&

equal(inputE2,”data2”)}

//斷言4：活動3需要在活動和活動2完成后被激活。

assertion(“4”){

activityFollows(process1.ACT3,process1.ACT1) &&

activityFollows(process1.ACT3,process1.ACT2)}

上面提出的這4個斷言為觀察結(jié)構(gòu)提出了需求。下面的事件和信息與檢驗(yàn)斷言相關(guān)：活動3的輸入端獲取完整(斷言1)；活動1、活動2和活動3被激活(斷言2)；當(dāng)活動3被激活后，輸入數(shù)據(jù)被獲取(斷言3)；活動1和活動2失效，活動3被激活(斷言4)。此信息可以通過傳感器獲得，通知活動的激活(在狀態(tài)機(jī)中轉(zhuǎn)換“激活”)和端口的數(shù)據(jù)接收(在狀態(tài)機(jī)中轉(zhuǎn)換“包”)。

第四步，建立測試用例。此步驟可依據(jù)上文中的自動生成測試用例方法來實(shí)現(xiàn)。

第五步，運(yùn)行測試用例。我們提供了兩種方法運(yùn)行測試用例。第一種，使用測試腳本自動地執(zhí)行所有測試用例，結(jié)果會以文本的方式告知用戶。第二種，使用一個Eclipse plugin開發(fā)的圖形化工具運(yùn)行測試用例[16]。這個工具叫做Test Viewer，以圖形化的方式，呈現(xiàn)測試用例的執(zhí)行和結(jié)果。為了顯示結(jié)果，使用一個類似JUnit的Eclipse視圖[17]，斷言程序的結(jié)果可以很容易的被查看。

5 結(jié)語

本文詳細(xì)闡明了一種基于模型的測試工作流應(yīng)用程序的方法。為了配合這種特殊的測試方法，文中提出了抽象測試框架和測試開發(fā)路徑，以此來搭建測試的環(huán)境以及創(chuàng)建相關(guān)套件，最終在J-Cumbia環(huán)境下應(yīng)用，證明了基于模型的測試方案和抽象測試框架可以有效應(yīng)用于工作流引擎的測試。文中使用了一個XPM進(jìn)程引擎建立在J-Cumbia平臺之上，模擬抽象測試框架與測試開發(fā)路徑的廣泛適用性。盡管最初抽象測試框架和測試開發(fā)路徑是基于Cumbia引擎開發(fā)的，但他們同樣可以應(yīng)用在其他不相關(guān)的工作流引擎上。隨著當(dāng)前軟件規(guī)模的越來越大，測試的規(guī)模也必將逐漸擴(kuò)展，這就使得純粹的基于程序的測試十分困難。而基于模型的測試不僅可以有效地提高效率，還提高測試用例生成的自動化程度，進(jìn)行測試失效辨別，也有利于測試結(jié)果的評估與分析。

雖然文中提到的方法已在J-Cumbia平臺上實(shí)現(xiàn)，但自動化測試還需要能夠?qū)y試用例的結(jié)果進(jìn)行自動分析，在該方面還留有不足，將來也將進(jìn)一步改進(jìn)完善。

[1]Torsel A M. A testing tool for web applications using a domain-specific modelling language and the NuSMV model checker[J/OL]. IEEEXplore.

[2]張 玲. Web應(yīng)用自動化測試框架的研究和應(yīng)用[D]. 上海：華東理工大學(xué), 2014.

[3]Zhu B B, Guo R, Feng M, et al. Component-oriented architecture for web mashups[P]. US: US9009657,2015.

[4]馮 洋,張冬冬,劉 群.層次短語翻譯模型的介詞短語調(diào)序[J]. 中文信息學(xué)報(bào),2012,26(1) :31-36.

[5]張 清.基于模型的自動化測試工具的實(shí)現(xiàn)[D].北京：北京交通大學(xué),2013.

[6]陸公正. 基于EFSM模型的測試用例優(yōu)化生成及實(shí)例化[D]. 上海:上海大學(xué), 2014.

[7]Aichernig B K, Lorber F, Tiran S. Formal test-driven development with verified test cases[A]. Special Session on Model-based Analysis & Testing of Embedded Systems[C]. 2014: 626-635.

[8]王雙成,劉念祖,王小玲.基于局部依賴分析的特征子集選擇[J].計(jì)算機(jī)研究與發(fā)展,2014(44): 329-333.

[9]馮 韻.基于標(biāo)記語言的工作流過程描述語言[J].電腦知識與技術(shù),2012(8): 43-45.

[10]郭 曦,張煥國.基于謂詞抽象的測試用例約簡生成方法[J].通信學(xué)報(bào),2012,33(3) :35-43.

[11]張孟穎.基于工作流的軟件測試管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].南京:南京理工大學(xué),2013.

[12]王志才. 一種基于斷言圖的模型抽象技術(shù)的研究[D].成都：電子科技大學(xué)，2013.

[13]周婷婷,費(fèi)樹岷.基于工作流的辦公自動化系統(tǒng)研究與設(shè)計(jì)[J].工業(yè)控制計(jì)算機(jī),2013,26(4):102-104.

[14]王 平.基于組件的工作流定義工具的研究與實(shí)現(xiàn)[D].沈陽：沈陽工業(yè)大學(xué),2014.

[15]張 娟.軟件測試中測試用例復(fù)用的研究[D].上海：上海大學(xué),2012.

[16]張 娟,余童蘭,吳取勁,等.基本路徑生成算法的圖形化設(shè)計(jì)與實(shí)現(xiàn)[J].南華大學(xué)學(xué)報(bào)(自然科學(xué)版),2014(1) :88-90.

[17]楊 鵬.基于Feed4JUnit架構(gòu)的單元測試技術(shù)研究與應(yīng)用[J].軟件工程師,2014(7) :25-27.

Research of Model Based Testing for Workflow Application

Wang Yiran，Zhang Shudong

(College of Information Engineering, Capital Normal University, Beijing 100048, China)

In recent years, more and more workflow applications applied in the software program. The new workflow language associated with the new workflow and workflow engine also got rapid development. However, the current test methods of the development of the auxiliary workflow application is still inadequate, especially the workflow engine test also there are serious limitations. To this end, this paper presents a method based on model based testing to carry out on the workflow engine. In addition, it introduces the concept of the abstract test framework. Applying it to the workflow of the test, it can build the test environment and test suites for the workflow engine. At the end, a workflow engine built on Cumbia platform shows that the using of method based on model testing and abstract test framework can be effectively applied to the workflow engine testing.

model based testing; workflow testing; trace based execution analysis; model driven engineering

2015-12-22；

2016-03-08。

國家科技支撐計(jì)劃項(xiàng)目(2013BAH19F01);高可靠嵌入式系統(tǒng)技術(shù)北京市工程研究中心，電子系統(tǒng)可靠性技術(shù)北京市重點(diǎn)實(shí)驗(yàn)室，北京市屬高等學(xué)校創(chuàng)新團(tuán)隊(duì)建設(shè)與教師職業(yè)發(fā)展計(jì)劃項(xiàng)目。

汪祎然(1990-)，女，碩士研究生，主要從事軟件工程、軟件測試方向的研究。

張樹東(1969-)，男，博士，教授，主要從事計(jì)算機(jī)網(wǎng)絡(luò)、分布式計(jì)算方向的研究。

1671-4598(2016)06-0143-04

10.16526/j.cnki.11-4762/tp.2016.06.039

TP311.5

A