蓝新生 封二强 郑 军
(中航工业综合技术研究所,北京 100028)
基于UML Testing Profile的软件测试过程浅析
蓝新生 封二强 郑 军
(中航工业综合技术研究所,北京 100028)
对软件测试过程的现状进行了分析,并对对象管理组织(Object Management Group,OMG)提出的测试建模标准(UMLTesting Profile,UTP)进行了简要介绍,对UTP的建模特点进行了分析,最后结合实例对UTP进行测试建模的有效性进行了说明。
UTP;软件测试;测试建模
软件测试是提高软件质量和可靠性的重要手段。随着软件规模的增大和复杂程度的提高,特别是攸关生命和财产安全的领域,如航空、航天、铁路、金融,医疗等领域,软件测试对提高软件质量和可靠性的作用愈发明显。
然而,软件开发人员、设计人员、测试人员通常使用不同的语言和工具,导致不同角色的交流和文档信息交换变得困难。
另一方面,目前软件测试工作主要还是通过手工方式来完成,软件测试的大部分时间都是用来进行测试文档的编写,由于测试存在分工,测试产品的非形式化表示容易造成不同的测试人员对同一测试产品产生不同的理解;测试产品的形式化可以有效地避免上述问题,也有利于测试的实施,但测试产品的形式化要求测试人员具有较高的专业知识和形式化能力,再加上测试项目紧张,形式化的测试产品表示往往是不允许的。
半形式化语言的出现,大大缓解了上述两种矛盾,如统一建模语言(United Modeling Language,UML),它提供了9种视图,可以从不同应用层次和不同角度为软件开发人员、设计人员、测试人员提供交流的途径,很好的避免了测试产品表示的不准确性、歧义性。
由于测试产品中往往存在着时间性能约束、测试结果等描述,而UML无法直接支持这些元素的测试建模,将UML引入软件测试领域,进行软件测试产品的表示,还需要进一步的拓展。
为了弥补UML测试建模能力的不足,OMG提出UTP测试建模标准[1],并分别于2005年7月、2012年4月和2013年4月发布了该标准的V1.0、V1.1、V1.2版本。UTP为用UML进行建模的系统提供用于系统结构和行为方面测试的确切定义。它可以支持测试相关的设计、可视化、规格说明、分析、构造以及文档化。
UTP是基于UML2. 0的测试建模语言,可以独立于UML使用,支持从单元测试到系统测试的各个级别的测试建模[2,3,4]。UTP可以进一步扩展并应用到多个领域,如远程通信、IT、航空航天等。
UTP从UML继承而来,具有与UML相同的建模特性,此外,UTP提供了4个逻辑概念对软件测试进行支持[5],即测试体系结构(Test Architecture);测试行为(Test Behavior);测试数据(Test Data);测试时间(Test Time)。测试体系结构指定了UTP的静态结构;测试行为指定了UTP的动态行为;测试数据是代表了贯穿UTP测试行为始终需要的数据;测试时间是对UTP测试行为的量化。
1.1 测试体系结构
测试体系架构定义了一组概念,用来描述测试系统的静态组成结构,主要包括测试上下文(Test Context)、测试结果判决器(Arbiter)、调度器(Scheduler)、被测对象(SUT)、测试组件(Test Component)等。
被测对象是一个待测的系统或者系统的行为。
测试上下文用来管理整个测试,包括测试组件和测试用例,以及测试的配置、测试控制等。
测试组件用于测试系统中与被测对象或其他测试组件进行交互,以完成某个测试行为。
测试结果判决器用于判断测试用例的执行是否通过。
调度器用来以启动、终止测试用例及动态创建测试组件。
1.2 测试行为
测试行为定义一组概念,来用来描述测试系统的行为,包括测试用例(Test Case)、测试目标(Test Objectives)、测试日志(Test Log)、测试结果类别(Verdict)等。
测试目标允许测试设计人员描述测试的目的。
测试用例作为测试上下文的一个行为,用来描述被测对象如何与测试组件进行交互以实现测试的目的。
测试日志用以记录在测试用例执行过程中的实体以便进行更深入的分析。
U T P共定义了4种测试结果类别:通过(Pass),测试行为和预期结果一致;失败(Fail),测试行为和预期结果不一致;错误(Error),测试系统本身存在错误或者异常;不可判定(Inconclusive),无法判定测试行为和预期结果的一致性。可通过测试结果判决器设置或者获取测试用例模型的测试结果类别。
1.3 测试数据
测试数据定义了一组概念,用以描述测试过程中使用的数据,主要包括数据池(Data Pool)、数据分区(Data Partition)、数据选择器(Data Selector)和编码规则(Coding Rules)。
数据池与测试上下文相关,包含数据分区与具体的数据值;数据分区用以定义一组划分测试数据的规则;测试选择器提供了不同的策略来选择和验证数据;编码规则允许用户定义测试数据的编码和解码规则。
1.4 测试时间
测试时间控制主要定义了两个概念,即定时器(Timers)和时区(Time Zone)。
时区用于描述各个测试组件的协调与同步问题(尤其在分布式测试中),并规定每个测试组件属于至多一个时区,在同一个时区中的测试组件具有同样的时间特性,即同步。定时器用于操作和控制测试行为以保证测试用例的终止。
关于UTP更详细的介绍可以参考OMG的UML 2.0 Testing Profile[6]。
在本节我们通过一个实例来对UTP的测试建模进行说明。以ATM系统为例,为了简要说明,假设与ATM系统交互的包含两部分:外部硬件设备HWEmulator和银行BankEmulator。
图1描述了AT M系统的测试上下文、测试组件,其中,测试上下文包含3个测试用例(validWiring、validPIN和authorizeCard)来描述ATM测试行为,测试组件HWEmulator和BankEmulator描述了测试的初始配置,包括各个组件与被测对象ATM的连接关系,其中测试组件BankEmulator包括两种类型的接口,需求接口(required interface)和供给接口(provided interface),其中供给接口IHardware描述了HWEmulator需要的接口,需求接口IATM描述了HWEmulator实现的接口。
图1 ATM测试上下文和测试组件
图2描述实例化了ATM及其测试组件,atm、be和hwe分别表示BankATM、BankEmulator和HWEmulator的实例,各测试组件通过各自的接口与ATM进行连接。
图2 ATM及其测试组件实例
为了提高UML模型表示的简洁性以及优化UML模型的结构,UML中引进了时序组合片段,如ref、alt、opt、par等,其中ref表示了引用其他地方定义的组合片段,alt表示在一组行为中根据特定的条件选择某个交互等,UTP完全继承了UML的这些建模特性。图3使用了两个ref组合片段来描述测试用例invalidPIN和validWiring的执行顺序,即当测试用例invalidPIN执行通过时才能执行测试用例validWiring。
图3 ATM系统测试用例执行顺序
图3中测试用例invalidPIN的测试目的是验证ATM是否插入有效的银行卡,以及在输入错误的PIN码后是否立即提醒用户重新输入密码。图4利用顺序图对invalidPIN的行为进行描述,并使用定时器t1来对插入有效的银行卡后硬件显示端提示用户输入银行卡PIN码的时间进行约束,即在用户插入有效的银行卡后ATM必须2s内提示用户输入PIN码。
图4 invalidPIN测试用例
图4的最后表明当向ATM输入错误的PIN码后,ATM向硬件显示终端发送重新输入PIN码的消息,则通过测试。
在本节中我们通过实例简单介绍了UTP的基本概念和建模过程。值得说明的是,UTP测试可以支持从单元测试到系统测试各个级别的测试建模。
本文介绍了软件测试的现状和UTP产生的背景,并对UTP的概念和建模的特点进行介绍和分析。随着诸如GJB/Z 141-2004《军用软件测试指南》和GJB 2725-1996《校准实验室和测试实验室通用要求》等标准的出现,软件测试过程日趋成熟。UTP在UML的基础上进行扩展,可以有效的复用开发阶段的UML模型,提高了软件测试建模的能力,大大提高了软件测试过程阶段产品的规范化。
与UML类似,UTP也是与平台无关的,即UTP表示的软件测试模型可以在不同的平台之间复用,大大提高了测试产品的可移植性。
此外,UTP表示的软件测试产品可以进一步转换成可扩展标记语言(Extensive Markup Language,XML)或基于XML的元数据交换(XML Metadata Interchange,XMI)形式,通过对XML或XMI测试模型信息的提取,可实现后续测试产品的自动生成。
目前,已有一些学者研究了UTP概念与其他可执行测试脚本之间的转换关系,如Java单元测试框架JUnit[7]和树表结合表示法(Tree And Tabular Combined Notation,TTCN)[8,9],进一步提高了软件测试的自动化程度。
[1] 黄陇,杨宇航. 面向Web Services的UTP测试模型扩展[J]. 计算机科学, 2010(09): 第135-136+ 176页.
[2] Donglin, L. and X. Kai. Test-Driven Component Integration with UML 2.0 Testing and Monitoring Profile[C]. Proceedings of 2007 Seventh International Conference onQuality Software,2007: 32-39.
[3] Lamancha, B.P., M.P. Usaola and M.P. Velthius. Towards an automated testing framework tomanage variability using the UML Testing Profile[C]. Proceedings of 2009 ICSE Workshop on Automation of Software Test, 2009: 10-17.
[4] L, P.R., S. B and X. PULEI.Framework testing of web applications using TTCN-3[J]. International International Journal on Software Tools for Technology Transfer,2008:371-381.
[5] 刘冬懿. 从UML设计模型到测试模型的研究[J].计算机应用研究, 2007, 24(5):56-59.
[6] OMG ptc/04-04-02:UML 2.0 Testing Profile, Finalized Specification[S].
[7] Palacios, F. and C. Pons. A tool for automatic generation of executable code from testing models[C]. Proceedings of the 22nd IFIP ICTSS, 2010:47-54.
[8] 梁曦, 魏仰苏. UML2.0 Testing Profile到TTCN-3的映射研究[J]. 杭州电子科技大学学报, 2007(4):第17-21页.
[9] Baker, P. and C. Jervis. Early UML Model Testing using TTCN-3 and the UML Testing Profile[C]. Proceedings of Testing: Academic and Industrial Conference on Practice and Research Techniques - MUTATION (2007TAICPART-MUTATION), 2007: 47-54.
(编辑:雨晴)
T–65
C
1003–6660(2015)04–0049–04
10.13237/j.cnki.asq.2015.04.014
[收修订稿日期] 2015-05-13