《电子技术应用》
您所在的位置:首页 > 通信与网络 > 设计应用 > 基于Wright的SA级测试路径生成方法
基于Wright的SA级测试路径生成方法
来源:微型机与应用2011年第8期
徐士华1 ,赵 磊2 ,吕莉媛3
(1. 黑龙江司法警官职业学院, 黑龙江 哈尔滨 150060;2. 哈尔滨师范大学 现代实验中心,
摘要: 软件体系结构用来描述系统的高层结构和行为特征,软件体系结构描述语言ADLs是对软件体系结构的形式化描述。在软件体系结构描述语言Wright的基础上,引入了一种图形的表示方法,即以动态行为图(BG图)来表示相关的构件间的动态行为及它们之间的关系,并提出了软件体系结构测试覆盖准则。根据BG图中路径的定义,给出了BG图中测试路径生成算法的基本思想。以C/S体系结构为例,验证了该方法在生成SA级的测试路径上是可行的。
Abstract:
Key words :

摘  要: 软件体系结构用来描述系统的高层结构和行为特征,软件体系结构描述语言ADLs是对软件体系结构的形式化描述。在软件体系结构描述语言Wright的基础上,引入了一种图形的表示方法,即以动态行为图(BG图)来表示相关的构件间的动态行为及它们之间的关系,并提出了软件体系结构测试覆盖准则。根据BG图中路径的定义,给出了BG图中测试路径生成算法的基本思想。以C/S体系结构为例,验证了该方法在生成SA级的测试路径上是可行的。
关键词: 软件体系结构; 软件测试; 测试路径; 动态行为图; 测试覆盖准则

    利用软件体系结构模型来指导测试是目前软件测试的一个重要研究领域。依据参考文献[1]的定义,SA基本组成元素包括构件、连接件、配置和约束。构件是一个计算单元或一个数据存储单元;连接件是体系结构中的“粘合剂”,用于建模构件间交互并定义交互规则;配置是一种拓扑结构,用来描述系统中的构件与连接件之间的关系;约束是关于系统或其一部分性质或断言。
    软件体系结构描述语言ADLs从不同方面对软件体系结构进行规约和建模分析,是对软件体系结构的形式化描述。典型的ADL包括UniCon、Rapide、Darwin、Wright、C2 SADL、Acme、xADL、XYZ/ADL和ABC/ADL等[2]。
    目前软件体系结构测试主要集中在建立测试抽象模型及体系结构动态特征的提取。Jin Zhenyi和OFFUTT J用Wright语言描述软件体系结构,生成基于ICG图和BG图的测试用例[3]。ROBERT A[4]引入体系结构描述语言Wright,为描述和分析软件体系结构和结构类型提供一种有效方式。BERTOLINO A[5]等人提出利用化学抽象机形式化描述SA,定义了基于化学抽象机的模型和测试覆盖准则,由此导出基于结构描述的测试计划。ABDURAZIK A等人针对软件体系结构描述,提出了通用的体系结构测试覆盖准则[6]。ROSENBLUM[7]提出基于构件的软件测试理论,指出这种技术在综合层要优于结构层,同时也依赖于执行的完整性。
    本文提出一种基于Wright的新技术。以Client/ Server体系结构的Wright描述为模型,提出了相应的测试覆盖准则,生成此结构的动态行为图以及相应的测试路径,文中还给出了基于此结构的测试路径生成算法的基本思想。

 


1 Wright和BG图
1.1 Wright

    Wright是一种通用的软件体系结构描述语言,它对体系结构中构件、连接件以及它们之间的一组约束进行形式化描述,为体系结构配置和体系结构风格的描述提供实用的形式化基础。Wright中构件间的行为及合作是利用CSP中的符号来指定的。CSP中,确定构件间行为以及交互模式的符号主要包括:事件e、进程P、e?x表示进程接收数据x、e!x表示进程输出数据x、§表示系统成功终止、e→P表示进程首先执行事件e然后启动进程P、□表示外部选择(选择由外部环境决定)、∏表示内部选择(选择由进程自身决定);表示按顺序连接两个进程。下面以Client/Server体系结构为例,给出该结构的Wright描述:
Component Client
    Port Service=ClientPullT
     Computation=Service.open;UseOrExit
    where UseOrExit=UserService∏ExitUseService=Service.
        request→Service.result?y→UseOrExit
     Exit=Service.close→§
Component Server
     Port Provide=ServerPushT
     Computation=WaitForClient□Exit§
    where WaitForClient=Provide.open→Provide.request→
        Provide.result?x→WaitForClient
     Exit=Provide.close→§
Connector C-S Connector
     Role Client=ClientPullT
     Role Server=ServerPushT
    Glue=Client.open→Server.open→Glue□Client.close→
        Server.close→Glue□Client.request→Server.request→
        Glue□Server.result?x→Client.result!x→Glue□§
Type ClientPullT=open→Operate∏§
    where Operate=request→result?x→Operate∏Close
    Close=close→§
Type ServerPushT= open→Operate□§
    where Operate=request→result!x→Operate□Close
     Close=close→§
Instances
c: Client
s: Server
cs: C-S Connector
Attachments:
c provides as cs.c
s provides as cs.S
end
1.2 动态行为图(BG图)
    Wright给出了构件、连接件及其接口的行为描述,以及它们之间是如何工作的,为在测试中反映这些信息,本文引入一种新型的图形表示方法,即BG图(Behavior Graph),表示构件间和它们之间连接的接口行为信息。BG图主要基于Petri网理论[8],同时在Petri网理论中增加了外部选择和内部选择信息。
    定义1 构件间动态行为图BG=(COMPi(Pn1,Tn1, In1,On1),COMPj(Pn2,Tn2,In2,On2),Pc,Tc,Ic,Oc),其中 COMPi、COMPj分别是对构件Ni、Nj的描述;Pn是构件N的库所集,Tn是变迁集,In是输入弧集,On是输出弧集;Pc是两个构件间的库所集;Tc是两个构件间的变迁集且Pn1∩Pn2∩Pc=Φ,Tn1∩Tn2∩Tc=Ic是两个构件间库所到变迁弧的集合,Ic:({Pni,Pnj,Pc}×{Tni,Tnj,Tc})→{0,1},该值为1表明构件i的库所到构件j的变迁有弧存在;否则构件i的库所到构件j的变迁没有弧存在;Oc是两个构件间变迁到库所弧的集合,Oc:({Tni,Tnj,Tc}×{Pni,Pnj,Pc})→{0,1},该值为1表明构件i的变迁到构件j的库所有弧存在;否则构件i的变迁到构件j的库所没有弧存在。
    从C/S结构的Wright描述转换到该结构的BG图可以根据已有的理论[9],图1给出了与Wright描述相对应的C/S结构的BG图。C/S结构遵循如下规则:

    Client端或初始化进程与Server端建立连接client.open,或什么也不做结束进程client.§1,一旦连接建立,Client端向Server端发送请求client.request,Server端打开与Client端建立的连接。当Server端接收来自Client端的请求server.request时,Server端向Client端返回请求结果server.result!x;然后Server端等待Client端发送更多请求;当Client端接收到自Server端的请求结果client.result?x,Client端可以向Server端发送更多的请求,也可关闭连接client.close。如果Client端关闭连接,迫使Server端也关闭连接、结束进程。
    设COMP1为Client component,COMP2为Server component,根据定义1有:
    BG=(COMP1(Pn1,Tn1,In1,On1), COMP2(Pn2,Tn2,In2,On2),Pc,Tc,Ic,Oc)
Client:
Pn1={(client.p0,client.p1,client.p2,client.p3,client.p4,client.p5)}
Tn1={(client.open,client.request,client.result,client.close,client.
    §1,cleint.§2)}
In1={(client.p0,client.open),(client.p1,client.request),(client.p2,
    client.result),(client.p1,client.close),(client.p0,client.§1),
    (client.p4,client.§2)}
On1={(client.open,client.p1),(client.§1,client.p3),(client.
    request,client.p2),(client.result,client.p1),(client.§2,client.
    p5),(client.close,client.p4)}
Server:
Pn2={(server.p0,server.p1,server.p2,server.p3,server.p4,server.
    p5)}
Tn2={(server.open,server.request,server.result,server.close,server.
    §1,server.§2)}
In2={(server.p0,server.open),(server.p1,server.request),(server.
    p2,server.result),(server.p1,server.close),(server.p4,server.
    §2),(server.p0,server.§1)}
On2={(server.open,server.p1),(server.request,server.p2),(server.
    result,server.p1),(server.§1,server.p3),(server.close,server.
    p4),(server.§2, server.p5)}
Pc={p101,p102,p103,p104}
Tc={}
Ic={(p101,server.open),(p102,server.request),(p103,server.close),
    (p104,client.result)}
Oc={(client.open,p101),(client.request,p102),(server.result,p104),
    (Client.close,p103)}
2 软件体系结构测试覆盖准则
  为了有效地产生测试用例,需要定义一组体系结构层的测试覆盖准则。具体可定义以下六种测试覆盖准则:
  (1)构件(连接件)内部传递关系覆盖准则:软件体系结构中所有构件(连接件)接口间内部数据流或控制流关系至少分析一次。
  (2)构件(连接件)内部顺序关系覆盖准则:软件体系结构中所有构件(连接件)接口间行为应遵循某些必要的执行规则至少分析一次。
  (3)构件-连接件关系(连接件-构件关系)覆盖准则:软件体系结构中所有构件(连接件)接口与对应的连接件(构件)接口间存在的关联关系至少分析一次。
  (4)直接构件关系覆盖准则:软件体系结构中构件-连接件关系、连接件-构件关系和连接件内部关系至少分析一次。
  (5)间接构件关系覆盖准则:若构件Ni和构件Nj(i≠j)间存在非直接关联路径,则该路径至少分析一次。
    (6)全连接构件覆盖准则:若存在全连接构件路径N1-C1-…-Ct-Ns,则该路径N1-C1-…-Ct-Ns至少分析一次。
3 基于BG图的测试路径生成方法
3.1 B-路径生成算法

    根据BG图可以给出以下关于测试路径的定义:
    定义2 BG图中的路径:一条BG图中的路径是由k个库所(迁移)的节点和k-1条弧构成,对于整数k,第i条弧或者连接第i个节点到第i+1个节点或者连接第i+1个节点到第i个节点。
    定义3 构件内部行为路径(B-路径):在一个构件接口的子网内,它起始于开始库所,终止于结束库所,当在子网内存在环时,在每条B-路径中,有且只有一个环存在。每个库所(变迁)在每条B-路径中最多被访问两次。
    定义4 构件连接路径(C-路径):C-路径通过两个构件子网A和B,它起始于构件子网A的一个库所,终止于构件子网B的一个库所,在软件体系结构的上下文中,两个构件之间的连接通常都是从一个构件的迁移到另一个构件的迁移。
    下面以B-路径为例,给出BG图中B-路径的生成算法,在算法中,将图中的库所和迁移都统一归为节点,由于B-路径是找到一个构件内部的所有路径,因此可以将两个构件间的库所和迁移先忽略掉,而只考虑一个构件内部的所有库所和迁移,以下给出B-路径的生成算法:
    (1)首先定义两个数组set1和set2,并使之为空,初始化节点p0使之为初始节点,初始化节点pf使之为终止节点(终止节点可不唯一)。
    (2)从初始节点p0向下搜索,找到所有与p0直接相连的边((p0→pi),(p0→pj)…),同时修改数组set1,将每条路径分别存入数组set1中(即将路径(p0→pi),(p0→pj)…分别存入数组中的每个元素)。当数组set1不为空时,作:
    ①对数组set1中的每条路径Ci(i=0,1…)进行检查,如果路径Ci的最后一个节点为pf,则将Ci存入数组set2中,同时将其从数组set1中删除。否则作:
    ②对数组set1中的每条路径Ci(i=0,1…)进行检查,如果路径Ci中某个节点出现的次数大于等于3,则将其从数组set1中删除。否则作:
    ③沿路径Ci中的最后一个节点pk继续向下搜索,找出与pk节点直接相连的路径((pk→pr),(pk→pq)…),并将其与路径Ci进行连接,即将与pk节点直接相连的路径连接到Ci的后面((p0…→pk→pr)(p0…→pk→pq)…),并分别存入数组set1中,同时将Ci从set1中删除。
    (3)算法结束
    最终,数组set2中存放的所有路径就是一个构件内部的所有B-路径,然后根据得到的该构件内部的B-路径设计测试用例的输入和预期输出。
    根据B-路径生成算法,可以分别得到C/S结构中Client构件和Server构件的B-路径,从而完成对两个构件内部的测试。以下给出了Client构件中的B-路径:
    ①client.p0-client.open-client.p1-client.request-client.p2-client.result-client.p1-client.close-client.p4-client.§2-client.p5
    ②client.p0-client.§1-client.p3
    ③client.p0-client.open-client.p1-client.close-client.p4-client.§2-client.p5
    根据路径覆盖准则,覆盖以上三条路径就可以完成对Client构件内部进行的测试,同理可以得到Server构件的内部行为路径。
3.2 C-路径生成算法
    B-路径生成算法只能对构件内部进行测试,当需要对两个构件间进行测试时,就需要找到连接两个构件间的所有路径,即找到BG图中的C-路径。以下给出BG图中C-路径生成算法的基本思想。
  首先找到连接两个构件的所有库所(迁移),对找到的每一个库所(迁移)向前搜索直到找到它的前一个库所为止,对找到的每一个库所(迁移)向后搜索直到找到它的后一个库所为止,同时记录所经过的路径,即可生成BG图中的所有C-路径。以下给出了C/S结构中的所有C-路径:
  ①client.p0-client.open-p101-server.open-server.p1
    ②client.p1-client.request-p102-server.request-server.p2
  ③server.p2-server.result-p104-client.result-client.p1
  ④client.p1-client.close-p103-server.close-server.p4
    将以上两种算法生成的路径结合在一起,就可以完成对C/S结构的集成测试,根据定义的测试覆盖准则,生成整个BG图中的所有测试路径,然后根据生成的测试路径,设计测试用例的输入和预期的输出结果,从而完成对C/S结构的测试工作。
    实例证明这种基于软件体系结构的测试路径生成方法在生成测试路径上是可行的,下一步工作将主要集中在根据生成的测试路径设计相应的测试用例。
参考文献
[1] SHAW M, GARLAN D. Software architecture:perspectives on an emerging discipline.Prentice Hall,1996
[2] 梅宏, 申峻嵘.软件体系结构研究进展[J].软件学报, 2006,17(6):1257-1275.
[3] Jin Zhenyi, OFFUTT J. Deriving tests from software architectures[C].12th International Symposium on Software Reliability Engineering,Hong Kong,2001:308-313.
[4] ROBERT A. A formal approach to software architecture. carnegie mellon university.CMU Technical Report CMUCS-97-144,1997(5).
[5] BERTOLINO A. Deriving test plans from architectural  descriptions.In:ACM Proc.Int.Conf.on Software Engineering  (ICSE2001),2000,6:220-229.
[6] ABDURAZIK A, Jin Zhenyi, OFFUTT A J, et al. Analyzing software architecture descriptions to generate systemlevel tests.http://www. ics.uci.edu/~djr/rosatea/attendees.html.
[7] DAVID R. Adequate testing of component based software. department of information and computer science, University of California,Irvine,Technical Report UCI-ICS-97-34, 1997,8.
[8] ROZENBERG G, THIAGARAJAN P S. Petri nets: Basic  notions, structure and behavior. Lecture Notes in Computer  Science,224. Berlin: Springer, 1986:585-668.
[9] Allen Robertand Garlan D. A case study in architectural modeling: The AEGIS System. In Proceedings of Eighth International Conference on Software Specification and Design (IWSSD-8),Paderborn,Germany, 1996(3).

此内容为AET网站原创,未经授权禁止转载。