CN104699613B - 一种航天器测试需求自动生成系统及其方法 - Google Patents

Abstract

本发明是一种航天器测试需求自动生成系统及其方法，属于系统测试领域。所述系统包括测试需求库、UML模型读取模块、被测目标抽取模块和测试需求构建模块；测试需求库是经过积累的各型号被测系统、分系统、单机和模块所需的测试需求；UML模型读取模块对基于UML的状态转换图和交联图转换为XML格式存储；被测目标抽取模块抽取被测目标的测试环境需求；测试需求构建模块用于构建静态测试需求和动态测试需求。所述方法基于上述系统，根据被测目标的类名、接口名称以及总线名称构建静态测试需求，依据状态转换图构建动态测试需求。本发明实现了对航天器测试需求模型所包含信息的完备抽取，自动生成测试需求，减少重复工作，提高工作效率。

Description

一种航天器测试需求自动生成系统及其方法

技术领域

本发明属于系统测试领域，涉及一种在航天器测试中的测试需求自动生成的系统与方法。

背景技术

航天器是一种安全攸关的实时系统。对于航天器的测试需求必须既可以描述被测系统的功能、性能特征，也能够描述系统的约束。测试需求模型是用来指导测试人员开展后续测试活动、方便测试人员与设计人员之间的沟通的工具。测试需求文档是测试人员通过《开发需求说明书》、《接口控制文档》、《设计文档》和《用户手册》整理得来，帮助测试人员设计出更贴近需求的测试的文档。也可以帮助测试人员准确的了解需求的变化从而快速更改测试方案。

由于航天器系统作为高集成度复杂电子系统的典型，其测试需求达到上万项。现有的测试需求生成方法集中在如何获取被测系统的静态需求，而在获取动态需求方面现有方法则过于复杂，不便于测试人员理解和使用。因此在目前的工程实践中，由于系统过于复杂，测试人员通常依据其测试经验人工编写测试需求文档。这极大的延长了测试工作的时间。为了减少重复性工作，加快测试进度，实现测试需求的自动生成是非常有必要的。

目前关于测试需求模型的主要研究有面向UUT(Unit Under Test，被测模块)的测试需求模型，和基于模型测试需求模型。其中面向UUT的测试需求模型主要面向的是测试设备和测试单元，通过分析被测系统的逻辑给出测试所需要的激励信号，是从硬件层面对被测单元进行测试需求建模。基于模型特别是基于UML(Unified Modeling Language，标准建模语言)的测试需求模型，其主要是通过状态图和类图描述被测系统，对被测系统的静态结构和动态结构进行测试需求建模。但是这些工作都是以理论研究为主，仅给出一种测试需求建模方法，测试人员仍然需要通过人工的方式生成测试需求。而如何从测试需求模型生成真正满足实际的测试需求的技术和方法却很少。

发明内容

本发明为了减少测试人员选取测试需求的时间，提高测试效率。提供了一种面向航天器的测试需求自动化获取系统及方法。本发明通过分析被测系统基于UML的状态转换图和交联图的测试需求模型，并根据被测系统级别和一种遍历算法，找出被测系统的测试需求。被获取的测试需求可以根据用户要求转变成不同格式的文本输出。

本发明提供了一种航天器测试需求自动生成系统，包括测试需求库、UML模型读取模块、被测目标抽取模块和测试需求构建模块。针对被测航天器按照模块级、单机级、分系统级和系统级分别绘制基于UML的状态转换图和交联图。

所述的测试需求库是经过积累的各型号被测系统、分系统、单机和模块所需的测试需求，包含环境测试需求库、总线测试需求库和接口测试需求库。测试需求库的数据结构包括：被测产品名称，被测产品类型，被测产品测试需求，被测产品的接口名称和接口类型，以及被测产品关联的总线名称和总线类型。

所述的UML模型读取模块对基于UML的状态转换图和交联图抽取对应的XML存储结构，并将状态转换图和交联图转换为XML格式的模型存储。在XML格式的交联图模型中，将被测产品以类视图来描述，类视图包含被测类、交联类、类之间的连接方式和接口数据；交联图模型的属性中包括是否为被测类、类的ID、类名和类的类型，与被测类连接的总线的属性包括总线ID、总线名称和总线类型，类的接口数据包括接口ID、接口名称和接口类型。

所述的被测目标抽取模块的功能包括被测目标测试环境抽取和被测目标测试环境测试需求查询。被测目标测试环境抽取具体是：当测试需求为模块级或者单机级时，从交联图模型中选取所有被测产品，从中抽取被测产品对应的类名以及被测产品的各个接口的接口名称；当测试需求为系统级和分系统级时，遍历模型中所有被测产品，抽取与被测产品相关联的总线名称，抽取被测产品对应的类名以及被测产品的各个接口的接口名称；根据抽取到的被测产品名称、总线名称和接口名称从测试需求库中筛选出所需的接口测试需求、总线测试需求和环境测试需求。被测目标测试环境测试需求查询是：根据类名和总线名称从测试需求库中查找对应的产品名称，选出所需要的环境测试需求。

所述的测试需求构建模块用于构建静态测试需求和动态测试需求；构建静态测试需求是指将被测目标抽取模块获取的接口测试需求、总线测试需求和环境测试需求输出。构建动态测试需求的过程是：读取状态转换图模型，遍历所有状态迁移路径，对每个状态迁移路径，从起始状态开始，依次找出各个状态的后续状态和迁移条件，对选择的每个状态添加已访问过的标记，列出所有实现转移的状态形成功能测试需求，列出所有迁移条件形成约束测试需求，输出功能测试需求和约束测试需求。

本发明提供了一种航天器测试需求自动生成方法，主要包括如下步骤：

步骤一：针对航天器测试，定义系统、分系统、单机和模块四个级别的测试需求，对被测航天器按照模块级，单机级，分系统级和系统级分别绘制基于UML的状态转换图和交联图，抽取状态转换图和交联图对应的XML存储结构，并将状态转换图和交联图转换成XML格式的模型存储。

在XML格式的交联图模型中，将被测产品以类视图来描述，类视图包含被测类、交联类、类之间的连接方式和接口数据；交联图模型的属性中包括是否为被测类、类的ID、类名和类的类型，与被测类连接的总线的属性包括总线ID、总线名称和总线类型，类的接口数据包括接口ID、接口名称和接口类型。

将被测系统的逻辑结构转换成由串行，并行，选择和循环等单元构成XML格式的状态转换图模型；将被测系统的物理结构转换成由黑盒、接口和总线等单元构成的XML格式的交联图模型。

步骤二：判断当前测试需求级别，若级别为模块级或单机级，则读取交联图模型，遍历交联图模型中所有被测产品，从中抽取被测产品对应的类名和被测产品的各个接口的接口名称；若级别为系统级或分系统级，则读取交联图模型，遍历模型中所有被测产品，从交联图模型中抽取与被测产品相关联的总线名称，抽取被测产品对应的类名以及被测产品的各个接口的接口名称。

步骤三：根据抽取到的被测产品对应的类名、总线名称和接口名称从已有的测试需求库中筛选出接口测试需求、总线测试需求和测试环境测试需求。

步骤四：读取状态转换图模型，具体是：从状态转换图中的起始状态开始，依次找出各个状态的后续状态和迁移条件，当选择一个后续状态时在该状态上添加已访问过的标记。若一个状态有两个以上的后续状态，则随机选取一个没有被标记已访问过的状态继续，直至遇到终止状态，然后执行步骤五。

步骤五：判断终止状态是否还有未遍历的路径。若存在未遍历的路径，则返回距离终止状态最近的分支状态，执行步骤四；若不存在未遍历的路径，执行步骤六。

步骤六：在功能测试区域列出每一个实现转移的状态，形成功能测试需求，列举完成后执行步骤七。

步骤七：在约束测试区域依次列出约束测试需求，列举完成后执行步骤八。

步骤八：将接口测试需求、总线测试需求、环境测试需求、功能测试需求和约束测试需求合并成为测试需求分析表输出。

相比现有技术，本发明的优点和积极效果在于：

(1)完备性：本发明通过航天器各类型的测试需求字段的完备定义，实现了对航天器测试需求模型中所包含信息完备的抽取。通过自动化的测试需求文档生成方法保障了测试需求文档内容的完备性；

(2)易用性：本发明所给出的测试需求自动生成系统及其方法简单易用，具有可视化模块，可在图形界面进行操作，操作简单易用，方法接口调用易用性强，方便与其它模块集成；

(3)通用性：本发明提出的一种航天器测试需求自动生成系统及其方法，在实际应用中针对特定领域工程，采用此方法对交联图获取和状态转换图模型读取接口进行适当修改即可满足本领域需求；

(4)实用性：在航天器测试中，由于实际工程的结构特点，大量的静态测试需求具有通用性，而动态测试需求可以由系统功能实现进行分析，本发明提出的一种航天器测试需求自动生成系统及其方法，可以根据测试需求模型自动生成测试需求，对帮助测试人员对被测系统的理解，减少重复工作，方便测试需求编写，提高工作效率具有重大意义，可以满足工程实际需求，具有一定的实用性；

(5)兼容性：本发明在设计时已经考虑到在不同测试层级，并应用在不同型号系统下使用，实现不同型号下的测试需求自动抽取；同时可以依照不同的项目，不同的安全等级选择不同的测试需求库文件进行测试需求抽取。

(6)可复用性：本发明在设计时采用了UML来描述被测产品，通过将UML转换成为XML文件进行读取，由于UML和XML都是标准化的建模方法，该测试需求自动获取方法具有可复用性。

(7)可维护性：本发明采取接口类型和被测产品类型对测试需求库中的测试需求进行管理，可以方便测试人员测试需求库。针对不同的型号，将通过测试经验获得的新的测试需求知识添加入测试需求库。

(8)可扩展性：本发明通过定义被测产品ID和类型为后续的测试需求文档管理提供了文档管理依据。

附图说明

图1为本发明的测试需求自动生成系统的结构示意图；

图2为本发明的测试需求自动生成方法的整体流程图。

具体实施方法

下文中将参考附图并结合实施来详细说明本发明。

根据航天器测试的相关知识，本发明定义四个测试需求级别，包括模块级，单机级，分系统级和系统级。定义第一级别为系统级测试需求模型，第二级为分系统级测试需求模型，第三级为单机级测试需求模型，第四级为模块级测试需求模型。

一种面向航天器的测试需求自动生成系统的结构如图1所示，包含测试需求库1，UML模型读取模块2，被测目标抽取模块3和测试需求构建模块4。

测试需求库1是经过积累的各型号被测系统、分系统、单机和模块所需的测试需求，包含环境测试需求库、总线测试需求库和接口测试需求库。

环境测试需求库是被测系统、分系统、单机和模块所需环境测试项。总线测试需求库是是被测系统和分系统所需总线测试项。接口测试需求库是被测系统、分系统、单机和模块所需接口测试项。测试需求库的数据结构信息包括：被测产品名称，被测产品类型，被测产品测试需求，被测产品的接口名称及接口类型，以及被测产品关联的总线名称及总线类型。本发明采取的接口类型和被测产品类型对测试需求库中的测试需求进行管理，以方便测试人员测试需求库。针对不同的类型，将通过测试经验获得的新的测试需求知识添加入测试需求库

UML模型读取模块2主要功能包括针对被测系统交联视图和状态转换视图的UML模型结构抽取，并依据抽取的模型构建存储UML模型。

UML模型结构抽取：对UML交联图和状态转换图做如下定义。

1、UML交联图模型：

交联图模型描述了被测系统的物理结构，需要确定：(1)与被测系统相关联的其他设备或系统；(2)被测系统与环境之间的连接方式；(3)被测系统与环境之间的交互信息，包括信息的数据类型、数据格式及内容等。

被测产品以类视图进行描述，类视图包括：被测类、交联类、类之间的连接方式和接口数据。当进行模块级测试时，类图中的对象为模块；当进行单机级测试时，类图中的对象为被测单机；当进行分系统级测试时，类图中的对象为分系统所包括的模块，单机以及连接总线；当进行系统级测试时，类图的对象为系统所包含的各分系统，独立于各分系统之外的单机和模块以及将各对象相连接的总线。类的接口数据包括接口ID、接口名称和接口类型。

2、UML状态转换图模型：

在被测系统静态结构类图的基础上对系统的动态行为进行描述，绘制状态转换图。状态转换图描述了被测系统的逻辑结构，一个状态转换图应包括状态，迁移，时间和动作。

状态转换图的元素包括：状态、并发、连接、分支、起点、终点和迁移。其中迁移包括迁移源状态，迁移目标状态，和迁移触发条件(约束)。迁移触发条件包括：时间约束Time,指令约束Instruction。指令约束数据结构包括：接收Receive，发送Send，判断Judge和等待Wait等。

通过对UML模型的定义之后，UML模型向XML转换定义如下：

交联图在XML中用<Interaction:Class>表示，其属性<Interaction:Porperty>包括了是否为被测类<Ineraction:Test>,类的ID<Interaction:ID>，类的名称<Interaction:Name>和类的类型<Interaction:Type>。

交联图模型的XML结构层次如下：

其中，类名<Interaction:Name>描述接口名称的属性，例如1553B总线接口，COM接口，RJ45接口，SMP接口等；类型<Interaction:Type>描述接口的类型，例如1553B总线接口类型应该是Bus，SMP接口的类型应该是Inter等，类型为Bus的接口才具有相应的总线，进行总线测试。

交联图模型中的总线定义为：

状态转换图在XML中用<State:StateChart>表示，包含了状态<State:States>和迁移<State:Transition>，状态转换图的XML结构如下：

其中状态的数据结构定义为：

状态迁移的数据结构定义为：

迁移中的变量的数据结构定义为：

通过以上定义，UML模型读取模块2将UML交联图和状态转换图模型的XML存储结构抽取后，可以将读入的UML模型存入XML文件中。如UML模型中出现未定义的图元，则说明其模型存在错误，应向测试需求编写人员发送报告提示其修改。

被测目标抽取模块3包括被测目标测试环境抽取和被测目标测试环境测试需求查询。当测试需求编写人员选择编写模块级或者单机级测试需求时，从存储的XML文件中选取<Interaction:Bus>和<Ineraction:Test>为True的类进行分析。通过接口的类型Type的赋值从环境测试需求库中抽取对应被测系统的测试需求，同时通过总线类型BusType的赋值从接口测试需求库中抽取对应被测系统的测试需求。当测试需求编写人员选择编写分系统或者系统级的测试需求时，则应该选取所有的类进行分析。通过Type的赋值从环境测试需求库中抽取对应被测系统的环境测试需求，同时通过BusType分别从接口需求库和总线需求库抽取对应被测系统的测试需求。被测目标抽取模块3将被测目标与测试需求库中已有的测试需求建立关联关系，通过对类名和总线名称来搜索需求库，以抽取到完备的测试需求数据。

被测目标测试环境测试需求查询是依据被测产品的类名<Interaction:Name>和总线名称<Interaction:BusName>从测试需求库中查找对应的产品名称，选出所需要的环境测试需求项目，例如高低温测试，电磁兼容(EMC)测试等等。

测试需求构建模块4包含静态测试需求构建和动态测试需求构建。静态测试需求即是通过被测目标抽取时得到的环境测试需求，接口测试需求和总线测试需求的集合。

动态测试需求可以被认为是系统功能的测试需求，系统状态的每一次迁移就可以视为一种系统功能的实现，因此动态测试需求的项目包含：

1、系统状态从源状态到目标状态的一次迁移是否能够实现，即功能测试需求；

2、系统状态迁移成功时是否遵守迁移条件，即约束测试需求。

构建动态测试需求的过程是：读取状态转换图模型，遍历所有状态迁移路径，对每个状态迁移路径，从起始状态开始，依次找出各个状态的后续状态和迁移条件，对选择的每个状态添加已访问过的标记，列出所有实现转移的状态形成功能测试需求，列出所有迁移条件形成约束测试需求，输出功能测试需求和约束测试需求。

结合本发明提供的的航天器测试需求自动生成系统，本发明的一种航天器测试需求自动生成方法，如图2所示，下面对实现步骤进行具体说明。

步骤一：针对航天器测试，定义系统、分系统、单机和模块四个级别的测试需求，利用UML工具对被测航天器按照模块级，单机级，分系统级和系统级，分别绘制构建基于UML的状态转换图和交联图。将被测系统的逻辑结构转换成由串行，并行，选择和循环等单元构成XML格式的状态转换图模型；将被测系统的物理结构转换成由黑盒、接口和总线等单元构成的XML格式的交联图模型。

若状态转换图或交联图无法转换为XML格式，则测试人员对无法转换部分进行修改后再进行转换。

所采用的UML模型，可以通过修改开发过程中已经绘制好的状态转换图和交联图获取，以避免重复性的工作。

步骤二：判断当前测试级别，若级别为模块级或单机级，则读取交联图模型，遍历交联图模型中所有被测产品，从中抽取被测产品对应的类名和被测产品的各个接口的接口名称；若级别为系统级或分系统级，则读取交联图模型，遍历交联图模型中所有被测产品，从交联图模型中抽取与被测产品相关联的总线名称，抽取被测产品对应的类名和被测产品的各个接口的接口名称。

更具体地，在抽取数据时，对被测产品抽取对应的类的ID、类名和类的类型，对被测产品的各接口抽取接口名称、接口ID以及接口类型。对相关联的被测总线抽取总线名称、总线ID和总线类型。

对于模块级或单机级，被测产品是指交联图模型中所包含的模块或者单机。对于系统级或分系统级，被测产品是指模型中所包含的分系统，以及独立于分系统存在的单机和模块。

步骤二具体实现过程是：首先，测试人员标记导入的静态测试需求要分析的是哪一个级别的测试需求，若是模块级或单机级测试需求，则遍历交联图模型中的类，将被测模块或被测单机对应的类添加到测试需求目录下，之后遍历交联图模型中的总线信息，将所有被测模块或被测单机相连的总线添加到测试需求目录下；若是分系统级或者系统级测试需求，则遍历交联图模型中的类，将被测分系统或者被测系统中所有的类添加到测试需求目录下，之后遍历交联图模型中的总线信息，将所有被测分系统或被测系统包含的总线和总线接口添加到测试需求目录下。

步骤三：根据抽取到的被测产品的类名，总线名称和接口名称从已有的测试需求库中筛选出接口测试需求、总线测试需求和环境测试需求。通过步骤三，将已经抽取出来的被测目标与测试需求库中已有的测试需求建立关联关系，并将筛选出来的测试需求记录在缓冲区。

在测试需求库进行数据筛选时，涉及到的数据包括：被测产品对应的类名、类的类型、适用安全等级和测试需求等级。

接口测试需求和总线测试需求中描述了接口测试和总线测试所需要搭建的物理环境测试需求，比如周边的配套电路，配套的测试仪器等等。而环境测试需求描述了测试所需要的环境，例如高温环境下的测试，低温环境下的测试，以及复杂电磁环境下的测试。

若在已有的测试需求库未查询到对应被测产品、总线和/或接口的测试需求，则需要测试人员更新测试需求库，然后再进行选取。

构建静态测试需求的步骤如下：

步骤a、将查询到的环境测试需求输出到测试需求的环境测试部分；

步骤b、将查询到的接口测试需求输出到测试需求的接口测试部分；

步骤c、将查询到的总线测试需求输出到测试需求的总线测试部分。

步骤四：读取状态转换图模型，具体是：状态转换图中的起始状态开始，依次找出各个状态的后续状态和迁移条件，然后在该状态上添加一个flag标记表示已访问过。若一个状态有多个后续状态，则随机选取一个没有被标记过的状态继续，直至遇到终止状态，执行步骤五。

步骤五：判断终止状态是否还有未遍历的路径，若存在未遍历的路径，则返回距离终止状态最近的分支状态，执行步骤四；若不存在未遍历的路径，执行步骤六。

步骤六：在功能测试区域列出每一个实现转移的状态，即为功能测试需求，列举完成后执行步骤七。具体地，将每一个状态迁移的前驱状态和后继状态作为一项功能测试需求记录到缓冲区。

步骤七：将每一个状态迁移条件作为一项约束测试需求记录到缓冲区，在约束测试区域依次列出约束测试需求，列举完成后执行步骤八。

功能测试需求和约束测试需求合并构建动态测试需求，具体步骤四～七可通过如下过程来实现：

步骤1、将状态转换图存储在一个邻接矩阵M中。

步骤2、遍历邻接矩阵，将所有状态迁移路径存在一个链表的集合L中。遍历算法的伪代码如下：

通过上面过程，遍历状态转换图，将所有状态迁移路径存在链表L中。

步骤3、将每一个迁移的源状态和目标状态存入一个数组A[i][j]，A[i][j]的数据结构应为(Source,Target)，Source表示迁移的源状态，Target表示迁移的目标状态。

步骤4、抽取每一个状态迁移条件，并将其保存。

步骤5、将数组A中的每一个状态迁移记录依次输出到测试需求的功能测试部分。

步骤6、将保存的每一项迁移条件记录依次输出到测试需求的约束测试部分。

步骤八：将接口测试需求、总线测试需求、环境测试需求、功能测试需求和约束测试需求合并成为测试需求分析表，结束本方法。

步骤八中，对提交缓冲区存储的步骤三、步骤六和七得到的测试需求，先去除其中的冗余操作，然后再将得到的测试需求提交到数据库，并更新数据库，并根据用户需求输出测试需求。通过以上步骤，可以实现航天器的测试需求自动获取。

Claims (3)

1.一种航天器测试需求自动生成系统，其特征在于，针对航天器测试，定义系统、分系统、单机和模块四个级别的测试需求，并对被测航天器按照模块级、单机级、分系统级和系统级分别绘制基于UML的状态转换图和交联图；

所述的航天器测试需求自动生成系统包括测试需求库、UML模型读取模块、被测目标抽取模块和测试需求构建模块；

所述的测试需求库是经过积累的各型号被测系统、分系统、单机和模块所需的测试需求，包含环境测试需求库、总线测试需求库和接口测试需求库；测试需求库的数据结构包括：被测产品名称，被测产品类型，被测产品测试需求，被测产品的接口名称和接口类型，以及被测产品关联的总线名称和总线类型；

所述的UML模型读取模块对基于UML的状态转换图和交联图抽取对应的XML存储结构，并将状态转换图和交联图转换为XML格式的模型存储；在XML格式的交联图模型中，将被测产品以类视图来描述，类视图包含被测类、交联类、类之间的连接方式和接口数据；交联图模型的属性中包括是否为被测类、类的ID、类名和类的类型，与被测类连接的总线的属性包括总线ID、总线名称和总线类型，类的接口数据包括接口ID、接口名称和接口类型；

所述的被测目标抽取模块的功能包括被测目标测试环境抽取和被测目标测试环境测试需求查询；被测目标测试环境抽取具体是：当测试需求为模块级或单机级时，从交联图模型中选取所有被测产品，从中抽取被测产品对应的类名以及被测产品的各个接口的接口名称；当测试需求为系统级或分系统级时，遍历模型中所有被测产品，抽取与被测产品相关联的总线名称，抽取被测产品对应的类名以及被测产品的各个接口的接口名称；根据抽取到的被测产品对应的类名、总线名称和接口名称从测试需求库中筛选出所需的接口测试需求、总线测试需求和环境测试需求；被测目标测试环境测试需求查询是：根据类名和总线名称从测试需求库中查找对应的产品名称，选出所需要的环境测试需求；

所述的测试需求构建模块用于构建静态测试需求和动态测试需求；构建静态测试需求是指将被测目标抽取模块获取的接口测试需求、总线测试需求和环境测试需求输出；构建动态测试需求的过程是：读取状态转换图模型，遍历所有状态迁移路径，对每个状态迁移路径，从起始状态开始，依次找出各个状态的后续状态和迁移条件，对选择的每个状态添加已访问过的标记，列出所有实现转移的状态形成功能测试需求，列出所有迁移条件形成约束测试需求，输出功能测试需求和约束测试需求。

2.一种面向航天器测试需求自动生成的方法，其特征在于，包括如下步骤：

步骤一：针对航天器测试，定义系统、分系统、单机和模块四个级别的测试需求，对被测航天器按照模块级、单机级、分系统级和系统级分别绘制基于UML的状态转换图和交联图，抽取状态转换图和交联图对应的XML存储结构，并将状态转换图和交联图转换成XML格式的模型存储；

在XML格式的交联图模型中，将被测产品以类视图来描述，类视图包含被测类、交联类、类之间的连接方式和接口数据；交联图模型的属性中包括是否为被测类、类的ID、类名和类的类型，与被测类连接的总线的属性包括总线ID、总线名称和总线类型，类的接口数据包括接口ID、接口名称和接口类型；

步骤二：判断当前测试需求级别，若级别为模块级或单机级，则读取交联图模型，遍历交联图模型中所有被测产品，从中抽取被测产品对应的类名和被测产品的各个接口的接口名称；若级别为系统级或分系统级，则读取交联图模型，遍历交联图模型中所有被测产品，从模型中抽取与被测产品相关联的总线名称，抽取被测产品对应的类名以及被测产品的各个接口的接口名称；

步骤三：根据抽取到的被测产品对应的类名、总线名称和接口名称从测试需求库中筛选出接口测试需求、总线测试需求和环境测试需求；

步骤四：读取状态转换图模型，具体是：从状态转换图中的起始状态开始，依次找出各个状态的后续状态和迁移条件，当选择一个后续状态时在该状态上添加已访问过的标记；若一个状态有两个以上的后续状态，则随机选取一个没有被标记已访问过的状态继续，直至遇到终止状态，然后执行步骤五；

步骤五：判断终止状态是否还有未遍历的路径，若存在未遍历的路径，则返回距离终止状态最近的分支状态，执行步骤四；若不存在未遍历的路径，执行步骤六；

步骤六：在功能测试区域列出每一个实现转移的状态，形成功能测试需求；

步骤七：在约束测试区域依次列出约束测试需求；

步骤八：将接口测试需求、总线测试需求、环境测试需求、功能测试需求和约束测试需求合并成为测试需求分析表输出。

3.根据权利要求2所述的一种面向航天器测试需求自动生成的方法，其特征在于，所述的步骤二的具体实现方法是：首先，测试人员标记导入的静态测试需求要分析的是哪一个级别的测试需求，若是模块级或单机级测试需求，则遍历交联图模型中的类，将被测模块或被测单机对应的类添加到测试需求目录下，之后遍历交联图模型中的总线信息，将所有被测模块或被测单机相连的总线添加到测试需求目录下；若是分系统级或者系统级测试需求，则遍历交联图模型中的类，将被测分系统或者被测系统中所有的类添加到测试需求目录下，之后遍历交联图模型中的总线信息，将所有被测分系统或被测系统包含的总线和总线接口添加到测试需求目录下。