Interface test method, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an interface test method, electronic equipment and a storage medium, and the method comprises the steps: analyzing a configuration file of an automobile open system architecture, and obtaining the interface information of a runtime environment RTE interface; generating a test function according to the interface type of the RTE interface; generating a test code based on the configuration file, the interface information, the source code of the RTE interface and the test function; and executing the test code to obtain a test result of the RTE interface. According to the embodiment of the invention, the test code can be automatically generated based on the automobile open system architecture configuration file, the interface information and the RTE interface source code, the test result of the RTE interface is directly obtained by executing the test code, manual configuration and debugging are not needed, and the test efficiency of the RTE interface is effectively improved.

Description

Technical Field

[0001] This application relates to the field of interface technology, and in particular to an interface testing method, electronic device, and storage medium. Background Technology

[0002] In the field of automotive electronics, the Automotive Open System Architecture (AUTOSAR) is becoming increasingly important in automotive development. In the AUTOSAR architecture, the Run Time Environment (RTE), situated between the application layer and the underlying software layer, provides infrastructure services for various application software. Therefore, the accuracy and efficiency of RTE interface testing have become key factors affecting the development of in-vehicle systems.

[0003] Traditional RTE interface testing solutions mainly rely on configuration tools, debuggers, and bus tools for manual configuration and debugging, resulting in a large workload and high maintenance costs, leading to low testing efficiency for RTE interfaces. Summary of the Invention

[0004] In view of the above, it is necessary to provide an interface testing method, electronic device and storage medium to solve the problem that the traditional RTE interface testing scheme has a large testing workload and high maintenance cost, resulting in low testing efficiency of RTE interface.

[0005] In a first aspect, embodiments of this application provide an interface testing method, the method comprising: Parse the configuration file of the automotive open system architecture to obtain the interface information of the runtime environment RTE interface; Generate a test function based on the interface type of the RTE interface; Based on the configuration file, the interface information, the source code of the RTE interface, and the test function, test code is generated; Execute the test code to obtain the test results of the RTE interface.

[0006] In one possible implementation, generating the test function based on the interface type of the RTE interface includes: If the interface type is a client-server (CS) interface, an interface call function for the required port in the CS interface is generated according to the calibration value, and the calibration value is used to control the call of the required port; Based on the observations, an interface response function for the feed port in the CS interface is generated, and the observations are used to record the response results of the CS interface; Based on the interface call function and the interface response function, a test function for the CS interface is generated.

[0007] In one possible implementation, executing the test code to obtain the test results of the RTE interface includes: In the case where the calibration quantity indicates that the state has not been triggered, the demand port calls the supply port to process the request and update the calibration quantity to indicate that the state has been triggered. When the calibrated quantity is updated to indicate a triggered state, the observation is updated according to the response of the supply port to the request; The test results of the CS interface are determined based on the calibrated values ​​and the observed values.

[0008] In one possible implementation, determining the test result of the CS interface based on the calibrated quantity and the observed quantity includes: If the calibration indicator is not triggered, it is determined that the CS interface has not been tested; If the calibration quantity indication is in a triggered state and the observation quantity indication is in a failed state, it is determined that the CS interface communication is abnormal; If the calibration quantity indication is triggered and the observation quantity indication is successful, it is determined that the CS interface communication is normal.

[0009] In one possible implementation, generating the test function based on the interface type of the RTE interface includes: If the interface type is a sender-receiver (SR) interface, set the test parameters of the SR interface. The test parameters are used to control the boundary value test of the SR interface. Generate the test function for the SR interface based on the test parameters.

[0010] In one possible implementation, the test parameters include at least one of a state machine, an interface parameter value group, a flag group, an observation group, read-value variables, and write-value variables. Running the test code to obtain the test results of the RTE interface includes: For any boundary value in the test code, if the state machine value corresponding to any boundary value matches the boundary value and the flag bit corresponding to the boundary value indicates a non-triggered state, then write the boundary value in the interface parameter value group into the write variable. The boundary value is published to the automotive open system architecture bus through the provided port, and the flag bit corresponding to the boundary value is updated to indicate that the trigger status has been triggered. If the flag corresponding to any boundary value is updated to indicate a triggered state, and the observation corresponding to any boundary value indicates an unverified state, the data of the automotive open system architecture bus is read through the required port, and the read data is written into the read value variable. The read value variable is compared with the write value variable, and the observation corresponding to any boundary value is updated based on the comparison result. After all boundary value tests are completed, the test results of the SR interface are determined based on the state machine, the flag group, and the observation group.

[0011] In one possible implementation, determining the test result of the SR interface based on the state machine, the flag set, and the observation set includes: If the state machine value does not change or all flag bits in the flag group indicate a non-triggered state, it is determined that the SR interface has not been tested. If any boundary value in the observation group indicates a failure status, the boundary value test of the SR interface is determined to be unqualified. If all boundary values ​​in the observation group indicate a successful status, the boundary value test of the SR interface is deemed qualified.

[0012] In one possible implementation, the interface information includes the interface identifier, interface type, and mapping relationship between demand and supply ports of the RTE interface. The step of generating test code based on the configuration file, the interface information, the source code of the RTE interface, and the test function includes: The interface information is verified based on the configuration file. If the interface information is verified as qualified, the positions of the port function of the required port and the port function of the supplied port in the source code are determined according to the interface identifier and the mapping relationship; Write the test function corresponding to the interface type of the interface identifier into the specified location to obtain the test code.

[0013] Secondly, embodiments of this application provide an interface testing apparatus, the apparatus comprising: The parsing module is used to parse the configuration files of the automotive open system architecture to obtain the interface information of the runtime environment RTE interface; The generation module is used to generate test functions based on the interface type of the RTE interface; The generation module is also used to generate test code based on the configuration file, the interface information, the source code of the RTE interface, and the test function; The testing module is used to execute the test code and obtain the test results of the RTE interface.

[0014] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described interface testing method.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, and the computer program, when executed by a processor, is the interface testing method described above.

[0016] This application provides an interface testing method, electronic device, and storage medium that can generate corresponding test functions based on the interface type of the RTE interface. Then, by combining configuration files, interface information, the source code of the RTE interface, and test functions, test code is automatically generated. By executing the test code, the test results of the RTE interface can be obtained directly without relying on configuration tools, debuggers, or bus tools for manual configuration and debugging. This effectively improves the testing efficiency of the RTE interface and reduces human error, thereby improving the accuracy of the RTE interface test results. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of an open automotive system architecture provided in one embodiment of this application.

[0019] Figure 2 This is a flowchart of an interface testing method provided in an embodiment of this application.

[0020] Figure 3 This is a flowchart of generating test code provided in one embodiment of this application.

[0021] Figure 4 This is a flowchart illustrating the determination of test results for the CS interface according to an embodiment of this application.

[0022] Figure 5 This is a flowchart illustrating the test results for determining the SR interface, provided in one embodiment of this application.

[0023] Figure 6 This is a schematic diagram of the interface testing device provided in one embodiment of this application.

[0024] Figure 7 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used in this application's specification is for the purpose of describing particular embodiments only and is not intended to limit the application. It should be understood that, unless otherwise stated, " / " in this application means "or". For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. "At least one" refers to one or more. "More than one" refers to two or more. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, and a, b, and c. Where there is no conflict, the following embodiments and features described herein can be combined with each other.

[0027] See Figure 1 The diagram shown is a schematic of an open system architecture for automobiles provided in an embodiment of this application. In the field of automotive electronics, with the widespread application of open system architectures, their role in automotive development is becoming increasingly important. In the AUTOSAR architecture, the RTE (Real-Time Interface) sits between the application layer and the basic software layer. It is the implementation of the AUTOSAR Virtual Function Bus (VFB) interface, providing infrastructure services for communication between application software (ASW) and facilitating access to basic software (BSW) components, including the operating system (OS). The accuracy and efficiency of RTE interface testing have become key factors affecting the development quality of in-vehicle systems.

[0028] RTE interface testing in related technologies often relies on manual configuration and debugging using configuration tools, debuggers, and bus tools. The entire process, from test code generation to result analysis, requires significant manual intervention, resulting in a large workload, high maintenance costs, and incomplete coverage. Furthermore, as domain controller integration increases, a single system may contain more and more RTE interfaces, leading to higher system loads. Consequently, existing RTE interface testing methods are unable to efficiently identify, locate, and resolve problems.

[0029] In the RTE interface testing of related technologies, the ability to test interface type differences is insufficient. Related technologies do not design differentiated test logic for the communication characteristics of the client-server (CS) interface and the sender-receiver (SR) interface. For the CS interface, a complete "request-response" communication verification mechanism has not been built, making it difficult to effectively identify potential problems such as function call anomalies or response timeouts, resulting in insufficient verification of the availability and correctness of the interface service. For the SR interface, only regular data transmission scenarios are verified, and no specific injection tests are designed for data boundary values ​​(such as maximum, minimum, and average values), making it difficult to comprehensively assess the stability of the interface under extreme data scenarios, and posing a risk of missed detections of data out-of-bounds errors or processing logic defects.

[0030] In RTE interface testing of related technologies, a closed-loop automated testing process is lacking. The testing process relies on manual configuration and debugging, requiring significant manual intervention throughout the entire process from interface information acquisition, test code generation, interface test execution to test result analysis. For a large number of RTE interfaces, the testing workload is enormous, consuming substantial human resources, and test script errors are easily caused by human error. Furthermore, the related technologies lack automated closed-loop capabilities from code generation, compilation and flashing, interface testing to test report generation, failing to meet the rapid iterative development pace of automotive electronics.

[0031] In RTE interface testing of related technologies, there is an imbalance between resource consumption and execution efficiency. Most RTE interface testing schemes employ a loop-based approach to execute test code, continuously consuming the storage and processing resources of the vehicle's ECU, leading to excessive load on the tested system and even affecting normal functionality. Simultaneously, the lack of a single-execution control mechanism for test logic, such as the absence of flag management for multi-round boundary value testing of the SR interface, results in repetitive execution and resource waste. This inefficient testing method is particularly unsuitable for resource-constrained embedded environments with high performance and real-time requirements. Therefore, improving the efficiency of RTE interface testing, enhancing the maintainability of testing methods, increasing test coverage, and reducing system load have become urgent problems to be solved in the automotive electronics field.

[0032] To address the above issues, this application provides an interface testing method that can generate corresponding test functions based on the interface type of the RTE interface. Then, by combining configuration files, interface information, the source code of the RTE interface, and the test functions, test code is automatically generated. By executing the test code, the test results of the RTE interface can be directly obtained. This eliminates the need for manual configuration and debugging using configuration tools, debuggers, or bus tools, effectively improving the testing efficiency of the RTE interface and reducing human error, thereby increasing the accuracy of the RTE interface test results.

[0033] See Figure 2 The diagram shown is a flowchart of an interface testing method provided in an embodiment of this application. The interface testing method is applied to an electronic device, and the method includes: S101 parses the configuration file of the automotive open system architecture to obtain the interface information of the runtime environment RTE interface.

[0034] In one embodiment of this application, a configuration file for an automotive open system architecture is obtained, which is an ARXML file. An ARXML file is a standardized configuration file for an automotive open system architecture in XML format, used to describe the software architecture, communication configuration, resource allocation, and functional behavior of an automotive electronic control unit (ECU).

[0035] In one embodiment of this application, the configuration file is parsed to extract the interface information of the RTE interface. This interface information includes, but is not limited to: interface identifier, interface type, mapping relationship between the require port (R port) and the provide port (P port), and data structure. For example, the interface identifier is an interface number used to distinguish different RTE interfaces. Interface types include client-server (CS) interfaces and sender-receiver (SR) interfaces. The CS interface works by initiating an operation call from the client to the server based on a service request, and the server returns the result after execution. The SR interface works by broadcasting data; the sender pushes data, and the receiver receives the data. The R port (require port) is used to request data or services and is the initiator of communication. The P port (provide port) is used to provide data or services and is the responder of communication.

[0036] In one embodiment of this application, a mapping report can also be generated based on the interface information of the RTE interface to record the correspondence between various data in the interface information. For example, each interface identifier corresponds to an interface type and the mapping relationship and data structure between the demand type R port and the supply type P port, providing a structured data foundation for test code generation.

[0037] Obtaining RTE interface information and mapping relationships by parsing ARXML is the foundation for subsequent differentiated testing, ensuring that the test logic matches the interface type.

[0038] S102, Generate test functions based on the interface type of the RTE interface.

[0039] In one embodiment of this application, the test function can verify whether the RTE interface transmits data or calls services as expected by simulating input and output behavior, or actively inject boundary values, abnormal values ​​or illegal operations to verify the robustness of the RTE interface, or verify whether the RTE interface meets the real-time requirements by measuring key indicators.

[0040] In one embodiment of this application, if the interface type is a CS interface, test parameters for the CS interface are set. The test parameters for the CS interface include a calibration value and an observation value. The calibration value is a control variable used to control the call to the R-end and determine whether the R-end interface call is triggered. The calibration value is modified simultaneously with the R-end interface call. The calibration value is configured as a global state variable, and its value is either a first preset value or a second preset value. For example, the first preset value is 0, and the second preset value is 1. In the initial state, the calibration value is 0, indicating a non-triggered state, i.e., the R-end interface call has not been triggered. If the calibration value is 1, it indicates a triggered state, i.e., the R-end interface call has been triggered.

[0041] Observations are used to record the response results of the P-side to the request, verifying whether the "request-response" communication is complete. When the Runnable entity on the P-side is triggered, the observations are modified according to the calibrated state of the CS interface. Observations are configured as global result variables, and the values ​​of the observations are either a first preset value or a second preset value. Initially, an observation is 0, indicating a failure state; if an observation is 1, it indicates a success state, indicating that the "request-response" communication verification is successful.

[0042] In one embodiment of this application, an interface call function for the required port in the CS interface is generated based on the calibrated quantity, an interface response function for the supplied port in the CS interface is generated based on the observation, and a test function for the CS interface is generated based on the interface call function and the interface response function.

[0043] This application's embodiment designs a "request-response" closed-loop verification mechanism for the CS interface, which solves the problem of missed detection of abnormal request communication through calibrated triggering and observation verification.

[0044] In one embodiment of this application, if the interface type is a sender-receiver (SR) interface, test parameters for the SR interface are set. These test parameters control the boundary value testing of the SR interface. The boundary value is the boundary of the data transmitted by the SR interface; for example, the boundary value can be a minimum value, an average value, a maximum value, etc. The test parameters for the SR interface include at least one of the following: a state machine, an interface parameter value group, a flag group, an observation group, a read value variable, and a write value variable.

[0045] In one embodiment of this application, a state machine is used to control the boundary value injection order, for example, the boundary value injection order is minimum value, average value, and maximum value. The state machine is configured as a global variable, defining the state sequence "minimum value, average value, maximum value". The state machine has three configuration values, each corresponding to one of the three boundary values. For example, the first configuration value corresponding to the minimum value is 0, the second configuration value corresponding to the average value is 127, and the third configuration value corresponding to the maximum value is 255.

[0046] The interface parameter value group configures independent interface parameter values ​​for each boundary value state, setting them to the minimum, average, and maximum values ​​corresponding to the SR interface parameter type, and is used for boundary value injection of write-value variables for different SR interfaces.

[0047] Each boundary value state is configured with an independent global flag, including a minimum value flag, an average value flag, and a maximum value flag. The flag state determines whether to execute the corresponding boundary value test, ensuring single-execution. The flag for each boundary value in the flag group is either a first preset value or a second preset value. For example, the first preset value is 0, and the second preset value is 1. Initially, the flag for each boundary value is 0, indicating a non-triggered state, meaning the corresponding boundary value test has not been triggered. If the flag for a boundary value is 1, it indicates a triggered state, meaning the corresponding boundary value test has been triggered.

[0048] The observation group configures independent global result variables for each boundary value state, including minimum, average, and maximum value observations. Each boundary value observation is used to identify whether the communication for the corresponding boundary value was successful. Each boundary value observation in the observation group is a first preset value, a second preset value, or a third preset value. For example, the first preset value is 0, the second preset value is 1, and the third preset value is 2. Initially, each boundary value observation is 0, indicating an unverified state, meaning the corresponding boundary value test was not executed. If the boundary value observation is 1, it indicates a successful state, meaning the corresponding boundary value test passed. If the boundary value observation is 2, it indicates a failed state, meaning the corresponding boundary value test failed.

[0049] The read-value variable and write-value variable are configured as global variables with an initial value of 0. The read-value variable is used to store the boundary value injected by the P end, and the write-value variable is used to store the real-time value read by the R end.

[0050] In one embodiment of this application, a test function for the SR interface is generated based on the test parameters of the SR interface. This embodiment constructs a boundary value state machine, boundary value code injection, and flag control logic for the SR interface, covering extreme data scenario testing. This addresses the problem of insufficient communication reliability verification under extreme data scenarios and mitigates the risk of missed tests due to data out-of-bounds errors or processing logic defects.

[0051] S103 generates test code based on configuration files, interface information, the source code of the RTE interface, and test functions.

[0052] In one embodiment of this application, test code is automatically generated based on the automotive open system architecture configuration file, interface information parsed from the configuration file, RTE interface source code, and test functions.

[0053] See Figure 3 The diagram shown is a flowchart of generating test code according to an embodiment of this application.

[0054] S1031 verifies interface information based on configuration files.

[0055] In one embodiment of this application, interface information is verified based on a configuration file to determine its validity. If the parsed interface information matches the interface information in the configuration file, the parsed interface information is deemed valid; otherwise, if any parsed interface information differs from the corresponding interface information in the configuration file, the parsed interface information is deemed invalid. If the parsed interface information is invalid, the configuration file for the automotive open system architecture is re-parsed.

[0056] S1032, If the interface information verification is successful, determine the positions of the port functions on the R side and the port functions on the P side in the source code based on the interface identifier and mapping relationship.

[0057] In one embodiment of this application, the corresponding interface code is determined in the source code based on the interface identifier, and the positions of the port functions of the R end and the P end are determined in the interface code corresponding to the interface identifier based on the mapping relationship between the R end and the P end.

[0058] S1033, write the test function corresponding to the interface type of the interface identifier into this location to obtain the test code.

[0059] In one embodiment of this application, the interface type corresponding to the interface identifier is determined, and the test function of the interface type is written into the port function of the R end and the port function of the P end corresponding to the interface identifier to generate test code.

[0060] S104, execute the test code and obtain the test results of the RTE interface.

[0061] In one embodiment of this application, the generated test code is automatically compiled and burned to the vehicle controller using a toolchain. For example, the toolchain is the GHS (Green Hills Software) toolchain. The vehicle controller runs the software execution code, starts the software under test (SDK), and automatically executes the RTE interface test code, enabling communication between the RTE interfaces of the SDK. A state machine controls the boundary value injection order of the SR interface to complete the RTE interface test. During the RTE interface test, the test framework continuously monitors and records the calibrated values ​​and observations of the CS interface, and the boundary value observations of the SR interface, until all interface tests are completed.

[0062] See Figure 4 The diagram shown is a flowchart for determining the test results of the CS interface according to an embodiment of this application.

[0063] S201, when the calibration quantity indicates that the state has not been triggered, the request is processed by calling the P end through the R end, and the calibration quantity is updated to indicate that the state has been triggered.

[0064] In one embodiment of this application, if the calibrator value is 0, it indicates a non-triggered state, indicating that the R-end call has not been triggered. When the CS interface receives a request, it processes the request by calling the P-end through the R-end and updates the calibrator value to 1, indicating a triggered state, indicating that the R-end call has been triggered.

[0065] S202, if the calibrated quantity is updated to indicate that the state has been triggered, update the observation quantity according to the response result of the P end to the request.

[0066] In one embodiment of this application, if the response result of the P terminal to the request is that the request processing is successful, the observation is updated to 1 to indicate a successful state; if the response result of the P terminal to the request is that the request processing fails, the observation is kept at 0 to indicate a failed state.

[0067] S203, based on the calibrated quantity and the observed quantity, determine the test results of the CS interface.

[0068] In one embodiment of this application, if the calibrator value is 0, it indicates a non-triggered state, and it is determined that the CS interface has not been tested. If the calibrator value is 1, it indicates a triggered state, and if the observation value is 0, it indicates a failed state, and it is determined that the CS interface communication is abnormal. If the calibrator value is 1, it indicates a triggered state, and if the observation value is 1, it indicates a successful state, and it is determined that the CS interface communication is normal.

[0069] See Figure 5The diagram shown is a flowchart for determining the test results of the SR interface according to an embodiment of this application.

[0070] S301: For any boundary value in the test code, if the state machine value matches any boundary value and the flag corresponding to any boundary value indicates that the state has not been triggered, write any boundary value in the interface parameters to the write-value variable.

[0071] Taking the minimum value as an example, if the state machine value is the first configuration value 0, indicating the minimum value test state, and the minimum value flag is 0, indicating the non-triggered state, then the minimum value in the interface parameter group is written to the write variable. For example, the minimum value is the minimum voltage of 5V.

[0072] S302 publishes any boundary value to the automotive open system architecture bus via the P terminal, and updates the flag bit corresponding to any boundary value to indicate that the trigger status has been triggered.

[0073] For example, the P-side is Rte_Write or Rte_Send in the RTE interface. The minimum value flag is updated to 1 to indicate that the state has been triggered, preventing repeated injection of boundary values.

[0074] S303, if the flag bit corresponding to any boundary value is updated to indicate a triggered state, and the observation value corresponding to any boundary value is not verified, the data of the automotive open system architecture bus is read through the R terminal, and the read data is written to the read value variable.

[0075] In one embodiment of this application, when the minimum value flag is updated to indicate a triggered state, if the minimum value observation is 0, indicating an unverified state, bus data is read through the R terminal, and the read data is written to the read value variable. For example, the R terminal is Rte_Read or Rte_Receive in the RTE interface.

[0076] S304 compares the read value variable with the write value variable, and updates the observation corresponding to any boundary value based on the comparison result.

[0077] In one embodiment of this application, if the comparison result between the read value variable and the write value variable is that the read value variable and the write value variable are the same, then the minimum observation value is updated to 1 to indicate a success status. If the comparison result between the read value variable and the write value variable is that the read value variable and the write value variable are different, then the minimum observation value is updated to 2 to indicate a failure status.

[0078] S305, after all boundary value tests are completed, the test results of the SR interface are determined based on the state machine, flag group, and observation group.

[0079] In one embodiment of this application, the minimum value test, average value test and maximum value test are performed sequentially according to the boundary value injection order defined by the state machine. After the minimum value test, average value test and maximum value test are completed, all boundary value tests are completed. The test results of the SR interface are determined according to the state machine, the flag bit group and the observation group.

[0080] In one embodiment of this application, if the state machine value remains unchanged, for example, it is still the first configuration value corresponding to the minimum value, or all flag bits in the flag group are 0, indicating a non-triggered state, it is determined that the SR interface has not been tested. If any boundary value observation in the observation group is 2, indicating a failure state, it is determined that the boundary value test of the SR interface is unqualified. If all boundary value observations in the observation group are 1, indicating a success state, it is determined that the boundary value test of the SR interface is qualified.

[0081] By binding the analysis test results with information such as interface number, interface type (CS / SR), and parameter definition in the mapping report, the system can automatically complete the test result judgment and anomaly location for tens of thousands of interfaces without manual intervention, forming a traceability chain of "interface number - test result - parameter configuration".

[0082] This application implements differentiated testing strategies for the CS and SR interfaces, significantly optimizing their test coverage. Automated testing processes significantly improve testing efficiency and reduce test errors caused by human error. Single-execution control and dynamic resource release mechanisms, along with scalar values ​​and flags, ensure that interface test logic is executed only once, avoiding interference from traditional loop testing on real-time tasks and improving the stability of the embedded system. This achieves resource optimization in the embedded environment.

[0083] See Figure 6 The diagram shown is a structural schematic of an interface testing apparatus provided in one embodiment of this application. In one embodiment of this application, the interface testing apparatus 200 is applied in an electronic device and may include multiple functional modules composed of computer program segments. The computer program segments in the interface testing apparatus 200 may be stored in the memory of the electronic device and executed by at least one processor to perform interface testing functions.

[0084] In one embodiment of this application, the interface testing device 200 can be divided into multiple functional modules according to the functions it performs. The functional modules of the interface testing device 200 may include: a parsing module 201, a generation module 202, and a testing module 203. In this embodiment, a module refers to a series of computer program segments that can be executed by at least one processor and perform a fixed function, and which are stored in memory.

[0085] The parsing module 201 is used to parse the configuration file of the automotive open system architecture to obtain the interface information of the runtime environment RTE interface.

[0086] The generation module 202 is used to generate test functions based on the interface type of the RTE interface.

[0087] The generation module 202 is also used to generate test code based on configuration files, interface information, source code of the RTE interface, and test functions.

[0088] Test module 203 is used to execute test code and obtain test results for the RTE interface.

[0089] See Figure 7 The diagram shown is a hardware structure schematic of an electronic device provided in an embodiment of this application. Figure 2 The interface testing method provided in the illustrated embodiment is applied to electronic device 1. Electronic device 1 can be a vehicle or other device that can be configured with an on-board controller to test the RTE interface in the on-board controller, such as a personal computer, server, etc. Electronic device 1 includes, but is not limited to, a processor 110 and a memory 120 connected via a communication bus 130. Figure 7 This is merely an example of an electronic device and does not constitute a limitation thereof. In other embodiments, the electronic device may include more components than those shown in the figure.

[0090] The aforementioned memory may include one or more Random Access Memory (RAM) and one or more Non-Volatile Memory (NVM). RAM can be directly read and written by the processor and can be used to store executable programs (such as machine instructions) of the operating system or other running programs, as well as user and application data. RAM may include Static Random-Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), etc.

[0091] Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into random access memory for direct read and write operations by the processor. Non-volatile memory can include disk storage devices and flash memory.

[0092] The memory is used to store one or more computer programs. These one or more computer programs are configured to be executed by a processor. The one or more computer programs include multiple instructions that, when executed by the processor, enable interface testing methods to be executed on an electronic device.

[0093] In other embodiments, the electronic device further includes an external memory interface for connecting to an external memory to expand storage capacity.

[0094] A processor may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0095] The processor provides computing and control capabilities; for example, the processor is used to execute computer programs stored in memory to implement the interface testing methods described above.

[0096] A communication bus is used at least to provide a channel for communication between memory and processor.

[0097] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0098] This application also provides a computer storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the interface testing method in the above embodiments.

[0099] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the interface testing method described in the above embodiments.

[0100] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component or module. The apparatus may include a connected processor and a memory; wherein the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the interface testing methods in the above method embodiments.

[0101] In this application, the electronic devices, computer storage media, computer program products or chips provided in the embodiments are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0102] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0104] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0105] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0106] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts or all or part of the technical solutions that contribute to the prior art, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0107] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. An interface testing method, characterized in that, The method includes: Parse the configuration file of the automotive open system architecture to obtain the interface information of the runtime environment RTE interface; Generate a test function based on the interface type of the RTE interface; Based on the configuration file, the interface information, the source code of the RTE interface, and the test function, test code is generated; Execute the test code to obtain the test results of the RTE interface.

2. The interface testing method according to claim 1, characterized in that, The step of generating a test function based on the interface type of the RTE interface includes: If the interface type is a client-server (CS) interface, an interface call function for the required port in the CS interface is generated according to the calibration value, and the calibration value is used to control the call of the required port; Based on the observations, an interface response function for the feed port in the CS interface is generated, and the observations are used to record the response results of the CS interface; Based on the interface call function and the interface response function, a test function for the CS interface is generated.

3. The interface testing method according to claim 2, characterized in that, The execution of the test code to obtain the test results of the RTE interface includes: In the case where the calibration quantity indicates that the state has not been triggered, the demand port calls the supply port to process the request and update the calibration quantity to indicate that the state has been triggered. When the calibrated quantity is updated to indicate a triggered state, the observation is updated according to the response of the supply port to the request; The test results of the CS interface are determined based on the calibrated values ​​and the observed values.

4. The interface testing method according to claim 3, characterized in that, Determining the test results of the CS interface based on the calibrated quantity and the observed quantity includes: If the calibration indicator is not triggered, it is determined that the CS interface has not been tested; If the calibration quantity indication is in a triggered state and the observation quantity indication is in a failed state, it is determined that the CS interface communication is abnormal; If the calibration quantity indication is triggered and the observation quantity indication is successful, it is determined that the CS interface communication is normal.

5. The interface testing method according to claim 1, characterized in that, The step of generating a test function based on the interface type of the RTE interface includes: If the interface type is a sender-receiver (SR) interface, set the test parameters of the SR interface. The test parameters are used to control the boundary value test of the SR interface. Generate the test function for the SR interface based on the test parameters.

6. The interface testing method according to claim 5, characterized in that, The test parameters include at least one of the following: state machine, interface parameter value group, flag bit group, observation group, read value variable, and write value variable. Running the test code to obtain the test results of the RTE interface includes: For any boundary value in the test code, if the state machine value corresponding to any boundary value matches the boundary value and the flag bit corresponding to the boundary value indicates a non-triggered state, then write the boundary value in the interface parameter value group into the write variable. The boundary value is published to the automotive open system architecture bus through the feed port, and the flag bit corresponding to the boundary value is updated to indicate that the trigger status has been triggered. If the flag corresponding to any boundary value is updated to indicate a triggered state, and the observation corresponding to any boundary value indicates an unverified state, the data of the automotive open system architecture bus is read through the required port, and the read data is written into the read value variable. The read value variable is compared with the write value variable, and the observation corresponding to any boundary value is updated based on the comparison result. After all boundary value tests are completed, the test results of the SR interface are determined based on the state machine, the flag group, and the observation group.

7. The interface testing method according to claim 6, characterized in that, The step of determining the test result of the SR interface based on the state machine, the flag group, and the observation group includes: If the state machine value does not change or all flag bits in the flag group indicate a non-triggered state, it is determined that the SR interface has not been tested. If any boundary value in the observation group indicates a failure status, the boundary value test of the SR interface is determined to be unqualified. If all boundary values ​​in the observation group indicate a successful status, the boundary value test of the SR interface is deemed qualified.

8. The interface testing method according to any one of claims 1, 2, and 5, characterized in that, The interface information includes the interface identifier, interface type, and mapping relationship between the required and supplied ports of the RTE interface. The generation of test code based on the configuration file, the interface information, the source code of the RTE interface, and the test function includes: The interface information is verified based on the configuration file. If the interface information is verified as qualified, the positions of the port function of the required port and the port function of the supplied port in the source code are determined according to the interface identifier and the mapping relationship; Write the test function corresponding to the interface type of the interface identifier into the specified location to obtain the test code.

9. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the interface testing method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the interface testing method as described in any one of claims 1 to 8.

Images