一种形式化测试模型建模方法、系统、计算机及存储介质

摘要

本发明提供一种形式化测试模型建模方法、系统、计算机及存储介质，形式化测试模型建模方法，包括：定义原子模型的结构、类型、端口、属性及行为，用于表述测试中最小测试步骤实体；定义功能模型的结构与耦合规则，以将原子模型组合为具备测试应答交互的测试功能实体；通过功能模型的组合，生成测试场景模型，以实现过程复杂的测试流程实体；定义测试交互模型，为原子模型提供作为信息流端口的导入接口；构建特有的模型元素与行为，以生成测试场景模型的数据结构；实例化测试场景模型。通过采用上述方法，对测试场景模型进行了形式化描述，模型属性和行为采用数学的方式进行形式化描述，消除模型中的不确定性和歧异性。

说明书

技术领域

本申请涉及软件测试技术领域，特别是涉及一种形式化测试模型建模方法、系统、计算机及存储介质。

背景技术

随着数字化、信息化、智能化的普及与推广，现在软件系统的规模越来越大，复杂程度越来越高，模型驱动的软件工程方法逐渐成为业界主流。当前，采用基于模型的软件定义方法已经成为许多安全关键领域软件系统正向定义过程中的一项主要工程活动。在规模庞大和结构复杂的软件项目里，软件的需求、定义、仿真、测试工作均围绕模型进行开展。

在传统软件测试中，测试用例的描述通常采用自然语言描述，机器不能自动识别，难以用自动化方法进行测试，因此需要消耗大量人力和资源进行人工测试。同时，传统测试过程复现同样需要采用人工的方式进行，成本较高，且容易出错，具有较大的不确定性，不利于对测试用例进行大规模智能和自动化分析工作。

基于模型的测试技术可以通过形式化方式表述测试过程，根据规则制定行为和行为之间的约束与联系，基于被测系统的状态、设置的测试流程及测试策略来自动生成测试用例。是解决机器自动生成与识别的一个解决方案。但是，目前测试模型既缺乏顶层系统化定义，也缺少底层形式化描述，提出的许多测试模型中仍存在歧异性。

发明内容

本申请实施例提供了一种形式化测试模型建模方法、系统、计算机及存储介质，以解决目前测试模型中即缺乏顶层系统化定义，也缺少底层形式化描述，导致测试模型仍存在歧异性的技术问题。

第一方面，本申请实施例提供了一种形式化测试模型建模方法，其特征在于，包括：

定义原子模型的结构、类型、端口、属性及行为，用于表述测试中最小测试步骤实体；

定义功能模型的结构与耦合规则，以将所述原子模型组合为具备测试应答交互的测试功能实体；

通过所述功能模型的组合，生成测试场景模型，以实现过程复杂的测试流程实体；

定义测试交互模型，为所述原子模型提供作为信息流端口的导入接口；

构建特有的模型元素与行为，以生成所述测试场景模型的数据结构；

实例化所述测试场景模型。

进一步地，所述定义原子模型的结构、类型、端口、属性及行为的步骤包括：

通过七元组形式化描述所述原子模型的结构；

将所述原子模型定义为信息发送原子模型、信息接收原子模型及测试状态原子模型，以实现测试基本行为；

定义所述原子模型的开始端口和通过端口，以生成所述原子模型的控制关系，定义所述原子模型的信息输入端口和信息输出端口，以生成所述原子模型的数据关系；

定义所述原子模型的内部使用参数，以控制和约束所述原子模型的行为：

描述所述原子模型在仿真或执行过程中基于时间反应的动态行为。

进一步地，所述定义功能模型的结构与耦合规则，以将所述原子模型组合为具备测试应答交互的测试功能实体的步骤包括:

通过六元组形式化描述所述功能模型的结构；

通过连线的方式确定所述原子模型的耦合关系，以形成所述功能模型的逻辑行为，定义约束规则，以正确的完成所述功能模型的构建。

进一步地，所述定义测试交互模型，为所述原子模型提供作为信息流端口的导入接口的步骤包括：

通过三元组形式化描述所述测试交互模型的结构；

通过建立节点和带方向的连线，生成消息协议建模，以提取消息协议的交互关系属性。

进一步地，所述构建特有的模型元素与行为，以生成所述测试场景模型的数据结构的步骤包括：

定义图形化模型元素，组合所述图形化模型元素，以形式化构建所述测试场景模型；

根据所述测试场景模型的层级关系，生成所述测试场景模型的数据层级结构。

进一步地，所述实例化所述测试场景模型的步骤包括：

根据特定的软件测试环境和软件测试需求，创建所述测试场景模型，并生成测试用例。

第二方面，本申请实施例提供了一种形式化测试模型建模系统，用于所述形式化测试模型建模方法，其特征在于，所述系统包括：

第一构建模块，用于定义原子模型的结构、类型、端口、属性及行为，用于表述测试中最小测试步骤实体；

第二构建模块，用于定义功能模型的结构与耦合规则，以将所述原子模型组合为具备测试应答交互的测试功能实体；

第三构建模块，用于通过所述功能模型的组合，生成测试场景模型，以实现过程复杂的测试流程实体；

第四构建模块，用于定义测试交互模型，为所述原子模型提供作为信息流端口的导入接口；

第五构建模块，用于构建特有的模型元素与行为，以生成所述测试场景模型的数据结构；

创建模块，用于实例化所述测试场景模型。

进一步地，所述第一构建模块包括：

第一定义单元，用于通过七元组形式化描述所述原子模型的结构；

第二定义单元，用于将所述原子模型定义为信息发送原子模型、信息接收原子模型及测试状态原子模型，以实现测试基本行为；

第三定义单元，用于定义所述原子模型的开始端口和通过端口，以生成所述原子模型的控制关系，定义所述原子模型的信息输入端口和信息输出端口，以生成所述原子模型的数据关系；

第四定义单元，用于定义所述原子模型的内部使用参数，以控制和约束所述原子模型的行为；

第五定义单元，用于描述所述原子模型在仿真或执行过程中基于时间反应的动态行为。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的形式化测试模型建模方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的形式化测试模型建模方法。

相比于相关技术，本发明的有益效果在于：对测试场景模型进行了形式化描述，模型属性和行为采用数学的方式进行形式化描述，消除模型中的不确定性和歧异性。对高可靠的测试场景模型的构建提供了完善的数学理论支持，同时，提供了一个模块化、层次化模型框架。不可细分的测试步骤封装为具有独立内部属性、行为和明确I/O接口的原子模型，测试操作通过若干个原子模型通过一定的连接关系组成功能模型，测试场景模型通过更复杂的功能模型组成，不同模型间之间具有清晰的层次性与模块化，提出了一个图形化模型表示方法。对图形化建模界面，给出了一套原子模型、功能模型、测试交互模型、测试场景模型的模型元素的定义与描述，更便于用户快速应用。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本发明第一实施例中形式化测试建模方法的流程图；

图2为本发明第二实施例中形式化测试建模方法的流程图；

图3为本发明第一实施例中形式化测试建模方法中功能模型的构成图；

图4为本发明第二实施例中形式化测试建模方法中信息发送原子模型状态机描述图；

图5为本发明第二实施例中形式化测试建模方法中信息接收原子模型状态机描述图；

图6为本发明第二实施例中形式化测试建模方法中测试状态原子模型状态机描述图；

图7为本发明第一实施例中形式化测试建模方法中测试场景模型的构成图；

图8为本发明第二实施例中形式化测试建模方法中测试交互模型与原子模型的接口原理图；

图9为本发明第一实施例中形式化测试建模方法中测试场景模型的数据结构示意图；

图10为本发明第二实施例中形式化测试建模方法中以无人飞行器协同飞行控制任务需求为例所生成的测试交互模型的示例图；

图11本发明第二实施例中形式化测试建模方法中以无人飞行器协同飞行控制任务需求为例所生成的测试场景模型的示例图；

图12本发明第二实施例中形式化测试建模方法中以无人飞行器协同飞行控制任务需求为例所生成的功能模型的示例图；

图13为本发明第一实施例中形式化测试建模方法的层次框架图；

图14为本发明第三实施例中形式化测试建模系统的结构框图。

如下具体实施方式将结合上述附图进一步说明本发明。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些定义，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块（单元）的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

请参阅图1，本发明第一实施例提供的形式化测试模型建模方法。所述方法包括步骤S10至步骤S60：

步骤S10：定义原子模型的结构、类型、端口、属性及行为，用于表述测试中最小测试步骤实体；

所述原子模型是描述软件测试过程中信息输出、输出的最小单元实体，为建模过程中最基本模型。

步骤S20：定义功能模型的结构与耦合规则，以将所述原子模型组合为具备测试应答交互的测试功能实体；

可以理解地，所述功能模型通过其他模型组合构成，是一个耦合模型，构成的模型可以为所述原子模型，也可以为其他功能模型。

步骤S30：通过所述功能模型的组合，生成测试场景模型，以实现过程复杂的测试流程实体；

通过构建所述功能模型，以产生测试逻辑更为复杂的交互行为，所述功能模型的嵌套却容易让人产生认知复杂，增加所述测试场景模型中产生错误的可能。在定义所述功能模型时，规定了所述功能模型的嵌套层次。而所述测试场景模型是最外层的所述功能模型，请参阅图3，描述了所述测试场景模型通过所述功能模型的组合过程。

所述测试场景模型除了描述测试流程，往往需要从系统层次描述系统/软件在使用中的业务场景，涉及不同功能之间的连接问题。因此在定义所述测试场景模型时，将所述测试场景模型设置为一个专门的模型层次，在该层次，通过隐藏信息流的方式，实现所述测试场景模型的简化。保留的控制关系，通过带方向的箭头，标识所述功能模型的开始端口和通过端口。简化的所述测试场景模型为一个有向图。

步骤S40：定义测试交互模型，为所述原子模型提供作为信息流端口的导入接口；

在信息流中涉及消息协议实体，而一个测试过程中，可能需要向不同的被测系统/软件发送多个不同的消息信息。为了使所述原子模型和所述功能模型的定义松耦合，增加消息协议本身的复用性。通过构建一个独立的所述测试交互模型，进行消息协议定义。

在所述测试交互模型中对测试平台和被测对象的拓扑关系进行，并在连线上配置消息协议模型。

步骤S50：构建特有的模型元素与行为，以生成所述测试场景模型的数据结构。

通过定义建模编辑器，以构建特有的模型元素与行为，所述建模编辑器是人机交互的接口，优选地，所述建模编辑器包括：测试交互建模编辑器与测试场景建模编辑器。

步骤S60：实例化所述测试场景模型。

请参阅图13，所述形式化测试模型建模方法由两个部分构成：模型定义部分和模型应用部分。所述模型定义分为基础模型定义与高层模型定义。所述基础模型定义包含所述原子模型的定义与所述功能模型的定义，主要为所述测试场景模型提供数学理论支撑；所述高层模型定义包含所述测试场景模型和所述测试交互模型，所述测试交互模型为所述测试场景模型提供消息协议的接口。高层模型通过模型编辑器提供人机交互接口，在模型应用层中供测试人员建模使用，并根据实际的软件测试环境和测试场景创建实例化的所述测试场景模型，最后基于所述测试场景模型实现自动测试用例生成。模型应用层为一般使用方法，在实施过程中进行描述，以确保本发明的完整性。

对测试场景模型进行了形式化描述，模型属性和行为采用数学的方式进行形式化描述，消除模型中的不确定性和歧异性。对高可靠的测试场景模型的构建提供了完善的数学理论支持，同时，提供了一个模块化、层次化模型框架。不可细分的测试步骤封装为具有独立内部属性、行为和明确I/O接口的原子模型，测试操作通过若干个原子模型通过一定的连接关系组成功能模型，测试场景模型通过更复杂的功能模型组成，不同模型间之间具有清晰的层次性与模块化，提出了一个图形化模型表示方法。对图形化建模界面，给出了一套原子模型、功能模型、测试交互模型、测试场景模型的模型元素的定义与描述，更便于用户快速应用。

请参阅图2，本发明第二实施例提供的形式化测试模型建模方法，所述形式化测试模型建模方法通过代码于建模编辑器组件上实现。

所述方法包括步骤S100至步骤S112：

步骤S100：通过七元组形式化描述所述原子模型的结构；

将所述原子模型的结构定义为M,则M = ;其中IN是外部输入集；OUT是输出集合；S是模型状态集。

time是时钟运行函数，time(s)表示在没有外部输入到达时，模型状态保持为s的时钟数,s∈S,time(s)=+∞的模型状态称为静止。在无外部输入情况下，模型将保持静止（不工作）。time(s)=0的模型状态称为瞬时，表示在该状态下时钟不运行。

δinternal是内部转移函数。如无外部输入激发，系统经过time(s)时间后，状态s将转移到δinternal(s)的状态。

δexternal是外部转移函数，若有一外部输入in∈IN激发，模型在状态s已停留时间为t，则它立即转移到δexternal(s,in)。

f是输出函数，输出函数在模型状态发生转移时执行，在状态s发生转移时产生输出f(s)。

步骤S101：将所述原子模型定义为信息发送原子模型、信息接收原子模型及测试状态原子模型，以实现测试基本行为；

测试基本行为由发送消息和信息接收构成，最后通过组合原子模型的关系构成功能，所述信息发送原子模型、所述信息接收原子模型及所述测试状态原子模型的具体定义如下：

所述信息发送原子模型：在等候时间结束时发送一条消息；

所述信息接收原子模型：以等候时间内等待一条消息，收到消息时进行测试预言，确定通过/不通过状态；

所述测试状态原子模型：不接收和发送任何消息，在整个测试过程中获取从功能模型“开始”到最后一个非本原子模型的状态，并通过状态逻辑设置，完成功能的测试预言。是功能模型的结束节点。

步骤S102：定义所述原子模型的开始端口和通过端口，以生成所述原子模型的控制关系，定义所述原子模型的信息输入端口和信息输出端口，以生成所述原子模型的数据关系；

一个基础模型结构包含控制关系和数据关系。控制关系描述模型的进入与退出条件，包含两个端口：开始端口和通过端口；数据关系描述模型的输入与输出数据，包含两个端口：信息输入端口和信息输出端口。其具体定义如下：

开始端口：通过开始端口接收到外部触发事件，由外部事件激发模型状态进入一个新的状态。

通过端口：通过端口输出向下一个模型发送开始事件。通过端口有两个值，“通过”值与“失败”值，当为“通过”值时，激活下个模型的开始事件。当为“失败”值时，输出所述功能模型的外部通过端口值。

输入端口：由被测系统/软件产生的测试信息通过所述输入端口传输进入，由所述信息接收原子模型使用。进行信息输入时，模型必须处于休眠状态，否则，所述不发生状态变化。当模型通过所述输入端口接收到外部信息输入后，由外部事件激发使模型进入一个新的状态。

输出端口：这个输出端发送由所述信息发送原子模型产生测试信息数据到所述功能模型的信息输入端口。

步骤S103：定义所述原子模型的内部使用参数，以控制和约束所述原子模型的行为。

所述原子模型的端口定义从黑盒的角度描述了所述原子模型外部接口，所述原子模型内部使用的参数通过属性进行定义，属性是控制和约束所述原子模型行为的参数。如果初始为休眠信号，则所述原子模型启动时为休眠状态；如果初始为激活信号，则所述原子模型启动时为发送状态。

步骤S104：描述所述原子模型在仿真或执行过程中基于时间反应的动态行为；

具体地，所述动态行为的描述如下：

请参阅图4，所述信息发送原子模型表示与逻辑行为。信号表明了所述信息发送原子模型的初始状态，如果为激活，所述信息发送原子模型将以“发送状态”启动，否则，将以“休眠状态”启动。在“休眠状态”下，如果所述开始端口有输入值，则转移到“发送状态”，在等待时间结束后，f(s)产生两个输出，信息发送端口的数据和通过端口的“通过”值；同时，时间结束时，状态迁移到“休眠状态”。

请参阅图5，所述信息接收原子模型表示与逻辑行。在“休眠状态”下，如果所述开始端口有输入值，则转移到“接收状态”；在该状态下如果有所述信号输入端口传入数据，则状态迁移到“验收状态”，此时，f(s)产生一个输出，根据验证结果设置通过端口的“通过/失败”值；在“接收状态”下如果没有所述信号输入端口传入数据，在等待时间结束后，产生δinternal(s)，并转移到“延时状态”；f(s)产生一个输出，通过端口的“失败”值；同时，时间结束时，状态迁移到“休眠状态”。

请参阅图6，所述测试状态原子模型表示与逻辑行为。所述测试状态原子模型没有激活信号，只从“休眠状态”启动。所述测试状态原子模型的输入端为所述测试状态原子模型到所述功能模型“开始”之间所有的所述信息接收原子模型的“通过”端口信息，主要用于计算测试逻辑。如果所述开始端口有输入值，则转移到“验证状态”；在验证状态下，会根据测试逻辑计算当前测试状态是“通过”还是“失败”；并根据设置逻辑决定是否产生中断信号，如果有中断信号，产生δinternal(s)，进入“输出状态”，通过端口产生“通过/失败”值，否则状态迁移到“休眠状态”。

测试逻辑是根据之前所述消息接收原子模型的通过端口判断整个功能测试的状态。测试逻辑有：

如果所述开始端口收到任何“失败”值，则该模型的通过端口为“失败”；否者为“通过”。

如果所述开始端口收到指定的所述消息接收原子模型的通过端口的值为“失败”，则该模型的通过端口为“失败”；否者为“通过”。

中断信号产生的在“继续执行”和“错误退出”两个模式。模式必须事先设定。

在“继续执行”模式下，所述测试状态原子模型之前所有的所述原子模型都必须全部执行完毕，产生中断信号。

在“错误退出”模式下，所述测试状态原子模型的测试逻辑为“失败”时产生中断信号。

根据形式化描述构建基础模型类的属性和函数；根据所述原子模型的端口描述建立基础模型的端口子类；根据所述原子模型的属性描述建立基础模型的属性变量；根据所述原子模型的定义描述通过继承基础模型方式建立三类所述原子模型；根据所述信息发送原子模型、所述信息接收原子模型、所述测试状态原子模型的行为建立所述原子模型的状态行为函数。通过上述方法用代码实现原子模型类。

步骤S105：通过六元组形式化描述所述功能模型的结构；

将所述功能模型的结构定义为C，则C = ；

其中，IN是外部输入集；OUT是输出集合；N是功能模型中模型名称集；{Mi}是功能模型中的模型集，Mi(i∈N)是原子模型或功能模型。Ii是模型i的影响集。Tij是模型i到影响集Ii的输出转移函数。

步骤S106：通过连线的方式确定所述原子模型的耦合关系，以形成所述功能模型的逻辑行为，定义约束规则，以正确的完成所述功能模型的构建；

请参阅图7，所述功能模型由所述原子模型构成，而所述功能模型能够与其他的所述原子模型构成更为复杂的所述功能模型。

在所述功能模型的外部为基本模型结构的四个基本端口，所述开始端口、所述通过端口、所述信息输入端口和所述信息输出端口。内部通过所述原子模型进行耦合关联，形成所述功能模型的逻辑行为。耦合关系通过连线的方式进行确定。为了能够正确地完成所述功能模型构建,定义如下约束规则对所述功能模型的创建进行约束：

所述原子模型的通过端口只能连接其他所述原子模型的开始端口或所述功能模型的通过端口；

所述信息发送原子模型的信息输出端口自动连接所述功能模型的信息输出端口；

所述信息接收原子模型信息输入端口自动连接所述功能模型的信息输入端口；

所述测试状态原子模型的开始端口自动连接之前的其他的所述信息接收原子模型的通过端口；

所述功能模型可以包含多个所述信息发送原子模型、所述信息接收原子模型和所述测试状态原子模型，在一个所述功能模型中至少要使用一个所述信息发送原子模型或所述信息接收原子模型。

所述功能模型必须以所述测试状态原子模型结束。

所述功能模型的嵌套不超过两层。

根据形式化描述构建所述功能模型的属性和函数；根据所述功能模型的规则构建所述功能模型中所述原子模型的约束函数；通过上述方法用代码实现功能模型类。

以创建无人飞行器协同飞行控制任务的实例化测试场景模型为例。地面控制站为仿真对象，模拟地面控制站向三架无人飞行器发送协同控制命令。

打开所述建模编辑器组件的功能模型图层，对所述原子模型进行定义。

在功能界面放置需要的所述原子模型，对所述原子模型中的端口和属性进行实例参数设置，完成所述功能模型的测试过程描述。请参阅图12，所述功能模型中包含三个所述信息发送原子模型，分别为由地面控制站向三个无人机飞行器发送空中协同指令，并设置三个所述信息接收原子模型，分别为等待三个无人机飞行器返回航迹方位信息。构建过程如下：初次打开功能模型图层时会创建一个空白的功能模型容器。

首先，在容器中放置三个所述信息发送原子模型，分别命名“空中航迹信息指令A”、“空中航迹信息指令B”、“空中航迹信息指令C”，分别表示由地面控制站向三个无人机发送空中协同飞行指令。双击打开所述“空中航迹信息指令A”，会打开“空中航迹信息指令A”的属性项编辑，其中会显示由测试交互模型提供的发送消息列表，在所述发送消息列表包含空中协同指令A、空中协同指令B与空中协同指令C。选择空中协同指令A作为消息协议，并对消息协议中的具体协议字段进行赋值，完成协议发送数据的实例化。同时确定等待时间为50ms，模型初始信号为“激活”（只有“空中航迹信息指令A”为“激活”状态）。依次打开空中“空中航迹信息指令B”与“空中航迹信息指令C”，完成相应协议数据进行实例化，与“空中航迹信息指令A”不同的是模型初始信号为“休眠”。

其次，通过“控制连线”将“空中航迹信息指令A”的S端口连接到容器的S端口，将“空中航迹信息指令A”的P端口连接到“空中航迹信息指令B”的S端口，表示执行的顺序逻辑；通过“数据连线”将“空中航迹信息指令A”的O端口连接到容器的O端口，表示数据关联关系。依次完成“空中航迹信息指令B”和“空中航迹信息指令C”的“控制连线”与“数据连线”的连接。

接着，在容器中放置三个所述信息接收原子模型，分别命名“等待接收无人A定位指令”、“等待接收无人B定位指令”、“等待接收无人C定位指令”，分别表示由地面控制站接收三个无人机返回的空中航迹（接收）消息。双击打开“等待接收无人A定位指令”的属性项编辑，其中会显示由测试交互模型提供的接收消息列表，所述接收消息列表包含空中航迹A（接收）消息、空中航迹B（接收）消息与空中航迹C（接收）消息。选择空中航迹A（接收）消息作为“等待接收无人A定位指令”的消息协议，并对消息协议中的具体协议字段进行测试断言，完成接收协议断言的实例化。同时确定等待时间为1000ms，模型初始信号为“休眠”。依次打开“等待接收无人B定位指令”与“等待接收无人C定位指令”，完成相应接收协议断言的实例化。

其次，通过“控制连线”将“等待接收无人A定位指令”的S端口连接到“空中航迹信息指令C”的P端口，将“等待接收无人A定位指令”的P端口连接到“等待接收无人B定位指令”的S端口，表示执行的顺序逻辑；通过“数据连线”将空中“等待接收无人A定位指令”的输入端I端口连接到容器的I端口，表示数据关联关系。依次完成“等待接收无人B定位指令”和“等待接收无人C定位指令”的“控制连线”与“数据连线”的连接。

最后，放置所述测试状态原子模型，实现对所述功能模型的测试逻辑断言。测试状态是对所述功能模型中需要进行断言的所述原子模型进行组合判定，其中提供“逻辑与&&”、“逻辑或||”和“逻辑非！”三种逻辑组合。

首先将三个接收协议的输出端口P端口用“数据连线”连接到测试状态，随后双击打开所述测试状态原子模型的编辑界面，设置逻辑关系为：“等待接收无人A定位指令”&&“等待接收无人B定位指令” &&“等待接收无人C定位指令”。测试状态将三个所述信息接收原子模型的测试断言情况，执行逻辑运算，实现最终的所述功能模型的逻辑判定。

步骤S107：通过所述功能模型的组合，生成测试场景模型，以实现过程复杂的测试流程实体；

所述测试场景模型是一种所述功能模型，其继承所述功能模型父类；根据所述测试场景模型的简化原理，构建所述测试场景模型行为函数；通过上述方法用代码实现测试场景模型类。

所述功能模型的正确性和无二异性通过所述原子模型的实例化和耦合规则的约束共同实现。错误的模型构建将导致模型通不过检测。在所述原子模型的组合中通过耦合规则实现建模的规范，从而保证所述功能模型的测试信息表达的正确性和唯一性。

例如，如果不以所述测试状态原子模型结束，违背耦合规则时，在建模结束给出相应错误提示。所述功能模型不包含所述信息发送原子模型或所述信息接收原子模型收，在建模结束时给出错误提示。完成所有的所述功能模型中的所述原子模型的定义，生产所述测试场景模型。

步骤S108：通过三元组形式化描述所述测试交互模型的结构；

所述测试交互模型通过平台模型和连线模型构成，将所述测试交互模型的结构定义为：I，则I = < N, E, {MSGe}>；

其中，N是测试交互模型中节点集；E是测试交互模型中连线集，E(i,j)(i, j∈N)是节点模型i到节点模型j的连线；{MSGe}，即MSGe(e∈E)是连线e上消息协议集。

步骤S109：通过建立节点和带方向的连线，生成消息协议建模，以提取消息协议的交互关系属性；

请参阅图8，所述测试交互模型由节点和带方向的连线构成，在模型编辑器的界面上通过建立节点和连线的方式可以针对测试平台和被测对象的拓扑关系进行建模。通过双击连线打开连线模型上的消息协议建模。所述消息协议建模是针对消息的数据结构进行构建，建立完毕后可以结合连线的起点和终点的属性，提取消息协议的交互关系属性。

通过提取所述测试交互模型中的所有消息协议可建立两个消息协议列表：发送消息协议表和信息接收协议表，所述发送消息协议表包含所有的以测试平台为起始的发送消息；所述发送消息协议表包含所有以测试平台为终点的信息接收。所述发送消息协议表将作为所述发送消息原子模型中的信息输出接口，所述发送消息协议表将作为所述信息接收原子模型的信息输入接口。通过从所述消息协议表中选择消息协议的方式，可实现协议模型与所述测试场景模型的松耦合，方便模型之间的调用。

根据形式化描述构建基础模型类的属性和函数；通过上述方法用代码实现测试交互模型类。

步骤S110：定义图形化模型元素，组合所述图形化模型元素，以形式化构建所述测试场景模型。

通过自定义的所述图形化模型元素，代替具体的属性行为，以将所述测试场景模型以图形化的方式呈现；

步骤S111：根据所述测试场景模型的层级关系，生成所述测试场景模型的数据层级结构。

通过图形化建模编辑器将模型元素组合起来，从而形式化构建所述测试场景模型。所述测试交互模型是一个辅助模型，本身不包含测试信息，主要功能是为所述原子模型提供公共的消息协议列表接口，所述消息协议模型本身不提供具体数据。

所述测试场景模型包含具体的消息协议、数据信息，以及测试流程的信息交互逻辑，具有一个完整测试交互流程所包含的所有信息。因此测试序列生成及模型中测试数据提取工作主要集中在所述测试场景模型中，针对所述测试场景模型的数据结构定义是将图形化模型映射到数据层的关键。

请参阅图9，根据所述测试场景模型的层级关系，定义了模型数据层级结构。优选地，数据层级关系通过Xml文件实现数据格式存储。模型数据中不仅包含了测试模型的数据信息，也包含了图形界面的绘制信息。通过Xml文件方便在下次打开模型文件时，可以重新将数据映射到编辑器中，实现图形化模型的还原和模型的二次编辑。

创建建模编辑器基类，包含图形画布基本属性和功能函数；为建模编辑器基类添加模型的新建、打开、删除、关闭基本功能，添加图形元素的选择、增加、删除、移动、复制、剪切、拷贝和保存等基本建模使用功能；分别创建所述测试交互建模编辑器和所述测试场景建模编辑器，均继承至建模编辑器基类；为所述测试交互建模编辑器增加图形化模型元素，并定义模型元素的属性和行为函数；为所述测试场景建模编辑器增加图形化模型元素，并定义模型元素的属性和行为函数；为所述测试交互建模编辑器增加消息协议建模图层，该图层通过双击测试交互模型中连线进行打开；为所述测试场景建模编辑器增加功能模型编辑图层，该图层通过双击测试场景模型中耦合节点进行打开；所述功能模型的图层包含功能模型元素和原子模型元素。在所述原子模型的信息流端口中增加打开所述测试交互模型的消息协议列表接口。所述测试场景建模编辑器的保存功能实现测试场景图形化模型到XML文件转换。通过上述方法用代码实现建模编辑器组件。

以创建无人飞行器协同飞行控制任务的实例化测试场景模型为例，将建模编辑器组件通过“视图”切换到测试交互建模编辑器模式，并创建无人飞行器协同飞行控制任务的测试交互模型。首先创建测试平台，命名“地面控制站”，以测试平台模拟地面控制站发送指令信息，其次创建3个无人机被测系统“无人飞行器A”、“无人飞行器B”与“无人飞行器C”。通过“连线”方式将地面控制站与3个无人机被测系统连接，“连线”描述了地面控制站与三架无人飞行器的连接关系，请参阅图10，可以看出地面控制站与无人飞行器的交互是双向的。通过双击测试交互编辑中创建好的“连线”，打开消息协议创建界面。在界面的填入符合该交互方向的消息协议信息，该消息协议描述测试平台与被测对象之间通讯消息的协议规定与约束，包含协议字段格式、类型和长度，为一个未实例化的协议模板。

对所述测试交互模型中所有的“连线”进行协议创建，完成所述测试交互模型的协议编辑，如下表：

步骤S112：根据特定的软件测试环境和软件测试需求，创建所述测试场景模型，并生成测试用例。

将所述建模编辑器组件通过“视图”切换到测试场景建模编辑器模式，在测试场景建模编辑器中创建无人飞行器协同飞行控制任务的测试场景模型。通过模型区中选择“起始节点”与“结束节点”，在画布编辑器中放置，随后选择“功能模型节点”，根据需求描述，设计所述测试场景模型中的所述功能模型。无人飞行器协同飞行控制任务包含初始化控制字、协同控制、精确定位、巡航指令、航路规划几个核心功能，创建对应的所述功能模型并命名，同时通过“连线”方式，连接不同的所述功能模型，该模型中的“连线”描述了不同功能之间顺序执行逻辑，连线的箭头表示顺序关系，请参阅图11，为绘制完的所述测试场景模型。

所述测试场景模型显示从开始到结束中的测试场景信息，包含多条路径分支，每条路径均是对软件任务需求的图形化描述。需要注意的是，该阶段创建的所述功能模型仅对需求进行抽象地设计，未对测试具体步骤进行实现，其实际测试流程需要将所述原子模型通过耦合以体现。因此，需要优先定义所述原子模型。

完成所述功能模型的建模工作后的所述测试场景模型为完整的模型，在完整的模型基础上，可以通过人工选择或自动生成的方式，完成基于模型的测试用例自动生成工作。自动生成可采用基于图论的遍历算法，如深度优先搜索算法、遗传算法等。对无人飞行器协同飞行控制任务的测试场景模型采用深度优先搜索自动生成的测试用例如下表所示：

需要注意的是，可以同时创建多个所述测试场景模型。根据不同的所述测试场景模型生成具有不同测试意图的测试用例。

请参阅图14，本发明第三实施例提供了一种形式化测试模型建模系统，该系统应用于所述形式化测试建模方法，并实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”、“单元”、“子单元”等可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

所述系统包括：

第一构建模块10，用于定义原子模型的结构、类型、端口、属性及行为，用于表述测试中最小测试步骤实体；

优选地，所述第一构建模块10包括：

第一定义单元，用于通过七元组形式化描述所述原子模型的结构；

第二定义单元，用于将所述原子模型定义为信息发送原子模型、信息接收原子模型及测试状态原子模型，以实现测试基本行为；

第三定义单元，用于定义所述原子模型的开始端口和通过端口，以生成所述原子模型的控制关系，定义所述原子模型的信息输入端口和信息输出端口，以生成所述原子模型的数据关系；

第四定义单元，用于定义所述原子模型的内部使用参数，以控制和约束所述原子模型的行为；

第五定义单元，用于描述所述原子模型在仿真或执行过程中基于时间反应的动态行为。

第二构建模块20，用于定义功能模型的结构与耦合规则，以将所述原子模型组合为具备测试应答交互的测试功能实体；

优选地，所述第二构建模块20包括：

第六定义单元，用于通过六元组形式化描述所述功能模型的结构；

第七定义单元，用于通过连线的方式确定所述原子模型的耦合关系，以形成所述功能模型的逻辑行为，定义约束规则，以正确的完成所述功能模型的构建。

第三构建模块30，用于通过所述功能模型的组合，生成测试场景模型，以实现过程复杂的测试流程实体；

第四构建模块40，用于定义测试交互模型，为所述原子模型提供作为信息流端口的导入接口；

优选地，所述第四构建模块40包括：

第八定义单元，用于通过三元组形式化描述所述测试交互模型的结构；

第九定义单元，用于通过建立节点和带方向的连线，生成消息协议建模，以提取消息协议的交互关系属性。

第五构建模块50，用于构建特有的模型元素与行为，以生成所述测试场景模型的数据结构；

优选地，所述第五构建模块50包括：

第一组合单元，用于定义图形化模型元素，组合所述图形化模型元素，以形式化构建所述测试场景模型；

第二组合单元，用于根据所述测试场景模型的层级关系，生成所述测试场景模型的数据层级结构。

创建模块60，用于实例化所述测试场景模型。

具体地，所述创建模块60用于根据特定的软件测试环境和软件测试需求，创建所述测试场景模型，并生成测试用例。

本发明还提供了一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述技术方案中所述的基于AUTOSAR Adaptive的服务调用链追踪方法。

本发明还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述技术方案中所述的基于AUTOSAR Adaptive的服务调用链追踪方法。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。