A method for testing functions after whole vehicle OTA upgrade

Abstract

The application discloses a vehicle OTA upgrading function test method, and relates to the technical field of automatic test, which comprises the following steps: after vehicle OTA upgrading is completed, based on a preset verification script set, performing corresponding verification operations on each function to be verified of the vehicle, wherein the preset verification script set comprises verification logic of multiple functions to be verified; obtaining multi-source response data corresponding to each function to be verified during the verification operation, wherein the multi-source response data comprises at least two of communication data, log data and image data; based on the multi-source response data, determining the verification result of each function to be verified; and based on the verification result of all functions to be verified, determining the function test result of the vehicle after OTA upgrading.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and in particular to a functional testing method for a vehicle after an OTA upgrade. Background Technology

[0002] As automotive intelligence continues to improve, over-the-air (OTA) updates have become a core method for updating vehicle software functions. Currently, mainstream OTA update verification solutions primarily focus on software version consistency checks. This involves an OTA testing platform sending commands to the vehicle's central gateway via the OBD interface to obtain and compare the software version numbers before and after the upgrade, thus determining the success of the upgrade. However, this method only confirms whether the new software version has been successfully installed on the corresponding electronic control unit; it cannot verify the availability of various actual vehicle functions (such as lights, air conditioning, and instrument displays) after the upgrade. This creates a blind spot where the version is correct but the function is not, making it difficult to guarantee the overall functional quality of the vehicle after an OTA update. Therefore, a functional testing method for vehicle OTA updates is urgently needed to address the aforementioned technical problems. Summary of the Invention

[0003] The summary section introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. This summary section is not intended to limit the key and essential technical features of the claimed technical solutions, nor is it intended to determine the scope of protection of the claimed technical solutions.

[0004] Firstly, this application provides a method for functional testing after a vehicle OTA upgrade, including: After the vehicle OTA upgrade is completed, based on the preset verification script set, the corresponding verification operation is performed on each function to be verified of the vehicle. The preset verification script set includes the verification logic of multiple functions to be verified. Acquire multi-source response data corresponding to each function to be verified during the execution of the verification operation, wherein the multi-source response data includes at least two of communication data, log data, and image data; Based on the multi-source response data, the verification result of each function to be verified is determined; Based on the verification results of all functions to be verified, the functional test results after the vehicle OTA upgrade are determined.

[0005] In some implementations, after the vehicle OTA upgrade is completed, based on a preset set of verification scripts, the corresponding verification operation is performed on each function of the vehicle to be verified, including: After the vehicle OTA upgrade is completed, load the preset verification script set; Based on the verification logic corresponding to each function to be verified in the preset verification script set, the execution order of each verification function is determined. According to the execution order, the corresponding verification operations are performed sequentially for each function to be verified.

[0006] In some implementations, acquiring multi-source response data corresponding to each function to be verified during the execution of the verification operation includes: After performing a verification operation for any function to be verified, response data corresponding to the function to be verified is collected from at least two preset data sources. The response data includes communication data corresponding to the function to be verified obtained from the vehicle bus, log data corresponding to the function to be verified obtained from the vehicle system, and image data corresponding to the function to be verified obtained through an image acquisition device. Based on the response data collected from the at least two data sources, multi-source response data for the function to be verified is generated.

[0007] In some implementations, determining the verification result of each function to be verified based on the multi-source response data includes: For each function to be verified, determine the specific data type of the multi-source response data that constitutes the function to be verified; For each specific data type identified, a matching analysis is performed between the data of that type and the corresponding preset expected information to determine the verification sub-result corresponding to that data type; Based on all the determined verification sub-results, the verification result of the function to be verified is determined.

[0008] In some implementations, the step of performing a matching analysis between the data of each determined specific data type and the corresponding preset expected information to determine the verification sub-result corresponding to that data type includes: When the specific data type is the communication data, a communication verification sub-result is determined based on the matching result between the communication data and the preset communication expectation data; When the specific data type is the log data, the log verification sub-result is determined based on the matching result between the log data and the preset log expectation pattern; When the specific data type is the image data, the image verification sub-result is determined based on the matching result between the image data and the preset image expected features.

[0009] In some implementations, determining the functional test results after the vehicle OTA upgrade based on the verification results of all functions to be verified includes: Based on the verification results of all functions to be verified, determine the function pass rate and anomaly severity; A health score is determined based on the pass rate of the aforementioned function and the severity of the anomaly. Based on the health score, the functional test results after the vehicle OTA upgrade are determined.

[0010] In some implementations, determining the pass rate based on the verification results of all functions to be verified includes: Count the number of functions that passed verification out of all functions to be verified; Calculate the ratio of the number of functions that have passed verification to the total number of functions to be verified, and determine this ratio as the function pass rate.

[0011] In some implementations, determining the severity of the anomaly based on the verification results of all functions to be verified includes: Based on the verification results of all functions to be verified that failed, determine the corresponding function problem level; Based on the preset deduction weights corresponding to each functional problem level, the total deduction value is calculated, and the total deduction value is determined as the severity of the abnormality.

[0012] In some implementations, it also includes: Obtain the historical function test results corresponding to previous OTA upgrade versions; Determine the version degradation rate based on the feature pass rate of the current version and the feature pass rate of historical versions; The determination of the functional test results after the vehicle OTA upgrade based on the health score includes: Based on the health score and the version degradation rate, the functional test results after the vehicle OTA upgrade are determined.

[0013] In some implementations, after determining the functional test results after the vehicle OTA upgrade based on the health score, the method further includes: Based on the functional test results and the preset release threshold, determine whether the current OTA upgrade version meets the version release conditions; An alarm notification will be triggered if the current OTA upgrade version does not meet the release conditions.

[0014] Secondly, this application proposes a functional testing device for a vehicle after an OTA upgrade, comprising: The script execution unit is used to perform corresponding verification operations on each function to be verified of the whole vehicle based on a preset verification script set after the whole vehicle OTA upgrade is completed. The preset verification script set includes verification logic for multiple functions to be verified. The data acquisition unit is used to acquire multi-source response data corresponding to each function to be verified during the execution of the verification operation, wherein the multi-source response data includes at least two of communication data, log data and image data; The functional verification unit is used to determine the verification result of each function to be verified based on the multi-source response data. The functional testing unit is used to determine the functional test results after the vehicle OTA upgrade based on the verification results of all functions to be verified.

[0015] In summary, the functional testing method for vehicle OTA upgrades provided in this application effectively improves the comprehensiveness and reliability of functional testing after vehicle OTA upgrades by introducing a preset verification script set and a multi-source data fusion verification mechanism. Performing corresponding verification operations on each function to be verified based on the preset verification script set ensures the repeatability of the testing process and overcomes the subjectivity and omission risks of manual testing. By collecting at least two of the following as multi-source response data—communication data from the vehicle bus, log data from the vehicle system, and image data from image acquisition devices—multi-dimensional cross-verification of the same function is achieved. This method can comprehensively judge the functional status from multiple levels, including vehicle-level signal transmission, system logic execution, and human-machine interaction performance, thereby reducing the probability of misjudgment caused by abnormal or limited single data sources. For example, it can simultaneously identify hidden defects where the version number is correct but the actual function is not working. Furthermore, the verification result of each function to be verified is determined item by item based on the multi-source response data, ensuring that the determination of the functional status has sufficient data support and objective basis. Ultimately, by integrating the verification results of all functions, a vehicle-level test conclusion is formed, reflecting the overall quality of this OTA upgrade. Based on test automation, a substantial improvement in test depth and judgment accuracy has been achieved. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a schematic diagram of the functional testing method for a vehicle after an OTA upgrade, provided in an embodiment of this application. Figure 2 This is a schematic diagram of the functional testing device for a vehicle after OTA upgrade provided in an embodiment of this application; Figure 3 This is a schematic diagram of the functional testing equipment after a vehicle OTA upgrade provided in an embodiment of this application. Detailed Implementation

[0017] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0018] The functional testing method for vehicles after OTA upgrades provided in this application is mainly applied to automotive electronic software R&D verification, production line testing, and after-sales service systems. Specifically, after a vehicle completes an OTA (Over-The-Air) software upgrade, it enters the testing phase covered by this method. This aims to replace traditional functional inspections that rely on manual labor or single-dimensional data, achieving automated, integrated, and reliable verification of various electrical and intelligent functions of the upgraded vehicle. Typical application scenarios include, but are not limited to, conducting comprehensive functional regression testing on upgraded prototypes or trial production vehicles in a closed preparation environment or laboratory; performing rapid quality verification on vehicles about to leave the production line after OTA upgrades at the end of the production line; and serving as an automated quality assessment before version release in continuous integration R&D pipelines.

[0019] For ease of understanding, the following explanations are provided for some of the terms used in this application: The over-the-air (OTA) upgrade of the whole vehicle in this application refers to the process of batch and collaboratively updating the software or data of multiple electronic control units inside the vehicle through a wireless communication network.

[0020] The pre-set verification script set in this application refers to a set of instructions that has been pre-compiled and stored before testing following an OTA upgrade, containing multiple independent test logics. Each script corresponds to a vehicle function to be verified (such as light control or air conditioning adjustment), and encapsulates the logical steps for triggering the function, collecting relevant data, and judging the results. The script can be in the form of source code, configuration files, or executable scripts.

[0021] The multi-source response data in this application refers to a collection of various types of data synchronously collected from different subsystems of the vehicle or external devices after performing a verification operation for a specific function. Its core feature lies in the diversity of data sources, aiming to obtain evidence from multiple dimensions such as command transmission, internal system execution, and external physical performance. It typically includes, but is not limited to, communication data obtained from vehicle CAN / FlexRay buses, log data obtained from the vehicle's infotainment system or domain controller operating system, and image or video data obtained through image sensors such as cameras.

[0022] The communication data in this application refers to signal data related to a specific function transmitted via the vehicle's internal network bus. For example, a command to turn on the headlights is transmitted on the bus in a frame, or a lighting status feedback frame returned by the body controller. These typically contain identifiers and data payloads to reflect command interactions and status communications between electronic control units.

[0023] The log data in this application refers to the recording of timing events generated during the operation of in-vehicle software systems (such as in-vehicle infotainment systems and domain controllers). These records reflect the software-level operation execution process, state transitions, and possible error information.

[0024] The image data in this application refers to digital images or video frames acquired through optical acquisition devices (such as cameras) that contain the vehicle's human-machine interface or external physical state. By analyzing this data, the final performance of the function can be intuitively verified, such as the display status of dashboard icons, the touch feedback of the central control screen, or the actual illumination of the exterior lights.

[0025] The functions to be verified in this application refer to the specific performance or services of the vehicle that need to be tested using this method, such as lighting control, air conditioning adjustment, instrument display, voice interaction, etc.

[0026] The health score in this application refers to a comprehensive quantitative indicator used to comprehensively evaluate the test quality status of the vehicle's functions after a single OTA upgrade. It is generated based on statistical analysis (such as function pass rate) and weighted calculation (such as considering the severity of different function failures) of the verification results of all functions to be verified, and aims to characterize the reliability and risk level of this upgrade with a numerical score.

[0027] The function pass rate in this application is a statistical indicator, namely the ratio of the number of unverified functions that passed the verification in this test to the total number of all unverified functions executed. This ratio directly reflects the coverage rate of vehicle functions that successfully pass verification on the first attempt after an OTA upgrade.

[0028] The anomaly severity in this application is a weighted index used to quantify the impact of functional verification failures. Based on predefined criteria (such as functional safety issue level, user experience impact, etc.), it assigns different weights or deduction values ​​to different types of verification failure results. The cumulative weight of all failed functions constitutes the anomaly severity of this test, used to distinguish the risk differences between different failure modes.

[0029] Please see Figure 1 This is a schematic diagram of a functional testing method for a vehicle after an OTA upgrade, provided in an embodiment of this application. Specifically, it may include: S110. After the vehicle OTA upgrade is completed, based on the preset verification script set, perform corresponding verification operations on each function to be verified of the vehicle. The preset verification script set includes the verification logic of multiple functions to be verified. For example, this test process is initiated after the vehicle OTA upgrade operation is completed. This process uses a pre-compiled and stored set of verification scripts to automatically verify each of the vehicle's functions to be verified. This pre-compiled script set contains a series of independent test logics corresponding to different vehicle functions, aiming to transform test intent into a series of operational instructions that can be automatically recognized and executed by the system. By calling and running these scripts, user interaction is simulated or test commands are sent directly to the relevant vehicle control modules, thereby actively stimulating the function under test to enter its specific working state.

[0030] S120. Obtain multi-source response data corresponding to each function to be verified during the verification operation, wherein the multi-source response data includes at least two of communication data, log data and image data. For example, after performing the corresponding verification operation for each function to be verified, response data from different dimensions are collected synchronously as a basis for judgment. This data includes vehicle bus communication data reflecting the underlying command interaction, vehicle system log data recording the internal execution process of the system, and image data reflecting the final physical or interface performance status. By acquiring at least two different types of data, evidence about the same functional status can be obtained from multiple independent levels such as command transmission, logic execution, and final performance, forming cross-verification of the actual working status of the function. This method overcomes the risk of misjudgment that may occur when relying on a single data source due to the abnormality, delay, or limitation of that data source itself. For example, the log may show that the operation was successful but the actual function did not take effect, or the bus signal may be normal but the human-machine interface display may be abnormal. This improves the reliability of judging whether the function is truly usable after an OTA upgrade.

[0031] S130. Based on multi-source response data, determine the verification result of each function to be verified; For example, the multi-source data corresponding to each function, such as specific communication frames on the vehicle bus, relevant entries in the system log, and collected status images, will be compared and analyzed with the expected information or patterns pre-defined for each data type. This process does not rely on a simple match from a single data source, but rather cross-verifies evidence from different dimensions. By evaluating the consistency of instruction execution reflected by each data source, the absence of anomalies in internal system processing, and the final external performance meeting expectations, a conclusion is reached regarding whether the function is working properly.

[0032] S140. Based on the verification results of all functions to be verified, determine the functional test results after the vehicle OTA upgrade.

[0033] For example, after independently verifying all functions and obtaining their respective results, the vehicle-level comprehensive evaluation phase begins. This phase involves integrating the verification conclusions for individual functions and transforming them into comprehensive test results that reflect the overall functional quality of the vehicle after the OTA upgrade. Through aggregated analysis of all verification results—such as statistically analyzing the proportion of functions that successfully passed verification, assessing the severity and distribution patterns of different function failures—conclusions characterizing the reliability and risk of this software upgrade are generated. These vehicle-level functional test results constitute the final quantitative assessment of the OTA upgrade's effectiveness, providing input for version release review, issue prioritization, and test process optimization.

[0034] In summary, this embodiment of the application achieves repeatability and high coverage of the testing process by performing automated verification operations on each function to be verified based on a preset set of verification scripts after the vehicle OTA upgrade is completed, overcoming the subjectivity and omission risks of manual testing. By acquiring multi-source response data composed of at least two of the following: vehicle bus communication data, vehicle system log data, and image data from image acquisition devices, a multi-dimensional cross-verification mechanism is established from underlying signal transmission and system logic execution to human-machine interface or physical state performance. This effectively identifies hidden defects where the version number is correct but the actual function is not working, improving the reliability and accuracy of function status judgment. Furthermore, based on the multi-source data, the verification result of each function is determined item by item, and quantitative indicators such as function pass rate and anomaly severity are assigned to all function results. This leads to the comprehensive generation of a vehicle health score and version degradation rate, providing objective data support for version release decisions.

[0035] In some instances, it also includes: During the system initialization and pre-preparation phase, the goal is to ensure that the test environment is stable and ready after the vehicle completes the OTA upgrade, and that all necessary software scripts and hardware devices are synchronously available, laying a reliable foundation for subsequent automated function verification. This phase begins with listening for and confirming the upgrade completion event, specifically by monitoring specific event signals emitted by the vehicle's infotainment system. For example, this involves capturing the ACTION_BOOT_COMPLETED intent broadcast by the Android system upon startup, or parsing the OTA_FINISH keyword entry in the vehicle's system log that indicates the end of the OTA process. These serve as trigger conditions for determining that the upgrade process has been initially completed. After detecting the upgrade completion event, it is necessary to further verify whether the software version has been accurately updated to the target version. This verification is performed by sending an ADB debugging command to the vehicle's infotainment system. Specifically, the `adb shellgetprop ro.build.version.release` command is used to query and obtain the current system's internal version number, and the return value is compared with the target version number of this OTA upgrade. If they match, the version upgrade is confirmed to be successful.

[0036] To ensure that subsequent functional verification operations can be responded to normally by the vehicle system, it is also necessary to check and maintain the wake-up state of the vehicle device. If the device status detection shows that the vehicle or related controller is in sleep or low power mode, a simulated wake-up button event command should be sent immediately through the ADB tool, that is, the adb shell input keyevent KEY_WAKEUP command should be executed to force the device to wake up to the full-function working state, thereby ensuring that all functions to be verified can be effectively triggered and controlled, and completing the basic environment protection before testing.

[0037] In some instances, after a vehicle OTA upgrade is completed, based on a preset set of verification scripts, corresponding verification operations are performed on each function of the vehicle to be verified, including: After the vehicle OTA upgrade is completed, load the preset verification script set; Based on the verification logic corresponding to each function to be verified in the preset verification script set, determine the execution order of each verification function; In the order of execution, the corresponding verification operations are performed sequentially for each function to be verified.

[0038] For example, after the vehicle OTA upgrade process is confirmed, the preparation phase for automated function verification begins. The first step in this phase is loading a pre-set set of verification scripts. This loading process is typically triggered automatically after successful upgrade confirmation and environment readiness checks, reading a set of pre-compiled script files from a predefined storage location. These script files are stored in a specific structured format, encapsulating test logic for various vehicle functions, such as lighting control, air conditioning adjustment, and instrument display. The loading operation means reading the script data from the storage medium into the test platform's memory or parsing environment, making it a series of instruction units that can be recognized and executed by the test engine, thus establishing an operational foundation for sequentially triggering specific function verifications.

[0039] After successfully loading the preset verification script set, the execution order of all verification functions is determined based on the verification logic corresponding to each function to be verified within the set. This order is not random or fixed, but rather decided based on the inherent dependencies between functional tests or preset priority rules. For example, the verification of some functions may depend on the readiness of other basic functions or system states; such as ensuring the vehicle's infotainment system has successfully started and entered the main interface before testing the navigation function. Also, to avoid interference between test signals, functional tests involving the same hardware resources may be arranged in a staggered order. By parsing the dependencies in the scripts or according to a pre-configured priority mapping table, all functions to be verified are topologically sorted or prioritized to plan an execution path that ensures the preconditions for each test item are met.

[0040] After determining the execution order of all functions to be verified, the corresponding verification operations for each function are executed sequentially according to this predetermined order. This means that the test execution engine will follow the planned sequence, calling and running the corresponding scripts in the preset verification script set one by one. For each function in the sequence, its verification operation unfolds according to the complete logical flow defined by the function script, typically involving sending specific control commands to the vehicle system to activate the function. This sequential execution method ensures that when testing dependent functions, the preceding functions have been verified and are in the expected state, thus providing the correct context and system state for subsequent functional testing. This avoids test failures caused by condition races, resource conflicts, or unmet prerequisites due to disordered execution order.

[0041] In summary, this application's embodiments, by loading a pre-set set of scripts after the upgrade, achieve the separation and solidification of test cases and test execution logic, ensuring consistency of the starting point and repeatability of the process for each test, thus laying the foundation for the reliability of automated testing. By determining the execution order based on functional verification logic analysis, the test process can intelligently adapt to the inherent connections and dependencies between functions, simulating a reasonable sequence of test scenarios during automated execution. This not only improves the efficiency and first-pass yield of test execution but also avoids false failures that may be caused by disordered testing, enhancing the accuracy and reliability of test results. Following the planned sequence to execute each verification operation sequentially ensures the orderliness and controllability of the testing process, enabling complex vehicle functional regression testing to proceed in a systematic and modular manner, providing process assurance for obtaining comprehensive and reliable overall test conclusions.

[0042] In practice, this verification logic is defined and stored in a structured data format, such as JSON (JavaScript Object Notation). A complete script instance defines the end-to-end verification process from operation triggering to result assertion.

[0043] A function verification script named "Lighting Control" consists of three main parts: feature, steps, and assertions. The feature field specifies the target function module being verified by the script. The steps field defines an ordered sequence of operations used to trigger the function and collect raw data. The first operation is ADB_SEND, with its command value set to a specific ADB broadcast command, such as am broadcast -acom.example.light.TURN_ON. This step simulates user operation, sending a software command to the vehicle system to turn on the lights. The second operation is defined as CAN_MONITOR, where the id field specifies the CAN message identifier to be listened to (e.g., 0x123), and the expected_data field presets the data value expected to be seen in the message on that CAN ID after the light-on command is correctly processed (e.g., 0x01). This step is used to capture evidence of underlying network communication. The third step is set to CAMERA_CAPTURE, which specifies the area of ​​interest for image acquisition (such as "dashboard lighting area") through the region parameter. Its expected_state parameter describes the visual state that the area should present when the function is executed correctly (such as "bright"). This step aims to obtain evidence of the physical or human-machine interface performance of the function execution.

[0044] After the operation sequence is completed and multi-source data is collected, the verification enters the assertions stage, i.e., the assertion rule set. This set contains a series of parallel verification conditions, each judged for data from different sources. For CAN bus data, an assertion of type CAN_DATA_MATCH is set, whose id and expected parameters must correspond to the CAN_MONITOR step in steps, used to compare whether the actual received CAN data meets expectations. For image data, an assertion of type IMAGE_ANALYSIS is set, whose region and expected parameters are associated with the CAMERA_CAPTURE step, using image processing algorithms to analyze whether the features of the specified region match the expected state (e.g., "bright color"). For system running status, an assertion of type LOG_NO_ERROR is set, using keyword parameters (e.g., "Light Control Exception") to search the system log to confirm that no specific error records were generated during the test. The test execution engine will evaluate all these assertion conditions in sequence. Only when all assertions are satisfied will the verification result of the "lighting control" function be determined as "passed", thus realizing automated closed-loop verification based on the fusion of multi-dimensional evidence such as instructions, communication and vision.

[0045] In some instances, multi-source response data corresponding to each function to be verified is obtained during the execution of the verification operation, including: After performing a verification operation for any function to be verified, response data corresponding to the function to be verified is collected from at least two preset data sources. The response data includes communication data corresponding to the function to be verified obtained from the vehicle bus, log data corresponding to the function to be verified obtained from the vehicle system, and image data corresponding to the function to be verified obtained through an image acquisition device. Generate multi-source response data for the function to be verified based on response data collected from at least two data sources.

[0046] For example, after performing a verification operation for any function to be verified, response data directly related to the function operation is synchronously collected from at least two preset data sources according to a predefined data acquisition strategy in the function verification logic. The data sources are pre-configured information acquisition channels that can reflect the state of different levels of the function, and the types include, but are not limited to, vehicle bus, vehicle operating system, and image acquisition devices.

[0047] Specifically, for the vehicle bus, communication data is acquired by listening to and capturing communication messages associated with the function to be verified during the verification operation execution window using a dedicated tool connected to the vehicle diagnostic interface or bus monitoring port. These messages include control command transmission frames and status feedback frames. For the in-vehicle infotainment system, log data is acquired by reading event records, status information, or error reports generated by relevant applications, services, or driver modules within the in-vehicle infotainment system during a period before and after the verification operation is triggered, through the debug interface or system log service. For image acquisition devices, image data is acquired by capturing images of specified physical components or in-vehicle infotainment display areas at the moment when visual feedback is expected to be generated during the verification operation, by controlling the camera or invoking the screenshot function.

[0048] It should be noted that for a specific function to be verified, the corresponding multi-source response data does not necessarily have to consist of all three types: communication data, log data, and image data. Depending on the specific configuration of the function's script, at least two of these three data types should be selected for collection. For example, for some functions that primarily rely on network communication status, only communication data and log data may be collected; while for some functions that emphasize verifying the human-machine interface performance, only log data and image data may be collected. Subsequently, the identifier and timestamp of this verification operation are associated with the raw response data collected from the at least two data sources selected according to the script configuration to generate a multi-source response data set for the function to be verified, used for analysis.

[0049] During the generation of multi-source response data, a preset correspondence is followed to ensure that each piece of data collected is clearly associated with the currently executed verification operation and its target function. When acquiring communication data from the vehicle bus, only specific CAN or Ethernet messages related to the current function control or status feedback are collected according to predefined message identifier filtering rules, and their complete frame data and precise timestamps are recorded. When acquiring log data from the vehicle system, relevant entries generated during the operation execution period and output by the target function module are filtered from the system log stream according to preset keywords or process identifiers, ensuring that the log content can reflect the execution trajectory and results of the function at the software level. When acquiring image data through image acquisition devices, the physical camera is controlled to capture images of physical components such as vehicle exterior lights and dashboard icons according to the acquisition area, triggering time, and acquisition parameters defined in the script, or screenshots of specific application interfaces on the vehicle screen are taken through ADB commands to capture the physical state or human-machine interface performance after function execution. Finally, these data from different dimensions, but which are temporally and logically related and selected according to the script configuration, are aligned and encapsulated to form multi-source response data.

[0050] In summary, this application's embodiments change the traditional model of relying on a single data source for judgment. By introducing data from multiple independent dimensions, a cross-validation mechanism is constructed. Since different data sources reflect the different stages of a function's operation from instruction issuance and internal execution to external performance, any abnormal or deceptive signal from a single stage is unlikely to be consistent across all data sources. This significantly reduces the risk of misjudgment due to errors, delays, or limitations of a single data source. Specifying at least two, rather than all three, data sources reflects the method's configurability. For certain specific functions, collecting data from a particular type of data source may be infeasible, unnecessary, or too costly, allowing test designers to flexibly select the most relevant and reliable combination of data sources based on functional characteristics and the test environment. For example, for functions primarily relying on software logic interaction, log and image data can be used for verification; for functions involving strong hardware response, communication data and image data can be used for judgment. This design ensures that the method maintains feasibility and efficiency while pursuing verification reliability, making multi-source verification universally applicable to various vehicle function testing scenarios and laying a data foundation for functional quality assessment after OTA upgrades.

[0051] In some instances, the verification result for each function to be verified is determined based on multi-source response data, including: For each function to be verified, determine the specific data type that constitutes the multi-source response data corresponding to that function; For each specific data type identified, a matching analysis is performed between the data of that type and the corresponding preset expected information to determine the verification sub-results corresponding to that data type, including: When the specific data type is communication data, the communication verification sub-result is determined based on the matching result between the communication data and the preset expected communication data; When the specific data type is log data, the log verification sub-result is determined based on the matching result between the log data and the preset expected log pattern; When the specific data type is image data, the image verification sub-result is determined based on the matching result between the image data and the preset image expected features; Based on all determined verification sub-results, determine the verification result of the function to be verified.

[0052] For example, the multi-source response data collected for a specific function to be verified is parsed to determine its actual data type composition. This step is based on the script configuration loaded before executing the function verification operation, which determines the types of data sources to be collected and used in this verification. For example, for a "lighting control" function, its script may be configured to collect three types of data: communication data, log data, and image data, while for another "network connection" function, its script may only be configured to collect two types of data: log data and communication data. Therefore, determining the specific data type means, based on the execution context and script definition of this verification operation, identifying the set of data types actually collected and used for this judgment from the three possible categories of communication data, log data, and image data.

[0053] For each specific data type identified, the preset analysis rules and expected information corresponding to that data type will be invoked to perform matching analysis on the actual collected data under that type, and produce independent verification sub-results under that data type dimension.

[0054] When the specific data type is determined to be communication data, the core of the matching analysis lies in comparing the actual communication messages captured from the vehicle bus with the preset expected communication data. The preset expected communication data is usually predefined in the functional verification script and includes the expected message identifier, data segment content, and possible time windows or state transition sequences. For example, for a light-on operation, the expected data might be defined as a response frame with identifier 0x124 and data segment 0x00 appearing on the bus within a specific time after the command is issued. The analysis process involves checking whether there are messages in the actual captured communication data stream that match these expected characteristics, and determining the communication verification sub-result (e.g., "communication verification passed" or "communication verification failed") based on this matching result (complete match, partial match, or no match).

[0055] When the specific data type is determined to be log data, the focus of the matching analysis shifts to content scanning and pattern recognition of time-series log entries obtained from the vehicle's infotainment system. Preset expected log patterns are also pre-defined in the script, including two types of key information: first, the expected success flag string or event code, such as "LightControl:Success"; and second, error keywords or exception stack traces that are prohibited, such as "LightControlException". The analysis process performs full-text search and context analysis on the log data collected within the verification operation time window to determine whether the expected success flag has appeared, and simultaneously confirms whether prohibited error messages have appeared. Based on the matching results between the log content and these preset patterns (i.e., success flag appears and no error message appears, success flag does not appear or error message appears, etc.), the log verification sub-result is determined.

[0056] When the specific data type is determined to be image data, the matching analysis involves processing and extracting features from the acquired digital image using computer vision algorithms, and then comparing the extracted results with preset expected image features. The preset expected image features are defined in the script, determining the target area and judgment criteria for image analysis. For example, for a dashboard light icon, the expected features might be defined as the specific color histogram distribution (e.g., "bright color") that the icon area should display after function execution, or a specific text value (e.g., brightness value "100%) read using optical character recognition technology). The analysis process first locates the preset region of interest in the image, then applies an image classification model or optical character recognition engine to analyze that region, obtaining the actual state features. By comparing the analyzed actual features with the preset expected features, the image verification sub-result is determined based on their degree of consistency (e.g., color similarity exceeding a threshold, consistent recognized text).

[0057] After obtaining all or part of the communication verification sub-results, log verification sub-results, and image verification sub-results, the final verification result of the function to be verified is determined. Only when all verification sub-results corresponding to all types of data collected according to the script configuration are "passed" is the final verification result of the function to be verified determined to be "passed." In other words, if any necessary verification sub-result is "failed," the final function verification result will fail. For example, even if the communication data indicates that the start command was successfully sent and a response was received, and the logs are error-free, but image recognition shows that the light icon has not lit up, then the "light control" function verification is ultimately determined to have failed. This rule ensures that the judgment of the function status is based on the verification sub-results of all corresponding data types, achieving end-to-end validity verification.

[0058] In summary, this application's embodiments achieve verification of evidence of different natures by setting preset expected information for each data type—communication data, log data, and image data—and performing matching analysis. Matching of communication data ensures the correctness of underlying hardware instruction transmission and response; matching of log data verifies the error-free and anomaly-free execution path of the software logic; and matching of image data confirms that the physical or interface performance perceived by the end user meets design expectations. By integrating the independent verification sub-results, a cross-validation decision mechanism is constructed. This mechanism requires that any anomaly in any single dimension be captured and cause overall verification failure, thereby reducing the risk of false positives due to errors, delays, or even tampering with a single data source, and improving the accuracy and reliability of functional verification after OTA upgrades.

[0059] In some instances, based on the verification results of all functions to be verified, the functional test results after the vehicle OTA upgrade are determined, including: Based on the verification results of all functions to be verified, determine the function pass rate and anomaly severity; A health score is determined based on the functional pass rate and the severity of the anomalies. Based on the health score, the functional test results after the vehicle OTA upgrade are determined.

[0060] For example, based on the verification results of all functions to be verified, two quantitative indicators are determined: function pass rate and anomaly severity. The process for determining the function pass rate is as follows: Count the number of functions whose verification results are judged as "pass" among all functions to be verified. Then, calculate the ratio of the number of pass functions to the total number of functions to be verified, and determine this ratio as the function pass rate for this test. The process for determining the anomaly severity is as follows: For all functions to be verified that have a verification result of "fail", determine the specific level corresponding to each failed function according to the predefined problem level for each function (e.g., V1, V2, V3 levels based on functional safety criticality or user experience impact). Then, based on the pre-configured deduction weights for each problem level (e.g., V1 level corresponds to a deduction of 40 points, V2 level corresponds to a deduction of 10 points, and V3 level corresponds to a deduction of 5 points), sum the deduction weights of all failed functions, and determine the total deduction value as the anomaly severity for this test.

[0061] After obtaining the feature pass rate and anomaly severity, a health score is determined. This health score is generated by fusing the feature pass rate and anomaly severity using a pre-defined calculation model. In one specific implementation, this calculation model can set an initial maximum score, such as 100 points. First, the initial maximum score is proportionally reduced based on the feature pass rate to obtain a base score. Then, the previously calculated anomaly severity, i.e., the total deduction value, is subtracted from this base score. The final value is determined as the health score. This calculation process ensures that the health score reflects both the breadth of test coverage (pass rate) and the depth of issues (severity). For example, even if the pass rate is high, if several high-severity issues occur, resulting in a large number of deductions, the final score will be lower accordingly, thus revealing the version quality risk.

[0062] The calculated health score is compared with multiple preset score threshold ranges. For example, when the health score is greater than or equal to 90, the functional test result is judged as healthy; when the score is between 70 and 89, it is judged as good but with observation suggestions; when the score is between 60 and 69, it is judged as a warning but requires the repair of critical issues; when the score is below 60, it is judged as a fault. In this way, a single health value is converted into a vehicle-level functional test result, providing a basis for version release decisions.

[0063] In summary, this embodiment of the application first calculates the function pass rate and anomaly severity separately, summarizing the test results from discrete function point states into statistical indicators: the function pass rate objectively reflects the proportion of vehicle functions working normally after this OTA upgrade, directly reflecting the success rate of the upgrade; the anomaly severity quantifies the impact of failed or abnormal function points, avoiding the defect of only counting the number while ignoring the differences in problems. By merging these two complementary indicators into a health score, a quantitative assessment of the overall vehicle software version quality status is achieved, making quality comparisons between different versions and different test batches direct and operable. By mapping the health score to test result levels with semantic descriptions, technical quantitative data is transformed into a management decision-making language, which can not only identify the version quality level, but also automatically associate different subsequent processing flows according to preset rules, such as directly approving release, requiring retesting after repair, or blocking release, thereby achieving automated connection between test evaluation and R&D process control, improving the efficiency and reliability of OTA upgrade quality assurance.

[0064] In some instances, it also includes: Obtain the historical function test results corresponding to previous OTA upgrade versions; Determine the version degradation rate based on the feature pass rate of the current version and the feature pass rate of historical versions; Based on the health score, the functional test results after the vehicle OTA upgrade are determined, including: Based on the health score and version degradation rate, the functional test results after the vehicle OTA upgrade are determined.

[0065] For example, a historical version comparison mechanism is introduced in the process of processing the verification results of all functions to be verified to determine the functional test results after the vehicle OTA upgrade. Specifically, the method also includes obtaining historical functional test results corresponding to previous OTA upgrade versions. These historical functional test results are retrieved from a database or version management system that stores test records, and include the functional pass rate index calculated after the specific historical version of interest was tested. After obtaining this historical data, the functional pass rate calculated for the current OTA upgrade version is compared and analyzed with the functional pass rates of one or more selected historical versions. Based on this comparative analysis, the change in functional pass rate of the current version relative to historical versions is calculated, such as calculating the difference or percentage decrease between the current pass rate and the historical average pass rate, and this calculated change is determined as the version degradation rate. This version degradation rate quantifies whether the current upgrade version has improved or regressed in terms of functional passability compared to previous versions.

[0066] The calculated version degradation rate is then used to jointly determine the functional test results after the vehicle OTA upgrade. This determination process does not rely solely on the absolute value of the health score, but rather comprehensively considers both the health score, which reflects the quality status of the current version, and the version degradation rate, which reflects its change relative to the historical baseline. For example, even if the current version's health score is above a preset threshold, if its version degradation rate shows a significant decrease in the functional pass rate compared to the previous stable version and exceeds the preset degradation threshold, the final functional test result may be marked as "version has a risk of degradation." Conversely, if the health score is good and the version degradation rate shows stable or improved quality, it is judged as "version quality is stable." By combining the health score, which represents the absolute quality status, with the version degradation rate, which represents relative quality changes, the final functional test results not only reflect the immediate quality level of the version but also reveal its quality evolution trend, providing a richer and more predictive basis for version release decisions.

[0067] In some instances, after determining the functional test results of the vehicle OTA upgrade based on health scores, the following are also included: Based on the functional test results and the preset release threshold, determine whether the current OTA upgrade version meets the release conditions; An alarm notification will be triggered if the current OTA upgrade version does not meet the release requirements.

[0068] For example, after determining the functional test results of the vehicle OTA upgrade based on the health score, the method further includes determining whether the current OTA upgrade version meets the version release conditions based on the functional test results and a preset release threshold, and triggering an alarm notification when the conditions are not met.

[0069] Specifically, functional test results include quantitative metrics, such as health scores and / or version degradation rates. Preset release thresholds are pre-defined critical values ​​used to assess whether a version meets release-ready quality standards. These thresholds include at least a health score threshold and may further include a version degradation rate threshold. The process for determining whether release conditions are met involves comparing the health score from the functional test results with the preset health score threshold. If the functional test results also include a version degradation rate, this is further compared with the preset version degradation rate threshold. The current OTA upgrade version is considered to meet release conditions only when the health score is not lower than the health score threshold and the version degradation rate does not exceed the version degradation rate threshold during the comparison. If any of the above comparison results fails to meet the preset threshold requirements—for example, if the health score is lower than the threshold or the version degradation rate exceeds the threshold—the current version is considered not to meet release conditions.

[0070] Once the conditions are determined not to be met, an alert notification will be automatically triggered. This alert notification is designed to immediately convey warning information that the version quality has not met the standards to relevant personnel (such as the testing team, development team, or version administrator). Its triggering and generation are automatically executed based on the determination result of the non-compliance of conditions. The alert format can be one or more of the following: integrated into the email system, instant messaging tools, or continuous integration pipeline notification mechanism.

[0071] In some instances, it also includes: By constructing an automated closed-loop testing pipeline, the functional verification process after a vehicle OTA upgrade is integrated into the continuous integration and continuous delivery phase of software development. Specifically, an automated testing pipeline is built based on continuous integration tools, configured to automatically trigger execution after each vehicle OTA upgrade. The pipeline's execution logic begins by pulling the latest OTA package to be verified from the software repository and deploying it to the vehicle. It then automatically loads and executes verification operations for various vehicle functions from a pre-set set of verification scripts. Subsequently, it generates a test report containing a health score based on multi-source response data analysis and archives it. Finally, based on the comparison between the health score obtained from this test and a pre-set release threshold, the pipeline automatically decides whether to allow the current OTA version to be released. This achieves a fully automated closed loop from upgrade triggering, test execution to release decision, ensuring that the quality assessment process is synchronized with the development schedule and improving the efficiency and standardization of version delivery.

[0072] In some instances, it also includes: To ensure continuous evolution of testing capabilities and keep pace with the iteration of vehicle software functions, this approach establishes a dynamic maintenance and optimization mechanism for the script library and verification model. The driving factors for this mechanism stem from actual testing activities and software changes, primarily including new version features, test script execution failures, and new problem scenarios exposed during test runs. When a new OTA software version is planned to introduce new features or modify existing functional logic, the test script library must synchronously add or update the corresponding verification scripts to ensure the integrity of test coverage. During automated test runs, changes to vehicle system interfaces, communication protocol updates, or environmental differences may cause some existing scripts to fail to execute correctly or to fail assertions. Such failure cases are recorded and analyzed, directly driving the debugging and correction of specific scripts. Furthermore, when test reports show that a function, although verified by existing scripts, exposes defects in broader real-world user scenarios, this indicates insufficient existing verification logic or scenario coverage, necessitating the addition of new test steps or optimization of assertion conditions. Based on the above-mentioned driving force, the preset verification script set is updated regularly, the image recognition and other analysis models are continuously optimized to improve accuracy, and the anomaly diagnosis rules are continuously improved, so as to ensure that the entire testing system always maintains a high degree of fidelity with the actual state of the vehicle system.

[0073] Please see Figure 2 This is a schematic diagram of a functional testing device for a vehicle after an OTA upgrade, provided in an embodiment of this application, including: The script execution unit 21 is used to perform corresponding verification operations on each function to be verified of the whole vehicle based on a preset verification script set after the whole vehicle OTA upgrade is completed. The preset verification script set includes verification logic for multiple functions to be verified. The data acquisition unit 22 is used to acquire multi-source response data corresponding to each function to be verified during the verification operation. The multi-source response data includes at least two of the following: communication data, log data, and image data. Functional verification unit 23 is used to determine the verification result of each function to be verified based on multi-source response data; Functional test unit 24 is used to determine the functional test results after the vehicle OTA upgrade based on the verification results of all functions to be verified.

[0074] Please see Figure 3 This application also provides an electronic device 300, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements the steps of a functional testing method after a vehicle OTA upgrade.

[0075] Since the electronic device described in this embodiment is the device used to implement the functional testing device after a vehicle OTA upgrade in this application embodiment, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in this application embodiment. Therefore, how the electronic device implements the method in this application embodiment will not be described in detail here. Any device used by those skilled in the art to implement the method in this application embodiment is within the scope of protection of this application.

[0076] In practice, when the computer program 311 is executed by the processor, it can implement any of the embodiments corresponding to the first aspect.

[0077] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0078] Those skilled in the art will understand that embodiments of this application can provide methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media containing computer-readable program code.

[0079] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a mechanism for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0080] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0081] These computer program instructions can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0082] This application also provides a computer program product, which includes computer software instructions that, when executed on a processing device, cause the processing device to perform... Figure 1 The flowchart of a functional testing method after a vehicle OTA upgrade in the corresponding embodiment.

[0083] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, computer instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any usable medium that a computer can store or a data storage device such as a server or data center that integrates one or more usable media. The usable medium may be a magnetic medium, an optical medium, or a semiconductor medium, etc.

[0084] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0085] In the several embodiments provided in this application, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Furthermore, the mutual couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0086] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0087] 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 units described above can be implemented in the form of hardware and / or software functional units.

[0088] 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 computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods in 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, magnetic disks, or optical disks.

[0089] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0090] Although preferred embodiments have been described in this specification, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications that fall outside the scope of this specification.

[0091] Obviously, those skilled in the art can make various modifications to this specification without departing from its spirit and scope. Therefore, this specification is intended to include any modifications that fall within the scope of the claims and their equivalents.

Claims

1. A method for functional testing after a vehicle OTA upgrade, characterized in that, include: After the vehicle OTA upgrade is completed, based on the preset verification script set, the corresponding verification operation is performed on each function to be verified of the vehicle. The preset verification script set includes the verification logic of multiple functions to be verified. Acquire multi-source response data corresponding to each function to be verified during the execution of the verification operation, wherein the multi-source response data includes at least two of communication data, log data, and image data; Based on the multi-source response data, the verification result of each function to be verified is determined; Based on the verification results of all functions to be verified, the functional test results after the vehicle OTA upgrade are determined.

2. The method according to claim 1, characterized in that, After the vehicle OTA upgrade is completed, based on a preset set of verification scripts, corresponding verification operations are performed on each function of the vehicle to be verified, including: After the vehicle OTA upgrade is completed, load the preset verification script set; Based on the verification logic corresponding to each function to be verified in the preset verification script set, the execution order of each verification function is determined. According to the execution order, the corresponding verification operations are performed sequentially for each function to be verified.

3. The method according to claim 1, characterized in that, The acquisition of multi-source response data corresponding to each function to be verified during the execution of the verification operation includes: After performing a verification operation for any function to be verified, response data corresponding to the function to be verified is collected from at least two preset data sources. The response data includes communication data corresponding to the function to be verified obtained from the vehicle bus, log data corresponding to the function to be verified obtained from the vehicle system, and image data corresponding to the function to be verified obtained through an image acquisition device. Based on the response data collected from the at least two data sources, multi-source response data for the function to be verified is generated.

4. The method according to claim 1, characterized in that, The determination of the verification result for each function to be verified based on the multi-source response data includes: For each function to be verified, determine the specific data type of the multi-source response data that constitutes the function to be verified; For each specific data type identified, a matching analysis is performed between the data of that type and the corresponding preset expected information to determine the verification sub-result corresponding to that data type; Based on all the determined verification sub-results, the verification result of the function to be verified is determined.

5. The method according to claim 4, characterized in that, For each specific data type identified, the process involves matching and analyzing the data of that type with the corresponding preset expected information to determine the verification sub-result corresponding to that data type, including: When the specific data type is the communication data, a communication verification sub-result is determined based on the matching result between the communication data and the preset communication expectation data; When the specific data type is the log data, the log verification sub-result is determined based on the matching result between the log data and the preset log expectation pattern; When the specific data type is the image data, the image verification sub-result is determined based on the matching result between the image data and the preset image expected features.

6. The method according to claim 1, characterized in that, The functional test results after the vehicle OTA upgrade are determined based on the verification results of all functions to be verified, including: Based on the verification results of all functions to be verified, determine the function pass rate and anomaly severity; A health score is determined based on the pass rate of the aforementioned function and the severity of the anomaly. Based on the health score, the functional test results after the vehicle OTA upgrade are determined.

7. The method according to claim 6, characterized in that, The process of determining the pass rate based on the verification results of all functions to be verified includes: Count the number of functions that passed verification out of all functions to be verified; Calculate the ratio of the number of functions that have passed verification to the total number of functions to be verified, and determine this ratio as the function pass rate.

8. The method according to claim 6, characterized in that, The determination of anomaly severity based on the verification results of all functions to be verified includes: Based on the verification results of all functions to be verified that failed, determine the corresponding function problem level; Based on the preset deduction weights corresponding to each functional problem level, the total deduction value is calculated, and the total deduction value is determined as the severity of the abnormality.

9. The method according to claim 6, characterized in that, Also includes: Obtain the historical function test results corresponding to previous OTA upgrade versions; Determine the version degradation rate based on the feature pass rate of the current version and the feature pass rate of historical versions; The determination of the functional test results after the vehicle OTA upgrade based on the health score includes: Based on the health score and the version degradation rate, the functional test results after the vehicle OTA upgrade are determined.

10. The method according to claim 6, characterized in that, After determining the functional test results of the vehicle OTA upgrade based on the health score, the following is also included: Based on the functional test results and the preset release threshold, determine whether the current OTA upgrade version meets the version release conditions; An alarm notification will be triggered if the current OTA upgrade version does not meet the release conditions.

Images