HIL automatic test control method, device and equipment and readable storage medium

By controlling third-party tools to run only during the execution of each sequence to be tested in HIL automation testing, the problem of log files being unable to be crawled due to long-term operation is solved, and the successful crawling and testing efficiency of log files is achieved. promote.

CN119473882APending Publication Date: 2025-02-18VOYAH AUTOMOBILE TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411521108.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-10-29
Publication Date
2025-02-18

AI Technical Summary

Technical Problem

In the prior art, there is a problem that the log files cannot be successfully crawled due to long-term operation of third-party tools.

Method used

Before executing the sequence to be tested, the control target third-party tool is in the running state and stops its operation after the sequence to be tested is completed, ensuring that the third-party tool only runs during the execution of each sequence to be tested.

Benefits of technology

By avoiding third-party tools running for a long time, they reduce their running memory, thereby avoiding jamming and exiting due to memory overflow, ensuring successful crawling of log files.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119473882A_ABST
    Figure CN119473882A_ABST
Patent Text Reader

Abstract

The invention discloses an HIL automatic test control method, device and equipment and a readable storage medium, and relates to the technical field of simulation test control, and the method comprises the steps: for each to-be-tested sequence, before the to-be-tested sequence is executed, controlling a target third-party tool to be in a running state; executing the to-be-tested sequence to enable the target third-party tool to capture a log file generated in the execution process of the to-be-tested sequence; after the to-be-tested sequences are executed, the test result is output, and the target third-party tool is controlled to be in the running stopping state, so that the target third-party tool only runs in the execution process of each to-be-tested sequence, the target third-party tool does not need to participate in the running of HIL automatic test software in the whole process, namely, the target third-party tool does not need to run for a long time; therefore, the running memory of the target third-party tool is reduced, the phenomena that the target third-party tool is stuck, exits and the like due to running memory overflow are effectively avoided, and successful capture of the log file can be ensured.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of simulation test control technology, and in particular to a HIL automated test control method, device, equipment and readable storage medium. Background Art

[0002] HIL (Hardware In the Loop) automated testing is a technology widely used in the automotive development and testing phase, which can simulate the vehicle's working environment and driver's operation when the Electronic Control Unit (ECU) is separated from the actual vehicle hardware. Among them, the HIL test system usually includes components such as hardware simulation platform, real-time simulation model, test management software and automated testing software. The organic combination of these components can provide a test platform that highly simulates the real vehicle operating environment, which not only greatly improves the efficiency and safety of the test, but also helps to ensure the safety and reliability of automotive products.

[0003] In HIL automated testing, test engineers often perform long-term tests, which may last for several hours or even several days, resulting in the continuous execution of thousands of test sequences. It is understandable that the purpose of testing is to discover defects in software or functions. That is, if a test sequence fails, the test engineer can use the test report provided by the HIL automated testing software to analyze which step of the test sequence is wrong. However, if it is necessary to delve deeper into the root cause of the problem, it is necessary to obtain the log file of the time when the problem occurred. However, for the entire vehicle function, the log file usually contains data such as CAN (Controller Area Network) / LIN (Local Interconnect Network) / ETH (Ethernet), and the HIL automated testing software does not provide the above data.

[0004] In the related art, if you want to keep the log files during the test, you usually need to manually use third-party tools to obtain them. Therefore, for long-term automated testing, the third-party tools that capture log files need to run for a long time together with the HIL automated testing software; however, the long-term operation of the third-party tools will cause its own running memory to overflow, resulting in the software tool being stuck or exiting, and thus the log files cannot be captured. It can be seen that how to ensure the successful capture of log files is a problem that needs to be solved urgently. Summary of the invention

[0005] The present application provides a HIL automated test control method, device, equipment and readable storage medium, which can solve the technical problem in the prior art that log files cannot be successfully captured due to the long-term operation of third-party tools.

[0006] In a first aspect, an embodiment of the present application provides a HIL automated test control method, the HIL automated test control method comprising:

[0007] For each sequence to be tested, before executing the sequence to be tested, controlling the target third-party tool to be in a running state;

[0008] Executing the sequence to be tested so that the target third-party tool captures the log files generated during the execution of the sequence to be tested;

[0009] After the sequence to be tested is executed, the test result is output and the target third-party tool is controlled to be in a stopped state.

[0010] In combination with the first aspect, in one implementation, after the step of outputting the test result after the sequence to be tested is executed, the method further includes:

[0011] Determine whether the sequence to be tested passes the test according to the test result;

[0012] If the test passes, all log files captured by the target third-party tool are deleted;

[0013] If the test fails, all log files captured by the target third-party tool are saved.

[0014] In combination with the first aspect, in one implementation, the step of saving all log files captured by the target third-party tool includes:

[0015] Obtaining the ID number of the sequence to be tested;

[0016] All log files are named based on the ID number, and all log files are stored in the same target folder, where the name of the target folder is determined based on the ID number.

[0017] In combination with the first aspect, in one implementation, the controlling target third-party tool is in a running state, including:

[0018] Calling a target interface corresponding to the target third-party tool;

[0019] After receiving the target response data sent by the target third-party tool and confirming that the target interface call is successful based on the target response data, the target third-party tool is started to put the target third-party tool into a running state.

[0020] In combination with the first aspect, in one implementation, before the step of controlling the target third-party tool to be in a running state, the method further includes:

[0021] The target third-party tool is determined according to the preset log file type corresponding to the sequence to be tested.

[0022] In a second aspect, an embodiment of the present application provides a HIL automated test control device, the HIL automated test control device comprising: a first control module, a second control module and a third control module;

[0023] For each sequence to be tested, the first control module is used to control the target third-party tool to be in a running state before executing the sequence to be tested;

[0024] The second control module is used to execute the sequence to be tested, so that the target third-party tool can capture the log file generated during the execution of the sequence to be tested;

[0025] The third control module is used to output the test result and control the target third-party tool to be in a stopped state after the sequence to be tested is executed.

[0026] In conjunction with the second aspect, in one implementation, the HIL automated test control device further includes a log control module, which is used to:

[0027] Determine whether the sequence to be tested passes the test according to the test result;

[0028] If the test passes, all log files captured by the target third-party tool are deleted;

[0029] If the test fails, all log files captured by the target third-party tool are saved.

[0030] In conjunction with the second aspect, in one implementation, the log control module is specifically used to:

[0031] Obtaining the ID number of the sequence to be tested;

[0032] All log files are named based on the ID number, and all log files are stored in the same target folder, where the name of the target folder is determined based on the ID number.

[0033] In conjunction with the second aspect, in one implementation, the first control module is specifically configured to:

[0034] Calling a target interface corresponding to the target third-party tool;

[0035] After receiving the target response data sent by the target third-party tool and confirming that the target interface call is successful based on the target response data, the target third-party tool is started to put the target third-party tool into a running state.

[0036] In conjunction with the second aspect, in one implementation, the first control module is further configured to: determine a target third-party tool according to a preset log file type corresponding to the sequence to be tested.

[0037] In a third aspect, an embodiment of the present application provides a HIL automated test control device, which includes a processor, a memory, and a HIL automated test control program stored in the memory and executable by the processor, wherein when the HIL automated test control program is executed by the processor, the steps of the aforementioned HIL automated test control method are implemented.

[0038] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a HIL automated test control program is stored, wherein when the HIL automated test control program is executed by a processor, the steps of the aforementioned HIL automated test control method are implemented.

[0039] The beneficial effects brought by the technical solution provided by the embodiments of the present application include:

[0040] By controlling the target third-party tool to be in a running state before executing the sequence to be tested, that is, executing the sequence to be tested after the target third-party tool starts running, and the target third-party tool will capture log files during the execution of the sequence to be tested; and controlling the target third-party tool to stop running after the execution of the sequence to be tested is completed, the target third-party tool is only run during the execution of each sequence to be tested, and does not need to participate in the operation of the HIL automated testing software throughout the whole process, that is, it does not need to run for a long time, thereby reducing the running memory of the target third-party tool, so as to effectively avoid the target third-party tool from being stuck or exiting due to running memory overflow, thereby ensuring the successful capture of log files. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a flow chart of an embodiment of the HIL automated test control method of the present application;

[0042] Figure 2This is a schematic diagram of the pretestcase test sequence workflow involved in the embodiment of the present application;

[0043] Figure 3 This is a schematic diagram of the posttestcase test sequence workflow involved in the embodiment of the present application;

[0044] Figure 4 This is a schematic diagram of the overall process of the HIL automated test involved in the embodiment of the present application;

[0045] Figure 5 This is a schematic diagram of the hardware structure of the HIL automated test control device involved in the embodiment of the present application. DETAILED DESCRIPTION

[0046] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0047] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0048] In a first aspect, an embodiment of the present application provides a HIL automated test control method.

[0049] In one embodiment, referring to Figure 1 , Figure 1 This is a flow chart of an embodiment of the HIL automated test control method of the present application. Figure 1 As shown, the HIL automated test control method includes:

[0050] Step S10: for each sequence to be tested, before executing the sequence to be tested, control the target third-party tool to be in a running state.

[0051] Exemplarily, it should be understood that the sequence to be tested refers to the test sequence that needs to be executed by the HIL automated test software; wherein, for the whole vehicle simulation test, there are often tens of thousands of sequences to be tested that need to be executed by the HIL automated test software, and in this embodiment, since the execution method and principle of each sequence to be tested in the HIL automated test software are the same, for the sake of brevity of description, the subsequent embodiments will only take one of the sequences to be tested as an example to explain the control process, method and principle of the HIL automated test. It should be noted that the test method and principle of the HIL automated test software for performing the test sequence are common knowledge in the art, and for the sake of brevity of description, they are not limited here.

[0052] In addition, the target third-party tool refers to a tool used to capture log files generated by the HIL automated testing software during the execution of the sequence to be tested. It can be a general third-party tool (such as CAnoe, etc.) or a third-party tool developed by the enterprise itself, and is not limited here. It should be noted that the implementation method and principle of log file capture by third-party tools are common knowledge in the field, so for the sake of brevity of description, no limitation is made here.

[0053] In this embodiment, before executing each sequence to be tested, it is necessary to first control the target third-party tool to be in a running state, even if the target third-party tool starts running; in other words, if the target third-party tool does not start running, the sequence to be tested will not be executed. Specifically, a pretestcase test sequence can be generated in the HIL automated testing software by means of a Python (an object-oriented programming language) script, so as to control the target third-party tool to be in a running state before executing each sequence to be tested through the pretestcase test sequence.

[0054] Furthermore, in one embodiment, the controlling target third-party tool is in a running state, including:

[0055] Calling a target interface corresponding to the target third-party tool;

[0056] After receiving the target response data sent by the target third-party tool and confirming that the target interface call is successful based on the target response data, the target third-party tool is started to put the target third-party tool into a running state.

[0057] Exemplarily, it should be understood that the target interface refers to an interface for implementing data interaction between the target third-party tool and the HIL automated test software; see Figure 2As shown, when the running state of the target third-party tool is controlled by the pretestcase test sequence, a call request corresponding to the target interface (including but not limited to the interface address, request parameters, request method, and necessary authentication information, etc.) is first sent to the target third-party tool; after the target third-party tool confirms that the request parameters are correct and meet the interface requirements of the third-party tool based on the call request, the corresponding target response data will be returned; after confirming that the target interface call is successful according to the target response data, the target third-party tool will start to run so that the target third-party tool can crawl data.

[0058] Furthermore, in one embodiment, before the step of controlling the target third-party tool to be in a running state, the method further includes:

[0059] The target third-party tool is determined according to the preset log file type corresponding to the sequence to be tested.

[0060] Exemplarily, it should be understood that the types of log files generated by different sequences to be tested may be different, wherein different file types can be distinguished based on the file suffix (e.g., CAN / LIN data can be stored as .blf or .asc type files, and ETH data can be stored as .pcap or .pcapng type files); assuming that the data generated by sequence A to be tested includes CAN data and ETH data, and the data generated by sequence B to be tested includes CAN data and LIN data, then the log files corresponding to the CAN data and LIN data are .blf or .asc type files, and the log files corresponding to the ETH data are .pcap or .pcapng type files; although different types of log files can be captured by the same third-party tool, it is not ruled out that due to corporate competition issues, some companies cannot use the same third-party tool to complete the capture of all types of log files, and need to use different third-party tools to achieve the capture of different types of log files. It should be noted that the data types generated by the sequences to be tested and the corresponding log file types can be known in advance and integrated into the HIL automated testing software.

[0061] For scenarios where different third-party tools are required to capture different types of log files, it is understandable that different third-party tools may be required for different sequences to be tested. For example, for sequence A to be tested, it requires third-party tool 1 for capturing .blf or .asc type files and third-party tool 2 for .pcap or .pcapng type files; while for sequence B to be tested, it only requires third-party tool 1 for capturing .blf or .asc type files; it can be seen that sequence B to be tested does not require third-party tool 2.

[0062] It should be understood that the calling and starting of a third-party tool requires a certain amount of time and memory, and the time and memory required for different third-party tools may be different; therefore, before executing the sequence to be tested, if all third-party tools including those not required by the sequence to be tested are started, it will cause a waste of resources and a reduction in test efficiency to a certain extent; for example, before executing the sequence to be tested B, if both third-party tools 1 and 2 are controlled to be started, it will not only cause the capture action of the third-party tool 2 to be invalid and waste unnecessary running memory, but also require additional waiting for the third-party tool 2 to be started before the sequence to be tested B can be executed, that is, the waiting time required to execute the sequence to be tested B becomes longer, which will reduce the test efficiency of the sequence to be tested B.

[0063] In order to solve the above problems, this embodiment will only run the third-party tools required by the sequence to be tested, so as to effectively reduce the running memory and improve the test efficiency. Specifically, the target third-party tool can be determined according to the log file type corresponding to the sequence to be tested. For example, for sequence A to be tested, third-party tools 1 and 2 used to capture the corresponding log file types (i.e., .blf or .asc type files and .pcap or .pcapng type files) are used as target third-party tools. Therefore, before executing sequence A to be tested, third-party tools 1 and 2 need to be controlled to run; similarly, before executing sequence B to be tested, only third-party tool 1 needs to be controlled to run.

[0064] Step S20: executing the sequence to be tested, so that the target third-party tool captures the log file generated during the execution of the sequence to be tested.

[0065] Exemplarily, in this embodiment, after running the target third-party tool, the HIL automated testing software will start to execute the sequence to be tested according to the preset test plan. During this process, the target third-party tool will capture the log files generated during the execution of the sequence to be tested in real time; since the target third-party tool has just been run before the execution of the sequence to be tested, in other words, the running time of the target third-party tool is almost the same as the execution time of the sequence to be tested, that is, the target third-party tool has not been running for a long time, so it can be ensured that the target third-party tool will not be stuck or exit due to memory overflow during its own operation, thereby ensuring that all log files can be successfully captured by the target third-party tool.

[0066] Step S30: After the sequence to be tested is executed, the test result is output and the target third-party tool is controlled to be in a stopped state.

[0067] Exemplarily, in this embodiment, when the sequence to be tested is executed, the HIL automated testing software will not only output the corresponding test results (the test results include information such as whether the test passed or not), but will also immediately stop running all target third-party tools after the sequence to be tested is executed, that is, the target third-party tools are in a stopped state, so that the target third-party tools only run during the execution of the sequence to be tested, so as to avoid the target third-party tools from running for a long time.

[0068] Specifically, a posttestcase test sequence can be generated in the HIL automated test software through Python scripts, etc., so as to control the target third-party tool to stop running after each sequence to be tested is executed. For example, for sequence A to be tested, after sequence A to be tested is executed, the posttestcase test sequence can be used to control third-party tools 1 and 2 to stop running, and the log files captured by third-party tools 1 and 2 can be stored and processed; at the same time, the next sequence to be tested B can continue to be executed. Of course, when executing sequence B to be tested, it is still necessary to control third-party tool 1 to start running through the pretestcase test sequence, that is, to start processing again from step S10.

[0069] It can be seen that this embodiment controls the target third-party tool to be in a running state before executing the sequence to be tested, that is, the sequence to be tested is executed after the target third-party tool starts running, and the target third-party tool will capture log files during the execution of the sequence to be tested; and controls the target third-party tool to stop running after the execution of the sequence to be tested is completed, so that the target third-party tool only runs during the execution of each sequence to be tested, and does not need to participate in the operation of the HIL automated testing software throughout the whole process, that is, it does not need to run for a long time, thereby reducing the running memory of the target third-party tool, so as to effectively avoid the target third-party tool from being stuck or exiting due to running memory overflow, thereby ensuring the successful capture of log files.

[0070] Furthermore, in one embodiment, after the step of outputting the test result after the sequence to be tested is executed, the method further includes:

[0071] Determine whether the sequence to be tested passes the test according to the test result;

[0072] If the test passes, all log files captured by the target third-party tool are deleted;

[0073] If the test fails, all log files captured by the target third-party tool are saved.

[0074] For example, see Figure 3 As shown, after the target third-party tool is controlled to stop running through the posttestcase test sequence, the test result corresponding to the test sequence output by the automated testing software is also obtained, and based on the test result, it is determined whether the test of the sequence to be tested is passed. For example, if the test result is success or none, it means that the test is passed, and if the test result is fail or error, it means that the test is not passed; wherein, when the test is passed, it means that there are no error items in the sequence to be tested. In other words, it is not necessary to perform problem analysis on the sequence to be tested based on the log file. Therefore, this embodiment will delete all log files corresponding to the sequence to be tested captured by the target third-party tool to avoid occupying storage memory; and when the test fails, it means that there are error items in the sequence to be tested. In other words, it is necessary to perform problem analysis on the sequence to be tested based on the log file. Therefore, this embodiment will save all log files corresponding to the sequence to be tested captured by the target third-party tool.

[0075] Furthermore, in one embodiment, the step of saving all log files captured by the target third-party tool includes:

[0076] Obtaining the ID number of the sequence to be tested;

[0077] All log files are named based on the ID number, and all log files are stored in the same target folder, where the name of the target folder is determined based on the ID number.

[0078] For example, it is understandable that after running for a long time, current third-party tools often capture logs for tens of thousands of test sequences, and all logs are stored in one file, so that the memory of the stored log files is usually very large, which not only causes the third-party tools to consume a long time to load and play back these log files for users to view and analyze, but also when test engineers analyze one of the failed sequences, it is often difficult to find the time when the problem occurred from the huge log files, that is, it is difficult to obtain relevant data before the problem occurred for problem analysis, thereby increasing the difficulty of analyzing the root cause of the problem.

[0079] To solve the above problems, see Figure 3As shown, in this embodiment, after the third-party tool completes the capture of the log file of a sequence to be tested, the posttestcase test sequence will process all its log files, that is, when the test sequence fails, all its corresponding log files will be renamed based on the ID number of the sequence to be tested, and the renamed log files will be packaged and placed in the same folder, and the name of the folder will also be renamed with the ID number of the sequence to be tested, and finally the folder will be stored in the specified path, so that the test engineer can quickly locate and retrieve the corresponding log file according to the ID number of the test sequence for problem analysis.

[0080] For example, assuming that during the execution of the sequence to be tested A with ID number Z1, the log files captured by the third-party tool 1 include log file X1, and the log files captured by the third-party tool 2 include log file Y1 and log file Y2, then after the sequence to be tested A is executed and the test result is that the test fails, the log file X1, log file Y1 and log file Y2 are renamed based on Z1, and then the renamed log files X1, log file Y1 and log file Y2 are packaged and stored in folder P; the folder P is then renamed based on Z1, and finally the renamed folder P is stored in the specified path.

[0081] For another example, assuming that during the execution of the test sequence B with ID number Z2, the log files captured by the third-party tool 1 include log files X2 and X3, then after the test sequence B is executed and the test result is that the test fails, the log file X1 and the log file X2 are renamed based on Z2, and then the renamed log files X1 and X2 are packaged and stored in the folder M; then the folder M is renamed based on Z2, and finally the renamed folder M is stored in the specified path.

[0082] It can be seen that this embodiment manages the log files corresponding to each sequence to be tested separately, that is, the log files belonging to the same sequence to be tested are placed in the same folder, so that a relatively small log file can be provided for a single test sequence to facilitate analysis by test engineers, effectively improving the test efficiency and troubleshooting efficiency.

[0083] In general, see Figure 4As shown, in the present embodiment, two test steps are added for each sequence to be tested in the original HIL automated test execution steps, that is, before each sequence to be tested is executed, a pretestcase test sequence named pretestcase.py is first executed to run the third-party tool for capturing logs through the pretestcase test sequence; then the sequence to be tested is executed normally according to the processing logic of the automated test software, and after the sequence to be tested is executed, a posttestcase test sequence named posttestcase.py is executed, and the log file is deleted or stored according to the aforementioned control strategy, thereby completing the storage of the error item test log file based on the HIL automated test.

[0084] In summary, in the HIL automated testing process, the present embodiment does not need to manually record additional test log files, and the fully automated testing process reduces manual operations, and can provide test engineers with separate log files based on each test case that fails the test, so that the test engineers can locate and analyze the problem and save time for troubleshooting; secondly, the third-party tool will be started and stopped for each test sequence to avoid the third-party tool from running for a long time and causing its own memory overflow, thereby preventing the third-party tool from getting stuck and exiting due to memory overflow; in addition, a log file can be provided for a single test sequence, so that the time and specific data of the problem can be located according to the folder name of the log file and the file name of the log file, which greatly facilitates the test engineer to analyze the problem without wasting time to determine the time point when the problem occurred, saving a lot of time and improving the test efficiency and troubleshooting efficiency; in addition, the present embodiment also directly deletes the log files of the test sequences that have passed the test, and deleting these useless files can effectively save the memory of the test host computer.

[0085] In a second aspect, an embodiment of the present application also provides a HIL automated test control device.

[0086] In one embodiment, the HIL automated test control device comprises: a first control module, a second control module and a third control module;

[0087] For each sequence to be tested, the first control module is used to control the target third-party tool to be in a running state before executing the sequence to be tested;

[0088] The second control module is used to execute the sequence to be tested, so that the target third-party tool can capture the log file generated during the execution of the sequence to be tested;

[0089] The third control module is used to output the test result and control the target third-party tool to be in a stopped state after the sequence to be tested is executed.

[0090] Furthermore, in one embodiment, the HIL automated test control device further includes a log control module, which is used to:

[0091] Determine whether the sequence to be tested passes the test according to the test result;

[0092] If the test passes, all log files captured by the target third-party tool are deleted;

[0093] If the test fails, all log files captured by the target third-party tool are saved.

[0094] Furthermore, in one embodiment, the log control module is specifically used to:

[0095] Obtaining the ID number of the sequence to be tested;

[0096] All log files are named based on the ID number, and all log files are stored in the same target folder, where the name of the target folder is determined based on the ID number.

[0097] Furthermore, in one embodiment, the first control module is specifically used for:

[0098] Calling a target interface corresponding to the target third-party tool;

[0099] After receiving the target response data sent by the target third-party tool and confirming that the target interface call is successful based on the target response data, the target third-party tool is started to put the target third-party tool into a running state.

[0100] Furthermore, in one embodiment, the first control module is further configured to: determine a target third-party tool according to a preset log file type corresponding to the sequence to be tested.

[0101] Among them, the functional implementation of each module in the above-mentioned HIL automatic test control device corresponds to each step in the above-mentioned HIL automatic test control method embodiment, and its functions and implementation processes are no longer repeated here.

[0102] In a third aspect, an embodiment of the present application provides a HIL automated test control device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0103] Reference Figure 5 , Figure 5 Schematic diagram of the hardware structure of the HIL automated test control device involved in the embodiment of the present application. In the embodiment of the present application, the HIL automated test control device may include a processor, a memory, a communication interface and a communication bus.

[0104] The communication bus may be of any type and is used to interconnect the processor, the memory, and the communication interface.

[0105] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces, which are used to interconnect devices within the HIL automated test control equipment, as well as interfaces used to interconnect the HIL automated test control equipment with other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet interfaces, optical fiber interfaces, ATM interfaces, etc.; user devices can be display screens (Display), keyboards (Keyboard), etc.

[0106] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0107] The processor may be a general-purpose processor, which may call the HIL automated test control program stored in the memory and execute the HIL automated test control method provided by the embodiment of the present application. For example, the general-purpose processor may be a central processing unit (CPU). The method executed when the HIL automated test control program is called may refer to the various embodiments of the HIL automated test control method of the present application, which will not be described in detail here.

[0108] Those skilled in the art will understand that Figure 5 The hardware structure shown in the figure does not constitute a limitation on the present application, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0109] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium.

[0110] The readable storage medium of the present application stores a HIL automated test control program, wherein when the HIL automated test control program is executed by a processor, the steps of the HIL automated test control method described above are implemented.

[0111] Among them, the method implemented when the HIL automated test control program is executed can refer to the various embodiments of the HIL automated test control method of the present application, and will not be repeated here.

[0112] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.

[0113] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.

[0114] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0115] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0116] In some processes described in the embodiments of the present application, multiple operations or steps that appear in a specific order are included, but it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or in parallel, and the sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.

[0117] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.

[0118] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A HIL automated test control method, characterized in that: The HIL automated test control method comprises: For each sequence to be tested, before executing the sequence to be tested, controlling the target third-party tool to be in a running state; Executing the sequence to be tested so that the target third-party tool captures the log files generated during the execution of the sequence to be tested; After the sequence to be tested is executed, the test result is output and the target third-party tool is controlled to be in a stopped state.

2. The HIL automated test control method according to claim 1, characterized in that: After the step of outputting the test result after the sequence to be tested is executed, the method further includes: Determine whether the sequence to be tested passes the test according to the test result; If the test passes, all log files captured by the target third-party tool are deleted; If the test fails, all log files captured by the target third-party tool are saved.

3. The HIL automated test control method according to claim 2, characterized in that: The storing and processing of all log files captured by the target third-party tool includes: Obtaining the ID number of the sequence to be tested; All log files are named based on the ID number, and all log files are stored in the same target folder, where the name of the target folder is determined based on the ID number.

4. The HIL automated test control method according to claim 1, characterized in that: The control target third-party tool is in operation, including: Calling a target interface corresponding to the target third-party tool; After receiving the target response data sent by the target third-party tool and confirming that the target interface call is successful based on the target response data, the target third-party tool is started to put the target third-party tool into a running state.

5. The HIL automated test control method according to claim 1, characterized in that: Before the step of controlling the target third-party tool to be in a running state, the method further includes: The target third-party tool is determined according to the preset log file type corresponding to the sequence to be tested.

6. A HIL automated test control device, characterized in that: The HIL automated test control device comprises: a first control module, a second control module and a third control module; For each sequence to be tested, the first control module is used to control the target third-party tool to be in a running state before executing the sequence to be tested; The second control module is used to execute the sequence to be tested, so that the target third-party tool can capture the log file generated during the execution of the sequence to be tested; The third control module is used to output the test result and control the target third-party tool to be in a stopped state after the sequence to be tested is executed.

7. The HIL automated test control device according to claim 6, characterized in that: The HIL automated test control device further includes a log control module, which is used to: Determine whether the sequence to be tested passes the test according to the test result; If the test passes, all log files captured by the target third-party tool are deleted; If the test fails, all log files captured by the target third-party tool are saved.

8. The HIL automated test control device according to claim 7, characterized in that: The log control module is specifically used for: Obtaining the ID number of the sequence to be tested; All log files are named based on the ID number, and all log files are stored in the same target folder, where the name of the target folder is determined based on the ID number.

9. A HIL automated test control device, characterized in that: The HIL automated test control device comprises a processor, a memory, and a HIL automated test control program stored in the memory and executable by the processor, wherein when the HIL automated test control program is executed by the processor, the steps of the HIL automated test control method according to any one of claims 1 to 5 are implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a HIL automated test control program, wherein when the HIL automated test control program is executed by a processor, the steps of the HIL automated test control method according to any one of claims 1 to 5 are implemented.