基于任务场景的测试需求建模方法

徐 珞，石 晶，郝 博

（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.