Software module management and control method, storage medium and computer program product

Abstract

The invention discloses a software module management and control method, a storage medium and a computer program product, and relates to the technical field of production testing, and the method comprises the steps: obtaining a module verification list corresponding to a testing end from a server end; determining a local check value of each local module at the test end; traversing each preset module in the module verification list, and determining a target local module corresponding to the preset module in each local module; according to a comparison result of a preset verification value of the preset module and a target local verification value of the target local module, judging whether the target local module operates normally or not; according to the method and the device, the local modules at the test end are automatically and sequentially verified through the module verification list stored at the server end, whether the local modules are abnormal compared with the standard preset modules or not is judged, and the modules of the test system software are verified in an automatic mode; the problem that errors are easily caused by subjective reasons in manual operation is avoided, and the management efficiency of the test system software is improved.

Description

Technical Field

[0001] The present application relates to the field of production testing technology, and in particular to a software module management and control method, storage medium, and computer program product. Background Art

[0002] In the field of electronic product manufacturing, test system software is usually composed of a variety of software modules (such as vi, dll, py files) based on different development languages ​​(such as LabVIEW, C++, Python) to achieve automated control of test stations.

[0003] In test system software, version management and consistency assurance for software modules rely primarily on manual operations, such as manually checking module versions at each workstation and manually copying and updating files. However, with the increasing number of test stations on production lines and the increasing complexity of projects, the drawbacks of manual management and control are becoming increasingly apparent. First, manual operations are inefficient and error-prone, making it difficult to ensure module version consistency across multiple projects and workstations, leading to an increased risk of test anomalies. Second, there is a lack of effective recording and tracking mechanisms for module version releases, making version rollbacks difficult and posing a high operational risk.

[0004] Therefore, how to improve the management efficiency of test system software has become an urgent problem to be solved in this field.

[0005] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0006] The main purpose of this application is to provide a software module management and control method, storage medium and computer program product, aiming to solve the technical problem of how to improve the management efficiency of test system software.

[0007] To achieve the above objectives, the present application proposes a software module management and control method, which is applied to a test terminal. The software module management and control method includes:

[0008] Obtaining a module verification list corresponding to the test end from the server end;

[0009] Determining a local checksum value of each local module of the test end;

[0010] Traversing each preset module in the module verification list to determine a target local module corresponding to each preset module in each local module;

[0011] According to a comparison result of the preset check value of the preset module and the target local check value of the target local module, it is determined whether the target local module operates normally.

[0012] In one embodiment, after the step of determining whether the target local module is operating normally, the software module management and control method further includes:

[0013] If the comparison result is that the preset check value is different from the target local check value, determining that the target local check value is different;

[0014] The preset module is downloaded from the server side and deployed locally on the test side.

[0015] In one embodiment, the step of deploying the preset module locally on the test end includes:

[0016] Obtaining the operating environment dependency information of the preset module from the server side;

[0017] Obtaining local operating environment information of the test terminal;

[0018] If the local operating environment information does not completely include the operating environment dependency information, determining the target operating environment information that is missing from the local operating environment information compared to the operating environment dependency information;

[0019] The target operating environment information is configured from the server side, and the preset module is updated locally on the test side.

[0020] In one embodiment, after the step of downloading the preset module from the server, the software module management method further includes:

[0021] When download interruption is detected, the current download breakpoint position is recorded;

[0022] When download resumption is detected, sending a download request to the server from the breakpoint position to continue downloading the preset module;

[0023] After the download of the preset module is completed, a download verification value of the preset module is calculated. When the download verification value is the same as the preset verification value, it is determined that the deployment of the preset module is completed.

[0024] In one embodiment, after the step of deploying the preset module locally on the test end, the method further includes:

[0025] Running the preset module and monitoring the running result of the preset module;

[0026] If the operation result is abnormal, the preset module is deleted and the target local module is restored;

[0027] Send reminder information through the preset notification method.

[0028] In one embodiment, after the step of determining whether the target local module is operating normally, the software module management and control method further includes:

[0029] The judgment result is stored as a log file in a preset format according to the preset log template;

[0030] Upload the log file to the server.

[0031] To achieve the above objectives, the present application further proposes a software module management and control method, which is applied to a server side; the software module management and control method comprises:

[0032] Receiving an uploaded module file, wherein the module file includes a plurality of preset modules and a check value of each of the preset modules;

[0033] Bind each of the preset modules to a corresponding test terminal, and generate a corresponding module verification list for each test terminal;

[0034] When receiving the verification request sent by the test end, the module verification list corresponding to the test end is sent to the test end, so that the test end can verify whether the local module is running normally.

[0035] In one embodiment, the software module management method further includes:

[0036] Upon receiving the log file uploaded by the test terminal, traverse each of the test terminals and calculate the number of common modules that the test terminal has in common with other test terminals;

[0037] The modularization rate of the test end is obtained by dividing the number of common modules by the total number of modules of the test end.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a test end and a server end, which include: a memory, a processor, and a computer program stored on the memory and runnable on the processor, and the computer program is configured to implement the steps of the software module management method described above.

[0039] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the software module management method described above are implemented.

[0040] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the software module management and control method as described above.

[0041] The present application provides a software module management and control method. The present application first receives the uploaded module file on the server side, and then generates a module verification list corresponding to each test side. When the test is started on the test side, the module verification list is obtained from the server side, and then the local verification value of each local module of the test side is calculated. Then, the module verification list is traversed, and the target local module corresponding to each preset module in the module verification list is determined in turn. The preset verification value of the preset module is compared with the target local verification value of the target local module. According to the comparison result, it can be judged whether the target local module is running normally. After completing the traversal of the module verification list, all local modules can be verified.

[0042] In summary, this application automatically verifies the local modules of the test end in sequence through the module verification list stored on the server side, determines whether there are any abnormalities in the local modules compared with the standard preset modules, and verifies the modules of the test system software in an automated manner, thereby avoiding the problem that manual operations are prone to errors due to subjective reasons, and improving the management efficiency of the test system software. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0044] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0045] Figure 1 A flowchart of the first embodiment of the software module control method of this application is provided;

[0046] Figure 2 A flowchart of the second embodiment of the software module control method of this application is provided;

[0047] Figure 3 A flowchart of the third embodiment of the software module control method of this application is provided;

[0048] Figure 4 A schematic diagram of the interaction process provided for an embodiment of the software module control method of this application;

[0049] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the software module control method in the embodiment of the present application.

[0050] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0051] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0052] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0053] The main solution of the embodiment of the present application is: obtain the module verification list corresponding to the test end from the server end; determine the local verification value of each local module local to the test end; traverse each preset module in the module verification list to determine the target local module corresponding to the preset module in each local module; and judge whether the target local module is operating normally based on the comparison result of the preset verification value of the preset module and the target local verification value of the target local module.

[0054] In the field of electronic product manufacturing, test system software is usually composed of a variety of software modules (such as vi, dll, py files) based on different development languages ​​(such as LabVIEW, C++, Python) to achieve automated control of test stations.

[0055] In test system software, version management and consistency assurance for software modules rely primarily on manual operations, such as manually checking module versions at each workstation and manually copying and updating files. However, with the increasing number of test stations on production lines and the increasing complexity of projects, the drawbacks of manual management and control are becoming increasingly apparent. First, manual operations are inefficient and error-prone, making it difficult to ensure module version consistency across multiple projects and workstations, leading to an increased risk of test anomalies. Second, there is a lack of effective recording and tracking mechanisms for module version releases, making version rollbacks difficult and posing a high operational risk.

[0056] Therefore, how to improve the management efficiency of test system software has become an urgent problem to be solved in this field.

[0057] In response to the above problems, the present application provides a software module management method. The present application first receives the uploaded module file on the server side, and then generates a module verification list corresponding to each test end. When the test is started on the test end, the module verification list is obtained from the server side, and then the local verification value of each local module of the test end is calculated. Then, the module verification list is traversed, and the target local module corresponding to each preset module in the module verification list is determined in turn. The preset verification value of the preset module is compared with the target local verification value of the target local module. According to the comparison result, it can be judged whether the target local module is running normally. After completing the traversal of the module verification list, all local modules can be verified.

[0058] In summary, this application automatically verifies the local modules of the test end in sequence through the module verification list stored on the server side, determines whether there are any abnormalities in the local modules compared with the standard preset modules, and verifies the modules of the test system software in an automated manner, thereby avoiding the problem that manual operations are prone to errors due to subjective reasons, and improving the management efficiency of the test system software.

[0059] Based on this, the embodiment of the present application provides a software module management method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the software module control method of this application.

[0060] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device capable of implementing the above functions, a test station, etc. The following uses the test end as an example to illustrate this embodiment and the following embodiments.

[0061] In this embodiment, the software module management and control method includes steps S10 to S40:

[0062] Step S10, obtaining a module verification list corresponding to the test end from the server end;

[0063] In this embodiment, before the test station executes the test task, it will establish a communication connection with the server side. The server side pre-stores the module verification list corresponding to different test ends. The list records in detail the identification information of each preset module that the corresponding test end should have (such as module name, platform category, file relative path, version number, modifier, etc.) and the corresponding preset verification value. The test station sends a specific request instruction to the server side to request to obtain the module verification list corresponding to itself. After receiving the request, the server side retrieves the corresponding module verification list from the database based on the identification information of the test station and sends it to the test station. After receiving the list, the test station stores it in the local temporary storage area for subsequent verification operations.

[0064] The module checklist records the checksum values and other information of the preset modules, providing an effective recording and tracking mechanism for module version releases. When a module anomaly is found, the version information of the problem module can be quickly located according to the checklist, facilitating version rollback operations, reducing operational risks, and improving the convenience and security of system maintenance.

[0065] Step S20, determining the local checksum of each local module of the test end;

[0066] In this embodiment, after receiving the module verification list, the test station traverses all locally stored software modules and uses a specific verification algorithm to calculate the local verification value of each local module. For example, a hash algorithm (such as MD5, SHA-1, etc.) can be used to generate a unique hash value as the local verification value of the module based on the binary data content of the module file.

[0067] During the calculation process, the test station reads the complete data of each local module in turn according to the preset module reading rules, and provides it as input to the hash algorithm function. After the hash algorithm function processes the input data, it outputs a fixed-length string as the local verification value of the local module. The test station records the calculated local verification values of each local module and establishes an association with the corresponding local module for subsequent comparison operations.

[0068] Step S30, traversing each preset module in the module verification list to determine a target local module corresponding to each local module;

[0069] In this embodiment, after obtaining the verification value of each local module, the test station begins to traverse each preset module in the module verification list. For each preset module, the test station performs a matching search in the locally stored module set based on the identification information of the preset module (such as module name, version number, etc.). Specifically, the test station will traverse all local modules according to the preset search strategy (such as alphabetical order of module name, ascending or descending order of version number, etc.), and compare the identification information of the local module with the identification information of the preset module one by one. When a local module whose identification information matches the preset module is found, it is determined that the local module is the target local module corresponding to the current preset module. If no matching module is found after traversing all local modules, the information that there is no corresponding module for the preset module locally is recorded so that the tester can perform exception handling.

[0070] Step S40 , judging whether the target local module operates normally based on a comparison result of the preset check value of the preset module and the target local check value of the target local module.

[0071] In this embodiment, after determining the target local module corresponding to the preset module, the test station obtains the preset verification value corresponding to the current preset module from the module verification list, and at the same time obtains the target local verification value of the corresponding target local module from the recorded local verification value information. Then, the preset verification value and the target local verification value are accurately compared. If the two are completely consistent, it indicates that the target local module and the preset module defined by the server are exactly the same in content, that is, the target local module is in normal operation and no abnormal changes have occurred; if the two are inconsistent, it means that the target local module may have the following problems: the module file is damaged during transmission, the module is accidentally modified or there is malicious tampering, etc. At this time, it can be determined that the target local module is operating abnormally.

[0072] The test station performs the aforementioned comparison and judgment operations for each target local module until it completes the verification of all target local modules corresponding to the preset modules in the module verification list. Furthermore, a detailed verification report is generated based on the verification results of all target local modules. The report includes the verification status of each module (normal or abnormal) and relevant information about the abnormal module (such as module name, version number, and abnormality type).

[0073] In this embodiment, the present application implements the verification of software modules in an automated manner, avoiding manual operation, greatly shortening the time required for module verification, and significantly improving the management efficiency of the test system software. It is particularly suitable for scenarios with a large number of production line test stations and high project complexity. In addition, based on the module verification list stored on the server side, the local modules on the test side are uniformly verified, which can effectively ensure the consistency of module versions between multiple projects and multiple stations, reduce the risk of test anomalies caused by inconsistent module versions, and ensure the accuracy and reliability of test results.

[0074] After the above step S40, the method may further include steps S50 to S60:

[0075] Step S50, storing the judgment result as a log file in a preset format according to a preset log template;

[0076] In this embodiment, after completing the judgment of the preset module operation result, the test end will call the preset log template to format and store the judgment result. The test end will fill the judgment result and related information into the corresponding field according to the log template, generate a complete log record, and then write the log record into the log file according to the preset format.

[0077] Step S60: Upload the log file to the server.

[0078] In this embodiment, after a log file is generated, the test client triggers an upload operation based on a preset upload policy. The upload policy can be based on various methods, such as time triggering (e.g., uploading once every hour), event triggering (e.g., uploading when the log file size reaches a certain threshold), or manual triggering (e.g., the user initiates an upload request through a specific operation interface). For example, the upload operation can be automatically triggered when the log file size exceeds 10MB to avoid inefficient transmission or storage difficulties caused by a single log file being too large.

[0079] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 2 , Figure 2 This is a flow chart of the second embodiment of the software module control method of this application.

[0080] After the above step S40, the method may further include steps A10 to A20:

[0081] Step A10: If the comparison result is that the preset check value is different from the target local check value, then determining that the target local check value is different;

[0082] In this embodiment, after completing the comparison between the preset check value and the target local check value, the comparison result is judged. When a difference is found between the preset check value and the target local check value, it is determined that the target local module currently being checked is in an abnormal state. This is because the different check values mean that the content of the target local module is inconsistent with the preset module content defined on the server side. There may be various problems such as module file damage, accidental modification, malicious tampering, or version mismatch. The test station immediately records the abnormal judgment result, including the name of the abnormal module, version number, specific information of the check value difference, etc., and stores this information in the local log file. At the same time, an abnormal notification is sent to the relevant monitoring system or management personnel so that the abnormal situation can be known and handled in time.

[0083] Step A20: Download the preset module from the server and deploy the preset module locally on the test end.

[0084] In this embodiment, after determining that the target local module is abnormal, the module update process is automatically initiated. First, the test end sends a module download request to the server based on the identification information of the abnormal module (such as the module name and version number). After receiving the request, the server retrieves the corresponding preset module file from its own repository based on the module identification information carried in the request and sends it to the test end. After receiving the preset module file, the test end first performs an integrity check on the downloaded file, for example, recalculates the checksum of the downloaded file and compares it with the preset checksum recorded by the server to ensure that the downloaded file is not damaged during transmission. If the integrity check passes, the test end stops the operation of the current abnormal module and backs up the original abnormal module file to prevent the need for a subsequent rollback operation. Then, the test end deploys the downloaded preset module file to the locally designated software module storage directory and updates the corresponding module configuration information to ensure that the test end can correctly identify and load the new module. After deployment is complete, the test end restarts the module and verifies the newly deployed module according to the above verification process to verify whether the module has resumed normal operation.

[0085] Through the above steps, this application automates the process of determining, downloading and deploying module anomalies, reduces the subjective errors and uncertainties caused by manual operations, reduces the dependence on the technical level of maintenance personnel, improves the standardization and normalization of maintenance work, and also facilitates the monitoring and management of the entire maintenance process. When an abnormality is detected in the target local module, the correct preset module can be automatically downloaded from the server and deployed locally without manual intervention, which greatly shortens the repair time of the module anomaly, reduces the test interruption time caused by module anomaly, and improves the overall operation efficiency of the production line. Moreover, by timely updating the abnormal module, it ensures that the software module used by the test end is always consistent with the standards defined by the server, effectively avoiding problems such as inaccurate test results and system crashes caused by module anomalies, enhancing the stability and reliability of the test system, and ensuring product quality and production progress.

[0086] Furthermore, in a feasible implementation manner, the above-mentioned step A20 may include steps A21 to A24:

[0087] Step A21, obtaining the operating environment dependency information of the preset module from the server;

[0088] In this embodiment, when it is determined that the target local module is abnormal and the preset module is to be downloaded from the server for updating, the test end first sends a request to the server to obtain the preset module operating environment dependency information. After receiving the request, the server retrieves the operating environment dependency information associated with the preset module from the data storage area of the preset module. These operating environment dependency information generally include but are not limited to operating system version requirements (such as a specific version of Windows, Linux distribution, etc.), runtime library dependencies (such as .NET Framework version, Visual C++ Redistributable version, etc.), hardware configuration requirements (such as processor model, memory capacity, storage space, etc.), and dependencies on other software tools or middleware (such as database management system version, message queue middleware version, etc.). The server organizes the retrieved operating environment dependency information and sends it to the test end, which receives and stores it in the local temporary storage area.

[0089] Step A22: obtaining local operating environment information of the test terminal;

[0090] In this embodiment, the test end starts a local operating environment information collection program, which comprehensively collects the current operating environment information of the test end through various methods such as system calls, querying the system registry, and reading configuration files. Specifically, for the operating system version, the name, version number, internal version number and other detailed information of the operating system are obtained by calling the system API; for runtime library dependencies, the locally installed runtime library and its version information are checked, which can be achieved by querying the system installed software list, checking the file version under a specific directory, etc.; for hardware configuration, the processor model, number of cores, main frequency, memory capacity, disk partition and remaining space and other information are obtained by calling the hardware detection interface; for dependencies on other software tools or middleware, check whether the relevant software and its version information are installed locally, for example, by querying the service list, checking the program installation directory, etc. The collected local operating environment information will be organized into a structured data format and stored in the local memory for subsequent comparison with the operating environment dependency information of the preset module.

[0091] Step A23: if the local operating environment information does not completely include the operating environment dependency information, determining the target operating environment information that is missing from the local operating environment information compared to the operating environment dependency information;

[0092] In this embodiment, the test end compares the local operating environment information obtained with the preset module operating environment dependency information obtained from the server end item by item. The comparison process adopts an accurate matching method to ensure that each dependency requirement can find a corresponding satisfied item in the local operating environment. If it is found during the comparison process that the local operating environment information is missing one or more of the contents required by the operating environment dependency information, these missing parts are determined as the target operating environment information.

[0093] For example, if the preset module requires running on Windows 10 or above, and the local operating environment information shows that the current operating system is Windows 7, then the operating system version is the target operating environment information; if the preset module depends on .NET Framework 4.8, and only .NET Framework 4.5 is installed locally, then .NET Framework 4.8 is the missing target operating environment information. The test end will record all determined target operating environment information, including the type of target operating environment information (such as operating system, runtime library, etc.), specific requirements, and other information, so as to facilitate subsequent targeted environment configuration.

[0094] Step A24: configure the target operating environment information from the server side, and update the preset module to the local test side.

[0095] In this embodiment, the test end sends a configuration request to the server end based on the determined target operating environment information. After receiving the request, the server end obtains the corresponding environment configuration resources from its own resource library based on the type and specific requirements of the target operating environment information. For example, if the target operating environment information is a specific operating system version, the server end may provide the installation image file or upgrade patch of the operating system; if it is a runtime library dependency, the server end provides the corresponding runtime library installation package; if it is other software tools or middleware, the server end provides the corresponding software installation program. The server end sends these environment configuration resources to the test end. After receiving the resources, the test end performs the environment configuration according to the preset configuration process. Environment configuration. During the configuration process, the test end will perform corresponding installation or upgrade operations according to the type of resources, such as running the installation program, applying patch files, etc., and monitor the configuration progress and status in real time during the configuration process, and record log information during the configuration process. When the target operating environment information is configured, the test end obtains the local operating environment information again for verification to ensure that all target operating environment information has been successfully configured. After the verification is passed, the test end downloads the preset module file from the server and deploys it to the local specified software module storage directory, updates the corresponding module configuration information, and completes the update operation of the preset module. After the update is completed, the updated module is verified to ensure that it can operate normally.

[0096] By comprehensively checking and configuring runtime environment dependencies before updating pre-set modules, we ensure that the local runtime environment of the test end meets the runtime requirements of the pre-set modules. This effectively avoids problems such as module failure and functional anomalies caused by incompatible runtime environments, improving the success rate and stability of module deployment. The test end can automatically identify and handle runtime environment differences, adapt to different test end environments, and enhance the compatibility of the test end. At the same time, the runtime environment configuration is automatically completed during the module update process, facilitating subsequent maintenance and management of the test end. When runtime environment issues arise, they can be quickly located and resolved, improving the maintainability of the test end.

[0097] Furthermore, after the step of downloading the preset module from the server in step A20, the software module management and control method further includes steps B10 to B30:

[0098] Step B10, when download interruption is detected, recording the current download breakpoint position;

[0099] In this embodiment, during the process of downloading the preset module from the server, the test end will continuously monitor the download status. When a download interruption event is detected, such as a sudden disconnection of the network connection, a server response timeout, insufficient local system resources causing the download process to be forced to terminate, etc., the breakpoint recording mechanism will be immediately started. Specifically, the system will obtain the file size information of the currently downloaded module, which is accurate to the byte level, and record it as the download breakpoint position in a local specific log file or configuration file. At the same time, the test end will also record the time of the download interruption, the reason for the interruption, and other related information for subsequent fault analysis and troubleshooting. The operation of recording the breakpoint position can ensure that when the download is resumed, the system knows clearly where to continue downloading, avoids repeated downloading of the completed part, and improves download efficiency and resource utilization.

[0100] Step B20: When download resumption is detected, sending a download request to the server from the breakpoint to continue downloading the preset module;

[0101] In this embodiment, the test end will periodically or in real time detect whether the download environment has returned to normal, such as whether the network connection has been re-established, whether the server has resumed normal response, whether the local system resources are sufficient, etc. When the download is detected to be resumed, the test end reads the download breakpoint position information from the previously recorded log file or configuration file, and then generates a specific download request based on the breakpoint position. The request contains a breakpoint position identifier and the module's unique identification information (such as module name, version number, etc.), which is used to inform the server to continue transmitting the preset module file from the breakpoint position. After receiving the request, the server parses the breakpoint position information in the request, locates the corresponding starting position from the preset module file stored on the server, and sends the data stream starting from this position to the test end. After receiving the data stream, the test end appends it to the locally downloaded module file and continues to complete the download process of the preset module. During the continued download process, the system will continue to monitor the download status to prevent the download from being interrupted again.

[0102] Step B30: After the download of the preset module is completed, the download verification value of the preset module is calculated. When the download verification value is the same as the preset verification value, it is determined that the deployment of the preset module is completed.

[0103] In this embodiment, when the preset module is downloaded, the test end immediately starts the verification process. The test end uses the same verification algorithm (such as MD5, SHA-1, etc.) as the preset verification value generated by the server end to calculate the complete preset module file downloaded locally and generate a download verification value. During the calculation process, the test end reads the data of the module file byte by byte according to the requirements of the verification algorithm and provides it as input to the verification algorithm function. After processing the input data, the verification algorithm function outputs a fixed-length string as the download verification value. Then, the test end accurately compares the calculated download verification value with the preset verification value previously obtained from the server end. If the two are exactly the same, it is said that the download verification value is correct. The downloaded preset module file has not been damaged or tampered with during the transmission process, and the file content is consistent with the preset module defined on the server side. At this time, the test end determines that the preset module deployment is complete, and the test end will update the local module configuration information, mark the newly downloaded preset module as available, and clean up the temporary files and log records generated during the download process (except for the necessary deployment completion records). If the downloaded checksum is different from the preset checksum, the test end will record the checksum failure information, including the time of the checksum failure, module name, checksum difference details, etc., and trigger the exception handling mechanism, such as restarting the download process, sending an alarm message to the administrator, etc., to ensure that the correct preset module file can be obtained in the end.

[0104] By recording the download breakpoint location and resuming the download from the breakpoint after the download is resumed, repeated downloads caused by network fluctuations, server failures, etc. are avoided, which greatly improves the download efficiency, reduces unnecessary network traffic consumption and download time, and enhances the reliability of the download process, ensuring that the module download can be successfully completed in various complex network environments. After the download is completed, by calculating the download checksum and comparing it with the preset checksum, it can accurately determine whether the downloaded preset module file is complete and has not been tampered with, effectively preventing problem modules caused by file corruption or malicious attacks from being deployed to the test end, ensuring the stability and security of the test system software. The entire download and verification process implements an automated fault-tolerant processing mechanism. When abnormal situations such as download interruption or verification failure occur, the test end can automatically record relevant information and take corresponding recovery measures without manual intervention, improving the fault tolerance and automation level of the test end and reducing system maintenance costs.

[0105] Furthermore, after the above step A20, the method may further include steps A30 to A50:

[0106] Step A30, running the preset module and monitoring the running result of the preset module;

[0107] In this embodiment, after completing the deployment of the preset module locally on the test end, the test end automatically starts the preset module. During the startup process, the test end will allocate necessary system resources (such as memory, process / thread resources, etc.) to the module according to the preset module initialization process, load the configuration files and dependencies required by the module, and ensure that the module can smoothly enter the running state.

[0108] Step A40: If the operation result is abnormal, the preset module is deleted and the target local module is restored;

[0109] In this embodiment, when the monitoring results of the test end determine that there is an abnormality in the operation of the preset module, the module rollback operation is immediately initiated. First, the test end will stop the running preset module, release the system resources occupied by it, and ensure that the module completely exits the running state. Then, the test end obtains the previously backed up target local module file from the local backup storage area. Before restoring the target local module, the test end will perform an integrity check on the backup file, such as recalculating the check value of the backup file and comparing it with the check value recorded during the backup to ensure that the backup file has not been damaged or tampered with.

[0110] If the backup file verification passes, the test end will delete the local abnormal preset module file, and copy the backed up target local module file to the original storage location of the preset module, and update the corresponding module configuration information, including the module startup path, dependencies, etc., so that the system can correctly identify and load the restored target local module. After the recovery operation is completed, the test end will start the target local module again and monitor its operation to ensure that the target local module can operate normally to ensure the normal function of the test system.

[0111] Step A50: Send a reminder message via a preset notification method.

[0112] In this embodiment, after completing exception handling for the preset module (whether it is successfully deployed and running normally, or rolled back to the target local module due to an exception), the test end will send a prompt message to relevant personnel according to the preset notification rules. The notification method can be flexibly configured according to actual needs. Common notification methods include the following:

[0113] Email notification: The test end automatically generates an email containing detailed processing results. The email content may include module name, version number, operation type (such as module update, rollback), operation time, operation result (success or failure), exception details (if the operation fails), etc. Then, the email is sent to a pre-configured list of recipient email addresses, such as system administrators, developers, testers, etc., so that relevant personnel can understand the module processing status in a timely manner.

[0114] Instant messaging tool notifications: By integrating the API interfaces of commonly used instant messaging tools in enterprises (such as DingTalk, WeChat for Business, Lark, etc.), the test end will send prompt information in the form of messages to designated groups or personal accounts. The message content is concise and clear, highlighting key information such as module name and operation results, making it convenient for relevant personnel to quickly view and respond on mobile devices.

[0115] SMS notification: For situations that require high real-time performance or timely processing, the test end can also send SMS reminders to the mobile phone numbers of relevant personnel through the SMS platform. The SMS content usually only contains the most critical information, such as module name and operation results, to ensure that the recipient can quickly obtain important information.

[0116] Based on the first embodiment and / or the second embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the first embodiment and / or the second embodiment can be referred to the above introduction and will not be described in detail later. Figure 3 , Figure 3 This is a flowchart of the third embodiment of the software module management and control method of this application.

[0117] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or server capable of implementing the above functions. The following describes this embodiment and the following embodiments using the server as an example.

[0118] In this embodiment, the software module management and control method is applied to the server side; the software module management and control method includes steps C10 to C30:

[0119] Step C10: receiving an uploaded module file, wherein the module file includes a plurality of preset modules and a checksum value of each preset module;

[0120] In this embodiment, the server side is equipped with a dedicated file upload interface that supports a variety of common file upload protocols, such as HTTP POST upload, FTP upload, etc., to meet the needs of different development environments or automated deployment tools. When the client (usually a development machine operated by a developer or an automated build system) initiates a module file upload request, the server-side interface will listen to and receive the uploaded data stream.

[0121] Step C20: Bind each of the preset modules to a corresponding test terminal, and generate a corresponding module verification list for each test terminal;

[0122] In this embodiment, developers or operation and maintenance personnel can manually configure the binding relationship between preset modules and test terminals through the server or batch configure them through automated scripts. For example, for a specific business module, it is bound to multiple test terminals in a specific test environment according to the test requirements. During the configuration process, the module information that needs to be deployed on each test terminal is recorded in detail, including the module name, version number, etc. For each test terminal, the server generates a corresponding module verification list based on the module information bound to it. The module verification list is a data structure (such as a list in JSON format, a database table, etc.), which contains detailed information on all preset modules that need to be deployed on the test terminal. The information items of each module generally include the module name, version number, preset verification value, etc.

[0123] Step C30: upon receiving the verification request sent by the test end, sending the module verification list corresponding to the test end to the test end, so that the test end can verify whether the local module is operating normally.

[0124] In this embodiment, the server side continuously monitors network requests from each test side, and when the test side starts, performs self-check tasks regularly, or detects that a module may be abnormal, it sends a verification request to the server side. The request contains the tester's unique identification information (such as the tester's ID, IP address, etc.) so that the server can accurately identify the request source and locate the corresponding module verification list. After receiving the verification request, the server searches the database for the module verification list corresponding to the tester based on the tester's identification information in the request. After retrieving the corresponding module verification list, the server encapsulates it into a specific data format (such as a JSON response message) and sends the module verification list back to the tester via the network. After receiving the module verification list sent by the server, the tester verifies the locally deployed modules according to the preset verification rules. The tester first obtains the file information of each local module, calculates its checksum, and then compares the calculated checksum with the corresponding preset checksum in the module verification list. If the checksums of all modules are consistent, the local module is considered to be running normally. If there is any inconsistency, the tester further determines which modules have problems based on the module information in the module verification list and takes appropriate measures, such as re-downloading the module or triggering an alarm notification. The module verification list sent by the server provides an accurate reference for the tester's local module verification, ensuring that the tester can promptly detect and handle module anomalies.

[0125] The server generates and maintains a corresponding module verification list for each test terminal, ensuring that the verification basis used by the test terminal when performing local module verification is accurate. Different test terminals obtain the corresponding verification list based on the module information bound to them, ensuring that the verification process of each test terminal is independent of each other and the results are consistent. This helps to promptly discover module operation abnormalities caused by module damage, version mismatch, etc., and improves the stability and reliability of the test system.

[0126] Based on the first to third embodiments of the present application, in the fourth embodiment of the present application, the same or similar contents as those of the first to third embodiments can be referred to above and will not be described in detail. On this basis, the software module management method further includes steps D10 to D20:

[0127] Step D10: upon receiving the log file uploaded by the test terminal, traverse each of the test terminals and calculate the number of common modules that the test terminal has in common with other test terminals;

[0128] In this embodiment, the server side continuously monitors the log file upload requests from each test side. After receiving the log file uploaded by the test side, the log file is first format checked to ensure that the log file complies with the preset format specifications (such as specific field delimiters, whether required fields exist, etc.). If the format check fails, an error message is returned to the test side, requiring it to re-upload a log file that complies with the specifications. Key information is extracted from the log file that has passed the check, focusing on the module information recorded therein, including module name, version number, etc. For the current test side and each other test side, the module sets they deploy are compared. In specific implementation, the intersection operation of the sets can be used to quickly find the same modules for the two test sides, and the number of modules in the intersection is counted. This number is the number of modules that the current test side has in common with other test sides currently traversed (the number of common modules).

[0129] Step D20: Divide the number of common modules by the total number of modules of the test end to obtain the modularization rate of the test end.

[0130] In this embodiment, information on all modules deployed by the current test terminal is extracted from the log file uploaded by the current test terminal, and the number of these modules is counted, which is the total number of modules of the current test terminal. Alternatively, the server side has stored the module deployment information of each test terminal when previously recording the binding relationship between the module and the test terminal. At this time, the total number of modules of the current test terminal can be directly queried from the database. The total number of common modules of the modules that are the same as those of all other test terminals is divided by the total number of modules of the current test terminal. The result is the modularization rate of the current test terminal.

[0131] By calculating the modularity rate of a test terminal, we can intuitively and quantitatively reflect the degree of similarity between this test terminal and other test terminals in terms of module deployment. The higher the modularity rate, the more common modules the test terminal uses and the higher the degree of module reuse. This helps evaluate the modular design level of the software system and provides data support for subsequent architecture optimization.

[0132] As an example, in the entire interaction process, please refer to Figure 4 , Figure 4 This is the interactive flow chart involved in the embodiment of the present application. First, the server side establishes a module library based on the received module information, and then the server formulates module management rules to correspond each preset module to the test side. When the test side is testing, it verifies the correctness of each test station module by comparing the difference in verification value between the local module and the preset module. For the verification process, the test side synchronously generates a module verification log and uploads it to the server side. Finally, the modularization rate of each test station is counted on the server side to provide an automated module verification process for the test system program.

[0133] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the software module control method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0134] The present application provides a test end and a server end, which include: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the software module management method in the above-mentioned embodiment one.

[0135] Reference below Figure 5 , which shows a schematic diagram of the structure of a test terminal and a server terminal suitable for implementing the embodiments of the present application. The test terminal and server terminal in the embodiments of the present application may include, but are not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), etc., as well as fixed terminals such as digital TVs and desktop computers. Figure 5 The test end and server end shown are merely examples and should not impose any limitations on the functions and scope of use of the embodiments of the present application.

[0136] like Figure 5As shown, the test end and the server end may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory 1002 or programs loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the test end and the server end. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the test end and the server end to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows the test end and the server end with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0137] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0138] The test terminal and server provided in this application, employing the software module management and control methods of the aforementioned embodiments, can address the technical problem of improving the management efficiency of test system software. Compared to the prior art, the test terminal and server provided in this application achieve the same beneficial effects as the software module management and control methods of the aforementioned embodiments. Other technical features of the test terminal and server are the same as those disclosed in the aforementioned embodiments and are not further elaborated here.

[0139] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0140] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0141] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the software module management and control method in the above-mentioned embodiment.

[0142] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0143] The computer-readable storage medium may be included in the test end and the server end; or may exist independently without being assembled into the test end and the server end.

[0144] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the test end, the test end: obtains the module verification list corresponding to the test end from the server end; determines the local verification value of each local module local to the test end; traverses each preset module in the module verification list, and determines the target local module corresponding to the preset module in each local module; and judges whether the target local module is operating normally based on the comparison result of the preset verification value of the preset module and the target local verification value of the target local module.

[0145] When the above one or more programs are executed by the server side, the server side: receives the uploaded module file, wherein the module file includes multiple preset modules and the verification value of each preset module; binds each preset module to the corresponding test end, and generates a corresponding module verification list for each test end; when receiving the verification request sent by the test end, sends the module verification list corresponding to the test end to the test end, so that the test end can verify whether the local module is operating normally.

[0146] The computer program code for performing the operations of the present application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an Internet service provider to connect through the Internet).

[0147] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0148] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0149] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned software module management and control method, thereby solving the technical problem of improving the management efficiency of test system software. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the software module management and control method provided in the aforementioned embodiment, and are not further elaborated here.

[0150] The present application also provides a computer program product, including a computer program, which implements the steps of the software module management method as described above when executed by a processor.

[0151] The computer program product provided in this application can solve the technical problem of how to improve the management efficiency of test system software. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the software module management and control method provided in the above embodiment, and will not be repeated here.

[0152] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A software module management and control method, characterized in that: The software module management and control method is applied to the test end; the software module management and control method includes: Obtaining a module verification list corresponding to the test end from the server end; Determining a local checksum value of each local module of the test end; Traversing each preset module in the module verification list to determine a target local module corresponding to each preset module in the local modules; According to a comparison result of the preset check value of the preset module and the target local check value of the target local module, it is determined whether the target local module operates normally.

2. The software module management and control method according to claim 1, wherein: After the step of determining whether the target local module is operating normally, the software module management and control method further includes: If the comparison result is that the preset check value is different from the target local check value, determining that the target local check value is different; The preset module is downloaded from the server side and deployed locally on the test side.

3. The software module management and control method according to claim 2, wherein: The step of deploying the preset module locally to the test end includes: Obtaining the operating environment dependency information of the preset module from the server side; Obtaining local operating environment information of the test terminal; If the local operating environment information does not completely include the operating environment dependency information, determining the target operating environment information that is missing from the local operating environment information compared to the operating environment dependency information; The target operating environment information is configured from the server side, and the preset module is updated locally on the test side.

4. The software module management and control method according to claim 2, wherein: After the step of downloading the preset module from the server, the software module management and control method further includes: When download interruption is detected, the current download breakpoint position is recorded; When download resumption is detected, sending a download request to the server from the breakpoint position to continue downloading the preset module; After the download of the preset module is completed, a download verification value of the preset module is calculated. When the download verification value is the same as the preset verification value, it is determined that the deployment of the preset module is completed.

5. The software module management and control method according to claim 2, wherein: After the step of deploying the preset module locally on the test end, the method further includes: Running the preset module and monitoring the running result of the preset module; If the operation result is abnormal, the preset module is deleted and the target local module is restored; Send reminder information through the preset notification method.

6. The software module management and control method according to claim 1, wherein: After the step of determining whether the target local module is operating normally, the software module management and control method further includes: The judgment result is stored as a log file in a preset format according to the preset log template; Upload the log file to the server.

7. A software module management and control method, characterized in that: The software module management and control method is applied to the server side; The software module management and control method includes: Receiving an uploaded module file, wherein the module file includes a plurality of preset modules and a check value of each of the preset modules; Bind each of the preset modules to a corresponding test terminal, and generate a corresponding module verification list for each test terminal; When receiving the verification request sent by the test end, the module verification list corresponding to the test end is sent to the test end, so that the test end can verify whether the local module is running normally.

8. The software module management and control method according to claim 7, wherein: The software module management and control method further includes: Upon receiving the log file uploaded by the test terminal, traverse each of the test terminals and calculate the number of common modules that the test terminal has in common with other test terminals; The modularization rate of the test end is obtained by dividing the number of common modules by the total number of modules of the test end.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the software module management and control method according to any one of claims 1 to 6 or 7 to 8 are implemented.

10. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the software module management and control method according to any one of claims 1 to 6 or 7 to 8 are implemented.

Images