Differential OTA upgrading incremental test regression method and system and electronic equipment

Abstract

The invention discloses an incremental test regression method and system for differential OTA upgrade and electronic equipment, and relates to the field of vehicle tests.The method comprises the steps that a multi-dimensional data fusion knowledge base is obtained, the knowledge base comprises a full-amount use case associated data and code relation dependency graph, and whether a differential OTA upgrade package meets the upgrade requirement or not is judged; if yes, the differential OTA upgrade package is input into a change influence analysis engine, and an influence range list is obtained; obtaining an incremental test case screening engine; inputting the influence range list into an incremental test case screening engine, and screening out a minimum necessary regression test case set; executing the minimum necessary regression test case set to obtain a test result; judging whether execution passes or not according to a test result; if not, analyzing the test result; the analysis of the test result comprises the steps of judging whether missing test exists in the test result; if yes, analyzing reasons, and updating the knowledge base and the change influence analysis engine; and outputting a test report.

Description

Technical Field

[0001] This application relates to the field of vehicle testing, and in particular to an incremental test regression method for differential OTA upgrades, an incremental test regression system for differential OTA upgrades, electronic devices, and storage media. Background Technology

[0002] Modern in-vehicle infotainment software is quite complex. Differential OTA upgrades rely on full-case regression testing for test scenario coverage, resulting in a test case library containing thousands or tens of thousands of test cases. Each upgrade requires significant manpower, leading to time-consuming and labor-intensive processes and low testing efficiency. Secondly, the impact analysis of code changes after differential OTA upgrades is inaccurate. Manual analysis of code changes can lead to inaccurate assessments of the test scope's impact, easily resulting in omissions or incomplete test case coverage, leading to either missed tests or the inclusion of numerous unaffected test cases, resulting in over-coverage. Finally, because the testing environment depends on the actual vehicle or certain hardware, inefficient testing strategies result in constantly occupied and strained testing resources. Therefore, a more precise testing strategy is needed to address the issues of low testing efficiency, inaccurate test scope assessment, and limited testing resources.

[0003] For example, the Chinese patent, entitled "Test Method, Apparatus, Electronic Device and Vehicle for Differential Upgrade of Domain Controller", application number: CN119472572A, verifies the hash digest of the differential packet in the OTA system to ensure that it is consistent with the original full packet, thus solving the problem of insufficient differential packet verification in the prior art and improving the reliability of the OTA system and user experience.

[0004] For example, the Chinese patent, titled "A Method and System for OTA Wireless Testing of Production Lines," application number CN117793234A, describes a method that imports OTA differential packets into terminal devices via OTA wireless testing, automatically upgrades and executes test items. This method primarily solves the problems of long testing times and high costs for terminal devices in existing technologies, achieving efficient testing and troubleshooting. Summary of the Invention

[0005] The purpose of this invention is to provide an incremental test regression method, an incremental test regression system, an electronic device, and a storage medium for differential OTA upgrades. It aims to solve the problems of time-consuming and labor-intensive testing and low testing efficiency caused by full test case regression during differential OTA upgrades; the problems of inaccurate manual evaluation of code change analysis leading to incomplete evaluation of test case coverage and easy omission of test cases; and the problem of scarce test resources.

[0006] This invention provides the following solution:

[0007] According to one aspect of the present invention, an incremental test regression method for differential OTA upgrades is provided, comprising the following steps:

[0008] A knowledge base for multi-dimensional data fusion is obtained, the knowledge base including: a dependency graph of full use case association data and code relationship;

[0009] Based on the knowledge base, determine whether the differential OTA upgrade package meets the upgrade requirements;

[0010] If the conditions are met, the differential OTA upgrade package is input into the change impact analysis engine to obtain a list of impact ranges.

[0011] Get the incremental test case filtering engine;

[0012] Input the list of impact ranges into the incremental test case filtering engine to filter out the minimum necessary regression test case set;

[0013] Execute the minimum necessary regression test case set and obtain the test results;

[0014] Determine whether the execution succeeds based on the test results;

[0015] If the test is passed, the test result is recorded and the knowledge base is updated.

[0016] If the test fails, the analysis will be based on the test results.

[0017] The analysis of the test results includes: determining whether there are any missed tests in the test results;

[0018] If so, analyze the cause and update the knowledge base and the change impact analysis engine;

[0019] Output the test report.

[0020] Furthermore, including:

[0021] Multidimensional data includes: all test cases and test case coverage and related information;

[0022] Furthermore, including:

[0023] The specific coverage association information for the test cases is as follows:

[0024] After executing all test cases through code instrumentation, the coverage objects corresponding to each test case are recorded;

[0025] This includes: the specific functions of the vehicle infotainment system covered by the test cases; and the code entities covered by the test cases.

[0026] The test cases cover the vehicle infotainment interface and vehicle-specific communication signals;

[0027] The vehicle infotainment system configuration entities covered by the test cases.

[0028] Furthermore, including:

[0029] Determining whether a differential OTA upgrade package meets the upgrade requirements includes:

[0030] Verify the code integrity of the differential OTA upgrade package and confirm that the code changes it contains can match the modules and interfaces in the code relationship dependency graph in the knowledge base;

[0031] Verify the compatibility between the differential OTA upgrade package and the vehicle system configuration entities in the knowledge base to ensure that the configuration changes involved in the upgrade package do not exceed the vehicle system configuration adaptation range recorded in the knowledge base;

[0032] If both of the above checks pass, the differential OTA upgrade package is deemed to meet the upgrade requirements; if either check fails, it is deemed not to meet the requirements, the subsequent process is terminated, and a check failure report is output.

[0033] Furthermore, including:

[0034] The list of impact areas is obtained by: the change impact analysis engine performs static analysis on the differential OTA upgrade package, parses out the direct code change points, the direct code change points include modified files, functions and classes, and traces the indirect dependencies corresponding to the direct code change points, the indirect dependencies cover the modules, interfaces, vehicle-specific communication signals and configuration entities that are depended on;

[0035] The change impact analysis engine correlates the parsed code change points with the requirement data and historical defect data in the knowledge base to locate the requirement items affected by the code change and potential defect recurrence points;

[0036] The change impact analysis engine calls a machine learning model trained on historical test data from the knowledge base to predict high-risk impact areas that may be missed by static analysis. These high-risk impact areas include modules with functional safety level ≥ ASIL-B and the vehicle infotainment core module, and assign a risk score to each affected object.

[0037] By integrating the above analysis results, a list of the impact ranges is generated, which includes affected modules, interfaces, vehicle-specific communication signals, configuration entities, requirement items, defect recurrence points, and corresponding risk scores.

[0038] Furthermore, including:

[0039] The incremental test case filtering engine loads a predefined rule base, which includes basic coverage rules, risk enhancement rules, and optimization and constraint rules.

[0040] Based on the basic coverage rules, test cases are selected from the full set of test cases in the knowledge base to cover the direct code change points, strong dependencies of the direct change points, vehicle interface and configuration entities within the scope of impact list;

[0041] Based on risk enhancement rules, test cases are selected to cover high-risk impact areas within the scope of impact list.

[0042] Based on optimization and constraint rules, the selected test cases are deduplicated, and the total number of test cases is controlled to ensure that the test case set is minimized, ultimately forming the minimum necessary regression test case set.

[0043] Furthermore, including:

[0044] If any omissions are found, the reasons will be analyzed, and the knowledge base and the change impact analysis engine will be updated, specifically including:

[0045] The reasons for missed tests include incomplete code relationship dependency graphs in the knowledge base, prediction biases in the machine learning model of the change impact analysis engine, and missing test cases in the knowledge base.

[0046] If the reason for the missed test is that the code relationship dependency graph is incomplete, then the module dependency relationship, interface dependency relationship or vehicle-specific communication signal dependency relationship corresponding to the missed test scenario should be added to the knowledge base.

[0047] If the reason for the missed test is the lack of test cases, then add test cases that cover the missed test scenario and the corresponding coverage information to the knowledge base;

[0048] If the reason for the missed detection is the prediction bias of the machine learning model, then the missed case is used as new training data to input into the machine learning model of the change impact analysis engine, the model is retrained to optimize the prediction accuracy, and the update of the change impact analysis engine is completed.

[0049] According to a second aspect of the present invention, an incremental test regression system for differential OTA upgrades is provided, comprising:

[0050] The module includes a knowledge base module, an upgrade package verification module, a change impact analysis module, an incremental test case filtering module, a test execution module, and a report output module.

[0051] The knowledge base module is used to acquire a knowledge base of multi-dimensional data fusion, which includes: full set of use case association data and code relationship dependency graph;

[0052] The upgrade package verification module is used to determine whether the differential OTA upgrade package meets the upgrade requirements based on the knowledge base.

[0053] The change impact analysis module is used to input the differential OTA upgrade package into the change impact analysis engine to obtain a list of impact ranges;

[0054] The incremental test case filtering module is used to obtain the incremental test case filtering engine;

[0055] Input the list of impact ranges into the incremental test case filtering engine to filter out the minimum necessary regression test case set;

[0056] The test execution module is used to execute the minimum necessary regression test case set and obtain the test results;

[0057] Determine whether the execution succeeds based on the test results;

[0058] If the test is passed, the test result is recorded and the knowledge base is updated.

[0059] If the test fails, the analysis will be based on the test results.

[0060] The report output module is used to analyze the test results, including determining whether there are any missed tests in the test results;

[0061] If so, analyze the cause and update the knowledge base and the change impact analysis engine;

[0062] Output the test report.

[0063] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0064] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps of an incremental test regression method based on differential OTA upgrades.

[0065] According to four aspects of the present invention, a computer-readable storage medium is provided that stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform steps of an incremental test regression method based on differential OTA upgrade.

[0066] Compared with the prior art, the present invention has the following advantages:

[0067] This application establishes a knowledge base and combines a code change analysis engine, an incremental test case filtering engine, and closed-loop feedback to filter out the smallest set of incremental test cases through a single system operation. This can greatly improve testing efficiency, increase the accuracy of code change analysis, and alleviate the problem of test resource shortages. Attached Figure Description

[0068] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0069] Figure 1 This is a flowchart of an incremental test regression method for differential OTA upgrades provided by one or more embodiments of the present invention.

[0070] Figure 2 This is a structural diagram of an incremental test regression system for differential OTA upgrades provided in one or more embodiments of the present invention.

[0071] Figure 3 This is an overall flowchart of an incremental test regression system for differential OTA upgrades according to a specific embodiment of the present invention.

[0072] Figure 4 This is a flowchart of a change impact analysis engine according to a specific embodiment of the present invention.

[0073] Figure 5 This is a flowchart of an incremental test case filtering engine according to a specific embodiment of the present invention.

[0074] Figure 6 This is a block diagram of an electronic device structure that provides an incremental test regression method for differential OTA upgrades according to one or more embodiments of the present invention. Detailed Implementation

[0075] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. 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.

[0076] Figure 1 This is a flowchart of an incremental test regression method for differential OTA upgrades provided by one or more embodiments of the present invention.

[0077] like Figure 1 As shown, it includes the following steps:

[0078] Step S1: Obtain a knowledge base for multi-dimensional data fusion, the knowledge base including: full set of use case association data and code relationship dependency graph;

[0079] Specifically, a knowledge base integrating multi-dimensional data is established, a code relationship dependency graph is built, and the functional points, code modules, interface configuration items, etc. covered by each test case are recorded.

[0080] First, a complete set of test cases was compiled. By instrumenting the code, each test case was executed, and the functionalities, code modules, APIs, configuration items, signals, etc., covered by each test case were recorded. After analysis, the covered code modules, including modules, interfaces, signals, and configurations, were associated to establish a code relationship dependency graph. This includes function and class call relationships, interface dependencies between modules, and vehicle-specific dependencies such as ECU communication signal dependencies (CAN / LIN / Ethernet signal interaction), service dependencies in service-oriented architecture (SOA), and configuration file dependencies (which modules read which configuration files). These connections were established to form the necessary knowledge base.

[0081] Step S2: Based on the knowledge base, determine whether the differential OTA upgrade package meets the upgrade requirements;

[0082] If the conditions are met, the differential OTA upgrade package is input into the change impact analysis engine to obtain a list of impact ranges.

[0083] Specifically, once the knowledge base is established, the process starting point will be set to the availability of the new differential OTA upgrade package.

[0084] The process for inputting the OTA (Over-The-Air) differential package, i.e., the code change set, is as follows: First, static analysis is performed to parse the code changes in the differential package, identifying direct changes and indirect dependencies, including code modules, interfaces, configurations, and signals. Second, requirements, defects, and test cases are correlated, linking the code changes in the differential package with requirements and defects to analyze the affected requirements and defects. Finally, machine learning (ML) prediction is used, employing a model trained on historical data to predict and identify high-risk impact areas that may have been missed by the static analysis, providing corresponding confidence levels. The output is a relatively accurate list of impact areas with risk scores, including affected modules, interfaces, signals, services, configurations, requirements, and potential defect recurrence points.

[0085] The change impact analysis engine generates a relatively accurate list of the affected areas, including the affected modules, interfaces, signals, configurations, etc.

[0086] Step S3: Obtain the incremental test case filtering engine;

[0087] Input the list of impact ranges into the incremental test case filtering engine to filter out the minimum necessary regression test case set;

[0088] Specifically, the impact range list serves as input to the incremental test case filtering engine. Based on the impact range and a series of filtering rules, it filters out the minimum necessary regression test set of the affected test cases from the full test case library.

[0089] The input is a list of affected areas, and the filtering process selects the minimum necessary set of test cases based on predefined rules in the rule engine. First, the rules in the rule base are defined, including basic coverage rules (strong dependency scenarios, generally mandatory), risk enhancement rules (weak correlation scenarios, selective selection), and optimization and constraint rules (controlling the size and number of sets). The corresponding rules are described below: 1. Basic Coverage Rules: Rule A covers direct modification points: If the affected area list contains directly modified code entities (file_A, function_B, class_C), then: test cases covering file_A, function_B, and class_C are selected from the knowledge base. The purpose is to ensure that the directly modified code can be directly tested. Rule B: Covering Directly Affected Items - Strong Dependencies: If the list of affected areas contains code entities (Module_X, Interface_Y, Signal_Z) that are strongly dependent on the directly modified point, then test cases covering Module_X, Interface_Y, and Signal_Z are selected from the knowledge base. The purpose is to cover modules and interaction points coupled with the modified point, preventing interface contracts from being broken or signal processing errors from occurring. Rule C: Covering Affected Interfaces and Signals: If the list of affected areas contains affected interfaces and signals (Interface_Y, Signal_Z), then test cases covering Interface_Y and Signal_Z are selected from the knowledge base. The purpose is to ensure the stability and correctness of bus communication and prevent signal changes from causing vehicle function failures. Rule D: Affected Configuration Items: If the list of affected areas contains affected configuration entities (Config_ParamFile), all test cases that cover Config_ParamFile are selected from the knowledge base. Purpose: To verify whether configuration changes are correctly loaded and applied, preventing configuration errors from causing functional abnormalities. 2. Risk Enhancement Rule: Rule E (Coverage of Key Indirectly Impacted Items - Weak Dependency + High Risk): If: IF the code entity (Module_W) with indirect impact exists in the impact scope list AND (Module_W's Functional Safety Level (ASIL) >= ASIL-B) OR (Module_W is marked as a 'core module' in the knowledge base) OR (the confidence level of static analysis / ML prediction on Module_W > threshold_high), then select all test cases that cover Module_W from the knowledge base. Purpose: For modules that are indirectly dependent but safety-critical, core functionalities, or predicted to be high-risk, it is better to test more than to miss. Controlling the selection scope through condition combinations avoids overexpansion.Rule F (covers high-risk areas predicted by ML):

[0090] If the list of affected entities contains high-risk entities predicted by ML (Module_Risk, Signal_Risk) AND (predicted risk score > threshold_risk), then all covers are selected from the knowledge base.

[0091] Test cases for Module_Risk or Signal_Risk. Purpose: To use machine learning models to uncover potential risks that may be overlooked by static analysis and to conduct supplementary testing.

[0092] Step S4: Execute the minimum necessary regression test case set and obtain the test results;

[0093] Step S5: Determine whether the test passed based on the test results;

[0094] If the test is passed, the test result is recorded and the knowledge base is updated.

[0095] If the test fails, the analysis will be based on the test results.

[0096] Specifically, the selected test cases are executed, and it is determined whether the execution is successful. If the execution is successful, the result is recorded and the knowledge base is updated.

[0097] Step S6, analyzing the test results includes: determining whether there are any missed tests in the test results;

[0098] If so, analyze the cause and update the knowledge base and the change impact analysis engine;

[0099] Output the test report.

[0100] Specifically, if execution fails, the cause of the failure is analyzed to determine if it was due to a missed test. If so, the cause needs to be analyzed in depth (whether the dependency is correct, the model is inaccurate, or test cases are missing). Based on this analysis, the knowledge base (code dependency graph, test case library, etc.) is updated and the ML model is optimized. At this point, the closed-loop feedback learning is completed. Finally, the corresponding test report is output to provide a basis for OTA release decisions.

[0101] Specifically, the test results serve as input for the closed-loop feedback learning module. A key process is missed test analysis. First, it's necessary to check if failed test cases were included in the previously selected test set. If so, it indicates a problem with the change analysis or the test cases themselves. If not, it indicates missed tests, requiring in-depth analysis of the reasons, such as incomplete dependency graphs, blind spots in static analysis, inaccurate ML model predictions, or incomplete test case design coverage. After analyzing the causes, it's necessary to update the code dependency graph, mark high-risk areas, and add or update test case metadata. Secondly, the ML prediction model is updated, using the missed test cases as new training data to improve future prediction accuracy.

[0102] Furthermore, including:

[0103] Multidimensional data includes: all test cases and test case coverage and related information;

[0104] Furthermore, including:

[0105] The specific coverage association information for the test cases is as follows:

[0106] After executing all test cases through code instrumentation, the coverage objects corresponding to each test case are recorded;

[0107] This includes: the specific functions of the vehicle infotainment system covered by the test cases; and the code entities covered by the test cases.

[0108] The test cases cover the vehicle infotainment interface and vehicle-specific communication signals;

[0109] The vehicle infotainment system configuration entities covered by the test cases.

[0110] Furthermore, including:

[0111] Determining whether a differential OTA upgrade package meets the upgrade requirements includes:

[0112] Verify the code integrity of the differential OTA upgrade package and confirm that the code changes it contains can match the modules and interfaces in the code relationship dependency graph in the knowledge base;

[0113] Verify the compatibility between the differential OTA upgrade package and the vehicle system configuration entities in the knowledge base to ensure that the configuration changes involved in the upgrade package do not exceed the vehicle system configuration adaptation range recorded in the knowledge base;

[0114] If both of the above checks pass, the differential OTA upgrade package is deemed to meet the upgrade requirements; if either check fails, it is deemed not to meet the requirements, the subsequent process is terminated, and a check failure report is output.

[0115] Furthermore, including:

[0116] The list of impact areas is obtained by: the change impact analysis engine performs static analysis on the differential OTA upgrade package, parses out the direct code change points, the direct code change points include modified files, functions and classes, and traces the indirect dependencies corresponding to the direct code change points, the indirect dependencies cover the modules, interfaces, vehicle-specific communication signals and configuration entities that are depended on;

[0117] The change impact analysis engine correlates the parsed code change points with the requirement data and historical defect data in the knowledge base to locate the requirement items affected by the code change and potential defect recurrence points;

[0118] The change impact analysis engine calls a machine learning model trained on historical test data from the knowledge base to predict high-risk impact areas that may be missed by static analysis. These high-risk impact areas include modules with functional safety level ≥ ASIL-B and the vehicle infotainment core module, and assign a risk score to each affected object.

[0119] By integrating the above analysis results, a list of the impact ranges is generated, which includes affected modules, interfaces, vehicle-specific communication signals, configuration entities, requirement items, defect recurrence points, and corresponding risk scores.

[0120] Furthermore, including:

[0121] The incremental test case filtering engine loads a predefined rule base, which includes basic coverage rules, risk enhancement rules, and optimization and constraint rules.

[0122] Based on the basic coverage rules, test cases are selected from the full set of test cases in the knowledge base to cover the direct code change points, strong dependencies of the direct change points, vehicle interface and configuration entities within the scope of impact list;

[0123] Based on risk enhancement rules, test cases are selected to cover high-risk impact areas within the scope of impact list.

[0124] Based on optimization and constraint rules, the selected test cases are deduplicated, and the total number of test cases is controlled to ensure that the test case set is minimized, ultimately forming the minimum necessary regression test case set.

[0125] Furthermore, including:

[0126] If any omissions are found, the reasons will be analyzed, and the knowledge base and the change impact analysis engine will be updated, specifically including:

[0127] The reasons for missed tests include incomplete code relationship dependency graphs in the knowledge base, prediction biases in the machine learning model of the change impact analysis engine, and missing test cases in the knowledge base.

[0128] If the reason for the missed test is that the code relationship dependency graph is incomplete, then the module dependency relationship, interface dependency relationship or vehicle-specific communication signal dependency relationship corresponding to the missed test scenario should be added to the knowledge base.

[0129] If the reason for the missed test is the lack of test cases, then add test cases that cover the missed test scenario and the corresponding coverage information to the knowledge base;

[0130] If the reason for the missed detection is the prediction bias of the machine learning model, then the missed case is used as new training data to input into the machine learning model of the change impact analysis engine, the model is retrained to optimize the prediction accuracy, and the update of the change impact analysis engine is completed.

[0131] Figure 2 This is a structural diagram of an incremental test regression system for differential OTA upgrades provided in one or more embodiments of the present invention.

[0132] like Figure 2 As shown, it includes:

[0133] The module includes a knowledge base module, an upgrade package verification module, a change impact analysis module, an incremental test case filtering module, a test execution module, and a report output module.

[0134] The knowledge base module is used to acquire a knowledge base of multi-dimensional data fusion, which includes: full set of use case association data and code relationship dependency graph;

[0135] The upgrade package verification module is used to determine whether the differential OTA upgrade package meets the upgrade requirements based on the knowledge base.

[0136] The change impact analysis module is used to input the differential OTA upgrade package into the change impact analysis engine to obtain a list of impact ranges;

[0137] The incremental test case filtering module is used to obtain the incremental test case filtering engine;

[0138] Input the list of impact ranges into the incremental test case filtering engine to filter out the minimum necessary regression test case set;

[0139] The test execution module is used to execute the minimum necessary regression test case set and obtain the test results;

[0140] Determine whether the execution succeeds based on the test results;

[0141] If the test is passed, the test result is recorded and the knowledge base is updated.

[0142] If the test fails, the analysis will be based on the test results.

[0143] The report output module is used to analyze the test results, including determining whether there are any missed tests in the test results;

[0144] If so, analyze the cause and update the knowledge base and the change impact analysis engine;

[0145] Output the test report.

[0146] It is worth noting that although only some basic functional modules are disclosed in this embodiment, it does not mean that the composition of this system is limited to the above-mentioned basic functional modules. On the contrary, what this embodiment intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules does not mean that the scope of protection of the claims of this invention is limited to the disclosed basic functional modules. At the same time, for the convenience of description, the above device is described separately according to its functions as various units and modules. Of course, in implementing this invention, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0147] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0148] Figure 3 This is an overall flowchart of an incremental test regression system for differential OTA upgrades according to a specific embodiment of the present invention.

[0149] like Figure 3 As shown, it includes the following steps:

[0150] First, a multi-dimensional data fusion knowledge base is established, along with a code dependency graph, recording the functionalities, code modules, and interface configuration items covered by each test case. Once the knowledge base is complete, the process starting point is set to the availability of a new differential OTA upgrade package. A change impact analysis engine generates a relatively precise list of impact scopes, including affected modules, interfaces, signals, and configurations. This impact scope list then serves as input to an incremental test case filtering engine. Based on the impact scope and a series of filtering rules, the minimum necessary regression test set for affected test cases is selected from the full test case library. Finally, the selected test cases are executed, and their success is determined. If successful, the result is recorded and the knowledge base is updated. If failure occurs, the cause of the failure is analyzed to determine if it was a missed test. If so, a deeper analysis is needed, including possible reasons such as incomplete dependencies, inaccurate models, or missing test cases. Based on this analysis, the knowledge base (code dependency graph, test case library, etc.) is updated, and the ML model is optimized. This completes the closed-loop feedback learning process. Finally, a corresponding test report is output to provide a basis for OTA release decisions.

[0151] 2. Knowledge Base Establishment: First, a complete set of test cases is compiled. By instrumenting the code, each test case is executed, and the functional points, code modules, APIs, configuration items, signals, etc., covered by each test case are recorded. After analysis, the covered code modules, including modules, interfaces, signals, and configurations, are associated to establish a code relationship dependency graph. For example, the calling relationships of functions and classes, the interface dependencies between modules, and the vehicle-specific dependencies such as ECU communication signals (CAN / LIN / Ethernet signal interaction), service dependencies in the service-oriented architecture (SOA), and configuration file dependencies (which modules read which configuration files) are established to form the required knowledge base.

[0152] 3. Change Impact Analysis Engine: Input OTA (Over-The-Air) differential package, i.e., the code change set. Process: First, static analysis is performed to parse the code changes in the differential package, identifying direct change points and indirect dependencies, including code modules, interfaces, configurations, and signals. Second, requirements, defects, and test cases are correlated, linking the code changes in the differential package with requirements and defects to analyze the affected requirements and defects. Finally, ML (Machine Learning) prediction is used, leveraging a model trained on historical data to predict and analyze high-risk impact areas that may have been missed by the static analysis, providing corresponding confidence levels. Output: A relatively accurate list of impact areas with risk scores, including affected modules, interfaces, signals, services, configurations, requirements, and potential defect recurrence points, such as... Figure 4 As shown.

[0153] 4. Incremental Test Case Filtering Engine: The input is a list of affected areas. The filtering process selects the minimum necessary set of test cases based on predefined rules in the rule engine. First, the rules in the rule base are defined, including basic coverage rules (strong dependency scenarios, generally mandatory), risk enhancement rules (weak dependency scenarios, selective selection), and optimization and constraint rules (controlling the size and number of sets). The corresponding rules are described below: 1. Basic Coverage Rules: Rule A covers direct modification points: If the affected area list contains directly modified code entities (file File_A, function Func_B, class Class_C), then: test cases covering file File_A, function Func_B, and class Class_C are filtered from the knowledge base. The purpose is to ensure that the directly modified code can be directly tested. Rule B: Covering Directly Affected Items - Strong Dependencies: If the list of affected areas contains code entities (Module_X, Interface_Y, Signal_Z) that are strongly dependent on the directly modified point, then test cases covering Module_X, Interface_Y, and Signal_Z are selected from the knowledge base. The purpose is to cover modules and interaction points coupled with the modified point, preventing interface contracts from being broken or signal processing errors from occurring. Rule C: Covering Affected Interfaces and Signals: If the list of affected areas contains affected interfaces and signals (Interface_Y, Signal_Z), then test cases covering Interface_Y and Signal_Z are selected from the knowledge base. The purpose is to ensure the stability and correctness of bus communication and prevent signal changes from causing vehicle malfunctions. Rule D: Affected Configuration Items: If the list of affected areas contains affected configuration entities (Config_ParamFile), all test cases that cover Config_ParamFile are selected from the knowledge base. Purpose: To verify whether configuration changes are correctly loaded and applied, preventing configuration errors from causing functional abnormalities. 2. Risk Enhancement Rule: Rule E (Coverage of Key Indirectly Impacted Items - Weak Dependency + High Risk): If: IF the code entity (Module_W) with indirect impact exists in the impact scope list AND (Module_W's Functional Safety Level (ASIL) >= ASIL-B) OR (Module_W is marked as a core module in the knowledge base) OR (the confidence level of static analysis / ML prediction on Module_W > threshold_high), then select all test cases that cover Module_W from the knowledge base. Purpose: For modules that are indirectly dependent but are safety-critical, core functionalities, or predicted to be high-risk, it is better to test more than to miss them.The selection range is controlled by combining conditions to avoid overexpansion. Rule F (covers high-risk areas predicted by ML):

[0154] If the impact range list contains high-risk entities predicted by machine learning (Module_Risk, Signal_Risk) AND (predicted risk score > threshold_risk), then select all test cases that cover Module_Risk or Signal_Risk from the knowledge base. Objective: To utilize machine learning models to uncover potential risk points that may be overlooked by static analysis and to conduct supplementary testing, such as... Figure 5 As shown.

[0155] 5. Closed-Loop Feedback Learning: The test results serve as input for the closed-loop feedback learning module. A key process is missed test analysis. First, check if failed test cases were included in the previously selected test set. If so, it indicates a problem with the change analysis or the test cases themselves. If not, it indicates missed tests, requiring in-depth analysis of the reasons, such as incomplete dependency graphs, blind spots in static analysis, inaccurate ML model predictions, or incomplete test case design coverage. After analyzing the reasons, update the code dependency graph, mark high-risk areas, and add or update test case metadata. Secondly, update the ML prediction model, using the missed test cases as new training data to improve future prediction accuracy.

[0156] Figure 6 This is a block diagram of an electronic device structure provided by one or more embodiments of the present invention, which is an incremental test regression method based on differential OTA upgrade.

[0157] like Figure 6 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0158] The memory stores a computer program that, when executed by the processor, causes the processor to perform steps of an incremental test regression method based on differential OTA upgrades.

[0159] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform steps of an incremental test regression method based on differential OTA upgrade.

[0160] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0161] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0162] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. An incremental test regression method based on differential OTA upgrades, characterized in that, Includes the following steps: A knowledge base for multi-dimensional data fusion is obtained, the knowledge base including: a dependency graph of full use case association data and code relationship; Based on the knowledge base, determine whether the differential OTA upgrade package meets the upgrade requirements; If the conditions are met, the differential OTA upgrade package will be input into the change impact analysis engine. Get the list of affected areas; Get the incremental test case filtering engine; Input the list of impact ranges into the incremental test case filtering engine to filter out the minimum necessary regression test case set; Execute the minimum necessary regression test case set and obtain the test results; Determine whether the execution succeeds based on the test results; If the test is passed, the test result is recorded and the knowledge base is updated. If the test fails, the analysis will be based on the test results. The analysis of the test results includes: determining whether there are any missed tests in the test results; If so, analyze the cause and update the knowledge base and the change impact analysis engine; Output the test report.

2. The incremental test regression method based on differential OTA upgrade according to claim 1, characterized in that, The multidimensional data includes: all test cases and test case coverage association information.

3. The incremental test regression method based on differential OTA upgrade according to claim 2, characterized in that, The coverage association information of the test cases is as follows: After executing all test cases through code instrumentation, the coverage objects corresponding to each test case are recorded; This includes: the specific functions of the vehicle infotainment system covered by the test cases; and the code entities covered by the test cases. The test cases cover the vehicle infotainment interface and vehicle-specific communication signals; The vehicle infotainment system configuration entities covered by the test cases.

4. The incremental test regression method based on differential OTA upgrade as described in claim 1, characterized in that, The determination of whether the differential OTA upgrade package meets the upgrade requirements includes: Verify the code integrity of the differential OTA upgrade package and confirm that the code changes it contains can match the modules and interfaces in the code relationship dependency graph in the knowledge base; Verify the compatibility between the differential OTA upgrade package and the vehicle system configuration entities in the knowledge base to ensure that the configuration changes involved in the upgrade package do not exceed the vehicle system configuration adaptation range recorded in the knowledge base; If both of the above checks pass, the differential OTA upgrade package is deemed to meet the upgrade requirements; if either check fails, it is deemed not to meet the requirements, the subsequent process is terminated, and a check failure report is output.

5. The incremental test regression method based on differential OTA upgrade according to claim 1, characterized in that, The list of impact areas is obtained by: the change impact analysis engine performs static analysis on the differential OTA upgrade package, parses out the direct code change points, the direct code change points include modified files, functions and classes, and traces the indirect dependencies corresponding to the direct code change points, the indirect dependencies cover the modules, interfaces, vehicle-specific communication signals and configuration entities that are depended on; The change impact analysis engine will associate the parsed code change points with the requirement data and historical defect data in the knowledge base to locate the requirement items affected by the code change and potential defect recurrence points. The change impact analysis engine calls a machine learning model trained on historical test data from the knowledge base to predict high-risk impact areas that may be missed by static analysis. The high-risk impact areas include modules with functional safety level ≥ ASIL-B and the vehicle infotainment core module, and assigns a risk score to each affected object. By integrating the above analysis results, a list of the impact ranges is generated, which includes affected modules, interfaces, vehicle-specific communication signals, configuration entities, requirement items, defect recurrence points, and corresponding risk scores.

6. The incremental test regression method based on differential OTA upgrade according to claim 1, characterized in that, The incremental test case filtering engine loads a predefined rule base, which includes basic coverage rules, risk enhancement rules, and optimization and constraint rules. Based on the basic coverage rules, test cases are selected from the full set of test cases in the knowledge base to cover the direct code change points, strong dependencies of the direct change points, vehicle interface and configuration entities within the scope of impact list; Based on risk enhancement rules, test cases are selected to cover high-risk impact areas within the scope of impact list. Based on optimization and constraint rules, the selected test cases are deduplicated, and the total number of test cases is controlled to ensure that the test case set is minimized, ultimately forming the minimum necessary regression test case set.

7. The incremental test regression method based on differential OTA upgrade according to claim 1, characterized in that, If any detection is missed, the process of analyzing the reasons and updating the knowledge base and the change impact analysis engine specifically includes: The reasons for missed tests include incomplete code relationship dependency graphs in the knowledge base, prediction biases in the machine learning model of the change impact analysis engine, and missing test cases in the knowledge base. If the reason for the missed test is that the code relationship dependency graph is incomplete, then the module dependency relationship, interface dependency relationship or vehicle-specific communication signal dependency relationship corresponding to the missed test scenario should be added to the knowledge base. If the reason for the missed test is the lack of test cases, then add test cases that cover the missed test scenario and the corresponding coverage information to the knowledge base; If the reason for the missed detection is the prediction bias of the machine learning model, then the missed case is used as new training data to input into the machine learning model of the change impact analysis engine, the model is retrained to optimize the prediction accuracy, and the update of the change impact analysis engine is completed.

8. An incremental test regression system based on differential OTA upgrades, characterized in that, include: The module includes a knowledge base module, an upgrade package verification module, a change impact analysis module, an incremental test case filtering module, a test execution module, and a report output module. The knowledge base module is used to acquire a knowledge base of multi-dimensional data fusion, which includes: full set of use case association data and code relationship dependency graph; The upgrade package verification module is used to determine whether the differential OTA upgrade package meets the upgrade requirements based on the knowledge base. The change impact analysis module is used to input the differential OTA upgrade package into the change impact analysis engine to obtain a list of impact ranges; The incremental test case filtering module is used to obtain the incremental test case filtering engine; Input the list of impact ranges into the incremental test case filtering engine to filter out the minimum necessary regression test case set; The test execution module is used to execute the minimum necessary regression test case set and obtain the test results; Determine whether the execution succeeds based on the test results; If the test is passed, the test result is recorded and the knowledge base is updated. If the test fails, the analysis will be based on the test results. The report output module is used to analyze the test results, including determining whether there are any missed tests in the test results; If so, analyze the cause and update the knowledge base and the change impact analysis engine; Output the test report.

9. An electronic device, characterized in that, include: The processor, communication interface, memory, and communication bus are connected, with the processor, communication interface, and memory communicating with each other via the communication bus. The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the incremental test regression method based on differential OTA upgrade as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of an incremental test regression method based on differential OTA upgrade as described in any one of claims 1-7.

Images