Non-intrusive software integration testing method and system and storage medium

Abstract

The invention provides a non-intrusive software integration test method and system and a storage medium, and the method comprises the steps: obtaining a test demand and a test scene, presetting a software architecture and an observable variable set according to the test demand and the test scene, generating a non-intrusive data mapping statement, and embedding the non-intrusive data mapping statement into a to-be-tested controller; designing a test case based on the software architecture, the observable variable set and the test scene to obtain a test communication matrix and generate a standard DBC file; the file is imported into a testing upper computer for environment configuration, and then the upper computer and a controller are connected through CAN interface hardware, so that a non-intrusive testing environment is established, and software integration testing is achieved. According to the method, the system and the storage medium, the software architecture and the observable variable set are preset based on the test function requirements, and the non-intrusive data mapping statement is generated and embedded into the to-be-tested controller, so that the internal key state and complex logic of the controller can be observed without changing source codes, and the test coverage accuracy and effectiveness are remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of electric vehicle testing technology, specifically relating to a non-intrusive software integration testing method, system, and storage medium. Background Technology

[0002] With the rapid development of vehicle electrification, intelligence, and connectivity, the complexity of embedded system software continues to increase. Software integration testing has become a crucial link in ensuring the correctness of controller functions and the stability of the system. Traditional software testing methods mostly rely on direct analysis and instrumentation of source code, which not only poses the risk of core code leakage but also requires testers to have in-depth code understanding capabilities, resulting in high testing costs and long cycles. Furthermore, the difference between the test environment and the real operating environment often makes it difficult to effectively expose some deep-seated logical defects and dynamic interaction problems. Therefore, how to achieve in-depth and efficient verification of the internal state and logical behavior of complex software while ensuring code security has become a pressing technical challenge in this field. Against this backdrop, there is an urgent need for a non-intrusive software integration testing method that can balance testing accuracy, security, and execution efficiency. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a non-intrusive software integration testing method, system, and storage medium to solve the aforementioned problems. The method, system, and storage medium pre-define the software architecture and observable variable set based on the test functional requirements, generate non-intrusive data mapping statements, and embed them into the controller under test. This allows for the observation of key states and complex logic within the controller without modifying the source code, significantly improving the accuracy and effectiveness of test coverage.

[0004] To address the aforementioned technical problems, this invention provides a non-intrusive software integration testing method, comprising the following steps: Obtain test functionality requirements and test scenarios; Based on the aforementioned test function requirements, a pre-defined software architecture and set of observable variables are established; Based on the software architecture and the set of observable variables, a non-intrusive data mapping statement is generated and embedded into the controller to be tested. Design a test case set based on the software architecture, observable variable set, and test scenario; The test communication matrix is ​​obtained based on the test case set and non-intrusive data mapping statement. Generate a standard DBC file based on the test communication matrix; Import the standard DBC file into the preset test host computer so that the test host computer can configure the software environment based on the standard DBC file; One end of the preset CAN interface hardware is connected to the test host computer, and the other end is connected to the controller under test, so that the test host computer, CAN interface hardware and non-intrusive data mapping statement are built into a non-intrusive test environment, and then software integration test is realized based on the non-intrusive test environment.

[0005] In the above solution, a pre-defined software architecture and observable variable set are established based on the test functional requirements. Non-intrusive data mapping statements are generated and embedded into the controller under test. This allows for the capture of key states and logic within the controller without modifying the source code, solving the problem of strong dependence on source code in traditional testing and significantly improving the accuracy and effectiveness of test coverage. A standard DBC file is generated based on the test case set and the test communication matrix obtained from the non-intrusive data mapping statements. This file is imported into the host test computer for software environment configuration and connected to the controller via a CAN interface. The resulting non-intrusive test environment is consistent with the real operating environment, ensuring the reliability of test results while significantly reducing the risk of core code leakage and the professional skills required of testers. Furthermore, the test process supported by the standard DBC file improves the reusability and execution efficiency of test case sets, providing efficient, secure, and low-cost testing support for the rapid iterative development of complex embedded software.

[0006] Furthermore, the software architecture and observable variable set are preset based on the test function requirements; the specific process of setting the observable variable set is as follows: The software architecture is pre-designed based on the aforementioned test function requirements; Based on the software architecture, functional modules are divided and interfaces are defined to obtain module function definitions; The set of observable variables is defined based on the module's functional definition.

[0007] The above solution first pre-defines the software architecture based on the test functional requirements, ensuring that the top-level test design directly serves the core verification objectives and lays the foundation for targeted observation. Secondly, based on the software architecture, functional modules are divided and interfaces are defined, forming module function definitions and clarifying internal data flows and logical boundaries. This allows subsequent observation point settings to cover the key states and interactive interfaces of each module, effectively avoiding blind spots in observation. Finally, based on the module function definitions, a set of observable variables is set, ensuring that variables are directly related to specific functional implementations and internal logic. This allows non-intrusive testing to efficiently and accurately capture internal data and state changes related to the test scenario. This solution improves the completeness and accuracy of test coverage, reduces the complexity of test design and reliance on personnel experience, and enhances the reusability of test cases and the maintainability of the testing process.

[0008] It should be noted that the observable variables may include input variables, output variables, and key intermediate variables, used to characterize functional states, decision logic, or intermediate algorithm results. The software architecture can be a formal design specification, clearly defining the data flow and state transition relationships between modules, providing a structured basis for defining observable variables.

[0009] Furthermore, the design of test case sets based on the software architecture, observable variable set, and test scenario includes: Based on the test scenario, obtain the functional definitions of the scenario function modules; Based on the software architecture and the set of observable variables, global and local observation variables are obtained. The test case set is designed based on the functional definitions of the scenario modules, global observation variables, and local observation variables.

[0010] In the above scheme, by using test scenarios as a guide, the functional definitions of the scenario's functional modules are first obtained, directly linking the test objectives to the specific software functionality, ensuring that each test case has a clear and specific verification focus. Combining the software architecture and the set of observable variables, global and local observable variables are accurately distinguished and obtained, achieving optimized configuration of test observation granularity: global observable variables ensure the verification of system-level interactions and overall state, while local observable variables focus on key logic and state transitions within modules. The test case set designed based on the functional definitions of the scenario's functional modules, global and local observable variables enhances test targeting and scenario coverage depth, while avoiding redundant testing through structured variable management, improving execution efficiency. The resulting test cases possess good hierarchy and traceability, significantly improving test case reusability and test activity maintainability.

[0011] It should be noted that the test case set can cover normal functions, boundary conditions, exception handling, and fault injection scenarios; the global observation variables are used for system-level state verification, and the local observation variables are used for module internal logic verification.

[0012] Further, the step of obtaining the test communication matrix based on the test case set and non-intrusive data mapping statement includes: Based on the test case set, obtain global and local observation variables; Based on the global observation variables, local observation variables, and non-intrusive data mapping statements, a set of physical test attribute definitions is obtained; The message identifier, signal definition, physical layout, numerical conversion, and value range description are determined based on the physical test attribute definition set. The test communication matrix is ​​obtained based on the message identifier, signal definition, physical layout, numerical conversion, and value range description.

[0013] The above scheme first obtains global and local observation variables based on the test case set, ensuring strict alignment between the test communication matrix and the test target. Then, variable mapping is completed based on the global and local observation variables and non-intrusive data mapping statements to obtain a physical test attribute definition set. This establishes a reliable correspondence between the software's internal state and the communication layer signal definitions, effectively avoiding errors introduced by manual mapping. On this basis, message identifiers, signal definitions, physical layouts, numerical conversions, and value range descriptions are determined based on the physical test attribute definition set, generating a structurally complete and clearly defined test communication matrix that can directly drive subsequent standard DBC file generation and test environment configuration. This scheme improves the efficiency and accuracy of test communication matrix construction, strengthens the underlying communication foundation for test stimulus and observation, and provides key support for automated, standardized, and non-intrusive testing processes.

[0014] It should be noted that the test communication matrix can explicitly define the CAN message ID, signal name, signal length, byte order, scaling factor, and offset; the non-intrusive data mapping statement is implemented in the code to map internal variables to CAN or diagnostic messages without changing the core business logic.

[0015] Furthermore, the step of connecting one end of the preset CAN interface hardware to the test host computer and the other end to the controller under test, so as to build a non-intrusive test environment by connecting the test host computer, the CAN interface hardware, and the non-intrusive data mapping statement, and then realizing software integration testing based on the non-intrusive test environment; includes: One end of the preset CAN interface hardware is connected to the test host computer, and the other end is connected to the controller under test through the board and bench, so that the board and bench output simulated real test signals to the controller under test; A non-intrusive testing environment is built based on the simulated real test signals, the test host computer, the CAN interface hardware, and the non-intrusive data mapping statements, and then software integration testing is carried out based on the non-intrusive testing environment.

[0016] In the above solution, one end of the CAN interface hardware is connected to the test host computer, and the other end is connected to the controller under test via a board and bench. The board and bench output simulated real test signals, injecting high-fidelity operating stimuli into the controller, effectively replicating its electrical and communication states under real operating conditions. Based on this, the test host computer, CAN interface hardware, and non-intrusive data mapping statements embedded in the controller are integrated to build a complete non-intrusive test environment, achieving "black box" verification without modifying the source code. This solution ensures the reliability and authenticity of test results, effectively exposing deep-seated defects in real software interactions. Simultaneously, through standardized hardware connections and signal simulation, it reduces the complexity of test environment setup, improves test preparation efficiency and consistency, and provides a safe and efficient verification platform for software integration testing.

[0017] It should be noted that the board and bench may include a programmable power supply, a fault injection unit and a sensor simulator, used to simulate various real working conditions such as voltage changes, load changes, and signal faults.

[0018] Furthermore, the software integration testing based on the non-intrusive testing environment specifically includes the following steps: In the non-intrusive testing environment, a preset diagnostic command is sent based on the test case set to enable the controller under test to turn on a preset debugging switch in the controller, thereby causing the controller to output a test message; Based on the test message, obtain real-time observable variables; The real-time test data stream is obtained based on the real-time observable variables and non-intrusive data mapping statements, so that the real-time test data stream is input to the test host computer, and then the software integration test results are obtained.

[0019] In the above scheme, under a non-intrusive testing environment, preset diagnostic commands are sent based on the test case set to activate the preset debugging switch of the controller under test, causing the controller to output test messages. This enables non-intrusive, on-demand, in-depth observation of the software's operational status. Subsequently, real-time observable variables are obtained based on the test messages, and combined with non-intrusive data mapping statements to obtain the real-time test data stream, which is then input into the host computer to generate software integration test results. This scheme achieves a complete closed loop of automatic test data acquisition, conversion, and uploading, improving the automation and objectivity of test execution and result judgment, effectively supporting the accurate verification of dynamic software behavior and complex interactions, and enhancing test depth and reliability.

[0020] It should be noted that the host computer for testing can support a graphical monitoring panel to display variable values ​​in real time, and supports automated comparison and judgment of preset expected behavior and actual test results.

[0021] The present invention also provides a non-intrusive software integration testing system, comprising: The test requirements acquisition module is used to acquire test function requirements and test scenarios; The architecture design module is used to pre-define the software architecture and observable variable set based on the test function requirements; A non-intrusive statement embedding module is used to generate non-intrusive data mapping statements based on the software architecture and observable variable set, and to embed the non-intrusive data mapping statements into the controller to be tested; The test case design module is used to design test case sets based on the software architecture, observable variable set, and test scenario. A test communication matrix writing module is used to obtain the test communication matrix based on the test case set and non-intrusive data mapping statements. A non-intrusive test environment configuration module is used to generate a standard DBC file based on the test communication matrix; import the standard DBC file into a preset test host computer so that the test host computer can configure the software environment based on the standard DBC file; connect one end of a preset CAN interface hardware to the test host computer and the other end to the controller under test, so that the test host computer, CAN interface hardware and non-intrusive data mapping statements are built into a non-intrusive test environment, and then realize software integration testing based on the non-intrusive test environment.

[0022] In the above solution, relying on the test requirements acquisition, architecture design, and non-intrusive statement embedding modules, the software architecture and observable variable set are preset based on the test functional requirements. Non-intrusive data mapping statements are generated and embedded into the controller under test, capturing internal key states and logic without modifying the source code. This solves the problem of strong dependence on source code in traditional testing, improving the accuracy and effectiveness of test coverage. Based on the test communication matrix output by the test case design and communication matrix writing modules, a standard DBC file is generated, imported into the host computer configuration environment, and connected to the controller via CAN interface hardware. The resulting non-intrusive test environment closely resembles real-world operating conditions, ensuring the reliability of test results while reducing the risk of core code leakage and lowering personnel skill requirements. Furthermore, the test process supported by the standard DBC file improves the reusability and execution efficiency of test case sets, providing efficient, secure, and low-cost testing support for the iterative development of complex embedded software.

[0023] Furthermore, the architecture design module is used to pre-define the software architecture and a set of observable variables based on the test function requirements; the process of setting the set of observable variables specifically includes: The software architecture is pre-designed based on the aforementioned test function requirements; Based on the software architecture, functional modules are divided and interfaces are defined to obtain module function definitions; The set of observable variables is defined based on the module's functional definition.

[0024] In the above solution, the architecture design module first pre-defines the software architecture based on the test functional requirements, ensuring that the top-level test design directly serves the core verification objectives and lays the foundation for targeted observation. Secondly, based on the software architecture, it completes the functional module division and interface definition, forming module function definitions, clarifying internal data flows and logical boundaries, enabling subsequent observation point settings to cover the key states and interactive interfaces of each module, effectively avoiding observation blind spots. Finally, based on the module function definitions, it sets observable variable sets, ensuring that variables are directly related to specific functional implementations and internal logic, allowing non-intrusive testing to efficiently and accurately capture internal data and state changes related to the test scenario. This solution improves the completeness and accuracy of test coverage, reduces the complexity of test design and reliance on personnel experience, and enhances the reusability of test cases and the maintainability of the test process.

[0025] Furthermore, the test case design module is used to design a test case set based on the software architecture, the set of observable variables, and the test scenario; including: Based on the test scenario, obtain the functional definitions of the scenario function modules; Based on the software architecture and the set of observable variables, global and local observation variables are obtained. The test case set is designed based on the functional definitions of the scenario modules, global observation variables, and local observation variables.

[0026] In the above scheme, the test case design module, guided by test scenarios, first obtains the functional definitions of the scenario functional modules, directly linking test objectives with specific software function implementations, ensuring that each test case has a clear and specific verification focus. Combining the software architecture and observable variable set, it accurately distinguishes and obtains global and local observation variables, achieving optimized configuration of test observation granularity: global observation variables ensure the verification of system-level interactions and overall state, while local observation variables focus on key logic and state transitions within modules. The test case set designed based on the functional definitions of scenario functional modules, global and local observation variables enhances test targeting and scenario coverage depth, while avoiding redundant testing through structured variable management, improving execution efficiency. The resulting test cases possess good hierarchy and traceability, significantly improving test case reusability and test activity maintainability.

[0027] Another embodiment of the present invention provides a computer-readable storage medium item, including: a stored computer program, which, when the computer program is running, controls the device where the computer-readable storage medium is located to perform the steps of a non-intrusive software integration testing method of the present invention. Attached Figure Description

[0028] Figure 1This is a schematic diagram of a non-intrusive software integration testing method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a non-intrusive software integration testing system architecture provided in an embodiment of the present invention. Detailed Implementation

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] Please see Figure 1 This embodiment provides a non-intrusive software integration testing method, including the following steps: Step S1: Obtain test function requirements and test scenarios; Step S2: Based on the aforementioned test function requirements, pre-define the software architecture and observable variable set; Step S3: Generate a non-intrusive data mapping statement based on the software architecture and the set of observable variables, and embed the non-intrusive data mapping statement into the controller to be tested; Step S4: Design a test case set based on the software architecture, observable variable set, and test scenario; Step S5: Obtain the test communication matrix based on the test case set and non-intrusive data mapping statement; Step S6: Generate a standard DBC file based on the test communication matrix; Step S7: Import the standard DBC file into the preset test host computer so that the test host computer can configure the software environment based on the standard DBC file; Step S8: Connect one end of the preset CAN interface hardware to the test host computer and the other end to the controller to be tested, so that the test host computer, CAN interface hardware and non-intrusive data mapping statement are built into a non-intrusive test environment, and then software integration test is realized based on the non-intrusive test environment.

[0031] In this embodiment, a non-intrusive data mapping statement is generated and embedded into the controller under test based on the pre-defined software architecture and observable variable set according to the test functional requirements. This allows for the capture of key states and logic within the controller without modifying the source code, solving the problem of strong dependence on source code in traditional testing and significantly improving the accuracy and effectiveness of test coverage. A standard DBC file is generated based on the test case set and the test communication matrix obtained from the non-intrusive data mapping statement. This file is imported into the test host computer for software environment configuration and connected to the controller via a CAN interface. The resulting non-intrusive test environment is consistent with the real operating environment, ensuring the reliability of test results while significantly reducing the risk of core code leakage and the professional skills required of testers. Furthermore, the test process supported by the standard DBC file improves the reusability and execution efficiency of the test case set, providing efficient, secure, and low-cost testing support for the rapid iterative development of complex embedded software.

[0032] In one embodiment, a non-intrusive software integration testing method is provided. First, the test function requirements and corresponding test scenarios of the controller under test are obtained, such as verifying the alarm and actuator linkage function of the vehicle body controller during a collision. Based on these function requirements, implementation is carried out during the software development phase according to a predefined software architecture design specification (i.e., software architecture). The software architecture clearly identifies variables used to characterize the core functional states and key decision logic, forming an observable variable set. Taking the collision alarm function as an example, through analysis of the software architecture, it is determined that it involves modules such as CAN signal reception, hard-wired signal reception, collision alarm processing, door lock control, horn control, and headlight control. The input variables are then extracted as CAN collision signals and hard-wired collision signals. The output and key internal state variables include crash_status (collision status), lock_status (door lock status), horn_status (horn status), light_status (headlight status), horn_pwm (horn drive signal duty cycle), and light_pwm (headlight drive signal duty cycle). These variables together constitute the observable variable set for this function.

[0033] Subsequently, based on the aforementioned software architecture and observable variable set, non-intrusive data mapping statements are generated and embedded into the controller software. At the final output location of the corresponding functional module, statements mapping key variable values ​​to specific CAN signals are added without altering the original core business logic. For example, the Boolean variable `crash_status` is mapped to bit 0 of byte 0 of the CAN message (ID 0x100), and `lock_status` is mapped to bit 1 of byte 0 of the same message. For numerical variables, such as arbitration torque, scaling can be used to map them to a specified signal in a dedicated test message. This process only adds a data output path and does not introduce additional functional risks.

[0034] Next, testers designed a test case set based on the same software architecture design specification (i.e., software architecture), the defined set of observable variables, and the test scenario. Taking the aforementioned collision scenario as an example, the test case was designed as follows: Under the premise that the system is powered normally, the doors are closed, and the warning lights and horn are not activated, a hard-wired collision signal is injected. The expected result is that the observable variable set changes accordingly: crash_status changes from 0 to 1, lock_status changes from 1 to 0, horn_status and light_status change from 0 to 1, horn_pwm changes to 60, and light_pwm changes to 30. Based on this test case set and the implemented data mapping relationship, a test communication matrix was compiled, clearly defining the CAN message ID, signal name, starting byte, starting bit, signal length, scaling factor, offset, and physical value meaning of each variable. For example, for message 0x100, the signal crash_status is defined to start at byte 0, bit 0, with a length of 1 bit, where 0 indicates no collision and 1 indicates a collision; the signal lock_status starts at byte 0, with a length of 1 bit, where 0 indicates unlocked and 1 indicates locked.

[0035] Using this test communication matrix, a standard DBC file is generated through a database editing tool. It should be noted that this DBC file enables the test host computer to parse the received raw CAN message data (such as BE 5E 00 00 00 00 00 00) into signal values ​​with clear engineering significance, forming the basis for automated observation and judgment. The obtained DBC file is imported into the test host computer (such as CANoe) to complete the environment configuration. Subsequently, a non-intrusive test environment is established by connecting the test host computer and the controller under test via a CAN interface hardware connection. The data mapping output function within the controller is activated through diagnostic commands. The test system simulates test case input conditions (such as injecting collision signals), and the host computer parses the received messages in real time according to the DBC file, obtains the actual values ​​of the observable variable set, and automatically compares them with the expected results preset in the test cases. This completes the integration test of the software functional logic, effectively ensuring that the test process does not access the source code, the environment is realistic, and the results are reliable.

[0036] Furthermore, the software architecture and observable variable set are preset based on the test function requirements; the specific process of setting the observable variable set is as follows: The software architecture is pre-designed based on the aforementioned test function requirements; Based on the software architecture, functional modules are divided and interfaces are defined to obtain module function definitions; The set of observable variables is defined based on the module's functional definition.

[0037] In this embodiment, the software architecture is first pre-defined based on the test functional requirements, ensuring that the top-level test design directly serves the core verification objectives and laying the foundation for targeted observation. Secondly, based on the software architecture, functional modules are divided and interfaces are defined, forming module function definitions and clarifying internal data flows and logical boundaries. This allows the subsequent observation point setting system to cover the key states and interactive interfaces of each module, effectively avoiding blind spots in observation. Finally, based on the module function definitions, a set of observable variables is set, ensuring that variables are directly related to specific functional implementations and internal logic. This allows non-intrusive testing to efficiently and accurately capture internal data and state changes related to the test scenario. This embodiment improves the completeness and accuracy of test coverage, reduces the complexity of test design and reliance on personnel experience, and enhances the reusability of test cases and the maintainability of the test process.

[0038] Furthermore, the design of test case sets based on the software architecture, observable variable set, and test scenario includes: Based on the test scenario, obtain the functional definitions of the scenario function modules; Based on the software architecture and the set of observable variables, global and local observation variables are obtained. The test case set is designed based on the functional definitions of the scenario modules, global observation variables, and local observation variables.

[0039] In this embodiment, guided by test scenarios, the functional definitions of the scenario's functional modules are first obtained, directly linking the test objectives to the specific software functionality, ensuring that each test case has a clear and specific verification focus. Combining the software architecture and observable variable set, global and local observation variables are precisely distinguished and obtained, achieving optimized configuration of test observation granularity: global observation variables ensure the verification of system-level interactions and overall state, while local observation variables focus on key logic and state transitions within modules. The test case set designed based on the functional definitions of the scenario's functional modules, global and local observation variables enhances test targeting and scenario coverage depth, while structured variable management avoids redundant testing and improves execution efficiency. The resulting test cases possess good hierarchy and traceability, significantly improving test case reusability and test activity maintainability.

[0040] In one embodiment, a specific implementation method for software architecture pre-setting, observable variable set setting, and test case set design in a non-intrusive software integration testing method is provided.

[0041] First, the software architecture is pre-designed based on the test functionality requirements. It should be noted that this aims to ensure that the overall software structure and data flow design are aligned with the test verification objectives from the outset, establishing a top-level framework for subsequent non-intrusive observation. Taking the collision alarm function of the vehicle body controller as an example, its software architecture must explicitly support the complete chain from signal input and logic processing to actuator driving.

[0042] Subsequently, based on the aforementioned software architecture, functional modules were divided and interfaces were defined, resulting in clear module function definitions. Under this collision alarm function architecture, modules including a CAN signal receiving module, a hard-wired signal receiving module, a collision alarm processing module, a door lock control module, a horn control module, and a headlight control module can be defined. The interfaces between each module define the data interaction specifications; for example, the hard-wired signal receiving module transmits hard-wired collision signals to the collision alarm processing module.

[0043] Subsequently, the observable variable set is defined based on the module function definition. Software developers code according to a formalized software architecture design specification (i.e., a pre-defined software architecture). This software architecture, based on traditional module division and interface definition, explicitly identifies variables used to characterize core functional states, key decision logic, or intermediate results of complex algorithms, forming the observable variable set. These variables serve as observation anchors for subsequent testing and include input variables, output variables, and internal key state variables. In the collision alarm function, according to the module function definition, the configurable input variables are: CAN collision signal and hard-wired collision signal; the output and key internal variables (i.e., the observable variable set) include: crash_status (collision status), lock_status (door lock status), horn_status (horn status), light_status (headlight status), horn_pwm (horn drive signal duty cycle), and light_pwm (headlight drive signal duty cycle), etc.

[0044] Based on the established set of observable variables, a test case set is designed. Specifically, this includes obtaining the functional definitions of the scenario's functional modules based on the test scenario. For example, for the "vehicle collision" test scenario, the focused functional modules mainly include the collision alarm processing module and its related actuator control modules.

[0045] Next, based on the software architecture and the established set of observable variables, global and local observation variables are obtained. It should be noted that global observation variables are used to verify system-level interactions and overall state, such as crash_status (collision status); local observation variables are used to deeply verify the internal logic of specific modules, such as the internal state variables in the door lock module used to disable remote control functionality (for vehicles with remote unlocking capabilities).

[0046] Finally, based on the functional definitions of the scenario modules, global observation variables, and local observation variables, the test case set is designed. Testers analyze the expected behavior, input-output relationships, and state transition logic of the target functional modules using the same software architecture (not source code) and a pre-defined list of observable variables, thereby designing comprehensive test cases. Test cases should cover normal functions, boundary conditions, exception handling, and fault injection scenarios. During this process, testers precisely extract key variables related to the current test case from the architecture specifications as verification criteria. For example, for the torque arbitration function, Torque_Arbitation_Result (the torque arbitration result, i.e., the final target torque value output after coordination and arbitration of multiple torque request sources) is extracted; or for the thermal management function, Coolant_Flow_Target (the target coolant flow rate, i.e., the expected coolant flow rate calculated based on engine or battery temperatures and other operating conditions) is extracted.

[0047] This embodiment combines test scenarios, functional module definitions, and observation variables at different levels to design a test case set that has clear verification orientation, optimized observation granularity, and good structural hierarchy. This ensures test depth while improving the reusability of test cases and the maintainability of test activities.

[0048] Further, the step of obtaining the test communication matrix based on the test case set and non-intrusive data mapping statement includes: Based on the test case set, obtain global and local observation variables; Based on the global observation variables, local observation variables, and non-intrusive data mapping statements, a set of physical test attribute definitions is obtained; The message identifier, signal definition, physical layout, numerical conversion, and value range description are determined based on the physical test attribute definition set. The test communication matrix is ​​obtained based on the message identifier, signal definition, physical layout, numerical conversion, and value range description.

[0049] In this embodiment, global and local observation variables are first obtained based on the test case set to ensure strict alignment between the test communication matrix and the test target. Then, variable mapping is completed based on the global and local observation variables and non-intrusive data mapping statements to obtain a physical test attribute definition set. This establishes a reliable correspondence between the software's internal state and the communication layer signal definitions, effectively avoiding errors introduced by manual mapping. Based on this, message identifiers, signal definitions, physical layouts, numerical conversions, and value range descriptions are determined based on the physical test attribute definition set, generating a structurally complete and clearly defined test communication matrix that can directly drive subsequent standard DBC file generation and test environment configuration. This embodiment improves the efficiency and accuracy of test communication matrix construction, strengthens the underlying communication foundation for test stimulus and observation, and provides key support for automated, standardized, and non-intrusive testing processes.

[0050] In one embodiment, the global and local observation variables involved are first obtained based on the test case set. Global observation variables are typically used to verify system-level behavior and states, such as crash_status, which characterizes the state of a vehicle collision; local observation variables are used to examine the internal logic of specific modules, such as lock_status, which characterizes the specific state of a door lock.

[0051] Subsequently, based on the acquired global and local observation variables, as well as the non-intrusive data mapping statements embedded in the controller during the development phase, precise variable mapping is performed. This mapping process aims to establish a one-to-one correspondence between the logical variables within the software and the physical signals of the CAN network communication layer, thereby obtaining a structured set of physical test attribute definitions. It should be noted that this definition set is the foundation for the subsequent generation of a machine-readable communication matrix. It ensures the accuracy of the conversion relationship from internal software states to bus signals, effectively avoiding ambiguity or errors that may be introduced by manual definitions.

[0052] Subsequently, based on the physical test attribute definition set, the specific communication attributes carrying these variables are determined. These communication attributes include, but are not limited to: Message Identifier: This refers to the identifier (ID) of the CAN message. For example, a dedicated message ID 0x100 can be assigned to variables related to collision alarms.

[0053] Signal definition: This refers to the signal name of each observable variable in the communication matrix. It must be consistent with the internal variable name in the software or have an explicit mapping established, such as crash_status.

[0054] Physical layout: Defines the specific location of each signal within the message data field. Taking a standard 8-byte (64-bit) CAN message as an example: crash_status (collision status): The starting byte is 0, the starting bit is 0, and the signal length is 1 bit. Its value range is described as follows: 0 represents no collision, and 1 represents a collision.

[0055] lock_status (lock status): The starting byte is 0, the starting bit is 1, and the signal length is 1 bit. Its value range is described as follows: 0 represents unlocked, and 1 represents locked.

[0056] Numerical Conversion: For non-Boolean numerical variables, scaling factors and offsets need to be defined to convert the software's engineered values ​​into the raw values ​​of the CAN signal, or vice versa. For example, torque values ​​may need to be multiplied by a scaling factor before being sent in integer form.

[0057] Value range description: Clarify the meaning of the physical value of the signal, such as the definition of 0 and 1 above.

[0058] Finally, by integrating the aforementioned determined message identifiers, signal definitions, physical layouts, numerical conversions, and value range descriptions, a standardized and fully defined dedicated test communication matrix is ​​formed. In this embodiment, the test communication matrix exists in tabular or structured data form, clearly defining the communication specifications for all test observation data.

[0059] After this, a standard DBC (CAN database) file is generated using a dedicated database editing tool (such as CANdb++ Editor) with the test communication matrix as input.

[0060] It should be noted that the standard DBC file contains all the definitions in the aforementioned communication matrix, enabling the test host computer (such as CANoe) and its supporting CAN interface hardware to correctly parse and decode the CAN messages carrying observable variable data sent from the controller under test based on this file, thereby restoring the original binary data stream into engineering values ​​with clear physical meaning for subsequent observation, recording and automated judgment.

[0061] Furthermore, the step of connecting one end of the preset CAN interface hardware to the test host computer and the other end to the controller under test, so as to build a non-intrusive test environment by connecting the test host computer, the CAN interface hardware, and the non-intrusive data mapping statement, and then realizing software integration testing based on the non-intrusive test environment; includes: One end of the preset CAN interface hardware is connected to the test host computer, and the other end is connected to the controller under test through the board and bench, so that the board and bench output simulated real test signals to the controller under test; A non-intrusive testing environment is built based on the simulated real test signals, the test host computer, the CAN interface hardware, and the non-intrusive data mapping statements, and then software integration testing is carried out based on the non-intrusive testing environment.

[0062] In this embodiment, one end of the CAN interface hardware is connected to the test host computer, and the other end is connected to the controller under test via a board and bench. The board and bench output simulated real test signals, injecting high-fidelity operating stimuli into the controller, effectively replicating its electrical and communication states under real operating conditions. Based on this, a complete non-intrusive test environment is built by integrating the test host computer, CAN interface hardware, and non-intrusive data mapping statements embedded in the controller, achieving "black box" verification without modifying the source code. This embodiment ensures the reliability and authenticity of test results, effectively exposing deep-seated defects in real software interactions. Simultaneously, through standardized hardware connections and signal simulation, it reduces the complexity of test environment setup, improves test preparation efficiency and consistency, and provides a safe and efficient verification platform for software integration testing.

[0063] Furthermore, the software integration testing based on the non-intrusive testing environment specifically includes the following steps: In the non-intrusive testing environment, a preset diagnostic command is sent based on the test case set to enable the controller under test to turn on a preset debugging switch in the controller, thereby causing the controller to output a test message; Based on the test message, obtain real-time observable variables; The real-time test data stream is obtained based on the real-time observable variables and non-intrusive data mapping statements, so that the real-time test data stream is input to the test host computer, and then the software integration test results are obtained.

[0064] In this embodiment, under a non-intrusive testing environment, a preset diagnostic command is sent based on the test case set to activate a preset debugging switch on the controller under test, causing the controller to output test messages. This enables non-intrusive, on-demand, in-depth observation of the software's operational status. Subsequently, real-time observable variables are obtained based on the test messages, and combined with non-intrusive data mapping statements to obtain a real-time test data stream, which is then input into the host computer to generate software integration test results. This embodiment achieves a complete closed loop of automatic test data acquisition, conversion, and uploading, improving the automation and objectivity of test execution and result judgment, effectively supporting accurate verification of dynamic software behavior and complex interactions, and enhancing test depth and reliability.

[0065] In one embodiment, the construction of the non-intrusive test environment specifically includes: connecting one end of a preset CAN interface hardware (such as a CAN box) to a computing device equipped with a professional test host computer (such as CANoe or CANalyzer), and connecting the other end of the device to be tested to a board and a test bench.

[0066] It should be noted that the above connection method constitutes the physical basis of the test. The boards and bench are used to integrate peripherals such as programmable power supplies, fault injection units, and sensor simulators. Their function is to accurately output electrical and communication signals simulating real-world operating conditions (such as simulated voltage changes, sensor signals, load surges, or network messages) according to the requirements of the test cases, and inject these signals into the controller under test, thereby providing the controller with high-fidelity operating stimuli and reproducing its real working environment. At the same time, the standard DBC file generated based on the test communication matrix is ​​imported into the test host computer to complete the software-level parsing environment configuration. Thus, by integrating the test host computer, CAN interface hardware, boards and bench peripherals, and the non-intrusive data mapping statements embedded in the controller, a complete non-intrusive test environment highly consistent with the real operating environment is constructed.

[0067] Software integration testing is implemented based on the established non-intrusive testing environment, specifically including the following steps: First, in the test environment, based on the operation logic of the test case set, preset diagnostic instructions are sent to the controller under test through the test host computer or diagnostic tools.

[0068] It should be noted that the diagnostic command is used to activate the pre-set debug switch inside the controller, enabling the non-intrusive data mapping statement embedded in the controller, thereby allowing the controller to start outputting test messages containing key observable variable data via the CAN network. In mass production software, this function is disabled by default to ensure information security and clean operation.

[0069] Next, test execution and data observation are performed. The test system driver board and peripherals on the test bench accurately simulate various input conditions defined by the test cases, driving the controller to run. At the same time, the host computer receives test messages sent by the controller in real time through the CAN interface hardware, and parses them into real-time observable variables with clear engineering significance according to the imported DBC file, such as lock_status (door lock status) and horn_status (horn status), thereby obtaining the real-time test data stream.

[0070] Finally, the results are automatically compared and judged. Testers can create graphical monitoring panels in the test host computer to intuitively monitor the real-time changes of key variables. More importantly, by automatically comparing the actual observed variable behavior with the expected behavior preset in the test cases, the correct implementation of the functional logic can be determined. For example, for collision alarm testing, the expected behavior can be set as follows: within 100ms after the collision signal is injected, lock_status changes from 1 (locked) to 0 (unlocked), and horn_status changes from 0 (silent) to 1 (honking). The test host computer automatically completes such timing and status logic verification, thereby objectively and efficiently generating software integration test results.

[0071] Please see Figure 2 This embodiment also provides a non-intrusive software integration testing system, including: The test requirements acquisition module is used to acquire test function requirements and test scenarios; The architecture design module is used to pre-define the software architecture and observable variable set based on the test function requirements; A non-intrusive statement embedding module is used to generate non-intrusive data mapping statements based on the software architecture and observable variable set, and to embed the non-intrusive data mapping statements into the controller to be tested; The test case design module is used to design test case sets based on the software architecture, observable variable set, and test scenario. A test communication matrix writing module is used to obtain the test communication matrix based on the test case set and non-intrusive data mapping statements. A non-intrusive test environment configuration module is used to generate a standard DBC file based on the test communication matrix; import the standard DBC file into a preset test host computer so that the test host computer can configure the software environment based on the standard DBC file; connect one end of a preset CAN interface hardware to the test host computer and the other end to the controller under test, so that the test host computer, CAN interface hardware and non-intrusive data mapping statements are built into a non-intrusive test environment, and then realize software integration testing based on the non-intrusive test environment.

[0072] In this embodiment, relying on the test requirement acquisition, architecture design, and non-intrusive statement embedding modules, a software architecture and observable variable set are preset based on the test functional requirements. Non-intrusive data mapping statements are generated and embedded into the controller under test. This captures key internal states and logic without modifying the source code, solving the problem of strong dependence on source code in traditional testing and improving the accuracy and effectiveness of test coverage. Based on the test communication matrix output by the test case design and communication matrix writing modules, a standard DBC file is generated, imported into the host computer configuration environment, and connected to the controller via a CAN interface. This creates a non-intrusive test environment that closely resembles real-world operating conditions, ensuring the reliability of test results while reducing the risk of core code leakage and lowering personnel skill requirements. Furthermore, the test process supported by the standard DBC file improves the reusability and execution efficiency of test case sets, providing efficient, secure, and low-cost testing support for the iterative development of complex embedded software.

[0073] Furthermore, the architecture design module is used to pre-define the software architecture and a set of observable variables based on the test function requirements; the process of setting the set of observable variables specifically includes: The software architecture is pre-designed based on the aforementioned test function requirements; Based on the software architecture, functional modules are divided and interfaces are defined to obtain module function definitions; The set of observable variables is defined based on the module's functional definition.

[0074] In this embodiment, the architecture design module first pre-defines the software architecture based on the test functional requirements, ensuring that the top-level test design directly serves the core verification objective and laying the foundation for targeted observation. Secondly, based on the software architecture, it completes the functional module division and interface definition, forming module function definitions, clarifying internal data flows and logical boundaries, enabling subsequent observation point settings to cover the key states and interactive interfaces of each module, effectively avoiding observation blind spots. Finally, based on the module function definitions, it sets a set of observable variables, ensuring that variables are directly related to specific functional implementations and internal logic, allowing non-intrusive testing to efficiently and accurately capture internal data and state changes related to the test scenario. This embodiment improves the completeness and accuracy of test coverage, reduces the complexity of test design and reliance on personnel experience, and enhances the reusability of test cases and the maintainability of the test process.

[0075] Furthermore, the test case design module is used to design a test case set based on the software architecture, the set of observable variables, and the test scenario; including: Based on the test scenario, obtain the functional definitions of the scenario function modules; Based on the software architecture and the set of observable variables, global and local observation variables are obtained. The test case set is designed based on the functional definitions of the scenario modules, global observation variables, and local observation variables.

[0076] In this embodiment, the test case design module, guided by test scenarios, first obtains the functional definitions of the scenario functional modules, directly linking test objectives with specific software function implementations, ensuring that each test case has a clear and specific verification focus. Combining the software architecture and observable variable set, it accurately distinguishes and obtains global and local observation variables, achieving optimized configuration of test observation granularity: global observation variables ensure the verification of system-level interactions and overall state, while local observation variables focus on key logic and state transitions within modules. The test case set designed based on the scenario functional module functional definitions, global and local observation variables enhances test targeting and scenario coverage depth, while structured variable management avoids redundant testing and improves execution efficiency. The resulting test cases possess good hierarchy and traceability, significantly improving test case reusability and test activity maintainability.

[0077] Based on the above embodiments, another embodiment of the present invention provides a computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute a non-intrusive software integration testing method as described in any of the above method embodiments of the present invention.

[0078] The integrated modules of the system, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0079] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A non-intrusive software integration testing method, characterized in that, Includes the following steps: Obtain test functionality requirements and test scenarios; Based on the aforementioned test function requirements, a pre-defined software architecture and set of observable variables are established; Based on the software architecture and the set of observable variables, a non-intrusive data mapping statement is generated and embedded into the controller to be tested. Design a test case set based on the software architecture, observable variable set, and test scenario; The test communication matrix is ​​obtained based on the test case set and non-intrusive data mapping statement. Generate a standard DBC file based on the test communication matrix; Import the standard DBC file into the preset test host computer so that the test host computer can configure the software environment based on the standard DBC file; One end of the preset CAN interface hardware is connected to the test host computer, and the other end is connected to the controller under test, so that the test host computer, CAN interface hardware and non-intrusive data mapping statement are built into a non-intrusive test environment, and then software integration test is realized based on the non-intrusive test environment.

2. The non-intrusive software integration testing method according to claim 1, characterized in that, The software architecture and observable variable set are pre-defined based on the test function requirements; the specific process of setting the observable variable set is as follows: The software architecture is pre-designed based on the aforementioned test function requirements; Based on the software architecture, functional modules are divided and interfaces are defined to obtain module function definitions; The set of observable variables is defined based on the module's functional definition.

3. The non-intrusive software integration testing method according to claim 1, characterized in that, The design of test case sets based on the software architecture, observable variable set, and test scenario includes: Based on the test scenario, obtain the functional definitions of the scenario function modules; Based on the software architecture and the set of observable variables, global and local observation variables are obtained. The test case set is designed based on the functional definitions of the scenario modules, global observation variables, and local observation variables.

4. The non-intrusive software integration testing method according to claim 1, characterized in that, The process of obtaining the test communication matrix based on the test case set and non-intrusive data mapping statements includes: Based on the test case set, obtain global and local observation variables; Based on the global observation variables, local observation variables, and non-intrusive data mapping statements, a set of physical test attribute definitions is obtained; The message identifier, signal definition, physical layout, numerical conversion, and value range description are determined based on the physical test attribute definition set. The test communication matrix is ​​obtained based on the message identifier, signal definition, physical layout, numerical conversion, and value range description.

5. The non-intrusive software integration testing method according to claim 1, characterized in that, The step involves connecting one end of a pre-set CAN interface hardware to the test host computer and the other end to the controller under test, thereby establishing a non-intrusive test environment by combining the test host computer, the CAN interface hardware, and non-intrusive data mapping statements. Software integration testing is then implemented based on this non-intrusive test environment. This includes: One end of the preset CAN interface hardware is connected to the test host computer, and the other end is connected to the controller under test through the board and bench, so that the board and bench output simulated real test signals to the controller under test; A non-intrusive testing environment is built based on the simulated real test signals, the test host computer, the CAN interface hardware, and the non-intrusive data mapping statements, and then software integration testing is carried out based on the non-intrusive testing environment.

6. The non-intrusive software integration testing method according to claim 1, characterized in that, The software integration testing based on the non-intrusive testing environment specifically includes the following steps: In the non-intrusive testing environment, a preset diagnostic command is sent based on the test case set to enable the controller under test to turn on a preset debugging switch in the controller, thereby causing the controller to output a test message; Based on the test message, obtain real-time observable variables; The real-time test data stream is obtained based on the real-time observable variables and non-intrusive data mapping statements, so that the real-time test data stream is input to the test host computer, and then the software integration test results are obtained.

7. A non-intrusive software integration testing system, characterized in that, include: The test requirements acquisition module is used to acquire test function requirements and test scenarios; The architecture design module is used to pre-define the software architecture and observable variable set based on the test function requirements; A non-intrusive statement embedding module is used to generate non-intrusive data mapping statements based on the software architecture and observable variable set, and to embed the non-intrusive data mapping statements into the controller to be tested; The test case design module is used to design test case sets based on the software architecture, observable variable set, and test scenario. A test communication matrix writing module is used to obtain the test communication matrix based on the test case set and non-intrusive data mapping statements. A non-intrusive test environment configuration module is used to generate standard DBC files based on the test communication matrix; The standard DBC file is imported into a preset test host computer, so that the test host computer can configure the software environment based on the standard DBC file; one end of the preset CAN interface hardware is connected to the test host computer, and the other end is connected to the controller under test, so that the test host computer, CAN interface hardware and non-intrusive data mapping statement are built into a non-intrusive test environment, and then software integration testing is realized based on the non-intrusive test environment.

8. A non-intrusive software integration testing system according to claim 7, characterized in that, The architecture design module is used to pre-define the software architecture and a set of observable variables based on the test function requirements; the process of setting the set of observable variables is as follows: The software architecture is pre-designed based on the aforementioned test function requirements; Based on the software architecture, functional modules are divided and interfaces are defined to obtain module function definitions; The set of observable variables is defined based on the module's functional definition.

9. A non-intrusive software integration testing system according to claim 7, characterized in that, The test case design module is used to design a test case set based on the software architecture, observable variable set, and test scenario; it includes: Based on the test scenario, obtain the functional definitions of the scenario function modules; Based on the software architecture and the set of observable variables, global and local observation variables are obtained. The test case set is designed based on the functional definitions of the scenario modules, global observation variables, and local observation variables.

10. A computer-readable storage medium, characterized in that, include: A stored computer program, wherein, when the computer program is executed, it controls the device containing the computer-readable storage medium to perform a non-intrusive software integration testing method as described in any one of claims 1-6.

Images