Combination instrument testing method, equipment and medium
By generating a set of test function modules and automated test scripts, the issues of flexibility and efficiency in combined instrument testing are resolved, achieving efficient and accurate test coverage and rapid adaptation to combined instrument function updates and platform changes.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 潍柴新能源商用车有限公司
- Filing Date
- 2025-12-26
- Publication Date
- 2026-05-08
AI Technical Summary
Existing instrument testing methods suffer from drawbacks such as the ease with which test items can be missed during manual operation, long processing times, and insufficient flexibility. Automated testing systems, on the other hand, are rigid, require significant upfront investment, and have long debugging cycles, making them unable to quickly respond to diverse and rapidly iterating market demands.
By generating multiple sets of test function modules, and parsing and classifying them based on the function module division rules, automated test scripts are generated. The scripts are loaded and run sequentially, and the actual display status is observed and recorded in comparison with the expected status to generate test judgment results.
It achieves complete and consistent test coverage, reduces redundant development work, shortens test preparation cycle, combines automation efficiency with artificial intelligence, and adapts to instrument function updates and platform adaptation.
Smart Images
Figure CN121996542A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle testing technology, and in particular to a method, equipment and medium for testing combined instruments. Background Technology
[0002] In the field of automotive electronics technology, the instrument cluster, as a core component of vehicle information interaction, is of paramount importance in terms of its functional correctness and reliability. With the diversification of commercial vehicle platforms and the accelerated pace of functional iteration, the types and number of signals that the instrument cluster needs to support have increased dramatically. Therefore, comprehensive and efficient testing of the instrument cluster has become a critical step in the product development process.
[0003] Currently, there are two main technical approaches to testing instrument cluster functions in the industry. One approach relies on testers manually operating specialized software tools to configure and send hundreds of bus signals one by one to simulate vehicle conditions, followed by manual observation of the instrument displays for judgment. While this method allows for flexible adjustment of the signal sequence according to different testing needs, manual operation is prone to missing test items, is time-consuming, and the accuracy and consistency of the test results largely depend on the tester's focus and experience, making it difficult to adapt to large-scale, high-frequency testing and verification requirements.
[0004] Another technical approach aims to increase automation by introducing dedicated automated testing equipment and writing fixed test scripts. This method can automatically execute test cases and generate reports, significantly reducing testing time and improving process standardization. However, its drawback lies in the system's rigidity and the deep coupling of test scripts with specific hardware devices and instrument software versions. When dealing with combined instruments on different platforms with varying functional definitions, it is necessary to redevelop or significantly adjust test scripts and equipment configurations for each variant. This results in high upfront investment, long debugging cycles, and an inability to quickly respond to market demands for product diversification and rapid functional iteration, demonstrating insufficient flexibility. Summary of the Invention
[0005] This application provides a combined instrument testing method, equipment, and medium to solve the above-mentioned technical problems.
[0006] On one hand, embodiments of this application provide a method for testing a combination instrument, including: The function definition of the instrument under test is obtained, and based on the preset function module division rules, the function definition is parsed and classified to generate multiple test function module sets; the function definition includes various types of display signals and their relationships. For each set of test function modules, a corresponding automated test script is generated based on the display type and correlation of the displayed signals in the set of test function modules. The automated test scripts corresponding to the selected target function modules are loaded and run sequentially to send corresponding display signals to the instrument under test according to the order, value and timing logic defined in the automated test scripts. Observe and record the actual display status of the instrument under test after executing the corresponding automated test script, and compare and analyze the actual display status with the expected display status predefined in the test case to generate test judgment results for the target functional module.
[0007] In one implementation of this application, based on preset functional module division rules, the functional definitions are parsed and categorized to generate multiple test functional module sets, specifically including: Extract the control system identifiers of all signal sources from the functional definition, and classify the display signals to the corresponding control systems based on the control system identifiers; the control systems include chassis control system, power control system and body control system; Extract the display type identifier of all display signals from the function definition, and classify the display signals into the corresponding display types based on the display type identifier; the display types include visual indication, numerical display, audible alarm, text prompt, and code error; Based on predefined module partitioning logic, display signals originating from the same control system identifier and belonging to the same display type identifier are grouped together to generate the first type of test function module set. In the case where multiple display signals identified by different control systems collaboratively control the same display content in the functional definition, the corresponding signal combinations are aggregated to generate a second type of test function module set; The first type of test function module set and the second type of test function module set are integrated to form a final set of multiple independent test function modules.
[0008] In one implementation of this application, for each set of test function modules, a corresponding automated test script is generated based on the display type and correlation of the display signals in the set of test function modules, specifically including: The test function module set is analyzed to obtain the signal identifier, allowed value range, and triggering conditions of each display signal; Based on the triggering conditions and the display logic of the instrument under test, a test sequence logic chain for the display signal is constructed, and a test case is configured for each test node in the test sequence logic chain. The test sequence logic chain defines the signal state change path required to trigger different display states, and the test case includes the test value applied to the corresponding display signal and the duration. Based on the test sequence logic chain and the nested test cases, the code is converted according to the preset script syntax rules to generate an automated test script that can be directly loaded and run.
[0009] In one implementation of this application, the automated test scripts corresponding to the selected target functional modules are loaded and run sequentially to send corresponding display signals to the instrument under test according to the order, value retrieval, and timing logic defined in the automated test scripts. Specifically, this includes: The communication interface is initialized by the test host, and the target automated test script corresponding to the target functional module is loaded into the script interpreter in the memory of the test host. The script interpreter parses the target automated test script line by line, converting the control instructions in the target automated test script into low-level communication messages; the low-level communication messages include specific identifiers, data values, and sending timestamps. The test host sends the underlying communication messages to the vehicle communication network corresponding to the instrument cluster under test in real time through the communication interface and according to the timing of the sending timestamps. Monitor the execution progress of the target automated test script, and trigger a script switching event upon receiving an execution end instruction or reaching a preset execution duration; In response to the script switching event, the test host loads and executes the next automated test script of the target automated test script until all automated test scripts have been executed.
[0010] In one implementation of this application, observing and recording the actual display status of the instrument under test after executing the corresponding automated test script specifically includes: Based on the display screen, indicator light area, and buzzer of the instrument under test, the real-time display change information of the instrument under test is obtained, and the status information of the key checkpoints predefined in the test case is determined; the key checkpoints include the on / off state of specific indicator lights, the accuracy of numerical display, the appearance and content of text information, and the sound mode of the buzzer. The display change information and the status information of the key checkpoints are converted into records in text or code form to generate the actual display status; the actual display status has a comparable field structure to the expected display status predefined in the test case.
[0011] In one implementation of this application, the actual display state is compared and analyzed with the predefined expected display state in the test case to generate a test judgment result for the target functional module, specifically including: Establish a mapping relationship between the fields of the actual display state and the expected display state; Each observation in the actual display state is compared with the corresponding expected result in the expected display state field by field to check whether the actual display state and the expected display state are completely matched in terms of state, value or content; For each comparison field, a binary judgment result is generated based on the matching result. If there is a match, it is marked as passed; if there is no match, it is marked as failed. The difference between the actual value and the expected value is recorded. The binary judgment results of all comparison fields are combined and a predefined pass rule is applied. If all key fields are marked as pass, an overall test pass conclusion is generated. If any key field is marked as failed, an overall test failure conclusion is generated, and the differences of all failed fields are appended to the conclusion to summarize and generate the test judgment result.
[0012] In one implementation of this application, a test sequence logic chain for the display signal is constructed based on the triggering conditions and the display logic of the instrument under test, specifically including: Analyze the triggering conditions and extract the dependencies and mutual exclusions between the display signals to construct initial signal relationship graph data; The display logic of the instrument under test is traversed to determine each target display state that needs to be tested, and each target display state is mapped to a specific signal condition that needs to be met, generating a display state and signal condition mapping table data; Using the initial signal relationship spectrum data as constraints and each set of specific signal conditions in the display state and signal condition mapping table data as test target nodes, the optimal path sequence for traversing all test target nodes from the initial state is planned. Each state switching step in the optimal path sequence is converted into a standardized instruction unit consisting of a signal identifier, a target value, and a switching condition, and then combined in sequence to form a test sequence logic chain.
[0013] In one implementation of this application, the execution progress of the target automated test script is monitored, and a script switching event is triggered when an execution end instruction is received or a preset execution duration is reached. Specifically, this includes: An execution pointer is set within the script interpreter to track the current line of code being parsed and executed in real time, and to generate execution progress. The execution progress is continuously monitored, and the execution progress is compared with the preset key nodes of the target automated test script; When the execution progress indicator has been parsed and executed to the preset end marker in the target automated test script, an end event is generated as a trigger signal for the script switching event; A timer is started to record the execution time of the target automated test script. When the execution time exceeds the maximum allowed execution time threshold preset for the script, a timeout event is generated as a trigger signal for the script switching event. In response to the received end event or timeout event, the current script execution flow is paused, the execution context of the current script is cleaned up, and a script switching event flag is set at the corresponding position of the target automated test script.
[0014] On the other hand, embodiments of this application also provide a combined instrument testing device, the device comprising: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform a combined instrument testing method as described above.
[0015] On the other hand, embodiments of this application also provide a non-volatile computer storage medium storing computer-executable instructions, which, when executed, implement a combined instrument testing method as described above.
[0016] This application provides a combined instrument testing method, equipment, and medium, which has at least the following beneficial effects: By generating multiple sets of test function modules, the massive testing task is decomposed into logically cohesive independent units. Each module set corresponds to a clear test focus, ensuring that every display signal in the functional definition can be accurately categorized into a specific test category. This eliminates test blind spots at the system level and guarantees the completeness of test coverage. By automating the signal sending process with scripts, testers only need to focus on observing and judging the final display results. This semi-automatic mode combines the efficiency of automation with the intelligence of human intervention. The scripts strictly send signals according to a predefined order, value retrieval, and timing logic, avoiding the uncertainty and random errors of manual operation, ensuring a high degree of consistency in the execution path and stimulus conditions for each test. By using function modules as the basic units of testing rather than the entire instrumentation system, when the combined instrumentation's functionality is updated or needs to be adapted to a new platform, only the test scripts corresponding to the affected specific function modules need to be adjusted or replaced, without reconstructing the entire testing system. This makes test cases and scripts reusable assets, requiring only minor adaptations, reducing redundant development work, and shortening the test preparation cycle. Attached Figure Description
[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a combined instrument testing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the internal structure of a combined instrument testing device provided in an embodiment of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0019] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.
[0020] Figure 1 This is a flowchart illustrating a combined instrument testing method provided in an embodiment of this application.
[0021] The analysis method involved in the embodiments of this application can be implemented by a terminal device or a server, and this application does not impose any special limitations on it. For ease of understanding and description, the following embodiments are all described in detail using a server as an example.
[0022] It should be noted that the server can be a single device or a system composed of multiple devices, i.e., a distributed server. This application does not make any specific limitations on this.
[0023] like Figure 1 As shown in the embodiment of this application, a combined instrument testing method includes: Step 101: Obtain the function definition of the instrument under test, and based on the preset function module division rules, parse and classify the function definition to generate multiple test function module sets.
[0024] It should be noted that the functional definitions in the embodiments of this application include various types of display signals and their associated relationships.
[0025] In this embodiment, it is impractical to directly perform overall testing on a vehicle-level functional definition document containing hundreds of display signals and their complex relationships. This application intelligently decomposes this massive whole into multiple smaller, more manageable, and testable independent units through a set of preset, logically clear rules.
[0026] Specifically, the classification process begins with a deep analysis of the functional definition data. First, it's necessary to extract the control system identifiers for all signal sources from the functional definitions. For example, the control system identifier is a unique code or name identifying the electronic control unit (ECU) that generates each display signal. In the context of pure electric commercial vehicles, typical control systems include chassis control systems (such as ABS / EBS / ESC and Electronic Parking Brake (EPB) for braking and stability), powertrain control systems (such as Vehicle Control Unit (VCU) and Battery Management System (BMS)), and body control systems (such as Body Controller (BCM) and Tire Pressure Monitoring System (TPMS)). After extracting this identifier, the system can categorize display signals to the corresponding control system based on the control system identifier. This categorization step organizes the system at the physical level of the vehicle's electrical architecture, grouping all signals from the same ECU together for easier understanding and testing from the system's source. For example, all signals labeled "BMS," regardless of the display they control, will be initially categorized under the "Powertrain Control System" group.
[0027] It's important to note that simply categorizing signals by their source is insufficient, as the same ECU may output signals controlling different types of displays. Therefore, it's also necessary to extract the display type identifier for all display signals from the functional definitions. The display type identifier describes the sensory output that the signal ultimately drives in the instrument cluster. Common display types include visual indicators (such as various fault indicator lights and status icons), numerical displays (such as vehicle speed, engine speed, and battery percentage), audible warnings (such as buzzer sounds of different frequencies and rhythms), text prompts (such as floating alarm messages and menu text), and error codes (such as the display of Diagnostic Trouble Codes (DTCs)). Based on this identifier, signals can be categorized into their corresponding display types. For example, a signal from the BMS might be categorized as a "visual indicator" if it controls the "battery overheat" icon, and as a "numerical display" if it conveys a specific value for "battery pack temperature."
[0028] After completing the two basic classifications mentioned above, the core module generation stage proceeds according to the predefined module division logic, primarily generating two types of functional module sets. The first type follows the principle of "single source, single type," meaning that display signals originating from the same control system identifier and belonging to the same display type identifier are grouped together to generate the first type of test functional module set. For example, all signals from the "VCU" (Power Control Unit) and of the "numerical display" type (such as vehicle speed, instantaneous power consumption, and total mileage) are grouped together to form a "VCU numerical display" functional module. The signals within this module are logically highly correlated (all originating from the same controller and all presented in numerical form), allowing testers to write a script to centrally test whether the display of all these values is normal; the logic is clear and unlikely to miss any.
[0029] However, many advanced display functions in vehicles are not controlled by a single signal. Therefore, the partitioning logic must cover more complex situations. Specifically, when parsing function definitions, special handling is required if it is identified that multiple display signals identified by different control systems are collaboratively controlling the same display content. For example, a "Hill Descent Control (HDC) Activated" indicator icon may require the simultaneous fulfillment of two conditions: a "HDC Available" signal from the ABS (Chassis Control System) being true, and a "Current Gear" signal from the TCU (Transmission Control Unit) being in a low gear range. In this case, these two signals from different control systems jointly determine the display of the same visual indication. According to the rules, the corresponding signal combinations should be grouped to generate a second type of test function module set. This "HDC Activation Indicator" module is a typical example of a second type of set, specifically designed to test this type of cross-system, combinational logic-based display function.
[0030] Finally, all the first-type test function module sets (such as the "BMS visual indication module" and "BCM text prompt module") and the second-type test function module sets (such as the "AEBS cross-system alarm module" and "combined driving mode display module") automatically generated by the rules are integrated. The integration process involves gathering all independent modules into a list or database, thus forming multiple independent test function module sets. Independence means that each function module set encapsulates a clearly defined and internally consistent test subtask, with low coupling between modules. This structure allows test engineers to flexibly select all or some modules for testing, and greatly facilitates the writing, maintenance, and reuse of subsequent test scripts, laying a solid foundation for achieving efficient and accurate semi-automated testing.
[0031] Step 102: For each set of test function modules, generate the corresponding automated test script based on the display type and relationship of the displayed signals in the set of test function modules.
[0032] In this embodiment, a specific implementation method for generating corresponding automated test scripts is provided for each set of pre-defined test function modules. It is understood that the test script is the "intelligent script" driving the entire semi-automated testing process, and its quality directly determines the accuracy and efficiency of the test. The script generation of this invention is not a simple listing of signals, but a creative process based on deep logical analysis and structured design.
[0033] Specifically, the automated test script generation process begins with a detailed analysis of the input data. First, the set of test function modules is analyzed. The purpose of this analysis is to accurately extract the signal identifier, allowed value range, and trigger conditions for each display signal from the structured data encapsulated within this set. For example, the signal identifier is the signal's unique "identity card" in the vehicle communication network (such as the CAN bus), potentially containing a network ID, signal name, etc., used for addressing and assigning values in subsequent steps. The allowed value range defines the physically valid interval of the signal; for example, vehicle speed signal 0-150 km / h, gear signal enumeration values P / R / N / D. This forms the basis for generating meaningful test values that do not exceed specifications. The trigger condition is the logical prerequisite that the signal must meet for it to participate in or influence the instrument cluster display. It is often expressed as a Boolean expression and may depend on the signal's own value or the state of other signals. For example, the trigger condition for a "left turn indicator" signal might be "left turn signal switch signal is true and hazard warning light switch signal is false."
[0034] After obtaining these basic parameters, the core, and creatively significant, step is to construct the logic, which involves building a test sequence logic chain for the display signals based on the triggering conditions and the display logic of the instrument cluster under test. Display logic refers to the fixed behavioral rules governing how the instrument cluster's internal software processes input signals and updates the display. For example, some warnings are only activated when the vehicle speed exceeds a certain value, and some display content has priority-exclusive relationships. The goal of constructing the test sequence logic chain is to design a "test path" that can systematically and efficiently verify all key display scenarios of this functional module. This path defines the signal state change paths required to trigger different display states.
[0035] Specifically, the first step is to analyze the triggering conditions and extract the dependencies and mutual exclusions between the displayed signals. By analyzing the triggering conditions of all signals, an initial signal relationship graph can be constructed, which serves as the constraint for subsequent path planning. For example, the graph might show that signal A is a prerequisite for signal B to take effect (dependency), while signals C and D cannot be active simultaneously (mutual exclusion).
[0036] Secondly, it is necessary to traverse the display logic of the instrument cluster under test to determine the target display states to be tested. These target states are the specific behaviors of the instrument cluster that the test cases hope to verify, such as "engine malfunction light is constantly red", "the main screen displays the text alarm 'Please check the charging system'", and "the remaining range value is displayed in red". For each target display state, it is necessary to reverse-engineer and map it to the specific signal conditions that need to be met, that is, in order to generate this display, the relevant signals in the network must be at a specific set of values. All mapping relationships are organized into a display state and signal condition mapping table.
[0037] Next, using the initial signal relationship graph data as constraints and each specific signal condition in the display state and signal condition mapping table as the test target nodes, intelligent test path planning is performed. The goal of the planning is to devise the optimal path sequence that traverses all test target nodes from the initial state (e.g., all signals are at default values or in a dormant state). "Optimal" can refer to the shortest time, the fewest signal switching times, or the sequence that best reflects the actual driving scenario. This is analogous to finding the best route to all key points in a constrained state space.
[0038] Next, this abstract optimal path sequence is transformed into executable instructions. Each state-switching step in the optimal path sequence needs to be converted into a standardized instruction unit consisting of a signal identifier, a target value, and a switching condition. For example, an instruction unit might be: "Set the signal identified as 'VehicleSpeed' to a target value of '80', with the switching condition that the current gear signal is already in 'D' gear." Finally, these standardized instruction units are combined sequentially to form a well-structured, machine-readable test sequence logic chain.
[0039] After the logic chain is constructed, test cases need to be configured for each test node in the test sequence logic chain. Each test case mainly includes two parts: the test value applied to the corresponding display signal and the duration for which this value needs to be maintained. The test value applied to the corresponding display signal is a typical value, boundary value, or fault value selected within the allowed value range. The duration for which this value needs to be maintained is to ensure that the instrument has sufficient time to complete the display refresh and remain stable for observation. For example, when testing a speedometer, the test case might include setting the vehicle speed signal to values such as 0, 60, and 120, with each value lasting for several seconds.
[0040] Finally, the aforementioned test sequence logic chain and nested test cases are taken as input and encoded according to preset script syntax rules. These preset script syntax rules are determined by the test execution environment used; for example, if CANoe software is used, the rules are based on the CAPL language syntax. The encoding conversion process translates the logical test steps and parameters into source code that the test environment can directly recognize and execute, ultimately generating automated test scripts that can be directly loaded and run.
[0041] Step 103: Load and run the automated test scripts corresponding to the selected target function modules in sequence, so as to send the corresponding display signals to the instrument under test according to the order, value retrieval and timing logic defined in the automated test scripts.
[0042] In this embodiment, the starting point of the driving test process is the establishment of the test environment and the loading of scripts. First, the communication interface needs to be initialized through the test host. The test host is usually a general-purpose computer or industrial control computer with professional test software (such as Vector CANoe) installed. Initializing the communication interface is a crucial preparatory step, which includes identifying and configuring the physical hardware channel connected to the instrument under test (DUT), such as a specific CAN card channel, Ethernet port, or LIN interface; setting communication parameters consistent with the vehicle network, such as CAN baud rate and protocol type; and loading the corresponding database file (DBC file) so that the system can correctly understand the signal identification and encoding rules. This ensures that there is a standardized and predictable data exchange channel between the test host and the DUT.
[0043] Once the communication link is ready, the test host begins loading and executing the test logic. Specifically, it loads the target automated test script corresponding to the target functional module into the script interpreter in the test host's memory. The target automated test script is a program file generated for a specific functional module and contains complete stimulus logic. The script interpreter is a virtual machine or execution engine in the test software that can parse and run a specific scripting language (such as CAPL). Loading the script file into the interpreter in memory means that the script is read from external storage media and prepared to enter an executable runtime state.
[0044] Subsequently, the script interpreter begins its work, parsing the target automated test script line by line. This parsing process is the core of semantic translation. The interpreter reads each high-level instruction in the script (such as setting a signal value, waiting for a specific time or condition), and, based on a pre-loaded communication database, converts the control instructions in the target automated test script into low-level communication messages. This conversion is precise: the signal names referenced in the instructions are mapped to specific identifiers on the network (such as CAN IDs); the target values specified in the instructions are encoded into binary data values; and the timing requirements implied in the instructions (such as delays and periods) are calculated to produce precise transmission timestamps, which control the absolute or relative moment when the message is sent.
[0045] Next, the test host sends the underlying communication messages to the vehicle communication network corresponding to the instrument cluster under test (IDT) in real time via the communication interface, according to the sending timestamp sequence. "According to the sending timestamp sequence" is the essence of ensuring the accuracy of the test scenario reproduction; it simulates the precise interaction of signals from various ECUs in a real vehicle along the timeline. These messages are injected into the vehicle bus (such as the CAN bus), and the IDT, acting as a bus node, receives and processes these signals, thereby generating the corresponding physical display output.
[0046] To ensure the smooth and robust operation of the automated process, the system must continuously monitor the execution status of each script and trigger process switching at appropriate times. Monitoring the execution progress of the target automated test script is achieved through a sophisticated internal mechanism. Specifically, an execution pointer is set within the script interpreter. This execution pointer is a software variable that tracks the current line of code being parsed and executed in real time. Its movement accurately reflects the script's interpretation progress, thereby generating execution progress information. The system continuously monitors the execution progress and compares it with preset key nodes in the target automated test script. These key nodes may include important function call points, the start and end positions of loop structures, etc., to more precisely determine whether the script is running according to the expected logic.
[0047] The ultimate goal of monitoring is to determine when the current script should end. By design, there are two ways to determine script termination (i.e., triggering a switchover). The first is normal termination: when the execution progress indicator has been parsed and executed to the preset end marker in the target automated test script (e.g., the `return;` statement at the end of the script or a code block specifically marked as ending), the system internally generates a termination event as the trigger signal for the script switchover event. The second is exception protection: the system starts a timer to record the execution time of the target automated test script. If the script "gets stuck" due to script logic errors, unmet waiting conditions, or unresponsive instruments, and the execution time exceeds the preset maximum allowed execution time threshold, the system will generate a timeout event as the trigger signal for the script switchover event. This timeout mechanism is a key safety measure to prevent the testing process from getting stuck in infinite waiting and to ensure the continuity of automation.
[0048] Once the monitoring system detects any of the aforementioned termination or timeout events, the test host responds to the received event. The response is systematic: First, it pauses the current script execution flow, interrupting any ongoing message sending or waiting; second, it cleans up the execution context of the current script, such as releasing variables defined in the script and resetting simulated signals to their default safe state to avoid residual effects on the execution of the next script; finally, in the flow control logic, it sets a script switching event flag at the corresponding location in the target automated test script to formally record the end of the current script cycle.
[0049] After cleaning up and setting flags for the current script, the automated process enters the next cycle. The test host loads and executes the next automated test script for the target automated test script. This means that the test host will retrieve the script file corresponding to the next functional module from the queue of scripts to be executed and repeat the complete process of "loading to interpreter - parsing and conversion - sending in sequence - continuous monitoring". This cycle continues until all automated test scripts have been executed.
[0050] Step 104: Observe and record the actual display status of the instrument under test after executing the corresponding automated test script, and compare and analyze the actual display status with the expected display status predefined in the test case to generate test judgment results for the target functional module.
[0051] In this embodiment, firstly, it is necessary to acquire real-time display change information of the instrument under test (DUT) based on its display screen, indicator light area, and buzzer. The acquisition method primarily relies on the visual and auditory observation of the test personnel, or is supplemented by image acquisition and sound recording equipment. Display change information refers to the sum of dynamic changes occurring on all output media of the instrument during script execution, such as a screen area changing from dark to bright, a set of numbers changing, a piece of text popping up and disappearing, a change in the color of an indicator light, or a specific sound pattern emitted by the buzzer.
[0052] However, not all changes require equal documentation and evaluation. For efficient and targeted assessment, testing is conducted around predefined evaluation criteria. Therefore, it is necessary to determine the status information of key checkpoints (CChecks) defined in the test cases. CChecks are specific instrument output elements that require focused verification, explicitly specified when writing test scripts and test cases. These CChecks include the on / off status of specific indicator lights (e.g., the engine malfunction indicator should be red), the accuracy of numerical displays (e.g., the speedometer needle should indicate 80 km / h with a tolerance of ±2 km / h), the appearance and content of text messages (e.g., the yellow text "Please check ABS system" should be displayed in the information center), and the beeping pattern of the buzzer (e.g., three short "beep beep" alarm sounds should be emitted). For each such checkpoint, a clear judgment needs to be made to determine its specific status information. For example, for indicator lights, the status information is "on (red)" or "off"; for text messages, the status information is "appears, content is 'Please check ABS system,' color is yellow."
[0053] To facilitate subsequent automated or systematic comparisons, these observations must be standardized. Therefore, it is necessary to convert display change information and key checkpoint status information into text or code records. This is a crucial transformation step from unstructured sensory information (seen images, heard sounds) to structured data. For example, all observations can be organized into a JSON object, an XML fragment, or a row of records in a database table. Through this transformation process, the actual display state is ultimately generated. A critical requirement is that the actual display state has a comparable field structure to the predefined expected display state in the test cases.
[0054] For example, if the expected state is defined as {"LeftTurnLight":"ON","SpeedDisplay":"80","WarningText":"Low Tire Pressure"}, then the actual display state must also be recorded as a structure with the exact same key name, such as {"LeftTurnLight":"OFF", "SpeedDisplay":"80","WarningText":"Low Tire Pressure"}, thus ensuring that the two can be accurately compared on the same dimension.
[0055] After obtaining the structured actual and expected states, establish a mapping relationship between the fields of the actual display state and the expected display state. This is usually done automatically through field names (i.e., key names), ensuring that the "actual speed" field is compared with the "expected speed" field.
[0056] Next, a field-by-field comparison is performed, which systematically compares each observation in the actual display state with the corresponding expected result in the expected display state. The core is to check whether the actual display state and the expected display state completely match in terms of state, value, or content. For example, it compares whether the value "ON" of the "LeftTurnLight" field is consistent with the expected value "ON"; it compares whether the value "80" of the "SpeedDisplay" field is within the expected value "80" and its allowable tolerance range.
[0057] For each field that completes the comparison, a binary judgment result is generated based on the matching result. If there is a perfect match, the field is marked as passed; if there is any mismatch (such as reversed status, value exceeding tolerance, or content inconsistency), it is marked as failed. For fields marked as failed, the difference between the actual value and the expected value must be recorded, for example, "expected 'ON', actual 'OFF'" or "expected '80', actual '75'". This provides direct clues for subsequent problem localization.
[0058] After all fields have been compared, a comprehensive decision is required. This involves combining the binary decision results of all compared fields and applying predefined pass / fail rules. Pass / fail rules are global decision criteria defined in the test plan. For example, a rule might be "all fields must pass," or more commonly, "all fields marked 'critical' must pass, and non-critical fields are allowed a maximum of a specified number of failures."
[0059] After applying this rule, if all key fields are marked as passed, an overall test pass conclusion is generated, indicating that the target functional module has passed the test. Conversely, if any key field is marked as failed, an overall test failure conclusion is generated. The test failure conclusion includes details of the differences in all failed fields, forming a detailed defect list. Finally, this overall conclusion and detailed difference information are summarized to generate a final, clear, and unambiguous test judgment result. This result is not only the end point of the test but also the starting point for guiding developers to locate and fix problems, completing a full logical loop from test incentives to result judgment.
[0060] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a combined instrument testing device, the structure of which is as follows: Figure 2 As shown.
[0061] Figure 2 This is a schematic diagram of the internal structure of a combined instrument testing device provided in an embodiment of this application. Figure 2 As shown, the device includes: At least one processor; And, a memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by at least one processor, and the instructions, when executed by at least one processor, enable at least one processor to: The system acquires the functional definitions of the instrument under test and, based on preset functional module division rules, parses and categorizes these definitions to generate multiple sets of test functional modules. The functional definitions include various types of display signals and their relationships. For each set of test function modules, generate corresponding automated test scripts based on the display type and relationships of the displayed signals in the set of test function modules; The automated test scripts corresponding to the selected target function modules are loaded and run sequentially to send corresponding display signals to the instrument under test in accordance with the order, value retrieval and timing logic defined in the automated test scripts. Observe and record the actual display status of the instrument under test after executing the corresponding automated test script, and compare and analyze the actual display status with the expected display status predefined in the test case to generate test judgment results for the target functional module.
[0062] This application also provides a non-volatile computer storage medium storing computer-executable instructions, which, when executed, can: The system acquires the functional definitions of the instrument under test and, based on preset functional module division rules, parses and categorizes these definitions to generate multiple sets of test functional modules. The functional definitions include various types of display signals and their relationships. For each set of test function modules, generate corresponding automated test scripts based on the display type and relationships of the displayed signals in the set of test function modules; The automated test scripts corresponding to the selected target function modules are loaded and run sequentially to send corresponding display signals to the instrument under test in accordance with the order, value retrieval and timing logic defined in the automated test scripts. Observe and record the actual display status of the instrument under test after executing the corresponding automated test script, and compare and analyze the actual display status with the expected display status predefined in the test case to generate test judgment results for the target functional module.
[0063] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.
[0064] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.
[0065] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0066] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0067] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0068] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0069] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.
[0070] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.
[0071] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.
[0072] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0073] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A method for testing a combination instrument, characterized in that, The method includes: The function definition of the instrument under test is obtained, and based on the preset function module division rules, the function definition is parsed and classified to generate multiple test function module sets; the function definition includes various types of display signals and their relationships. For each set of test function modules, a corresponding automated test script is generated based on the display type and correlation of the displayed signals in the set of test function modules. The automated test scripts corresponding to the selected target function modules are loaded and run sequentially to send corresponding display signals to the instrument under test according to the order, value and timing logic defined in the automated test scripts. Observe and record the actual display status of the instrument under test after executing the corresponding automated test script, and compare and analyze the actual display status with the expected display status predefined in the test case to generate test judgment results for the target functional module.
2. The method for testing a combined instrument according to claim 1, characterized in that, Based on preset functional module division rules, the functional definitions are parsed and categorized to generate multiple test functional module sets, specifically including: Extract the control system identifiers of all signal sources from the functional definition, and classify the display signals to the corresponding control systems based on the control system identifiers; the control systems include chassis control system, power control system and body control system; Extract the display type identifier of all display signals from the function definition, and classify the display signals into the corresponding display types based on the display type identifier; the display types include visual indication, numerical display, audible alarm, text prompt, and code error; Based on predefined module partitioning logic, display signals originating from the same control system identifier and belonging to the same display type identifier are grouped together to generate the first type of test function module set. In the case where multiple display signals identified by different control systems collaboratively control the same display content in the functional definition, the corresponding signal combinations are aggregated to generate a second type of test function module set; The first type of test function module set and the second type of test function module set are integrated to form a final set of multiple independent test function modules.
3. The method for testing a combined instrument according to claim 1, characterized in that, For each set of test function modules, based on the display type and correlation of the displayed signals in the set of test function modules, a corresponding automated test script is generated, specifically including: The test function module set is analyzed to obtain the signal identifier, allowed value range, and triggering conditions of each display signal; Based on the triggering conditions and the display logic of the instrument under test, a test sequence logic chain for the display signal is constructed, and a test case is configured for each test node in the test sequence logic chain. The test sequence logic chain defines the signal state change path required to trigger different display states, and the test case includes the test value applied to the corresponding display signal and the duration. Based on the test sequence logic chain and the nested test cases, the code is converted according to the preset script syntax rules to generate an automated test script that can be directly loaded and run.
4. The method for testing a combined instrument according to claim 1, characterized in that, The automated test scripts corresponding to the selected target functional modules are loaded and run sequentially to send corresponding display signals to the instrument under test according to the order, value retrieval, and timing logic defined in the automated test scripts. Specifically, this includes: The communication interface is initialized by the test host, and the target automated test script corresponding to the target functional module is loaded into the script interpreter in the memory of the test host. The script interpreter parses the target automated test script line by line, converting the control instructions in the target automated test script into low-level communication messages; the low-level communication messages include specific identifiers, data values, and sending timestamps. The test host sends the underlying communication messages to the vehicle communication network corresponding to the instrument cluster under test in real time through the communication interface and according to the timing of the sending timestamps. Monitor the execution progress of the target automated test script, and trigger a script switching event upon receiving an execution end instruction or reaching a preset execution duration; In response to the script switching event, the test host loads and executes the next automated test script of the target automated test script until all automated test scripts have been executed.
5. The method for testing a combined instrument according to claim 1, characterized in that, Observe and record the actual display status of the instrument under test after executing the corresponding automated test script, specifically including: Based on the display screen, indicator light area, and buzzer of the instrument under test, the real-time display change information of the instrument under test is obtained, and the status information of the key checkpoints predefined in the test case is determined; the key checkpoints include the on / off state of specific indicator lights, the accuracy of numerical display, the appearance and content of text information, and the sound mode of the buzzer. The display change information and the status information of the key checkpoints are converted into records in text or code form to generate the actual display status; the actual display status has a comparable field structure to the expected display status predefined in the test case.
6. The method for testing a combined instrument according to claim 5, characterized in that, The actual display state is compared and analyzed with the predefined expected display state in the test case to generate a test judgment result for the target functional module, specifically including: Establish a mapping relationship between the fields of the actual display state and the expected display state; Each observation in the actual display state is compared with the corresponding expected result in the expected display state field by field to check whether the actual display state and the expected display state are completely matched in terms of state, value or content; For each comparison field, a binary judgment result is generated based on the matching result. If there is a match, it is marked as passed; if there is no match, it is marked as failed. The difference between the actual value and the expected value is recorded. The binary judgment results of all comparison fields are combined and a predefined pass rule is applied. If all key fields are marked as pass, an overall test pass conclusion is generated. If any key field is marked as failed, an overall test failure conclusion is generated, and the differences of all failed fields are appended to the conclusion to summarize and generate the test judgment result.
7. The method for testing a combined instrument according to claim 3, characterized in that, Based on the triggering conditions and the display logic of the instrument under test, a test sequence logic chain for the display signal is constructed, specifically including: Analyze the triggering conditions and extract the dependencies and mutual exclusions between the display signals to construct initial signal relationship graph data; The display logic of the instrument under test is traversed to determine each target display state that needs to be tested, and each target display state is mapped to a specific signal condition that needs to be met, generating a display state and signal condition mapping table data; Using the initial signal relationship spectrum data as constraints and each set of specific signal conditions in the display state and signal condition mapping table data as test target nodes, the optimal path sequence for traversing all test target nodes from the initial state is planned. Each state switching step in the optimal path sequence is converted into a standardized instruction unit consisting of a signal identifier, a target value, and a switching condition, and then combined in sequence to form a test sequence logic chain.
8. The method for testing a combined instrument according to claim 4, characterized in that, Monitor the execution progress of the target automated test script, and trigger a script switching event when an execution end command is received or a preset execution duration is reached, specifically including: An execution pointer is set within the script interpreter to track the current line of code being parsed and executed in real time, and to generate execution progress. The execution progress is continuously monitored, and the execution progress is compared with the preset key nodes of the target automated test script; When the execution progress indicator has been parsed and executed to the preset end marker in the target automated test script, an end event is generated as a trigger signal for the script switching event; A timer is started to record the execution time of the target automated test script. When the execution time exceeds the maximum allowed execution time threshold preset for the script, a timeout event is generated as a trigger signal for the script switching event. In response to the received end event or timeout event, the current script execution flow is paused, the execution context of the current script is cleaned up, and a script switching event flag is set at the corresponding position of the target automated test script.
9. A combined instrument testing device, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform a combined instrument testing method as described in any one of claims 1-8.
10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, a combined instrument testing method as described in any one of claims 1-8 is implemented.