CN108508867A - 基于行为驱动脚本的车载控制器软件测试系统及方法 - Google Patents

Abstract

本发明涉及一种基于行为驱动脚本的车载控制器软件测试系统及方法，包括：行为驱动脚本解析模块M1，用于对基于行为驱动的测试脚本进行解析，生成能够被测试系统所识别的机器指令输入；测试执行模块M2，用于以行为驱动脚本解析模块M1产生的机器指令作为输入，实时模拟仿真被测车载控制器软件外围接口消息及数据，向被测车载控制器软件提供激励反馈，并实时监控测试系统运行状态；测试结果记录及分析模块M3，记录被测车载控制器软件运行过程产生的输出数据以及测试系统的运行数据，并根据行为驱动脚本解析模块M1中给出的结果分析判定脚本语句，判定测试通过与否。与现有技术相比，本发明具有更易读，易掌握，人机交互友好等优点。

Description

基于行为驱动脚本的车载控制器软件测试系统及方法

技术领域

本发明涉及一种轨道交通车载控制器软件测试系统及方法，尤其是涉及一种基于行为驱动脚本的车载控制器软件测试系统及方法。

背景技术

随着我国轨道交通行业高速发展，车载控制器软件的功能需求日益复杂，而对于这类高可信嵌入式软件的测试是验证软件功能和确认软件具有足够安全性防护能力的重要手段，测试结果也是对这类软件进行安全评估的重要依据。高可信嵌入式软件要求测试用例对软件需求的覆盖率需达到100％，应覆盖到所有可能的正常和异常场景，因此测试工作量巨大，仅靠人工手段难于全面覆盖，并且成本可观。

自动化测试是提高测试效率和质量，降低测试成本的有效手段。而脚本技术是实现软件测试自动化的重要方法，其中，测试脚本语言是脚本技术的核心，采用测试脚本语言对测试用例加以描述，通过构建可自动执行的脚本，可以提高软件测试的质量和可维护性，大大减少测试人员的工作量。

然而，传统的测试脚本存在以下不足：

(1)脚本的可读性、复用性差；可读性差表现在的脚本的个体差异性大，测试人员往往无法准确理解其他测试人员编写的脚本，不利于测试工作的动态调配，复用性差表现在脚本无法快速、准确地移植到不同项目的软件测试中；

(2)测试用例编写和测试脚本的编写存在重复劳动；测试用例描述了测试某一个需求功能点的数据、操作步骤和预期结果，是测试过程的具体刻画，测试脚本是为了在测试系统中实现测试用例的输入和步骤的一个翻译的过程，这两个过程完全有可能合二为一；

(3)车载控制器软件对时序和数据流的动态变化高度敏感，而相应的有相当一部分测试工作是围绕这类特性展开的。但传统测试脚本技术缺乏对这类测试结果判定分析的有效方法。

因此，如何实现一种既有针对性，同时又能高效地对车载控制器软件进行基于脚本的自动化测试方法就变得越来越紧迫。

发明内容

本发明的目的就是为了克服上述现有技术存在的传统自动测试脚本可读性差，对轨道交通专业领域时序判断支持度不够等缺陷而提供一种基于行为驱动脚本的车载控制器软件测试系统。

本发明的目的可以通过以下技术方案来实现：

一种基于行为驱动脚本的车载控制器软件测试系统，包括：

行为驱动脚本解析模块M1，用于对基于行为驱动的测试脚本进行解析，生成能够被测试系统所识别的机器指令输入；

测试执行模块M2，用于以行为驱动脚本解析模块M1产生的机器指令作为输入，实时模拟仿真被测车载控制器软件外围接口消息及数据，向被测车载控制器软件提供激励反馈，并实时监控测试系统运行状态；

测试结果记录及分析模块M3，记录被测车载控制器软件运行过程产生的输出数据以及测试系统的运行数据，并根据行为驱动脚本解析模块M1中给出的结果分析判定脚本语句，判定测试通过与否。

优选地，所述的基于行为驱动的测试脚本，是指一种自定义且对人阅读友好的用来描述被测车载控制器软件及其周围系统行为的通用语言CASSL。

优选地，所述的CASSL的基本构成包括两部分：

初始配置部分，这是对列车初始状态和地图线路的配置部分，该部分对运行线路、起始位置、车身长度、列车行驶方向和列车控制器的方向进行配置；

场景序列部分，这是测试场景序列描述部分，测试场景序列有两种，包括动作Action和触发器Trigger。

优选地，所述的初始配置部分包含五项属性：

1)route_setting：代表的是列车地图线路的配置，由一连串顺序的地图坐标用逗号隔开表示；

2)start_setting：代表的是列车起始位置坐标配置；

3)length_setting：代表的是列车车身长度的配置；

4)direction_setting：代表的是列车行驶方向的配置；

5)cog_dir_setting：代表的是列车控制器的方向的配置。

优选地，所述的场景序列共有五种常见的动作：

1)start_action：起始动作；格式为：start(pos,time)，参数pos指位置信息，time指时间，它的含义是从pos位置开始，等待time的时间；

2)stop_action：停止动作；格式为：stop(pos)，参数pos指的是位置信息，它的含义是在pos位置停车，速度变为0；

3)run_action：匀速运行动作；格式为：run(pos)，参数pos指的是位置信息，它的含义是匀速运行到pos位置；

4)acc_action：匀加速运行动作；格式为：acc(accel,time)，参数accel指的是加速度，time指的是时间，它的含义是以accel的加速度运行time的时间；

5)acc_to_action”：匀加速运行动作；格式为：acc_to(pos,speed)，参数pos指的是位置信息，speed是速度，它的含义是从pos位置开始匀加速，直到速度变为speed为止。

一种基于行为驱动脚本的车载控制器软件测试系统的测试方法，包括以下步骤：

步骤S1：根据被测车载控制器软件需求，针对具体软件功能点设计测试场景，用基于行为驱动的脚本语言对测试场景加以刻画和描述；同时，给出相应的结果分析判定条件脚本；

步骤S2：将步骤S1中设计完成的给基于行为驱动的测试脚本以及结果分析判定条件脚本放入脚本解析模块M1，对其进行解析，生成对应的能被测试系统识别的机器指令；

步骤S3：对步骤S2中生成的机器指令进行检查和校验，包括语法正确性和物理意义正确性，对于通过检查校验的测试脚本将分别进入步骤S4和S5，对于没有通过检查校验的测试脚本，则给出错误提示信息，对脚本进行修改，并返回步骤S1；

步骤S4：对于通过步骤S3检查校验的测试脚本，结合组织过程资产中的测试用例模板，生成自然语言描述的测试用例；

步骤S5：将通过步骤S3检查校验的测试脚本送入测试执行模块M2，测试系统根据机器指令仿真模拟被测车载控制器软件外围接口消息和数据，从而驱动被测车载控制器软件执行；

步骤S6：记录步骤S5测试执行过程中被测对象以及测试系统产生的记录和输出；在完成测试执行后，依据步骤S2正确解析出的结果分析判定条件分析测试结果，判定测试是否通过。

与现有技术相比，本发明具有以下优点：

1、相较于传统测试脚本更易读，易掌握，人机交互友好。对于编写测试用例的人员没有编程基础要求，即测试人员可能精通业务逻辑，但可以不精通程序开发；

2、将被测软件的功能和接口解耦，被测软件的具体接口实现不影响测试脚本的设计编写，使测试脚本可以在不同项目的同类软件的测试中服用；

3、将测试用例和测试脚本以及测试报告高度整合，有利于持续集成，省去了测试用例到测试脚本的翻译过程。

附图说明

图1为场景语言转换为脚本的规则示意图；

图2为本发明测试系统结构示意图；

图3为本发明测试方法的流程图；

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。

如图2所示，是本发明基于行为驱动脚本的轨道交通车载控制器软件测试系统的结构示意图。本实施例中基于行为驱动脚本的轨道交通车载控制器软件测试系统包括：行为驱动脚本的解析模块M1，测试执行模块M2以及结果记录及分析模块M3。

其中，行为驱动脚本的解析模块M1是对基于行为驱动的测试脚本进行解析，生成能够被测试系统所识别的机器指令输入，例如，将描述“列车里程计失效时”的测试脚本解析为列车模型，列车动力学参数，外围系统消息以及触发故障仿真的机器指令。测试执行模块M2以行为驱动脚本解析模块M1产生的机器指令作为输入，实时模拟仿真被测车载控制器软件外围接口消息及数据。例如，根据列车模型，列车动力学参数，外围系统消息以及触发故障仿真的机器指令实时生成接口数据，给被测车载控制器软件以激励，并产生反馈。结果记录及分析模块M3记录被测车载控制器软件运行过程产生的输出数据以及测试系统的运行数据，并根据模块M1中给出的结果分析判定脚本语句，判定测试通过与否。

为了描述上文中的“测试场景”，本专利设计了一种基于行为驱动的脚本语言--CASSL。

CASSL的基本构成包括两部分：

·初始配置部分。这是对列车初始状态和地图线路的配置部分，该部分对运行

线路、起始位置，车身长度，列车行驶方向，列车控制器的方向进行配置。

·场景序列部分。这是测试场景序列描述部分，测试场景序列有两种，动作Action，和触发器Trigger。

CASSL所描述的测试场景结构如上面的代码所示。以关键字“train”开头并用花括号括起来的部分是列车初始状态与地图线路配置部分。可以看到，里面有一些变量的名称，以及对应的赋值。测试序列部分是由一些->开头的函数调用组成。

本专利分别从这两部分对CASSL的语法和语义进行详细的描述。

初始配置对初始配置的语法定义见代码清单1。

其中，1-6行定义了train的基本书写格式，类似于Python的结构体样式。

7-13行定义了train的结构体内部的属性。

14-28则分别定义了这五项属性的值的规范。

表1

初始配置共包含五项属性：

1)route_setting：代表的是列车地图线路的配置，由一连串顺序的地图坐标用逗号隔开表示；

2)start_setting：代表的是列车起始位置坐标配置；

3)length_setting：代表的是列车车身长度的配置。在这里，列车不能被看作质点，因为列车车身相比于行驶距离来说是不可忽略的一项内容。

4)direction_setting：代表的是列车行驶方向的配置。因为一般列车前后各有一个车头，两个方向都可以运行，把其中任何一个看做车头的话，那么另外一个便是车尾。

5)cog_dir_setting：代表的是列车控制器的方向的配置。列车上一般都有两个同样的列车控制器，分别位于车头和车尾，列车运行前要选择其中一个作为主控制器，因为不同的选择对于列车行驶距离的计算是不同的。一般将车头的控制器作为主控制器。

对于初始配置的书写格式，我们举例来如说明，代码如下所示：

其中，#(247,0)表示的是位置坐标。第一个参数是BlockID，第二个参数是相对长度。意为相对从第247个Block开始，长度为0的位置。

场景序列对场景步骤场景序列的文法定义见表2。

其中，1-7行定义了场景步骤的基本格式。场景有一个或多个场景步顺序组成，一个步骤可以是动作，也可以是触发器。对场景步我们设计了一个特殊的步骤符号->，位于一个场景步的起始位置。

8-29行定义了动作的基本格式和五种常见动作的规范。

30-35定义了触发器的基本格式，以及触发操作语句规范。

共有五种常见的动作：

1)start_action：起始动作。格式为：start(pos,time)。参数pos指位置信息，time指时间。它的含义是从pos位置开始，等待time的时间。

2)stop_action：停止动作。格式为：stop(pos)。参数pos指的是位置信息。它的含义是在pos位置停车，速度变为0。

3)run_action：匀速运行动作。格式为：run(pos)。参数pos指的是位置信息。它的含义是匀速运行到pos位置。

4)acc_action：匀加速运行动作。格式为：acc(accel,time)。参数accel指的是加速度，time指的是时间。它的含义是以accel的加速度运行time的时间。

表2

5)acc_to_action”：匀加速运行动作。格式为：acc_to(pos,speed)。参数pos指的是位置信息，speed是速度。它的含义是从pos位置开始匀加速，直到速度变为speed为止。

如下代码所示，是对CASSL场景序列的一个举例。该例子中的每一个序列会面都有相应的注释。其中，每一个场景步都有其对应的注释。

其中，@84是绝对位置的表示方式，意为位置84。

如图3所示，本实施例基于行为驱动脚本的轨道交通车载控制器软件测试系统用于测试车载控制器软件的列车信标初始化定位状态管理功能的一具体过程，包括以下步骤：

步骤S1，根据被测车载控制器软件需求，针对列车信标初始化定位状态管理功能中“当列车里程计失效时，车载控制器软件退出信标初始化定位状态”的这一功能点，设计测试场景，用基于行为驱动的脚本语言对该测试场景加以描述。如下脚本段中定义了模拟列车的基本属性和模拟列车初始化定位后发生里程计失效的物理场景，其中，列车基本属性包括运行线路，初始位置，车身长度以及运行方向；物理场景中描述了列车的动力学行为和外围系统的接口消息行为，具体脚本如下所示：

同时，给出源自被测系统功能需求的结果分析判定条件脚本，如下所示：

def MovingInitialByBeacon(k):

if ValidOdometerState(k)！＝True:

return False

步骤S2，将步骤S1中设计完成的给基于行为驱动的测试脚本以及结果分析判定条件脚本放入脚本解析模块M1，对其进行解析，生成对应的能被测试系统识别的机器指令，在本实例中，测试系统根据解析后的测试脚本仿真列车模型，列车动力学参数，外围系统消息以及触发故障；

步骤S3，对步骤S2中生成的机器指令进行检查和校验，包括语法正确性和语义正确性，对于通过检查校验的测试脚本将直接进入步骤S4和S5；

步骤S4，对于通过步骤S3检查校验的测试脚本，结合组织过程资产中的测试用例模板，生成自然语言描述的测试用例；

步骤S4：对于通过步骤S3检查校验的测试脚本，结合组织过程资产中的测试用例模板，生成自然语言描述的测试用例；

步骤S5：将通过步骤S3检查校验的测试脚本送入测试执行模块M1,测试系统根据机器指令仿真模拟被测车载控制器软件外围接口消息和数据，从而驱动被测车载控制器软件执行；

步骤S6，记录步骤S5测试执行过程中被测对象以及测试系统产生的记录和输出；在完成测试执行后，依据步骤S2正确解析出的结果分析判定条件分析测试结果，判定测试是否通过。

本实施例中，将某一正式版本的车载控制器软件作为被测对象，在本发明基于行为驱动脚本的轨道交通车载控制器软件测试系统中运行上述测试脚本，测试结果显示“当列车里程计失效时，车载控制器软件退出信标初始化定位状态”的这一被测软件功能点对应的用例通过测试。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (6)

1.一种基于行为驱动脚本的车载控制器软件测试系统，其特征在于，包括：

行为驱动脚本解析模块M1，用于对基于行为驱动的测试脚本进行解析，生成能够被测试系统所识别的机器指令输入；

测试执行模块M2，用于以行为驱动脚本解析模块M1产生的机器指令作为输入，实时模拟仿真被测车载控制器软件外围接口消息及数据，向被测车载控制器软件提供激励反馈，并实时监控测试系统运行状态；

测试结果记录及分析模块M3，记录被测车载控制器软件运行过程产生的输出数据以及测试系统的运行数据，并根据行为驱动脚本解析模块M1中给出的结果分析判定脚本语句，判定测试通过与否。

2.根据权利要求1所述的系统，其特征在于，所述的基于行为驱动的测试脚本，是指一种自定义且对人阅读友好的用来描述被测车载控制器软件及其周围系统行为的通用语言CASSL。

3.根据权利要求2所述的系统，其特征在于，所述的CASSL的基本构成包括两部分：

初始配置部分，这是对列车初始状态和地图线路的配置部分，该部分对运行线路、起始位置、车身长度、列车行驶方向和列车控制器的方向进行配置；

场景序列部分，这是测试场景序列描述部分，测试场景序列有两种，包括动作Action和触发器Trigger。

4.根据权利要求3所述的系统，其特征在于，所述的初始配置部分包含五项属性：

1)route_setting：代表的是列车地图线路的配置，由一连串顺序的地图坐标用逗号隔开表示；

2)start_setting：代表的是列车起始位置坐标配置；

3)length_setting：代表的是列车车身长度的配置；

4)direction_setting：代表的是列车行驶方向的配置；

5)cog_dir_setting：代表的是列车控制器的方向的配置。

5.根据权利要求3所述的系统，其特征在于，所述的场景序列共有五种常见的动作：

1)start_action：起始动作；格式为：start(pos,time)，参数pos指位置信息，time指时间，它的含义是从pos位置开始，等待time的时间；

2)stop_action：停止动作；格式为：stop(pos)，参数pos指的是位置信息，它的含义是在pos位置停车，速度变为0；

3)run_action：匀速运行动作；格式为：run(pos)，参数pos指的是位置信息，它的含义是匀速运行到pos位置；

4)acc_action：匀加速运行动作；格式为：acc(accel,time)，参数accel指的是加速度，time指的是时间，它的含义是以accel的加速度运行time的时间；

5)acc_to_action”：匀加速运行动作；格式为：acc_to(pos,speed)，参数pos指的是位置信息，speed是速度，它的含义是从pos位置开始匀加速，直到速度变为speed为止。

6.一种采用权利要求1所述的基于行为驱动脚本的车载控制器软件测试系统的测试方法，其特征在于，包括以下步骤：

步骤S1：根据被测车载控制器软件需求，针对具体软件功能点设计测试场景，用基于行为驱动的脚本语言对测试场景加以刻画和描述；同时，给出相应的结果分析判定条件脚本；

步骤S2：将步骤S1中设计完成的给基于行为驱动的测试脚本以及结果分析判定条件脚本放入脚本解析模块M1，对其进行解析，生成对应的能被测试系统识别的机器指令；

步骤S3：对步骤S2中生成的机器指令进行检查和校验，包括语法正确性和物理意义正确性，对于通过检查校验的测试脚本将分别进入步骤S4和S5，对于没有通过检查校验的测试脚本，则给出错误提示信息，对脚本进行修改，并返回步骤S1；

步骤S4：对于通过步骤S3检查校验的测试脚本，结合组织过程资产中的测试用例模板，生成自然语言描述的测试用例；

步骤S5：将通过步骤S3检查校验的测试脚本送入测试执行模块M2，测试系统根据机器指令仿真模拟被测车载控制器软件外围接口消息和数据，从而驱动被测车载控制器软件执行；

步骤S6：记录步骤S5测试执行过程中被测对象以及测试系统产生的记录和输出；在完成测试执行后，依据步骤S2正确解析出的结果分析判定条件分析测试结果，判定测试是否通过。