Software upgrading method, client, server and system for testing equipment

Abstract

The application relates to the technical field of software upgrading, in particular to a software upgrading method of a test device, a client, a server, a software upgrading system and a storage medium. When receiving an upgrading task, the server can acquire attribute information of a deployed component of a target test device reported by a client and dependency relationship data of a new version software component, the dependency relationship data comprising attribute information of the new version software component and specified components, the specified components comprising at least one specified software component and at least one specified hardware component dependent on the new version software component; therefore, before performing a software upgrading operation on the target test device, the server can evaluate the compatibility between the new version software component and the deployed component based on the attribute information of the deployed component and the dependency relationship data, and obtain an evaluation result. The evaluation result can be used to determine whether the software component to be upgraded can be safely upgraded to the new version, and is beneficial to reducing compatibility faults caused by software upgrading.

Description

Technical Field

[0001] This application relates to the field of software upgrade technology for test equipment, and in particular to a software upgrade method, client, server, software upgrade system, and storage medium for test equipment. Background Technology

[0002] Automatic Test Equipment (ATE) is a key piece of equipment used in high-end manufacturing industries such as semiconductors, automotive electronics, and aerospace to perform functional and performance tests on electronic components, circuit boards, and modules.

[0003] An ATE (Automatic Test Equipment) is a complex hardware and software system. The software running on an ATE typically includes an operating system (OS), test executive software, various instrument drivers, test program sets (TPS), and other auxiliary software tools. These software components have numerous versions, and complex dependencies exist between them. Current software upgrade schemes for semiconductor test equipment generally lack effective upgrade risk assessment mechanisms, easily leading to various compatibility failures. Summary of the Invention

[0004] This application provides a software upgrade management method, a software upgrade method, a client, a server, a software upgrade system, and a storage medium. It can assess the compatibility between the new version of the software components and the deployed components before the software upgrade operation is performed on the target test device, which helps to reduce compatibility failures caused by software upgrades.

[0005] To address the aforementioned technical problems, the embodiments of this application provide the following technical solutions: In a first aspect of this application, a software upgrade method for a test device is provided, applied to a server. The target test device includes deployed components, wherein the deployed components include at least one deployed software component and at least one deployed hardware component, and the deployed software component includes a software component to be upgraded and at least one non-upgraded software component. The method includes: receiving an upgrade task, the upgrade task instructing the software component to be upgraded from a current old version to a new version to obtain a new version software component; responding to the upgrade task, obtaining attribute information of the deployed components reported by a client, the attribute information of the deployed components including attribute information of the at least one deployed software component and attribute information of the at least one deployed hardware component; obtaining dependency data of the new version software component, the dependency data including attribute information of the new version software component and attribute information of a specified component, the specified component including at least one specified software component and at least one specified hardware component that the new version software component depends on, and the dependency data including a first dependency relationship and a second dependency relationship. The new version software component has a first dependency relationship with the designated software component, and a second dependency relationship with the designated hardware. Based on the attribute information of the deployed components and the dependency relationship data, the compatibility between the new version software component and the deployed components is evaluated to obtain an evaluation result. This includes: determining an upgrade risk score corresponding to each evaluation item in a plurality of compatibility evaluation items based on the attribute information of the deployed components and the attribute information of the designated component; performing a weighted calculation based on the upgrade risk scores and weight values ​​corresponding to each evaluation item to obtain a comprehensive upgrade risk value; wherein the plurality of compatibility evaluation items include: a first dependency satisfaction degree and a second dependency satisfaction degree, whereby the first dependency satisfaction degree characterizes the degree of adaptation of each non-upgradeable software component in the at least one non-upgradeable software component to the first dependency relationship; and the second dependency satisfaction degree characterizes the degree of adaptation of each deployed hardware in the at least one deployed hardware to the second dependency relationship.

[0006] In the embodiments of this application, upon receiving an upgrade task, the server can obtain attribute information of the deployed components of the target test device reported by the client. The server can also obtain dependency data of the new version software components, which includes attribute information of the new version software components and attribute information of specified components. The specified components include at least one specified software component and at least one specified hardware component that the new version software components depend on. Therefore, before performing a software upgrade operation on the target test device, the server can evaluate the compatibility between the new version software components and the deployed components based on the attribute information and dependency data of the deployed components, and obtain an evaluation result. This evaluation result can be used to determine whether the software component to be upgraded can be safely upgraded to the new version, which helps reduce compatibility failures caused by software upgrades.

[0007] In some embodiments, the plurality of compatibility evaluation items further include: version span, which represents the span between the version number of the software component to be upgraded and the version number of the new version software component; and historical upgrade information, which is the historical upgrade information under the version span.

[0008] In some embodiments, determining the upgrade risk score corresponding to each of the multiple compatibility evaluation items based on the attribute information of the deployed components and the attribute information of the specified components includes: determining an upgrade risk score value corresponding to a first dependency satisfaction based on the attribute information of the at least one deployed software component and the attribute information of the at least one specified software component; determining an upgrade risk score value corresponding to a second dependency satisfaction based on the attribute information of the at least one deployed hardware and the attribute information of the at least one specified hardware; determining the size of the version span, and determining an upgrade risk score value corresponding to the version span based on the size of the version span; determining the historical upgrade success rate of the software component to be upgraded under the version span, and determining an upgrade risk score value corresponding to the historical upgrade situation based on the historical upgrade success rate.

[0009] In some embodiments, the attribute information includes a version number, where the version number of the deployed software component is a first version number and the version number of the specified software component is a second version number. Determining the upgrade risk score corresponding to the first dependency satisfaction based on the attribute information of the at least one deployed software component and the attribute information of the at least one specified software component includes: if it is determined that the at least one deployed software component does not include any of the specified software components in the at least one specified software component, then the upgrade security score corresponding to the first dependency satisfaction is determined to be a preset first minimum score; if it is determined that the at least one deployed software component includes n specified software components in the at least one specified software component, then the upgrade security score corresponding to the first dependency satisfaction is determined based on the first version number and the second version number corresponding to each of the n specified software components, where n is a positive integer not less than 1; subtracting the upgrade security score corresponding to the first dependency satisfaction from the first maximum score yields the upgrade risk score corresponding to the first dependency satisfaction.

[0010] In some embodiments, the first version number includes a first major version number, and the second version number includes a second major version number; determining the upgrade security score corresponding to the first dependency satisfaction based on the first version number and second version number corresponding to each of the n specified software components includes: if it is determined that the first version number corresponding to any specified software component among the n specified software components is not lower than the second version number corresponding to any specified software component, then the upgrade security score corresponding to any specified software component is determined to be a first full score; if it is determined that the first version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, and the first major version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, then the upgrade security score corresponding to any specified software component is determined to be a first full score; If the difference between the corresponding second major version numbers does not exceed 1, then the upgrade security score corresponding to any specified software component is determined to be the first intermediate score; if it is determined that the first version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, and the difference between the first major version number corresponding to any specified software component and the second major version number corresponding to any specified software component exceeds 1, then the upgrade security score corresponding to any specified software component is determined to be the first minimum score; the average of the upgrade security scores corresponding to each of the n specified software components is calculated to obtain the upgrade security score corresponding to the first dependency satisfaction; wherein, the first minimum score < the first intermediate score < the first full score.

[0011] In some embodiments, the attribute information of the deployed hardware and the designated hardware includes model and firmware version number; determining the upgrade risk score corresponding to the second dependency satisfaction based on the attribute information of the at least one deployed hardware and the attribute information of the at least one designated hardware includes: if it is determined that the model of each of the deployed hardware in the at least one deployed hardware is different from the model of the designated hardware, and it is determined that the dependency type between the designated hardware and the new version software component is mandatory dependency, then the upgrade security score corresponding to the designated hardware is determined to be the second minimum score; if it is determined that the model of each of the deployed hardware in the at least one deployed hardware is different from the model of the designated hardware, and it is determined that the dependency type between the designated hardware and the new version software component is optional dependency... If the type of dependency is determined, the upgrade security score corresponding to the specified hardware is determined to be the second lower score; if the at least one deployed hardware includes the target deployed hardware, the upgrade security score corresponding to the specified hardware is determined based on the firmware version number of the target deployed hardware and the firmware version number of the specified hardware; the average of the upgrade security scores corresponding to each specified hardware in the at least one specified hardware is calculated to obtain the upgrade security score corresponding to the second dependency satisfaction; the upgrade risk score corresponding to the second dependency satisfaction is obtained by subtracting the upgrade security score corresponding to the second dependency satisfaction from the second full score; wherein, the target deployed hardware is deployed hardware of the same model as the specified hardware, and the second lowest score < the second lower score < the second full score.

[0012] In some embodiments, determining the upgrade security score corresponding to the specified hardware based on the firmware version number of the target deployed hardware and the firmware version number of the specified hardware includes: if it is determined that the firmware version number of the target deployed hardware is lower than the firmware version number of the specified hardware, then the upgrade security score corresponding to the specified hardware is determined to be a second higher score; if it is determined that the firmware version number of the target deployed hardware is not lower than the firmware version number of the specified hardware, then the upgrade security score corresponding to the specified hardware is determined to be a second full score; wherein, the second lower score < the second higher score < the second full score.

[0013] In some embodiments, determining the upgrade risk score corresponding to the version span based on the size of the version span includes: if the difference between the major version number of the software component to be upgraded and the major version number of the new software component is no more than 1, then the upgrade risk score corresponding to the version span is determined to be the third lowest score; if the difference between the major version number of the software component to be upgraded and the major version number of the new software component is greater than 1 and no more than 2, then the upgrade risk score corresponding to the version span is determined to be the third intermediate score; if the difference between the major version number of the software component to be upgraded and the major version number of the new software component is greater than 2, then the upgrade risk score corresponding to the version span is determined to be the third highest score; wherein, the third lowest score < the third intermediate score < the third highest score.

[0014] In some embodiments, determining the upgrade risk score corresponding to the historical upgrade situation based on the historical upgrade success rate includes: determining the success rate interval in which the historical upgrade success rate falls based on the historical upgrade success rate, wherein the success rate interval and the upgrade risk score have a mapping relationship; determining the upgrade risk score corresponding to the success rate interval based on the success rate interval and the mapping relationship, thereby obtaining the upgrade risk score corresponding to the historical upgrade situation.

[0015] In some embodiments, after obtaining the comprehensive upgrade risk value, the method further includes: if it is determined that the comprehensive upgrade risk value is less than a preset risk threshold, then it is determined that the software component to be upgraded can be safely upgraded from the old version to the new version, and an upgrade command is issued to the client; if it is determined that the comprehensive upgrade risk value is not less than the preset risk threshold, then the upgrade task of the target test device is terminated.

[0016] In some embodiments, the dependency data is a dependency graph model, the server is configured with a graph database, and the graph database stores the dependency graph model; obtaining the dependency data of the new version software component includes: obtaining the dependency graph model of the new version software component from the graph database; wherein, the dependency graph model includes multiple nodes, the multiple nodes include a first node, at least one second node, and at least one third node; a first directed edge is provided between the first node and each of the second nodes among the at least one second node, and a second directed edge is provided between the first node and each of the third nodes among the at least one third node; the first node is used to represent the attribute information of the new version software component; each of the second nodes is used to represent the attribute information of each of the specified software components in the at least one specified software component; each of the third nodes is used to represent the attribute information of each of the specified hardware in the at least one specified hardware; the first directed edge is used to represent the dependency relationship between the first node and the second node, and the second directed edge is used to represent the dependency relationship between the first node and the third node.

[0017] In some embodiments, the step of obtaining the attribute information of the deployed component reported by the client in response to the upgrade task includes: issuing a pre-detection instruction to the client in response to the upgrade task, so that the client scans the hardware and software environment of the target test device based on the pre-detection instruction, generates an environment snapshot file, and reports the environment snapshot file to the server; receiving the environment snapshot file reported by the client, and obtaining the attribute information of the deployed component based on the environment snapshot file.

[0018] In some embodiments, the method further includes: parsing the environment snapshot file to obtain a component list of the software component to be upgraded; determining the difference components in the first component list and the second component list; generating a differentiated update package carrying a manifest file based on the difference components; and sending the differentiated update package to the client; wherein the difference components include components to be added, components to be deleted, and components to be updated, and the manifest file is used to record the operation type, target path, hash value, and execution order of each component in the difference components; the first component list is the component list of the software component to be upgraded; and the second component list is the component list of the new version software component.

[0019] In some embodiments, the server includes a preset version repository; generating a differentiated update package carrying a manifest file based on the differentiated components includes: extracting the new version of the component to be added from the preset version repository; determining a difference file based on the installation files under the component to be updated in the first component list and the installation files under the component to be updated in the second component list, the difference file including the file to be added, the file to be deleted, and the file to be updated; extracting the new version of the file to be added from the preset version repository; if it is determined that the file to be updated supports incremental differential updates, generating a corresponding difference patch, the difference patch being used to incrementally repair the old version of the file to be updated to obtain the new version of the file to be updated; if it is determined that the file to be updated does not support incremental differential updates, extracting the new version of the file to be updated from the preset version repository; generating a differentiated update package carrying a manifest file based on the information of the new version of the component to be added, the new version of the file to be added, the difference patch, the new version of the file to be updated, the information of the component to be deleted, and / or the information of the file to be deleted.

[0020] In a second aspect of this application, a software upgrade method for a testing device is also provided, applied to a client. The method includes: receiving an upgrade instruction from a server, the upgrade instruction instructing the target testing device to upgrade a currently installed software component to be upgraded from its current old version to a new version, the target testing device having test execution software installed, the test execution software controlling a test suite to execute test tasks; responding to the upgrade instruction, calling a first application programming interface of the test execution software to query whether the target testing device is currently executing the test task; if it is determined that the target testing device is currently executing the test task, and it is determined that the currently running test suite has a dependency relationship with the software component to be upgraded, then the current upgrade mode of the software component to be upgraded is determined to be a cold update mode; if it is determined that the target testing device is currently executing the test task, and it is determined that the currently running test suite does not have a dependency relationship with the software component to be upgraded, then the current upgrade mode of the software component to be upgraded is determined to be a hot update mode; and in the current upgrade mode, upgrading the software component to be upgraded from its current old version to the new version to obtain a new version software component.

[0021] In some embodiments, upgrading the software component to be upgraded from the current old version to the new version in the current upgrade mode includes: if it is determined that the current upgrade mode of the software component to be upgraded is a cold update mode, then subscribing to the current test batch completion event; if the current test batch completion event is detected, then calling the second application programming interface of the test execution software to send a task pause request to the test execution software, so that the test execution software pauses test task scheduling; upgrading the software component to be upgraded from the current old version to the new version; if it is determined that the software component to be upgraded has been successfully upgraded to the new version, then calling the third application programming interface of the test execution software to send a task recovery request to the test execution software, so that the test execution software resumes test task scheduling.

[0022] In some embodiments, upgrading the software component to be upgraded from the current old version to the new version under the current upgrade mode includes: if it is determined that the current upgrade mode of the software component to be upgraded is a hot update mode, then determining the component type of the software component to be upgraded; based on the component type, determining the hot update mechanism of the hot update mode; and upgrading the software component to be upgraded from the current old version to the new version based on the hot update mechanism; wherein the component type is a regular file type, a system service or system daemon type, a dynamic link library type, or an independent process communication type.

[0023] In some embodiments, determining the hot update mechanism based on the component type includes: if the component type is determined to be a regular file, then the hot update mechanism is determined to be a file lock detection and waiting mechanism; if the component type is determined to be a system service or system daemon, then the hot update mechanism is determined to be a graceful service restart mechanism; if the component type is determined to be a dynamic link library, then the hot update mechanism is determined to be a versioned loading mechanism for dynamic link libraries; if the component type is determined to be an independent process communication type, then the hot update mechanism is determined to be a seamless switching mechanism for inter-process communication.

[0024] In some embodiments, the software component to be upgraded includes an old version file, and the new version software component includes a new version file; upgrading the software component to be upgraded from the current old version to the new version based on the hot update mechanism includes: if it is determined that the hot update mechanism is a file lock detection and waiting mechanism, then determining whether the old version file is locked by other processes; if it is determined that the old version file is locked by other processes, then entering a waiting state; in the waiting state, polling the file lock status of the old version file at preset time intervals; if it is determined that the file lock status of the old version file becomes unlocked within a preset first duration, then replacing the old version file with the new version file; if it is determined that the file lock status of the old version file does not become unlocked within the preset first duration, then adjusting the current upgrade mode of the software component to be upgraded to a cold update mode.

[0025] In some embodiments, upgrading the software component to be upgraded from its current old version to a new version based on the hot update mechanism includes: if it is determined that the hot update mechanism is a graceful restart mechanism, then sending a graceful stop signal to the software component to be upgraded, the graceful stop signal being used to instruct the software component to be upgraded to automatically exit operation after completing the existing service request currently being processed; if it is determined that the software component to be upgraded has not automatically exited operation within a preset second time period, then sending a forced termination signal to the software component to be upgraded, the forced termination signal being used to force the software component to be upgraded to exit operation; if it is determined that the software component to be upgraded has automatically exited operation, then replacing the software component to be upgraded with a new version software component.

[0026] In some embodiments, upgrading the software component to be upgraded from its current old version to a new version based on the hot update mechanism includes: if the hot update mechanism is determined to be a dynamic link library versioning loading mechanism, then, if the new version software component is configured with a name carrying a version identifier, copying the new version software component to the storage directory of the software component to be upgraded, and retaining the software component to be upgraded in the storage directory; modifying the configuration file or registry configuration item corresponding to the software component to be upgraded to update the loading path configuration of the software component to be upgraded to point to the new version software component carrying the version identifier; automatically loading and running the new version software component when the host process that depends on the dynamic link library file loads the corresponding software component to be upgraded next time; monitoring the running status of the new version software component; if the running status is confirmed to be stable, marking the software component to be upgraded remaining in the storage directory as cleanable.

[0027] In some embodiments, upgrading the software component to be upgraded from the current old version to the new version based on the hot update mechanism includes: if it is determined that the hot update mechanism is a seamless inter-process communication switching mechanism, then copying the new version software component to the storage directory of the software component to be upgraded; starting the new version service process, binding the new version service process to a communication identifier consistent with the old version service process, and the operating system of the target test device automatically routing subsequent new communication requests sent to the old version service process to the new version service based on the communication identifier; if it is determined that the old version service process has finished processing the existing access requests and exited, then determining that the software component to be upgraded in the storage directory can be cleaned up; wherein, the new version service process is the business service process corresponding to the new version software component; and the old version service process is the business service process corresponding to the software component to be upgraded.

[0028] In some embodiments, upgrading the software component to be upgraded to a new version includes: performing an update operation to upgrade the software component from the old version to the new version in an atomic transaction manner based on a write-ahead transaction log mechanism.

[0029] In some embodiments, the update operation includes multiple operation steps, and the target operation step is any one of the multiple operation steps; the upgrade operation of the software component to be upgraded from the old version to the new version based on the write-ahead transaction log mechanism and in an atomic transaction manner includes: creating a transaction log file, writing the transaction identifier, transaction start time and information of the new version of the software component of the update operation into the transaction log file, and marking the transaction status of the update operation as "started"; executing each of the multiple operation steps in a preset operation order; during the sequential execution of each of the multiple operation steps, first writing the operation content of the target operation step and the inverse operation corresponding to the target operation step. The process involves entering the transaction log file and then executing the target operation step. If the target operation step is successfully executed, the transaction status of the target operation step is marked as "completed" in the transaction log file. If each of the multiple operation steps is successfully executed, the transaction status of the update operation is marked as "completed" in the transaction log file. If the target operation step fails, the transaction status of the target operation step is marked as "rollback" in the transaction log file, and the reverse operation of each completed operation step is executed sequentially in the reverse order of the preset operation sequence. If the reverse operation of each completed operation step has been executed, the transaction status of the update operation is marked as "rollback" in the transaction log file.

[0030] In some embodiments, the method further includes: if it is determined that each of the plurality of operation steps was executed successfully, then checking the upgrade result, wherein the upgrade result is either successful or abnormal; if it is determined that the upgrade result is abnormal, then triggering a rollback mechanism; under the rollback mechanism, reading the transaction log file to obtain the inverse operations of all completed operation steps; executing the inverse operations of each completed operation step in reverse order; if it is determined that all the inverse operations of each operation step have been executed, then determining whether the current service state has been restored to the state before the upgrade based on the system state snapshot file; if it is determined that the current service state has been restored to the state before the upgrade, then checking whether the software running system of the target test device can work normally; wherein, the service state is the running state of the service associated with the software component to be upgraded.

[0031] In some embodiments, the method further includes: creating a system status snapshot file, wherein creating the system status snapshot file includes: traversing the installation directory of the software component to be upgraded, copying all files under the installation directory to a backup directory with timestamps, and generating file backup data; exporting and saving registry entries and configuration files associated with the software component to be upgraded, and generating configuration backup data; recording the current service running status associated with the software component to be upgraded, and generating service status backup data; and writing the index information of the file backup data, the configuration backup data, and the service status backup data into a snapshot description file to obtain a system status snapshot file.

[0032] In some embodiments, the method further includes: if a pre-detection instruction is received from the server, then in response to the pre-detection instruction, scanning the current hardware and software environment of the target test device to generate an environment snapshot file, and reporting the environment snapshot file to the server.

[0033] In a third aspect of this application, a server is also provided, the server comprising: at least one first processor, and a first memory communicatively connected to the at least one first processor, wherein the first memory stores instructions executable by the at least one first processor, the instructions being executed by the at least one first processor to enable the at least one first processor to perform the method as described in the first aspect.

[0034] In a fourth aspect of this application, a client is also provided, the client comprising: at least one second processor, and a second memory communicatively connected to the at least one second processor, wherein the second memory stores instructions executable by the at least one second processor, the instructions being executed by the at least one second processor to enable the at least one second processor to perform the method as described in the second aspect.

[0035] In a fifth aspect of this application, a software upgrade system is also provided, the system comprising: the server described in the third aspect; and / or the client described in the fourth aspect, the server and the client being communicatively connected.

[0036] In a sixth aspect of this application, a computer-readable storage medium is also provided, the computer-readable storage medium storing computer-executable instructions for causing a computer device to perform the method described in the first aspect or the second aspect.

[0037] It should be understood that the description in the Summary of the Invention section is not intended to limit the key or essential features of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0038] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0039] Figure 1 This is a schematic diagram of the architecture of a software upgrade system provided in some embodiments of this application; Figure 2 This is a schematic diagram of the dependency graph model provided in some embodiments of this application; Figure 3 This is a flowchart illustrating a software upgrade method for a test device provided in some embodiments of this application; Figure 4 This is a flowchart illustrating a software upgrade method for a test device provided in some other embodiments of this application; Figure 5 These are schematic diagrams of the hardware structure of a server provided in some embodiments of this application; Figure 6 This is a schematic diagram of the hardware structure of a client provided in some embodiments of this application. Detailed Implementation

[0040] The principles and spirit of this disclosure will be described below with reference to several exemplary embodiments illustrated in the accompanying drawings. It should be understood that these specific embodiments are described merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art.

[0041] As used herein, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects and are used only to distinguish the objects referred to, without implying a particular spatial order, temporal order, order of importance, etc., of the objects referred to.

[0042] In terms of software upgrades, ATE differs fundamentally from general information technology (IT) servers, personal computer (PC) terminals, and cloud computing nodes, making general IT operation and maintenance solutions unsuitable for ATE software upgrade scenarios. The unique characteristics of ATE compared to general IT equipment are mainly reflected in the following five aspects.

[0043] Firstly, there is a tight coupling between software, firmware, and hardware. In contrast, the software and hardware of general-purpose IT equipment are typically loosely coupled through standardized interfaces, such as Peripheral Component Interconnect Express (PCIe) or Universal Serial Bus (USB) interfaces. Furthermore, software upgrades for general-purpose IT equipment generally do not involve compatibility issues with specific boards.

[0044] Each test board in ATE, such as digitizers, signal generators, and digital I / O cards, requires a driver version that precisely matches the test board's specifications. The test board driver is the interface software between the operating system and the test board, used for initialization, control, data exchange, and runtime scheduling. The test board driver not only needs to be compatible with the operating system but also strictly correspond to the test board's firmware version.

[0045] For example, firmware version 2.0 of a PXI-5162 digitizer board is only compatible with driver versions 3.0 and above. If the driver version is downgraded to 2.x, the digitizer board will fail to initialize, causing the entire ATE to lose its testing capability. This tight coupling between the software, firmware, and hardware layers means that ATE software upgrades must be performed with a thorough understanding of the ATE's hardware configuration; any version mismatch can lead to adverse consequences.

[0046] Secondly, there's the version locking effect of test suites. In general IT equipment, applications typically have relatively loose dependencies on underlying software versions, and environmental isolation can be achieved through technologies like containerization and virtualization. However, in the ATE (Automatic Test Equipment) field, test suites (TPSs) are rigorously validated and certified test solutions; the accuracy of TPS execution results directly affects the quality assessment of the product under test. During the development and validation phases of a TPS, each TPS locks onto the versions of the test execution software, instrument drivers, and operating systems it depends on. If these underlying software versions change, even with minor patch updates, it can lead to deviations in test results, requiring TPS re-qualification. Re-qualification of a TPS not only takes several days to weeks but also incurs high human and equipment costs. Therefore, ATE software upgrades must fully consider the impact on existing TPSs, a problem completely unaddressed by upgrade solutions for general IT equipment.

[0047] Thirdly, the software upgrade process must meet the real-time and continuous requirements of chip production and testing. Maintenance windows for servers in general IT equipment can usually be flexibly scheduled, and short downtime of a single server can be absorbed through load balancing and redundant architecture. However, ATEs (Automatic Test Equipment) on semiconductor production lines undertake 24 / 7 uninterrupted chip testing tasks, with each ATE capable of testing hundreds to thousands of chips per hour. ATE downtime directly leads to chip production capacity loss. Therefore, ATE software upgrades must be able to coordinate with testing tasks, completing the upgrade as little as possible without interrupting or minimizing disruption to chip production and testing.

[0048] Fourthly, there is the high heterogeneity of hardware configurations. In data centers with general-purpose IT equipment, servers typically use standardized configurations, with servers in the same batch having identical hardware. However, in ATE factories, different ATEs require different instrument boards depending on the test object. Even two ATEs of the same model may have different board configurations. This high heterogeneity of hardware configurations means that a uniform software upgrade package cannot be used to upgrade all ATEs in a "one-size-fits-all" manner. Instead, updates must be dynamically generated based on the actual hardware configuration of each ATE.

[0049] Fifthly, the high cost of software upgrade failures. For general IT equipment, software upgrade failures can usually be quickly resolved by reinstalling the system or restoring a virtual machine snapshot. However, if an ATE software upgrade fails, it can easily lead to the following adverse consequences: (1) the test board driver is damaged, causing the board to be unrecognizable, requiring engineers to troubleshoot and repair on-site; (2) the test execution software malfunctions, causing the entire chip production line to stop production, and troubleshooting requires external technical support, making the recovery cycle uncontrollable; (3) the instrument calibration configuration is lost, requiring the calibration process to be re-executed, which takes several hours. In extreme cases, a failed software upgrade can cause the ATE to be shut down for several days, resulting in a loss of millions of yuan in production capacity and a delay in customer delivery. Therefore, the requirements for reliability and recoverability of ATE software upgrades are much higher than those for general IT equipment.

[0050] In recent years, with the increasing demands for semiconductor equipment utilization in the semiconductor manufacturing industry, the industry has begun to explore hot-update technology for semiconductor equipment automation programs. Existing hot-update technologies mainly employ a dynamic script code loading approach based on reflection-based application programming interfaces (APIs). The basic principle of existing hot-update technologies is as follows: a new version of the script code is dynamically loaded into an isolated runtime environment through reflection. After preheating and initialization in the isolated environment, subsequent requests are directed to the new version of the code through atomic switching at the request routing level, thereby achieving code replacement without shutting down the semiconductor equipment.

[0051] However, existing hot update technologies have the following limitations: (1) The scope of application is limited to application layer script code: This scheme relies on the reflection mechanism of scripting languages ​​and the isolation capability of the runtime environment. It is only applicable to the online replacement of interpreted script code and cannot handle the upgrade of compiled system-level software components (such as instrument drivers written in C / C++, operating system kernel patches, etc.); (2) It lacks compatibility pre-detection capability before upgrade: This scheme assumes that the new version code is naturally compatible with the runtime environment and does not involve pre-detection and risk assessment of device hardware configuration, software dependencies and test program compatibility; (3) It lacks system-level automatic rollback capability after upgrade failure: The rollback of this scheme is only to switch the request route back to the old version code, which is an application-level traffic switch and does not involve the restoration of system-level states such as file system, registry, and system services.

[0052] Currently, the software upgrade process of ATE generally suffers from the following problems: (1) Manual operation, low efficiency: The upgrade operation mostly relies on engineers to perform manually, which is cumbersome, time-consuming, and prone to failure due to human error; (2) Lack of risk assessment, frequent compatibility issues: ATE has diverse hardware configurations and different software component versions, and it is impossible to effectively assess the compatibility of the hardware and software environment before the upgrade; (3) Long business interruption time: Traditional upgrade methods require the ATE to be completely shut down, interrupting all test tasks; (4) Poor atomicity of the upgrade process, difficult rollback: The upgrade process involves multiple steps, and the existing methods cannot guarantee the atomicity of these operations. Once a link fails in the middle, the system may be in an inconsistent "intermediate state"; (5) Lack of centralized management and monitoring: In an environment with multiple ATEs, there is a lack of a central platform to uniformly manage the software versions of all ATEs.

[0053] Furthermore, in the general IT operations and maintenance field, although enterprise-level software distribution management systems such as Microsoft SCCM (System Center Configuration Manager) and Red Hat Satellite exist, as well as rolling update and rollback mechanisms in configuration management tools such as Ansible and Puppet, and container orchestration platforms such as Kubernetes, none of these general solutions are designed specifically for the unique needs of ATE. Specifically: tools like SCCM and Ansible lack compatibility testing capabilities for ATE test boards and cannot determine the compatibility between the test board's driver and firmware version; Kubernetes' rolling update mechanism relies on containerization and microservice architecture, while ATE's software stack cannot be containerized; and all general solutions lack the ability to coordinate tasks with ATE's test execution software, making it impossible to implement cold / hot update decisions based on test task status.

[0054] Therefore, the market urgently needs an upgrade method that can automate, intelligentize, and centralize the management of ATE software to solve the problems of low efficiency, high risk, long downtime, and management difficulties in existing technologies.

[0055] In order to overcome the shortcomings of the prior art, this application provides a software upgrade method, server, client, software upgrade system and storage medium for testing equipment, which mainly solves the following technical problems: (1) How to realize automated and centralized unified upgrade management of software for large-scale ATE clusters; (2) How to automatically pre-detect the compatibility of software and hardware environment before upgrade and avoid upgrade risks; (3) How to perform precise updates through differentiated and componentized methods to shorten the upgrade package size and execution time; (4) How to improve the test service interruption caused by software upgrade; (5) How to ensure the atomicity of the upgrade process and realize fast and reliable automatic state rollback when upgrade fails.

[0056] For example, Figure 1 The present application provides schematic diagrams of the architecture of a software upgrade system according to some embodiments, such as... Figure 1 As shown, system 100 includes a server 10 and at least one test device 20. Each test device 20 in the at least one test device 20 is equipped with a client 30. Specifically, system 100 may include one test device 20 or N test devices 20; where N is a positive integer and N is not less than 2. For example, N can be any suitable value such as 10, 15, or 20.

[0057] Specifically, in some embodiments, server 10 may be deployed in a data center or in the cloud. Server 10 and each client 30 may communicate through an internal corporate network; and server 10 and each client 30 may use Hypertext Transfer Protocol Secure (HTTPS) for data interaction to ensure the security of data transmission.

[0058] In some embodiments, server 10 is configured with a version repository. The version repository can be implemented using general-purpose software repositories such as Nexus or Artifactory, or it can be implemented using a custom storage scheme based on object storage. The software stack of each test device 20 is a collection of all software components running within each test device 20, hierarchically structured, and interdependent. Each software component in the collection has multiple versions. The version repository stores version files and metadata corresponding to different versions of each software component within the software stack of each test device 20. Each version corresponds to a version file and a metadata description file. The metadata description file contains metadata including component name, version number, type, hash value, digital signature, release date, dependency list, and hardware compatibility list. The metadata description file can be in JSON format.

[0059] In some embodiments, server 10 also includes a dependency database. The dependency database can be implemented using a graph database such as Neo4j. The dependency database stores and maintains a dependency graph model. This dependency graph model abstracts the version of each software component and the model of each hardware component as nodes in the graph. If a dependency exists between any two nodes, the dependency between the two nodes is abstracted as a directed edge; the attributes of the directed edge include the dependency type and version constraints; wherein, the dependency type includes mandatory dependencies and weak dependencies. Server 10 can traverse the dependency graph model using a graph traversal algorithm to quickly query the dependency path between any two versions, detect circular dependencies, and identify potential version conflicts.

[0060] For example, Figure 2 A schematic diagram of a dependency graph model provided in some embodiments of this application is shown. In this model, circular nodes represent the versions of each software component, and rectangular nodes represent the models of each hardware component. Directed edges between different nodes can be solid arrows or dashed arrows; solid arrows represent mandatory dependency relationships, while dashed arrows represent weak dependency relationships, also known as optional dependency relationships. Figure 2 Nodes 1-7 in the table are: OS Win10_1809, DriverA v2.1, TestExec v5.2, DriverB v3.0, TPS_Memory Test_v3, PXI-6251, and PXI-5162, respectively. OS Win10_1809 represents the version number of the Windows 10 operating system (1809); DriverA v2.1 represents the version number of driver A (v2.1); TestExec v5.2 represents the version number of the test execution software (v5.2); DriverB v3.0 represents the version number of driver B (v3.0); TPS_Memory Test_v3 represents the version number of the memory test program (v3); PXI-6251 represents the model number of the first board; and PXI-5162 represents the model number of the second board.

[0061] exist Figure 2In the dependency graph model, solid arrows pointing from nodes 2 and 4 to node 3 correspond to mandatory dependencies, indicating that TestExec v5.2 strongly depends on DriverA v2.1 and DriverB v3.0. That is, TestExec v5.2's normal operation depends on DriverA v2.1 and DriverB v3.0; without DriverA v2.1 or DriverB v3.0, TestExec v5.2 cannot function correctly. The dependency relationship between two nodes can also be a reference relationship, such as mandatory or weak (optional) dependency references. For example... Figure 2 The dependency graph model also includes a dashed arrow pointing from node 4 to node 2. This dashed arrow corresponds to an optional dependency relationship, indicating that DriverA v2.1 only depends on DriverB v3.0 to achieve some functions, and DriverB v3.0 is not a core condition for DriverA v2.1 to run. Even without DriverB v3.0, the core functions of DriverA v2.1 are not affected, and DriverA v2.1 can still run normally.

[0062] In the embodiments of this application, server 10 can use a graph database to manage the dependency relationships between different software component versions of the target test equipment, as well as the dependency relationships between the versions of each software component of the target test equipment and the models of each hardware. Using a graph database to manage the dependency relationships of ATE software has the following technical advantages: (1) The dependency graph model is suitable for expressing complex relationship networks between different entities, and can intuitively map the many-to-many dependency relationships between different software components and different hardware boards into a graph structure; (2) Server 10 can efficiently perform dependency path queries and cyclic dependency detection between different software components and different hardware boards by traversing the dependency graph model through a graph traversal algorithm, and the time complexity of the full graph traversal process is O(V+E), where V is the total number of nodes in the dependency graph model, E is the total number of dependency edges between each node, and O() is the asymptotic complexity representation symbol of the algorithm; (3) The dependency graph model supports the dynamic addition of nodes and directed edges, and has good scalability.

[0063] In some embodiments, server 10 is also configured with a web user interface and an application programming interface (API). Server 10 can receive upgrade tasks defined by the administrator through the web user interface. The upgrade strategy corresponding to the upgrade task includes: the identifier of the target test device, information on the components to be upgraded in the new version, the release mode, the upgrade time window, and the upgrade failure strategy. The target test device is the test device selected by the administrator from at least one test device; there can be one or multiple target test devices. The administrator can select target test devices according to actual needs. The server supports the administrator to filter target test devices from at least one test device by device tag, device group, or single device. The release mode is the software upgrade distribution execution strategy. The release mode can be a full release or a canary release. A full release refers to completing the software upgrade on all target test devices at once. Canary release is a controlled deployment strategy for software upgrades. It involves gradually upgrading all target test devices in batches and proportions according to preset upgrade rules. First, a small number of target test devices are upgraded to verify the stability and compatibility of the new version. If the upgrade proceeds without issues, the upgrade coverage is continuously expanded. If problems arise, the upgrade task can be paused and rolled back at any time, ultimately completing the upgrade for all devices and ensuring controllable release risks. When the deployment mode is canary release, the upgrade strategy also includes the batch proportions for canary releases.

[0064] In some embodiments, server 10 creates specific upgrade task instances according to the upgrade strategy. Within a preset upgrade time window, server 10 parses the upgrade task instances and generates corresponding upgrade instructions, which are then sent to the client 30 of the target test device via an HTTPS secure channel. If the release mode is a canary release mode, server 10 generates upgrade instructions in batches according to the preset batch ratio and the configuration of the upgrade task instances, and sends the upgrade instructions to each batch of target test devices in batches. After all devices in the previous batch have successfully executed the instructions, the instruction distribution process for the next batch is started.

[0065] Please see Figure 3 This application provides a software upgrade method for a testing device, applied to a server, for example. Figure 1 Server 10 in the middle, such as Figure 3 As shown, the method includes the following steps: Step S31: The server receives an upgrade task, which instructs the software component to be upgraded from the current old version to the new version, so as to obtain the new version software component.

[0066] Specifically, in some embodiments, the server can receive upgrade tasks from the administrator through a web-based user interface. These upgrade tasks include the identifier of the target test device, the version number of the new software component, the release mode, the upgrade time window, and the failure policy. The target test device includes deployed components, which in turn include at least one deployed software component and at least one deployed hardware component. The deployed software components include the software component to be upgraded and at least one non-upgraded software component. The deployed software components include an operating system (OS), test execution software, various instrument drivers, test program sets (TPS), and other auxiliary software tools. The deployed hardware includes circuit boards. The at least one non-upgraded software component refers to all deployed software components other than the software to be upgraded.

[0067] Step S32: The server responds to the upgrade task by obtaining the attribute information of the deployed components reported by the client.

[0068] In some embodiments, step S32 includes: the server responding to the upgrade task by issuing a pre-detection instruction to the client, causing the client to scan the hardware and software environment of the target test device based on the pre-detection instruction, generate an environment snapshot file, and report the environment snapshot file to the server; the server receiving the environment snapshot file reported by the client and obtaining the attribute information of the deployed components based on the environment snapshot file. The attribute information of the deployed software components includes the version number of the deployed software components; the firmware is burned into the deployed hardware; the attribute information of the deployed hardware includes the model of the deployed hardware and the firmware version number.

[0069] Step S33: The server obtains the dependency data of the new version software components. The dependency data includes the attribute information of the new version software components and the attribute information of the specified components. The specified components include at least one specified software component and at least one specified hardware that the new version software components depend on.

[0070] In some embodiments, the dependency data is a dependency graph model, the server is configured with a graph database, and the graph database stores the dependency graph model; step S33 specifically includes: the server obtaining the dependency graph model of the new version software component from the graph database. The dependency graph model includes multiple nodes, including a first node, at least one second node, and at least one third node; a first directed edge is provided between the first node and each of the second nodes in the at least one second node, and a second directed edge is provided between the first node and each of the third nodes in the at least one third node; the first node is used to represent the attribute information of the new version software component; each second node is used to represent the attribute information of each of the specified software components in the at least one specified software component; each third node is used to represent the attribute information of each of the specified hardware in the at least one specified hardware; the first directed edge is used to represent the dependency relationship between the first node and the second node, and the second directed edge is used to represent the dependency relationship between the first node and the third node. For example, in some embodiments, the dependency graph model can be Figure 2 Dependency graph model in [the context of the project].

[0071] Specifically, in some embodiments, dependency data may include attribute information of all specified software components that are dependent on the new version software component and attribute information of all specified hardware, so that the server can query the attribute information of all software components and hardware that are dependent on the new version software component through dependency data; at this time, at least one second node includes attribute information of all specified software components that are dependent on the new version software component, and at least one third node includes attribute information of all hardware that are dependent on the new version software component.

[0072] Step S34: Based on the attribute information and dependency data of the deployed components, the server evaluates the compatibility between the new version of the software components and the deployed components, and obtains the evaluation results.

[0073] In some embodiments, the dependency data includes a first dependency and a second dependency. The new version software component has a first dependency with the specified software component, and the new version software component has a second dependency with the specified hardware. Step S34 specifically includes: the server determines the upgrade risk score corresponding to each evaluation item in a plurality of compatibility evaluation items based on the attribute information of the deployed components and the attribute information of the specified components; the server performs a weighted calculation based on the upgrade risk score corresponding to each evaluation item and the weight value corresponding to each evaluation item to obtain a comprehensive upgrade risk value; wherein, the plurality of compatibility evaluation items include: a first dependency satisfaction degree, which represents the degree of adaptation of each non-upgraded software component in at least one non-upgraded software component to the first dependency; and a second dependency satisfaction degree, which represents the degree of adaptation of each deployed hardware in at least one deployed hardware to the second dependency.

[0074] In some embodiments, the multiple compatibility assessment items further include: version span, which represents the span between the version number of the software component to be upgraded and the version number of the new software component; and historical upgrade history, which refers to the historical upgrade history under the version span. The server can specifically calculate the comprehensive upgrade risk value using the following formula: Overall upgrade risk value = D1×W1 + D2×W2 + D3×W3 + D4×W4; Where D1 is the upgrade risk score corresponding to the satisfaction of the first dependency; D2 is the upgrade risk score corresponding to the satisfaction of the second dependency; D3 is the upgrade risk score corresponding to the version span; D4 is the upgrade risk score corresponding to the historical upgrade situation; W1, W2, W3 and W4 are the weight values ​​corresponding to D1, D2, D3 and D4 respectively, and W1+W2+W3+W4=1.

[0075] In some embodiments, the server determines the upgrade risk score corresponding to each of a plurality of compatibility assessment items based on the attribute information of deployed components and the attribute information of specified components, including: the server determining the upgrade risk score value corresponding to the first dependency satisfaction based on the attribute information of at least one deployed software component and the attribute information of at least one specified software component; the server determining the upgrade risk score value corresponding to the second dependency satisfaction based on the attribute information of at least one deployed hardware and the attribute information of at least one specified hardware; the server determining the size of the version span and determining the upgrade risk score value corresponding to the version span based on the size of the version span; the server determining the historical upgrade success rate of the software component to be upgraded under the version span and determining the upgrade risk score value corresponding to the historical upgrade situation based on the historical upgrade success rate.

[0076] In some embodiments, the attribute information includes a version number, where the version number of the deployed software component is the first version number and the version number of the specified software component is the second version number. The server determines the upgrade risk score corresponding to the first dependency satisfaction based on the attribute information of at least one deployed software component and the attribute information of at least one specified software component. This includes: if the server determines that the at least one deployed software component does not include any of the specified software components in the at least one specified software component set, then the server determines the upgrade security score corresponding to the first dependency satisfaction as a preset first minimum score; if the server determines that the at least one deployed software component includes n specified software components in the at least one specified software component set, then the server determines the upgrade security score corresponding to the first dependency satisfaction based on the first version number and the second version number corresponding to each of the n specified software components, where n is a positive integer not less than 1; the server subtracts the upgrade security score corresponding to the first dependency satisfaction from the first maximum score to obtain the upgrade risk score corresponding to the first dependency satisfaction.

[0077] In some embodiments, the first version number includes a first major version number, and the second version number includes a second major version number; the server determines the upgrade security score corresponding to the first dependency satisfaction based on the first version number and the second version number corresponding to each of the n specified software components, including: if the server determines that the first version number corresponding to any specified software component is not lower than the second version number corresponding to any specified software component, then the server determines that the upgrade security score corresponding to any specified software component is a first full score; if the server determines that the first version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, and the first major version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, then the server determines that the upgrade security score corresponding to any specified software component is a first full score; if the server determines that the first version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, and the first major version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, then the server determines that the upgrade security score corresponding to any specified software component is a first full score. If the difference between the corresponding second major version numbers does not exceed 1, the server determines the upgrade security score value corresponding to any specified software component as the first intermediate score. If the server determines that the first version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, and the difference between the first major version number and the second major version number corresponding to any specified software component exceeds 1, the server determines the upgrade security score value corresponding to any specified software component as the first minimum score. The server calculates the average of the upgrade security scores corresponding to each of the n specified software components to obtain the upgrade security score value corresponding to the first dependency satisfaction. Wherein, the first minimum score < the first intermediate score < the first maximum score. For example, the first minimum score can be 0 points; the first intermediate score can be 50 points; and the first maximum score can be 100 points.

[0078] In some embodiments, the attribute information of the deployed hardware and the specified hardware includes model and firmware version number; the server determines the upgrade risk score corresponding to the second dependency satisfaction based on the attribute information of at least one deployed hardware and the attribute information of at least one specified hardware, including: if the server determines that the model of each of the deployed hardware in the at least one deployed hardware is different from the model of a specified hardware, and the server determines that the dependency type between the specified hardware and the new version software component is mandatory dependency, then the server determines that the upgrade security score corresponding to the specified hardware is the second minimum score; if the server determines that the model of each of the deployed hardware in the at least one deployed hardware is different from the model of a specified hardware, and the server determines that the dependency type between the specified hardware and the new version software component is optional. In the case of dependency, the server determines the upgrade security score corresponding to a specified hardware as the second highest score. If the server determines that at least one deployed hardware includes the target deployed hardware, the server determines the upgrade security score corresponding to the specified hardware based on the firmware version number of the target deployed hardware and the firmware version number of the specified hardware. The server calculates the average of the upgrade security scores corresponding to each specified hardware in the at least one specified hardware to obtain the upgrade security score corresponding to the second dependency satisfaction. The server subtracts the upgrade security score corresponding to the second dependency satisfaction from the second full score to obtain the upgrade risk score corresponding to the second dependency satisfaction. Wherein, the target deployed hardware is deployed hardware of the same model as the specified hardware, and the second lowest score < the second lowest score < the second full score.

[0079] In some embodiments, the server determines an upgrade security score for a specified hardware device based on the firmware version number of the target deployed hardware and the firmware version number of a specified hardware device. This includes: if the server determines that the firmware version number of the target deployed hardware is lower than the firmware version number of the specified hardware device, then the server determines the upgrade security score for the specified hardware device to be a second higher score; if the server determines that the firmware version number of the target deployed hardware is not lower than the firmware version number of the specified hardware device, then the server determines the upgrade security score for the specified hardware device to be a second maximum score; wherein the second lower score < the second higher score < the second maximum score. For example, the second lowest score, the second lowest score, the second highest score, and the second maximum score can be 0, 30, 80, and 100 points, respectively.

[0080] In some embodiments, the server determines the upgrade risk score corresponding to the version span based on the size of the version span, including: if the server determines that the difference between the major version number of the software component to be upgraded and the major version number of the new software component is no more than 1, then the server determines the upgrade risk score corresponding to the version span as the third lowest score; if the server determines that the difference between the major version number of the software component to be upgraded and the major version number of the new software component is greater than 1 but not more than 2, then the server determines the upgrade risk score corresponding to the version span as the third intermediate score; if the server determines that the difference between the major version number of the software component to be upgraded and the major version number of the new software component is greater than 2, then the server determines the upgrade risk score corresponding to the version span as the third highest score; wherein, the third lowest score < the third intermediate score < the third highest score. The version number may include a major version number and a minor version number, for example, for DriverA v2.1; where 2 is the major version number and 1 is the minor version number. The third lowest score, the third intermediate score, and the third highest score can be 5 points, 30 points, and 60 points, respectively.

[0081] In some embodiments, the server determines the upgrade risk score corresponding to a historical upgrade scenario based on the historical upgrade success rate. This includes: the server determining the success rate range within which the historical upgrade success rate falls, where the success rate range and the upgrade risk score have a mapping relationship; and the server determining the upgrade risk score corresponding to the success rate range based on the success rate range and the mapping relationship, thus obtaining the upgrade risk score corresponding to the historical upgrade scenario. In this embodiment, the larger the success rate value within the success rate range, the larger the upgrade risk score corresponding to that range. For example, the upgrade risk score corresponding to the success rate range [95%, 100%] is 5; the upgrade risk score corresponding to the success rate range [80%, 95%] is 20; and the upgrade risk score corresponding to the success rate range [0%, 80%] is 50.

[0082] In some embodiments, after step S34, the method further includes: if the server determines that the overall upgrade risk value is less than a preset risk threshold, the server determines that it is safe to upgrade the software component to be upgraded from the old version to the new version and issues an upgrade instruction to the client; if the server determines that the overall upgrade risk value is not less than the preset risk threshold, the server terminates the upgrade task of the target test device.

[0083] In some embodiments, the method further includes: the server parsing an environment snapshot file to obtain a list of components of the software components to be upgraded; the server determining the difference components in the first component list and the second component list; the server generating a differentiated update package carrying a manifest file based on the difference components; and the server sending the differentiated update package to the client; wherein the difference components include components to be added, components to be deleted, and components to be updated, and the manifest file is used to record the operation type, target path, hash value, and execution order of each component in the difference components; the first component list is a list of components of the software components to be upgraded; and the second component list is a list of components of the new version of the software components.

[0084] In some embodiments, the server sends a differentiated update package to the client, including: if the server receives an update package download request reported by the client, the server sends the differentiated update package to the client.

[0085] In some embodiments, the server includes a preset version repository; the server generates a differential update package carrying a manifest file based on the differential components, including: the server extracting the new version of the component to be added from the preset version repository; the server determining a differential file based on the installation files under the component to be updated in the first component list and the installation files under the component to be updated in the second component list, the differential file including the file to be added, the file to be deleted, and the file to be updated; the server extracting the new version of the file to be added from the preset version repository; if the server determines that the file to be updated supports incremental differential updates, then generating a corresponding differential patch, the differential patch being used to incrementally repair the old version of the file to be updated to obtain the new version of the file to be updated; if the server determines that the file to be updated does not support incremental differential updates, then extracting the new version of the file to be updated from the preset version repository; the server generating a differential update package carrying a manifest file based on the new version of the component to be added, the new version of the file to be added, the differential patch, the new version of the file to be updated, the information of the component to be deleted, and / or the information of the file to be deleted.

[0086] Specifically, in some embodiments, the difference patch is a binary difference patch. If the server determines that the file to be updated supports incremental differential updates, the server generates the corresponding difference patch, including: if the server determines that the file to be updated supports incremental differential updates, the server generates the corresponding difference patch using the bsdiff algorithm.

[0087] In the embodiments of this application, for new version software components and components to be upgraded, the server can perform a component-level overall comparison based on an environment snapshot file. This environment snapshot file contains not only information about the software components of the software already deployed on the target test device, but also hardware configuration information about the hardware already deployed on the target test device, as well as dependency information between each software component and other software components and hardware. Therefore, the server can evaluate hardware compatibility constraints while generating the differentiated update package. If the server determines that any driver in the new version software component is incompatible with the firmware version of the board on the target test device, the server will automatically exclude that driver from the differentiated update package and indicate the reason for exclusion in the manifest file.

[0088] In some embodiments, the number of target test devices is m, where m is a positive integer not less than 1. The method further includes: the server displaying, in real-time, the online status of each of the m target test devices, the version information of the currently installed software, the progress of the ongoing upgrade task, historical upgrade records and results, and detailed operation audit logs through a web-based user interface. If the server determines that any of the m target test devices is offline, has failed to upgrade, or has a comprehensive upgrade risk value not less than a preset risk threshold, it sends an alarm notification via an alarm device. This alarm device can be an indicator light or a speaker, etc.

[0089] Please see Figure 4 This application also provides a software upgrade method for a testing device, applied to a client, for example... Figure 1 Client 30 in the middle, such as Figure 4 As shown, the method includes: Step S41: The client receives the upgrade command issued by the server.

[0090] In some embodiments, if the server determines that the overall upgrade risk value is less than a preset risk threshold, the server will issue an upgrade command to the client. This upgrade command instructs the client to upgrade the currently installed software component to be upgraded on the target test device from its current older version to a newer version. The target test device has test execution software installed, which controls the test suite to execute test tasks.

[0091] Step S42: In response to the upgrade command, the client calls the first application programming interface of the test execution software to query whether the target test device is currently executing a test task.

[0092] Step S43: If the client determines that the target test device is currently executing a test task, and the client determines that the currently running test program set has a dependency relationship with the software component to be upgraded, then the client determines that the current upgrade mode of the software component to be upgraded is the cold update mode.

[0093] Step S44: If the client determines that the target test device is currently executing a test task, and the client determines that the currently running test program set has no dependency relationship with the software component to be upgraded, then the client determines that the current upgrade mode of the software component to be upgraded is hot update mode.

[0094] In some embodiments, if the client determines that the target test device is currently executing a test task, the client extracts the dependency list of the currently running test assembly from the environment snapshot file. This dependency list includes a list of dependencies between various software components that the test assembly depends on for normal operation. The client compares the component to be upgraded with the dependency list of the test assembly. If the component to be upgraded is found in the dependency list, the component to be upgraded is determined to be a core component, and the current upgrade mode of the component to be upgraded is determined to be a cold update mode. If the component to be upgraded is not found in the dependency list, the component to be upgraded is determined to be a non-core component, and the current upgrade mode of the component to be upgraded is determined to be a hot update mode.

[0095] Step S45: In the current upgrade mode, the client upgrades the software component to be upgraded from the current old version to the new version, and obtains the new version software component.

[0096] In some embodiments, step S45 specifically includes: if the client determines that the current upgrade mode of the software component to be upgraded is cold update mode, the client subscribes to the current test batch completion event (such as the TestBatchCompleted event); if the client listens to the current test batch completion event, the client calls the second application programming interface of the test execution software to send a task pause request to the test execution software so that the test execution software pauses test task scheduling; the client upgrades the software component to be upgraded from the current old version to the new version; if the client determines that the software component to be upgraded has been successfully upgraded to the new version, the client calls the third application programming interface of the test execution software to send a task recovery request to the test execution software so that the test execution software resumes test task scheduling.

[0097] Specifically, the first application programming interface (API) can be the IsTesting() API; the second API can be the PauseExecution() API; and the third API can be the ResumeExecution() API.

[0098] In some embodiments, step S45 further includes: if the client determines that the current upgrade mode of the software component to be upgraded is hot update mode, the client determines the component type of the software component to be upgraded; based on the component type, the client determines the hot update mechanism of the hot update mode; the client upgrades the software component to be upgraded from the current old version to the new version based on the hot update mechanism; wherein, the component type is a regular file type, a system service or system daemon type, a dynamic link library type, or an independent process communication type. Regular file type refers to file types other than system service or system daemon type, dynamic link library type, or independent process communication type.

[0099] In some embodiments, the client determines the hot update mechanism based on the component type, including: if the client determines the component type to be a regular file, the client determines the hot update mechanism to be a file lock detection and waiting mechanism; if the client determines the component type to be a system service or system daemon, the client determines the hot update mechanism to be a graceful service restart mechanism; if the client determines the component type to be a dynamic link library, the client determines the hot update mechanism to be a versioned loading mechanism for dynamic link libraries; if the client determines the component type to be an independent process communication type, the client determines the hot update mechanism to be a seamless switching mechanism for inter-process communication.

[0100] In some embodiments, the software component to be upgraded includes an old version file, and the new version software component includes a new version file. The client upgrades the software component to be upgraded from the current old version to the new version based on a hot update mechanism, including: if the client determines that the hot update mechanism is a file lock detection and waiting mechanism, the client determines whether the old version file is locked by other processes; if the client determines that the old version file is locked by other processes, it enters a waiting state; in the waiting state, the client polls the file lock status of the old version file at preset time intervals; if the client determines that the file lock status of the old version file becomes unlocked within a preset first duration, the client replaces the old version file with the new version file; if the client determines that the file lock status of the old version file does not become unlocked within the preset first duration, the client adjusts the current upgrade mode of the software component to be upgraded to a cold update mode. For example, the preset time interval can be 100 milliseconds, and the preset first duration can be 60 seconds.

[0101] In some embodiments, the client upgrades the software component to be upgraded from the current old version to the new version based on a hot update mechanism, including: if the client determines that the hot update mechanism is a graceful restart mechanism, the client sends a graceful stop signal to the software component to be upgraded, which instructs the software component to automatically exit operation after completing the existing business request currently being processed; if the client determines that the software component to be upgraded has not automatically exited operation within a preset second time period, the client sends a forced termination signal to the software component to be upgraded, which forces the software component to exit operation; if the client determines that the software component to be upgraded has automatically exited operation, the client replaces the software component to be upgraded with the new version software component. The preset second time period can be 30 seconds.

[0102] Specifically, in some embodiments, the client sends a graceful stop signal to the software component to be upgraded, including: if the component to be upgraded is running as a Windows service, then the Windows platform sends a SERVICE_CONTROL_STOP control code to the software component to be upgraded through Service Control Manager; if the component to be upgraded is running as a Linux daemon, then the Linux platform sends a SIGTERM signal to the software component to be upgraded.

[0103] In some embodiments, the client upgrades the software component to be upgraded from the current old version to the new version based on a hot update mechanism, including: if the client determines that the hot update mechanism is a dynamic link library versioning loading mechanism, then if the new version software component is configured with a name carrying a version identifier, the client copies the new version software component to the storage directory of the software component to be upgraded, and retains the software component to be upgraded in the storage directory; the client modifies the configuration file or registry configuration item corresponding to the software component to be upgraded, updating the loading path configuration of the software component to be upgraded to point to the new version software component carrying the version identifier; when the host process that depends on the dynamic link library file loads the corresponding software component to be upgraded the next time, the client automatically loads and runs the new version software component; the client monitors the running status of the new version software component; if the client confirms that the running status is stable, the client marks the software component to be upgraded remaining in the storage directory as cleanable. The dynamic link library file can be a dynamic link library under the Windows system with the suffix .dll; the dynamic link library file can also be a dynamic shared library under the Linux / Unix system with the suffix .so.

[0104] In some embodiments, the client upgrades the software component to be upgraded from the current old version to the new version based on a hot update mechanism, including: if the client determines that the hot update mechanism is a seamless inter-process communication switching mechanism, the client copies the new version software component to the storage directory of the software component to be upgraded; the client starts the new version service process, binds the new version service process to a communication identifier consistent with the old version service process, and the operating system of the target test device automatically routes subsequent new communication requests sent to the old version service process to the new version service based on the communication identifier; if the client determines that the old version service process has finished processing the existing access requests and exited, the client determines that the software component to be upgraded in the storage directory can be cleaned up; wherein, the new version service process is the business service process corresponding to the new version software component; the old version service process is the business service process corresponding to the software component to be upgraded.

[0105] In some embodiments, upgrading a software component to a new version includes: performing an update operation to upgrade the software component from an old version to a new version in an atomic transaction manner based on a write-ahead transaction log (WAL) mechanism.

[0106] In some embodiments, the update operation includes multiple operation steps, and the target operation step is any one of the multiple operation steps. The client executes the upgrade operation of the software component to be upgraded from the old version to the new version in an atomic transaction manner based on the write-ahead transaction log mechanism, including: the client creates a transaction log file, writes the transaction identifier of the update operation, the transaction start time, and the information of the new version of the software component into the transaction log file, and marks the transaction status of the update operation as "started"; the client executes each operation step in the multiple operation steps in a preset operation order; during the sequential execution of each operation step in the multiple operation steps, the client first writes the operation content of the target operation step and the inverse operation corresponding to the target operation step into the transaction log. The client then executes the target operation steps. If the client determines that the target operation steps were executed successfully, the client marks the transaction status of the target operation steps as "completed" in the transaction log file. If the client determines that each of the multiple operation steps was executed successfully, the client marks the transaction status of the update operation as "completed" in the transaction log file. If the client determines that the target operation steps failed, the client marks the transaction status of the target operation steps as "rollback in progress" in the transaction log file, and executes the reverse operation of each completed operation step in the reverse order of the preset operation sequence. If the client determines that the reverse operation of each completed operation step has been executed, the client marks the transaction status of the update operation as "rollback completed" in the transaction log file.

[0107] In some embodiments, the method further includes: if the client determines that each of the multiple operation steps has been successfully executed, the client checks the upgrade result, which is either successful or abnormal; if the client determines that the upgrade result is abnormal, a rollback mechanism is triggered; under the rollback mechanism, the client reads the transaction log file to obtain the inverse operations of all completed operation steps; the client executes the inverse operations of each completed operation step in reverse order; if the client determines that all inverse operations of each operation step have been completed, the client determines whether the current service state has been restored to the state before the upgrade based on the system state snapshot file; if the client determines that the current service state has been restored to the state before the upgrade, the client checks whether the software operating system of the target test device can work normally; wherein, the service state is the running state of the service associated with the software component to be upgraded.

[0108] In some embodiments, the above method further includes: the client creating a system status snapshot file, and creating a system status snapshot file includes: the client traversing the installation directory of the software component to be upgraded, copying all files in the installation directory to a backup directory with timestamps, and generating file backup data; the client exporting and saving registry entries and configuration files associated with the software component to be upgraded, and generating configuration backup data; the client recording the current service running status associated with the software component to be upgraded, and generating service status backup data; the client writing the index information of the file backup data, configuration backup data, and service status backup data into a snapshot description file to obtain a system status snapshot file.

[0109] In some embodiments, the above method further includes: if the client receives a pre-detection instruction from the server, the client responds to the pre-detection instruction by scanning the current hardware and software environment of the target test device to generate an environment snapshot file, and reports the environment snapshot file to the server.

[0110] In some embodiments, the client scans the current hardware and software environment of the target test device to generate an environment snapshot file. This includes: the client scanning the current hardware and software environment of the target test device to obtain scan results; the scan results include attribute information (hardware configuration information) of each deployed hardware component in at least one deployed hardware component of the target test device, and attribute information (such as version number) of each deployed software component in at least one deployed software component of the target test device; the client organizes the scan results into a JSON-formatted environment snapshot file. The hardware configuration information includes: motherboard model, list of installed cards and their firmware version numbers, memory, and storage capacity.

[0111] For example, if the target test device runs a Windows operating system, the client can obtain the hardware configuration information of the target test device by executing Windows Management Instrumentation (WMI) query commands. If the target test device runs a Linux operating system, the client can obtain the hardware configuration information of the target test device by reading the file nodes of the process pseudo-filesystem ( / proc) and the system device pseudo-filesystem ( / sys). If the target test device runs a Windows operating system, the client can obtain the attribute information of the software components deployed on the target test device by reading the registry; if the target test device runs a Linux operating system, the client can obtain the attribute information of the software components deployed on the target test device by reading the package management database. Specifically, the client obtains the detailed version numbers of the deployed software components by scanning the file version information in a specified directory.

[0112] Specifically, in some embodiments, the environment snapshot file includes the target test device's device identifier, scan timestamp, hardware configuration information, and software information. The hardware configuration information includes the motherboard model, a list of installed cards, memory capacity, and storage capacity. The list of installed cards includes the slot number, card model, serial number, and firmware version number of each installed card. The attribute information of each deployed software component includes: the name, version number, and compilation version number of the operating system; the version of the test execution software; the list of instrument drivers; and the list of deployed test assemblies. The list of instrument drivers includes the name, version number, and installation path of each driver. The list of deployed test assemblies includes the name and corresponding version number of each test assembly.

[0113] In some embodiments, the method further includes the client sending an update package download request to the server, so that the server responds to the update package download request by sending a differentiated update package to the client. If the client receives the differentiated update package, the client performs an integrity check on the downloaded update package.

[0114] In some embodiments, the client performs integrity verification on the downloaded update package, specifically including: the client verifying the digital signature of the differentiated update package to confirm whether the source of the differentiated update package is trustworthy, and confirming whether the differentiated update package has been tampered with; if the client determines that the source of the differentiated update package is untrustworthy or the differentiated update package has been tampered with, the client determines that the update package is unusable.

[0115] If the client determines that the differentiated update package has not been tampered with and its source is trustworthy, the client calculates the hash value of the differentiated update package and compares it with the hash value of the differentiated update package provided by the server. If the client determines that the hash value of the differentiated update package calculated by the client does not match the hash value of the differentiated update package provided by the server, the client determines that the differentiated update package cannot be used for software updates. If the client determines that the hash value of the differentiated update package calculated by the client matches the hash value of the differentiated update package provided by the server, the client decompresses the differentiated update package and verifies one by one whether the hash value of each file in the differentiated update package calculated by the client matches the hash value of each file recorded in the manifest file of the differentiated update package. If the client determines that the hash value of any file in the differentiated update package matches the hash value of that file recorded in the manifest file of the differentiated update package, the client determines that that file can be used for software updates. If the client determines that the hash value of any file in the differentiated update package does not match the hash value recorded in the manifest file of the differentiated update package, the client determines that that file cannot be used for software updates.

[0116] Specifically, in some embodiments, the hash value can be a Message-Digest Algorithm Version 5 (MD5) hash value; Several embodiments of this application are provided below.

[0117] Example 1 This application example illustrates upgrading the instrument driver DriverB (the software component to be upgraded) from version 2.5 (old version) to version 3.0 (new version). The method for upgrading DriverB from version 2.5 to version 3.0 is as follows: Step S101: The administrator logs into the server's web interface and uploads a new version of the instrument driver, DriverB.zip, to server 10. The version number of this new instrument driver is 3.0. Simultaneously, the administrator adds directed edges to the dependency database through the web interface for the new version of the instrument driver, indicating that the new version of the instrument driver depends on test execution software version 5.2 or higher, and that the new version of the instrument driver is compatible with PXI-5162 boards with firmware version 2.0 or higher.

[0118] Step S102: The administrator creates a canary release strategy through the web interface, selects 5 automatic test devices labeled "Production Line A" as the first batch of target test devices, specifies that DriverB will be upgraded to version 3.0, the preset upgrade time window is 2:00-4:00 AM, and the canary ratio is to upgrade the first batch of 2 target test devices (40%) first, and then upgrade the remaining 3 target test devices in the first batch after verification.

[0119] Step S103: Before the preset upgrade time window arrives, the server sends a pre-detection command to the clients of the two target test devices (ATE-001 and ATE-002) in the first batch of target test devices, so that each client 30 of the two target test devices can perform a local environment scan of each target test device, generate an environment snapshot file of each target test device, and report the environment snapshot file of each target test device to the server 10.

[0120] Step S104: After receiving the environment snapshot files reported by each client, the server performs a compatibility analysis between the new version of the instrument driver and the target test equipment. The specific process is as follows: (a) Server 10 extracts the version number of the currently deployed test execution software (TestExec) and the firmware version number of the PXI-5162 board from the environment snapshot file; (b) Server 10 queries the dependency relationship database for DriverB 3.0; (c) The server compares the version number of the currently deployed test execution software (TestExec) and the firmware version number of the PXI-5162 board with the dependency relationship of DriverB 3.0 item by item, checking whether the TestExec version number is ≥5.2 and whether the firmware version number of the PXI-5162 board is ≥2.0; (d) If Server 10 determines that all dependencies of DriverB 3.0 are satisfied, the server can calculate the comprehensive upgrade risk value using the following formula: Overall upgrade risk value = D1×W1 + D2×W2 + D3×W3 + D4×W4; Where D1 is the upgrade risk score corresponding to the satisfaction of the first dependency; D2 is the upgrade risk score corresponding to the satisfaction of the second dependency; D3 is the upgrade risk score corresponding to the version span; D4 is the upgrade risk score corresponding to the historical upgrade situation; W1, W2, W3 and W4 are the weight values ​​corresponding to D1, D2, D3 and D4 respectively, and W1+W2+W3+W4=1.

[0121] For example, in this embodiment, W1=0.4, W2=0.3, W3=0.2, and W4=0.1. The calculation methods for D1, D2, D3, and D4 are described in the above embodiment. Assuming device ATE-001 has TestExec version 5.3 and the PXI-5162 board firmware version 2.1, with a historical upgrade success rate of 98% and all dependencies satisfied, the sub-scores are as follows: D1=0; D2=0; D3=30 (upgrading the software component from 2.5 to 3.0); D4=5. The overall upgrade risk value = 0×0.4 + 0×0.3 + 30×0.2 + 5×0.1 = 6.5, which is lower than the preset risk threshold of 30. Therefore, the client determines that the software component to be upgraded can be safely upgraded and generates a compatibility analysis report. Device ATE-001 passes the pre-test. Assuming device ATE-002 has TestExec version 5.0, which does not meet the dependency requirement of ≥5.2, the calculated overall upgrade risk value is 75. Therefore, the client determines that the software component to be upgraded cannot be upgraded, alerts the administrator, and excludes ATE-002 from this upgrade task.

[0122] Step S105: If the compatibility analysis report indicates that the software component to be upgraded can be safely upgraded, after the administrator confirms the compatibility analysis report, the server will issue a formal upgrade command to the device ATE-001 that has passed the pre-detection when the preset upgrade time window of 2:00 AM arrives.

[0123] Step S106: After receiving the upgrade command, the client on ATE-001 sends an IsTesting() query to the API interface of the test execution software to check whether the test execution software is executing a test task. If the return is no, proceed directly to step S107. If the return is yes, determine whether DriverB is a core component: Since DriverB is an instrument driver and the currently running test program TPS_MemoryTest_v3 references DriverB, DriverB is determined to be a core component. The client subscribes to the TestBatchCompleted event, waits for the current test batch to complete, calls PauseExecution(), sends a pause test task scheduling message to the test execution software, and then proceeds to step S107.

[0124] Step S107: The client sends a differential update package download request to the server. The server generates a differential update package for DriverB 3.0 based on the differences between the software components to be updated and the new version software components in the ATE-001 environment snapshot file. After downloading the differential update package, the client verifies the digital signature and MD5 hash value of the differential update package and confirms that the verification is successful.

[0125] Step S108: The client begins executing the update operation for the component to be upgraded. The client first creates a system state snapshot file for ATE-001: backing up all files of DriverB 2.5 to the backup directory, exporting DriverB-related registry entries, and recording the current state of the DriverB service. Then, it initializes the transaction log and begins executing the update operation for the software component to be upgraded using atomic transactions. The steps for the client to execute the update operation of the software component to be upgraded using atomic transactions are shown in the table below: Table 1:

[0126] After the client executes the update operation of the software component to be upgraded using atomic transactions, the client begins a self-check, with the following steps: (a) The client checks the file version in the DriverB installation directory and confirms that the file version is 3.0; (b) The client checks the DriverBService service status and confirms that it is "running"; (c) The client calls the DriverB initialization interface to attempt to establish communication with the PXI-5162 board and confirms that the communication is normal. After all self-checks pass, the transaction log is marked as "COMMITTED", and the client reports "upgrade successful" to the server. The client calls the ResumeExecution() interface of the test execution software to resume the test task scheduling of the test execution software.

[0127] If the client determines that the self-check has failed, a rollback mechanism is triggered. Under the rollback mechanism, the client reads the transaction log and performs the reverse operation in reverse order of the update operation sequence: first, it forcibly terminates the DriverBService related processes; then, it deletes the DriverB 3.0 file, restores the .bak file to its original name, restores the version number in the registry to 2.5, and finally restarts the DriverBService service. After the rollback operation is completed, the client confirms that the DriverBService service status has returned to normal based on the system state snapshot, performs a simplified self-check to confirm that DriverB 2.5 is working properly, and reports "upgrade failed" and detailed error logs to server 10. After the first batch of devices (ATE-001) successfully upgrades, the server automatically initiates the second phase of the canary release, repeating steps S103 to S110 for the remaining three devices. If the first batch of devices fails to upgrade, the entire canary release task is aborted.

[0128] Example 2 In this embodiment, the administrator needs to install Windows security patch KB5034441 on all ATE devices. This patch is an operating system-level update, and the update steps are as follows: The administrator uploaded patch KB5034441 to version repository 101 and marked it in dependency database 102 as applicable to Windows 10 1809 and above, and compatible with TestExec 2021 SP1 and above.

[0129] The administrator creates a full release policy through the web user interface, selects all online ATEs as the target, and sets the preset upgrade time window to 1:00-5:00 AM on weekends.

[0130] The pre-detection and compatibility analysis process is described in Example 1, with a focus on checking whether the Windows version of each device meets the applicability requirements of the patch.

[0131] Since operating system patches are core components, the upgrade mode is a cold update mode. The client must wait for all test tasks to be completed and test scheduling to be paused before it can perform the update operation.

[0132] During backup and atomic updates, the system state snapshot file additionally includes the creation of system restore points. The client calls the Windows Update API to install patches, and the patch installation operation and its reverse operation are recorded in the transaction log. The self-test process additionally includes boot verification after a system restart.

[0133] In practical applications, ATE devices can also run on the Linux operating system. When administrators need to install security patches for Linux on all ATE devices, they can follow the steps described above for the update, which will not be repeated here.

[0134] Example 3 This embodiment designs a hot update for non-core components. Specifically, it requires upgrading an auxiliary data analysis tool software, DataAnalyzer, from version 1.0 to version 1.1. This software does not participate in the test execution process and is considered a non-core component. This embodiment focuses on demonstrating the specific execution process of the hot update mode. In this embodiment, the definition of the upgrade strategy, pre-detection, and compatibility analysis process can be referred to in Embodiment 1.

[0135] The client queries whether the test execution software is currently running a test task and confirms that it is. The client retrieves the dependency list of the currently running test program TPS_MemoryTest_v3 from the environment snapshot and confirms that DataAnalyzer is not on the dependency list; therefore, DataAnalyzer is determined to be a non-core component. The client decides to update DataAnalyzer using a hot update mode, without pausing the test task.

[0136] The client begins executing the DataAnalyzer hot update process. First, the client creates a system state snapshot file, backing up all files and related configurations of DataAnalyzer 1.0. Then, the client performs the following steps: (a) File lock detection: Checks if the DataAnalyzer executable and DLL files are locked by other processes. The detection finds that DataAnalyzer.exe is running, and its main program file is locked; (b) Graceful service shutdown: Sends a graceful shutdown signal to the DataAnalyzer service, waiting for DataAnalyzer to complete its current data analysis task and exit automatically. DataAnalyzer exits within 5 seconds, releasing the file lock; (c) File replacement: Renames the DataAnalyzer 1.0 files to the .bak extension and copies the DataAnalyzer 1.1 files to the installation directory; (d) Configuration update: Updates the DataAnalyzer version number in the registry to 1.1; (e) Service restart: Starts the DataAnalyzer 1.1 service. The entire hot update process takes approximately 8 seconds. During this time, the running test task TPS_MemoryTest_v3 is unaffected, and the test data acquisition and judgment process continues normally.

[0137] After the client performs a self-check to confirm that DataAnalyzer 1.1 is running normally, it reports a successful upgrade. The transaction log is marked as "completed".

[0138] Example 4 This embodiment group covers the complete rollback process after an upgrade failure. This embodiment details how the client can achieve a complete and reliable automatic rollback using transaction logs and system state snapshot files when an upgrade failure occurs. Assume that during the process of upgrading the test execution software TestExec from version 5.2 to version 5.3 on device ATE-003, a failure occurs in the atomic execution phase.

[0139] Upgrade execution process: The client first creates a system state snapshot, backs up all files of TestExec 5.2, exports the TestExec-related registry entries, and records that the current status of both the TestExecService and TestExecEngine services is "running". Then, the client initializes the transaction log and executes the update operation of the software component to be upgraded using atomic transactions. The steps are as follows: Table 2:

[0140] When executing step 6 in Table 2, the TestExecEngine service failed to start, and the error log showed that "TestExecEngine.dll" failed to load, indicating a missing dependency library NI-VISA 2024Q1. Upon detecting the failure of step 6, the client immediately changed the transaction status from "EXECUTING" to "FAILED" and triggered the rollback mechanism.

[0141] The rollback process is as follows: Under the rollback mechanism, the client changes the transaction status from "execution failed" to "rollback in progress (ROLLING_BACK)" and begins executing the rollback operation in reverse order of the update operations recorded in the transaction log. As shown in Table 3, the rollback order starts from the last completed operation step (step 5) and gradually rolls back to step 1: Table 3:

[0142] Since step 6 itself failed, its status is "execution failed," therefore, the reverse operation of step 6 does not need to be performed during rollback. Step 7's status is "not started (NOT_STARTED)," so similarly, no rollback operation is needed for step 7. Rollback operations are only performed on steps with a status of "completed."

[0143] Integrity verification after rollback: As shown in Table 4, after all reverse operations are completed, the client compares the pre-upgrade state recorded in the system state snapshot file with the current actual state item by item: Table 4:

[0144] If the client determines that the comparison results of all validation items are consistent, the client performs a simplified self-check. The simplified self-check steps are as follows: The client calls the initialization interface of TestExec 5.2 to confirm that the test execution software can load normally and respond to the call. After the self-check passes, the client changes the transaction status of the update operation from "rolling back" to "rolled back" and reports the upgrade failure information to the server. The upgrade failure information includes the reason for failure, the failure steps, the rollback status, and recommended measures.

[0145] The rollback mechanism of this application has the following advantages: First, the reverse rollback based on the transaction log can accurately undo only the executed operations; second, the integrity verification based on the system state snapshot can ensure that the system state after rollback is completely consistent with that before the upgrade; third, the rollback report includes failure cause analysis and suggested measures, providing valuable reference information for administrators to conduct subsequent investigations and re-upgrades.

[0146] This application's embodiments construct a closed-loop system around the entire lifecycle of ATE software upgrades, where each step has a tight data flow dependency and logical coordination relationship. The environment snapshot file is the core data carrier throughout the entire process. Generated in the pre-detection step, it is used not only for compatibility analysis but also to calculate the differences in components that need updating and to determine whether the component to be upgraded is a core component. The system state snapshot file and transaction log constitute dual recovery protection. The transaction log is used to accurately undo each executed update operation step, while the system state snapshot file is used for integrity verification after the reverse operation is completed. The self-test step is the key hub connecting the normal process and the rollback process; its result determines the direction of subsequent processes.

[0147] The embodiments of this application have the following beneficial effects: (1) Improve the efficiency and automation level of software upgrades for testing equipment: Through a centralized management platform and automated upgrade process, the manual software upgrade work that originally took several days or even weeks can be shortened to several hours. In actual testing, the software upgrade of a cluster of 50 automated testing equipment using the method provided in this application took about 3 hours, while the traditional manual upgrade method takes about 5 working days.

[0148] (2) Reduce upgrade risks: The pre-upgrade detection and compatibility analysis mechanism can detect potential software and hardware conflicts in advance, reducing upgrade risks. In practical applications, the pre-detection mechanism can successfully intercept about 15% of incompatible upgrade requests.

[0149] (3) Reduce business interruption time: Differentiated updates reduce download and installation time (the average size of the differentiated update package is only 20%-35% of the full update package), while the unique "hot update" and test task coordination mechanism allows some upgrades to be completed without interrupting or with minimal interruption of test tasks.

[0150] (4) Ensuring high reliability: The atomic upgrade execution process and intelligent state rollback mechanism ensure that the upgrade operation is "either completely successful or completely recovered", which helps to reduce the possibility of the system falling into an unstable "intermediate state".

[0151] (5) Achieve refined management and traceability: The central control platform provides a global view of the software version of the entire ATE equipment cluster, flexible upgrade strategies (including canary releases), and complete operation audit logs.

[0152] (6) The overall effect of the synergy of each step surpasses the simple sum of individual technologies: The six steps of this invention—pre-detection, task coordination, differentiated update, atomic execution, self-check verification, and intelligent rollback—form a tightly coupled closed-loop system by sharing core data such as environment snapshots, system status snapshots, and transaction logs. This collaborative design makes the overall solution significantly better than the effect of applying each individual technology independently in key indicators such as upgrade success rate (over 99.5%), reduction in equipment downtime (over 85%), and rollback success rate (100%).

[0153] For example, Figure 5 A hardware structure diagram of server 50 is shown. (For example...) Figure 5 As shown, the server 50 includes: One or more first processors 51 and a first memory 52, Figure 5 Take the first processor 51 as an example.

[0154] The first processor 51 and the first memory 52 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0155] The first memory 52, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the methods in the embodiments of this application. The first processor 51 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the first memory 52, thereby implementing the methods in the above-described method embodiments.

[0156] The first memory 52 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on server usage. Furthermore, the first memory 52 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the first memory 52 may optionally include memory remotely located relative to the first processor 51. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0157] The one or more modules are stored in the first memory 52. ​​When executed by the one or more first processors 51, they perform the methods in any of the above method embodiments, for example, the methods described above. Figure 3 Method steps S31-S34.

[0158] For example, Figure 6 A hardware structure diagram of client 60 is shown. (For example...) Figure 6 As shown, the client 60 includes: One or more second processors 61 and a second memory 62, Figure 6 Take a second processor 61 as an example.

[0159] The second processor 61 and the second memory 62 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0160] The second memory 62, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the methods in the embodiments of this application. The second processor 61 executes various functional applications and data processing of the client by running the non-volatile software programs, instructions, and modules stored in the second memory 62, thereby implementing the methods in the above-described method embodiments.

[0161] The second memory 62 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on client usage. Furthermore, the second memory 62 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the second memory 62 may optionally include memory remotely located relative to the second processor 61. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0162] The one or more modules are stored in the second memory 62. When executed by the one or more second processors 61, they perform the methods in any of the above method embodiments, for example, the methods described above. Figure 4 Method steps S41-S45.

[0163] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 5 One of the first processors 51 or Figure 6 A second processor 61 in one of the above-described methods may enable the one or more processors to perform the methods in any of the above-described method embodiments, for example... Figure 3 Method steps S31-S34, Figure 4 Method steps S41-45.

[0164] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0165] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0166] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; under the concept of the present invention, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the present invention as described above, which are not provided in detail for the sake of brevity; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and 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 the present invention.

Claims

1. A software upgrade method for a testing device, applied to a server, characterized in that, The target test equipment includes deployed components, which include at least one deployed software component and at least one deployed hardware component, and the deployed software component includes a software component to be upgraded and at least one non-upgraded software component; The method includes: Receive an upgrade task, the upgrade task being used to instruct the software component to be upgraded from the current old version to a new version, so as to obtain a new version software component; In response to the upgrade task, the attribute information of the deployed components reported by the client is obtained, wherein the attribute information of the deployed components includes the attribute information of the at least one deployed software component and the attribute information of the at least one deployed hardware component. Obtain the dependency data of the new version software component. The dependency data includes the attribute information of the new version software component and the attribute information of a specified component. The specified component includes at least one specified software component and at least one specified hardware that the new version software component depends on. The dependency data includes a first dependency relationship and a second dependency relationship. The new version software component has the first dependency relationship with the specified software component and the new version software component has the second dependency relationship with the specified hardware. Based on the attribute information of the deployed components and the dependency data, the compatibility between the new version software component and the deployed components is evaluated to obtain an evaluation result, including: determining the upgrade risk score corresponding to each evaluation item in a plurality of compatibility evaluation items based on the attribute information of the deployed components and the attribute information of the specified component; performing a weighted calculation based on the upgrade risk scores corresponding to each evaluation item and the weight values ​​corresponding to each evaluation item to obtain a comprehensive upgrade risk value; wherein, the plurality of compatibility evaluation items include: a first dependency satisfaction degree and a second dependency satisfaction degree, wherein the first dependency satisfaction degree characterizes the degree of adaptation of each non-upgradeable software component in the at least one non-upgradeable software component to the first dependency; and the second dependency satisfaction degree characterizes the degree of adaptation of each deployed hardware in the at least one deployed hardware to the second dependency.

2. The method according to claim 1, characterized in that, The multiple compatibility evaluation items also include: Version span, which represents the span between the version number of the software component to be upgraded and the version number of the new version software component; and Historical upgrade history, which refers to the historical upgrade history within the aforementioned version span.

3. The method according to claim 2, characterized in that, The step of determining the upgrade risk score corresponding to each of the multiple compatibility assessment items based on the attribute information of the deployed components and the attribute information of the specified components includes: Based on the attribute information of the at least one deployed software component and the attribute information of the at least one specified software component, determine the upgrade risk score corresponding to the first dependency satisfaction. Based on the attribute information of the at least one deployed hardware and the attribute information of the at least one specified hardware, determine the upgrade risk score corresponding to the second dependency satisfaction. Determine the size of the version span, and based on the size of the version span, determine the upgrade risk score corresponding to the version span; Determine the historical upgrade success rate of the software component to be upgraded within the version span, and determine the upgrade risk score corresponding to the historical upgrade situation based on the historical upgrade success rate.

4. The method according to claim 3, characterized in that, The attribute information includes a version number, wherein the version number of the deployed software component is a first version number, and the version number of the specified software component is a second version number; The step of determining the upgrade risk score corresponding to the first dependency satisfaction based on the attribute information of the at least one deployed software component and the attribute information of the at least one specified software component includes: If it is determined that the at least one deployed software component does not include any of the specified software components among the at least one specified software components, then the upgrade security score corresponding to the first dependency satisfaction is determined to be a preset first minimum score. If it is determined that the at least one deployed software component includes n specified software components among the at least one specified software components, then based on the first version number and the second version number corresponding to each of the n specified software components, the upgrade security score corresponding to the first dependency satisfaction is determined, where n is a positive integer not less than 1; Subtract the upgrade security score corresponding to the first dependency satisfaction from the first full score to obtain the upgrade risk score corresponding to the first dependency satisfaction.

5. The method according to claim 4, characterized in that, The first version number includes the first major version number, and the second version number includes the second major version number; The step of determining the upgrade security score corresponding to the first dependency satisfaction based on the first version number and second version number of each of the n specified software components includes: If it is determined that the first version number of any one of the n specified software components is not lower than the second version number of any one specified software component, then the upgrade security score value of any one specified software component is determined to be the first full score value. If it is determined that the first version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, and the difference between the first major version number corresponding to any specified software component and the second major version number corresponding to any specified software component does not exceed 1, then the upgrade security score value corresponding to any specified software component is determined to be the first intermediate score. If it is determined that the first version number corresponding to any specified software component is lower than the second version number corresponding to any specified software component, and the difference between the first major version number corresponding to any specified software component and the second major version number corresponding to any specified software component exceeds 1, then the upgrade security score value corresponding to any specified software component is determined to be the first minimum score. Calculate the average of the upgrade security score values ​​corresponding to each of the n specified software components to obtain the upgrade security score value corresponding to the first dependency satisfaction. Wherein, the first minimum score < the first intermediate score < the first maximum score.

6. The method according to claim 3, characterized in that, The attribute information of the deployed hardware and the specified hardware includes the model and firmware version number; The step of determining the upgrade risk score corresponding to the second dependency satisfaction based on the attribute information of the at least one deployed hardware and the attribute information of the at least one specified hardware includes: If it is determined that the model of each of the deployed hardware in the at least one deployed hardware is different from the model of the specified hardware, and it is determined that the type of dependency relationship between the specified hardware and the new version software component is a forced dependency, then the upgrade security score value corresponding to the specified hardware is determined to be the second lowest score. If it is determined that the model of each of the deployed hardware in the at least one deployed hardware is different from the model of the specified hardware, and it is determined that the dependency relationship between the specified hardware and the new version software component is of the optional dependency type, then the upgrade security score corresponding to the specified hardware is determined to be the second lower score. If it is determined that the at least one deployed hardware includes the target deployed hardware, then the upgrade security score value corresponding to the specified hardware is determined based on the firmware version number of the target deployed hardware and the firmware version number of the specified hardware. Calculate the average of the upgrade security score values ​​corresponding to each of the at least one specified hardware to obtain the upgrade security score value corresponding to the second dependency satisfaction. Subtract the upgrade security score corresponding to the second dependency satisfaction from the second full score to obtain the upgrade risk score corresponding to the second dependency satisfaction. Wherein, the target deployed hardware is deployed hardware of the same model as the specified hardware, and the second minimum score < the second lower score < the second maximum score.

7. The method according to claim 6, characterized in that, The step of determining the upgrade security score value corresponding to the specified hardware based on the firmware version number of the target deployed hardware and the firmware version number of the specified hardware includes: If it is determined that the firmware version number of the target deployed hardware is lower than the firmware version number of the specified hardware, then the upgrade security score value corresponding to the specified hardware is determined to be the second higher score. If it is determined that the firmware version number of the target deployed hardware is not lower than the firmware version number of the specified hardware, then the upgrade security score value corresponding to the specified hardware is determined to be the second full score value. Among them, the second lower score < the second higher score < the second full score.

8. The method according to claim 3, characterized in that, The determination of the upgrade risk score corresponding to the version span based on the size of the version span includes: If it is determined that the difference between the major version number of the software component to be upgraded and the major version number of the new version software component does not exceed 1, then the upgrade risk score corresponding to the version span is determined to be the third lowest score. If the difference between the major version number of the software component to be upgraded and the major version number of the new version software component is determined to be greater than 1 and not more than 2, then the upgrade risk score corresponding to the version span is determined to be the third intermediate score. If the difference between the major version number of the software component to be upgraded and the major version number of the new version software component exceeds 2, then the upgrade risk score corresponding to the version span is determined to be the third highest score. Wherein, the third lowest score < the third intermediate score < the third highest score.

9. The method according to claim 3, characterized in that, The determination of the upgrade risk score corresponding to the historical upgrade situation based on the historical upgrade success rate includes: Based on the historical upgrade success rate, a success rate interval is determined where the historical upgrade success rate falls, and the success rate interval and the upgrade risk score have a mapping relationship; Based on the success rate range and the mapping relationship, the upgrade risk score corresponding to the success rate range is determined, and the upgrade risk score corresponding to the historical upgrade situation is obtained.

10. The method according to claim 1, characterized in that, After obtaining the comprehensive upgrade risk value, the method further includes: If the overall upgrade risk value is determined to be less than the preset risk threshold, it is determined that the software component to be upgraded can be safely upgraded from the old version to the new version, and an upgrade command is issued to the client. If the overall upgrade risk value is determined to be not less than a preset risk threshold, the upgrade task of the target test equipment is terminated.

11. The method according to claim 1, characterized in that, The dependency data is a dependency graph model, and the server is configured with a graph database, which stores the dependency graph model. The process of obtaining the dependency data of the new version software components includes: Obtain the dependency graph model of the new version software components from the graph database; The dependency graph model includes multiple nodes, including a first node, at least one second node, and at least one third node. A first directed edge is provided between the first node and each of the second nodes among the at least one second node, and a second directed edge is provided between the first node and each of the third nodes among the at least one third node; The first node is used to represent the attribute information of the new version of the software component; Each second node is used to represent the attribute information of each specified software component in the at least one specified software component; Each third node is used to represent the attribute information of each specified hardware in the at least one specified hardware; The first directed edge is used to represent the dependency relationship between the first node and the second node, and the second directed edge is used to represent the dependency relationship between the first node and the third node.

12. The method according to claim 1, characterized in that, In response to the upgrade task, the method of obtaining the attribute information of the deployed components reported by the client includes: In response to the upgrade task, a pre-detection command is issued to the client, so that the client scans the hardware and software environment of the target test device based on the pre-detection command, generates an environment snapshot file, and reports the environment snapshot file to the server; Receive the environment snapshot file reported by the client, and obtain the attribute information of the deployed component based on the environment snapshot file.

13. The method according to any one of claims 1-12, characterized in that, The method further includes: Parse the environment snapshot file to obtain a list of the software components to be upgraded; Identify the differing components in the first component list and the second component list; A differentiated update package carrying a manifest file is generated based on the aforementioned differential components; The differentiated update package is then sent to the client; The difference components include components to be added, components to be deleted, and components to be updated. The manifest file is used to record the operation type, target path, hash value, and execution order of each component in the difference components. The first component list is a list of the software components to be upgraded; The second component list is the component list of the new version of the software.

14. The method according to claim 13, characterized in that, The server includes a pre-defined version repository; The generation of a differentiated update package carrying a manifest file based on the differentiated component includes: Extract the new version of the component to be added from the preset version repository; Based on the installation files of the components to be updated in the first component list and the installation files of the components to be updated in the second component list, the difference files are determined, including files to be added, files to be deleted, and files to be updated. Extract the new version of the file to be added from the preset version repository; If it is determined that the file to be updated supports incremental differential updates, a corresponding differential patch is generated. The differential patch is used to incrementally repair the old version of the file to be updated in order to obtain the new version of the file to be updated. If it is determined that the file to be updated does not support incremental differential updates, then the new version of the file to be updated is extracted from the preset version repository; Based on the information of the new version of the components to be added, the new version of the files to be added, the difference patch, the new version of the files to be updated, the information of the components to be deleted, and / or the information of the files to be deleted, a difference update package carrying a manifest file is generated.

15. A software upgrade method for a testing device, applied to a client side, characterized in that, The method includes: The server receives an upgrade instruction, which is an instruction issued by the server to the client after executing the method described in any one of claims 1-14 and determining that the comprehensive upgrade risk value is less than a preset risk threshold. The upgrade instruction is used to instruct the target test device to upgrade the software component to be upgraded from the current old version to the new version. The target test device is equipped with test execution software, which is used to control the test program set to execute test tasks. In response to the upgrade command, the first application programming interface of the test execution software is invoked to query whether the target test device is currently executing the test task; If it is determined that the target test device is currently executing the test task, and it is determined that the currently running test program set has a dependency relationship with the software component to be upgraded, then the current upgrade mode of the software component to be upgraded is determined to be the cold update mode. If it is determined that the target test device is currently executing the test task, and it is determined that the currently running test program set has no dependency relationship with the software component to be upgraded, then the current upgrade mode of the software component to be upgraded is determined to be hot update mode; In the current upgrade mode, the software component to be upgraded is upgraded from the current old version to the new version to obtain the new version software component.

16. The method according to claim 15, characterized in that, In the current upgrade mode, upgrading the software component to be upgraded from the current old version to the new version includes: If it is determined that the current upgrade mode of the software component to be upgraded is cold update mode, then subscribe to the current test batch completion event; If the current test batch completion event is detected, the second application interface of the test execution software is called to send a task pause request to the test execution software so that the test execution software pauses the test task scheduling. Upgrade the software component to be upgraded from its current old version to a new version; If it is determined that the software component to be upgraded has been successfully upgraded to the new version, then the third application programming interface of the test execution software is invoked to send a task recovery request to the test execution software so that the test execution software can resume test task scheduling.

17. The method according to claim 15, characterized in that, In the current upgrade mode, upgrading the software component to be upgraded from the current old version to the new version includes: If it is determined that the current upgrade mode of the software component to be upgraded is hot update mode, then the component type of the software component to be upgraded is determined. Based on the component type, determine the hot update mechanism of the hot update mode; Based on the hot update mechanism, the software component to be upgraded is upgraded from the current old version to the new version; The component types are: ordinary file type, system service or system daemon type, dynamic link library type, or independent process communication type.

18. The method according to claim 17, characterized in that, The hot update mechanism for determining the hot update mode based on the component type includes: If the component type is determined to be a regular file, then the hot update mechanism is determined to be a file lock detection and waiting mechanism; If the component type is determined to be a system service or a system daemon, then the hot update mechanism is determined to be a graceful service restart mechanism. If the component type is determined to be a dynamic link library, then the hot update mechanism is determined to be a dynamic link library versioning loading mechanism. If the component type is determined to be independent process communication type, then the hot update mechanism is determined to be an inter-process communication seamless switching mechanism.

19. The method according to claim 18, characterized in that, The software component to be upgraded includes old version files, and the new version software component includes new version files; The process of upgrading the software component to be upgraded from the current old version to the new version based on the hot update mechanism includes: If the hot update mechanism is determined to be a file lock detection and waiting mechanism, then determine whether the old version file is locked by other processes; If it is determined that the old version file is locked by another process, then enter a waiting state; In the waiting state, the file lock status of the old version file is polled at preset time intervals; If it is determined that the file lock state of the old version file becomes unlocked within a preset first time period, then the old version file is replaced with the new version file. If it is determined that the file lock state of the old version file has not changed to the unlock state within the preset first time period, then the current upgrade mode of the software component to be upgraded will be adjusted to the cold update mode.

20. The method according to claim 18, characterized in that, The process of upgrading the software component to be upgraded from the current old version to the new version based on the hot update mechanism includes: If the hot update mechanism is determined to be a graceful restart mechanism, a graceful stop signal is sent to the software component to be upgraded. The graceful stop signal is used to instruct the software component to be upgraded to automatically exit operation after completing the existing business request currently being processed. If it is determined that the software component to be upgraded has not automatically exited operation within a preset second time period, a forced termination signal is sent to the software component to be upgraded. The forced termination signal is used to force the software component to be upgraded to exit operation. If it is determined that the software component to be upgraded has automatically exited operation, then the new version of the software component will be used to replace the software component to be upgraded.

21. The method according to claim 18, characterized in that, The process of upgrading the software component to be upgraded from the current old version to the new version based on the hot update mechanism includes: If the hot update mechanism is determined to be a dynamic link library versioning loading mechanism, then if the new version software component is configured with a name carrying a version identifier, the new version software component is copied to the storage directory of the software component to be upgraded, and the software component to be upgraded in the storage directory is retained. Modify the configuration file or registry entry corresponding to the software component to be upgraded, and update the loading path configuration of the software component to be upgraded to point to the new version software component carrying the version identifier; When the host process that depends on the dynamic link library file loads the corresponding software component to be upgraded next time, the new version of the software component will be automatically loaded and run. Monitor the running status of the new version of the software components; If the operating status is confirmed to be stable, the software components to be upgraded that remain in the storage directory are marked as cleanable.

22. The method according to claim 18, characterized in that, The process of upgrading the software component to be upgraded from the current old version to the new version based on the hot update mechanism includes: If the hot update mechanism is determined to be a seamless inter-process communication switching mechanism, then the new version of the software component is copied to the storage directory of the software component to be upgraded; Start the new version service process, bind the new version service process to the same communication identifier as the old version service process, and the operating system of the target test device automatically routes subsequent new communication requests sent to the old version service process to the new version service based on the communication identifier; If it is determined that the old version service process has finished processing the existing access requests and exited the program, then it is determined that the software components to be upgraded in the storage directory can be cleaned up. The new version service process is the business service process corresponding to the new version software component; The old version service process is the business service process corresponding to the software component to be upgraded.

23. The method according to any one of claims 15-22, characterized in that, Upgrading the software component to be upgraded to a new version includes: The update operation of upgrading the software component from the old version to the new version is performed in an atomic transaction manner based on the write-ahead transaction log mechanism.

24. The method according to claim 23, characterized in that, The update operation includes multiple operation steps, and the target operation step is any one of the multiple operation steps. The upgrade operation, which is based on a write-ahead transaction log mechanism and executes the upgrade operation of the software component to be upgraded from the old version to the new version in an atomic transaction manner, includes: Create a transaction log file, write the transaction identifier, transaction start time, and information about the new version of the software component for the update operation into the transaction log file, and mark the transaction status of the update operation as "started". According to the preset operation sequence, each of the multiple operation steps is executed sequentially; During the sequential execution of each of the plurality of operation steps, the operation content of the target operation step and the inverse operation corresponding to the target operation step are first written into the transaction log file, and then the target operation step is executed. If the target operation step is determined to be executed successfully, the transaction status of the target operation step is marked as "completed" in the transaction log file; If it is determined that each of the multiple operation steps was executed successfully, the transaction status of the update operation is marked as "completed" in the transaction log file; If it is determined that the target operation step fails, the transaction status of the target operation step is marked as "rollback" in the transaction log file, and the reverse operation of each completed operation step is executed in reverse order of the preset operation sequence. If it is determined that the reverse operation of each completed operation step has been performed, the transaction status of the update operation in the transaction log file will be marked as "rolled back".

25. The method according to claim 24, characterized in that, The method further includes: If it is determined that each of the multiple operation steps was executed successfully, then the upgrade result is checked, and the upgrade result is either passed or abnormal. If the upgrade result is determined to be abnormal, a rollback mechanism is triggered; Under the rollback mechanism, the transaction log file is read to obtain the reverse operations of all completed operation steps; Perform the reverse operations of each completed operation step in reverse order; If it is determined that the inverse operations of each of the above-described operation steps have been completed, then it is determined whether the current service state has been restored to the state before the upgrade based on the system state snapshot file; If it is determined that the current service status has been restored to the state before the upgrade, then verify whether the software operating system of the target test equipment can work normally; The service status refers to the running status of the service associated with the software component to be upgraded.

26. The method according to claim 25, characterized in that, The method further includes: Creating a system status snapshot file, wherein creating a system status snapshot file includes: Traverse the installation directory of the software component to be upgraded, copy all files in the installation directory to the backup directory with timestamps, and generate file backup data; Export and save the registry entries and configuration files associated with the software components to be upgraded, and generate configuration backup data; Record the current service running status associated with the software component to be upgraded, and generate service status backup data; The index information of the file backup data, the configuration backup data, and the service status backup data is written into the snapshot description file to obtain the system status snapshot file.

27. The method according to claim 21, characterized in that, The method further includes: If a pre-detection instruction is received from the server, the system will respond to the pre-detection instruction by scanning the current hardware and software environment of the target test device to generate an environment snapshot file, and then report the environment snapshot file to the server.

28. A server, characterized in that, The server includes: At least one first processor, and A first memory communicatively connected to the at least one first processor, wherein, The first memory stores instructions executable by the at least one first processor, which, when executed by the at least one first processor, enables the at least one first processor to perform the method according to any one of claims 1-14.

29. A client application, characterized in that, The client includes: At least one second processor, and A second memory communicatively connected to the at least one second processor, wherein, The second memory stores instructions executable by the at least one second processor, which, when executed by the at least one second processor, enables the at least one second processor to perform the method according to any one of claims 15-27.

30. A software upgrade system, characterized in that, The system includes: The server as described in claim 28; and / or The client of claim 29, wherein the server and the client are in a communication connection.

31. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer device to perform the method according to any one of claims 1-27.

Images