基于任務(wù)場景的測試需求建模方法

徐 珞，石 晶，郝 博

（1.華北計算技術(shù)研究所，北京100083；2.中國電子設(shè)備系統(tǒng)工程公司研究所，北京100141）

0 引 言

測試需求描述［1］是軟件測試中最困難［2］也是最重要的部分，其質(zhì)量的好壞對軟件測試具有重要影響［3］。為了清晰地描述測試需求，研究人員提出了嚴謹?shù)男枨竽Ｐ?，如ETSI（歐洲電信標準化協(xié)會）制定的TPLan語言［4］，但由于采用了半形式化語法，該語言難以被計算機解析因而不能支持自動測試生成。為此，研究人員開始采用形式化模型來描述測試需求，如Segura等提出的測試套自動生成工具［5］，但該工具只能描述功能測試需求。性能測試中描述測試需求的傳統(tǒng)方法為開發(fā)benchmark，其典型代表是工作流［6］。在可靠性測試中，一般使用操作剖面描述測試需求，如基于 Musa［7］和 Markov［8，9］的使用剖面構(gòu)造法。然而，上述方法只針對單一類型的測試，目前仍缺乏一種統(tǒng)一的方法來同時描述功能、性能和可靠性測試需求。在一個包含這3種類型測試的復雜測試任務(wù)中，測試人員不得不采用多種方法來分別描述各類測試需求，這將加大測試負擔。

本文提出了一種基于任務(wù)場景的測試需求 （test requirements based on task scenario，TreBts）建模方法以統(tǒng)一地方式描述功能、性能和可靠性測試需求，并設(shè)計了3類視圖以可視化形式的展現(xiàn)TreBts模型，從而易于測試人員之間的溝通交流，以減小測試人員的負擔，提高測試有效性。

1 TreBts概念模型

定義1 任務(wù)場景TaskScenario［10］是指特定領(lǐng)域的用戶實際使用被測系統(tǒng) （system under test，SUT）完成一類給定任務(wù)的場景，可表示為一個五元組

其中name標記該任務(wù)場景的名字；Participants＝｛Participant｝，Participant指該任務(wù)場景的參與者，一個任務(wù)場景一般包含多類用戶和一個SUT（用屬性name標識其名字）；Tasks＝ ｛Task｝，Task為在任務(wù)場景中需要執(zhí)行的任務(wù)，包含一個屬性name以標識Task的名字；TaskRegions＝ ｛TaskRegion｝，TaskRegion為一系列原子任務(wù)的集合；Relations＝ ｛Relation｝，Relation則代表了兩個對象之間的關(guān)系，如Task和TaskRegion。

定義2 User為一類特定類型的用戶，可表示為一個四元組

屬性name標識了該用戶的名字，startTime和endTime分別表示了該用戶開始執(zhí)行任務(wù)的時間和執(zhí)行完所有任務(wù)的時間，load則定義為函數(shù)load＝function（t，c），指該類用戶的并發(fā)用戶數(shù)c隨著執(zhí)行時間t的變化而變化的情況。

Task可分解為StartTask、EndTask和TestTask，分別表示任務(wù)場景的開始任務(wù)、結(jié)束任務(wù)和測試任務(wù)，其中TestTask可繼續(xù)分解為復合任務(wù)CompTask和原子任務(wù)AtomTask，其中CompTask是一系列 AtomTask和／或CompTask的集合。一個AtomTask或CompTask與負責發(fā)起該任務(wù)的User相關(guān)聯(lián)。另外，AtomTask除繼承Task的屬性name外，還有一個屬性cycle用來表示一個任務(wù)在測試過程中需要循環(huán)執(zhí)行的次數(shù)。本文參考Fabio Paternò在并行任務(wù)樹 （concur task tree，CTT）［11］對任務(wù)的分類，將AtomTask分解為交互任務(wù)InteractionTask和應(yīng)用任務(wù)ApplicationTask，前者的參與者包括SUT及多類用戶，而后者只有SUT參與執(zhí)行。

定義3 SubTask表示兩個CompTask或一個CompTask和一個AtomTask的關(guān)系，其形式為如下二元組

SubTask＝ （fatherTask，sonTask）

其中fatherTask必須為CompTask，sonTask可為CompTask或AtomTask。

定義4 一個原子任務(wù)AtomTask關(guān)聯(lián)一個或多個Interaction，以描述多類用戶和SUT在任務(wù)執(zhí)行過程中的交互過程，可表示為一個二元組

LifeLines＝ ｛LifeLine｝，LifeLine為 代 表 參 與 者 （如SUT和用戶）的生命線，與Participant相關(guān)聯(lián)，Messages＝｛Message｝，Message指兩個LifeLine之間交換的消息。

定義5 Message可表示為一個三元組

以上3個屬性分別代表源LifeLine、目標LifeLine和此消息所調(diào)用方法。

Relation包括SequenceRel、ConcurrencyRel、EnablingRel、DeactivationRel和DiscontinuingRel共五類。

定義6 SequenceRel為兩個對象之間的順序關(guān)系，可表示為一個五元組

其中屬性sourceTask和targetTask分別表示順序關(guān)系的源任務(wù) （StartTask或 AtomTask）和目標任務(wù) （End－Task或AtomTask），Sequence代表順序執(zhí)行，rate和delay分別代表目標任務(wù)被選中的概率和開始執(zhí)行目標任務(wù)開始前應(yīng)延遲的時間。

定義7 ConcurrencyRel，EnablingRel，Deactivation－Rel，DiscontinuingRel分別表示兩個對象之間的并發(fā)關(guān)系，激發(fā)關(guān)系，終止關(guān)系和中斷關(guān)系，均可用一個三元組表示

X可為ConcurrencyRel，EnablingRel，DeactivationRel和DiscontinuingRel，對應(yīng)的Y為Concurrency，Enabling，Deactivation和Discontinuing。其中Concurrency表示兩個InteractionTask同時并發(fā)執(zhí)行；Enabling用于連接一個sourceObject（AtomTask）和它所激活的targetObject（ApplicationTask）；而終止關(guān)系Deactivation和中斷關(guān)系Discontinuing都用來描述兩個AtomTask或一個AtomTask和一個TaskRegion之間的關(guān)系，兩者的不同之處在于Deavtivation表示當其sourceObject（AtomTask）開始執(zhí)行時，targetObject（AtomTask或TaskRegion）必須終止，而Discontinuing表示當sourceObject（AtomTask）完成后，其targetObject（AtomTask或TaskRegion）可以繼續(xù)執(zhí)行。

2 TreBts視圖與建模指南

本節(jié)提出三類視圖來構(gòu)造TreBts模型并定義了一系列規(guī)則來檢查多類視圖之間的約束關(guān)系；另外，為指導測試人員正確建立三類視圖，本節(jié)還給出了建模指南。

2.1 TreBts視圖

第1節(jié)定義的TreBts概念模型包括多種概念和關(guān)系。相對于將這些概念和關(guān)系都用一個視圖來表示，常用方式是采用多個視圖來描述整個概念模型［12］，因此本文進行視圖分解的原則是：采用一個視圖來覆蓋概念模型中盡量少但相對完整的概念和關(guān)系，最后推導出了以下三類視圖。

（1）任務(wù)分解視圖：描述該任務(wù)場景中的各類用戶，并將一個給定的任務(wù)按用戶分解為一系列原子任務(wù)。

（2）交互場景視圖：描述SUT和其他用戶的交互過程，根據(jù)概念模型中AtomTask和Interaction之間的關(guān)系，任務(wù)分解視圖中的每個原子任務(wù)都關(guān)聯(lián)一個或多個交互場景視圖。

（3）任務(wù)規(guī)劃視圖：描述任務(wù)分解視圖中每類用戶的原子任務(wù)之間的執(zhí)行順序。

概念模型中的元素在三類視圖中的表示方法見表1。

表1 概念模型中的元素

由于不同的視圖可能會覆蓋相同的概念和關(guān)系，因此需要定義一系列規(guī)則來確保不同視圖之間概念的一致性和完整性［13］，見表2。

表2 一致性和完整性規(guī)則

2.2 建模過程指南

基于上述三類視圖和規(guī)則，本文給出了一個建模過程指南，以幫助測試人員快速建立測試需求模型，如圖1所示。

圖1 建模過程指南

該流程包含足夠的信息來同時支持功能、性能和可靠性測試。首先，每個原子任務(wù)關(guān)聯(lián)的交互場景視圖都描述成了一系列功能點的集合，且TreBts模型覆蓋了SUT所有功能，因此當整個測試完成后，獲得的測試結(jié)果可完全支持功能測試分析。其次，通過分析用戶的load特性可獲取各類用戶的最大并發(fā)數(shù)以及SUT響應(yīng)時間等其它性能屬性，這些數(shù)據(jù)可以為性能測試分析提供足夠的信息。再次，SUT的長時間運行可保證系統(tǒng)執(zhí)行多個原子任務(wù)并獲取大量數(shù)據(jù)來分析SUT的可靠性，綜上所述，本文提出的TreBts模型可同時描述3種類型的測試需求。

3 基于TreBts模型的測試流程

描述完TreBts的概念模型后，本文提出了基于TreBts模型的軟件測試流程，以指導測試人員開展測試，主要步驟如下：

步驟1 使用TreBts模型來描述SUT的測試需求。

步驟2 針對每類用戶，從任務(wù)規(guī)劃視圖中獲取該用戶的開始時間和結(jié)束時間。

步驟3 針對每類用戶，在測試執(zhí)行過程中，從任務(wù)規(guī)劃視圖中獲取動態(tài)變化的并發(fā)用戶數(shù)。

步驟4 針對每類用戶，從任務(wù)規(guī)劃視圖中依次讀取一個任務(wù)，包括該任務(wù)的cycle和delay屬性。同時，獲取該任務(wù)對應(yīng)的交互場景視圖以產(chǎn)生測試用例和相關(guān)的測試數(shù)據(jù)。

步驟5 開始執(zhí)行測試。根據(jù)步驟4獲得的測試用例和數(shù)據(jù)以及步驟3獲得的并發(fā)用戶數(shù)開始執(zhí)行測試。

步驟6 收集和分析測試結(jié)果。當所有用戶完成測試后，根據(jù)收集的測試結(jié)果進行功能、性能和可靠性測試分析。

4 實驗案例

為了驗證TreBts建模方法的有效性，本文選擇了典型被測系統(tǒng)進行了實驗驗證，下面進行詳細介紹。

4.1 選擇被測系統(tǒng)

本文選擇某數(shù)據(jù)共享系統(tǒng)作為被測系統(tǒng)，該系統(tǒng)主要提供數(shù)據(jù)注冊、數(shù)據(jù)發(fā)布、數(shù)據(jù)訂閱和數(shù)據(jù)推送功能，其業(yè)務(wù)流程模型如圖2所示。在本案例中需要測試該系統(tǒng)的功能、性能和可靠性。

圖2 SUT業(yè)務(wù)流程模型

4.2 建立TreBts模型

根據(jù)數(shù)據(jù)被測系統(tǒng)的基本功能，確定其典型任務(wù)場景來表示不同類型的用戶并發(fā)使用該系統(tǒng)的情況。在本案例中，氣象數(shù)據(jù)提供者、地圖數(shù)據(jù)提供者和數(shù)據(jù)消費者共三類用戶需要與SUT進行交互，其中兩類數(shù)據(jù)提供者主要使用SUT的數(shù)據(jù)注冊和數(shù)據(jù)發(fā)布功能，數(shù)據(jù)消費者則利用SUT進行數(shù)據(jù)訂閱和數(shù)據(jù)推送。最后建立的三類視圖如下。

4.2.1 任務(wù)分解視圖

任務(wù)分解如圖3所示，待分解的數(shù)據(jù)共享任務(wù)首先被三類用戶分解成了8個任務(wù)，之后，氣象數(shù)據(jù)提供者的兩個任務(wù)可進一步分解為兩個原子任務(wù)。該任務(wù)分解過程中，除了兩個數(shù)據(jù)推送任務(wù)屬于應(yīng)用任務(wù)外，其它的均為交互任務(wù)。

圖3 任務(wù)分解

4.2.2 交互場景任務(wù)

圖4為水文數(shù)據(jù)注冊的交互場景視圖，包含兩個參與者：氣象數(shù)據(jù)提供者和數(shù)據(jù)共享系統(tǒng)，分別由兩條LifeLine和一系列Message表示。

圖4 水文數(shù)據(jù)注冊交互場景

4.2.3 任務(wù)規(guī)劃視圖

三類用戶需要執(zhí)行任務(wù)分解視圖中的多個原子任務(wù)，所以任務(wù)規(guī)劃視圖需要描述原子任務(wù)在執(zhí)行過程需要的參數(shù)和他們之間的關(guān)系，如圖5所示。每個用戶有唯一的開始任務(wù)和結(jié)束任務(wù)，三類用戶執(zhí)行任務(wù)的開始時間和結(jié)束時間均為0小時和15小時，圖6給出了三類用戶的并發(fā)數(shù)隨執(zhí)行時間變化的情況。

圖5 任務(wù)規(guī)劃

圖6 三類用戶的并發(fā)用戶數(shù)

4.3 測試執(zhí)行

在用三類視圖描述完測試需求后，采用第3節(jié)提出的測試流程產(chǎn)生測試套，包括測試用例和測試數(shù)據(jù)，并執(zhí)行測試。

4.4 測試結(jié)果分析

對收集的測試結(jié)果分別進行功能、性能和可靠性分析。

（1）功能測試分析：功能測試結(jié)果見表3，可以看到整個測試覆蓋了SUT的所有功能，且所有功能都通過了。

表3 功能測試結(jié)果

（2）性能測試分析：從圖6中可以看到氣象數(shù)據(jù)提供者的并發(fā)數(shù)從0增長到120，系統(tǒng)響應(yīng)時間從0.02s變到0.1s，且穩(wěn)定在0.1s；同樣地，隨著執(zhí)行時間的增長，系統(tǒng)響應(yīng)時間隨著并發(fā)用戶數(shù)的變化而減少。

（3）可靠性測試分析：測試結(jié)束后，通過收集的失效數(shù)據(jù)得到SUT的失效率為2.75×10－3，可靠度為0.9973。另外，可從失效數(shù)據(jù)中判斷系統(tǒng)易發(fā)生失效的關(guān)鍵位置，從而在對SUT的后續(xù)使用中對這些位置進行重點保護來提高系統(tǒng)的可靠性。

從上面的分析中可以看到本文提出的TreBts模型可有效描述功能、性能和可靠性測試需求；對應(yīng)的測試套可完全滿足每類測試需求。

5 結(jié)束語

本文提出了TreBts模型來同時描述功能、性能和可靠性測試需求。在建立了TreBts概念模型之后，設(shè)計了三類視圖來表示模型中的元素和關(guān)系，同時給出了建模應(yīng)用指南來輔助測試人員建立三類視圖。另外，本文提出了基于TreBts的測試流程來指導測試人員開展測試。典型實驗結(jié)果表明TreBts模型可準確描述三類測試需求，且自動生成的測試套可完全滿足每類測試需求，同時本文提出的TreBts模型具有良好的可視化，便于測試人員理解，降低了測試人員的負擔，提高了測試有效性。

［1］Tian Mei，Wu Ji，Gong Ruilong.Test requirement model：As a bridge connecting SUT and test design ［C］／／Proceedings of International Conference on Software and Computer Applications，2012：132－136.

［2］Xiong Qiuyan，Yang Hebiao，Hu Jinjin.A method of evaluating software requirement specification ［C］／／Proceedings of 4th IEEE International Conference on Computer Science and Information Technology，2011：277－280.

［3］ZHAO Xiaolan.Analysis of standard software test process［J］.Aerospace Control，2010，28 （1）：96－99 （in Chinese）.［趙曉嵐.規(guī)范化軟件測試過程淺析 ［J］.航天控制，2010，28 （1）：96－99.］

［4］Schulz S，Wiles A，Randall S.TPLan－A notation for expressing test purposes ［C］／／Proceedings of Test Com，Springer－Verlag，2007：292－304.

［5］Segura S，Benavides D，Ruiz－Corteìs A.Functional testing of feature model analysis tools：A test suite ［J］.Software，IET，2011，5 （1）：70－82.

［6］XUE Haiyan，WANG Yan.Workflow model based on stochastic Petri nets and performance evaluation ［C］／／Proceedings of IEEE International Symposium on IT in Medicine ＆ Education，2009：245－249.

［7］LU Minyan.Software reliability engineering ［M］.Beijing：National Defense Industry Press，2011 （in Chinese）. ［陸民燕.軟件可靠性工程 ［M］.北京：國防工業(yè)出版社，2011.］

［8］LEI Hang，MA Chenggong.Testing adequacy of software reliability in Markov model ［J］.Journal of University of Electronic Science and Technology of China，2010，39 （1）：101－105 （in Chinese）.［雷航，馬成功.Markov模型的軟件可靠性測試充分性問題的研究 ［J］.電子科學大學學報，2010，39 （1）：101－105.］

［9］Yan Hua， Wu Xiaoyue.Reliability computing methods for TT＆C system using Markov approach ［C］／／The Proceedings of International Conference on Quality，Reliability，Risk，Maintenance，and Safety Engineering，2012：112－116.

［10］Qiu Dishan，Tan Qun，Peng Li，et al.A modeling method of space－based information system taskflow based on scenario［C］／／Proceedings of International Colloquium on Computing，Communication，Control，and Management，2012：712－717.

［11］HU Xiaoliang.Task model－based user interface development［D］.Jinan：Shandong University，2008 （in Chinese）. ［胡曉亮.基于任務(wù)模型構(gòu)建用戶界面的研究 ［D］.濟南：山東大學，2008.］

［12］Fan Z Q，Yue T，Zhang L.SAMM：An architecture modeling methodology for ship command and control systems ［J］.Softw Syst Model，2014.http：／／link.springer.com／article／10.1007／s10270－013－0393－x.

［13］OMG.OMG systems modeling language （OMG SysML）Version 1.1 ［EB／OL］.http：／／www.omg.org／spec／SysML／1.1，2008.