Automatic testing and closed-loop repair method, device and storage medium for wireless device software

Abstract

The application relates to the field of software testing, and provides an automatic testing and closed-loop repair method, device and storage medium for wireless device software. The method comprises the following steps: listening to a communication channel during wireless device operation, acquiring air interface data containing at least a Bluetooth or Wi-Fi protocol and corresponding radio frequency environment metadata; performing multidimensional analysis on the air interface data by using a machine learning model; automatically generating a machine executable defect report according to a predefined structured template based on the result of the multidimensional analysis; parsing an automatic repair trigger instruction in the machine executable defect report, automatically calling an application program interface of an external continuous integration system to trigger a code pulling, compiling and testing task chain for the defect; after the task chain is successfully completed, wirelessly pushing an update program generated to the wireless device, and when the pushing fails or the device runs abnormally after being updated, performing a predefined automatic retry operation or a predefined version rollback operation.

Description

Technical Field

[0001] This application relates to the field of software testing, and in particular to an automatic testing and closed-loop repair method, apparatus and storage medium for wireless device software. Background Technology

[0002] With the rapid development of industries such as the Internet of Things and smart terminals, the software functions of wireless devices (e.g., Bluetooth headsets, smart home devices, industrial sensor nodes, etc.) are becoming increasingly complex, posing serious challenges to their stability and reliability. Software and system testing is a key link in ensuring the quality of wireless devices, and its core objective is to efficiently and accurately discover and repair various communication anomalies caused by software defects or external environmental interference.

[0003] Currently, the industry commonly employs a phased, multi-tool, semi-automated approach for testing wireless device software. A typical testing process includes: first, testers use specialized equipment to capture wireless communication data and some environmental parameters during device operation; then, through manual analysis of logs or with the help of basic automated scripts, they filter for possible anomalies; finally, discovered defects are manually entered into the issue tracking system, and the development team intervenes to locate, fix, verify, and redeploy them. This approach constitutes an open-loop system centered on human decision-making and operation.

[0004] However, the applicant of this application found that the existing semi-automated, open-loop testing and repair methods have the following obvious drawbacks: 1) Low efficiency in problem localization and reliance on expert experience. This is because wireless communication problems may originate from internal software defects in the device (e.g., protocol stack logic errors) or from external complex and ever-changing radio frequency environment interference. Existing methods usually cannot automatically distinguish between these two types of root causes during the testing phase, resulting in unclear problem troubleshooting paths. They heavily rely on the experience of testers for manual analysis, which is time-consuming and prone to misjudgment; 2) A broken process from defect discovery to repair and deployment. Specifically, defect reporting, code repair, testing and verification, and version deployment are often completed by different teams using different tools. There are a large number of manual triggering and handover steps in the process, resulting in long feedback cycles and the inability to achieve a rapid closed loop of "discovery-repair-verification", which seriously affects the efficiency of software iteration and the response speed of online problems. Summary of the Invention

[0005] This application provides an automatic testing and closed-loop repair method, apparatus, and storage medium for wireless device software. By intelligently analyzing and identifying the root causes of defects and automatically triggering the repair process, it achieves a fast and reliable closed loop for wireless device software from testing and repair to deployment.

[0006] On the one hand, this application provides an automatic testing and closed-loop repair method for wireless device software, the method comprising:

[0007] During the operation of the wireless device, the communication channel is monitored to obtain air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata;

[0008] The air interface data is subjected to multidimensional analysis using a machine learning model. The multidimensional analysis includes at least: parsing the communication sequence based on the protocol state machine model to identify protocol state transition errors; comparing the actual communication timing with the ideal timing template based on the dynamic time warping algorithm to identify timing anomalies; and distinguishing between anomalies caused by external radio frequency interference and anomalies caused by internal software defects based on the temporal correlation between the radio frequency environment metadata and communication anomaly events.

[0009] Based on the results of the multidimensional analysis, a machine-executable defect report is automatically generated according to a predefined structured template, which includes defect root cause speculation, affected code module location information, and automated repair trigger instructions.

[0010] The machine can parse the automated repair trigger instructions in the defect report, automatically call the application programming interface of the external continuous integration system, and trigger a code retrieval, compilation, and testing task chain for the defect; and

[0011] After the task chain is successfully completed, the generated update program is wirelessly pushed to the wireless device. If the push fails or the device malfunctions after the update, a predefined automatic retry operation or a predefined version rollback operation is performed.

[0012] On the other hand, this application provides an automatic testing and closed-loop repair device for wireless device software, the device comprising:

[0013] The acquisition module is used to listen to the communication channel during the operation of the wireless device and acquire air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata;

[0014] The analysis module is used to perform multidimensional analysis on the air interface data using a machine learning model. The multidimensional analysis includes at least: parsing the communication sequence based on the protocol state machine model to identify protocol state transition errors; comparing the actual communication timing with the ideal timing template based on the dynamic time warping algorithm to identify timing anomalies; and distinguishing between anomalies caused by external radio frequency interference and anomalies caused by internal software defects based on the temporal correlation between the radio frequency environment metadata and communication anomaly events.

[0015] The generation module is used to automatically generate a machine-executable defect report based on the results of the multidimensional analysis and according to a predefined structured template. The report includes defect root cause prediction, affected code module location information, and automated repair trigger instructions.

[0016] The calling module is used to parse the automated repair triggering instructions in the machine executable defect report and automatically call the application interface of the external continuous integration system to trigger the code retrieval, compilation, and testing task chain for the defect;

[0017] The closed-loop deployment module is used to wirelessly push the generated update program to the wireless device after the task chain is successfully completed, and to perform predefined automatic retry operations or predefined version rollback operations when the push fails or the device runs abnormally after the update.

[0018] Thirdly, this application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the technical solution of the automatic testing and closed-loop repair method for wireless device software as described above.

[0019] Fourthly, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the technical solution of the automatic testing and closed-loop repair method for wireless device software described above.

[0020] As can be seen from the technical solutions provided in this application, on the one hand, by analyzing communication sequences based on protocol state machine models, logical software defects such as non-compliant state transitions can be efficiently identified; by comparing timing sequences using dynamic time warping algorithms, performance defects caused by resource contention, deadlock, etc., can be effectively discovered; more importantly, by correlating communication anomalies with real-time radio frequency environment metadata, it is possible to automatically determine whether the anomaly originates from external environmental interference or internal software faults. This automated, multi-dimensional integrated analysis method reduces reliance on human experience and significantly improves the accuracy and efficiency of problem diagnosis. On the other hand, the results of multi-dimensional analysis are automatically generated into machine-executable defect reports containing automated repair trigger instructions, and external system interfaces are automatically called to trigger subsequent task chains, achieving seamless automated connection from defect identification to development and repair processes. This is because the structured defect report not only describes "what" the problem is, but also, through internal... The instructions specify "how to fix" the defect, allowing downstream development and operations toolchains to directly understand and process the defect information. This design breaks down the traditionally fragmented testing, development, and deployment processes, enabling the entire fix workflow to flow automatically and significantly reducing the delay from problem discovery to fix initiation. Thirdly, by automatically pushing updates wirelessly after a successful task chain and automatically retrying or rolling back versions in case of anomalies, a complete and adaptive software delivery and operations loop is formed. The automatic deployment mechanism ensures that fixes quickly reach end devices, while the built-in retry and rollback strategies provide the system with adaptive fault tolerance and recovery capabilities against network fluctuations and compatibility issues that may occur during and after deployment. This not only improves the success rate and reliability of software updates but also constitutes a secure closed loop that can self-verify fix effects and automatically ensure system stability, thereby comprehensively improving the quality of wireless device software lifecycle management and user experience. In summary, the technical solution of this application, through intelligent analysis to distinguish the root causes of defects and automatically trigger the fix process, achieves a rapid and reliable closed loop for wireless device software from testing and fixes to deployment. Attached Figure Description

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

[0022] Figure 1 This is a flowchart of the automatic testing and closed-loop repair method for wireless device software provided in the embodiments of this application;

[0023] Figure 2This is a schematic diagram of the automatic testing and closed-loop repair device for wireless device software provided in the embodiments of this application;

[0024] Figure 3 This is a schematic diagram of the device provided in the embodiments of this application. Detailed Implementation

[0025] 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 some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] In this specification, adjectives such as "first" and "second" are used only to distinguish one element or action from another, without necessarily requiring or implying any actual such relationship or order. Where circumstances permit, reference to an element or component or step (etc.) should not be construed as being limited to only one of the elements, components, or steps, but may be one or more of the elements, components, or steps, etc.

[0027] For ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn to actual scale.

[0028] Currently, the industry commonly employs a phased, multi-tool, semi-automated approach for testing wireless device software. A typical testing process includes: first, testers use specialized equipment to capture wireless communication data and some environmental parameters during device operation; then, through manual analysis of logs or with the help of basic automated scripts, they filter for possible anomalies; finally, discovered defects are manually entered into the issue tracking system, and the development team intervenes to locate, fix, verify, and redeploy them. This approach constitutes an open-loop system centered on human decision-making and operation. However, the applicant of this application found that the existing semi-automated, open-loop testing and repair methods have the following obvious drawbacks: 1) Low efficiency in problem localization and reliance on expert experience. This is because wireless communication problems may originate from internal software defects in the device (e.g., protocol stack logic errors) or from external complex and ever-changing radio frequency environment interference. Existing methods usually cannot automatically distinguish between these two types of root causes during the testing phase, resulting in unclear problem troubleshooting paths. They heavily rely on the experience of testers for manual analysis, which is time-consuming and prone to misjudgment; 2) A broken process from defect discovery to repair and deployment. Specifically, defect reporting, code repair, testing and verification, and version deployment are often completed by different teams using different tools. There are a large number of manual triggering and handover steps in the process, resulting in long feedback cycles and the inability to achieve a rapid closed loop of "discovery-repair-verification", which seriously affects the efficiency of software iteration and the response speed of online problems.

[0029] To address the aforementioned problems in the prior art, this application proposes an automatic testing and closed-loop repair method for wireless device software, the flowchart of which is attached. Figure 1 As shown, it mainly includes steps S1 to S5, which are detailed below:

[0030] Step S1: Listen to the communication channel during the operation of the wireless device to obtain air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata.

[0031] This step requires the deployment of a wireless data acquisition system. This system can be one or more hardware devices equipped with dedicated wireless network cards (which support monitoring mode) and spectrum analysis capabilities, deployed within the communication range of the wireless device under test (e.g., smart home gateway, industrial sensor, etc.).

[0032] Specifically, the acquisition system continuously monitors the communication channels used by the target wireless device. For Bluetooth, this might include monitoring both the BLE broadcast and data channels; for Wi-Fi, it might monitor specific 2.4GHz or 5GHz channels. While capturing each communication data packet (i.e., air interface data), the acquisition system simultaneously collects the Received Signal Strength Indicator (RSSI) value, Signal-to-Noise Ratio (SNR) value, and Channel Utilization value corresponding to the timestamp of each communication data packet as RF environment metadata, and associates and stores this RF environment metadata with the corresponding communication data packet. For example, each captured data packet can be appended with a timestamp and a set of metadata {RSSI:-65dBm, SNR:25dB, Channel Utilization:15%} and stored in a time-series database. This synchronous and associated storage lays the foundation for subsequent correlation analysis between communication events and the RF environment.

[0033] Step S2: Perform multidimensional analysis on the air interface data using a machine learning model. This multidimensional analysis includes at least: parsing the communication sequence based on the protocol state machine model to identify protocol state transition errors; comparing the actual communication timing with the ideal timing template based on the dynamic time warping algorithm to identify timing anomalies; and distinguishing between anomalies caused by external radio frequency interference and anomalies caused by internal software defects based on the temporal correlation between radio frequency environment metadata and communication anomaly events.

[0034] Wireless communication anomalies may originate from logical defects or resource contention within the device's internal software, or from complex, time-varying radio frequency (RF) environmental interference (e.g., co-channel interference, multipath fading). For these anomalies, relying solely on manual experience for analysis—for example, having a senior test engineer review communication logs and simple RF metrics—is inherently flawed due to its heavy reliance on personal experience, extremely low efficiency, poor consistency, and inability to handle massive amounts of data. Even using rules based on fixed thresholds—such as preset simple signal strength or bit error rate thresholds that trigger an alarm—still has significant drawbacks. These include rigid rules, an inability to identify complex protocol state transition errors or specific timing pattern anomalies, and a high risk of false alarms. For instance, it may be impossible to distinguish whether poor signal strength is caused by device malfunction or environmental interference. To automatically and accurately distinguish between wireless communication anomalies of different origins, this application employs a technical solution that utilizes machine learning models to perform multidimensional analysis on air interface data. This multidimensional analysis includes: parsing communication sequences based on a protocol state machine model to identify protocol state transition errors; comparing actual communication timing with ideal timing templates based on a dynamic time warping algorithm to identify timing anomalies; and differentiating between anomalies caused by external radio frequency interference and those caused by internal software defects based on the temporal correlation between radio frequency environment metadata and communication anomaly events. This integrated approach, combining logical analysis based on a protocol state machine model, timing analysis based on a dynamic time warping algorithm, and correlation analysis based on radio frequency environment metadata, enables intelligent, multidimensional, and integrated diagnosis of wireless communication anomalies. It can automatically identify hidden logical errors and performance bottlenecks and, through temporal correlation analysis, effectively distinguish whether anomalies originate from external environmental interference or internal software defects, thus providing precise and clearly targeted root cause localization for subsequent repairs.

[0035] As an embodiment of this application, step S2 can be implemented by steps S2.1 to S2.4, as detailed below:

[0036] Step S2.1: Logical compliance analysis based on the protocol state machine model.

[0037] First, the system constructs an ideal state machine model according to the Bluetooth or Wi-Fi protocol specifications. This model defines the various protocol states (such as scanning, connecting, data transmission, and sleeping) and the legal state transition conditions. The analysis engine parses the communication sequence based on the protocol state machine model to identify protocol state transition errors. Specifically, it uses the captured communication message sequence (e.g., signaling packets) as input to drive the state machine. If a message occurs that prevents the state machine from transitioning from the current state to any next legal state, it is determined to be a protocol state transition error. For example, if a broadcast packet that should appear in the scanning state is suddenly received while the Bluetooth connection is already established, this will be identified as a protocol logic error. This is equivalent to equipping the communication process with a "protocol traffic policeman" who can automatically detect violations of traffic rules (protocol specifications).

[0038] Step S2.2: Timing compliance analysis based on the Dynamic Time Warping (DTW) algorithm.

[0039] Many performance issues in wireless devices, such as slow response and stuttering, manifest as anomalies in communication timing. The system predefines "ideal timing templates" for critical operations. For example, a complete Wi-Fi association process, from issuing a probe request to completing the four-way handshake, should be completed within a roughly defined time window under ideal network conditions, with specific time interval patterns between its sub-steps. The analysis engine uses a Dynamic Time Warping (DTW) algorithm to compare actual communication timing with the ideal timing template to identify timing anomalies. The DTW algorithm can measure the similarity between two sequences that are not perfectly aligned on the time axis, making it well-suited for handling minor time scaling caused by network jitter. By calculating the DTW distance between the actual timing sequence and the ideal template, if this distance exceeds a threshold, it is determined to be a timing anomaly. This method can sensitively detect problems that do not violate protocol logic but exhibit poor performance, such as processing delays caused by resource contention.

[0040] Step S2.3: Root cause differentiation analysis based on radio frequency environment correlation.

[0041] Based on the temporal correlation between radio frequency environment metadata and communication anomaly events, the system distinguishes between anomalies caused by external radio frequency interference and anomalies caused by internal software defects. This can be achieved through the following steps S2.3.1 to S2.3.4:

[0042] Step S2.3.1: When communication data packet loss or increased latency is detected, extract radio frequency environment metadata within the same time period.

[0043] When an abnormal event such as communication data packet loss, CRC check error, or significant increase in communication latency is identified through step S2.1 or step S2.2, the system extracts radio frequency environment metadata for the same time period. This "same time period" is usually centered on the timestamp of the abnormal event and extended forward and backward by a time window (e.g., 100 milliseconds before and after).

[0044] Step S2.3.2: Determine whether the radio frequency environment metadata exceeds the preset degradation threshold.

[0045] For example, determine whether the average RSSI during this period is below -85dBm (signal too weak) or whether the average channel utilization is above 80% (channel too congested).

[0046] Step S2.3.3: If the radio frequency environment metadata exceeds the preset deterioration threshold, it is determined that the current communication anomaly is caused by external radio frequency environment interference, and the interference type and intensity estimate are marked in the analysis results.

[0047] For example, if RSSI drops sharply while channel utilization is low, it may be inferred to be physical obstruction; if channel utilization spikes, it may be inferred to be co-channel interference. The system will record this conclusion along with the specific environmental parameters.

[0048] Step S2.3.4: If the radio frequency environment metadata does not exceed the preset deterioration threshold, it is determined that the current communication anomaly is likely caused by internal software logic or resource management defects, and a deep analysis of specific protocol layer or application layer data patterns in the air interface data is initiated.

[0049] Here, internal software logic or resource management defects may include memory leaks leading to decreased processing power, task scheduling deadlocks, buffer overflows, or code path errors triggered by specific conditions.

[0050] To further improve the differentiation accuracy, as another embodiment of this application, based on the temporal correlation between radio frequency environment metadata and communication anomaly events, distinguishing between anomalies caused by external radio frequency interference and anomalies caused by internal software defects can be achieved by: constructing a correlation timeline with time as the horizontal axis and communication anomaly events and radio frequency environment metadata as the vertical axis; applying a correlation analysis algorithm to calculate the correlation coefficient between specific types of communication anomaly events and the deterioration of radio frequency environment metadata; when the correlation coefficient exceeds a first preset threshold, it is determined that the specific type of communication anomaly event is mainly caused by external environmental interference; when the correlation coefficient is lower than a second preset threshold, and the communication anomaly exhibits a specific logical or state pattern, it is determined that the specific type of communication anomaly event is mainly caused by internal software defects. For example, the Pearson correlation coefficient between the time series of "data packet loss events" and the time series of "average channel utilization" in the past 5 minutes can be calculated. If the correlation coefficient is greater than 0.7 (first preset threshold), it is a strong correlation, and it is determined to be dominated by external interference. If the correlation coefficient is less than 0.2 (second preset threshold), but data packet loss always occurs during a specific protocol stage when the device attempts to wake up from a sleep state, it is determined to be dominated by internal software defects. The above solution concretizes the functional concept of distinguishing between internal and external factors into a mathematical model process that involves constructing a correlation timeline, calculating the correlation coefficient, and comparing it with two thresholds. This is no longer a simple "if-then" rule, but introduces quantitative statistical analysis, making the judgment process more objective and accurate, and capable of identifying complex and subtle correlation patterns, surpassing conventional threshold judgment methods.

[0051] Step S2.4: In-depth pattern analysis of internal defects.

[0052] When an anomaly is determined to be likely caused by an internal defect, the system performs deeper pattern mining on the relevant data packets. Specifically, the deep analysis of data patterns at a specific protocol layer or application layer, as described in the above embodiment, can be: for encrypted communication processes, without decrypting the application layer payload, analyzing the exchange sequence of key negotiation messages in the encrypted handshake protocol, the time intervals between messages, and the message length to identify logical vulnerabilities or performance bottlenecks in the encryption protocol implementation. This approach identifies logical vulnerabilities or performance bottlenecks by analyzing the message sequence, time intervals, and lengths of the encrypted handshake protocol without decrypting the application layer data. This breaks away from the traditional testing approach of either not testing the encrypted channel or needing to crack and decrypt it, thus verifying the quality of the security protocol implementation itself while ensuring security and privacy. In other words, problems can be discovered simply by observing the "envelope" information during the encrypted handshake phase (e.g., TLS handshake, Bluetooth LE Secure Connections pairing) without cracking the communication content. For example, discovering that the client repeatedly sends "Client Hello" multiple times without a server response may indicate a vulnerability in the server's handshake state machine; or discovering an abnormal size of the key exchange message may point to non-standard or incorrect parameter encoding.

[0053] Furthermore, the above analysis of the encrypted communication process can also verify the randomness quality of the random numbers exchanged during the encrypted handshake, detecting whether they deviate from a true random number distribution through statistical testing. If the randomness quality is lower than the security standard, the system will initiate a root cause analysis process to determine the specific source of the security vulnerability. This analysis process is implemented through multiple layers of correlation: combining lightweight performance profiling information or debugging symbols acquired synchronously during packet capture, the specific function call stack that generated the random number is located; by comparing protocol interaction characteristics (e.g., the order of supported cipher suites, specific extended fields) with version fingerprint databases of known cryptographic libraries, the cryptographic library used (e.g., OpenSSL, mbedTLS) and its possible version range are inferred; this library and version information are matched with a general vulnerability disclosure database to confirm whether a known weak random number generation vulnerability exists. Based on this precise location result, the system will mark it as a high-risk security vulnerability in the subsequently generated machine-executable defect report, explicitly pointing to the specific library to be updated, thereby setting the priority of the automated remediation trigger instruction to the highest level, triggering an emergency remediation process that includes cryptographic library updates. This mechanism for proactively verifying whether the randomness of random numbers meets security standards essentially integrates the core aspects of cryptographic security auditing into the automated testing process. Once insufficient randomness is detected, it is not only marked as a high-risk vulnerability but also triggers the highest-priority emergency remediation process, thus elevating the discovery of functional defects to the level of proactively identifying security vulnerabilities.

[0054] Step S3: Based on the results of multidimensional analysis, automatically generate a machine-executable defect report containing defect root cause speculation, affected code module location information, and automated repair trigger instructions according to a predefined structured template.

[0055] Traditional testing tools typically generate defect reports in human-readable natural language or simple log compilations. Developers need to manually extract key information, understand the problem, and then manually create tasks, pull branches, execute builds, and fill out work orders with fixed fields in version control systems, project management platforms, and continuous integration tools. This means that developers not only need to manually interpret, re-locate, and manually create remediation tasks, leading to process interruptions, inefficiency, and potential information distortion, but also, because the form information is static and descriptive, it lacks the precise machine instructions (e.g., specific code repository branches, test suite names) necessary to drive automated processes, thus failing to automatically trigger subsequent actions. To address the semantic gap and process breakpoints between the analysis conclusions and the development remediation process in the prior art, this application adopts a technical solution based on the results of multidimensional analysis. It automatically generates machine-executable defect reports containing defect root cause predictions, affected code module location information, and automated remediation trigger instructions according to a predefined structured template. This can be achieved through steps S3.1 to S3.3, as detailed below:

[0056] Step S3.1: Write the defect type, first occurrence timestamp, associated device identifier, and related protocol signaling summary into the report header.

[0057] This provides basic contextual information about the defect. For example, the header might contain: {"defect_type":"BLE_Connection_Timeout","first_seen":"2023-10-27T14:30:05Z","device_id":"Sensor_Node_05","protocol_summary":"LL_CONNECTION_UPDATE_REQ missing"}.

[0058] Step S3.2: In the report body, embed static analysis result references or dynamic execution path identifiers used to locate potential defective codes.

[0059] Step S3.2 is a crucial bridge connecting wireless layer anomalies with source code defects. Static analysis results refer to intermediate data generated during code compilation or static scanning. For example, this could be the code repository file path and line number range associated with a specific protocol stack function (e.g., l2cap_connection_update_handle). The system queries the static analysis database corresponding to the current test version to map protocol anomaly patterns (such as "connection parameter update request lost") to potentially involved source code modules. For devices supporting deep embedded tracing, lightweight instrumentation code can be implanted in their firmware. When an anomaly occurs, a simplified function call stack hash or unique trace point ID is captured and uploaded. After embedding a dynamic execution path identifier in the report body, a dedicated tracing and analysis service can subsequently reconstruct the approximate code execution path at the time of the anomaly.

[0060] Step S3.3: In the report instruction area, write a structured command to trigger a specific automated workflow. The structured command should include at least the code repository branch identifier to be pulled, the name of the test suite to be executed, and the identifier of the target device group to be deployed.

[0061] In this embodiment, the structured command used to trigger a specific automated workflow is the "executable" core of the report. It no longer describes "what" but rather specifies "what to do." The code repository branch identifier indicates which specific code branch the fix should be based on, for example, `git fetch origin fix / ble_conn_timeout`. The test suite name to be executed clarifies which targeted automated tests need to be run to verify this defect fix, for example, `pytest wifi_stress_test.py::test_high_density_association`. The deployment target device group identifier defines which specific batch of devices the new software should be deployed to after a successful fix, for example, `deploy_group:factory_sensor_line_A`.

[0062] In one embodiment of this application, the predefined structured template is in JSON-LD format, which uses associated data context to semantically associate defects, code modules, test cases and device entities, enabling different system tools to better understand the relationships between data.

[0063] In step S3, the analysis results are transformed into a structured, machine-readable data object containing executable instructions—a machine-executable defect report. This report is not only a record of defects but also a "work instruction manual" and "trigger" for subsequent automated repair processes. Because it embeds code module location information and specific operation instructions, the machine-executable defect report enables defect information to be transmitted between toolchains in a high-fidelity and lossless manner.

[0064] Step S4: Parse the automated repair trigger instructions in the machine-executable defect report, and automatically call the application programming interface of the external continuous integration system to trigger the code retrieval, compilation, and testing task chain for the defect.

[0065] Even with executable instructions, a closed loop cannot be formed if manual copying, pasting, and clicking are still required across multiple system interfaces. For example, developers manually pulling code, compiling, running tests, and deploying based on defect reports is not only slow, error-prone, and unscalable, but also has a long feedback cycle. Even writing separate fix scripts for specific defect types still has obvious drawbacks, including rigid scripts, high maintenance costs, poor scalability, inability to adapt to flexible and varied defect types and complex project environments, and disconnection from project management tools. To solve the last-mile problem of connecting and automating multiple toolchains in the DevOps process, this application parses the automated fix trigger instructions in machine-executable defect reports and automatically calls the application programming interface of an external continuous integration system to trigger a code pull, compilation, and testing task chain for the defect.

[0066] As one embodiment of this application, automatically calling the application programming interface of an external continuous integration system can be achieved through steps S4.1 to S4.3, as detailed below:

[0067] Step S4.1: Based on the structured commands in the machine-executable defect report, automatically create a defect tracking ticket in a third-party project management platform (e.g., Jira, Asana) and populate the report header and body.

[0068] Step S4.1 ensures that all related work is traceable on a unified collaboration platform, but the creation and population process requires no human intervention whatsoever.

[0069] Step S4.2: Call the application interface of the continuous integration server (e.g., Jenkins, GitLab CI) to create and start a build task. The configuration parameters of the build task are inherited from the structured commands.

[0070] Step S4.2 is crucial for automation because the system sends a request to the CI server via API to create a new build job. This job is dynamically configured: its source code repository address and branch name (fix / ble_conn_timeout) are obtained from the instructions; its build script contains a command to run the specified test suite (wifi_stress_test.py::test_high_density_association). In this way, a customized CI pipeline for fixing a specific defect is automatically created and immediately started.

[0071] Step S4.3: Monitor the execution status of the build task and synchronize the status change event to the corresponding defect tracking work order in the third-party project management platform in real time.

[0072] For example, when a CI task starts running, a test passes, a test fails, or a build completes, these status updates are automatically written back to the comments or status fields of the work order created in step S4.1 via API, achieving two-way synchronization and providing the team with real-time visibility.

[0073] In implementation scenarios that prioritize higher code quality, code review can be enforced within an automated closed loop. This includes: automatically associating the code change set corresponding to this build with the machine-executable defect report after the continuous integration server's build task passes all automated tests; automatically submitting this association information and code change set to a designated code review system (e.g., Gerrit) via an application programming interface (API), and assigning it to the responsible party related to the code module mentioned in the defect report; and only allowing the update to proceed to the subsequent over-the-air (OTL) push step after the code review system returns an approval instruction. This mechanism adds a critical human quality control point, but the submission, association, and assignment actions are all automated. The review process is seamlessly integrated into the automated pipeline, rather than a separate external process requiring manual initiation.

[0074] The technical solution in step S4 of the above example achieves cross-system, end-to-end automated process orchestration. By parsing the instructions in the report and automatically calling the application programming interface (API) of the external continuous integration system (CI), the system can automatically trigger a complete task chain from code pulling, compilation to testing, which is equivalent to automatically creating and starting a dedicated, standardized repair pipeline for each identified defect.

[0075] Step S5: After the task chain is successfully completed, the generated update program is wirelessly pushed to the wireless device. If the push fails or the device malfunctions after the update, a predefined automatic retry operation or a predefined version rollback operation is performed.

[0076] Traditional over-the-air (OTA) firmware upgrades are typically a one-way, batch push operation, lacking fine-grained management and self-healing capabilities for the push process and post-upgrade status. If a push fails or a new version introduces hidden defects, it can lead to a batch of devices becoming unusable or experiencing functional degradation, resulting in high operational risks. Therefore, this application introduces intelligent strategies and a security fallback mechanism in the deployment phase. Specifically, after the task chain is successfully completed, the generated update program is wirelessly pushed to wireless devices. In the event of a push failure or abnormal device operation after the update, a predefined automatic retry operation or a predefined version rollback operation is executed. This can be achieved through the following steps S5.1 to S5.3:

[0077] Step S5.1: Preparation and batch push.

[0078] Before initiating large-scale wireless push, the system performs pre-checks and risk controls. Specifically, before wirelessly pushing the generated update to wireless devices, a preparatory command is sent to the target device group to query the current operating status of the devices (e.g., CPU load, remaining memory, battery level) and resource availability. Only a subset of devices with normal status and sufficient resources are pushed initially, and subsequent push strategies are dynamically adjusted based on feedback from the initial batch. In practice, the system randomly or strategically selects a subset from the target device group (e.g., selecting the 10% with the strongest signal strength) as the "canary" batch. After pushing the update to this batch, the system closely monitors its key indicators (see subsequent step S5.3). If the "canary" devices perform stably during the monitoring period, the new version is considered to have low risk, and subsequent pushes are made in larger batches or in a full rollout. If the "canary" devices exhibit abnormalities, subsequent pushes are immediately suspended, and troubleshooting is initiated to minimize the potential impact.

[0079] Step S5.2: Wireless push and automatic retry.

[0080] The system pushes updates to the target device via a secure wireless connection (e.g., HTTPS, secure BLE connection). In a wireless environment, transmission may momentarily fail due to network fluctuations. To address this, the system monitors for transmission errors during the wireless push process. If the error is a network timeout or a momentary failure in data verification, it waits for an interval calculated based on an exponential backoff algorithm before automatically re-initiating the push. Specifically, the formula for calculating the exponential backoff algorithm interval can be... ,in, This is the base waiting time (e.g., 1 second). This is the current number of retries (starting from 0). This involves a small, random fluctuation (e.g., 0–100 milliseconds) to prevent network congestion caused by multiple devices retrying simultaneously. For example, the first retry might wait approximately 1–1.1 seconds, the second approximately 2–2.1 seconds, and so on, until the maximum number of retries is reached. This strategy effectively improves push success rates during periods of temporary network congestion while avoiding continuous stress on the network and devices.

[0081] Step S5.3: Post-update monitoring and dynamic rollback.

[0082] Successful push notifications are not the end of the process; ensuring stable operation of the updated devices is even more critical. This application introduces a proactive health monitoring and automatic rollback mechanism. Specifically, after a successful update push, a dynamically defined monitoring period is initiated. Within this period, the communication status of the wireless device is continuously monitored, and a set of health indicators is calculated in real time. These indicators include connection success rate, average response latency, and frequency of specific error codes per unit time. If any health indicator deteriorates beyond its corresponding safety threshold, a rollback process is immediately triggered. The software image of the previous globally stable version is retrieved from the security repository and automatically deployed to the wireless device. This solution upgrades version rollback from a possible manual recovery operation to an automated security mechanism based on real-time evaluation of multi-dimensional health indicators (including connection success rate, response latency, etc.). It defines a dynamic monitoring period and sets specific, quantifiable trigger conditions. This allows the system to not only automatically repair but also automatically verify the repair effect and automatically roll back when failure occurs, forming a highly valuable "security closed-loop" sub-function.

[0083] The monitoring period in the above embodiments can be dynamically determined as follows: based on the complexity level of the code modules modified in this update, the stability rate of historical versions, and the risk level of the functions involved, a weighted calculation model is used to dynamically generate the monitoring period for this update, with higher-risk core function updates corresponding to longer monitoring periods. If... If the monitoring period is specified, then dynamically determining the monitoring period can be achieved through the following model:

[0084]

[0085] in, Indicates the basic monitoring duration (e.g., 1 hour). This indicates the code complexity level (e.g., level 1 to 5, where the core of the protocol stack is modified to level 5). This indicates the stability rate of the module's historical versions ( (can be a decimal between 0 and 1) Indicates the functional risk level (e.g., level 1 to 5, where power management is level 5). , and These represent the weight coefficients of each factor.

[0086] This model ensures a longer "trial period" of observation for high-risk changes, while quickly ending monitoring for low-risk patches to free up resources.

[0087] During the monitoring period, the system continuously performs lightweight listening and analysis similar to steps S1 and S2, calculating the average health metrics of the device group. Each metric has a dynamic safety threshold, which may be calculated based on the baseline performance of the device in the 7 days prior to the update (e.g., baseline average response latency + 3 standard deviation). Once a metric continues to deteriorate and exceeds the threshold, the rollback process is automatically triggered to ensure that the user is restored to a stable state with minimal or no impact.

[0088] In this embodiment, the entire closed-loop system possesses the ability to learn from each repair event to continuously optimize the accuracy of its core—the analysis model. Specifically, Figure 1 The example method also includes a mechanism for online self-learning of the machine learning model: communication data and corresponding RF environment metadata of the wireless device during the operation of the new software version are collected as feedback data after the closed-loop repair is completed; the feedback data is compared and analyzed with the data that caused the defect before the repair; if the same type of anomaly does not reappear, the feedback data is used as a negative sample; if a new anomaly pattern appears, the feedback data is used as a new positive sample; the new samples are used to periodically perform incremental training on the machine learning model to optimize its analytical accuracy. In specific implementation, the system maintains a feedback data pool. After each successful closed-loop (from problem discovery to stable deployment and operation of the repair), data labeled "normal" generated by the new version device during the monitoring period and for a period thereafter is collected. If the pattern previously marked as "Defect A" disappears in this new data, then this new data is used as a negative sample indicating "Defect A has been repaired". If an anomaly pattern that the previous model failed to identify is found in this new data, it is marked as a new positive sample. Regularly (e.g., weekly) use these new and old samples to incrementally train or fine-tune the original machine learning model, enabling the model to adapt to new software versions and device operating environments, achieving an evolution that becomes more accurate with use.

[0089] The aforementioned mechanism for online self-learning of machine learning models enables the core of the system's intelligent analysis to have self-evolution capabilities. In other words, it uses the feedback data generated after closed-loop repair to automatically generate positive / negative samples for incremental training of the model. This breaks the boundary between model training and model use in traditional testing systems, enabling the system to adapt to new defect patterns and environmental changes, continuously improve diagnostic accuracy, and constitute a growth-oriented intelligent subsystem.

[0090] This application's closed-loop mechanism not only fixes the current defects but also aims to prevent the recurrence of similar problems. Based on the accurate root cause determination in step S2, the results are also used to guide the automatic generation of test cases. Specifically, when it is determined that a specific type of communication anomaly is mainly caused by external environmental interference, hardware-in-the-loop test cases simulating different intensities and types of radio frequency interference are automatically generated; when it is determined that a specific type of communication anomaly is mainly caused by internal software defects, fuzz test or concurrent stress test cases targeting specific logic or state patterns are automatically generated; and the hardware-in-the-loop test cases and fuzz test or concurrent stress test cases are added to the regression test set.

[0091] In practical implementation, for external interference root causes, the system calls the control API of the RF signal generator to generate test case scripts containing corresponding interference characteristics (e.g., continuous wave interference at a specific frequency, pulse noise conforming to a specific pattern). These scripts can be automatically executed in subsequent hardware-in-the-loop testing environments. For internal defect root causes, the system automatically constructs boundary conditions, abnormal inputs, or high-concurrency scenarios based on the protocol state sequence or data pattern triggered by the defect, generating targeted fuzzing or test case scripts to test the robustness of the corresponding code modules. These newly generated test cases are automatically added to the project's regression test set. In each subsequent CI task chain (step S4), these test cases will be automatically executed, thereby forming "immune memory" against previously encountered problem types at the code level, preventing regression and greatly improving the long-term quality of the software product.

[0092] From the above appendix Figure 1The example of automated testing and closed-loop repair methods for wireless device software demonstrates that, on the one hand, analyzing communication sequences based on protocol state machine models can efficiently identify logical software defects such as non-compliant state transitions. By comparing timing sequences using dynamic time warping algorithms, performance defects caused by resource contention and deadlocks can be effectively discovered. More importantly, by correlating communication anomalies with real-time RF environment metadata, it can automatically determine whether the anomaly originates from external environmental interference or internal software faults. This automated, multi-dimensional fusion analysis method reduces reliance on human experience and significantly improves the accuracy and efficiency of problem diagnosis. On the other hand, the results of multi-dimensional analysis are automatically generated into machine-executable defect reports containing automated repair trigger instructions, and external system interfaces are automatically invoked to trigger subsequent task chains. This achieves seamless automated integration from defect identification to development and repair processes. This is because the structured defect report not only describes "what" the problem is, but also... Furthermore, the built-in instructions specify "how to fix" the issue, enabling downstream development and operations toolchains to directly understand and process defect information. This design breaks down the traditionally fragmented testing, development, and deployment processes, allowing the entire fix workflow to flow automatically and significantly reducing the delay from problem discovery to fix initiation. Thirdly, by automatically pushing updates wirelessly after a successful task chain and performing automatic retries or version rollbacks in case of anomalies, a complete and adaptive software delivery and operations loop is formed. The automatic deployment mechanism ensures that fixes quickly reach end devices, while the built-in retry and rollback strategies provide the system with adaptive fault tolerance and recovery capabilities against network fluctuations and compatibility issues that may occur during and after deployment. This not only improves the success rate and reliability of software updates but also constitutes a secure closed loop that can self-verify fix effects and automatically ensure system stability, thereby comprehensively improving the quality of wireless device software lifecycle management and user experience. In summary, the technical solution of this application, through intelligent analysis to distinguish the root causes of defects and automatically trigger the fix process, achieves a rapid and reliable closed loop for wireless device software from testing and fixes to deployment.

[0093] Please see the appendix Figure 2 This application provides an automatic testing and closed-loop repair device for wireless device software, comprising an acquisition module 201, an analysis module 202, a generation module 203, a calling module 204, and a closed-loop deployment module 205, as detailed below:

[0094] The acquisition module 201 is used to listen to the communication channel during the operation of the wireless device and acquire air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata.

[0095] Analysis module 202 is used to perform multidimensional analysis on the air interface data using a machine learning model. The multidimensional analysis includes at least: parsing the communication sequence based on the protocol state machine model to identify protocol state transition errors; comparing the actual communication timing with the ideal timing template based on the dynamic time warping algorithm to identify timing anomalies; and distinguishing between anomalies caused by external radio frequency interference and anomalies caused by internal software defects based on the temporal correlation between radio frequency environment metadata and communication anomaly events.

[0096] The generation module 203 is used to automatically generate a machine-executable defect report based on the results of multidimensional analysis and according to a predefined structured template. The report includes defect root cause speculation, affected code module location information, and automated repair trigger instructions.

[0097] Module 204 is called to parse the automated repair trigger instructions in the machine-executable defect report and automatically call the application interface of the external continuous integration system to trigger the code retrieval, compilation, and testing task chain for the defect;

[0098] The closed-loop deployment module 205 is used to wirelessly push the generated update program to the wireless device after the task chain is successfully completed, and to perform predefined automatic retry operations or predefined version rollback operations when the push fails or the device runs abnormally after the update.

[0099] From the above appendix Figure 2As illustrated by the example of an automated testing and closed-loop repair device for wireless device software, on the one hand, by analyzing communication sequences based on a protocol state machine model, logical software defects such as non-compliant state transitions can be efficiently identified. By comparing timing sequences using a dynamic time warping algorithm, performance defects caused by resource contention and deadlocks can be effectively discovered. More importantly, by correlating communication anomalies with real-time RF environment metadata, it can automatically determine whether the anomaly originates from external environmental interference or internal software faults. This automated, multi-dimensional fusion analysis method reduces reliance on human experience and significantly improves the accuracy and efficiency of problem diagnosis. On the other hand, the results of multi-dimensional analysis are automatically generated into a machine-executable defect report containing automated repair trigger instructions, and external system interfaces are automatically called to trigger subsequent task chains. This achieves seamless automated integration from defect identification to development and repair processes. This is because the structured defect report not only describes "what" the problem is, but also... Furthermore, the built-in instructions specify "how to fix" the issue, enabling downstream development and operations toolchains to directly understand and process defect information. This design breaks down the traditionally fragmented testing, development, and deployment processes, allowing the entire fix workflow to flow automatically and significantly reducing the delay from problem discovery to fix initiation. Thirdly, by automatically pushing updates wirelessly after a successful task chain and performing automatic retries or version rollbacks in case of anomalies, a complete and adaptive software delivery and operations loop is formed. The automatic deployment mechanism ensures that fixes quickly reach end devices, while the built-in retry and rollback strategies provide the system with adaptive fault tolerance and recovery capabilities against network fluctuations and compatibility issues that may occur during and after deployment. This not only improves the success rate and reliability of software updates but also constitutes a secure closed loop that can self-verify fix effects and automatically ensure system stability, thereby comprehensively improving the quality of wireless device software lifecycle management and user experience. In summary, the technical solution of this application, through intelligent analysis to distinguish the root causes of defects and automatically trigger the fix process, achieves a rapid and reliable closed loop for wireless device software from testing and fixes to deployment.

[0100] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 3 in this embodiment mainly includes: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program for an automatic testing and closed-loop repair method for wireless device software. When the processor 30 executes the computer program 32, it implements the steps in the above-described embodiment of the automatic testing and closed-loop repair method for wireless device software, for example... Figure 1 Steps S1 to S5 are shown. Alternatively, when processor 30 executes computer program 32, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 2The functions of the acquisition module 201, analysis module 202, generation module 203, calling module 204, and closed-loop deployment module 205 are shown.

[0101] For example, the computer program 32 of the automatic testing and closed-loop repair method for wireless device software mainly includes: listening to the communication channel during the operation of the wireless device to obtain air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata; performing multidimensional analysis on the air interface data using a machine learning model, which includes at least: parsing the communication sequence based on the protocol state machine model to identify protocol state transition errors, comparing the actual communication timing with the ideal timing template based on the dynamic time warping algorithm to identify timing anomalies, and distinguishing anomalies caused by external radio frequency interference based on the temporal correlation between radio frequency environment metadata and communication anomaly events. The system handles anomalies caused by internal software defects. Based on the results of multidimensional analysis, it automatically generates a machine-executable defect report containing defect root cause prediction, affected code module location information, and automated repair trigger instructions according to a predefined structured template. It parses the automated repair trigger instructions in the machine-executable defect report and automatically calls the application programming interface of an external continuous integration system to trigger a code retrieval, compilation, and testing task chain targeting the defect. After the task chain is successfully completed, the generated update program is wirelessly pushed to a wireless device. If the push fails or the device malfunctions after the update, a predefined automatic retry operation or a predefined version rollback operation is executed. The computer program 32 can be divided into one or more modules / units, which are stored in memory 31 and executed by processor 30 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 32 in the electronic device 3.For example, computer program 32 can be divided into the functions of acquisition module 201, analysis module 202, generation module 203, invocation module 204, and closed-loop deployment module 205 (a module in the virtual device). The specific functions of each module are as follows: Acquisition module 201 is used to listen to the communication channel during the operation of the wireless device and acquire air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata; Analysis module 202 is used to perform multidimensional analysis on the air interface data using a machine learning model. This multidimensional analysis includes at least: parsing the communication sequence based on the protocol state machine model to identify protocol state transition errors, comparing the actual communication timing with the ideal timing template based on the dynamic time warping algorithm to identify timing anomalies, and comparing the time relationship between radio frequency environment metadata and communication anomaly events. The system distinguishes between anomalies caused by external radio frequency interference and those caused by internal software defects. A generation module 203 automatically generates a machine-executable defect report based on the results of multidimensional analysis and a predefined structured template. This report includes root cause predictions, affected code module location information, and automated repair trigger instructions. A calling module 204 parses the automated repair trigger instructions in the machine-executable defect report and automatically calls the application programming interface of an external continuous integration system to trigger a code retrieval, compilation, and testing task chain targeting the defect. A closed-loop deployment module 205 wirelessly pushes the generated update program to wireless devices after the task chain is successfully completed. In case of push failure or abnormal operation after device update, it executes predefined automatic retry operations or predefined version rollback operations.

[0102] Electronic device 3 may include, but is not limited to, processor 30 and memory 31. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0103] The processor 30 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0104] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0105] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed. That is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above-described device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0106] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0107] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0109] 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.

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

[0111] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program for the automatic testing and closed-loop repair method of wireless device software can be stored in a storage medium. When executed by a processor, this computer program can implement the steps of the various method embodiments described above, namely, listening to the communication channel during the operation of the wireless device, acquiring air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata; performing multidimensional analysis on the air interface data using a machine learning model, which includes at least: parsing the communication sequence based on a protocol state machine model to identify protocol state transition errors, and comparing the actual communication timing with an ideal timing template based on a dynamic time warping algorithm to identify timing errors. The system identifies anomalies and distinguishes between those caused by external radio frequency interference and those caused by internal software defects based on the temporal correlation between radio frequency environment metadata and communication anomaly events. Based on the results of multidimensional analysis, it automatically generates machine-executable defect reports containing defect root cause predictions, affected code module location information, and automated repair trigger instructions according to a predefined structured template. It parses the automated repair trigger instructions in the machine-executable defect reports and automatically calls the application programming interface of an external continuous integration system to trigger a code retrieval, compilation, and testing task chain targeting the defect. Upon successful completion of the task chain, the generated update program is wirelessly pushed to wireless devices. In case of push failure or abnormal operation after device update, predefined automatic retry operations or predefined version rollback operations are executed. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Storage media can include any entity or device capable of carrying computer program code, recording media, USB flash drives, external hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the contents of the storage medium may be appropriately added to or subtracted from the contents according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the storage medium may not include electrical carrier signals and telecommunication signals.

[0112] 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. These 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, and should all be included within the protection scope of this application. The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the protection scope of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. An automatic testing and closed-loop repair method for wireless device software, characterized in that, Includes the following steps: During the operation of the wireless device, the communication channel is monitored to obtain air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata; The air interface data is subjected to multidimensional analysis using a machine learning model. The multidimensional analysis includes at least: parsing the communication sequence based on the protocol state machine model to identify protocol state transition errors; comparing the actual communication timing with the ideal timing template based on the dynamic time warping algorithm to identify timing anomalies; and distinguishing between anomalies caused by external radio frequency interference and anomalies caused by internal software defects based on the temporal correlation between the radio frequency environment metadata and communication anomaly events. Based on the results of the multidimensional analysis, a machine-executable defect report is automatically generated according to a predefined structured template, which includes defect root cause speculation, affected code module location information, and automated repair trigger instructions. The machine can parse the automated repair trigger instructions in the defect report, automatically call the application programming interface of the external continuous integration system, and trigger a code retrieval, compilation, and testing task chain for the defect; and After the task chain is successfully completed, the generated update program is wirelessly pushed to the wireless device. If the push fails or the device malfunctions after the update, a predefined automatic retry operation or a predefined version rollback operation is performed.

2. The automatic testing and closed-loop repair method for wireless device software according to claim 1, characterized in that, The distinction between anomalies caused by external radio frequency interference and anomalies caused by internal software defects, based on the temporal correlation between the radio frequency environment metadata and communication anomaly events, includes: When communication data packet loss or increased latency is detected, the radio frequency environment metadata for the same time period is extracted; Determine whether the radio frequency environment metadata exceeds a preset degradation threshold; If the radio frequency environment metadata exceeds the preset degradation threshold, it is determined that the current communication anomaly is caused by external radio frequency environment interference, and the interference type and intensity estimate are marked in the analysis results. If the radio frequency environment metadata does not exceed the preset deterioration threshold, it is determined that the current communication anomaly is likely caused by internal software logic or resource management defects, and a deep analysis of specific protocol layer or application layer data patterns in the air interface data is initiated.

3. The automatic testing and closed-loop repair method for wireless device software according to claim 2, characterized in that, The initiation of in-depth analysis targeting specific protocol layer or application layer data patterns includes: For encrypted communication processes, without decrypting the application layer payload, we analyze the exchange sequence of key negotiation messages, the time interval between messages, and the message length in the encrypted handshake protocol to identify logical vulnerabilities or performance bottlenecks in the encryption protocol implementation.

4. The automatic testing and closed-loop repair method for wireless device software according to claim 1, characterized in that, The distinction between anomalies caused by external radio frequency interference and anomalies caused by internal software defects, based on the temporal correlation between the radio frequency environment metadata and communication anomaly events, includes: Construct a correlated timeline with time as the horizontal axis and communication anomalies and radio frequency environment metadata as the vertical axis; Using correlation analysis algorithms, the correlation coefficients between specific types of communication anomalies and the degradation of radio frequency environment metadata are calculated. When the correlation coefficient exceeds the first preset threshold, it is determined that the specific type of communication anomaly is mainly caused by external environmental interference. When the correlation coefficient is lower than the second preset threshold and the communication anomaly exhibits a specific logic or state pattern, it is determined that the specific type of communication anomaly is mainly caused by internal software defects.

5. The automatic testing and closed-loop repair method for wireless device software according to claim 1, characterized in that, The execution of the predefined version rollback operation includes: After successfully pushing the update, a dynamically determined monitoring period is initiated. During the dynamically determined monitoring period, the communication status of the wireless device is continuously monitored, and a set of health indicators are calculated in real time. The health indicators include the connection success rate, average response latency, and frequency of occurrence of specific error codes per unit time. If any health indicator deteriorates beyond its corresponding safety threshold, a rollback process is immediately triggered to retrieve the software image of the previous globally stable version from the security repository and automatically deploy it to the wireless device.

6. The automatic testing and closed-loop repair method for wireless device software according to claim 3, characterized in that, The analysis of the encrypted communication process also includes: Verify the randomness quality of the random numbers exchanged during the encrypted handshake process, and detect whether they deviate from the distribution of true random numbers through statistical tests; If the randomness quality is below the security standard, it is marked as a high-risk security vulnerability in the machine executable defect report, and the priority of the automated remediation trigger instruction is set to the highest to trigger an emergency remediation process that includes cryptographic library updates.

7. The automatic testing and closed-loop repair method for wireless device software according to claim 1, characterized in that, The method further includes the following step of performing online self-learning of the machine learning model: After the closed-loop repair is completed, the communication data and corresponding radio frequency environment metadata of the wireless device during the operation of the new version of the software are collected as feedback data. The feedback data is compared and analyzed with the data that caused the defects before the repair. If the same type of anomaly does not reappear, the feedback data is used as a negative sample. If a new anomaly pattern appears, the feedback data is used as a new positive sample. The machine learning model is incrementally trained periodically using newly added samples to optimize its analytical accuracy.

8. An automatic testing and closed-loop repair device for wireless device software, characterized in that, The device includes: The acquisition module is used to listen to the communication channel during the operation of the wireless device and acquire air interface data containing at least Bluetooth or Wi-Fi protocols and corresponding radio frequency environment metadata; The analysis module is used to perform multidimensional analysis on the air interface data using a machine learning model. The multidimensional analysis includes at least: parsing the communication sequence based on the protocol state machine model to identify protocol state transition errors; comparing the actual communication timing with the ideal timing template based on the dynamic time warping algorithm to identify timing anomalies; and distinguishing between anomalies caused by external radio frequency interference and anomalies caused by internal software defects based on the temporal correlation between the radio frequency environment metadata and communication anomaly events. The generation module is used to automatically generate a machine-executable defect report based on the results of the multidimensional analysis and according to a predefined structured template. The report includes defect root cause prediction, affected code module location information, and automated repair trigger instructions. The calling module is used to parse the automated repair triggering instructions in the machine executable defect report and automatically call the application interface of the external continuous integration system to trigger the code retrieval, compilation, and testing task chain for the defect; The closed-loop deployment module is used to wirelessly push the generated update program to the wireless device after the task chain is successfully completed, and to perform predefined automatic retry operations or predefined version rollback operations when the push fails or the device runs abnormally after the update.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images