一种CTC车次追踪子系统自动测试方法及系统与流程

一种ctc车次追踪子系统自动测试方法及系统
技术领域
1.本发明涉及轨道交通技术领域，尤其涉及一种ctc车次追踪子系统自动测试方法及系统。


背景技术：

2.ctc(centralized traffic control system，调度集中控制系统)目前广泛应用于铁路轨道交通领域，ctc能够对列车运行进行监督和控制，帮助行车调度指挥人员对全线列车进行管理，它在提高轨道交通运输效率和保障运行安全方面起到了极其重要的作用。其中，对列车车次号的管理，是整个ctc系统的重要基础，只有完成列车车次号的追踪，才能实现列车自动报点、占用丢失、紧跟踪报警、进路自动排路等后续其他核心功能。ctc车次追踪功能的测试工作是系统发布之前的重要环节，保障了系统的稳定性和正确性。
3.目前对于ctc车次追踪子系统的测试方式，主要采用人工测试。人工搭建测试环境，按照既定测试方案，人工模拟现场实际操作并确认执行结果是否符合预期。在实际工作中，ctc车次追踪子系统测试存在以下难点：
4.1)ctc车次追踪子系统需要适应现场不同站型，甚至包容轨道电路异常场景，最大程度上保证车次号的正确性，车次追踪功能的测试用例不仅要涵盖车次相关功能，更要覆盖各种站型，因此测试用例数量大，全面回归测试用时长。在测试过程中，若修改追踪功能，须重新回归所有测试，需要大量重复性劳动。人工测试ctc车次追踪功能时，在有限的测试时间内，存在回归测试功能覆盖不全的风险。
5.2)在ctc车次追踪子系统容错性测试工作中，需要制作错误的输入数据，该错误数据无法在仿真环境下模拟。
6.3)铁道线路升级ctc系统前，使用施工线路实际数据进行长时间测试，可对ctc车次追踪功能的稳定性提供具有针对性的评估，该项工作无法由人工测试实现。


技术实现要素：

7.本发明的目的是提供一种ctc车次追踪子系统自动测试方法及系统，能够自动执行测试任务，无需人工监督，保障了测试效果。
8.本发明的目的是通过以下技术方案实现的：
9.一种ctc车次追踪子系统自动测试方法，通过自动测试系统实现，包括如下步骤：
10.根据当前设定的测试模式，读取相应原始数据并生成若干测试用例与自动测试系统配置信息，所述测试用例中包括：测试输入、预期结果及追踪子系统配置信息；
11.按照配置信息的顺序执行测试用例，每一次执行时，将测试用例中的追踪子系统配置信息拷贝至被测ctc车次追踪子系统对应的文件夹，初始化系统时间早于当前执行的测试用例中第一条测试输入的时间，启动被测ctc车次追踪子系统，将系统时间修改为当前执行的测试用例中第一条测试输入的时间，当系统时间与当前待发送的测试输入的时间一致时，将对应测试输入发送给被测ctc车次追踪子系统，同时接收被测ctc车次追踪子系统
的反馈结果；
12.对比反馈结果与预期结果判断是否通过本次测试，执行完所有测试用例后，结合各测试用例的测试结果，输出测试报告。
13.一种ctc车次追踪子系统自动测试系统，包括：
14.配置与用例生成模块，用于根据当前设定的测试模式，读取相应原始数据并生成若干测试用例，所述测试用例中包括：测试输入、预期结果及追踪子系统配置信息；
15.用例执行模块，用于按照配置的顺序执行测试用例，每一次执行时，将测试用例中的追踪子系统配置信息拷贝至被测ctc车次追踪子系统对应的文件夹，初始化系统时间早于当前执行的测试用例中第一条测试输入的时间，启动被测ctc车次追踪子系统，将系统时间修改为当前执行的测试用例中第一条测试输入的时间，当系统时间与当前待发送的测试输入的时间一致时，将对应测试输入发送给被测ctc车次追踪子系统，同时接收被测ctc车次追踪子系统的反馈结果；
16.测试结果分析模块，用于对比反馈结果与预期结果判断是否通过本次测试，执行完所有测试用例后，结合各测试用例的测试结果，输出测试报告。
17.由上述本发明提供的技术方案可以看出，可以根据测试模式使用相应的原始数据自动生成测试用例，并进行自动测试，测试完毕会根据各项测试的结果生成测试报告；测试过程无需人工监督，便于在较短时间内进行全面测试，而且测试过程自动化程度高，可减少人工操作有效负担。
附图说明
18.为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他附图。
19.图1为本发明实施例提供的一种ctc车次追踪子系统自动测试方法的流程图；
20.图2为本发明实施例提供的一种ctc车次追踪子系统自动测试系统的示意图；
21.图3为本发明实施例提供的自动测试系统各模块间协作机制示意图；
22.图4为本发明实施例提供的生成配置与用例的示意图；
23.图5为本发明实施例提供的回归测试模式示意图；
24.图6为本发明实施例提供的回归测试模式下自动执行测试用例的流程图；
25.图7为本发明实施例提供的容错性测试模式的示意图；
26.图8为本发明实施例提供的实际数据测试模式的示意图。
具体实施方式
27.下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明的保护范围。
28.首先对本文中可能使用的术语进行如下说明：
29.术语“包括”、“包含”、“含有”、“具有”或其它类似语义的描述，应被解释为非排它性的包括。例如：包括某技术特征要素(如原料、组分、成分、载体、剂型、材料、尺寸、零件、部件、机构、装置、步骤、工序、方法、反应条件、加工条件、参数、算法、信号、数据、产品或制品等)，应被解释为不仅包括明确列出的某技术特征要素，还可以包括未明确列出的本领域公知的其它技术特征要素。
30.下面对本发明所提供的一种ctc车次追踪子系统自动测试方法进行详细描述。本发明实施例中未作详细描述的内容属于本领域专业技术人员公知的现有技术。本发明实施例中未注明具体条件者，按照本领域常规条件或制造商建议的条件进行。
31.如图1所示，一种ctc车次追踪子系统自动测试方法，包括如下步骤：
32.1、根据当前设定的测试模式，读取相应原始数据并生成若干测试用例与自动测试系统配置信息。所述测试用例中包括：测试输入、预期结果及追踪子系统配置信息。
33.2、按照自动测试系统配置信息的顺序执行测试用例，每一次执行时，将测试用例中的追踪子系统配置信息拷贝至被测ctc车次追踪子系统对应的文件夹，初始化系统时间早于当前执行的测试用例中第一条测试输入的时间(具体实现可根据实际情况自行设定，例如，设为2000年1月1日)，启动被测ctc车次追踪子系统，将系统时间修改为当前执行的测试用例中第一条测试输入的时间，当系统时间与当前待发送的测试输入的时间一致时，将对应测试输入发送给被测ctc车次追踪子系统，同时接收被测ctc车次追踪子系统的反馈结果。
34.本发明实施例中，每一测试用例中包含一个或多个测试输入，每一测试输入具有对应的接收时间，按照时间先后顺序排序并在时间达到时发送至被测ctc车次追踪子系统。
35.3、对比反馈结果与预期结果判断是否通过本次测试，执行完所有测试用例后，结合各测试用例的测试结果，输出测试报告。
36.本发明实施例上述方法主要通过图2所示的自动测试系统实现，上述三个步骤分别由配置与用例生成模块、用例执行模块、测试结果分析模块实现；此外，系统中还包含的通信模块，用于实现自动测试系统与被测ctc车次追踪子系统的通信连接；人机交互模块，用于实现测试人员与自动测试系统的交互，交互内容包含下发控制命令，以及展示测试结果。图3展示了自动测试过程中各模块协同工作的过程。
37.本领域技术人员可以理解，上述自动测试系统与自动测试方法是相对应的方案(统称为自动测试方案)，以下介绍所涉及的技术细节适用于与自动测试系统与自动测试方法，因此，不做区分说明。
38.本发明实施例中，自动测试方案适用于三种测试模块：回归测试、容错性测试与实际数据测试。各测试模块的流程与原理如下。
39.1、回归测试模式。
40.如图5所示，回归测试模式时，仿真环境下人工执行测试用例后，被测ctc车次追踪子系统配置和通信数据流保批量保存为原始数据。如图4所示，原始数据放在以用例编号命名的文件夹下，其中包含追踪子系统配置和通信数据流，通信数据流包含接收和发送数据以及收发时间。配置与测试用例生成过程需生成测试系统配置，原始数据会被转为测试用例(包含配置数据、测试输入和预期结果)。测试时，按照配置顺序逐一执行相关测试用例，而且每执行一次测试用例后，均关闭被测ctc车次追踪子系统。
41.回归测试模式下，测试数据特点是数量大，用例持续时间短，场景简单，测试功能明确。由于测试过程无人监督，控制测试过程的难点在于保证不同测试用例之间不会相互影响，如果有测试用例未执行成功，后续测试用例仍能够继续测试。此外，图6展示了回归测试模式下的测试流程，主要包括：
42.1)批量导入测试用例集原始数据。
43.原始数据文件夹储存到被测ctc车次追踪子系统所在文件夹。
44.2)生成测试系统配置。
45.测试系统配置分为通信配置和执行配置两部分。通信配置为固定值。所有测试用例原始数据文件夹放在自动测试系统所在的文件夹下，自动测试系统以文件夹名称作为测试用例名称生成测试系统执行配置，测试系统启动后便会按照配置顺序逐一执行测试用例。
46.3)修改追踪配置。
47.修改原始数据中的追踪配置(即，被测ctc车次追踪子系统配置)，适配测试系统通信配置，保证被测系统与测试系统正常通信。
48.4)解析测试输入。
49.通信数据流中接收数据解析为测试输入。
50.5)解析预期结果。
51.通信数据流中发送数据解析为预期结果。
52.6)将前述步骤3)中修改后的追踪子系统配置信息拷贝至待测追踪子系统所在文件夹。
53.7)初始化系统时间早于当前执行的测试用例中第一条测试输入时间(例如，2000年1月1日)，保证测试系统不对外发送数据。
54.8)启动ctc车次追踪子系统。
55.9)ctc追踪子系统与测试系统通信连接成功后，将系统时间修改为第一包输入数据时间，当系统时间与测试输入的时间一致，将对应测试输入发送给ctc车次追踪子系统，同时记录ctc车次追踪子系统反馈结果。若通信连接失败，停止测试本用例，关闭ctc追踪子系统。
56.10)测试输入发送完毕，关闭ctc追踪子系统。
57.11)将反馈结果与预期结果对比，若有实质性不同，判定测试不通过，否则，通过。
58.12)转存追踪子系统配置信息和测试输入，反馈结果作为预期结果，保存为新的测试用例。若ctc车次追踪子系统变更导致测试不通过，这是正常的，用例的预期结果更新了，应更新测试用例。
59.13)测试结果评定。
60.测试用例执行完毕，将用例中反馈结果与预期结果进行对比。被测ctc追踪子系统反馈结果可分为两类信息：周期性信息和事件触发性信息。周期性信息指每个时间周期对外发送一次信息，例如ctc追踪子系统周期性对外发送列车车次信息，由于信息发送周期无法做到精确同步，周期性信息时间差不视为实质性差异。事件触发性信息指被测ctc追踪子系统响应当前时间出现的事件(测试输入)对外发送的信息，例如ctc追踪子系统根据站场表示信息判断两车紧跟踪对外发送紧跟踪告警信息，事件触发性信息差异视为实质性差
异。若结果有实质性差异，则判定为测试不通过，否则判定为通过。
61.14)测试报告输出。
62.前述步骤6)
‑
13)为执行一个测试用例的过程，测试系统根据配置依次执行测试用例集中所有用例，测试用例集执行完毕，所有测试用例结果生成一份测试报告，其中包含测试是否通过以及不通过的测试用例结果对比差异。
63.2、容错性测试模式。
64.容错性测试模式主要用于复现问题，只有一个测试用例，需要人工手动修改数据，制造异常场景。
65.如图7所示，容错性测试模式时，根据异常场景，在仿真环境中人工执行正常场景实验后，保留原始数据，利用所述原始数据生成一个测试用例。
66.按照前述回归测试的方式执行步骤1)～5)，解析出测试输入，并根据异常场景对测试输入进行修改，由于容错性测试模式下只存在一个测试用例，因此，前述步骤2)中的执行配置只包含一个测试用例名称；步骤10)中测试完毕后不关闭被测ctc车次追踪子系统，等待人工关闭。因为容错性测试一般由开发人员使用，用于查找代码问题，测试的同时调试代码，为此不再自动关闭程序。
67.3、实际数据测试模式。
68.实际数据测试模式主要用于软件升级施工之前，采用实际数据(施工线路数据)进行长时间测试(一般会连续运行7*24小时)，针对特定线路环境的稳定性测试。
69.如图8所示，实际数据测试模式时，将现场ctc车次追踪子系统实际配置与通信数据流保留为原始数据，利用所述原始数据生成一个测试用例。
70.考虑到数据体量大，若测试输入保存的文件过大，会严重影响数据解析的速度。在读取数据时可能因为数据量过大导致测试工具卡顿，因此，该测试用例的测试输入被分为若干文件，每一文件对应指定时间段(例如，每一个小时的测试输入写在一个文件中)，文件大小不超过设定值(具体大小可根据情况自行设定)；利用测试用例进行稳定性测试，执行过程与容错性测试模式相同，区别主要在于，实际数据测试模式下，测试输入解析后不再保存在一个文件中，而是分散保存在多个文件以提高读取效率，以及测试完毕后关闭被测ctc车次追踪子系统。
71.需要说明的是，以上三种模式下步骤3)修改的都是追踪配置，但是，不同模式下追踪配置的来源存在区别，容错性测试使用的是仿真实验所用配置，实际数据测试模式使用的是现场实际配置。
72.本发明实施例上述方案，主要获得如下有益效果：
73.1)回归测试模式下，测试用例集可反复使用，测试过程无需人工监督，便于在较短时间内全面回归测试软件功能，节约了人工测试的成本。
74.2)容错性测试模式下，解决了实验环境无法复现异常场景的问题，测试输入数据可根据实验需要灵活修改，对软件安全防护机制测试提供了有力支撑。
75.3)实际数据测试模式下，为软件升级施工提供了具有针对性的验证手段，填补了实际数据稳定性测试的空白。
76.4)实施流程可实现自动执行，测试工具的自动化程度高，可减少人工操作有效负担。
77.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例可以通过软件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，上述实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd
‑
rom，u盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
78.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将系统的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
79.以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明披露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。