用于轨道交通车载控制器软件的测试脚本自动化检测方法
【专利摘要】本发明涉及一种用于轨道交通车载控制器软件的测试脚本自动化检测方法，包括以下步骤：步骤S101，加载测试脚本并对测试脚本作初步检查；步骤S102，对通过步骤S101中的初步检查的测试脚本进行解析；步骤S103，对车载控制器软件需求进行建模，利用步骤S102解析展开后的周期性数据作为输入，对需求模型进行仿真；步骤S104，结果比对，将步骤S103中得到的模型仿真输出与步骤S101测试脚本设计的预期结果进行对比分析，以检查测试脚本的正确性。与现有技术相比，本发明具有填补了轨道交通车载软件测试脚本验证检测自动化的空白，能够真正实现计算机对测试脚本内容正确性的实质检测等优点。
【专利说明】
用于轨道交通车载控制器软件的测试脚本自动化检测方法
技术领域
[0001]本发明涉及一种测试脚本检测方法，尤其是涉及一种用于轨道交通车载控制器软件的测试脚本自动化检测方法。
【背景技术】
[0002]随着我国轨道交通行业高速发展，车载控制器软件的更新换代日趋频繁，其功能也日益复杂。与此同时，给相关的软件测试工作带来的压力也越来越大。基于脚本的自动化测试具有可复现性好、可复用性高，尤其适用回归测试的特点，是减轻测试执行工作压力、提高测试效率的一种有效手段。然而，测试脚本的质量和正确性是基于脚本的自动化测试的核心，将直接影响到测试的质量和可信度。目前，主要是以人工检测的手段来保证测试脚本的质量。
[0003]在现有技术中，测试人员和验证人员需要根据测试用例检测测试脚本和测试用例的一致性和正确性，以确保之后测试阶段使用的测试脚本质量的可控。因为车载控制器软件测试的特殊性，脚本的执行是没有编译的，直接解释执行，所以，目前测试脚本的检测要通过人工完成。
[0004]此种人工检测测试脚本的方式存在以下不足:(I)由于是人工检测，可能会存在检查不到位、出现遗漏的情况，导致测试脚本检查不细致，以致出现安全风险。(2)车载控制器软件测试的特点，造成了测试脚本数量多、脚本文件内容较多的情况，人工检测势必影响了工作效率，会需要大量时间，导致变更实施的成本提高。
[0005]所以，如何实现一种能解放测试人员、验证人员的人力，同时又能高效、准确地对车载控制器软件测试脚本进行自动化的检查和分析方法就变得越来越紧迫。
【发明内容】
[0006]本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种用于轨道交通车载控制器软件的测试脚本自动化检测方法，能对软件测试脚本进行批量、自动检测，从而达到高效、便捷的效果。
[0007]本发明的目的可以通过以下技术方案来实现:
[0008]—种用于轨道交通车载控制器软件的测试脚本自动化检测方法，其特征在于，包括以下步骤:
[0009]步骤SlOl，加载测试脚本并对测试脚本作初步检查；
[0010]步骤S102，对通过步骤SlOl中的初步检查的测试脚本进行解析，轨道交通车载控制器软件的测试脚本采用专业术语对测试场景和测试输入进行刻画，其中包括测试所用到的线路、地图、测试持续时间、列车速度曲线、外围设备接口消息，对测试脚本的解析就是将这些专业术语描述的选定测试场景转化为物理场景，并将其展开为以车载软件周期为时间单位的周期性输入数据，作为步骤S103的输入数据；
[0011]步骤S103，对车载控制器软件需求进行建模，利用步骤S102解析展开后的周期性数据作为输入，对需求模型进行仿真；
[0012]步骤S104，结果比对，将步骤S103中得到的模型仿真输出与步骤SlOl测试脚本设计的预期结果进行对比分析，以检查测试脚本的正确性。
[0013]所述的测试脚本是以XML标记语言描述，所述的初步检查包括脚本语言格式检查和脚本内容前后一致性检查。
[0014]所述的步骤SlOl具体为:
[0015]步骤SI，加载测试脚本以及该测试脚本涉及到的相关配置文件，该文件包括线路地图；
[0016]步骤S2，对SI中加载的测试脚本进行XML语法分析以及脚本内容的一致性初步检查，如果检查通过则进入步骤S3，如果检查不通过则需要根据错误提示对测试脚本修改后返回步骤SI重新加载；
[0017]步骤S3，加载测试脚本的预期，作为与步骤SS104中结果比对的依据，如果加载的测试脚本是以测试某一具体软件功能为目的，则此处的预期是该软件功能关联的具体需求中的变量，如果加载的测试脚本是用来性能或者可靠性测试的，则此处的预期是与具体性能指标关联的需求变量。
[0018]所述的步骤SI02具体包括以下步骤:
[0019]步骤S4，解析测试脚本，将用专业术语描述的测试场景转换为物理条件；
[0020]步骤S5，判断步骤S4中的解析是否成功，如果解析失败，则返回步骤SI，修改测试脚本后重新加载，如果解析成功，则进入步骤S6;
[0021]步骤S6，将步骤S4中解析得到的物理条件并结合步骤SI的配置文件展开为以车载控制器软件周期为时间单位的周期性数据。
[0022]所述的步骤S103具体包括以下步骤:
[0023]步骤S7，对车载控制器软件的形式化或半形式化需求进行建模，得到可执行仿真的需求模型；
[0024]步骤S8，根据步骤S7中建立的需求模型以及步骤S3中与测试脚本预期相关的需求变量，识别出执行模型仿真所用的模型接口 ；
[0025]步骤S9，按步骤S8识别出的模型接口的规定，将步骤S6中展开的周期性数据作为输入，对步骤S7中建立的模型执行仿真并得到仿真结果。
[0026]所述的步骤S104具体包括以下步骤:
[0027]步骤S10，将S9中得到的仿真结果与步骤S3中的预期进行比对，并给出比对的结果并提示不一致是否存在。
[0028]与现有技术相比，本发明具有以下优点:
[0029]1、填补了轨道交通车载软件测试脚本验证检测自动化的空白，能够真正实现计算机对测试脚本内容正确性的实质检测。
[0030]2、可以替代测试脚本的人工检测，极大地节约了人力和时间，提高工作效率。
[0031]3、使测试准备工作提前成为可能，当需求文件定稿后即可准备测试脚本，并且可以最大程度地排除测试脚本对测试有效性的影响。
【附图说明】
[0032]图1为本发明测试脚本自动化检测方法的流程图；
[0033]图2为本发明测试脚本自动化检测方法的具体流程图。
【具体实施方式】
[0034]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。
[0035]如图1和图2所示，用本发明的测试脚本自动化检测方法检测以测试轨道交通车载控制器ATP软件处理打滑/空转状态机功能为目的测试脚本为例，具体包括下列步骤:
[0036]步骤SlOl，加载测试ATP软件处理打滑/空转状态机功能的测试脚本并对其作初步检查(该测试脚本模拟了车辆从无打滑发生状态进入刹车状态，继而有进入打滑状态，最后回到刹车状态的场景，该场景的持续时间为3分钟)，具体包括如下SI?S3步骤:
[0037]步骤SI，加载该测试脚本以及相关的地图数据；
[0038]步骤S2，对步骤SI加载的测试脚本进行初步检查，报告XML语法检查以及脚本中关于车辆模型参数的一致性检查；如果检查通过则进入步骤S4，如果检查不通过，则提示错误，回到步骤SI重新加载测试脚本；
[0039]步骤S3，加载对应SI加载的测试脚本的预期，在该实施例中，预期是一个ATP软件中关于监控打滑空转状态机的变量，其应当从无打滑发生状态(SMO)进入刹车状态(SMl)，再进入打滑状态(SM2)，最后回到刹车状态(SMl);
[0040]步骤SI 02，对通过步骤S101中初步检查的测试脚本进行解析，具体包括如下S4?S6步骤:
[0041]步骤S4，将该实施例中的测试脚本描述的车辆打滑空转状态迀移的测试场景解析为里程计测速变化的物理输入条件；
[0042]步骤S5，检查步骤S4是否能正常解析，物理输入条件是否能正常生成，如果解析成功，则进入步骤S6;如果解析失败，则返回到步骤SI重新加载测试脚本；
[0043]步骤S6，将通过步骤S5解析后的脚本展开位周期性数据，对于该实施例是将解析后的测试脚本中描述里程计的测速变化展开为ATP软件周期为单位的数据，因为车载控制器ATP软件周期为100ms，所以该实施例的测试脚本展开后包含有1800个周期里程计测速值的数据；
[0044]步骤S103，对车载控制器ATP软件需求进行建模，利用步骤S102解析展开后的1800个周期的里程计测速值数据作为输入，对模型进行仿真:
[0045]步骤S7，对车载控制器ATP软件需求进行建模，ATP软件需求采用半形式语言描述，精确到每个软件定时中断的行为，有利于后期得到需求的精确建模；
[0046]步骤S8，根据步骤S3中的测试脚本预期以及步骤S7中建立的ATP软件需求模型，识别出软件需求中与打滑空转状态机功能的密切相关的软件接口；
[0047]步骤S9，将步骤S6展开后的1800个周期的里程计测速值作为模型的输入，通过步骤8识别出的模型接口对步骤S7建立的需求模型进行仿真并得到1800个周期的仿真输出，其中包括用于监控打滑空转状态机的软件需求变量值；
[0048]步骤S104，将仿真结果与测试脚本预期比对:
[0049]步骤S10，将步骤S9中得到的仿真结果与步骤S3中的测试脚本预期进行比对，在该实施例中，检查需求中监控打滑空转状态机的变量值是否有SMO，SMl，SM2这三种状态，同时检查是否遵循如下的迀移顺序:SM04SM1—SM2—SM1。如果检查通过，则给出测试脚本正确的提示，如果检查失败则给出错误提示。
[0050]以上所述，仅为本发明的【具体实施方式】，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。
【主权项】
1.一种用于轨道交通车载控制器软件的测试脚本自动化检测方法，其特征在于，包括以下步骤: 步骤SlOI，加载测试脚本并对测试脚本作初步检查； 步骤S102，对通过步骤SlOl中的初步检查的测试脚本进行解析，轨道交通车载控制器软件的测试脚本采用专业术语对测试场景和测试输入进行刻画，其中包括测试所用到的线路、地图、测试持续时间、列车速度曲线、外围设备接口消息，对测试脚本的解析就是将这些专业术语描述的选定测试场景转化为物理场景，并将其展开为以车载软件周期为时间单位的周期性输入数据，作为步骤S103的输入数据； 步骤S103，对车载控制器软件需求进行建模，利用步骤S102解析展开后的周期性数据作为输入，对需求模型进行仿真； 步骤S104，结果比对，将步骤S103中得到的模型仿真输出与步骤SlOl测试脚本设计的预期结果进行对比分析，以检查测试脚本的正确性。2.根据权利要求1所述的一种用于轨道交通车载控制器软件的测试脚本自动化检测方法，其特征在于，所述的测试脚本是以XML标记语言描述，所述的初步检查包括脚本语言格式检查和脚本内容前后一致性检查。3.根据权利要求2所述的一种用于轨道交通车载控制器软件的测试脚本自动化检测方法，其特征在于，所述的步骤S1I具体为: 步骤SI，加载测试脚本以及该测试脚本涉及到的相关配置文件，该文件包括线路地图； 步骤S2，对SI中加载的测试脚本进行XML语法分析以及脚本内容的一致性初步检查，如果检查通过则进入步骤S3，如果检查不通过则需要根据错误提示对测试脚本修改后返回步骤SI重新加载； 步骤S3，加载测试脚本的预期，作为与步骤SS104中结果比对的依据，如果加载的测试脚本是以测试某一具体软件功能为目的，则此处的预期是该软件功能关联的具体需求中的变量，如果加载的测试脚本是用来性能或者可靠性测试的，则此处的预期是与具体性能指标关联的需求变量。4.根据权利要求3所述的一种用于轨道交通车载控制器软件的测试脚本自动化检测方法，其特征在于，所述的步骤S102具体包括以下步骤: 步骤S4，解析测试脚本，将用专业术语描述的测试场景转换为物理条件； 步骤S5，判断步骤S4中的解析是否成功，如果解析失败，则返回步骤SI，修改测试脚本后重新加载，如果解析成功，则进入步骤S6; 步骤S6，将步骤S4中解析得到的物理条件并结合步骤SI的配置文件展开为以车载控制器软件周期为时间单位的周期性数据。5.根据权利要求4所述的一种用于轨道交通车载控制器软件的测试脚本自动化检测方法，其特征在于，所述的步骤S103具体包括以下步骤: 步骤S7，对车载控制器软件的形式化或半形式化需求进行建模，得到可执行仿真的需求模型； 步骤S8，根据步骤S7中建立的需求模型以及步骤S3中与测试脚本预期相关的需求变量，识别出执行模型仿真所用的模型接口 ； 步骤S9，按步骤S8识别出的模型接口的规定，将步骤S6中展开的周期性数据作为输入，对步骤S7中建立的模型执行仿真并得到仿真结果。6.根据权利要求5所述的一种用于轨道交通车载控制器软件的测试脚本自动化检测方法，其特征在于，所述的步骤S104具体包括以下步骤: 步骤S10，将S9中得到的仿真结果与步骤S3中的预期进行比对，并给出比对的结果并提示不一致是否存在。
【文档编号】G06F11/36GK105912469SQ201610220634
【公开日】2016年8月31日
【申请日】2016年4月11日
【发明人】熊坤鹏, 刘锦峰, 陈晓轩, 陈硕豪
【申请人】卡斯柯信号有限公司