A rack test method and apparatus, and an electronic device

Abstract

Embodiments of the present application provide a rack test method and device and electronic equipment, the method comprises: acquiring real vehicle original message data transmitted from a simulation sensor; a bottom layer and an intermediate layer in a domain controller successively process the real vehicle original message data, and a signal is sent through an application layer; whether a function related to a to-be-tested executable file in the domain controller is normally activated is judged based on the signal, so as to determine whether the to-be-tested executable file passes the test. The technical solution provided by the embodiments of the present application reduces the software development cycle and cost, improves the software development efficiency, separates the development and testing into two bodies, improves the test efficiency, effectively reduces the meaningless test of the development accompanying test personnel, solves the problems of low debugging efficiency in the process of debugging the executable file and solving the bit BUG, and improves the universality and reliability of the test.

Description

Technical Field

[0001] This application relates to the field of software testing technology, specifically to a bench testing method and apparatus, and electronic equipment. Background Technology

[0002] Intelligent driving vehicles are vehicles that incorporate intelligent driving technologies into traditional vehicles. They utilize onboard sensors to perceive various environmental information around the vehicle, such as lane lines, obstacles, location data, and road signs. Based on this perceived information about the road, vehicle position, and obstacles, they make intelligent decisions and plan routes, controlling the vehicle's lateral (steering) and longitudinal (speed) movements, thereby enabling the vehicle to drive safely and reliably on the road.

[0003] The development process of intelligent driving vehicles includes the development of components and the complete vehicle. After the software code is developed and integrated, the current approach is to directly test it on a real vehicle. On the real vehicle, domain control is used to control the vehicle. After the software is burned into the host computer, testers and developers need to conduct real vehicle testing. However, there are many uncertainties in real vehicle conditions, such as vehicle sensor failures and hardware problems such as incompatibility of the underlying vehicle software version. However, it is not very meaningful for developers to participate in troubleshooting these factors, and such problems reduce the efficiency of testers, becoming a key reason for the inability to deliver projects on time.

[0004] Chinese patent document CN213042144U discloses a technology entitled "A Fusion Test Bench for an Autonomous Driving System," which relates to the field of autonomous driving system testing technology. The technology includes: a first device under test (DUT) housing a first autonomous driving assistance system; a second DUT housing a second autonomous driving assistance system; a vehicle function simulation device connected to both the first and second DUTs; an actuator connected to both the first and second DUTs; an information integration and enhancement device connected to both the first and second DUTs; and a test control device equipped with a virtual driving simulation platform, connected to both the information integration and enhancement device and the vehicle function simulation device. This technology enables the fusion function testing of the first and second autonomous driving assistance systems in a laboratory environment. However, this technology does not simulate vehicle sensors or perform actual signal input, which can lead to hardware problems such as sensor input errors in real-vehicle testing. It is unfriendly to developers and testers, time-consuming, and has unclear responsibilities, hindering efficiency.

[0005] Chinese patent document CN111289252A discloses a technology entitled "A Bench Testing Method, Apparatus, Computer Equipment, and Storage Medium." This technology adjusts the engine's operating state by acquiring test boundary conditions and then performs bench testing on the engine based on the adjusted operating state. In this embodiment, the engine's test boundary conditions include target values ​​for the engine's test operating parameters and / or adjustment rules for the test critical conditions. Thus, the computer equipment can automatically adjust the engine's operating state according to these test boundary conditions, and after the engine's operating state is adjusted, bench testing automatically begins according to the program. The entire process requires no manual debugging or judgment, greatly improving testing efficiency and the accuracy of test results. However, this technology does not simulate vehicle sensors or perform actual signal input. In real-vehicle testing, this can lead to hardware problems such as sensor input errors, making it unfriendly to developers and testers, time-consuming, and with unclear division of responsibilities, hindering efficiency improvement. Summary of the Invention

[0006] To address the aforementioned technical problems, embodiments of this application provide a bench testing method, apparatus, and electronic device. This aims to reduce software development cycle and cost, improve software development efficiency, and clearly define the specific responsibilities of developers and side engineers. Furthermore, it addresses the issue of low debugging efficiency in locating or resolving bugs when debugging executable files, and improves the versatility and reliability of the test.

[0007] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0008] According to one aspect of the embodiments of this application, a bench testing method is provided, comprising:

[0009] Acquire raw vehicle message data transmitted from simulated sensors;

[0010] The bottom and middle layers within the domain controller process the original message data of the actual vehicle in sequence, and send signals through the application layer;

[0011] Based on the signal, it is determined whether the relevant functions of the executable file under test in the domain controller are activated normally, thereby determining whether the executable file under test has passed the test.

[0012] In the technical solution provided by the embodiments of this application, the bottom layer and the middle layer within the domain controller process the original vehicle message data sequentially, and send signals through the application layer, including:

[0013] Get signals from the test cases;

[0014] The underlying layer performs relevant processing on the signals from the test cases;

[0015] Output the processing results and determine whether the information received by the executable file is consistent with the previous version based on the results.

[0016] In the technical solution provided by the embodiments of this application, after determining whether the functions related to the executable file under test in the domain controller are normally activated based on the signal, and thus determining whether the executable file under test has passed the test, the method further includes:

[0017] Acquire data on complex operating conditions of real vehicles;

[0018] The debugged executable file processes the complex operating condition data of the actual vehicle.

[0019] The processed signal is used to determine whether the debugged executable file meets the standards.

[0020] In the technical solution provided in the embodiments of this application, the processing result is output, and the information received by the executable file is determined based on the result to be consistent with the previous version, including: determining whether the information received by the executable file is consistent with the previous version based on the data sending cycle, data size and data type.

[0021] In the technical solution provided in the embodiments of this application, the debugged executable file processes the complex operating condition data of the real vehicle, including:

[0022] Obtain the source code file corresponding to the executable file, wherein the source code file includes at least one piece of road test problem code to be debugged and configuration debugging conditions corresponding to each piece of road test problem code to be debugged;

[0023] Load the debug option configuration file, which includes at least one piece of raw debug code and raw debug options corresponding to each piece of raw debug code;

[0024] Parse the debug option configuration file to generate a debug option dictionary;

[0025] Based on the configuration debugging conditions, the debug option dictionary is queried, the original debug option that matches the configuration debugging conditions is determined as the target debug option, and the target debug code corresponding to the target debug option is obtained;

[0026] The target is to debug the code for the road test problem to be debugged.

[0027] In the technical solutions provided in the embodiments of this application, obtaining the source code file corresponding to the executable file includes:

[0028] Load the program code corresponding to the executable file, wherein the program code includes at least one piece of code for a road test to be debugged;

[0029] The debugging configuration interface corresponding to each of the road test issues to be debugged is displayed sequentially. Based on the debugging configuration, the configuration debugging conditions corresponding to each of the road test issues to be debugged are obtained, and the source code file is obtained.

[0030] In the technical solution provided in the embodiments of this application, a signal from a test case is obtained, and the generation of the test case includes:

[0031] Establish a pre-defined test case generation specification module and combination algorithm;

[0032] Data test parameter values ​​are used to create an Extended Markup Language (XML) file;

[0033] Select the test parameters and their corresponding combination algorithms;

[0034] The specification module creates parameter test cases based on test parameters and synthesizes actual test cases.

[0035] In the technical solution provided by the embodiments of this application, the specification module establishes parameter test cases based on test parameters, and after synthesizing actual test cases, it further includes:

[0036] Output the actual test cases to the user interface;

[0037] If the actual test cases are incorrect, rebuild the XML file.

[0038] According to one aspect of the embodiments of this application, a bench testing apparatus is also provided, comprising:

[0039] The acquisition module is used to acquire the original message data of the real vehicle transmitted from the simulation sensors;

[0040] The processing module is used to process the original message data of the actual vehicle sequentially through the bottom layer and the middle layer within the domain controller, and to send signals through the application layer.

[0041] The judgment module is used to determine whether the relevant functions of the executable file under test in the domain controller are normally activated based on the signal, thereby determining whether the executable file under test has passed the test.

[0042] According to one aspect of the embodiments of this application, an electronic device is also provided, comprising:

[0043] One or more processors;

[0044] A storage device for storing one or more programs that, when executed by one or more processors, cause the point to implement the bench test method as described above in the device.

[0045] According to one aspect of the embodiments of this application, a computer-readable storage medium is also provided, on which computer-readable instructions are stored, which, when executed by the processor of a computer, cause the computer to perform the above-described bench test method.

[0046] According to one aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the above-described bench testing method.

[0047] The beneficial effects of the present invention are as follows: The technical solutions provided by the embodiments of this application reduce the software development cycle and cost, improve software development efficiency, separate the development and testing tools, improve testing efficiency, effectively reduce meaningless testing by developers accompanying testers, solve the problem of low debugging efficiency in debugging executable files, and improve the universality and reliability of testing.

[0048] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0049] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0050] Figure 1 This is a schematic diagram of the technical architecture shown in an exemplary embodiment of this application;

[0051] Figure 2 This is a schematic flowchart illustrating a bench testing method as shown in an exemplary embodiment of this application;

[0052] Figure 3 This is an exemplary embodiment of the present application illustrating a flowchart for determining whether the information received by the executable file is consistent with the previous version;

[0053] Figure 4 This is an exemplary embodiment of the present application illustrating a schematic flowchart of determining whether a debugged executable file is capable of processing complex operating condition data;

[0054] Figure 5 This is a schematic flowchart illustrating a debug executable file as shown in an exemplary embodiment of this application;

[0055] Figure 6 This is an exemplary flowchart illustrating how to obtain the source code file corresponding to an executable file, as shown in an exemplary embodiment of this application.

[0056] Figure 7 This is a schematic flowchart illustrating the generation of test cases, as shown in an exemplary embodiment of this application;

[0057] Figure 8 This is a flowchart illustrating a method after synthesizing actual test cases, as shown in an exemplary embodiment of this application;

[0058] Figure 9 This is a block diagram of a bench testing apparatus shown in an exemplary embodiment of this application;

[0059] Figure 10 This is a schematic diagram of the structure of a computer system for an electronic device, as illustrated in an exemplary embodiment of this application. Detailed Implementation

[0060] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0061] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0062] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0063] This article relates to the bench simulation of MCUs (Microcontroller Units) and SOCs (System-On-A-Chips) for intelligent driving vehicles before they are put into actual vehicles on an industrial control computer. More specifically, it relates to a bench testing method.

[0064] The development process of intelligent driving vehicles includes the development of components and the complete vehicle. After the software code is developed and integrated, the current approach is to directly test it on a real vehicle. On the real vehicle, domain control is used to control the vehicle. After the software is flashed onto the host computer, testers and developers need to conduct real-vehicle testing. However, many uncertainties arise in real-vehicle environments, such as vehicle sensor malfunctions and hardware issues like incompatible underlying software versions. It's not very meaningful for developers to troubleshoot these issues, and such problems reduce the efficiency of testers, becoming a key reason for delayed project delivery. This involves the complex issue of dividing responsibilities.

[0065] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings.

[0066] Figure 1 This is a schematic diagram of the technical architecture shown in an exemplary embodiment of this application.

[0067] like Figure 1 As shown, the bench testing method includes the following steps: S1001, releasing the software version, with developers writing and self-testing code, and uploading the code to the code repository; S1002, conducting bench testing; and S1003, delivering the software.

[0068] Specifically, S1002 includes: S1004, original data back injection; S1005, comparison of underlying input data; and S1006, problem ticket data back injection.

[0069] Figure 2 This is a schematic flowchart illustrating a bench testing method as shown in an exemplary embodiment of this application.

[0070] like Figure 2 As shown, the steps of this bench test method include:

[0071] S101. Obtain the original vehicle message data transmitted from the simulation sensor.

[0072] Original message data playback is achieved by recording data using real vehicle debugging tools, including original messages. Although the interfaces are not uniform across versions, using the original message format allows for data playback without changing the underlying sensor layer of the test vehicle, and it is applicable to each version.

[0073] After the developers complete the development, the domain controller is integrated, and then bench testing can be performed directly to check whether the corresponding functions can be completed. The implementation method is to use specific data that can reflect the corresponding module. In this way, functional verification can be performed without going on the vehicle, shortening the cycle and making it more efficient.

[0074] S102, the bottom layer and the middle layer in the domain controller process the original message data of the actual vehicle in sequence, and send signals through the application layer.

[0075] The underlying simulation output results are compared. The sensor and underlying version will have version iterations, but the frequency is not consistent with the version iteration and is relatively independent. In order to verify whether the information received by the software is consistent with the previous version, including data transmission cycle, data volume, data type, etc., to avoid abnormal functioning due to different received data after the vehicle is installed.

[0076] S103. Based on the signal, determine whether the relevant functions of the executable file under test in the domain controller are normally activated, thereby determining whether the executable file under test has passed the test.

[0077] Complex operating condition data replay: After the software version is released and road tests are conducted, various operating condition problems may occur. Here, we focus on modifying the source code logic-related issues. After the developers complete the modifications, we conduct tests, and the replay data uses the data from the road test at that time. We observe the effect of the code modifications through replay and visualization tools.

[0078] Developing software interactions and completing the above steps will greatly reduce the number of development-related issues during road tests. At the same time, more time will be available to verify the functional logic of the software code, improve testing efficiency, and avoid using the serious impact on testing efficiency as the reason for each test.

[0079] Specifically, this application aims to reduce software development cycle and cost, improve software development efficiency, and clearly define the specific responsibilities of developers and testers. To achieve these objectives, this application proposes an embodiment, the technical solution of which involves the following method: original message data playback, using a real-vehicle debugging tool to record data, including original messages. Since the interface is not uniform across versions, using original messages allows data playback without changing the underlying sensor layer of the test vehicle, and is applicable to each version. After the developers complete development, domain control integration is performed, followed by bench testing to verify if the corresponding functions can be completed. This is achieved using specific data that reflects the corresponding module, allowing functional verification without on-vehicle testing, shortening the cycle and increasing efficiency.

[0080] The comparison of the underlying simulation output results shows that while the sensor and underlying versions may have version iterations, the frequency of these iterations is relatively independent and does not follow the previous version. This step is to verify whether the information received by the software is consistent with the previous version, including the data transmission cycle, data volume, and data type, to avoid functional malfunctions caused by different received data after installation.

[0081] Complex operating condition data replay: After the software version is released and road tests are conducted, various operating condition problems may occur. Here, we focus on modifying the source code logic-related issues. After the developers complete the modifications, we conduct tests, and the replay data uses the data from the road test at that time. We observe the effect of the code modifications through replay and visualization tools.

[0082] Once the above steps are completed, the number of development-related issues during road testing will be greatly reduced. At the same time, more time will be available to verify the functional logic of the software code, improving testing efficiency and avoiding the situation where every test is cited as a reason for its failure to meet testing efficiency.

[0083] Figure 3 This is an exemplary embodiment of the present application illustrating a flowchart for determining whether the information received by the executable file is consistent with the previous version.

[0084] Reference Figure 3 As shown, the bottom layer and middle layer within the domain controller process the original message data of the actual vehicle in sequence, and send signals through the application layer, including: S201, obtaining signals from test cases; S202, the bottom layer performs relevant processing on the signals from test cases; S203, outputting the processing results, and judging whether the information received by the executable file is consistent with the previous version based on the results.

[0085] Raw data is injected back into the controller. An executable file generated by the developers is burned into the domain controller, and simulation is performed to observe whether the function can be activated normally without changing the sensors and underlying layers. If there are functional abnormalities, visualization tools can be used to observe whether the problem stems from logical errors or unmet operating conditions. Underlying data is compared: the sensors and the underlying system are tested using test cases to input signals. Under the same test cases, the output results are compared to the previous version. If there are differences, the compatibility issue is immediately resolved. The same principle applies to the underlying software.

[0086] Figure 4 This is an exemplary embodiment of the present application illustrating a schematic flowchart of determining whether a debugged executable file is capable of processing complex operating condition data.

[0087] Reference Figure 4 As shown, after determining whether the functions related to the executable file under test within the domain controller are properly activated based on the signal, and thus determining whether the executable file under test has passed the test, the method further includes:

[0088] S301. Acquire complex operating condition data of the actual vehicle; S302. Process the complex operating condition data of the actual vehicle using the debugged executable file; S303. Determine whether the debugged executable file meets the standards based on the processed signal.

[0089] Complex operating condition data replay: After the software version is released and road tests are conducted, various operating condition problems may occur. Here, we focus on modifying the source code logic-related issues. After the developers complete the modifications, we conduct tests, and the replay data uses the data from the road test at that time. We observe the effect of the code modifications through replay and visualization tools.

[0090] Based on the signals, it is determined whether the relevant functions of the executable file under test within the domain controller are activated normally, thereby determining whether the executable file under test has passed the test. Subsequent steps must be performed only upon software delivery. After modifications, developers can conduct independent bench simulations. Data issues can be resolved by modifying the issue report. Software interaction is only permitted after the software is problem-free. The testing team then conducts trial runs. These steps clarify responsibilities, personalize the division of labor between development and testing, improve testing efficiency, and effectively reduce meaningless testing involving developers and testers.

[0091] Specifically, this method includes software release, bench testing, and software interaction. Software release involves developers writing and self-testing code, then uploading the code to the code repository. Bench testing includes raw data injection, underlying data comparison, and issue data injection. Raw data injection involves burning the executable file generated by the developers to the domain controller and performing simulation to observe whether the function can be activated normally with unchanged sensors and underlying layers. If there are functional abnormalities, visualization tools can be used to observe whether the logic is incorrect or the current operating conditions are not met. Underlying data comparison involves inputting signals to sensors and the underlying layer using test cases. Under the same test cases, the output results are compared to the previous version. If there are differences, the adaptation problem is immediately resolved. The same applies to the underlying software. Issue data injection requires software interaction for testing. After modifications are made, developers can perform independent bench simulation. After data issue injection, the problem can be resolved simply by modifying the results. After the above steps are completed without any issues, software interaction is performed, and the testing team conducts real-vehicle testing. These steps clarify responsibilities, personalize the division of labor between development and testing, improve testing efficiency, and effectively reduce the need for developers to accompany testers in meaningless testing.

[0092] Figure 5 This is a schematic flowchart illustrating a debug executable file as an exemplary embodiment of this application.

[0093] Reference Figure 5 As shown, the debugged executable file processes the complex operating condition data of the real vehicle, including:

[0094] S401. Obtain the source code file corresponding to the executable file. The source code file includes at least one piece of road test problem code to be debugged and configuration debugging conditions corresponding to each piece of road test problem code to be debugged.

[0095] The source code file corresponding to the executable file refers to the file formed by the source code developed by the developers based on a specific project. The code to be debugged for road testing refers to the functional code that can perform relevant vehicle control functions; specifically, it refers to code that has already undergone road testing and needs to be tested and debugged to determine whether it can perform the corresponding functions. Configured debugging conditions refer to the conditions that the developers pre-configure during the project development process for debugging the code to be debugged for road testing.

[0096] Specifically, developers can configure different debugging conditions for different functionalities of the code to be debugged in the source code files during development and editing. This ensures that the final source code file contains at least one piece of code to be debugged and the corresponding debugging conditions for each piece of code. For example, after editing a piece of code, developers can use a specific identifier to mark the corresponding debugging conditions in the comments of the code to be debugged. This allows for the identification of the specific identifier and the corresponding debugging conditions when that identifier is recognized later. Since each piece of code to be debugged in the source code file corresponds to a specific debugging condition, this provides technical support for subsequent debugging using different debugging code based on that specific configuration.

[0097] S402. Load the debug option configuration file, wherein the debug option configuration file includes at least one piece of original debug code and original debug options corresponding to each piece of original debug code;

[0098] A debug option configuration file is a file that configures the relationship between raw debug code and raw debug options to facilitate debugging. Raw debug code is code used to find errors (i.e., bugs) in the code to be debugged during road testing, allowing developers to correct errors, improve correction efficiency, and ensure that the software developed by the developers can be used normally by users. Raw debug options are switches that control whether the raw debug code is used to debug the code to be debugged. In other words, the raw debug code is used to detect and locate bugs in the code to be debugged, while the raw debug options are switches that determine whether the raw debug code can be run. That is, only if the requirements of the raw debug options are met can the corresponding raw debug code be run to detect and locate the bugs in the code to be debugged.

[0099] Specifically, a pre-configured debug option configuration file is loaded. This configuration file includes at least one piece of original debug code and corresponding debug options for each piece of original debug code. This allows subsequent activation of the debug options in the configuration file, enabling the corresponding original debug code to debug the code to be debugged. Understandably, because the debug option configuration file establishes the association between at least one piece of original debug code and its corresponding debug options, it is a complete debug file offering good portability and extensibility. Therefore, the configuration file can be adjusted according to actual needs, linking the original debug code and debug options to different projects, thereby enabling the reuse of the configuration file and making the software debugging process more standardized and concise.

[0100] S403. Parse the debug option configuration file and generate a debug option dictionary;

[0101] The debug option configuration file is separated, and then, based on debugging needs, the separated debug options are parsed to extract the corresponding keys and values. The debug option dictionary is a program used to store the parsing results of the debug option configuration file. During debugging, the debug option dictionary is queried to determine whether to use the corresponding original debug code to debug the code to be debugged. Generally, the source code files of a specific project contain debuggable code corresponding to multiple functional modules. When debugging the source code of a specific project, to save debugging time, specific functional modules or related modules can be debugged. Therefore, a debug option dictionary needs to be generated to determine which functional module to debug based on the configuration debugging conditions configured by the developers in the project source code files, thereby saving debugging time and improving debugging efficiency.

[0102] S404. Based on the configuration debugging conditions, query the debugging option dictionary, determine the original debugging option that matches the configuration debugging conditions as the target debugging option, and obtain the target debugging code corresponding to the target debugging option;

[0103] Configuring debug conditions refers to the conditions that developers pre-configure for each piece of code to be debugged in the project's source code files. These configuration conditions allow you to find the corresponding target debug options. A target debug option is the original debug option selected from all the original debug options in the debug option dictionary that matches the configured debug condition. The target debug code is the original debug code in the debug option configuration file that corresponds to that target debug option. In essence, the target debug option acts as a switch to control whether the target debug code debugs the code to be debugged corresponding to the configured debug condition.

[0104] S405, Target Debug Code: Debug the road test problem code to be debugged.

[0105] Figure 6 This is an exemplary flowchart illustrating how to obtain the source code file corresponding to the executable file, as shown in an exemplary embodiment of this application.

[0106] Reference Figure 6 As shown, the source code file corresponding to the executable file is obtained, including:

[0107] S501. Load the program code corresponding to the executable file, wherein the program code includes at least one piece of code for a road test to be debugged;

[0108] Program code refers to the source code written by developers in a specific project according to specific functional requirements. To ensure the accuracy of the program code, it is necessary to debug code whose functionality is uncertain. Therefore, code that needs to be debugged is designated as "debug code." Understandably, since the complete program code contains different functional modules, it is necessary to debug the code corresponding to all functional modules. However, to ensure debugging efficiency, in actual debugging, updated functional modules and their associated code can be designated as debug code, while code corresponding to other unupdated or unrelated functional modules can also be designated as debug code, thus ensuring high-efficiency debugging.

[0109] S502. Display the debugging configuration interface corresponding to each of the road test issues to be debugged in sequence, obtain the configuration debugging conditions corresponding to each of the road test issues to be debugged based on the debugging configuration, and obtain the source code file.

[0110] The debug configuration interface is an interface used to configure the debugging conditions corresponding to the code to be debugged. Specifically, after editing each piece of code to be debugged, developers can click the corresponding configuration button or enter the corresponding configuration command to enter the debug configuration interface. This interface displays commonly used debugging conditions for developers to select, thereby improving the efficiency of configuring debug conditions.

[0111] Load the program code to obtain the code to be debugged; display the debugging configuration interface corresponding to each piece of code to be debugged in sequence, so as to accurately and quickly configure the configuration debugging conditions corresponding to the code to be debugged, thereby obtaining the source code file, and thus determining the configuration debugging conditions for each generation of debugging code, which helps to speed up the debugging process.

[0112] Figure 7 This is a schematic flowchart illustrating the generation of test cases, as shown in an exemplary embodiment of this application.

[0113] Reference Figure 7 As shown, signals are obtained from test cases, and the generation of test cases includes:

[0114] S601. Establish a preset test case generation specification module and combination algorithm;

[0115] Taking the executable file text as an example, there are multiple fields in the executable file text interface that need to be debugged. Each field has a corresponding specification, which is a method specification for generating various use cases according to specified requirements and settings. There are many types of specifications, but in general, they can be divided into two categories: general specifications and special specifications. Specifications can be applied to multiple fields and are generally more universal and simpler, while special specifications are only applicable to a certain field and are generally more complex.

[0116] The combination algorithm is used to combine test cases that meet the actual requirements after the test case generation specification module has created multiple parameter test cases based on test parameters.

[0117] S602, Data test parameter values ​​to create an Extended Markup Language (XML) file;

[0118] The specification generation module and parameter requirements were designed using C# and XML respectively. If the test case parameter setting functionality were centralized within the test case generation program's interface, flexibility and scalability would be insufficient. If it were implemented in the underlying code, it would compromise the protection of the code's internal structure, and not all ordinary testers would be proficient in C#. XML, on the other hand, is known for its simplicity and ease of use; even testers unfamiliar with C# can master it after a short training period, significantly reducing the burden on testers.

[0119] S603. Select the test parameters and the corresponding combination algorithm;

[0120] S604, the specification module creates parameter test cases based on test parameters and synthesizes actual test cases.

[0121] Once the tester establishes at least one test parameter value in the XML file according to the test requirements, the test parameter value will be read into the corresponding test case generation module. Through the C# code in the test case generation specification module, multiple parameter test cases will be created.

[0122] Figure 8 This is a flowchart illustrating a method after synthesizing actual test cases, as shown in an exemplary embodiment of this application.

[0123] Reference Figure 8 As shown, the specification module creates parameter test cases based on test parameters, and after synthesizing the actual test cases, it also includes:

[0124] S701. Output the actual test cases to the user interface; S702. If the actual test cases are incorrect, recreate the XML file. This is a checking program used to provide testers with a way to preview the results of a test case.

[0125] In this embodiment, the executable file test case generation process separates the more complex test case generation specifications from the simpler default test case parameters. This solves the cumbersome burden previously caused by testing work, improves the universality and reliability of the tests, and facilitates use by testers. It should be noted that the "testers" here do not refer to the objects delivered after the executable file has undergone road testing, but rather to the developers.

[0126] Figure 9 This is a block diagram of a bench testing apparatus illustrated in an exemplary embodiment of this application.

[0127] Reference Figure 9 As shown in the figure, an embodiment of this application also discloses a bench testing device, including: an acquisition module 801, a processing module 802, and a judgment module 803.

[0128] The acquisition module 801 is used to acquire the original vehicle message data transmitted from the simulation sensor; the processing module 802 is used to process the original vehicle message data sequentially by the bottom layer and the middle layer in the domain controller, and send a signal through the application layer; the judgment module 803 is used to judge whether the relevant functions of the executable file under test in the domain controller are normally activated based on the signal, thereby determining whether the executable file under test has passed the test.

[0129] In another exemplary embodiment, the processing module 802 includes: a signal acquisition unit configured to acquire signals from test cases; a test case signal processing unit configured to perform relevant processing on the signals from the test cases at the underlying level; and a processing result output unit configured to output the processing result and determine whether the information received by the executable file is consistent with the previous version based on the result.

[0130] In another exemplary embodiment, a complex operating condition data processing module is further included after the judgment module 803. The complex operating condition data processing module includes: a complex operating condition data acquisition unit configured to acquire real vehicle complex operating condition data; a file processing unit configured to process the real vehicle complex operating condition data using a debugged executable file; and a debugged executable file judgment unit configured to judge whether the debugged executable file meets the standard based on the processed signal.

[0131] In another exemplary embodiment, the processing result output unit is further configured to determine whether the information received by the executable file is consistent with the previous version based on the data sending cycle, data size, and data type.

[0132] In another exemplary embodiment, the file processing unit is further configured to: obtain a source code file corresponding to an executable file, the source code file including at least one piece of road test problem code to be debugged and configuration debugging conditions corresponding to each of the road test problem codes to be debugged; load a debug option configuration file, the debug option configuration file including at least one piece of original debugging code and original debugging options corresponding to each of the original debugging codes; parse the debug option configuration file to generate a debug option dictionary; query the debug option dictionary based on the configuration debugging conditions, determine the original debugging option that matches the configuration debugging conditions as the target debug option, obtain the target debugging code corresponding to the target debug option; and debug the road test problem code to be debugged using the target debugging code.

[0133] In another exemplary embodiment, the file processing unit is further configured to: load program code corresponding to an executable file, the program code including at least one piece of road test problem code to be debugged; sequentially display a debugging configuration interface corresponding to each road test problem code to be debugged; obtain the configuration debugging conditions corresponding to each road test problem code to be debugged based on the debugging configuration; and obtain the source code file.

[0134] In another exemplary embodiment, the test case signal processing unit is further configured to: establish a preset test case generation specification module and a combination algorithm; collect test parameter values ​​to establish an Extended Markup Language (XML) file; select test parameters and corresponding combination algorithms; and have the specification module establish parameter test cases based on the test parameters to synthesize actual test cases.

[0135] In another exemplary embodiment, the test case signal processing unit is further configured to: output the actual test case to the user interface; and re-establish the XML file when the actual test case is incorrect.

[0136] It should be noted that the bench testing device and the bench testing method provided in the above embodiments belong to the same concept. The specific operation methods of each module and unit have been described in detail in the method embodiments and will not be repeated here. In practical applications, the bench testing device provided in the above embodiments can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. This is not a limitation here.

[0137] Figure 10This is a schematic diagram of the structure of a computer system for an electronic device, as illustrated in an exemplary embodiment of this application.

[0138] Reference Figure 10 As shown, embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the bench testing methods provided in the above embodiments.

[0139] It should be noted that, Figure 10 The computer system of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0140] like Figure 10 As shown, the computer system includes a Central Processing Unit (CPU) 901, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 902 or programs loaded from storage portion 908 into Random Access Memory (RAM) 903, such as performing the methods described in the above embodiments. The RAM 903 also stores various programs and data required for system operation. The CPU 901, ROM 902, and RAM 903 are interconnected via a bus 904. An Input / Output (I / O) interface 905 is also connected to the bus 904.

[0141] The following components are connected to I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to I / O interface 905 as needed. Removable media 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 910 as needed so that computer programs read from them can be installed into storage section 908 as needed.

[0142] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 909, and / or installed from removable medium 911. When the computer program is executed by central processing unit (CPU) 901, it performs various functions defined in the system of this application.

[0143] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0144] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0145] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0146] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the bench testing method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0147] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0148] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the bench testing methods provided in the various embodiments described above.

[0149] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0150] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0151] It should be understood that the above content is only a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A rack test method, characterized by, The application comprises: acquiring real vehicle original message data transmitted from a simulation sensor, wherein the real vehicle original message data is obtained by playing back original message data recorded by a real vehicle debugging tool; a bottom layer and an intermediate layer in a domain controller successively process the real vehicle original message data, and a signal is sent through an application layer, specifically including: acquiring a signal from a test case; the bottom layer performs relevant processing on the signal from the test case; outputting a processing result, and judging whether information received by an executable file is consistent with the previous version based on data sending period, data size and data type in the processing result; judging whether a related function of the executable file to be tested in the domain controller is normally activated based on the signal sent by the application layer, so as to determine whether the executable file to be tested passes the test.

2. The bench testing method of claim 1, wherein, After judging whether the executable file to be tested passes the test based on the signal sent by the application layer, the application further comprises: acquiring real vehicle complex working condition data; the executable file after debugging processes the real vehicle complex working condition data; judging whether the executable file after debugging meets the standard based on a signal obtained after processing the real vehicle complex working condition data.

3. The bench testing method of claim 2, wherein, The executable file after debugging processes the real vehicle complex working condition data, including: acquiring a source code file corresponding to the executable file, wherein the source code file includes at least one piece of road test problem code to be debugged and a configuration debugging condition corresponding to each piece of the road test problem code to be debugged; loading a debugging option configuration file, wherein the debugging option configuration file includes at least one piece of original debugging code and an original debugging option corresponding to each piece of the original debugging code; parsing the debugging option configuration file to generate a debugging option dictionary; querying the debugging option dictionary based on the configuration debugging condition, determining an original debugging option matched with the configuration debugging condition as a target debugging option, and acquiring a target debugging code corresponding to the target debugging option; the target debugging code debugs the road test problem code to be debugged.

4. The bench testing method of claim 3, wherein, Acquiring a source code file corresponding to the executable file, including: loading program code corresponding to the executable file, wherein the program code includes at least one piece of road test problem code to be debugged; successively displaying a debugging configuration interface corresponding to each piece of the road test problem code to be debugged, acquiring a configuration debugging condition corresponding to each piece of the road test problem code to be debugged based on the debugging configuration, and acquiring the source code file.

5. The bench testing method of claim 1, wherein, Acquiring a signal from a test case, wherein the generation of the test case comprises: establishing a preset case generation specification module and a combination algorithm; establishing an extensible markup language (XML) file based on data test parameter values; selecting test parameters and corresponding combination algorithms; establishing a parameter test case based on test parameters, and synthesizing an actual test case based on the specification module.

6. The bench testing method of claim 5, wherein, After establishing a parameter test case based on test parameters, and synthesizing an actual test case based on the specification module, the application further comprises: outputting the actual test case to a user interface; when the actual test case is incorrect, reestablishing an XML file.

7. A rack test device, comprising: The application comprises: An acquisition module is configured to acquire real vehicle original message data transmitted from a simulation sensor, the real vehicle original message data being original message data playback obtained through data recording by a real vehicle debugging tool; A processing module is configured to sequentially process the real vehicle original message data by a bottom layer and an intermediate layer in a domain controller, and send a signal through an application layer, specifically including: acquiring a signal from a test case; performing relevant processing on the signal from the test case by the bottom layer; outputting a processing result, and judging whether information received by an executable file is consistent with a previous version based on a data sending period, a data amount size and a data type in the processing result; A judgment module is configured to judge whether a to-be-tested executable file in the domain controller activates a related function normally based on the signal sent by the application layer, so as to determine whether the to-be-tested executable file passes the test.

8. An electronic device, comprising: comprise: one or more processors; a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the bench test method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, a computer readable medium having stored thereon computer readable instructions, which, when executed by a processor of a computer, cause the computer to perform the bench test method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, the computer program, when executed by a processor, implements the bench test method according to any one of claims 1 to 6.

Images