Multi-version circular upgrading method and device for equipment, equipment and storage medium

Abstract

The invention discloses an equipment multi-version circulating upgrading method and device, equipment and a storage medium, and relates to the technical field of software upgrading queries, the method comprises the following steps: obtaining a target equipment set, a plurality of software upgrading versions and an upgrading sequence of the plurality of software upgrading versions according to pressure test task configuration, generating a corresponding circulating upgrading sequence according to the plurality of software upgrading versions and the upgrading sequence; for each target device in the target device set, sequentially sending an upgrading instruction corresponding to the current software upgrading version to the target device according to a circular upgrading sequence; and receiving state information returned by the target equipment after finishing the upgrading instruction, and executing the upgrading of the next software upgrading version according to the state information, or stopping the current round of upgrading. Through the mode, the stability and the reliability of the upgrade link in the limit scene are simulated by switching the software upgrade version back and forth at a high frequency, the test coverage is improved, upgrade instructions do not need to be manually issued one by one, and the test efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of software upgrade query technology, and more specifically, to a method, apparatus, device, and storage medium for multi-version cyclic upgrade of a device. Background Technology

[0002] With the explosive growth of the Internet of Things (IoT) and embedded devices, remote firmware upgrades have become commonplace. In scenarios such as smart homes, industrial sensing, and connected vehicles, devices must undergo frequent upgrades to patch security vulnerabilities, expand business functions, or adapt to new protocols. Upgrades have evolved into a core part of device lifecycle management.

[0003] In actual deployment, devices may need to be upgraded repeatedly between multiple versions (such as version rollback, alternating upgrades) to verify the compatibility, stability and reliability of the upgrade path.

[0004] However, existing testing methods are difficult to simulate such complex multi-version cyclical upgrade scenarios. In the testing of large-scale device clusters, testers need to manually configure upgrade tasks frequently, which reduces testing efficiency. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for multi-version cyclic upgrades of devices, in order to solve the problem that existing testing methods are difficult to simulate such complex multi-version cyclic upgrade scenarios. In the testing of large-scale device clusters, testers need to frequently manually configure upgrade tasks, which reduces testing efficiency.

[0006] Firstly, this application provides a method for cyclical upgrades of multiple versions of a device, including:

[0007] Based on the load testing task configuration, obtain the target device set, multiple software upgrade versions corresponding to the target device set, and the upgrade order of the multiple software upgrade versions, and generate a corresponding cyclic upgrade sequence based on the multiple software upgrade versions and the upgrade order;

[0008] For each target device in the target device set, upgrade instructions corresponding to the current software upgrade version are sent to the target device sequentially according to the cyclic upgrade sequence;

[0009] Receive the status information returned by the target device after completing the upgrade instruction, and execute the next software upgrade version upgrade according to the status information, or abort the current upgrade;

[0010] The cyclic upgrade sequence is used to perform multiple version switches on the target device set to simulate the pressure under high-frequency cyclic scenarios.

[0011] In one possible implementation, the step of performing the next software upgrade version based on the status information, or terminating the current upgrade, includes:

[0012] When the status information indicates that the upgrade is successful, the upgrade instruction corresponding to the next software upgrade version is issued based on the cyclic upgrade sequence, until the last version of the cyclic upgrade sequence is successfully upgraded;

[0013] Reset the sequence pointer to the first version of the cyclic upgrade sequence and start the next round of pressure testing cycle until the preset pressure testing stop condition is met;

[0014] When the status information indicates that the upgrade has failed, the issuance of subsequent upgrade instructions will be suspended and the failure event will be recorded.

[0015] Once the fault is cleared, continue stress testing of the remaining cyclic upgrade sequence from the failed version.

[0016] In one possible implementation, before generating the corresponding cyclic upgrade sequence based on the plurality of software upgrade versions and the upgrade order, the method further includes:

[0017] Generate a task identifier corresponding to the load testing task;

[0018] The task identifier, the cyclic upgrade sequence, and the device identifiers of each target device in the target device set are bound and stored to establish a target mapping relationship that indicates the correspondence between the task, device, and sequence.

[0019] In one possible implementation, binding and storing the task identifier, the cyclic upgrade sequence, and the device identifiers of each target device in the target device set includes:

[0020] The task identifier, the device identifier, and the version identifier of the cyclic upgrade sequence are stored using a three-level association structure of task-device-sequence to obtain the target mapping relationship;

[0021] The task identifier is associated with the device identifier, the device identifier is associated with the version identifier, and the version identifier is associated with the status information returned during the upgrade process, so as to support multi-dimensional inspection of the stress test log.

[0022] In one possible implementation, after receiving the status information returned by the target device after completing the upgrade instruction, the method further includes:

[0023] A version pair is formed based on the source version number and target version number in the status information;

[0024] Retrieve historical stress test and upgrade logs, and query the historical stress test and upgrade logs to obtain the version pair, the corresponding number of failures, and the total number of upgrades;

[0025] A compatibility score is obtained and stored based on the number of failures and the total number of upgrades. The compatibility score is used to sort multiple software upgrade versions in the next load testing task to obtain a suitable cyclic upgrade sequence.

[0026] In one possible implementation, obtaining the compatibility score based on the number of failures and the total number of upgrades includes:

[0027] The number of recent failures within a preset time period is obtained from the number of failures, and the number of recent upgrades within the preset time period is obtained from the total number of upgrades;

[0028] The historical success rate is determined based on the number of failures and the total number of upgrades, and the recent success rate is determined based on the number of recent failures and the number of recent upgrades.

[0029] The historical success rate and the recent success rate are processed by a weighted algorithm to obtain a compatibility score, which reflects the stability of the version under stress testing environment.

[0030] In one possible implementation, after processing the historical success rate and the recent success rate using a weighted algorithm to obtain a compatibility score, the method further includes:

[0031] Determine the relationship between the compatibility score and the compatibility score threshold;

[0032] When the compatibility score is less than the compatibility score threshold, the testing priority of the version pair will be advanced in the next load testing cycle to prioritize the verification of the stability of the low compatibility version combination.

[0033] Secondly, this application provides a device for multi-version cyclic upgrades, the device comprising:

[0034] The determination module is used to obtain a target device set, multiple software upgrade versions corresponding to the target device set, and the upgrade order of the multiple software upgrade versions according to the load testing task configuration, and generate a corresponding cyclic upgrade sequence according to the multiple software upgrade versions and the upgrade order;

[0035] The sending module is used to send the upgrade command corresponding to the current software upgrade version to each target device in the target device set in accordance with the cyclic upgrade sequence;

[0036] The control module is used to receive the status information returned by the target device after completing the upgrade instruction, and to execute the next software upgrade version upgrade or terminate the current upgrade based on the status information;

[0037] The cyclic upgrade sequence is used to perform multiple version switches on the target device set to simulate the pressure under high-frequency cyclic scenarios.

[0038] In one possible implementation, the control module is further configured to:

[0039] When the status information indicates that the upgrade is successful, the upgrade instruction corresponding to the next software upgrade version is issued based on the cyclic upgrade sequence, until the last version of the cyclic upgrade sequence is successfully upgraded;

[0040] Reset the sequence pointer to the first version of the cyclic upgrade sequence and start the next round of pressure testing cycle until the preset pressure testing stop condition is met;

[0041] When the status information indicates that the upgrade has failed, the issuance of subsequent upgrade instructions will be suspended and the failure event will be recorded.

[0042] Once the fault is cleared, continue stress testing of the remaining cyclic upgrade sequence from the failed version.

[0043] In one possible implementation, the control module is further configured to:

[0044] Generate a task identifier corresponding to the load testing task;

[0045] The task identifier, the cyclic upgrade sequence, and the device identifiers of each target device in the target device set are bound and stored to establish a target mapping relationship that indicates the correspondence between the task, device, and sequence.

[0046] In one possible implementation, the control module is further configured to:

[0047] The task identifier, the device identifier, and the version identifier of the cyclic upgrade sequence are stored using a three-level association structure of task-device-sequence to obtain the target mapping relationship;

[0048] The task identifier is associated with the device identifier, the device identifier is associated with the version identifier, and the version identifier is associated with the status information returned during the upgrade process, so as to support multi-dimensional inspection of the stress test log.

[0049] In one possible implementation, the control module is further configured to:

[0050] A version pair is formed based on the source version number and target version number in the status information;

[0051] Retrieve historical stress test and upgrade logs, and query the historical stress test and upgrade logs to obtain the version pair, the corresponding number of failures, and the total number of upgrades;

[0052] A compatibility score is obtained and stored based on the number of failures and the total number of upgrades. The compatibility score is used to sort multiple software upgrade versions in the next load testing task to obtain a suitable cyclic upgrade sequence.

[0053] In one possible implementation, the control module is further configured to:

[0054] The number of recent failures within a preset time period is obtained from the number of failures, and the number of recent upgrades within the preset time period is obtained from the total number of upgrades;

[0055] The historical success rate is determined based on the number of failures and the total number of upgrades, and the recent success rate is determined based on the number of recent failures and the number of recent upgrades.

[0056] The historical success rate and the recent success rate are processed by a weighted algorithm to obtain a compatibility score, which reflects the stability of the version under stress testing environment.

[0057] In one possible implementation, the control module is further configured to:

[0058] Determine the relationship between the compatibility score and the compatibility score threshold;

[0059] When the compatibility score is less than the compatibility score threshold, the testing priority of the version pair will be advanced in the next load testing cycle to prioritize the verification of the stability of the low compatibility version combination.

[0060] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0061] The memory stores computer-executed instructions;

[0062] The processor executes computer execution instructions stored in the memory to implement the device multi-version cyclic upgrade method as described in the first aspect.

[0063] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, are used to implement the device multi-version cyclic upgrade method as described in the first aspect.

[0064] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps of the scheme recommendation method as described in any of the foregoing claims.

[0065] This invention provides a method, apparatus, device, and storage medium for multi-version cyclic upgrades of devices. Based on a stress testing task configuration, a cyclic upgrade sequence containing multiple software upgrade versions and their upgrade order is generated. Then, upgrade commands for the current software upgrade version are issued to each target device in the target device set according to the cyclic upgrade sequence, and status information is received. If the status information is normal, the upgrade continues to the next version; otherwise, the current upgrade round is terminated. Through this method, the stability and reliability of the upgrade chain under extreme scenarios are simulated by frequently switching between software upgrade versions, improving test coverage and eliminating the need for manually issuing upgrade commands one by one, thus improving test efficiency. Attached Figure Description

[0066] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0067] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0068] Figure 1 A flowchart illustrating a device multi-version cyclic upgrade method provided in this application embodiment. Figure 1 ;

[0069] Figure 2 A flowchart illustrating a device multi-version cyclic upgrade method provided in this application embodiment. Figure 2 ;

[0070] Figure 3 This is a schematic diagram of the structure of a device for multi-version cyclic upgrade provided in an embodiment of this application;

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

[0072] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions 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, 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.

[0073] The explosive growth of the Internet of Things (IoT) and embedded devices has made remote firmware upgrades commonplace. In scenarios such as smart homes, industrial sensing, and connected vehicles, devices must undergo frequent upgrades to patch security vulnerabilities, expand business functions, or adapt to new protocols. Upgrades have evolved into a core part of device lifecycle management. In actual deployments, devices may need to be upgraded repeatedly between multiple versions (such as version rollbacks and alternating upgrades) to verify the compatibility, stability, and reliability of the upgrade path. However, existing testing methods are difficult to simulate this complex multi-version cyclical upgrade scenario. In testing large-scale device clusters, testers need to frequently manually configure upgrade tasks, resulting in low testing efficiency.

[0074] This invention provides a method for cyclical upgrades of multiple software versions for devices. Based on the load testing task configuration, a cyclical upgrade sequence containing multiple software upgrade versions and their order is generated. Then, upgrade commands for the current software upgrade version are issued to each target device in the target device set according to the cyclical upgrade sequence, and status information is received. If the status information is normal, the upgrade continues to the next version; otherwise, the current upgrade round is aborted. This method, by frequently switching between software upgrade versions, simulates the stability and reliability of the upgrade chain under extreme scenarios, improving test coverage, and eliminating the need for manually issuing upgrade commands one by one, thus improving testing efficiency.

[0075] Figure 1 A flowchart illustrating a device multi-version cyclic upgrade method provided in this application embodiment. Figure 1 .like Figure 1 As shown, the method includes:

[0076] S101. Based on the load testing task configuration, obtain the target device set, the multiple software upgrade versions corresponding to the target device set, and the upgrade order of the multiple software upgrade versions, and generate the corresponding cyclic upgrade sequence based on the multiple software upgrade versions and the upgrade order.

[0077] In this step, the explosive growth of IoT and embedded devices has made remote firmware upgrades commonplace. In scenarios such as smart homes, industrial sensing, and connected vehicles, devices must undergo frequent upgrades to patch security vulnerabilities, expand business functions, or adapt to new protocols. Upgrades have evolved into a core part of device lifecycle management. In actual deployments, devices may need to be upgraded repeatedly between multiple versions (such as version rollbacks and alternating upgrades) to verify the compatibility, stability, and reliability of the upgrade path. However, existing testing methods struggle to simulate this complex multi-version cyclical upgrade scenario. In testing large-scale device clusters, testers frequently need to manually configure upgrade tasks, leading to low testing efficiency.

[0078] Therefore, this embodiment simulates the real scenario of repeated upgrades between multiple versions of the device by pre-setting a version sequence and automatically triggering upgrade commands, so as to simulate the stability and reliability of the upgrade link under extreme scenarios.

[0079] This embodiment does not impose specific limitations on multiple versions and their corresponding upgrade order, which can be selected according to the actual situation. For example, the upgrade order can be determined according to the version identifier from smallest to largest, such as V1.0-V2.0-V3.0. Furthermore, based on the version test failure rate, the testing priority of versions with higher failure rates can be advanced.

[0080] After determining multiple versions and upgrade sequences, a corresponding cyclical upgrade sequence is generated.

[0081] In one possible implementation, in scenarios involving concurrent upgrades of numerous devices, the same task often spans multiple versions, involves a massive number of devices, and requires rollback and traceability of upgrade results. Traditional logs only use task identifiers or device identifiers as independent indexes, leading to full table scans for cross-queries such as "search for device by version" and "search for version by device," which can take minutes or even tens of minutes, failing to meet the real-time requirements of fault location. Therefore, it is necessary to bind the task, device, and version together at the same time as writing the log, forming a horizontally penetrable relational storage, establishing a data foundation for subsequent multi-dimensional retrieval. The implementation method is as follows:

[0082] Generate a task identifier corresponding to the load testing task;

[0083] The task identifier, the cyclic upgrade sequence, and the device identifier of each target device in the target device set are bound and stored to establish a target mapping relationship that indicates the correspondence between the task, device, and sequence.

[0084] Specifically, the upgrade scheduling engine generates a globally unique task identifier when creating an upgrade task and writes this task identifier and a list of device identifiers for the target devices into a "task-device" mapping table. Then, when a device starts downloading a specified version, the system generates a "device-version" mapping table with the device identifier as the primary key and the version identifier as the attribute value, while embedding the task identifier as a foreign key into this mapping table. After the device reports status information indicating the upgrade result, the system writes this status information into the "version identifier-status information" mapping table and associates it with the "device-version" mapping table using the version identifier as a foreign key. Finally, the above three mapping tables are committed all at once through the same database transaction, ensuring the atomicity and integrity of the four-level link of "task identifier-device identifier-version identifier-status information," thus completing the three-level associative structure storage.

[0085] S102. For each target device in the target device set, according to the cyclic upgrade sequence, send the upgrade command corresponding to the current software upgrade version to the target device in sequence, and receive the status information returned by the target device after completing the upgrade command.

[0086] In this step, after obtaining the cyclic upgrade sequence, upgrade commands are sent to the target device according to the order of the cyclic upgrade sequence.

[0087] The system scheduler maintains a cyclic upgrade sequence pointer internally. During the first startup, the pointer is set to the first version, the current version number is written into the upgrade command and sent to the target device, and response monitoring is initiated simultaneously. Upon receiving the upgrade command, the device completes local firmware replacement, integrity verification, and reboot, then sends back status information. This status information carries at least the upgrade result and may also include one or more of the following: device identifier, version identifiers before and after the upgrade, error code, checksum, timestamp, operating voltage, and remaining memory. This information is used by the scheduler for result determination, log archiving, and subsequent compatibility assessment.

[0088] S103. Execute the next software upgrade version based on the status information, or abort the current upgrade.

[0089] In this step, during the cyclic upgrade test, if the upgrade command for the next version is forcibly issued after any failed test, the device will be stuck on the abnormal version, and subsequent upgrade commands will fail to be implemented due to baseline incompatibility. This contaminates the entire cyclic path and distorts the test results. Therefore, the scheduler must immediately freeze the pointer upon failure or timeout to prevent invalid upgrade commands from being issued.

[0090] The specific implementation method is as follows:

[0091] When the status information indicates that the upgrade was successful, the upgrade command corresponding to the next software upgrade version is issued based on the cyclic upgrade sequence, until the last version of the cyclic upgrade sequence is successfully upgraded;

[0092] Reset the sequence pointer to the first version of the loop upgrade sequence and start the next round of pressure testing loop until the preset pressure testing stop condition is met;

[0093] When the status information indicates that the upgrade has failed, the issuance of subsequent upgrade commands will be suspended and the failure event will be recorded.

[0094] Once the fault is cleared, continue stress testing of the remaining cyclic upgrade sequence from the failed version.

[0095] Specifically, the scheduler first parses the upgrade result field in the status information: if a success flag is returned, the pointer advances sequentially, continues to encapsulate the next version upgrade command, and issues it. When the last version of the cyclic upgrade sequence also successfully responds, the pointer automatically resets to the first version and starts the next round of the loop, thus achieving multiple rounds of traversal without manual intervention. If a failure is parsed or the monitor triggers a timeout, the scheduler immediately stops the pointer advancement, writes the current breakpoint version number, failure reason, and timestamp to non-volatile storage, and reports the anomaly to the superior system; after the operations and maintenance personnel have ruled out image defects, network congestion, or equipment failure and given a continuation signal, the scheduler re-encapsulates the command from the recorded breakpoint version and continues to issue the upgrade. This ensures that the abnormal situation is preserved and that the cyclic upgrade sequence is fully covered, making the compatibility, rollback, and stability test data authentic and reliable.

[0096] This invention provides a method for cyclical upgrades of multiple software versions for devices. Based on the load testing task configuration, a cyclical upgrade sequence containing multiple software upgrade versions and their order is generated. Then, upgrade commands for the current software upgrade version are issued to each target device in the target device set according to the cyclical upgrade sequence, and status information is received. If the status information is normal, the upgrade continues to the next version; otherwise, the current upgrade round is terminated. This method, by frequently switching between software upgrade versions, simulates the stability and reliability of the upgrade chain under extreme scenarios, improving test coverage. Furthermore, it eliminates the need for manually issuing upgrade commands one by one, improving test efficiency. The introduction of a "successful loop, failure-resumable" mechanism allows load testing to be automatically replayed in unlimited rounds and precisely paused / resumed at the point of failure, improving test coverage and preventing the entire chain from being rendered unusable by a single failure, significantly saving manpower and rerun time. Through a "task-device-sequence" three-element binding, each load test is given a unique identity, achieving data isolation and traceability under multi-task parallelism, preventing version and device mismatches, and ensuring auditable results. It uses a three-level association table to store and directly link status information, supporting quick log retrieval by task, device, and version, enabling rapid fault location, significantly shortening troubleshooting time, and improving stress testing and maintenance efficiency.

[0097] Figure 2 A flowchart illustrating a device multi-version cyclic upgrade method provided in this application embodiment. Figure 2 This application provides a detailed description of the steps for obtaining a compatibility score. For example... Figure 2 As shown, the method includes:

[0098] S201. Form version pairs based on the source version number and target version number in the status information.

[0099] In this step, in the existing technology, testers often select the combination of versions to be tested based on personal experience or local historical fault memories. There is no unified quantitative standard, and it is difficult to quickly identify high-risk paths in large-scale cluster scenarios. As a result, there is often a resource mismatch phenomenon where high-risk combinations are postponed and low-risk combinations are repeatedly verified, which ultimately causes compatibility defects to be postponed and the cost of online rollback and emergency patching increases sharply.

[0100] To eliminate the aforementioned subjective uncertainties, this embodiment embeds a version compatibility scoring mechanism within the scheduler: for any version pair, the system automatically calculates the failure rate based on accumulated historical stress test and upgrade logs, processes the data, and generates a compatibility score. This score is updated in real time with each new upgrade result, thus transforming the originally abstract concept of "compatibility" into a quantifiable metric that can be compared horizontally. Using this metric, test plans can be automatically sorted by risk level during the scheduling phase, prioritizing high-risk paths for execution, significantly advancing defect exposure, reducing ineffective and repetitive testing, and improving overall test resource utilization efficiency.

[0101] The source of the scoring data is naturally coupled with the upgrade process, eliminating the need for additional manual input: When the scheduler parses the status information sent back by the device, it directly extracts the source version number and the target version number and concatenates them into an ordered version pair, which is then written to the log database. Each time the same version pair is marked as successful or failed in subsequent loop tests, the system updates the corresponding failure count and total count, thereby continuously providing fresh samples for compatibility scoring and forming a self-growing closed-loop data chain.

[0102] S202. Retrieve historical stress test and upgrade logs, and query the historical stress test and upgrade logs to obtain the version pair, the corresponding number of failures, and the total number of upgrades.

[0103] In this step, to obtain the basic data required for the compatibility score, the scheduler triggers a log aggregation process in the background before each calculation. First, based on the version pair to be evaluated, the source version number and target version number are sequentially matched in the index fields of the time-series database, thus identifying all relevant log records at once. Subsequently, within this result set, aggregation operators are used to accumulate the components corresponding to the failure markers and the total number of records to obtain the number of failures and the total number of upgrades for that version pair since the start time of the record. The entire query process uses a covering index and incremental caching mechanism, controlling the response time for millions of log entries to the millisecond level. This ensures that the score calculation can be updated almost in real time as the upgrade cycle progresses, avoiding the performance overhead of full table scans while ensuring that historical data and the latest results are included in the statistics simultaneously, so that the compatibility score always reflects the most accurate risk status of the device cluster.

[0104] S203. Obtain the recent number of failures within a preset time period from the number of failures, and obtain the recent number of upgrades within a preset time period from the total number of upgrades.

[0105] In this step, to take into account both the long-term trend and the latest fluctuations in version compatibility, the system introduces the "time decay" principle when calculating the score: first, the log of the preset time period immediately adjacent to the current moment is extracted, and the number of failures in this time period is divided by the total number of upgrades to obtain the recent success rate, which is used to reflect the instantaneous risks brought about by the recent batch of images, network environment or hardware batch changes.

[0106] The same calculation is then performed on the number of failures and the total number of upgrades throughout the entire lifecycle to obtain the historical success rate, which reflects the inherent stability of the version over long-term operation. These two success rates are then summed, with the recent success rate given a higher weight, allowing the score to quickly respond to newly emerging compatibility degradations. At the same time, historical data is retained with a certain proportion to prevent drastic score fluctuations due to occasional anomalies. Through this dual timescale overlay, the system's output compatibility score possesses both sensitivity to short-term defects and the robustness of long-term statistics, providing a quantitative basis for subsequent test ranking and resource scheduling that balances "real-time" and "experience-based" considerations.

[0107] The span of the preset time period can be written once in the upgrade scheduler's configuration file. Typical values ​​include, but are not limited to, the last 24 hours, the last week, or the last 30 days. The specific duration can be flexibly set according to the size of the device cluster, the version release rhythm, and the business tolerance. For example, for weekly updated smart home firmware, "the last week" can be selected as the preset time period to ensure that the score can quickly reflect the true compatibility of the previous release cycle, while retaining a sufficient sample size to avoid statistical distortion.

[0108] Specifically, the test time corresponding to each failure is obtained, and the number of test times included in a preset time period is selected from multiple test times. The recent failure count is determined based on this number. Similarly, the recent upgrade count within the preset time period is obtained from the total number of upgrades.

[0109] S204. Determine the historical success rate based on the number of failures and the total number of upgrades, and determine the recent success rate based on the number of recent failures and the number of recent upgrades.

[0110] In this step, the historical success rate is determined based on the ratio of the number of failures to the total number of upgrades. The recent success rate is determined based on the ratio of the number of recent failures to the number of recent upgrades.

[0111] For example, for version V1.0→V2.0, the system first extracts the logs from the last seven days, obtaining 12 recent failures and 200 recent upgrades, thus calculating a recent success rate of 94%. Then, it extracts all historical records, with 40 failures and a total of 1000 upgrades, resulting in a historical success rate of 96%.

[0112] S205. A compatibility score is obtained by processing historical success rates and recent success rates using a weighted algorithm, which reflects the stability of the version under stress testing conditions.

[0113] The compatibility score is used to sort multiple software upgrade versions in the next load testing task to obtain a compatible cyclical upgrade sequence.

[0114] In this step, the weighted algorithm initially assigns baseline weights to historical success rates and recent success rates, with historical weights being less than recent weights. For example, the recent weight is 0.6, and the historical weight is 0.4. Linear weighting yields a compatibility score between zero and one. As testing progresses, the system continuously monitors the fluctuations of these two success rates: if the recent success rate is significantly lower than the historical success rate for several consecutive rounds, it indicates the presence of new unstable factors in the version. In this case, the algorithm automatically increases the recent weight, causing the score to drop rapidly to warn of potential risks early. Conversely, when recent data stabilizes and the sample size is sufficient, the recent weight gradually returns to its initial level, preventing the score from fluctuating drastically due to short-term noise. The weight update uses a sliding exponential decay method, ensuring sensitivity to sudden compatibility degradation while maintaining the stability of long-term statistical results. This keeps the compatibility score in a dynamically optimal state, providing real-time and reliable quantitative data for subsequent test prioritization and resource scheduling.

[0115] In one possible implementation, linear weighting can be replaced by an offline-trained logistic regression model: using historical success rate, recent success rate, sample size, version interval in days, and error code distribution as input features, the model's output probability value is directly used as the compatibility score. During training, real cluster upgrade logs are used; positive samples are records that did not trigger rollback within the next three rounds, and negative samples are records that experienced rollback or secondary failure. Regularization prevents overfitting, and the weight coefficients are updated incrementally monthly, allowing the model to automatically evolve with new data. Therefore, the score no longer relies on fixed weights but integrates multi-dimensional nonlinear relationships, providing more significant differentiation for high-risk version pairs, further improving the scientific rigor and foresight of the testing strategy optimization.

[0116] In another possible implementation, to concentrate limited testing resources on high-risk paths, the system immediately compares the score with a preset compatibility score threshold after each score update: if the score is below the threshold, it indicates that the version pair has a significant tendency to be unstable, and the scheduler immediately inserts the version pair at the head of the instruction queue in the next round and assigns it the highest test priority, allowing it to be executed before other combinations; if the score is above or equal to the threshold, the original order is maintained. This adjustment principle is based on the idea of ​​"risk pre-emption," achieving objective decision-making through quantified thresholds and avoiding the lag and omissions caused by manual intervention.

[0117] In implementation, the scheduler only needs to modify the queue pointer array to complete the rearrangement in milliseconds, with no significant impact on the overall delivery rhythm. Ultimately, this allows high-risk combinations to expose defects as early as possible, shortens the problem localization loop time, and reduces the machine time and manpower consumed by subsequent iterative regressions.

[0118] For example, if the compatibility score of version V1.0-V3.0 drops to 0.72, while the threshold is 0.75, the system will automatically move that version pair to the first position for testing in the next loop. As a result, the compatibility problem is found in the first loop, which reduces the testing time compared to the traditional sequential execution.

[0119] In one possible implementation, historical success rate and recent success rate represent "long-term stable performance" and "recent real situation," respectively. The compatibility score, obtained by weighting the two, is a quantifiable risk line that integrates "old data" and "new signs." The compatibility score threshold is the "red line" of risk tolerance. Once the score falls below the red line, it indicates that the version combination has statistically shown signs of "instability." If stress testing continues in the original order, high-risk points may be pushed to the later stages or even missed, leading to problems erupting on the live network. Prioritizing the testing of "low-scoring version pairs" is equivalent to moving the most likely failure scenarios to the forefront, testing them in the lab first to prevent "hidden defects" from spreading to more devices or later versions over time.

[0120] The implementation process is as follows:

[0121] Determine the relationship between the compatibility score and the compatibility score threshold;

[0122] When the compatibility score is less than the compatibility score threshold, the testing priority of the version pair will be advanced in the next load testing cycle to prioritize the verification of the stability of the low compatibility version combination.

[0123] Specifically, the system reads the historical success rate of this version over the past N iterations and the recent success rate over the most recent M iterations, and synthesizes them into a compatibility score between 0 and 100 according to preset weights. This compatibility score is then compared to a pre-set compatibility score threshold. The compatibility score threshold can be dynamically adjusted by operations personnel based on business tolerance, or it can be automatically fine-tuned by the system based on historical defect density.

[0124] If the compatibility score is lower than the compatibility score threshold, the system will move the version pair to the head of the unverified queue when generating the next load test task. Simultaneously, the overall loop framework remains unchanged, only the execution order is adjusted, allowing low-scoring version pairs to get a new round of verification opportunities as quickly as possible. After early execution, the system continues to collect new status reports, updates historical and recent success rates, and re-enters weighted calculation, forming a closed-loop feedback. If the score subsequently rises and stably exceeds the threshold, the version pair can gradually return to its normal ranking; if the score remains low, a stricter interception or manual intervention process will be triggered.

[0125] Prioritize the most critical versions to gain prominence, shortening the issue discovery cycle and reducing the probability of missed defects. Avoid wasting valuable load testing time on already highly stable versions, allowing equipment, bandwidth, and manpower to focus on high-risk scenarios, thus improving overall testing efficiency. Through a closed loop of "early verification—rapid fix—re-verification," ensure that low-compatibility versions are thoroughly refined before the official upgrade channel, significantly reducing online rollback rates and user complaints.

[0126] This invention provides a method for multi-version cyclical upgrades of devices. By dynamically calculating a compatibility score by integrating recent and historical success rates, the system transforms subjective experience into quantitative indicators and uses threshold comparisons to instantly prioritize high-risk version pairs in the upgrade cycle. This allows potential defects to be exposed early and test resources to be deployed precisely, shortening the localization loop and reducing ineffective iterations, significantly improving the efficiency and reliability of multi-version cyclical upgrades. By prioritizing low-compatibility version pairs below a threshold to the forefront of the next round of load testing, "high-risk versions run first, and problems are exposed early," significantly shortening the defect discovery cycle and reducing the influx of hidden unstable combinations into subsequent stages. This improves test resource utilization, reduces the risk of online upgrade rollback, and ensures the overall stability of the version chain.

[0127] Figure 3 This is a schematic diagram of a device for multi-version cyclic upgrades provided in an embodiment of this application. Figure 3 As shown, the multi-version cyclic upgrade device 30 includes:

[0128] The determination module 301 is used to obtain the target device set, the multiple software upgrade versions corresponding to the target device set, and the upgrade order of the multiple software upgrade versions according to the load testing task configuration, and generate a corresponding cyclic upgrade sequence based on the multiple software upgrade versions and the upgrade order;

[0129] The sending module 302 is used to send the upgrade command corresponding to the current software upgrade version to each target device in the target device set in a cyclic upgrade sequence.

[0130] The control module 303 is used to receive the status information returned by the target device after completing the upgrade instruction, and to execute the upgrade of the next software upgrade version or terminate the current upgrade based on the status information;

[0131] The cyclic upgrade sequence is used to perform multiple version switches on the target device set to simulate the stress under high-frequency cyclic scenarios.

[0132] In one possible implementation, the control module 303 is further configured to:

[0133] When the status information indicates that the upgrade was successful, the upgrade command corresponding to the next software upgrade version is issued based on the cyclic upgrade sequence, until the last version of the cyclic upgrade sequence is successfully upgraded;

[0134] Reset the sequence pointer to the first version of the loop upgrade sequence and start the next round of pressure testing loop until the preset pressure testing stop condition is met;

[0135] When the status information indicates that the upgrade has failed, the issuance of subsequent upgrade commands will be suspended and the failure event will be recorded.

[0136] Once the fault is cleared, continue stress testing of the remaining cyclic upgrade sequence from the failed version.

[0137] In one possible implementation, the control module 303 is further configured to:

[0138] Generate a task identifier corresponding to the load testing task;

[0139] The task identifier, the cyclic upgrade sequence, and the device identifier of each target device in the target device set are bound and stored to establish a target mapping relationship that indicates the correspondence between the task, device, and sequence.

[0140] In one possible implementation, the control module 303 is further configured to:

[0141] A three-level association structure of task-device-sequence is used to store task identifiers, device identifiers, and version identifiers of cyclic upgrade sequences to obtain the target mapping relationship;

[0142] The task identifier is associated with the device identifier, the device identifier is associated with the version identifier, and the version identifier is associated with the status information returned during the corresponding upgrade process, in order to support multi-dimensional inspection of the stress test logs.

[0143] In one possible implementation, the control module 303 is further configured to:

[0144] Version pairs are formed based on the source version number and target version number in the status information;

[0145] Retrieve historical stress test and upgrade logs, and query the historical stress test and upgrade logs to obtain version pairs, corresponding failure counts, and total number of upgrades;

[0146] A compatibility score is obtained and stored based on the number of failures and the total number of upgrades. The compatibility score is used to sort multiple software upgrade versions in the next load test task to obtain a suitable cyclical upgrade sequence.

[0147] In one possible implementation, the control module 303 is further configured to:

[0148] Get the recent number of failures within a preset time period from the number of failures, and get the recent number of upgrades within a preset time period from the total number of upgrades;

[0149] The historical success rate is determined based on the number of failures and the total number of upgrades, and the recent success rate is determined based on the number of recent failures and the number of recent upgrades.

[0150] A compatibility score is obtained by weighting historical success rates and recent success rates to reflect the stability of the version under stress testing.

[0151] In one possible implementation, the control module 303 is further configured to:

[0152] Determine the relationship between the compatibility score and the compatibility score threshold;

[0153] When the compatibility score is less than the compatibility score threshold, the testing priority of the version pair will be advanced in the next load testing cycle to prioritize the verification of the stability of the low compatibility version combination.

[0154] The device for multiple version cyclic upgrades provided in this application can execute the device multiple version cyclic upgrade method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0155] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device 40 includes a processor 401 and a memory 402 communicatively connected to the processor 401. Optionally, the electronic device 40 also includes a communication component 403. The processor 401, memory 402, and communication component 403 are connected via a bus 404.

[0156] Memory 402 stores instructions executed by the computer;

[0157] The processor 401 executes computer execution instructions stored in the memory 402 to implement the device multi-version cyclic upgrade method as described above.

[0158] At least one processor 401 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0159] Optionally, in specific implementations, the processor 401 and memory 402 are implemented independently. In this case, the processor 401 and memory 402 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0160] Optionally, in a specific implementation, if the processor 401 and the memory 402 are integrated on a single chip, the processor 401 and the memory 402 can communicate through an internal interface.

[0161] This application also provides a computer storage medium storing computer execution instructions, which, when executed by a processor, implements the aforementioned method for multi-version cyclic upgrades of the device.

[0162] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The computer-readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0163] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Alternatively, the readable storage medium can be an integral part of the processor. Both the processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the control device of a garment handling apparatus.

[0164] This unit division is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

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

[0166] In addition, the functional units in the various embodiments of the present invention 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.

[0167] If this function 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 invention, or the part that contributes to the prior art, or a 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 (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods indicated in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0168] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0169] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it is readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. 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 or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for cyclical upgrades of multiple versions of a device, characterized in that, include: Based on the load testing task configuration, obtain the target device set, multiple software upgrade versions corresponding to the target device set, and the upgrade order of the multiple software upgrade versions, and generate a corresponding cyclic upgrade sequence based on the multiple software upgrade versions and the upgrade order; For each target device in the target device set, upgrade instructions corresponding to the current software upgrade version are sent to the target device sequentially according to the cyclic upgrade sequence; Receive the status information returned by the target device after completing the upgrade instruction, and execute the next software upgrade version upgrade according to the status information, or abort the current upgrade; The cyclic upgrade sequence is used to perform multiple version switches on the target device set to simulate the pressure under high-frequency cyclic scenarios.

2. The method according to claim 1, characterized in that, The step of performing the next software upgrade version based on the status information, or terminating the current upgrade, includes: When the status information indicates that the upgrade is successful, the upgrade instruction corresponding to the next software upgrade version is issued based on the cyclic upgrade sequence, until the last version of the cyclic upgrade sequence is successfully upgraded; Reset the sequence pointer to the first version of the cyclic upgrade sequence and start the next round of pressure testing cycle until the preset pressure testing stop condition is met; When the status information indicates that the upgrade has failed, the issuance of subsequent upgrade instructions will be suspended and the failure event will be recorded. Once the fault is cleared, continue stress testing of the remaining cyclic upgrade sequence from the failed version.

3. The method according to claim 1, characterized in that, Before generating a corresponding cyclic upgrade sequence based on multiple software upgrade versions and the upgrade order, the method further includes: Generate a task identifier corresponding to the load testing task; The task identifier, the cyclic upgrade sequence, and the device identifiers of each target device in the target device set are bound and stored to establish a target mapping relationship that indicates the correspondence between the task, device, and sequence.

4. The method according to claim 3, characterized in that, The step of binding and storing the task identifier, the cyclic upgrade sequence, and the device identifiers of each target device in the target device set includes: The task identifier, the device identifier, and the version identifier of the cyclic upgrade sequence are stored using a three-level association structure of task-device-sequence to obtain the target mapping relationship; The task identifier is associated with the device identifier, the device identifier is associated with the version identifier, and the version identifier is associated with the status information returned during the upgrade process, so as to support multi-dimensional inspection of the stress test log.

5. The method according to claim 4, characterized in that, After receiving the status information returned by the target device after completing the upgrade instruction, the method further includes: A version pair is formed based on the source version number and target version number in the status information; Retrieve historical stress test and upgrade logs, and query the historical stress test and upgrade logs to obtain the version pair, the corresponding number of failures, and the total number of upgrades; A compatibility score is obtained and stored based on the number of failures and the total number of upgrades. The compatibility score is used to sort multiple software upgrade versions in the next load testing task to obtain a suitable cyclic upgrade sequence.

6. The method according to claim 5, characterized in that, The process of obtaining a compatibility score based on the number of failures and the total number of upgrades includes: The number of recent failures within a preset time period is obtained from the number of failures, and the number of recent upgrades within the preset time period is obtained from the total number of upgrades; The historical success rate is determined based on the number of failures and the total number of upgrades, and the recent success rate is determined based on the number of recent failures and the number of recent upgrades. The historical success rate and the recent success rate are processed by a weighted algorithm to obtain a compatibility score, which reflects the stability of the version under stress testing environment.

7. The method according to claim 6, characterized in that, After processing the historical success rate and the recent success rate using a weighted algorithm to obtain a compatibility score, the method further includes: Determine the relationship between the compatibility score and the compatibility score threshold; When the compatibility score is less than the compatibility score threshold, the testing priority of the version pair will be advanced in the next load testing cycle to prioritize the verification of the stability of the low compatibility version combination.

8. A device for multi-version cyclic upgrades, characterized in that, The device includes: The determination module is used to obtain a target device set, multiple software upgrade versions corresponding to the target device set, and the upgrade order of the multiple software upgrade versions according to the load testing task configuration, and generate a corresponding cyclic upgrade sequence according to the multiple software upgrade versions and the upgrade order; The sending module is used to send the upgrade command corresponding to the current software upgrade version to each target device in the target device set in accordance with the cyclic upgrade sequence; The control module is used to receive the status information returned by the target device after completing the upgrade instruction, and to execute the next software upgrade version upgrade or terminate the current upgrade based on the status information; The cyclic upgrade sequence is used to perform multiple version switches on the target device set to simulate the pressure under high-frequency cyclic scenarios.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the device multi-version cyclic upgrade method as described in any one of claims 1 to 7.

Images