A power cycle test method and device, electronic equipment and readable storage medium

Abstract

This application provides a power supply cycle testing method, apparatus, electronic device, and readable storage medium. The method parses test commands and determines whether the current test process is in continuation mode. If it is, it logs into the desktop environment via automatic login configuration and restarts the target test program from the previous stage by automatically starting the test item according to the test program identifier in the test command. It restores the test parameters recorded in the parameter repository and continues to execute preprocessing and / or action sequences, saving the execution data and the end time of this test program to the session log corresponding to the target test program from the previous stage. If the test program's cycle count reaches the preset number of cycles, the test process ends and the test results are output. This improves the efficiency and accuracy of power supply cycle testing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a power cycle testing method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] Power cycle testing refers to the process of repeatedly performing a cycle of "power on - stable operation - power off / disconnect - power off pause - power on again" on electronic devices or components to evaluate their reliability and stability under long-term, frequent power on / off conditions.

[0003] In existing technologies, power cycle testing of computer systems typically involves engineers writing scripts to directly drive system commands for testing. This testing process is prone to issues if the system restarts, as the test cannot automatically resume and usually requires manual restarting by staff or execution of the restart process via another device. Furthermore, test data is easily lost after a restart, resulting in low efficiency and a high error rate in power cycle testing. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a power cycle testing method, apparatus, electronic device, and readable storage medium. During the test run, the target test program before the restart is automatically started through the configured automatic login configuration and automatic startup item. The test parameters recorded in the parameter warehouse are restored to continue execution and the preprocessing and / or action sequence interrupted is resumed. The execution results are saved to the same session log before the restart. In this way, the test process of automatically logging in and automatically restoring test parameters can improve the efficiency and accuracy of power cycle testing.

[0005] In a first aspect, embodiments of this application provide a power cycle testing method, the power cycle testing method comprising:

[0006] Parse the test commands to determine whether the current test process is in continue mode;

[0007] If the current test process is in continue mode, log in to the desktop environment through the automatic login configuration, and start the test project through the automatic startup item to restart the previous target test program according to the test program identifier in the test command; wherein, the automatic login configuration and the automatic startup item are installed when the test program is first started, and a parameter repository is established and a test program identifier is generated when the test program is first started;

[0008] Restore the test parameters recorded in the parameter repository, and continue to execute preprocessing and / or action sequences. Save the execution data and the end time of this test program to the session log corresponding to the target test program before the restart.

[0009] If the test program reaches the preset number of loops, the test process ends and the test results are output.

[0010] In one possible implementation, after parsing the test command and determining whether the current test process is in a continuation mode, the power cycle test method further includes:

[0011] If the current test process is not in continue mode, generate a test program identifier based on the test parameters obtained from parsing the test command;

[0012] Initialize the session log and establish the parameter repository, then write the test parameters into the parameter repository;

[0013] Install automatic login configuration and automatic startup items;

[0014] Read the preprocessing and / or action sequence from the configuration file, execute the preprocessing and / or action sequence, and save the execution data and the end time of this test program to the session log;

[0015] Check if the system restart process has been triggered.

[0016] If the system restart process is triggered, the current test process will be exited and the test will be resumed.

[0017] In one possible implementation, after detecting whether a system restart process has been triggered, the power cycle test method further includes:

[0018] If the system restart process is not triggered, check whether the current test program has reached the preset number of loops.

[0019] If the test program reaches the preset number of loops, the test process ends and the test results are output.

[0020] If the number of loops in the test program does not reach the preset number of loops, record the number of loops, and continue to read and execute preprocessing and / or action sequences from the configuration file until the number of loops in the test program reaches the preset number of loops, then end the test process and output the test results.

[0021] In one possible implementation, the step of ending the test process and outputting the test result if the number of loops in the test program reaches a preset number of loops includes:

[0022] Increment the current loop count by one, and check if the current loop count of the test program has reached the preset loop count;

[0023] If the test program reaches the preset number of loops, the test process ends and the test results are output.

[0024] The power cycle test method further includes:

[0025] If the number of loops in the test program does not reach the preset number of loops, record the number of loops, and continue to read and execute preprocessing and / or action sequences from the configuration file until the number of loops in the test program reaches the preset number of loops, then end the test process and output the test results.

[0026] In one possible implementation, after initializing the session log, establishing the parameter repository, and writing the test parameters into the parameter repository, the power cycle test method further includes:

[0027] The test parameters in the parameter repository are centrally persisted.

[0028] In one possible implementation, the step of ending the test process and outputting the test result if the number of loops in the test program reaches a preset number of loops includes:

[0029] If the test program reaches the preset number of loops, uninstall the configured automatic login settings and automatic startup items, restore the system's automatic login settings, clear temporary files, and then output the test results.

[0030] In one possible implementation, the power cycle test method further includes:

[0031] If an abnormal event is triggered during the testing process, the exception handling process will be automatically executed according to the type of the abnormal event.

[0032] The abnormal events include at least one of the following:

[0033] Automatic login configuration and automatic startup item installation failed; parameter files in the parameter repository were corrupted or parameter file verification failed; session log writing was abnormal; test process interruption command was received.

[0034] Secondly, embodiments of this application also provide a power cycle testing device, the power cycle testing device comprising:

[0035] The mode determination module is used to parse test commands and determine whether the current test process is in continue mode;

[0036] The test program restart module is used to log in to the desktop environment through automatic login configuration if the current test process is in continue mode, and start the target test program that was restarted before by starting the test project through automatic startup item according to the test program identifier in the test command; wherein, the automatic login configuration and the automatic startup item are installed when the test program is first started, and a parameter repository is established and a test program identifier is generated when the test program is first started;

[0037] The test data saving module is used to restore the test parameters recorded in the parameter warehouse and continue to execute preprocessing and / or action sequences, and save the execution data and the end time of this test program to the session log corresponding to the target test program before the restart;

[0038] The test result output module is used to end the test process and output the test result if the number of loops in the test program reaches the preset number of loops.

[0039] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the power cycle test method as described in any of the first aspects.

[0040] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the power cycle test method as described in any of the first aspects.

[0041] The power cycle testing method, apparatus, electronic device, and readable storage medium provided in this application parsed the test command and determined whether the current test process was in a continuation mode. If the current test process was in a continuation mode, the system logged into the desktop environment via automatic login configuration and started the test item to restart the target test program according to the test program identifier in the test command. The automatic login configuration and the automatic startup item were installed when the test program was first started, and a parameter repository was established and a test program identifier was generated during the first start of the test program. The system restored the test parameters recorded in the parameter repository and continued to execute preprocessing and / or action sequences, saving the execution data and the end time of this test program to the session log corresponding to the target test program before restarting. If the number of loops of the test program reached the preset number of loops, the test process ended and the test results were output. In this way, during the test continuation process, the target test program before the restart is automatically started through the configured automatic login configuration and automatic startup item, the test parameters recorded in the parameter repository are restored and the preprocessing and / or action sequence interrupted is resumed, and the execution results are saved to the same session log before the restart. In this way, the test process of automatically logging in and automatically restoring test parameters can improve the efficiency and accuracy of power cycle testing.

[0042] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0043] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 A flowchart of a power supply cycling test method provided in an embodiment of this application;

[0045] Figure 2 This is a schematic diagram of the power cycle test process provided in an embodiment of this application;

[0046] Figure 3 This is a schematic diagram of the power cycle testing system provided in the embodiments of this application;

[0047] Figure 4 This is a schematic diagram of the test process of the power cycle test system provided in the embodiments of this application;

[0048] Figure 5 This is a schematic diagram of the structure of a power supply cycle testing device provided in an embodiment of this application;

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

[0050] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0051] First, the applicable scenarios for this application will be introduced. This application can be applied to the field of computer technology.

[0052] Power cycle testing refers to the process of repeatedly performing a cycle of "power on - stable operation - power off / disconnect - power off pause - power on again" on electronic devices or components to evaluate their reliability and stability under long-term, frequent power on / off conditions.

[0053] In existing solutions, the test process cannot be automatically resumed after a system restart. For example, when executing a restart test (REBOOT mode), the script process terminates when the system shuts down, requiring manual rerunning after restarting. This not only increases manual costs but also easily introduces operational errors. Furthermore, existing technologies lack a unified state preservation mechanism. Test progress (such as the current loop count and test mode parameters) is typically stored in temporary files or memory, and this data is lost after a restart. For example, in cross-restart tests, existing scripts cannot record the number of completed loops, preventing the test from continuing from the breakpoint. Furthermore, existing technologies require manual configuration of automatic login and auto-start services. For example, after a suspended test (STR mode), the system may remain on the login screen upon recovery, requiring manual login to continue testing. This increases the complexity and instability of the test. Furthermore, existing log management typically involves simple appending to a file, lacking rotation, color output, and cross-restart correlation. For example, logs from multiple tests may be mixed in a single file, making it difficult to distinguish between different running sessions. Furthermore, existing solutions typically hard-code test parameters and do not support dynamic configuration. For example, switching test modes (such as from REBOOT to STR) requires modifying script code and cannot be flexibly adjusted via command-line parameters or configuration files. This results in low efficiency and a high error rate in power cycle testing.

[0054] Based on this, embodiments of this application provide a power cycle testing method to improve the efficiency and accuracy of power cycle testing.

[0055] Please see Figure 1 , Figure 1 This is a flowchart illustrating a power cycle testing method provided in an embodiment of this application. Figure 1 As shown in the embodiments of this application, the power cycle testing method includes:

[0056] S101. Parse the test command and determine whether the current test process is in continue mode.

[0057] S102. If the current test process is in continue mode, log in to the desktop environment through the automatic login configuration, and start the test project to restart the target test program according to the test program identifier in the test command through the automatic startup item; wherein, the automatic login configuration and the automatic startup item are installed when the test program is first started, and a parameter repository is established and a test program identifier is generated when the test program is first started.

[0058] S103. Restore the test parameters recorded in the parameter repository, and continue to execute preprocessing and / or action sequences. Save the execution data and the end time of this test program to the session log corresponding to the target test program before the restart.

[0059] S104. If the number of loops in the test program reaches the preset number of loops, the test process ends and the test results are output.

[0060] The power cycle testing method provided in this application automatically starts the target test program before restarting through the configured automatic login configuration and automatic startup item during the test run. It restores the test parameters recorded in the parameter warehouse to continue execution and interrupted preprocessing and / or action sequences, and saves the execution results to the same session log before restarting. In this way, the test process of automatically logging in and automatically restoring test parameters to continue execution can improve the efficiency and accuracy of power cycle testing.

[0061] The exemplary steps of the embodiments of this application are described below:

[0062] S101. Parse the test command and determine whether the current test process is in continue mode.

[0063] Here, power cycle testing refers to the process of repeatedly performing a cycle of "power on - stable operation - power off / out of power - power off pause - power on again" on electronic devices or components to evaluate their reliability and stability under long-term, frequent power on / off conditions.

[0064] In existing technologies, power cycle testing of computer systems typically involves engineers writing scripts to directly drive system commands for testing. This testing process is prone to issues if the system restarts, as the test cannot automatically resume and usually requires manual restarting by staff or execution of the restart process via another device. Furthermore, test data is easily lost after a restart, resulting in low efficiency and a high error rate in power cycle testing.

[0065] Based on this, in the embodiments of this application, during the test continuation process, the target test program before the restart is automatically started through the configured automatic login configuration and automatic startup item, the test parameters recorded in the parameter warehouse are restored to continue execution and the preprocessing and / or action sequence interrupted is resumed, and the execution result is saved to the same session log before the restart. In this way, the test process of automatically logging in and automatically restoring test parameters to continue execution can improve the efficiency and accuracy of power cycle testing.

[0066] In one possible implementation, after receiving a test command, the test name is parsed, and the parsed test parameters determine whether the current test process is in a continuation mode.

[0067] Here, test parameters can include running mode, whether to loop, delayed execution, current loop count, task start time, last finish time, and next schedule.

[0068] In one possible implementation, if the current_loop does not exist, it is determined that this test process is the first test process, the current_loop is created and initialized to 0, and it is not in the continuation mode; if the loop count is not zero, it is determined that the current test process is in the continuation mode.

[0069] In another possible implementation, a self-determination mechanism (checking status files / timestamps / boot-ids), a flag file / directory (if it exists, continue running), a watchdog / monitor (systemd Restart=always, supervisord) can also be activated to determine whether the test process is in continue running mode.

[0070] Furthermore, if it is determined that the current test process is in continue mode, after the system restarts, it can automatically log in to the desktop environment and start the test project through the automatic startup item according to the test program identifier in the test command, thereby restarting the target test program and proceeding with the subsequent test process.

[0071] S102. If the current test process is in continue mode, log in to the desktop environment through the automatic login configuration, and start the test project to restart the target test program according to the test program identifier in the test command through the automatic startup item; wherein, the automatic login configuration and the automatic startup item are installed when the test program is first started, and a parameter repository is established and a test program identifier is generated when the test program is first started.

[0072] In one possible implementation, if it is determined that the current test process is in continue mode, it is necessary to automatically log in to the desktop environment through the automatic login configuration, and start the test project through the automatic startup item according to the test program identifier in the test command to restart the previous target test program and continue to complete the test process.

[0073] Here, the automatic login configuration and automatic startup items are installed and configured when the test process is executed for the first time. The first execution of the test process will be described below.

[0074] Specifically, after the step of "parse the test command and determine whether the current test process is in continuous running mode", the power supply cycle test method further includes:

[0075] a1: If the current test process is not in continue mode, generate a test program identifier based on the test parameters obtained from parsing the test command.

[0076] a2: Initialize the session log and establish the parameter repository, and write the test parameters into the parameter repository.

[0077] a3: Install automatic login configuration and automatic startup items.

[0078] a4: Read the preprocessing and / or action sequence from the configuration file, execute the preprocessing and / or action sequence, and save the execution data and the end time of this test program to the session log.

[0079] a5: Check if the system restart process has been triggered.

[0080] a6: If the system restart process is triggered, exit the current test process and enter the continuation mode.

[0081] In one possible implementation, after the test program starts, an authentication / administration permission acquisition operation is performed.

[0082] Here, the operation of authentication / acquiring management permissions refers to the process by which a user obtains access permissions beyond their normal permissions. Specifically, users generally do not have permission to access underlying processing logic other than the user interface. Therefore, it is necessary to perform authentication / acquiring management permissions to grant users access permissions.

[0083] Specifically, the authentication / administration permission path can be determined according to the test environment, such as sudo / su; credentials are only held briefly and cleaned up uniformly at necessary stages; basic capabilities such as command execution, INI read and write, countdown, and output formatting are provided.

[0084] In another possible implementation, during the permission authorization process, polkit authorization rules can be used; root daemon + minimum interface of DBus / Unix domain sockets; Linux capabilities (setcap) can be granted only as necessary; dedicated test users / groups can be isolated to ensure minimal permissions and security.

[0085] Furthermore, after the authentication / acquisition of administrative privileges is completed, the test command is parsed. If it is based on the test parameters in the test command, specifically, the test program uses a persistent state file parameter.ini to drive the cycle: each time it starts, it first reads current_loop from the file. If current_loop does not exist, it is determined that this is the first run, current_loop is created, and current_loop is initialized to 0.

[0086] Furthermore, a test program identifier is generated, which can be, for example, run_id, etc. This is a unique identifier for the test program, and the same run_id indicates that they belong to the same test program process.

[0087] In one possible implementation, after generating the test program identifier, the session log can be initialized and a parameter repository can be established to store test parameters; the test parameters are then written into the parameter repository.

[0088] For example, initial values ​​can be written into the parameter repository: mode, loop, delay, current_loop=0, start_time.

[0089] In one possible implementation, in order to ensure that the context information of the parameter repository can be restored in subsequent run processes, the test parameters in the parameter repository can be centrally persisted.

[0090] Specifically, after the step of "initializing the session log and establishing the parameter repository, and writing the test parameters into the parameter repository", the power cycle test method further includes:

[0091] b1: Centrally persist the test parameters in the parameter repository.

[0092] Here, centralized persistence of parameters refers to the centralized and organized saving of key configurations, states, and results during the processing, so as to facilitate reproduction, debugging, monitoring, and recovery.

[0093] In one possible implementation, the parameter repository can be protected by file locks, thereby centrally persisting fields such as mode, loop, delay, current_loop, start_time, and last_finish_time in the parameter repository; furthermore, atomic write-back and recovery capabilities can be provided to ensure consistency of breakpoint resumption.

[0094] In another possible implementation, it can also be done via INI. JSON / TOML / YAML equivalents replace file locks for centralized persistence processes; specifically, fcntl locks. "Temporary file writing + fsync + atomic renaming"; embedded storage such as SQLite / LMDB / LevelDB; event-based append logs (summarized during recovery) to save test parameters in the parameter repository.

[0095] Furthermore, install the automatic login configuration and automatic startup item, with automatic login and auto-start, and Exec pointing to the continue running mode -re.

[0096] Specifically, configure / verify automatic login of the display manager so that the desktop session can be entered without manual intervention after the system restarts; write startup items to the desktop startup directory, with Exec pointing to the "resume mode (-re)" of the same program.

[0097] In another possible implementation, automatic login and startup processes can be controlled via systemd --user / system services, cron @reboot / anacron, console autologin (getty autologin + shell startup), login scripts (~ / .profile), Windows scheduled tasks, macOS launchd, etc.

[0098] Furthermore, after determining the automatic login configuration and automatic startup items, the corresponding sequence can be read from the configuration file, and the policy steps can be executed sequentially in a loop.

[0099] Here, the sequence can include preprocessing sequences and action sequences. Specifically, executing a preprocessing sequence can involve performing operations such as environment checks, pre-cleaning, and recording timestamps; executing an action sequence can involve triggering system operations or external commands.

[0100] In one possible implementation, the configuration file can be a YAML file, assembled and executed sequentially at runtime. It supports customization by project / machine type without altering the main control logic. Specifically, the preprocessing sequence and action sequence are extracted from the code and configured in YAML, which is then assembled and executed by the main control at runtime. Switching between REBOOT (reboot), STR (suspend), and SD (sleep / shutdown) modes, or customizing for a project, only requires editing the configuration file; no modification to the main control logic or large-scale regression testing is needed, reducing delivery and maintenance costs.

[0101] Here, during the execution of the test process, the user can update the configuration information in the YAML file. Exemplarily, the test process has been looped 30 times, and the current user requirement is to execute the test process again from the 50th time. Then, the user can directly modify the YAML file without changing the main control logic to complete the update of the test requirements.

[0102] In another possible implementation, the configuration file can also be JSON / TOML / custom DSL; pluggable actions (entry point / external script dynamic loading); explicit state machine or workflow engine (DAG / node) to express the same sequential relationship.

[0103] In one possible implementation, after executing the preprocessing and / or action sequence, the execution data and the end time of the current test program will be saved to the session log.

[0104] Specifically, the loop execution process can be: (a) Read the configuration file configured by the policy module to obtain the preprocessing or ordered action sequence; (b) Enter the loop i = current_loop+1 … loop: Synchronously write back current_loop = i-1; Execute the preprocessing sequence; Execute the action sequence; Record the end time last_finish_time and return code of the current test program; If the restart is not triggered and i < loop, enter the next round of the test process.

[0105] Furthermore, after executing the preprocessing sequence and the action sequence, it is necessary to detect whether the system restart process is triggered currently. If the system restart process is triggered currently, the system exits the normal process, and the system executes the restart process, and then enters the resume mode.

[0106] In another possible implementation, if the system restart process is not triggered currently, the subsequent processing process is determined according to the current loop count.

[0107] Specifically, after the step of "detecting whether the system restart process is triggered currently", the power cycle test method further includes:

[0108] c1: If the system restart process is not triggered, detect whether the loop count of the current test program reaches the preset loop count.

[0109] c2: If the loop count of the test program reaches the preset loop count, end the test process and output the test result.

[0110] c3: If the loop count of the test program does not reach the preset loop count, record the loop count, and continue to read and execute the preprocessing and / or action sequence from the configuration file until the loop count of the test program reaches the preset loop count, then end the test process and output the test result.

[0111] In one possible implementation, if the system restart process is not triggered, it is determined that the system restart process will not be executed at present. The loop test continues. If the test hits the test parameter test count, and it is determined that the loop count of the test program has reached the preset loop count, the test process is completed and the test result is output after safe termination. If the loop count of the test program has not reached the preset loop count, the loop count is recorded, and preprocessing and / or action sequences are read and executed from the configuration file until the loop count of the test program reaches the preset loop count. The test process ends and the test result is output.

[0112] Here, the preset number of loops can be set according to the current testing requirements, and the specific setting method is not limited here.

[0113] For example, if the preset number of loops is set to 100, and the current number of loops is 98, then the preprocessing and / or action sequence in the configuration file will continue to be read and executed until the number of loops in the test program reaches 100, then the test process will end and the test result will be output; if the current number of loops is 100, then the current test process needs to be exited and the test result will be obtained directly.

[0114] In one possible implementation, the system restart process is triggered, the system exits the process normally, the system executes the restart process, and then enters the resume mode. After the target test program that was interrupted before the restart, the test parameters recorded in the parameter repository are restored to continue the test process.

[0115] S103. Restore the test parameters recorded in the parameter repository, and continue to execute preprocessing and / or action sequences. Save the execution data and the end time of this test program to the session log corresponding to the target test program before the restart.

[0116] In one possible implementation, the test parameters recorded in the recovery parameter repository can be restored to contexts such as current_loop, mode, and delay, and the interrupted preprocessing and / or action sequence can be continued. The execution data and the end time of this test program are saved to the session log corresponding to the target test program before the restart. That is, the execution data in the same test process is written to the same session log.

[0117] In one possible implementation, a test procedure identifier, for example, run_id, can be used to bind a complete test process; a rolling strategy with configurable capacity and number of copies can be adopted; and the same session log can be written after a restart to record the start / end of each round, return code, and key events.

[0118] In another possible implementation, journald can be persisted and run_id can be used as a structured field; logrotate can be used for external rotation; "round-splitting" logs (one file or directory per round representing a session); and structured logs (JSON Lines / CSV) can be used to bind session logs to the test process.

[0119] Here, for the continuation process, the test process continues to execute the number of loops that were interrupted before. For example, after the system restarts, the program is restarted by auto-start. The program reads the status file again and repeats the closed loop of "read current_loop is 3 → calculate +1 → write back the new number of loops (4 times) → execute the action" until the current_loop reaches the preset total number of loops and then ends.

[0120] In one possible implementation, after performing preprocessing and / or the action sequence, the execution data and the end time of this test program are saved to the same session log.

[0121] Furthermore, after incrementing the current loop count by one and writing it back, the test process execution sequence is continued to run, and the subsequent processing flow is determined based on the current loop count.

[0122] S104. If the number of loops in the test program reaches the preset number of loops, the test process ends and the test results are output.

[0123] Specifically, the step "If the number of loops in the test program reaches the preset number of loops, the test process ends and the test results are output" includes:

[0124] d1: Increment the current loop count by one and check if the current loop count of the test program has reached the preset loop count.

[0125] d2: If the number of loops in the test program reaches the preset number of loops, the test process ends and the test results are output.

[0126] Furthermore, the power cycle test method also includes:

[0127] e1: If the number of loops in the test program does not reach the preset number of loops, record the number of loops, and continue to read and execute preprocessing and / or action sequences from the configuration file until the number of loops in the test program reaches the preset number of loops, then end the test process and output the test results.

[0128] In one possible implementation, after incrementing the current loop count and writing it back, the test process execution sequence is continued to run, and the loop test continues. If the test hits the test parameter test count, and it is determined that the loop count of the test program has reached the preset loop count, the test process is completed, and the test result is output after a safe termination. If the loop count of the test program has not reached the preset loop count, the loop count is recorded, and preprocessing and / or action sequences are read from the configuration file and executed until the loop count of the test program reaches the preset loop count, the test process ends, and the test result is output.

[0129] Similarly, the preset number of loops can be set according to the current testing requirements, and the specific setting method is not limited here.

[0130] Furthermore, during the execution of the loop test process, once the number of loops in the test program is determined to have reached the preset number of loops, the test process needs to be terminated and the test results output. In order to avoid storing too many temporary files in the system, temporary files should be deleted before outputting the test results after the test process is terminated.

[0131] Specifically, the step "If the number of loops in the test program reaches the preset number of loops, end the test process and output the test results" includes:

[0132] f1: If the test program reaches the preset number of loops, uninstall the configured automatic login and automatic startup items, restore the system's automatic login configuration, clear the temporary files, and then output the test results.

[0133] In one possible implementation, if the number of loops of the test program reaches the preset number of loops or after receiving the midpoint signal in the test process, the configured automatic login configuration and automatic startup item are uninstalled, the system automatic login configuration is restored to the system default state, and the temporarily stored files are cleared. Then, the test results and session log path are output to ensure that the test environment returns to its initial state.

[0134] In another possible implementation, uninstallation and recovery can be completed through the systemd ExecStopPost= / one-shot service; a "backup first, restore later" strategy (automatic backup / comparison of configuration files); limiting changes to temporary directories / container mount points, deleting them immediately upon completion, ensuring that the test environment returns to its initial state.

[0135] Furthermore, users can view the test information recorded in the session log by following the session log path.

[0136] In one possible implementation, during the testing process, abnormal events may occur, and different handling methods can be provided for different abnormal events.

[0137] Specifically, the power supply cycle test method further includes:

[0138] g1: If an exception event is triggered during the testing process, the exception handling process will be automatically executed according to the exception event type.

[0139] The abnormal events include at least one of the following:

[0140] Automatic login configuration and automatic startup item installation failed; parameter files in the parameter repository were corrupted or parameter file verification failed; session log writing was abnormal; test process interruption command was received.

[0141] In one possible implementation, when abnormal events include failures in automatic login configuration and automatic startup item installation, the corresponding exception handling process can be: record the error and stop the continued running path to avoid entering an uncertain state.

[0142] In another possible implementation, when an abnormal event includes a corrupted parameter file in the parameter repository or a parameter file validation failure, the corresponding exception handling process can be: attempt to repair it using lock and format validation; if repair fails, stop and prompt for manual intervention.

[0143] In another possible implementation, when the abnormal event includes a session log write exception, the corresponding exception handling process can be: downgrade to a minimal log while retaining critical events; and terminate the process early if necessary.

[0144] In another possible implementation, when the abnormal event includes receiving a test process interruption command, the corresponding abnormal handling process can be: immediately enter the automatic login configuration and automatic startup item uninstallation configuration, restore the system automatic login configuration, clear the temporarily stored files, and output the test results, prioritizing the completion of environment restoration and credential cleanup.

[0145] Furthermore, in this embodiment, since recovery after triggering the system restart process does not require manual execution of subsequent triggering operations, multiple devices can execute long tests in parallel. A centralized orchestrator can be used, with control issued and devices continuing locally; message queues / HTTP callbacks trigger the next round; templated batch parameters generate independent sessions and paths for each device, simultaneously executing the test process; and the timing control between the two test loops can be achieved by: systemd.timer / cron replacing internal sleep; and an external timing service periodically triggering checks to advance one round.

[0146] The power cycle test process in the embodiments of this application will be illustrated below with specific examples.

[0147] Specifically, please refer to Figure 2 , Figure 2 This is a schematic diagram of the power cycle test process provided in an embodiment of this application, as shown below. Figure 2 As shown, the test program starts, performs authentication / administration permission configuration operations, checks if it is in continuation mode, and if not, initializes logs, creates and binds the test program identifier, initializes the parameter repository, and creates and writes test parameters; installs automatic login configuration and automatic startup items; loads the configuration policy from the configuration file, parses the preprocessing or action sequence; performs loop control, executes the preprocessing sequence and action sequence, and checks if the current round triggers a system restart; if the current round triggers a system restart, it exits the process normally and lets the system restart; if the current round does not trigger a system restart, it checks if the preset number of loops has been reached; if the preset number of loops has not been reached, it continues loop control and subsequent sequence execution; if the preset number of loops has been reached, it performs a safe cleanup operation and outputs the results and archives the logs. If the current mode is continuation mode, initialize the logs and bind them to the same test program identifier. Restore the context from the parameter repository, load the strategy, and continue executing the remaining preprocessing or action sequences. Perform loop control, execute the preprocessing sequence and action sequence, and check if the current round triggers a system restart. If the current round triggers a system restart, exit the process normally and let the system restart. If the current round does not trigger a system restart, check if the preset number of loops has been reached. If the preset number of loops has not been reached, continue loop control and subsequent sequence execution. If the preset number of loops has been reached, perform a safe cleanup operation, output the results, and archive the logs.

[0148] In one possible implementation, the above power cycle test procedure can be executed within a power cycle test system. For details, please refer to [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of the power cycle testing system provided in the embodiments of this application, as shown below. Figure 3As shown, the power cycle test system includes a main control module 310, a strategy module 320, a state persistence module 330, a log module 340, an authentication and tool module 350, an automatic login module 360, and a self-starting module 370 (synthetic relay configuration module). Specifically, the main control module 310 parses command-line parameters (mode, total number of rounds, delay, and continuation flag), generates or binds a session identifier run_id; initializes the session log; initializes / loads the parameter repository; executes strategy steps sequentially in the loop; handles termination signals; and triggers unified termination at the end. The automatic login module 360 ​​configures / verifies the automatic login of the display manager, enabling the system to enter the desktop session without manual intervention after restarting; and restores the default settings at the end. The startup module 370 writes a startup item to the desktop startup directory, with Exec pointing to the "resume mode (-re)" of the same program; it unloads the startup item when it ends; the state persistence module 330 uses a file-lock-protected parameter repository to centrally persist fields such as mode, loop, delay, current_loop, start_time, and last_finish_time; it provides atomic write-back and recovery capabilities to ensure consistency of breakpoint resumption. For example, the state persistence module 330 can read and write INI storage files; the log module 340 archives data to the session log run_id, using run_id as the starting point. Binds to a complete test session; employs a rolling strategy with configurable capacity and number of copies; writes the same session log after restart, recording the start / end, return code, and key events of each round; the strategy module 320 is used to read and parse the YAML configuration file, reading the pre (preprocessing) and action (action) sequences of the current mode from the YAML; assembles and executes them sequentially at runtime; supports customization by project / model without changing the main control logic; the authorization and authentication tool 350 selects the authorization path according to the on-site environment in the first round; only briefly holds credentials at necessary stages and cleans them up uniformly; provides basic capabilities such as command execution, INI read / write, countdown, and output formatting.

[0149] For further details, please refer to Figure 4 , Figure 4 This is a schematic diagram of the test process of the power cycle test system provided in the embodiments of this application, as shown below. Figure 4As shown, the main control module in the test program binds run_id (test program identifier) ​​to enable session logging and synchronizes the session log information to the log module; it establishes and writes test parameters and synchronizes them to the state persistence module; it installs automatic login and auto-start and synchronizes them to the relay configuration module; the main control module's actions may trigger a restart, and the restart status is synchronized to the operating system or login and interface; if the restart causes the process to exit normally, the exit status is synchronized to the main control module in the test program; after the operating system or login and interface restart, it automatically logs into the desktop and synchronizes the information about automatically logging into the desktop after the operating system or login and interface restarts to the relay configuration module; the relay configuration module automatically starts the program and synchronizes it to the main control module in the test program; the main control module in the test program reads and restores the context from the state persistence module, continues writing the session log with the same run_id, and synchronizes the continued writing session log information to the log module; the main control module in the test program continues to execute subsequent rounds until completion, and synchronizes the completion information to the operating system or login and interface.

[0150] The above power cycle test process can eliminate restart breakpoints and support long-term unattended testing; controlled parameter repository and atomic write-back can avoid incorrect / missed cycles; session-based logs can be continued to be written across restarts and archived on a rolling basis, which is convenient for location and review; policy configuration drives preprocessing and action pipelines to quickly adapt to different scenarios; and environment rollback and credential cleanup can be performed at the end to avoid leaving residual risk configurations.

[0151] Furthermore, by implementing an "automatic login + auto-start" environment relay in the first round of installation, the system automatically enters the desktop and launches the same program's continuation mode after a restart, eliminating the need for manual intervention during testing. For long-cycle tests involving numerous restarts, manual operation is reduced from "once per round" to "once on the first run," significantly shortening the total execution time and reducing human error, thereby improving testing efficiency. A parameter repository protected by file locks stores key fields such as mode, loop, delay, and current_loop, performing atomic write-back and verification before and after triggering key actions in each round. Even if a restart occurs in any round, execution can continue from the precise round completed last time, avoiding missed or duplicate tests. A unique run_id session is generated for each test, using a rolling strategy to record rounds, actions, return codes, and timestamps in segments. After a restart, the same session file is written again, forming a complete timeline and evidence chain, facilitating the identification of "which specific round and which specific action." Preprocessing and actions are extracted from the code and configured in YAML, with the main controller assembling and executing them at runtime. Switching between REBOOT / STR / SD modes or customizing for a project only requires editing configuration files, without modifying the main control logic or large-scale regression testing, reducing delivery and maintenance costs. Upon test completion or abnormal termination, startup items are uniformly uninstalled, automatic login configuration is restored, and temporary credentials and intermediate files are cleaned up. Test modifications to the system are strictly limited to a controllable lifecycle to avoid legacy configurations affecting subsequent production or office environments. The authorization and tool modules self-check on-site capabilities and select usable paths. Failure branches and degradation strategies are provided for critical steps and recorded in the session log. Initialization success rate is improved; even if some capabilities are limited, exit or continue in a controlled manner, avoiding "silent failures." Since recovery after a restart requires no manual intervention, multiple devices can execute long-term tests in parallel. In a scenario with M devices and N rounds per device, manual intervention is reduced from M×N times to a single initialization and acceptance test at the device level, improving test resource utilization. The parameter repository and session log synchronously record the start and end status and action results of each round, with consistent numbering and continuity across restarts. Consistent process records can be obtained repeatedly under the same configuration, which facilitates subsequent review, quality audit, and compliance documentation.

[0152] The power cycle testing method provided in this application parses the test command and determines whether the current test process is in a continuation mode. If the current test process is in a continuation mode, it logs into the desktop environment through automatic login configuration and starts the target test program before restarting according to the test program identifier in the test command through the automatic startup item. It restores the test parameters recorded in the parameter repository and continues to execute preprocessing and / or action sequences, saving the execution data and the end time of this test program to the session log corresponding to the target test program before restarting. If the number of loops of the test program reaches the preset number of loops, the test process ends and the test results are output. Thus, during the test continuation process, the target test program before restarting is automatically started through the configured automatic login configuration and automatic startup item, restoring the test parameters recorded in the parameter repository to continue execution and interrupting the preprocessing and / or action sequences, and saving the execution results to the same session log before restarting. This automatic login and automatic restoration of test parameters to continue the test process can improve the efficiency and accuracy of power cycle testing.

[0153] Based on the same inventive concept, this application also provides a power cycle test device corresponding to the power cycle test method. Since the principle of the device in this application is similar to the power cycle test method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0154] Please see Figure 5 , Figure 5 This is a schematic diagram of a power cycle testing device provided in an embodiment of this application. Figure 5 As shown, the power cycle test apparatus 500 includes:

[0155] The mode determination module 510 is used to parse test commands and determine whether the current test process is in continuation mode.

[0156] The test program restart module 520 is used to log in to the desktop environment through automatic login configuration if the current test process is in continue mode, and start the target test program that was restarted before the test project was restarted through automatic startup item according to the test program identifier in the test command; wherein, the automatic login configuration and the automatic startup item are installed when the test program is first started, and a parameter repository is established and a test program identifier is generated when the test program is first started;

[0157] The test data storage module 530 is used to restore the test parameters recorded in the parameter warehouse and continue to execute preprocessing and / or action sequences, and save the execution data and the end time of this test program to the session log corresponding to the target test program before the restart;

[0158] The test result output module 540 is used to end the test process and output the test result if the number of loops in the test program reaches the preset number of loops.

[0159] In one possible implementation, the power cycle test apparatus 500 further includes a test program initial processing module (not shown in the figure), which is used for:

[0160] If the current test process is not in continue mode, generate a test program identifier based on the test parameters obtained from parsing the test command;

[0161] Initialize the session log and establish the parameter repository, then write the test parameters into the parameter repository;

[0162] Install automatic login configuration and automatic startup items;

[0163] Read the preprocessing and / or action sequence from the configuration file, execute the preprocessing and / or action sequence, and save the execution data and the end time of this test program to the session log;

[0164] Check if the system restart process has been triggered.

[0165] If the system restart process is triggered, the current test process will be exited and the test will be resumed.

[0166] In one possible implementation, the power cycle testing device 500 further includes a first cycle count determination module (not shown in the figure), which is used for:

[0167] If the system restart process is not triggered, check whether the current test program has reached the preset number of loops.

[0168] If the test program reaches the preset number of loops, the test process ends and the test results are output.

[0169] If the number of loops in the test program does not reach the preset number of loops, record the number of loops, and continue to read and execute preprocessing and / or action sequences from the configuration file until the number of loops in the test program reaches the preset number of loops, then end the test process and output the test results.

[0170] In one possible implementation, when the test result output module 540 is used to terminate the test process and output the test result if the number of loops in the test program reaches a preset number of loops, the test result output module 540 is used to:

[0171] Increment the current loop count by one, and check if the current loop count of the test program has reached the preset loop count;

[0172] If the test program reaches the preset number of loops, the test process ends and the test results are output.

[0173] In one possible implementation, the power cycle testing device 500 further includes a second cycle number determination module (not shown in the figure), which is used for:

[0174] If the number of loops in the test program does not reach the preset number of loops, record the number of loops, and continue to read and execute preprocessing and / or action sequences from the configuration file until the number of loops in the test program reaches the preset number of loops, then end the test process and output the test results.

[0175] In one possible implementation, the power cycle test apparatus 500 further includes a parameter persistence module (not shown in the figure), the parameter persistence module being used for:

[0176] The test parameters in the parameter repository are centrally persisted.

[0177] In one possible implementation, when the test result output module 540 is used to terminate the test process and output the test result if the number of loops in the test program reaches a preset number of loops, the test result output module 540 is used to:

[0178] If the test program reaches the preset number of loops, uninstall the configured automatic login settings and automatic startup items, restore the system's automatic login settings, clear temporary files, and then output the test results.

[0179] In one possible implementation, the power cycle test apparatus 500 further includes an anomaly handling module (not shown in the figure), the anomaly handling module being used for:

[0180] If an abnormal event is triggered during the testing process, the exception handling process will be automatically executed according to the type of the abnormal event.

[0181] The abnormal events include at least one of the following:

[0182] Automatic login configuration and automatic startup item installation failed; parameter files in the parameter repository were corrupted or parameter file verification failed; session log writing was abnormal; test process interruption command was received.

[0183] The power cycle testing device provided in this application parses test commands and determines whether the current test process is in a continuation mode. If the current test process is in a continuation mode, it logs into the desktop environment through automatic login configuration and starts the target test program that was restarted before restarting, according to the test program identifier in the test command, through the automatic startup item. The automatic login configuration and the automatic startup item are installed when the test program is first started, and a parameter repository is established and a test program identifier is generated during the first start of the test program. The test parameters recorded in the parameter repository are restored, and the preprocessing and / or action sequence continues to be executed. The execution data and the end time of this test program are saved to the session log corresponding to the target test program before restarting. If the number of loops of the test program reaches the preset number of loops, the test process ends and the test results are output. Thus, during the test continuation process, the target test program that was restarted before restarting is automatically started through the configured automatic login configuration and automatic startup item, the test parameters recorded in the parameter repository are restored, and the preprocessing and / or action sequence that was interrupted is executed. The execution results are saved to the same session log before restarting. This automatic login and automatic restoration of test parameters to continue the test process can improve the efficiency and accuracy of power cycle testing.

[0184] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 600 includes a processor 610, a memory 620, and a bus 630.

[0185] The memory 620 stores machine-readable instructions executable by the processor 610. When the electronic device 600 is running, the processor 610 and the memory 620 communicate via the bus 630. When the machine-readable instructions are executed by the processor 610, they can perform the operations described above. Figure 1 The steps of the power supply cycle test method in the illustrated method embodiment can be found in the method embodiment for specific implementation, and will not be repeated here.

[0186] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the power supply cycle test method in the illustrated method embodiment can be found in the method embodiment for specific implementation, and will not be repeated here.

[0187] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0188] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0189] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0190] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0191] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0192] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A power supply cycle test method, characterized in that, The power supply cycling test method includes: Parse the test commands to determine whether the current test process is in continue mode; If the current test process is in continue mode, log in to the desktop environment through the automatic login configuration, and start the test project through the automatic startup item to restart the previous target test program according to the test program identifier in the test command; wherein, the automatic login configuration and the automatic startup item are installed when the test program is first started, and a parameter repository is established and a test program identifier is generated when the test program is first started; Restore the test parameters recorded in the parameter repository, and continue to execute preprocessing and / or action sequences. Save the execution data and the end time of this test program to the session log corresponding to the target test program before the restart. If the test program reaches the preset number of loops, the test process ends and the test results are output.

2. The power supply cycle test method according to claim 1, characterized in that, After parsing the test command and determining whether the current test process is in continuation mode, the power cycle test method further includes: If the current test process is not in continue mode, generate a test program identifier based on the test parameters obtained from parsing the test command; Initialize the session log and establish the parameter repository, then write the test parameters into the parameter repository; Install automatic login configuration and automatic startup items; Read the preprocessing and / or action sequence from the configuration file, execute the preprocessing and / or action sequence, and save the execution data and the end time of this test program to the session log; Check if the system restart process has been triggered. If the system restart process is triggered, the current test process will be exited and the test will be resumed.

3. The power supply cycle test method according to claim 2, characterized in that, After detecting whether the system restart process has been triggered, the power cycle test method further includes: If the system restart process is not triggered, check whether the current test program has reached the preset number of loops. If the test program reaches the preset number of loops, the test process ends and the test results are output. If the number of loops in the test program does not reach the preset number of loops, record the number of loops, and continue to read and execute preprocessing and / or action sequences from the configuration file until the number of loops in the test program reaches the preset number of loops, then end the test process and output the test results.

4. The power supply cycle test method according to claim 2, characterized in that, If the number of iterations in the test program reaches the preset number of iterations, the test process ends and the test results are output, including: Increment the current loop count by one, and check if the current loop count of the test program has reached the preset loop count; If the test program reaches the preset number of loops, the test process ends and the test results are output. The power cycle test method further includes: If the number of loops in the test program does not reach the preset number of loops, record the number of loops, and continue to read and execute preprocessing and / or action sequences from the configuration file until the number of loops in the test program reaches the preset number of loops, then end the test process and output the test results.

5. The power supply cycle test method according to claim 2, characterized in that, After initializing the session log, establishing the parameter repository, and writing the test parameters into the parameter repository, the power cycle test method further includes: The test parameters in the parameter repository are centrally persisted.

6. The power supply cycle test method according to claim 2, characterized in that, If the number of iterations in the test program reaches the preset number of iterations, the test process ends and the test results are output, including: If the test program reaches the preset number of loops, uninstall the configured automatic login settings and automatic startup items, restore the system's automatic login settings, clear temporary files, and then output the test results.

7. The power supply cycle test method according to claim 1, characterized in that, The power cycle test method further includes: If an abnormal event is triggered during the testing process, the exception handling process will be automatically executed according to the type of the abnormal event. The abnormal events include at least one of the following: Automatic login configuration and automatic startup item installation failed; parameter files in the parameter repository were corrupted or parameter file verification failed; session log writing was abnormal; test process interruption command was received.

8. A power supply cycle testing device, characterized in that, The power cycle testing device includes: The mode determination module is used to parse test commands and determine whether the current test process is in continue mode; The test program restart module is used to log in to the desktop environment through automatic login configuration if the current test process is in continue mode, and start the target test program that was restarted before by starting the test project through automatic startup item according to the test program identifier in the test command; wherein, the automatic login configuration and the automatic startup item are installed when the test program is first started, and a parameter repository is established and a test program identifier is generated when the test program is first started; The test data saving module is used to restore the test parameters recorded in the parameter warehouse and continue to execute preprocessing and / or action sequences, and save the execution data and the end time of this test program to the session log corresponding to the target test program before the restart; The test result output module is used to end the test process and output the test result if the number of loops in the test program reaches the preset number of loops.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the power cycle test method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the power cycle test method according to any one of claims 1 to 7.

Images