测试需求是测试设计和实施的前提,也是航天器自动化测试的基础.测试需求描述规范与否成为影响测试质量的重要环节.为此,采用有效的方法规范化测试需求描述一直以来是航天器自动化测试技术的研究重点.
由于航天器结构复杂,当前测试需求庞杂,测试需求主要通过专业测试人员根据经验生成,与业务结合紧密,编制不规范且完全凭专业测试人员的经验,测试需求编写采用自然语言编写,测试需求复用性不高,内容易出现遗漏,造成测试需求的不完备,特别是当前的航天器并行批产化测试模式,无疑增加了测试人员的工作负担及时间开销,同时增加了航天器的研制成本,如何给出测试需求的描述规范,如何给出测试需求的自动生成方法是解决这一问题的有效途径.
现有的测试需求描述方法主要有基于IEEE P1598标准的TeRM(Test Requirements Model)方法、基于ATML标准的测试需求描述方法、基于UML的测试需求建模方法[9].其中,TeRM标准由于其通用性较差,其应用越来越少;基于ATML标准的测试需求描述方法,主要是基于XML,采用IEEE 1671.1标准,可以完整地描述UUT(Unit Under Test)测试需求,能在一定程度上提高测试需求的重用性和通用性[10, 11],但是当前航天器测试是系统级测试,该方法难以应用到航天器测试需求描述中;基于UML的测试需求建模方法应用相对较广,适用于从需求建模到系统测试建模的不同阶段,但是针对描述测试需求来讲,目前UML的现有语法还不能完整地描述测试需求,还需对UML进行扩展才能使用,文献[12]采用UML状态图,提出一种实时嵌入式软件系统测试需求建模方法,虽具有一定的借鉴意义,但是仍然不能完整描述测试需求,描述能力有限.此外,基于场景的测试方法近年来成为研究的热点,现有文献将研究重点放在采用UML模型对测试场景进行建模,在此基础上研究测试用例的自动生成[13, 14, 15].文献[15]采用模型驱动思想,以测试需求描述互操作性测试需求,以状态图描述被测应用的规格说明,给出了一种互操作性测试用例生成方法,该文献描述的基于用例的测试需求描述具有很好的借鉴意义,可用来描述给定的测试场景.文献[16]对卫星测试需求的规范化描述进行了相关研究,总结测试指令或操作类型,给出卫星测试需求模板,其工作侧重于卫星测试需求模板的程序自动解析为测试序列,和具体卫星型号紧耦合,其方法具有局限性.因此,现有方法不能解决航天器测试需求描述及其自动生成问题.
本文针对航天器功能性测试需求描述及自动生成方法展开研究,为支持通用性和开放性,基于航天器组织结构,采用形式化方法[17, 18, 19, 20, 21]对航天器组织结构建模,结合航天器测试过程业务特点,从航天器静态测试和动态测试任务流程两个方面,给出航天器功能性测试需求描述规范及自动生成方法,并采用函数式语言Haskell[22, 23]给出了航天器测试需求生成方法的具体实现.本文所提出的航天器测试需求自动生成方法能有效实现航天器测试需求规范化描述及其自动生成,有效提高航天器测试需求生成效率,并支持后续航天器测试用例的自动生成,本文还设计实现航天器测试需求自动生成应用系统,该系统应用较好.
1 航天器形式化建模1.1 航天器组织结构及测试过程航天器测试需求是测试大纲的细化,描述了航天器各个分系统、航天器整个飞行过程至完成的测试内容,与航天器组织结构及测试过程关系密切,航天器组织结构及测试过程如图 1所示.图 1
Fig. 1
 | 图 1 航天器组织结构及测试过程示意图 Fig. 1 Schematic diagram of spacecraft organization structure and test process |
航天器这类复杂系统的不同组织结构具有相似性,通常由多个分系统组成,每个分系统又由多个功能部件组成,各个不同的功能部件有其相应的部件操作;航天器测试过程涉及航天器测试系统、测试设备及被测航天器三端间的交互.测试过程中,设计的测试用例通过航天器测试系统发送至测试设备中的主测试服务器MTP(Master Test Processor),MTP接收到测试用例后进行解释执行,然后通过专用测试设备SCOE向指定的测试设备发送设备操作指令,产生被测航天器部件操作指令或激励,航天器收到相应操作指令或激励后改变自身状态参数并进行反馈,测试用例通过获取指定的测试参数取值进行评估以完成航天器测试[1, 2, 24].可见,航天器组织结构和测试设备是驱动测试需求生成的前提条件.航天器自动化测试包括测试用例自动生成和航天器测试过程的自动化,测试需求是测试用例生成的依据,测试用例是航天器自动化测试过程中的交互主体.因此,测试需求描述的规范化对实现航天器自动化测试起着至关重要的作用.
1.2 航天器形式化表示在航天器组织结构中,航天器测试需求与航天器的组织结构、测试设备密切相关.为了抽象三者之间的关系,并与具体航天器测试业务解耦合,首先有必要给出航天器的形式化表示,抽象航天器组织结构.将航天器组织结构从层次化的角度划分为4级,分别是系统级、分系统级、组件级及组件操作级.其中,组件包括设备和功能部件,相应地,组件操作也分为设备操作和部件操作;每个组件有其自己唯一的功能且能被多次重用;分系统由多个功能部件集成完成某一功能的应用且通过测试设备驱动完成测试;而系统则由多个分系统组成.
定义1 航天器SpacecraftId=(SpacecraftName,SubsysIdSet).
其中:SpacecraftName为航天器型号名称;SubsysIdSet为分系统集合,其定义为
SubsysIdSet=set of SubsysId
SubsysId=(SubsysName,DevSet,ComSet)
其中:SubsysName为分系统名称；DevSet为分系统的设备集合；ComSet为分系统的功能部件集合,下面分别给出DevSet和ComSet的形式化定义.
DevSet=set of Dev
Dev=(DevName,DevOpSet)
DevOpSet=set of DevOp
DevOp=(DevOpId,DevOpParam)
其中:Dev为具体设备,由设备名称DevName和设备操作集DevOpSet组成,设备操作集DevOpSet是设备操作DevOp的集合,Op由设备操作标识和设备操作参数组成.
ComSet=set of Com
Com=(ComId,ComOpSet)
ComOpSet=set of ComOp
ComOp=(ComOpId,ComOpParam)
其中:Com为具体功能部件,由功能部件名称ComName和功能部件操作集ComOpSet组成;部件操作集ComOpSet为部件操作ComOp的集合,部件操作ComOp由部件操作标识ComOpId和部件操作参数ComOpParam组成.
1.3 航天器任务流程描述在航天器测试过程中,首先对各个分系统及地面设备进行测试,检查各个分系统的设备是否齐备、功能部件功能是否正常、参数指标是否符合需求及各个分系统的指令或操作功能是否完好.在进行各个分系统检查时,一般要从地面设备启动开始,依次进行航天器加电、飞船功能部件初始化、分系统指令或操作使能检查、飞船断电等几个主要阶段.
完成静态测试基本任务后,在确保设备及各个分系统功能部件及指令操作功能都正常的情况下,还需进行模飞测试.在模飞测试过程中,主要通过各个分系统的各个功能部件间的相互协作完成航天器起飞过程的测试,主要包括正常模式模飞和故障模式模飞测试,其中正常模式模飞包括发射段、运行段、返回段及回收着陆段,故障模式模飞测试指根据起飞时间及可能遇到的故障而启动相应的救生程序以避免出现事故,救生程序有多种.
据此,可将航天器起飞前的测试过程看做航天器静态测试任务流程,主要包括地面设备检查、飞船功能部件初始化检查、设备操作指令使能和除能检查、部件操作指令使能和除能检查;将航天器模拟飞行测试过程看做航天器动态测试任务流程,包括正常模式和故障模式.
航天器静态测试任务流程包括设备检查、功能部件初始化检查、设备操作指令检查和功能部件操作指令检查4个方面.若用StaticCheck表示航天器静态测试需求,DevInspec表示设备检查测试需求,ComInitStaInspec表示功能部件初始化检查测试需求,DevOperInspec表示设备操作指令检查测试需求,ComOperInspec表示部件操作指令检查测试需求,则航天器静态测试需求由这4部分组成:
StaticCheck={DevInspec,ComInitStaInspec,DevOperInspec,ComOperInspec}.
航天器静态测试需求的抽象表示将根据静态测试任务流程,分别给出设备检查测试需求、功能部件初始化检查测试需求、设备操作指令检查测试需求和部件操作指令检查测试需求的具体形式表示,其具体定义将在2.1节给出.
从航天器的动态流程中可以看出,主要是由测试操作指令按照相关业务逻辑组成的动态流程.由于重用性,很多业务逻辑会重复使用某些若干测试指令组成的测试指令序列.为了提高复用性,可将这些重复使用的测试指令序列封装为指令链.因此,航天器动态测试需求即是由这些测试指令及指令链按照业务逻辑复合而成,具体测试指令和指令链的形式表示将在2.2节给出.
2 航天器测试需求形式化表示2.1 航天器静态测试需求形式化表示定义2 设备检查测试需求DevInspec=DevCheck(型号名称,分系统名称,设备集).
例如,devCheck(“神舟十号”,“数管分系统”,{“数管前端”,“供配电前端”,“测控前端”,“总控设备”,“并联网”,“对接总线模拟器”})表示检查神舟十号飞船的数管分系统的数管前端、供配电前端、测控前端、总控设备及对接总线模拟器等设备是否都齐备.
定义3 功能部件初始化状态检查测试需求ComInitStaInspec=ComInitStaCheck(型号名称,分系统名称,部件信息).
部件信息=(部件名称,部件参数集)
部件参数=(参数名,部件状态,参数指标)
部件状态=“连接”|“断开”|“加电”|“切电”|“断电”|“开机”|“关机”
例如,ComInitStaCheck(“神舟十号”,“数管分系统”,(DCA,{(V01,“Power”,“>3.5V”)}))表示检查神舟十号飞船数管分系统中的数传复接器A机加电后,其参数V01取值是否大于“3.5V”.
在航天器测试过程中,航天器设备操作和部件操作通过测试指令操作来实现,因此航天器设备操作和部件操作分别通过设备操作指令和部件操作指令实现,下面分别给出设备操作指令检查和功能部件操作指令检查测试需求的形式定义.
定义4 设备操作指令检查测试需求DevOperInspec=设备操作指令使能检查DevOperEnaCheck(型号名称,分系统名称,设备名称,设备操作指令标识)|设备操作指令除能检查DevOperUnEnaCheck(型号名称,分系统标识,设备名称,设备操作指令标识).
设备操作指令检查包括设备操作指令使能和除能检查,指令使能是指将禁止使用的指令转为可用的指令,指令使能后,该指令操作有效;指令除能是指将允许使用的指令转为禁止使用的指令,指令除能后,该操作指令无效.例如,DevOperEnaCheck(“神舟十号”,“测控与通信分系统”,“数管前端”,“K1”)表示将神舟十号飞船测控与通信分系统的数管前端设备操作指令K1使能;DevOperUnEnaCheck(“神舟十号”,“测控与通信分系统”,“数管前端”,“K1”)表示将神舟十号飞船测控与通信分系统的数管前端设备操作指令“K1”除能.
定义5 部件操作指令检查测试需求ComOperInspec=部件操作指令使能检查ComOperEnaCheck(型号名称,分系统名称,部件名称,部件操作指令标识)|部件操作指令除能检查ComOperUnEnaCheck(型号名称,分系统名称,部件名称,部件操作指令标识).
部件指令操作检查包括部件指令使能和除能检查,例如,ComOperEnaCheck(“神舟十号”,“数管分系统”,“DCA”,“B2”)表示将神舟十号飞船数管分系统的数传复接器A机操作指令“B2”使能检查;ComOperUnEnaCheck(“神舟十号”,“数管分系统”,“DCA”,“B2”)表示将神舟十号飞船数管分系统的数传复接器A机操作指令“B2”除能检查.
2.2 航天器动态测试需求形式化表示根据航天器动态测试任务流程的描述可知,航天器动态测试需求主要是针对航天器模飞测试而言的,若将航天器模飞测试过程中的不同模式下的各个测试阶段或测试过程看做不同的测试场景,则可采用场景技术对其进行建模,以刻画航天器动态测试需求.
因此,本文中根据航天器动态测试任务流程,将航天器动态测试需求划分为正常模式和故障模式下的测试场景.其中,正常模式测试场景包括发射段、运行段、返回段及回收着陆段测试场景;故障模式测试场景包括救生场景1,救生场景2,…,救生场景n.为保证本文给出的测试场景能完整且充分地刻画航天器动态测试需求,文中根据实际航天器测试业务流程,给出了航天器动态测试场景架构图,如图 2所示,该架构覆盖了所有航天器动态测试需求.
 |
| 图 2 航天器动态测试场景架构图Fig. 2 Architecture diagram of spacecraft dynamic test scenarios |
| 图选项 |
为实现动态构造各个测试场景,本文采用UML中的用例图模型刻画测试场景,以中继终端加电测试场景为例,其用例模型如图 3所示.
 |
| 图 3 中继终端加电场景示意图Fig. 3 Scenario schematic diagram of relay terminal with electricity |
| 图选项 |
从图 3中可以看出,中继终端加电测试场景中实际包含6个指令操作,若将这6个指令操作形成的指令操作序列封装为一条指令链,则该指令链就能完整描述中继终端加电测试场景,即能描述中继终端加电测试需求.采用测试场景描述测试需求,基于用例图描述测试场景,并由用例图映射为指令链,最终完成由指令链完整刻画航天器动态测试需求.下面分别给出测试操作指令和指令链的具体形式定义.
在航天器测试中,测试指令分为设备操作指令和部件操作指令,设备操作指令指的是设备操作的具体实现,部件操作指的是部件操作的具体实现,下面给出测试操作指令的形式表示.
定义6 测试操作指令=设备操作指令|部件操作指令.
设备操作指令=(型号名称,分系统名称,设备操作标识,设备操作参数,设备操作发送设备,发送次数,指令执行时间约束).
部件操作指令=(型号名称,分系统名称,部件操作标识,部件操作参数,部件操作发送设备,发送次数,指令执行时间约束).
即TestInsId=DevInsId|ComInsId
DevInsId=(SpacecraftName,SubsysName,DevOpId,DevOpPara,DevInsToDes,Times,DevInsTimeRestri)
ComInsId=(SpacecraftName,SubsysName,ComOpId,ComOpPara,ComInsToDes,Times,ComInsTimeRestri)
例如,(“神舟十号”,“测控与通信分系统”,“K1”,“Vs66＜=1&&Vs67>=-1”,“TCF”,1,2)表示神舟十号测控与通信分系统中指令“K1”发送目的地为“TCF”即遥测前端,判读参数为“Vs66＜=1&&Vs67>=-1”,该指令发送1次,且执行时间约束为2s.
指令链是由测试操作指令组成的序列,其定义如下.
定义7 指令链TestInsLink=(型号名称,测试模式,指令链标识,指令链).
测试模式=正常模式|故障模式
其中：正常模式包括发射段、运行段、返回段及回收着陆段；故障模式下对应多种相应的救生程序.
指令链是一条测试操作指令序列,其内部还可嵌套指令链,也可以是一条测试操作指令,即
指令链=测试操作指令|测试操作指令::测试操作指令序列|测试指令链::测试操作指令操作序列.
即TestInsLink=(SpacecraftName,TestMode,TestInsLinkId,TestInsList)
TestMode=NormalMode|FailureMode
TestInsList=TestInsId|TestInsId::TestInsList|TestInsLinkId::TestInsList
3 航天器静态测试需求生成方法基于航天器静态测试需求形式化表示,下面给出航天器静态测试需求自动生成方法.
3.1 设备检查测试需求自动生成航天器有多个分系统,不同的分系统,有各自的设备集合,需检查对设备集中的所有设备是否齐备,据此,给出设备检查测试需求生成CreateDevTR,其具体实现为
CreateDevTR:SpacecraftName×SubsysId×TRSet→TRSet
CreatDevTR((spn,ssid),trs)=
let(ssn,devs,-)=ssid
in DevCheck(spid,ssn,devs):trs
其中:TRSet为航天器测试需求集合,对给定的航天器spn,其分系统为ssid,则生成关于分系统中设备函数CreatDevTR通过调用DevCheck生成设备检查测试需求,并将其加入到航天器测试需求trs中.
3.2 航天器功能部件初始化状态检查测试需求自动生成航天器有多个分系统,不同的分系统有各自的功能部件集合,对部件集合中的每个部件都需进行检查,最终生成航天器各个功能部件初始化状态检查测试需求.据此,首先给出航天器单个功能部件初始化状态检查测试需求生成语义函数CreateComInfoTR,具体实现为
CreateComInfoTR:SpacecraftName×Subsysld×ComInfo→ComInfoTR
CreateComInfoTR(spn,ssid,comif)=
let(ssn,-,coms)=ssid
in let(comn,{(compid,comst,compv)})=comif
in ComInitStaCheck(spn,ssn,(comn,{(compid,comst,compv)}))
其中:ComInfoTR为生成的单个功能部件测试需求;comif为组件信息;coms为功能部件集合;comn为部件名称;compid为部件参数标识;comst为部件状态;compv为该功能部件参数compid在部件状态为comst时的取值.函数CreateComInfoTR通过调用ComInitStaCheck生成该功能部件检查测试需求.单个功能部件初始化状态测试需求生成后,可给出分系统的所有功能部件初始化状态检查测试需求自动生成语义函数CreateComInfosTR,具体实现为
CreateComInfosTR:SpacecraftName×Subsysld×TRSet→TRSet
CreateComInfosTR((spn,ssid),trs)=
let(ssn,-coms)=ssid
in let comnum=length coms
in let nthCom coms n=if n==1 then head coms else nthCom (tail coms)(n-1)
in let comsCheckTR coms i=
i ＜=comnum→CreateComInfoTR(spn,ssid,nthCom coms i):trs
in comIfsCheckTR coms comnum
其中:TRSet为航天器测试需求,每生成一个功能部件初始化状态检查测试需求就自动加入到trs中;comnum为分系统的功能部件个数;递归函数nthCom表示从功能部件集合中取一个部件,每在功能部件集合coms中取出一个设备,通过递归函数comsCheckTR调用单个功能部件初始化状态检查测试需求生成函数CreateComInfoTR，生成该功能部件初始化状态检查测试需求,并加入到航天器测试需求trs中,直到功能部件集合coms为空,完成该分系统所有功能部件初始化状态检查测试需求生成.
3.3 设备操作指令检查测试需求生成方法设备操作指令检查包括设备操作指令使能和除能,故设备操作指令检查测试需求也相应地包括设备操作指令使能测试需求和除能测试需求.航天器各个分系统均有各自的设备集合,每个设备包括其上固有的设备操作,比如连接、断开操作,这些操作通过设备操作指令来实现.因此,需要对每个设备上的所有操作进行相应的操作指令检查.据此,首先给出单个设备操作指令使能检查测试需求生成语义函数CreateDevOpEnaTR,具体实现为
CreateDevOpEnaTR:SpacecraftName×Dev×DevOp→DevOpEnaTR
CreateDevOpEnaTR(spn,ssid,dev,devop)=
let(ssn,devs,-)=ssid
in let(devn,devops)=dev
in let(devopid,-)=devop
in DevOperEnaCheck(spn,ssn,devn,devopid)
其中:dev为设备;devn为设备名称;devops为设备dev的设备操作指令集;devop为设备dev的一个设备操作;devopid为设备操作标识.函数CreateDevOpEnaTR通过调用函数DevOperEnaCheck生成单个设备操作指令使能检查测试需求.
基于单个设备操作指令检查测试需求生成函数CreateDevOpEnaTR,可给出生成一个设备所有操作指令的使能检查测试需求语义函数CreateDevOpsEnaTR,其具体实现为
CreateDevOpsEnaTR:SpacecraftName×Subsysld×Dev×TRSet→TRSet
CreateDevOpsEnaTR((spn,ssid,dev),trs)=
let (devn,devops)=dev
in let devopnum=length devops
in let nthDevOp devops n=if n==1 then head devopselse nthDevOp (tail devops)(n-1)
in let devOpsEnaTR devops i=
i＜=devopnum CreateDevOpEnaTR(spn,ssid,dev,nthDevOp devops i):trs
in devOpsEnaTR devops devopnum
其中:devopnum为该设备的操作指令个数;递归函数nthDevOp表示在设备操作集合中取一个设备操作,每在设备操作集合中取一个设备操作,通过递归函数devOpsEnaTR调用CreateDevOpEnaTR生成单个设备操作指令使能检查测试需求,并加入航天器测试需求trs中,直到设备操作集合为空,完成该设备所有操作指令使能检查测试需求生成.
根据一个设备的所有设备操作指令检查测试需求生成函数CreateDevOpsEnaTR,可给出一个分系统所有设备操作指令检查测试需求生成语义函数CreateDevsOpsEnaTR,其具体实现为
CreateDevsOpsEnaTR:SpacecraftName×Subsysld×TRSet→TRSet
CreateDevsOpsEnaTR((spn,ssid),trs)=
let(ssn,devs,-)=ssid
in let devnum=length devs
in let nthDev devs n=if n==1 then head devs else nthDev(tail devs)(n-1)
in let devsOpsEnaTR devs i=
i＜=devnum→CreateDevOpsEnaTR((spn,ssid,nthDev devs i),trs)++trs
in devsOpsEnaTR devs devnum
其中:devnum为该分系统的设备个数；递归函数nthDev为从设备集合中取一个设备.每获取到一个设备,即可通过递归函数devEnaTR调用CreateDevOpsEnaTR生成该设备的所有操作指令使能检查测试需求,并自动加入到航天器测试需求trs中,直到所有设备各自的设备操作集合为空,完成该分系统所有设备操作指令集使能测试需求生成.设备操作指令除能检查测试需求生成方法与使能检查测试需求生成方法类似,不再赘述.
3.4 部件操作指令检查测试需求生成方法部件操作指令检查包括部件操作指令使能和除能,故部件操作指令检查测试需求也相应地包括部件操作指令使能测试需求和除能测试需求.航天器各个分系统均有各自的功能部件集合,每个部件包括其上固有的部件操作,比如加电、断电操作,这些操作通过部件操作指令来实现.因此,需要对每个功能部件上的所有操作进行相应的操作指令检查.据此,首先给出单个部件操作指令使能检查测试需求生成语义函数CreateComOpEnaTR,具体实现为
CreateComOpEnaTR:SpacecraftName×Subsysld×Com×ComOp→ComOpEnaTR
CreateComOpEnaTR(spn,ssid,com,comop)=
let(ssn,-,coms)=ssid
in let(comn,comops)=com
in let(comopid,-)=comop
in ComOperEnaCheck(spn,ssn,comn,comopid)
其中:coms为功能部件集合;com为功能部件;comn为功能部件名称;comops为功能部件操作集;comop为单个部件操作.函数CreateComOpEnaTR通过调用函数ComOperEnaCheck生成单个部件操作指令使能检查测试需求.
基于单个部件操作指令使能检查测试需求生成函数CreateComOpEnaTR,可给出生成一个部件所有操作指令的使能检查测试需求语义函数CreateComOpsEnaTR,其具体实现为
CreateComOpsEnaTR:SpacecraftName×Subsysld×Com×TRSet→TRSet
CreateComOpsEnaTR((spn,ssid,com),trs)=
let(comn,comops)=com
in let comopnum=length comops
in let nthComOp comops n=if n==1 then head comops else nthComOp(tail comops)(n-1)
in let comOpsEnaTR comops i=
i＜=comopnum→CreateComOpEnaTR(spn,ssid,com,nthComOp comops i):trs
in comOpsEnaTR comops comopnum
其中:comopnum为该功能部件操作指令个数；递归函数nthComOp为在功能部件操作集合中取一个部件操作,每在部件操作集合comops中取一个部件操作,通过递归函数comOpsEnaTR调用CreateComOpEnaTR生成单个部件操作指令使能检查测试需求,并加入航天器测试需求trs中,直到部件操作集合为空.
根据一个部件的所有部件操作指令检查测试需求生成函数CreateComOpsEnaTR,可给出一个分系统所有功能部件操作指令检查测试需求自动生成语义函数CreateComsOpsEnaTR,具体实现为
CreateComsOpsEnaTR:SpacecraftName×Subsysld×TRSet→TRSet
CreateComsOpsEnaTR((spn,ssid,coms),trs)=
let comnum=length coms
in let nthCom coms n=if n==1 then head coms else nthCom (tail coms)(n-1)
in let comsEnaTR coms i=
i＜=comnum→CreateComOpsEnaTR((spn,ssid,nthCom coms i),trs)++trs
in comsOpsEnaTR coms comnum
其中:comnum为该分系统的功能部件个数;递归函数nthCom为从部件集合中取一个部件,每获取到一个部件,即可通过递归函数comsEnaTR调用CreateComOpsEnaTR生成该部件的所有操作指令使能检查测试需求,并自动加入到航天器测试需求trs中,直到所有部件各自的部件操作指令集合为空.功能部件操作指令除能检查测试需求生成方法与使能检查测试需求生成方法类似,不再赘述.
4 动态测试需求生成方法根据航天器动态测试需求形式化表示方法,本文采用测试场景描述测试需求,基于用例图描述测试场景,并由用例图映射为指令链,最终完成由指令链完整刻画航天器动态测试需求.因此,有必要给出用例图的形式化表示方法.
定义8 用例图=(角色,用例集)
用例集=用例的集合
用例=原子动作行为|原子动作行为序列
原子动作行为序列=原子动作行为::原子动作行为序列
即UseCaseDig=(Role,UseCaseSet)
UseCaseSet=set of UseCase
UseCase=AtomAct|ActSequence
ActSequence=AtomAct::ActSequence
AtomAct=TestInsId
若用例动作行为是一个原子动作行为,则可映射为一条操作指令,即对应的指令链为一个操作指令;若用例动作行为是一个原子动作行为序列,则可映射为操作指令序列,即对应的指令链为操作指令序列.
以下给出动态测试需求生成方法完成上述过程,首先给出用例图中一个用例的动态测试需求方法,然后通过调用一个用例动态测试需求生成方法完成整个场景用例图的动态测试需求生成,最后对于航天器每个测试场景,只需调用对应的场景用例图的动态测试需求生成方法即可完成所有测试场景的动态测试需求生成方法.
据此,首先给出一个用例的动态测试需求生成语义函数CreateUseCaseTR,其具体实现为
CreateUseCaseTR:SpacecraftName×UseCase×TRSet→TRSet
CreateUseCaseTR((spn,uc),trs)=
let(atomact::uc1)=uc
in let trs’=atomact
in trs=CreateUseCaseTR((spn,uc),trs’)
其中:uc为用例图中的一个用例,若该用例是一个原子动作行为atomact,则直接将该原子动作行为对应的指令加入到航天器动态测试需求trs’中,若该用例是原子动作行为序列uc1,则递归调用函数CreateUseCaseTR完成原子动作行为序列对应的航天器动态测试需求生成.
根据用例图中一个用例的动态测试需求生成方法CreateUseCaseTR,可给出整个用例图所有用例的动态测试需求生成语义函数CreateUseCaseDigTR,其具体实现为
CreateUseCaseDigTR:SpacecraftName×UseCaseDig×TRSet→TRSet
CreateUseCaseTR((spn,ucd),trs)=
let (rol,ucs)=ucd
in let ucsnum=length ucd
in let nthUc ucs n=if n==1 then head ucs else nthUc(tail ucs)(n-1)
in let nthUcTR ucs i=
i＜=ucsnum→CreateUseCaseTR((spn,nthUc ucs i),trs)
in nthUcTR ucs ucsnum
其中:ucd为用例图;rol为参与者;ucs为用例集;ucsnum为用例数.通过调用递归函数nthUc依次从用例集中取一个用例,并调用函数CreateUseCaseTR完成一个用例的动态测试需求生成方法,直至所有的用例取完,且均生成相应的动态测试需求.
以神舟飞船模飞测试正常模式下运行段为例,说明航天器动态测试需求生成方法.首先给出运行段测试场景的用例图,如图 4所示.
 |
| 图 4 运行段测试场景用例图Fig. 4 Use case digram of running period of test scenario |
| 图选项 |
从图 4中容易看出,运行段测试场景由TestInsList1等11个指令链组成,且每个测试链都有与其相对应的测试指令序列按照业务逻辑关系组成,则运行段测试需求可描述为
TestInsLink=(“神舟十号”,“正常模式”,“运行段”,TestInsList)
TestInsList=TestInsList1::TestInsList2::TestInsList3::TestInsList4::TestInsList5
TestInsList1=[(“神舟十号”,“数管分系统”,“K1”,“”,“数管前端”,2,0),(“神舟十号”,“数管分系统”,“K2”,“”,“数管前端”,1,1),…]
TestInsList2=[(“神舟十号”,“数管分系统”,“K3”,“”,“遥控前端”,1,3),(“神舟十号”,“数管分系统”,“K4”,“”,“遥控前端”,1,5),(“神舟十号”,“数管分系统”,“K5”,“”,“遥控前端”,1,4)]
TestInsList3=[(“神舟十号”,“测控与通信分系统”,“K9”,“”,“数管前端”,2,3),(“神舟十号”,“数管分系统”,“K19”,“”,“数管前端”,2,2),(“神舟十号”,“数管分系统”,“K18”,“”,“数管前端”,2,2)]
TestInsList4=[(“神舟十号”,“数管分系统”“K8”,“”,“数管前端”,2,5),(“神舟十号”,“测控与通信分系统”,“A20”,“”,“数管前端”,2,11),…]
TestInsList5=[(“神舟十号”,“测控与通信分系统”,“A2”,“”,“数管前端”,1,10)]
5 应用系统基于上述航天器测试需求自动生成方法,给出航天器测试需求生成框架,如图 5所示.
 |
| 图 5 航天器测试需求生成框架Fig. 5 Framework of spacecraft test requirements generation |
| 图选项 |
从图 5中容易看出,输入信息为各个航天器型号信息,通过采用静态测试需求和动态测试需求生成方法,将会输出各个航天器型号各自的测试需求.对于静态测试需求,主要根据本文给出的航天器静态需求生成方法,按照测试设备检查、部件状态初始化、设备操作指令及部件操作指令分别生成相应的静态测试需求;对于动态测试需求,则首先根据实际测试场景使用用例图对其进行建模,然后映射为预先定义的指令链来驱动相应测试场景的动态测试需求生成.此外,输入时可动态添加或删除航天器型号信息,支持动态性和开放性,与具体型号业务解耦合,具有一定的通用性.
基于上述航天器测试需求生成方法,设计并实现了航天器测试需求自动生成系统,该系统架构图如图 6所示.
 |
| 图 6 航天器测试需求自动生成系统架构图Fig. 6 Architecture of automatic generation of spacecraft test requirements system |
| 图选项 |
航天器测试需求自动生成系统架构分为资源层、基础服务层、功能层和展示层4层.其中,资源层主要包括基础数据库、自动化测试数据库、设备资源及测试需求文件等;基础服务层主要提供基础功能支持,包括数据库访问服务和文件操作接口服务;功能层包括静态测试需求生成方法、动态测试需求生成方法及航天器测试需求导出3个核心功能;展示层包括航天器型号管理可视化界面、静态测试需求生成可视化界面及动态测试需求生成可视化界面.航天器静态测试需求生成实现主界面如图 7所示.航天器动态测试需求生成主界面如图 8所示.
 |
| 图 7 航天器静态测试需求生成主界面Fig. 7 Main interface of spacecraft static test requirements generation |
| 图选项 |
 |
| 图 8 航天器动态测试需求生成主界面Fig. 8 Main interface of spacecraft dynamic test requirements generation |
| 图选项 |
最后,本文在成本方面对比了手工方式编写和本文方法.
通常某型号航天器由30多个分系统组成,就静态测试需求来讲,每个分系统静态测试大约对应350条测试需求,静态测试需求共计350×30=10500条测试需求;对于动态测试需求来讲,正常模式下各个测试阶段共计对应约1500条测试需求,故障模型下各个救生程序共计对应约2500条测试需求,故动态测试需求对应约4000条测试需求.因此,对于某型号航天器约对应14500条测试需求.采用手工方式编写航天器测试需求时,大约需要3分钟编写一条测试需求,则根据航天器测试大纲进行航天器测试需求编写一个人的时间成本是:14500×3=43500min,约30.2天.
采用本文提出的方法生成航天器测试需求时,是在实验室和某航天院所共同研制的某型号自动化测试软件平台上进行的,本文所提方法目前已经集成到该平台且运行稳定,一个人采用本文方法根据实验大纲进行测试需求建模所需时间为10天,建模包括静态、动态测试需求建模和数据结构设计3部分,然后在实验室自动化测试软件平台上进行测试需求生成(忽略人手动操作界面中控件的时间),每分钟生成约100条测试需求,则需要145min的时间,生成完测试需求后导出至本地Excel文件的速度是每分钟1000条记录,则需要14.5min,故采用本文所提方法生成测试需求时一个人的成本是10×24×60+145+14.5=14559.5min,约合11.1天.
对于该型号航天器测试需求成本来讲,本文所提方法将时间缩短了19.1天,测试需求编制周期缩短了64%,可见本文所提方法与手工编制方式相比,在很大程度上缩减了人力和时间成本.尤其是对于多型号航天器来讲,本文所提方法优势更为明显,因为一旦测试需求模型建立,在进行新型号测试需求生成时,可复用已有型号的测试需求模型,减少测试需求生成时间,最终有利于提高多型号航天器测试效率.
6 结 论本文针对航天器测试需求描述及其自动生成方法展开了研究,研究结果如下:
1) 通过分析航天器组织结构特点,建立了航天器形式化模型,为航天器测试需求形式化规范描述提供了理论基础.
2) 基于航天器静态测试任务流程特点,从设备检查、功能部件初始化检查、设备操作指令检查和功能部件操作指令检查4个方面给出航天器静态测试需求形式化描述规范,并给出了静态测试需求自动生成方法.
3) 基于航天器动态测试任务流程特点,采用测试场景描述动态测试需求,基于用例图描述测试场景,并由用例图映射为指令链,最终完成由指令链完整刻画航天器动态测试需求,建立了航天器动态测试需求形式化描述规范,并给出了动态测试需求自动生成方法.
4) 航天器静态测试需求、动态测试需求形式化描述规范及其自动生成方法,保证了航天器测试需求的充分性、完备性,提高了测试需求的复用性,缩短了航天器测试需求编制周期,能满足当前多航天器并行测试需求,为航天器测试用例自动生成奠定了理论基础.
5) 设计并实现了航天器测试需求生成应用系统,验证了所提方法的可行性和有效性,本文方法具有动态性和扩展性,从而支持航天器测试需求自动生成的通用性,可直接应用到多型号航天器的批产化并行测试中.
参考文献
| [1] | 吕江花, 马世龙, 李先军, 等.安全苛刻系统自动化测试的形式化语义模型[J].软件学报, 2014, 25(3): 489-505. Lü J H, Ma S L, Li X J.et al.Formal semantics model for automatic test of safety critical systems[J].Journal of Software, 2014, 25(3): 489-505(in Chinese). |
| Cited By in Cnki | |
| [2] | Lv J H, Ma S L, Li X J.et al.A high order collaboration and real time formal model for automatic test of safety critical systems[J].Frontiers of ComputerScience, 2015.DOI: 10.1007/s11704-015-2254-y. |
| Click to display the text | |
| [3] | Wilhelm H, Reussner R.Toward trustworthy software systems[J].Computer, 2006, 39(4): 91-92. |
| Click to display the text | |
| [4] | 刘克, 单志广, 王戟, 等.可信软件基础研究重大研究计划综述[J].中国科学基金, 2008(3): 145-151. Liu K, Shan Z G, Wang J, et al.Overview on major research plan of trustworthy software[J].Bulletin of National Natural Science Foundation of China, 2008(3): 145-151(in Chinese). |
| Cited By in Cnki (191) | |
| [5] | 郑志明, 马世龙, 李未, 等.软件可信性动力学特征及其演化复杂性[J].中国科学(F辑: 信息可信), 2009, 52(9): 1651-1657. Zheng Z M, Ma S L, Li W.et al.Dynamical characteristics of software trustworthiness and their evolutionary complexity[J].Science China Series F-Information Sciences, 2009, 52(9): 1651-1657(in Chinese). |
| Cited By in Cnki (17) | |
| [6] | 郑志明, 马世龙, 李未, 等.软件可信复杂性及其动力学统计方法[J].中国科学(F辑: 信息可信), 2009, 52(8): 1328-1334. Zheng Z M, Ma S L, Li W.et al.Complexity of software trustworthiness and its dynamical statistical analysis methods[J].Science China Series F-Information Sciences, 2009, 52(8): 1328-1334(in Chinese). |
| Cited By in Cnki (8) | |
| [7] | Knight J C. Safety critical systems: Challenges and directions[C]//Proceedings of the 24rd International Conference on Software Engineering.Piscataway, NJ: IEEE Press, 2002: 547-550. |
| [8] | 王庆成. 航天器电测技术[M].北京: 中国科学技术出版社, 2007: 48-133. Wang Q C.Electrical test technology for spacecraft[M].Beijing: China Science and Technology Press, 2007: 48-133(in Chinese). |
| [9] | 杨占才, 周一鸥, 刘金甫.测试需求描述方法综述[J].测控技术, 2009, 28: 270-273. Yang Z C, Zhou Y O, Liu J F.Summarization of test requirements description methods[J].Measurement Control Technology, 2009, 28: 270-273(in Chinese). |
| [10] | Lansdowne C A, McCartney P, Gorringe C.Experimental applications of automatic test markup language(ATML)[C]//Proceedings of 2012 IEEE Autotestcon.Piscataway, NJ: IEEE Press, 2012: 318-323. |
| [11] | Smith A, Wanigaratne A.Applications of ATML test results and intrastage to facilitate intelligent data analysis[C]// Proceedings of 2012 IEEE Autotestcon.Piscataway, NJ: IEEE Press, 2012: 200-203. |
| Click to display the text | |
| [12] | 高猛. 实时嵌入式软件系统测试需求建模研究[J].航天控制, 2010, 28(5): 64-69. Gao M.Research on system-testing requirement modeling for real-time embedded software[J].Aerospace Control, 2010, 28(5): 64-69(in Chinese). |
| Cited By in Cnki (3) | |
| [13] | 沈剑乐, 王林章, 李宣东, 等.一个基于UML顺序图的场景测试用例生成方法[J].计算机科学, 2004, 31(8): 179-184. Shen J L, Wang L Z, Li X D, et al.An approach to generate scenario test cases based on UML sequence diagrams[J].Computer Science, 2004, 31(8): 179-184(in Chinese). |
| Cited By in Cnki (18) | |
| [14] | 杨波, 吴际, 徐珞, 等. 一种软件测试需求建模及测试用例生成方法[J].计算机学报, 2014, 37(3): 522-538. Yang B, Wu J, Xu L, et al.An approach of modeling software testing requirements and generating test case[J].Chinese Journal of Computers, 2014, 37(3): 522-538(in Chinese). |
| Cited By in Cnki (3) | |
| [15] | 侯超凡, 吴际, 刘超. 基于测试需求的互操作性测试用例生成方法[J].计算机科学, 2014, 41(11): 162-168. Hou C F, Wu J, Liu C.Interoperability test case generation based on testing requirements[J].Computer Science, 2014, 41(11): 162-168(in Chinese). |
| Cited By in Cnki | |
| [16] | 赵瑞峰. 基于办公自动化的卫星自动测试方法的设计和实现[D].上海: 上海交通大学, 2010. Zhao R F.Design and implementation of satellite automatic test method based on office automation[D].Shanghai: Shanghai Jiaotong University, 2010(in Chinese). |
| Click to display the text | |
| [17] | Esteve M, Katoen J, Nguyen VP, et al.Formal correctness, safety, dependability, and performance analysis of a satellite[C]//Proceedings of the 34th International Conference on Software Engineering, ICSE.Piscataway, NJ: IEEE, 2012: 1022-1031. |
| Click to display the text | |
| [18] | Peng Z G, Lu Y, Miller A, et al.Formal modelling and quantitative analysis of satellite navigation systems[J].Computing Research Repository, 2014: 1402.5599. |
| Click to display the text | |
| [19] | Fischer P M, Ludtke D, Schaus V, et al.A formal method for early spacecraft design verification[C]//Proceedings of 2013 IEEE Aerospace Conference. Piscataway, NJ: IEEE Press, 2013: 1-8. |
| [20] | Nguyen V Y. Trustworthy spacecraft design using formal methods[D].Chemnitz: Technische Universit?t Chemnitz, 2012. |
| Click to display the text | |
| [21] | Bozzano M, Cimatti A, Katoen J P, et al.Safety, dependability and performance analysis of extended AADL models[J].The Computer Journal, 2011, 54(5): 754-775. |
| Click to display the text | |
| [22] | Hudak P, Hughes J, Peyton J, et al.A history of Haskell: being lazy with class[C]//Proceedings of the third ACM SIGPLAN Conference on History of Programming Languages.New York: ACM, 2007. |
| [23] | Pike L, Niller S, Wegmann N.Runtime verification for ultra-critical systems[C]//Proceedings of 2nd Conference on Runtime Verification.Berlin, Heidelberg: Springer, 2012: 310-324. |
| [24] | Yu D, Ma S. Design and implementation of spacecraft automatic test language[J].Chinese Journal of Aeronautics, 2011, 24(3): 287-298. |
| Click to display the text |
