一种台架测试方法及装置、电子设备与流程

1.本技术涉及软件测试技术领域，具体涉及一种台架测试方法及装置、电子设备。


背景技术：

2.智能驾驶车辆是在传统车辆基础上增加智能驾驶技术的车辆。智能驾驶车辆利用车载传感器来感知车辆周围各种环境信息，如：车道线、障碍物、定位、道路标识等；并根据感知获得的车辆所在道路、车辆位置和障碍物信息进行智能决策和路径规划，控制车辆的横向(转向)和纵向(车速)运动，从而使车辆能够安全、可靠地在道路上自动行驶。
3.智能驾驶车辆的研发过程包括零部件和整车的开发。在软件代码开发完成，并进行集成后，目前采用的方式是直接上实车测试，在实车上进行的是域控对车辆控制，在上位机进行软件烧录后，需要测试人员和开发人员进行实车测试，但是在实车情况下会有很多不确定因素，类似车辆传感器故障、车辆底层软件版本不对应等硬件问题，但是这类因素由开发人员参与排查意义不大，并且此类问题使测试人员效率降低，成为无法按时交付项目的关键原因。
4.公开号为cn213042144u的中国专利文献公开了名称为“一种自动驾驶系统的融合测试台架”的技术，该技术涉及自动驾驶系统测试技术领域，包括：一第一被测设备，第一被测设备内部搭载有第一自动驾驶辅助系统；一第二被测设备，第二被测设备内部搭载有第二自动驾驶辅助系统；一汽车功能仿真设备，分别连接第一被测设备和第二被测设备；一执行部件，分别连接第一被测设备和第二被测设备；一信息综合增强设备，分别连接第一被测设备和第二被测设备；一测试控制设备，测试控制设备装载有虚拟驾驶仿真平台，测试控制设备分别连接信息综合增强设备和汽车功能仿真设备。该技术能够在实验室环境下实现第一自动驾驶辅助系统和第二自动驾驶辅助系统的融合功能测试。该技术没有对车辆的传感器进行仿真，没有进行实际的信号输入，在实车测试上会出现传感器输入错误等相关硬件问题，对开发人员及测试人员不友好，耗费时间多，并且职责划分模糊，不利于效率提升。
5.公开号为“cn111289252a”的中国专利文献公开了名称为“一种台架测试方法、装置、计算机设备和存储介质”的技术，该技术通过获取的发动机的测试边界条件调整发动机的运行状态，然后根据调整后的发动机运行状态对该发动机进行台架测试。由于本实施例中，发动机的测试边界条件包括了发动机待测试运行参数的目标值和/或待测试临界条件的调整规则，这样，计算机设备就可以自动地根据该测试边界条件对发动机的运行状态进行调整，并且在发动机运行状态调整后，根据程序的自动开始对发动机进行台架测试，全过程无需人工进行调试和判断，大大提高了测试效率以及测试结果的精度。该技术没有对车辆的传感器进行仿真，没有进行实际的信号输入，在实车测试上会出现传感器输入错误等相关硬件问题，对开发人员及测试人员不友好，耗费时间多，并且职责划分模糊，不利于效率提升。


技术实现要素：

6.为解决上述技术问题，本技术的实施例提供了一种台架测试方法及装置、电子设备。进而实现降低软件开发周期和成本，提高软件开发效率，划分开发人员、侧人员具体职责的目的，另，在调试可执行文件时，以解决定位bug或者解决bug的过程调试效率低的问题，以及，提高测试的通用性、可靠性。
7.本技术的其他特点和优点将通过下面的详细描述变得显然，或部分地通过本技术的实践而习得。
8.根据本技术实施例的一个方面，提供了一种台架测试方法，包括：
9.获取从仿真传感器传送的实车原始报文数据；
10.域控制器内的底层、中间层依次对所述实车原始报文数据进行处理，并通过应用层发出信号；
11.基于所述信号判断所述域控制器内的待测可执行文件相关功能是否正常激活，从而判定待测可执行文件是否通过测试。
12.在本技术的实施例所提供的技术方案中，域控制器内的底层、中间层依次对所述实车原始报文数据进行处理，并通过应用层发出信号，包括：
13.获取来自测试用例的信号；
14.底层对所述来自测试用例的信号进行相关处理；
15.输出处理结果，并基于结果判断可执行文件收到的信息是否与上版本一致。
16.在本技术的实施例所提供的技术方案中，基于所述信号判断所述域控制器内的待测可执行文件相关功能是否正常激活，从而判定待测可执行文件是否通过测试之后，还包括：
17.获取实车复杂工况数据；
18.经调试之后的可执行文件对所述实车复杂工况数据进行处理；
19.基于处理之后的信号判断经调试之后的可执行文件是否达标。
20.在本技术的实施例所提供的技术方案中，输出处理结果，并基于结果判断可执行文件收到的信息是否与上版本一致，包括：基于数据发送周期、数据量大小及数据类型判断可执行文件收到的信心是否与上版本一致。
21.在本技术的实施例所提供的技术方案中，经调试之后的可执行文件对所述实车复杂工况数据进行处理，包括：
22.获取可执行文件对应的源码文件，所述源码文件包括至少一段待调试路试问题代码和与每一所述待调试路试问题代码相对应的配置调试条件；
23.加载调试选项配置文件，所述调试选项配置文件包括至少一段原始调试代码和与每一所述原始调试代码相对应的原始调试选项；
24.解析所述调试选项配置文件，生成调试选项字典；
25.基于所述配置调试条件查询所述调试选项字典，将与所述配置调试条件相匹配的原始调试选项确定为目标调试选项，获取与所述目标调试选项相对应的目标调试代码；
26.目标调试代码调试所述待调试路试问题代码。
27.在本技术的实施例所提供的技术方案中，获取可执行文件对应的源码文件，包括：
28.加载可执行文件对应的程序代码，所述程序代码包括至少一段待调试路试问题代
码；
29.依次显示每一所述待调试路试问题代码对应的调试配置界面，基于所述调试配置获取每一所述待调试路试问题代码对应的配置调试条件，获取所述源码文件。
30.在本技术的实施例所提供的技术方案中，获取来自测试用例的信号，所述测试用例的生成，包括：
31.建立预设用例生成规格模块及组合算法；
32.数据测试参数值以建立扩展标记语言xml文件；
33.对测试参数与对应的组合算法进行选择；
34.规格模块基于测试参数建立参数测试用例，合成实际测试用例。
35.在本技术的实施例所提供的技术方案中，规格模块基于测试参数建立参数测试用例，合成实际测试用例之后还包括：
36.将所述实际测试用例输出至用户接口；
37.当实际测试用例有误时，重新建立xml文件。
38.根据本技术实施例的一个方面，还提供了一种台架测试装置，包括：
39.获取模块，用于获取从仿真传感器传送的实车原始报文数据；
40.处理模块，用于域控制器内的底层、中间层依次对所述实车原始报文数据进行处理，并通过应用层发出信号；
41.判断模块，用于基于所述信号判断所述域控制器内的待测可执行文件相关功能是否正常激活，从而判定待测可执行文件是否通过测试。
42.根据本技术实施例的一个方面，还提供了一种电子设备，包括：
43.一个或多个处理器；
44.存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述点在设备实现如上述的台架测试方法。
45.根据本技术实施例的一个方面，还提供了一种计算机可读存储介质，其上存储有计算机可读指令，当诉搜狐计算机可读指令被计算机的处理器执行时，使计算机执行上述的台架测试方法。
46.根据本技术实施例的一个方面，还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述的台架测试方法。
47.本发明的有益效果：本技术的实施例所提供的技术方案降低软件开发周期和成本，提高软件开发效率，将开发和测试的分工具体化，提升测试效率，同时有效减少开发陪同测试人员进行无意义的测试，另解决了在调试可执行文件过程中解决定位bug或者解决bug的过程调试效率低的问题，以及提高了测试的通用性和可靠性。
48.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本技术。
附图说明
49.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术者来讲，在不付出创造性劳动的前提下，还可以根据这
些附图获得其他的附图。在附图中：
50.图1是本技术的一示例性实施例示出的技术架构示意图；
51.图2是本技术的一示例性实施例示出的台架测试方法的示意性流程图；
52.图3是本技术的一示例性实施例示出判断可执行文件收到的信息是否与上版本一致的流程图；
53.图4是本技术的一示例性实施例示出的判断经调试之后的可执行文件是否有能力对复杂工况数据进行处理的示意性流程图；
54.图5是本技术的一示例性实施例示出的调试可执行文件的示意性流程图；
55.图6是本技术的一示例性实施例示出的获取可执行文件对应的源码文件的示意性流程图；
56.图7是本技术的一示例性实施例示出的测试用例的生成的示意性流程图；
57.图8是本技术的一示例性实施例示出的合成实际测试用例之后的方法流程图；
58.图9是本技术的一示例性实施例示出的台架测试装置框图；
59.图10是本技术的一示例性实施例示出的电子设备的计算机系统的结构示意图。
具体实施方式
60.这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
61.附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立额实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
62.附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
63.本文涉及智能驾驶汽车的mcu(microcontroller unit微控制单元)、soc(system-on-a-chip系统级芯片)，在工控机进行上实车之前的台架模拟，更具体地说，涉及一种台架测试方法。
64.智能驾驶车辆的研发过程包括零部件和整车的开发。在软件代码开发完成，并进行集成后，目前采用的方式是直接上实车测试，在实车上进行的是域控对车辆控制，在上位机进行软件烧录后，需要测试人员和开发人员进行实车测试，但是在实车情况下会有很多不确定因素，类似车辆传感器故障、车辆底层软件版本不对应等硬件问题，但是这类因素由开发人员参与排查意义不大，并且此类问题使测试人员效率降低，成为无法按时交付项目的关键原因。在这里就涉及职责划分的复杂问题。
65.下面结合附图对本技术的实施例的技术方案进行说明。
66.图1是本技术的一示例性实施例示出的技术架构示意图。
67.如图1所示，从整体看，该台架测试方法包括：s1001、发布软件发布软件版本，各个
开发人员在进行代码编写和自测，将代码上传到代码仓库；s1002、进行台架测试；s1003、进行软件交付。
68.在s1002中，具体的包括：s1004、原始数据回注；s1005、底层输入数据对比；s1006、问题单数据回注。
69.图2是本技术的一示例性实施例示出的台架测试方法的示意性流程图。
70.如图2所示，该台架测试方法的步骤包括：
71.s101、获取从仿真传感器传送的实车原始报文数据。
72.原始报文数据回放，通过实车调试工具进行数据录制，包括原始报文，由于每个版本接口不统一，但如果采用原始报文的形式可以在试验车辆传感器底层不变的情况下进行数据回放，并且每个版本都适用。
73.在开发人员完成开发后，进行域控(即域控控制器)集成，然后直接进行台架测试即可，是否能完成相应的功能，实现方式是用能够体现相应模块的特定数据，由此不用上车就可进行功能验证，缩短周期，并且更加高效。
74.s102、域控制器内的底层、中间层依次对所述实车原始报文数据进行处理，并通过应用层发出信号。
75.底层模拟输出结果对比，传感器和底层版本会有版本迭代，但是频率并不是随版本迭代，相对独立，为了验证软件收到信息是否与上版本一致，包括数据发送周期、数据量大小、数据类型等，避免上车后由于接受数据不同引起的功能不正常。
76.s103、基于所述信号判断所述域控制器内的待测可执行文件相关功能是否正常激活，从而判定待测可执行文件是否通过测试。
77.复杂工况数据回放，在软件版本出现并进行路试后，会出现各种工况的问题，这里针对源码逻辑相关的问题修改，在开发人员完成修改后进行测试，同时回放的数据采用当时路试出现问题的数据，通过回放和可视化工具回放来观察代码修改效果。
78.开发软件交互，在上述环节走完，在路试中涉及开发的问题就会大大减少，同时会有更多时间验证软件代码功能逻辑，提高测试效率，避免每次测试都以严重影响测试效率来当做原因。
79.具体地，本技术实施例欲实现降低软件开发周期和成本，提高软件开发效率，划分开发人员、测试人员具体职责目的。为了实现上述目的，提出了本技术实施例，本技术实施例所提供的技术方案涉及的方法包括：原始报文数据回放，通过实车调试工具进行数据录制，包括原始报文，由于每个版本接口不统一，但如果采用原始报文的形式可以在试验车辆传感器底层不变的情况下进行数据回放，并且每个版本都适用。在开发人员完成开发后，进行域控集成，然后直接进行台架测试，是否能完成相应的功能，实现方式是用能够体现相应模块的特定数据，由此不用上车就可进行功能验证，缩短周期，并且更加高效。
80.底层模拟输出结果对比，传感器和底层版本会有版本迭代，但是频率并不是随版本迭代，相对独立。此步为了验证软件收到信息是否与上版本一致，包括数据发送周期、数据量大小、数据类型等，避免上车后由于接受数据不同引起的功能不正常。
81.复杂工况数据回放，在软件版本出现并进行路试后，会出现各种工况的问题，这里针对源码逻辑相关的问题修改，在开发人员完成修改后进行测试，同时回放的数据采用当时路试出现问题的数据，通过回放和可视化工具回放来观察代码修改效果。
82.开发软件交付，在上述环节走完，在路试中涉及开发的问题就会大大减少，同时会有更多时间验证软件代码功能逻辑，提高测试效率，避免每次测试都以严重影响测试效率来当做原因。
83.图3是本技术的一示例性实施例示出判断可执行文件收到的信息是否与上版本一致的流程图。
84.参照图3所示，域控制器内的底层、中间层依次对所述实车原始报文数据进行处理，并通过应用层发出信号，包括：s201、获取来自测试用例的信号；s202、底层对所述来自测试用例的信号进行相关处理；s203、输出处理结果，并基于结果判断可执行文件收到的信息是否与上版本一致。
85.原始数据回注，通过开发人员生成的可执行文件，烧录仅域控控制器后进行仿真，观察在传感器及底层不变的情况下是否能够正常激活功能。如果功能有异常可以通过可视化工具来观察是否是逻辑不正常，或者是当前工况不满足；底层数据对比，传感器和底层通过测试用例输入信号，在相同的测试用例情况下，输出结果是否和上版本一致，若有差别即刻解决适配问题，底层软件同理。
86.图4是本技术的一示例性实施例示出的判断经调试之后的可执行文件是否有能力对复杂工况数据进行处理的示意性流程图。
87.参照图4所示，基于所述信号判断所述域控制器内的待测可执行文件相关功能是否正常激活，从而判定待测可执行文件是否通过测试之后，还包括：
88.s301、获取实车复杂工况数据；s302、经调试之后的可执行文件对所述实车复杂工况数据进行处理；s303、基于处理之后的信号判断经调试之后的可执行文件是否达标。
89.复杂工况数据回放，在软件版本出现并进行路试后，会出现各种工况的问题，这里针对源码逻辑相关的问题修改，在开发人员完成修改后进行测试，同时回放的数据采用当时路试出现问题的数据，通过回放和可视化工具回放来观察代码修改效果。
90.基于所述信号判断所述域控制器内的待测可执行文件相关功能是否正常激活，从而判定待测可执行文件是否通过测试之后的步骤一定需要软件交付时才进行测试，可以修改好了之后开发人员进行自主台架仿真，数据问题回注后可以实现问题单修改结果即解决问题。软件交互，当软件没有问题之后方可进行软件交互，测试团队进行试车测试，上述步骤为了分清职责，将开发和测试的分工具体化，提升测试效率，同时有效减少开发陪同测试人员进行无意义测试。
91.具体地，该方法包括发布软件版本；台架测试；软件交互。发布软件版本，各个开发人员在进行代码编写和自测，将代码上传到代码仓库。台架测试，包括原始数据回注、底层数据对比及问题数据回注。原始数据回注，通过开发人员生成的可执行文件，烧录仅域控控制器后进行仿真，观察在传感器及底层不变的情况下是否能够正常激活功能，如果功能有异常可以通过可视化工具来观察是否是逻辑不正常，或者是当前工况不满足。底层数据对比，传感器和底层通过测试用例输入信号，在相同的测试用例情况下，输出结果是否和上版本一致，若有差别即刻解决适配问题，底层软件同理。问题数据回注，这一步骤一定需要软件交互时才进行测试，可以修改好了之后开发人员进行自主台架仿真，数据问题回注后可以实现问题单修改结果即解决问题。软件交互，上述步骤完成无异常后进行软件交互，测试团队进行实车测试，上述步骤为了分清职责，将开发和测试的分工具体化，提升测试效率，
同时有效减少开发陪同测试人员进行无意义测试。
92.图5是本技术的一示例性实施例示出的调试可执行文件的示意性流程图。
93.参照图5所示，经调试之后的可执行文件对所述实车复杂工况数据进行处理，包括：
94.s401、获取可执行文件对应的源码文件，所述源码文件包括至少一段待调试路试问题代码和与每一所述待调试路试问题代码相对应的配置调试条件；
95.可执行文件对应的源码文件是指开发人员基于特定项目开发出的源代码所形成的文件。待调试路试问题代码是指可完成对车辆进行相关控制的功能代码，具体是指已经经过路试的代码，需要进行测试并调试，以确定其是否能完成相应功能的代码。配置调试条件是指开发人员在项目开发过程中，预先配置的对该待调试路试问题代码进行调试的条件。
96.具体地，开发人员在开发编辑源码文件中，可对源码文件中不同功能的待调试路试问题代码配置不同的配置调试条件，以使最终形成的源码文件中包含至少一段待调试路试问题代码和与每一待调试路试问题代码相对应的配置调试条件。例如，开发人员在编辑完成一段代码之后，可采用特定标识在待调试代码的注释中标注相应的配置调试条件，以便后续识别到这一特定标识时，确定该特定标识对应的配置调试条件。由于源码文件中，每一段待调试路试问题代码对一以配置调试条件，为后续基于该配置调试条件适用不同的调试代码进行调试提供技术支持。
97.s402、加载调试选项配置文件，所述调试选项配置文件包括至少一段原始调试代码和与每一所述原始调试代码相对应的原始调试选项；
98.调试选项配置文件是指配置有原始调试代码和原始调试选项之间关联关系，以便进行调试的文件。原始调试代码是指用于查找待调试路试问题代码中是否存在错误(即bug)的代码，以便开发人员改正错误，提高改正效率，从而保证开发人员所开发的软件能够供用户正常使用。原始调试选项是指用于控制原始调试代码是否对待调试代码进行调试的选项开关，可以理解地，该原始调试代码是用于检测并定位待调试代码是否存在bug的代码，而原始调试选项是用于确定能否运行该原始调试代码的开关，即只有满足原始调试选项的要求，才可运行相对应的原始调试代码，实现对相应的待调试代码进行检测定位。
99.具体地，加载预先配置好的调试选项配置文件，该调试选项配置文件包括至少一段原始调试代码和与每一原始调试代码相对应的原始调试选项，以便后续启动调试选项配置文件中的原始调试选项，使对应的原始调试代码对待调试代码进行调试。可以理解地，由于调试选项配置文件配置有至少一段原始调试代码和对应的原始调试选项之间的关联关系，是一个完整的调试文件，提供了良好的移植和扩展性，因此，调试选项配置文件可以根据实际情况进行调整原始调试代码和原始调试选项之间的关联关系，链接到不同项目中，从而实现重复利用该调试选项配置文件，使软件调试流程更加规范和简洁。
100.s403、解析所述调试选项配置文件，生成调试选项字典；
101.对调试选项配置文件进行分离，然后依据调试需求，对分离后的调试选项进行解析，以解析对应的键和值。调试选项字典是用于存储对调试选项配置文件进行解析的解析结果的程序，在调试过程，查询调试选项字典以判断是否采用相应的原始调试代码对待调试代码进行调试。一般地，特定项目的源码文件中包含多个功能模块对应的待调试代码，在
对特定项目中的原木进行调试时，为节省调试时间，可以进对特定的功能模块或者与该功能模块相关联的关联模块进行调试，因此，需要生成调试选项字典以便基于开发人员在项目源码文件中配置的配置调试条件确定具体对哪一功能模块进行调试，从而节省了调试流程，提高调试效率。
102.s404、基于所述配置调试条件查询所述调试选项字典，将与所述配置调试条件相匹配的原始调试选项确定为目标调试选项，获取与所述目标调试选项相对应的目标调试代码；
103.配置调试条件是开发人员预先给项目源码文件中每一待调试代码配置的用于进行调试的条件，可根据该配置调试条件查找到相对应的目标调试选项。目标调试选项是指从调试选项字典所有的原始调试选中确定的与配置调试条件相匹配的原始调试选项。目标调试代码是调试选项配置文件中，与该目标调试选项相对应的原始调试代码。可以理解地，该目标调试选项是用于进行控制目标调试代码是否对于该配置调试条件相对应的待调试代码进行调试的开关。
104.s405、目标调试代码调试所述待调试路试问题代码。
105.图6是本技术的一示例性实施例示出的获取可执行文件对应的源码文件的示意性流程图。
106.参照图6所示，获取可执行文件对应的源码文件，包括：
107.s501、加载可执行文件对应的程序代码，所述程序代码包括至少一段待调试路试问题代码；
108.程序代码是指特定项目中，开发人员根据特定功能需求编写的源代码。为保证对该程序代码准确无误，需要对不确定是否实现正常功能的代码进行调试，因此将需要进行调试的代码确定为待调试代码。可以理解地，由于完整的程序代码中包含的功能模块有所不同，因此，需要对所有功能模块对应的待调试代码进行调试。但为了保证调试的效率，在实际调试过程中，可将已经更新的功能模块以及与该已经更新的功能模块关联的代码作为待调试代码，其他没有更新的功能模块或者不存在关联关系的功能模块对应的代码作为待调试代码进行调试，以确保调试的高效性。
109.s502、依次显示每一所述待调试路试问题代码对应的调试配置界面，基于所述调试配置获取每一所述待调试路试问题代码对应的配置调试条件，获取所述源码文件。
110.调试配置界面是指用于配置与待调试代码相对应的配置调试条件的界面。具体地，开发人员在编辑完每一待调试代码之后，可点击相应的配置按钮或者输入相应的配置指令，以进入调试配置界面，在该调试配置界面上可显示常用调试条件以供开发人员进行选择，以确定相对应的配置调试条件，从而提高配置调试条件的配置效率。
111.加载程序代码，以获取需要进行调试的待调试代码；依次显示每一待调试代码对应的调试配置界面，以便准确快捷地配置与待调试代码对应的配置调试条件，从而获取源码文件，从而确定每一代调试代码的配置调试条件，有助于加快调试进度。
112.图7是本技术的一示例性实施例示出的测试用例的生成的示意性流程图。
113.参照图7所示，获取来自测试用例的信号，所述测试用例的生成，包括：
114.s601、建立预设用例生成规格模块及组合算法；
115.以所述可执行文件文本为例子，可执行文件文本接口中，总共有多个字段需要调
试，每一个字段具有相对应的规格，即是根据指定需求及设置产生各种用例的方法规范，规格的种类很多，但总的来说，可以区分为通用规格和专用规格两类，通过规格可以适用于多个字段，一般来说通用性强、较为简单，而专用规格只适用于某一个字段，一般来说较为复杂。
116.组合算法是用于当用例生成规格模块通过测试参数，建立多个参数测试用例后，将这些参数测试用例按照不同需求组合成实际需求的测试用例。
117.s602、数据测试参数值以建立扩展标记语言xml文件；
118.将生成规格模块与参数需求分别用c#和xml进行设计。如果将测试用例参数设置的功能集中到测试用例生成程序的界面操作完成，则灵活性和扩展性不够。如果是放到底层代码中完成，则不利于保护代码内部结构，同时普通的测试人员也不可能都掌握c#。而xml语言以其简单易用著称，就算对c#不熟悉的测试人员只要经过短暂的培训就可熟练掌握，这种办法大大减轻了测试人员的负担。
119.s603、对测试参数与对应的组合算法进行选择；
120.s604、规格模块基于测试参数建立参数测试用例，合成实际测试用例。
121.当测试人员根据测试需求，于xml文件中建立至少一测试参数值后，所述的测试参数值将读入对应的用例生成模块，通过用例生成规格模块中以c#编写的代码，建立多个参数测试用例。
122.图8是本技术的一示例性实施例示出的合成实际测试用例之后的方法流程图。
123.参照图8所示，规格模块基于测试参数建立参数测试用例，合成实际测试用例之后还包括：
124.s701、将所述实际测试用例输出至用户接口；s702、当实际测试用例有误时，重新建立xml文件。即一种检查程序，用来提供测试人员通过预览进行一个测试用例结果检查的程序。
125.本实施例中，可执行文件测试用例生成过程中通过分离较复杂的用例生成规格和较简单用例参数默认值，解决以往因测试工作造成繁琐的负担，并提高测试的通用性和可靠性，方便测试人员使用。需要说明的是，该测试人员并非指的是可执行文件经过路试考验之后交付的对象，而是开发人员。
126.图9是本技术的一示例性实施例示出的台架测试装置框图。
127.参照图9所示，本技术的实施例还公开了一种台架测试装置，包括：获取模块801、处理模块802、判断模块803。
128.其中，获取模块801，用于获取从仿真传感器传送的实车原始报文数据；处理模块802，用于域控制器内的底层、中间层依次对所述实车原始报文数据进行处理，并通过应用层发出信号；判断模块803，用于基于所述信号判断所述域控制器内的待测可执行文件相关功能是否正常激活，从而判定待测可执行文件是否通过测试。
129.在另一示例性实施例中，处理模块802，包括：信号获取单元，配置为获取来自测试用例的信号；测试用例信号处理单元，配置为底层对所述来自测试用例的信号进行相关处理；处理结果输出单元，配置为输出处理结果，并基于结果判断可执行文件收到的信息是否与上版本一致。
130.在另一示例性实施例中，在判断模块803之后还包括复杂工况数据处理模块，复杂
工况数据处理模块包括：复杂工况数据获取单元，配置为获取实车复杂工况数据；文件处理单元，配置为经调试之后的可执行文件对所述实车复杂工况数据进行处理；经调试可执行文件判断单元，配置为基于处理之后的信号判断经调试之后的可执行文件是否达标。
131.在另一示例性实施例中，处理结果输出单元还被配置为基于数据发送周期、数据量大小及数据类型判断可执行文件收到的信心是否与上版本一致。
132.在另一示例性实施例中，文件处理单元还被配置为：获取可执行文件对应的源码文件，所述源码文件包括至少一段待调试路试问题代码和与每一所述待调试路试问题代码相对应的配置调试条件；加载调试选项配置文件，所述调试选项配置文件包括至少一段原始调试代码和与每一所述原始调试代码相对应的原始调试选项；解析所述调试选项配置文件，生成调试选项字典；基于所述配置调试条件查询所述调试选项字典，将与所述配置调试条件相匹配的原始调试选项确定为目标调试选项，获取与所述目标调试选项相对应的目标调试代码；目标调试代码调试所述待调试路试问题代码。
133.在另一示例性实施例中，文件处理单元还被配置为：加载可执行文件对应的程序代码，所述程序代码包括至少一段待调试路试问题代码；依次显示每一所述待调试路试问题代码对应的调试配置界面，基于所述调试配置获取每一所述待调试路试问题代码对应的配置调试条件，获取所述源码文件。
134.在另一示例性实施例中，测试用例信号处理单元还配置为：建立预设用例生成规格模块及组合算法；数据测试参数值以建立扩展标记语言xml文件；对测试参数与对应的组合算法进行选择；规格模块基于测试参数建立参数测试用例，合成实际测试用例。
135.在另一示例性实施例中，测试用例信号处理单元还配置为：将所述实际测试用例输出至用户接口；当实际测试用例有误时，重新建立xml文件。
136.需要说明的是，上述实施例所提供的台架测试装置与上述实施例所提供的台架测试方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。上述实施例所提供的台架测试装置在实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能，本处也不对此进行限制。
137.图10是本技术的一示例性实施例示出的电子设备的计算机系统的结构示意图。
138.参照图10所示，本技术的实施例还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述电子设备实现上述各个实施例中提供的台架测试方法。
139.需要说明的是，图10示出的电子设备的计算机系统仅是一个示例，不应对本技术实施例的功能和使用范围带来任何限制。
140.如图10所示，计算机系统包括中央处理单元(central processing unit，cpu)901，其可以根据存储在只读存储器(read-only memory，rom)902中的程序或者从储存部分908加载到随机访问存储器(random access memory，ram)903中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在ram 903中，还存储有系统操作所需的各种程序和数据。cpu 901、rom 902以及ram 903通过总线904彼此相连。输入/输出(input/output，i/o)接口905也连接至总线904。
141.以下部件连接至i/o接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射
线管(cathode ray tube，crt)、液晶显示器(liquid crystal display，lcd)等以及扬声器等的输出部分907；包括硬盘等的储存部分908；以及包括诸如lan(local area network，局域网)卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至i/o接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入储存部分908。
142.特别地，根据本技术的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本技术的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(cpu)901执行时，执行本技术的系统中限定的各种功能。
143.需要说明的是，本技术实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(erasable programmable read only memory，eprom)、闪存、光纤、便携式紧凑磁盘只读存储器(compact disc read-only memory，cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本技术中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
144.附图中的流程图和框图，图示了按照本技术各种实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
145.描述于本技术实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
146.本技术的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，
该计算机程序被处理器执行时实现如前所述的台架测试方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。
147.应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本技术的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
148.本技术的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的台架测试方法。
149.通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本技术实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本技术实施方式的方法。
150.本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。
151.应当理解的是，本上述内容，仅为本技术的较佳示例性实施例，并非用于限制本技术的实施方案，本领域普通技术人员根据本技术的主要构思和精神，可以十分方便地进行相应的变通或修改，故本技术的保护范围应以权利要求书所要求的保护范围为准。