A daemon-based distributed cluster testing system and method

Abstract

The application relates to a daemon-based distributed cluster test system and method, wherein after a tester is started, a daemon module establishes a communication connection with a server; the daemon module sends heartbeat information to the server at a preset period; the server receives the heartbeat information, updates a device state table, and displays the states of all testers in real time on a monitoring interface; the server sends a test flow starting instruction to multiple target testers, and a client test module executes a corresponding test flow after receiving the instruction; the client test module controls the power supply state of a product to be tested according to the test flow, sends a test instruction, and collects test data; the client test module stores the test data locally and uploads the test data to the server for summarization; when it is necessary to upgrade the client test module, the server pushes an update package to the daemon module to execute software updating of the client test module. The needs of centralized monitoring of multiple testers, remote control of a test flow and batch updating of test software are met.

Description

Technical Field

[0001] This invention belongs to the field of automated testing technology, and relates to a distributed cluster testing system and method based on daemon processes. Background Technology

[0002] With the rapid development of the electronics manufacturing industry, the requirements for testing efficiency and test management in the product testing process are becoming increasingly stringent. In large-scale production environments, it is typically necessary to deploy multiple testing instruments simultaneously to test products in order to meet production capacity demands.

[0003] Existing cluster testing solutions have the following technical problems: 1. Difficulty in monitoring equipment status: In traditional testing systems, each testing instrument is independent of the others. Managers cannot obtain the online and working status of each testing instrument in real time and need to check each device individually, resulting in low management efficiency.

[0004] 2. Cumbersome test process deployment: When it is necessary to update the test process or test parameters, operators need to configure each tester individually, which is labor-intensive and prone to errors, and cannot achieve batch and remote management.

[0005] 3. High software upgrade and maintenance costs: When testing software version updates, technicians need to go to the site to upgrade each device individually. With a large number of devices, the maintenance costs are extremely high, and the devices cannot be used normally during the upgrade period, affecting production efficiency.

[0006] 4. Lack of a unified equipment control mechanism: Existing solutions are difficult to remotely control the power supply status of products and cannot meet the needs of test scenarios that require remote power-on and power-off.

[0007] 5. Insufficient stability assurance for test software: The lack of an independent software protection mechanism means that when the test software exits abnormally, it cannot automatically recover or report the issue in a timely manner, affecting the continuity of testing.

[0008] Therefore, there is an urgent need for a distributed cluster testing system that can achieve centralized monitoring, remote control, and batch management. Summary of the Invention

[0009] The technical problem solved by this invention is to overcome the shortcomings of the prior art and propose a distributed cluster testing system and method based on daemon processes to achieve centralized monitoring of multiple testing instruments, remote control of the testing process, batch updates of testing software, and ensure the stable operation of the testing system.

[0010] The solution to the technical problem of this invention is: a distributed cluster testing system based on a daemon process, including a management host and multiple testers deployed in the same local area network. The management host deploys a server, and each tester runs a client testing module and a daemon module. The testers are used to test the product under test. The guardian module is configured to start automatically on boot and run in the system tray, including: Status reporting submodule: It communicates with the server via heartbeat according to a preset period to report the online status and working status of the tester; Software upgrade submodule: Receives manual upgrade commands from users or remote upgrade commands from the server, and executes version updates for the client test module; Process Guardian Submodule: Monitors the running status of the client test module and automatically recovers it in case of abnormal exit; The client testing module includes: Test Execution Submodule: Executes local test processes or remote test processes issued by the server to test the product under test; Equipment control submodule: Controls the power supply status of the product under test according to the test procedure, and sends test commands to the product under test; Data storage submodule: Stores test data to local storage media; Communication submodule: Establishes a communication connection with the server, receives test procedures and control commands issued by the server, and uploads test results; The server includes: Equipment monitoring submodule: Receives heartbeat information reported by the guardian module in each tester, maintains the equipment status table, and displays the online and working status of all testers in real time; Remote control submodule: Sends test process start commands and power supply control commands to the designated tester; Batch update submodule: Pushes client test module update packages to the guardian modules of multiple testers to achieve batch upgrades of client test modules; Data aggregation submodule: Collects test results uploaded by various testing instruments, performs statistical analysis, and stores the data.

[0011] Furthermore, the heartbeat communication cycle is 1 second, and the heartbeat information includes the tester identifier, online status, working status, and software version number.

[0012] Furthermore, the operating states include: idle state, testing state, fault state, and upgrade state.

[0013] Furthermore, the server and the guardian module communicate via a long TCP connection, and the server and the client testing module communicate via a custom TCP-based protocol.

[0014] Furthermore, the device status table records information about all testing instruments, including: Tester identification, represented by a unique ID or IP address, tester name, online status, working status, software version number, and last heartbeat time; If a tester does not receive a heartbeat for a preset time, its online status will be marked as offline.

[0015] Furthermore, when the guardian module receives the upgrade command, the software upgrade submodule performs the following operations: Set the tester's operating status to "upgrading"; Securely stop the client test module process; Download the client test module update package from the server; Use the MD5 or SHA256 algorithm to verify the integrity of the update packet; Backup the original program files of the client test module; Unzip the update package and replace the client test module program files; Start the new version client test module; Restore the tester to idle status; Report the upgrade results to the server.

[0016] Furthermore, the data storage submodule supports SQLite database or CSV file storage formats.

[0017] Furthermore, the execution process of the remote testing procedure is as follows: In the server-side management interface, select the target tester, configure the test process parameters, and start the test; The server sends a START_TEST message to the client test module of the target tester. The message body contains the test process file content or process ID. The client test module receives messages, parses the test process, and first sends a POWER_ON command to control the product under test to power on. The client-side testing module sends test commands to the product under test sequentially according to the defined process, collects and returns data, and judges the test results. After the test is completed, send the POWER_OFF command to power off the product under test; The client-side testing module writes test data to local storage and uploads it to the server via a TEST_RESULT message; The server receives the test results, updates the database, and displays the test status on the interface; Throughout the process, the guardian module continuously sends heartbeats, and the target tester's working state changes from idle to testing, and then returns to idle after the test is completed.

[0018] Furthermore, the process of batch upgrading the client testing module is as follows: Upload the new version of the client test module update package to the server, and set the version number and update description; Select the tester that needs to be upgraded and click the "Batch Upgrade" button; The server sends a UPGRADE_NOTIFY message to the guardian module of the selected tester, which includes the download address and version information of the client test module update package; After the selected tester's guardian module receives the upgrade notification, it first compares the version of the local client test module. If it is already the latest version, the upgrade is skipped. When the client testing module needs to be upgraded, the daemon module executes the upgrade process: stop the client testing module → download the update package → verify → back up → replace → restart the client testing module; The selected tester's guardian module reports the upgrade results to the server via the UPGRADE_RESULT message; The server aggregates all upgrade results, generates an upgrade report, and displays the number of successful upgrades, the number of failed upgrades, and the reasons for the failures.

[0019] A method for testing distributed clusters based on daemon processes includes the following steps: After the tester is powered on, the guardian module automatically starts and runs in tray mode, establishing a communication connection with the server. The guardian module sends heartbeat information to the server at a preset period. The heartbeat information includes the tester identifier, online status, working status, and software version number. The server receives heartbeat information, updates the device status table, and displays the status of each tester in real time on the monitoring interface; The server sends test process start commands to multiple target testers, and the client test module executes the corresponding test process after receiving the commands; The client-side testing module controls the power supply status of the product under test according to the testing process, sends test commands, and collects test data. The client-side testing module stores test data locally and uploads it to the server for aggregation. When the client testing module needs to be upgraded, the server pushes the update package to the guardian module, and the guardian module completes the software update of the client testing module.

[0020] The advantages of this invention compared to the prior art are: (1) Centralized monitoring improves management efficiency: The online and working status of all testers can be monitored in real time through the server, eliminating the need for on-site inspection of each instrument and greatly improving management efficiency.

[0021] (2) Remote control reduces operational complexity: It supports remote start of the test process and remote control of product power supply. Operators can complete the control operation of all testers on the management host.

[0022] (3) Batch update to reduce maintenance costs: Through the batch update mechanism, the software upgrade of all testers can be completed at one time, which greatly reduces maintenance costs and downtime.

[0023] (4) Guardian mechanism to ensure system stability: An independent guardian module is responsible for maintaining heartbeat communication and process monitoring. Even if the test software is abnormal, it can maintain communication with the server and perform fault recovery.

[0024] (5) Local storage to ensure data security: Test data is stored both locally and on the server side, so test data will not be lost in the event of network abnormality. Attached Figure Description

[0025] Figure 1 This is a diagram illustrating the overall architecture of a distributed cluster testing system based on a daemon process, as described in this invention. Figure 2 This is a functional module diagram of a distributed cluster testing system based on a daemon process according to the present invention. Figure 3 This is a flowchart of the protection module of the present invention. Detailed Implementation

[0026] like Figure 1 As shown, this invention proposes a distributed cluster testing system based on a daemon process, including a management host and multiple testers deployed in the same local area network. The management host deploys a server, and each tester runs a client testing module and a daemon module. The testers are used to test the product under test. The guardian module is configured to start automatically on boot and run in the system tray, including: Status reporting submodule: It communicates with the server via heartbeat according to a preset period to report the online status and working status of the tester; Software upgrade submodule: Receives manual upgrade commands from users or remote upgrade commands from the server, and executes version updates for the client test module; Process Guardian Submodule: Monitors the running status of the client test module and automatically recovers it in case of abnormal exit; The client testing module includes: Test Execution Submodule: Executes local test processes or remote test processes issued by the server to test the product under test; Equipment control submodule: Controls the power supply status of the product under test according to the test procedure, and sends test commands to the product under test; Data storage submodule: Stores test data to local storage media; Communication submodule: Establishes a communication connection with the server, receives test procedures and control commands issued by the server, and uploads test results; The server includes: Equipment monitoring submodule: Receives heartbeat information reported by the guardian module in each tester, maintains the equipment status table, and displays the online and working status of all testers in real time; Remote control submodule: Sends test process start commands and power supply control commands to the designated tester; Batch update submodule: Pushes client test module update packages to the guardian modules of multiple testers to achieve batch upgrades of client test modules; Data aggregation submodule: Collects test result data uploaded by each tester, performs statistical analysis, and stores the data.

[0027] Preferably, the heartbeat communication period is 1 second, and the heartbeat information includes the tester identifier, online status, working status, and software version number.

[0028] Preferably, the working states include: idle state, testing state, fault state, and upgrade state.

[0029] Preferably, the server and the guardian module communicate using a TCP long connection, and the server and the client test module communicate using a custom protocol based on TCP.

[0030] Preferably, when the software upgrade submodule performs the upgrade, it first stops the client test module process, and then restarts the client test module after the file replacement is completed.

[0031] This invention also provides a distributed cluster testing method based on daemon processes, comprising the following steps: S1: After the tester is powered on, the guardian module automatically starts and runs in tray mode, establishing a communication connection with the server; S2: The guardian module sends heartbeat information to the server according to a preset period. The heartbeat information includes the tester identifier, online status, working status, and software version number. S3: The server receives heartbeat information, updates the device status table, and displays the status of each tester in real time on the monitoring interface; S4: The server sends test process start instructions to multiple target testers, and the client test module executes the corresponding test process after receiving the instructions; S5: The client-side testing module controls the power supply status of the product under test according to the testing process, sends test commands, and collects test data; S6: The client-side testing module stores test data locally and uploads it to the server for aggregation; S7: When the client test module needs to be upgraded, the server pushes the update package to the guardian module, and the guardian module completes the software update of the client test module.

[0032] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0033] Example 1 like Figure 1 , Figure 2 As shown, the distributed cluster testing system provided in this embodiment includes a management host and multiple test instruments, all deployed within the same local area network. The management host hosts a server, and each test instrument runs a daemon module and a client testing module. Each test instrument tests one product under test.

[0034] The local area network can be Ethernet, and all devices are connected via a switch. Communication between the server, the guardian module, and the client testing module all uses the TCP / IP protocol.

[0035] The detailed server-side design scheme includes: The server is deployed on the management host and is implemented using a B / S or C / S architecture, including the following functional modules: (1) Equipment monitoring submodule The equipment monitoring submodule maintains an equipment status table, recording information about all testing instruments, including: Tester identification (unique ID or IP address); Tester name; Online status (online / offline); Working status (Idle / Testing / Faulty / Upgrading); Software version number; Last heartbeat time.

[0036] When a heartbeat message is received from the guardian module, the status and last heartbeat time of the corresponding tester are updated. If a tester does not receive a heartbeat for more than a preset time (e.g., 5 seconds), it is marked as offline.

[0037] The tester monitoring interface displays the real-time status of all testers in the form of a list or topology diagram, and provides functions such as status filtering and alarm prompts.

[0038] (2) Remote control submodule The remote control submodule provides the following remote control functions: Remote start test: Send the test procedure file and start command to the specified tester; Remote stop test: Send a stop test command to the specified tester; Remote power-on control: Sends a product power-on command to a designated tester; Remote power-off control: Sends a product power-off command to a designated tester; Operators can choose to perform batch control operations on one or multiple testing instruments.

[0039] (3) Batch update submodule Batch update submodules enable batch upgrades of the client testing module, including: Update package management: Upload, store, and delete update packages for client test modules; Version management: Records version information and update logs for each client test module; Batch push: Push update commands to multiple selected test instruments; Upgrade monitoring: Real-time display of the upgrade progress and results of each tester.

[0040] (4) Data aggregation submodule The data aggregation submodule collects test results uploaded by each tester and provides: a. Data storage: Store test results in a database; b. Statistical analysis: Statistical analysis is performed according to dimensions such as time, product model under test, and tester type; c. Report Generation: Generate test reports and statistical reports; d. Data export: Supports exporting to Excel, CSV and other formats.

[0041] The detailed design scheme of the guardian module includes: The guardian module is deployed on each tester, configured to start automatically on boot, and automatically minimized to the system tray after startup. For example... Figure 3 As shown, the workflow of the guardian module is as follows: (1) Startup and initialization After the tester is powered on, the guardian module is automatically started by the operating system and performs initialization operations: a. Read the configuration file to obtain the server's IP address and port number; b. Obtain the local device identifier (MAC address or pre-configured ID); c. Minimize the window to the system tray and display the tray icon; (2) Heartbeat communication mechanism The guardian module establishes a long TCP connection with the server and starts a heartbeat timer, sending a heartbeat message every second.

[0042] When the network is interrupted, the guardian module automatically attempts to reconnect, and the reconnection interval adopts an exponential backoff strategy.

[0043] (3) Process protection mechanism The daemon module periodically checks if the client test module process exists, with a check interval of 5 seconds. If the client test module process is detected to have exited abnormally, the daemon module controls the client test module to automatically restart and marks a fault status in the heartbeat information.

[0044] (4) Software upgrade mechanism After receiving the upgrade command, the guardian module performs the following steps: 1. Set the tester's operating status to "upgrading"; 2. Securely stop the client testing module process; 3. Download the client test module update package from the server; 4. Verify the integrity of the update package (using MD5 or SHA256 algorithms); 5. Back up the original program files of the client test module; 6. Unzip the update package and replace the client test module program files; 7. Launch the new version client test module; 8. Restore the tester to idle mode; 9. Report the upgrade results to the server.

[0045] (5) Tray menu function Right-click the tray icon to display the menu items: a. Display main window: Displays the main interface of the guardian module and allows you to view the operation log; b. Manual upgrade: Manually select the update package to upgrade; c. Start the test software: Manually start the client test module; d. Stop the testing software: Manually stop the client-side testing module; e. Exit: Exit the daemon module.

[0046] The detailed design scheme for the client-side testing module includes: The client-side testing module is the software that performs the actual testing tasks and is deployed on the testing instrument.

[0047] (1) Test execution submodule The test execution submodule parses and executes the test flow. The test flow can be: Local process: Test process files pre-stored locally; Remote process: The test process delivered in real time by the server.

[0048] The test process is defined using scripts or XML format, and includes a sequence of test steps. Each step includes: operation type, parameters, timeout, expected result, etc.

[0049] (2) Equipment control submodule The device control submodule controls the product under test through a hardware interface, including: Power supply control: Powering on / off the product under test is controlled via relays or programmable power supplies; Command communication: Send test commands to the product under test via interfaces such as serial port, USB, and network port; Signal acquisition: Acquire test data returned by the product under test.

[0050] (3) Data storage submodule The data storage submodule stores test data locally, including: Test log: Records the execution status of each test step; Test Results: Record the test pass / fail status and detailed data.

[0051] The data storage submodule supports SQLite databases or CSV files.

[0052] Local storage ensures data is not lost during network outages, and data can be manually or automatically uploaded to the server once the network is restored.

[0053] (4) Communication Submodule The communication submodule communicates with the server using a custom TCP protocol, supporting: Receive test procedures and control instructions; Report the test status and progress; Upload test result data; Receive power supply control commands.

[0054] In some embodiments, a complete remote testing process is executed as follows: Step 1: The operator selects the target tester in the server-side management interface, configures the test process parameters, and clicks the "Start Test" button; Step 2: The server sends a START_TEST message to the client test module of the target tester. The message body contains the test process file content or process ID. Step 3: The client test module receives the message, parses the test process, and first sends the POWER_ON command to control the product under test to power on; Step 4: The client-side testing module sends test commands to the product under test sequentially according to the process definition, collects the returned data, and judges the test results; Step 5: After the test is completed, send the POWER_OFF command to power off the product under test; Step 6: The client-side testing module writes the test data to local storage and uploads it to the server via the TEST_RESULT message; Step 7: The server receives the test results, updates the database, and displays the test status on the interface; Step 8: Throughout the process, the guardian module continuously sends heartbeats, and the target tester's working status changes from idle to testing, and returns to idle after the test is completed.

[0055] In some embodiments, the process of batch upgrading the client testing module is as follows: Step 1: The administrator uploads the new version of the client test module update package to the server, and sets the version number and update description; Step 2: The administrator selects the testers that need to be upgraded (all can be selected or filtered by conditions), and clicks the "Batch Upgrade" button; Step 3: The server sends a UPGRADE_NOTIFY message to the selected tester's guardian module, which includes the download address and version information of the client test module update package; Step 4: After receiving the upgrade notification, the selected tester's guardian module first compares the version of the local client test module. If it is already the latest version, the upgrade is skipped. Step 5: When the client testing module needs to be upgraded, the daemon module executes the upgrade process: stop the client testing module → download the update package → verify → back up → replace → restart the client testing module; Step 6: Select the guardian module of the tester to report the upgrade result (success / failure and reason) to the server via the UPGRADE_RESULT message; Step 7: The server summarizes all upgrade results, generates an upgrade report, and displays the number of successful upgrades, the number of failed upgrades, and the reasons for the failures.

[0056] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications to the technical solutions of the present invention by utilizing the methods and techniques disclosed above without departing from the spirit and scope of the present invention. Therefore, any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solutions of the present invention shall fall within the protection scope of the technical solutions of the present invention.

[0057] The contents not described in detail in this specification are common knowledge to those skilled in the art.

Claims

1. A distributed cluster testing system based on daemon processes, characterized in that, It includes a management host and multiple testers deployed in the same local area network. The management host deploys the server, and each tester runs a client test module and a guardian module. The testers are used to test the product under test. The guardian module is configured to start automatically on boot and run in the system tray, including: Status reporting submodule: It communicates with the server via heartbeat according to a preset period to report the online status and working status of the tester; Software upgrade submodule: Receives manual upgrade commands from users or remote upgrade commands from the server, and executes version updates for the client test module; Process Guardian Submodule: Monitors the running status of the client test module and automatically recovers it in case of abnormal exit; The client testing module includes: Test Execution Submodule: Executes local test processes or remote test processes issued by the server to test the product under test; Equipment control submodule: Controls the power supply status of the product under test according to the test procedure, and sends test commands to the product under test; Data storage submodule: Stores test data to local storage media; Communication submodule: Establishes a communication connection with the server, receives test procedures and control commands issued by the server, and uploads test results; The server includes: Equipment monitoring submodule: Receives heartbeat information reported by the guardian module in each tester, maintains the equipment status table, and displays the online and working status of all testers in real time; Remote control submodule: Sends test process start commands and power supply control commands to the designated tester; Batch update submodule: Pushes client test module update packages to the guardian modules of multiple testers to achieve batch upgrades of client test modules; Data aggregation submodule: Collects test results uploaded by various testing instruments, performs statistical analysis, and stores the data.

2. The distributed cluster testing system based on daemon processes according to claim 1, characterized in that, The heartbeat communication cycle is 1 second, and the heartbeat information includes the tester identifier, online status, working status, and software version number.

3. A distributed cluster testing system based on a daemon process according to any one of claims 1 or 2, characterized in that, The operating states include: idle state, testing state, fault state, and upgrade state.

4. The distributed cluster testing system based on daemon processes according to claim 1, characterized in that, The server and the guardian module communicate via a long TCP connection, while the server and the client testing module communicate via a custom TCP-based protocol.

5. A distributed cluster testing system based on a daemon process according to claim 1, characterized in that, The device status table records information about all testing instruments, including: Tester identification, represented by a unique ID or IP address, tester name, online status, working status, software version number, and last heartbeat time; If a tester does not receive a heartbeat for a preset time, its online status will be marked as offline.

6. The distributed cluster testing system based on daemon processes according to claim 1, characterized in that, When the guardian module receives the upgrade command, the software upgrade submodule performs the following operations: Set the tester's operating status to "upgrading"; Securely stop the client test module process; Download the client test module update package from the server; Use the MD5 or SHA256 algorithm to verify the integrity of the update packet; Backup the original program files of the client test module; Unzip the update package and replace the client test module program files; Start the new version client test module; Restore the tester to idle status; Report the upgrade results to the server.

7. The distributed cluster testing system based on daemon processes according to claim 1, characterized in that, The data storage submodule supports SQLite databases or CSV files.

8. A distributed cluster testing system based on a daemon process according to claim 1, characterized in that, The execution process of the remote testing procedure is as follows: In the server-side management interface, select the target tester, configure the test process parameters, and start the test; The server sends a START_TEST message to the client test module of the target tester. The message body contains the test process file content or process ID. The client test module receives messages, parses the test process, and first sends a POWER_ON command to control the product under test to power on. The client-side testing module sends test commands to the product under test sequentially according to the defined process, collects and returns data, and judges the test results. After the test is completed, send the POWER_OFF command to power off the product under test; The client-side testing module writes test data to local storage and uploads it to the server via a TEST_RESULT message; The server receives the test results, updates the database, and displays the test status on the interface; Throughout the process, the guardian module continuously sends heartbeats, and the target tester's working state changes from idle to testing, and then returns to idle after the test is completed.

9. A distributed cluster testing system based on a daemon process according to claim 1, characterized in that, The process for batch upgrading the client testing module is as follows: Upload the new version of the client test module update package to the server, and set the version number and update description; Select the tester that needs to be upgraded and click the "Batch Upgrade" button; The server sends a UPGRADE_NOTIFY message to the guardian module of the selected tester, which includes the download address and version information of the client test module update package; After the selected tester's guardian module receives the upgrade notification, it first compares the version of the local client test module. If it is already the latest version, the upgrade is skipped. When the client testing module needs to be upgraded, the daemon module executes the upgrade process: stop the client testing module → download the update package → verify → back up → replace → restart the client testing module; The selected tester's guardian module reports the upgrade results to the server via the UPGRADE_RESULT message; The server aggregates all upgrade results, generates an upgrade report, and displays the number of successful upgrades, the number of failed upgrades, and the reasons for the failures.

10. A distributed cluster testing method based on a daemon process, based on the system described in any one of claims 1 to 9, characterized in that, Includes the following steps: After the tester is powered on, the guardian module automatically starts and runs in tray mode, establishing a communication connection with the server. The guardian module sends heartbeat information to the server at a preset period. The heartbeat information includes the tester identifier, online status, working status, and software version number. The server receives heartbeat information, updates the device status table, and displays the status of each tester in real time on the monitoring interface; The server sends test process start commands to multiple target testers, and the client test module executes the corresponding test process after receiving the commands; The client-side testing module controls the power supply status of the product under test according to the testing process, sends test commands, and collects test data. The client-side testing module stores test data locally and uploads it to the server for aggregation. When the client testing module needs to be upgraded, the server pushes the update package to the guardian module, and the guardian module completes the software update of the client testing module.

Images