基于任務場景的測試需求建模方法

徐 珞，石 晶，郝 博

（1.華北計算技術研究所，北京100083；2.中國電子設備系統工程公司研究所，北京100141）

0 引 言

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

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

1 TreBts概念模型

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

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

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

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

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

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

SubTask＝ （fatherTask，sonTask）

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

定義4 一個原子任務AtomTask關聯一個或多個Interaction，以描述多類用戶和SUT在任務執行過程中的交互過程，可表示為一個二元組

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

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

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

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

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

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

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

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

2 TreBts視圖與建模指南

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

2.1 TreBts視圖

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

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

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

（3）任務規劃視圖：描述任務分解視圖中每類用戶的原子任務之間的執行順序。

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

表1 概念模型中的元素

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

表2 一致性和完整性規則

2.2 建模過程指南

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

圖1 建模過程指南

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

3 基于TreBts模型的測試流程

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

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

步驟2 針對每類用戶，從任務規劃視圖中獲取該用戶的開始時間和結束時間。

步驟3 針對每類用戶，在測試執行過程中，從任務規劃視圖中獲取動態變化的并發用戶數。

步驟4 針對每類用戶，從任務規劃視圖中依次讀取一個任務，包括該任務的cycle和delay屬性。同時，獲取該任務對應的交互場景視圖以產生測試用例和相關的測試數據。

步驟5 開始執行測試。根據步驟4獲得的測試用例和數據以及步驟3獲得的并發用戶數開始執行測試。

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

4 實驗案例

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

4.1 選擇被測系統

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

圖2 SUT業務流程模型

4.2 建立TreBts模型

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

4.2.1 任務分解視圖

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

圖3 任務分解

4.2.2 交互場景任務

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

圖4 水文數據注冊交互場景

4.2.3 任務規劃視圖

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

圖5 任務規劃

圖6 三類用戶的并發用戶數

4.3 測試執行

在用三類視圖描述完測試需求后，采用第3節提出的測試流程產生測試套，包括測試用例和測試數據，并執行測試。

4.4 測試結果分析

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

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

表3 功能測試結果

（2）性能測試分析：從圖6中可以看到氣象數據提供者的并發數從0增長到120，系統響應時間從0.02s變到0.1s，且穩定在0.1s；同樣地，隨著執行時間的增長，系統響應時間隨著并發用戶數的變化而減少。

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

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

5 結束語

本文提出了TreBts模型來同時描述功能、性能和可靠性測試需求。在建立了TreBts概念模型之后，設計了三類視圖來表示模型中的元素和關系，同時給出了建模應用指南來輔助測試人員建立三類視圖。另外，本文提出了基于TreBts的測試流程來指導測試人員開展測試。典型實驗結果表明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）.［趙曉嵐.規范化軟件測試過程淺析 ［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］.北京：國防工業出版社，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）. ［胡曉亮.基于任務模型構建用戶界面的研究 ［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.