Power-off test method and system based on Jenkins and secure CRT, computer device and medium

Abstract

The application relates to the technical field of computers, in particular to a power-off test method and system based on Jenkins and SecureCRT, computer equipment and a medium; the method comprises the following steps: in response to configuring power-off test parameters for a test task through a Jenkins platform, triggering the test task and distributing the test task to a test control host; establishing a connection with a device under test and a programmable power supply according to the power-off test parameters; executing an automatic script through a SecureCRT terminal on the test control host, controlling the programmable power supply to perform power-on and power-off operations on the device under test; in the process, monitoring the running state of the device under test, and based on the monitoring result, verifying the state of the device under test by applying a string matching rule, and generating a power-off test result. In this way, the technical problem that the existing automatic power-off test technology is difficult to synchronize with the internal state of the device is solved, and the automation level, repeatability and fusion degree with a modern research and development system of the test process are improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a power-down testing method, system, computer equipment, and medium based on Jenkins and SecureCRT. Background Technology

[0002] As electronic devices become increasingly complex, their ability to withstand unexpected power outages under different operating conditions has become a key indicator of product reliability. Most existing automated power-down testing solutions rely on a combination of customized host computer software and programmable power supplies, requiring the development of dedicated test control programs. This results in long development cycles, high costs, and difficulty in adapting to different device platforms. Furthermore, some solutions employ complex hardware triggering circuits, such as data acquisition cards, signal generators, or dedicated trigger boards, to precisely control the timing of power outages, but this increases system complexity and cost. Other solutions are based on device-specific test fixtures, resulting in low versatility and difficulty in quickly migrating to new projects. These solutions share common drawbacks: high system coupling, poor flexibility, large upfront investment, and difficulty in achieving deep interaction and precise synchronization with the device's internal software state.

[0003] In the field of automated test script generation, existing technologies have established a certain foundation. Prior art document 1 (application publication number CN111181790A) discloses a method for rapid generation of automated test scripts, which generates scripts through test configuration files to control signal sources to send test signals to the device under test (DUT) or process test results. This method can reduce script development time, but it mainly focuses on the initialization and execution of the test process and does not fully consider the high-precision requirements for synchronization with the internal state of the device during power-down testing. Specifically, existing technologies have two prominent problems: firstly, they rely on fixed hardware architectures or customized software, lacking deep integration with continuous integration platforms, and cannot achieve parameterized scheduling and centralized management of test tasks; secondly, they are difficult to integrate with external power supply devices using the scripting capabilities of general-purpose terminal tools, resulting in insufficient test flexibility and an inability to adapt to rapid switching in multi-device scenarios.

[0004] At the test execution level, engineers typically need to configure the environment, trigger loads, and monitor the status via interfaces such as serial ports or SSH (Secure Shell). However, this process is often manual or integrated into complex software, lacking scalability. Although the scripting capabilities of terminal software such as SecureCRT provide a foundation for automation, existing technologies have not yet resolved the coordination issues with power control systems and integration platforms, resulting in limitations in the accuracy and efficiency of power-down testing. These intertwined problems make it difficult for existing solutions to balance test cost and reliability verification requirements in highly complex electronic device environments. Therefore, existing automated power-down testing technologies suffer from the technical challenge of synchronizing with the internal state of the device. Summary of the Invention

[0005] To address the aforementioned shortcomings or drawbacks, this invention provides a power-down testing method, system, computer equipment, and medium based on Jenkins and SecureCRT, which can solve the technical problem that existing automated power-down testing technologies are difficult to synchronize with the internal state of the device.

[0006] This invention provides a power failure testing method based on Jenkins and SecureCRT, including: In response to configuring power-down test parameters for test tasks via the Jenkins platform, the test task corresponding to the power-down test parameters is triggered and sent to the test control host.

[0007] The test control host establishes a connection with the device under test and the programmable power supply based on the power-down test parameters.

[0008] The SecureCRT terminal on the test control host executes a preset automated script to control the programmable power supply to perform power-on and power-off operations on the device under test.

[0009] During the power-on and power-off operations, the operating status of the device under test is monitored through the SecureCRT terminal. Based on the monitoring results, string matching rules are applied to verify the status of the device under test and generate power-off test results.

[0010] According to a second aspect, this invention provides a power failure testing system based on Jenkins and SecureCRT, comprising: The test task distribution module is used to trigger the test task corresponding to the power failure test parameters when configuring power failure test parameters for the test task through the Jenkins platform, and distribute the test task to the test control host.

[0011] The power connection execution module is used to establish a connection with the device under test and the programmable power supply based on the power-down test parameters through the test control host.

[0012] The power-on / off operation execution module is used to execute preset automated scripts through the SecureCRT terminal on the test control host to control the programmable power supply to perform power-on and power-off operations on the device under test.

[0013] The power-down test result generation module is used to monitor the operating status of the device under test through the SecureCRT terminal during the power-on and power-off operations, and based on the monitoring results, to verify the status of the device under test by applying string matching rules and generate power-down test results.

[0014] According to a third aspect, the present invention provides a computer device comprising: At least one processor; and a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which enables the at least one processor to perform any of the power-down testing methods based on Jenkins and SecureCRT in the embodiments of the present invention.

[0015] According to another aspect of the present invention, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute any of the power-down testing methods based on Jenkins and SecureCRT in the embodiments of the present invention.

[0016] The present invention provides a power-down testing method based on Jenkins and SecureCRT. This method is achieved through four core steps: parameterized task scheduling, standardized device connection, scripted power control, and automated status verification. Specifically, by configuring power-down test parameters for test tasks through the Jenkins platform and triggering their deployment, centralized configuration and automated scheduling of test tasks are achieved. The test control host establishes connections with the device under test and the programmable power supply based on the parameters, achieving standardized and programmable access to hardware interfaces in the test environment. The SecureCRT terminal executes preset automated scripts to control the power supply to perform power-on and power-off operations, achieving precise and repeatable application of test stimuli. By monitoring the device status during operation and applying string matching rules for verification and result generation, fully automated monitoring and judgment of the test process are achieved.

[0017] In this technical solution, the present invention addresses the problems of high coupling and poor flexibility in the testing systems described in the background technology by introducing the Jenkins platform as a unified parameterized task scheduling entry point. This separates the test logic from the test data, enabling test cases to be quickly generated and switched through configuration parameters. This solves the defects of existing technologies, which rely on customized software and dedicated tooling, resulting in long development cycles and high migration costs. Addressing the difficulty of deep interaction and precise synchronization with the internal software state of devices in existing solutions, the invention integrates the script control capabilities and programmable power supply of the SecureCRT terminal, achieving precise status monitoring and synchronous trigger control based on the device's runtime output logs. This overcomes the shortcomings of traditional manual operation or simple hardware triggering, which cannot accurately control power-down timing under complex software logic. Finally, addressing the issues of low automation and lack of integration with continuous integration systems in the testing process, the invention constructs a fully automated process from task scheduling and script execution to result generation, outputting structured test results. This provides direct support for incorporating test tasks into the Continuous Integration (CI) pipeline, filling the technical gaps in existing solutions that are closed and isolated, unable to achieve remote triggering and centralized management of test tasks. Therefore, the technical solution of the present invention solves the technical problem that existing automated power-down testing technologies are difficult to synchronize with the internal state of the equipment, and improves the automation level, repeatability and integration with the modern R&D system of the testing process. Attached Figure Description

[0018] Figure 1 This is a flowchart of a power failure testing method based on Jenkins and SecureCRT according to an embodiment of the present invention; Figure 2 This diagram illustrates the deployment and data interaction architecture of an automated power failure testing system according to another embodiment of the present invention. Figure 3 This diagram illustrates the execution flow and logic control of an automated power-down testing method according to another embodiment of the present invention. Figure 4 This is a schematic diagram of the structure of a power failure testing system based on Jenkins and SecureCRT according to an embodiment of the present invention; Figure 5 This is a block diagram of a computer device for implementing embodiments of the present invention. Detailed Implementation

[0019] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0020] During the development of this invention, the inventors, through extensive experiments and data analysis, discovered an intrinsic correlation between the specific state of the internal software operation of a device and the success probability of achieving highly reliable and repeatable power-down tests: only when the power-down operation is precisely synchronized with the critical business logic state within the device can deep-seated potential defects be effectively exposed, and traditional methods based on fixed delays or external hardware signal triggers cannot capture this correlation. Based on this relationship, the inventors innovatively proposed this technical solution, utilizing the centralized scheduling and parameterized management capabilities of a continuous integration (CI) platform, through the script interface of a general-purpose terminal simulation software, combined with a device status monitoring mechanism based on string matching, and precise control of a programmable power supply, thereby achieving high-precision automated power-down testing deeply bound to the internal software state of the device, embodying the core concepts of "precise triggering of state awareness" and "automated closed-loop process."

[0021] Specifically, through comparative experiments, the invention team discovered that traditional power-down testing methods combining customized host computer software with programmable power supplies suffer from technical drawbacks such as high system coupling, poor flexibility, and difficulty in accurately synchronizing with the internal operating state of the device. The test logic is hard-coded in the software, requiring redevelopment when switching test scenarios, and the triggering timing cannot be precisely correlated with key operational nodes within the device. However, the integrated method based on Jenkins and SecureCRT proposed in this invention improves the efficiency of test environment setup and the reusability of test cases. Jenkins' parameterized build function decouples test logic from test data, enabling remote one-click triggering and centralized management of test tasks. SecureCRT scripts monitor device command-line output and wait for key status indicators, ensuring that power-down operations are triggered instantaneously within milliseconds when the device executes specific business logic. Automatic verification of device return information based on string matching rules enables unattended judgment and structured output of test results, thereby improving the accuracy, automation level, and adaptability to complex devices and changing scenarios in power-down testing.

[0022] Therefore, this invention provides a power-down testing method based on Jenkins and SecureCRT, applicable to automated testing and continuous integration or continuous deployment systems (hereinafter referred to as "the system"). This system can run in a centralized or distributed manner within a hardware network environment consisting of a Jenkins server, at least one test control host, a programmable power supply, and the device under test (DUT) to perform automated power-down reliability verification of various electronic devices. Specifically, this system can be deployed in various hardware environments, including but not limited to: dedicated test laboratory server clusters, physical test industrial control computers running Windows or Linux operating systems, and virtualized computing platforms supporting Jenkins Agent nodes. This flexible deployment architecture allows the system to meet both the needs of large-scale, high-concurrency standardized production line testing and the requirements of rapid iterative verification of small batches and multiple device models during the R&D phase.

[0023] like Figure 1 As shown, the method may include: Step S110: In response to configuring power failure test parameters for the test task through the Jenkins platform, trigger the test task corresponding to the power failure test parameters and send the test task to the test control host.

[0024] Among them, power failure test parameters refer to the set of variables defined by the parameterized build function of the Jenkins platform to control a complete power failure test process; the test control host refers to a physical or virtual computer with the Jenkins Agent and SecureCRT software installed, which is used to receive and execute test instructions from the Jenkins server.

[0025] Furthermore, Jenkins is an open-source continuous integration / continuous delivery (CI / CD) server used to automate the build, testing, and deployment phases of software development. It supports high scalability through its plugin ecosystem, enabling the scheduling and coordination of various automated tasks (such as code compilation, test execution, and packaging / deployment), and provides rich parametric build, pipeline orchestration, and task monitoring capabilities. SecureCRT is a commercial terminal emulation software primarily used for remotely accessing and managing servers, network devices, and other embedded systems via secure network connections (such as SSH and Telnet) or serial connections. It provides a graphical interface where users can open multiple session windows and interact with remote devices through a command-line interface to perform configuration, debugging, and monitoring operations. Its core features include robust session management, advanced encryption to ensure secure connections, and deep support for automation scripts (such as VBScript and Python), allowing users to record and replay operation sequences to achieve complex automation tasks.

[0026] Specifically, the system can complete the parameterized configuration by creating a "freestyle" software project on Jenkins and checking "parameterized build process" on its configuration page to add a string parameter plugin to define various test parameters.

[0027] For example, the system can be configured with the following parameters for a power-down test of a specific router model: the running node parameter is "Lab-PC-01", the power control parameter is "COM3,9600,8,N,1", the connection parameter for the device under test is "192.168.1.1,22,admin,password", and the anomaly detection rule parameter is "Login successful". After configuration, the user clicks the "Build Now" button, and the Jenkins platform triggers and generates a task instance containing the above parameters, distributing the task to the test control host named "Lab-PC-01" through its built-in distributed build mechanism.

[0028] Step S120: Establish a connection with the device under test and the programmable power supply through the test control host according to the power-down test parameters.

[0029] Among them, serial communication session refers to a stable data link established by the test control host and the programmable power supply through its serial communication port for sending ASCII (American Standard Code for Information Interchange) format control commands; command line communication session refers to a remote control connection established by the test control host and the device under test through a network or serial port based on text command interaction, such as SSH session or Telnet session.

[0030] Specifically, the system can use an automated script running on the test control host to call the serial port application programming interface (API) provided by the operating system to open a specified serial port (such as COM3) and set attributes such as baud rate according to parameters, thereby establishing a communication session with the programmable power supply. At the same time, the script can call the session connection function of SecureCRT and use the SSH protocol and the IP address, username and password provided in the parameters to establish a command line communication session with the device under test.

[0031] For example, the system connects to serial port COM3 using the crt.Session.Connect method in VBScript (Visual Basic Scripting Edition) based on the power control parameters "COM3,9600,8,N,1"; at the same time, it creates a new SSH2 session in SecureCRT and connects to the device under test based on the connection parameters "192.168.1.1,22,admin,password".

[0032] Step S130: Execute a preset automation script through the SecureCRT terminal on the test control host to control the programmable power supply to perform power-on and power-off operations on the device under test.

[0033] Among them, automation scripts refer to program files written in scripting languages ​​such as VBScript that can automatically execute a series of terminal operations and device control instructions in the SecureCRT software environment; control command sequences refer to a set of ASCII instructions organized in a specific logical order and sent to the programmable power supply for precise control of the opening and closing of its output channels.

[0034] Specifically, the system can load and run a pre-written VBScript script through SecureCRT's script engine. The script first sends a programmable power-on command (such as "OUTPUTON") to the established serial communication session to power on the device under test (DUT). Subsequently, the script monitors the output of the DUT in the command-line communication session, and upon detecting a preset key status string, immediately sends a power-off command (such as "OUTPUT OFF") to the serial communication session to achieve precise power-off.

[0035] For example, the system executes a script that first sends an "OUTPUT ON" command via the serial port, and then sends an "OUTPUT OFF" command after waiting for 30 seconds. In a more preferred embodiment, after sending the "OUTPUT ON" command, the script continuously reads the output of the SSH session. When it detects the string "Firmware initialization complete" in the device log, it immediately triggers the sending of the "OUTPUT OFF" command, thereby achieving precise synchronization with the device's internal boot process.

[0036] Step S140: During the power-on and power-off operations, the operating status of the device under test is monitored through the SecureCRT terminal, and based on the monitoring results, the status of the device under test is verified by applying string matching rules, and power-off test results are generated.

[0037] Among them, string matching rules refer to the predefined logical rules in the automation script used to search for specific keywords or patterns in the output text of the device to determine whether the device is operating normally; power failure test results refer to the formatted record of the execution process of one or more power failure tests and the verification results of the device status, which usually includes test time, operation sequence, status matching status and final conclusion.

[0038] Specifically, the system can continuously monitor the text appearing on the SecureCRT terminal screen using the `crt.Screen.WaitForString` function in the automation script. After the device is powered on again, the script waits and attempts to match a string indicating a successful system startup (such as "login:"). If a match is successful, the power-on is considered successful. The script can also send a query command (such as "cat / proc / version") to the device after startup and apply string matching rules (such as checking if it contains the expected kernel version number) to the returned information to verify system integrity. Finally, the script records the triggering time of each power-on / power-off cycle, the success or failure of the status match, and other information to a log file.

[0039] For example, in one test loop, after triggering a power outage, the script waits 10 seconds before sending the power-on command again. Then, it uses the WaitForString function to wait for the string "Boot completed" to appear, with a timeout of 60 seconds. If a match is successful within 60 seconds, "Power-on verification: Passed" is recorded in the result log; otherwise, "Power-on verification: Failed - Timeout" is recorded. After the test, the script generates a text file named "Power_Cycle_Test_20231027.log" as the power-down test result for that test.

[0040] In other embodiments, such as Figure 2 This illustration showcases the deployment and data interaction architecture of an automated power-down testing system in a specific embodiment of the present invention. This system architecture clearly embodies the core design principles of "centralized scheduling, distributed execution, and synchronized state triggering." In this architecture, the Jenkins server acts as a unified control node and task scheduling center, responsible for receiving user configurations, managing test task queues, and distributing parameterized batch commands to designated test control hosts through its distributed build function. The test control host, as a local execution node, carries the core control logic of SecureCRT and its automated test scripts. Based on the received parameters, the host simultaneously establishes connections and executes operations in two directions: on one hand, it sends control commands (ON / OFF) to the programmable power supply via serial port (COM) to directly control the on / off state of its internal power control module, thereby achieving power supply management for the device under test; on the other hand, it establishes a command-line session with the device under test via serial port or Secure Shell Protocol (SSH), using this session to monitor the device status in real time and send commands, interacting with the device's internal business logic and command-line interface. This architecture ensures that the issuance of power control commands and the monitoring of the internal status of the device are closely coordinated on the same control host, providing a physical basis for achieving millisecond-level precise power-down triggering based on the device software running status.

[0041] In other embodiments, such as Figure 3This diagram illustrates the execution flow and logic control details of an automated power-down testing method in a specific embodiment of the present invention. The flowchart, presented as a sequence of steps, intuitively reveals the complete automated closed loop from task triggering to loop termination. The process begins with the Jenkins interface receiving configuration parameters and remotely triggering the task on the test execution host, corresponding to the parameterized task scheduling and distribution steps in the claims. Subsequently, the process enters the core control phase dominated by SecureCRT starting and loading the VBS test script. This phase first executes script initialization, device connection, and power initialization, completing the technical actions corresponding to establishing a communication connection as described in the claims. The core loop of the process embodies an iterative process of "status monitoring - precise triggering - result recording." After configuring the test scenario to guide the device into a specific situation, the process monitors the information returned by the device to determine whether a critical state has been captured, achieving real-time perception of the device's internal operating status. This aligns with the core idea of ​​using string matching rules for verification in the claims. If a critical state is captured, the process sends a power-down command, achieving precise triggering based on the device's internal logic; if not captured, it enters the failure recording branch and determines whether the failure recording is full, thus achieving fault tolerance and loop control. After sending the power-off command, the process initiates a new test loop through script delay and the sending of the power-on command, until the conditions for whether the test count has been reached or manual intervention is required to stop the test are met, ultimately entering the test completion state. This flowchart clearly illustrates how this invention integrates discrete configuration, connection, control, and verification steps into an autonomous, state-judgment, and loop-control-capable organic whole, demonstrating the specific process by which this solution achieves high-precision, highly automated power-down testing.

[0042] Therefore, according to the above implementation method, the system achieves its functionality through four core steps: parameterized task scheduling, standardized device connection, scripted power control, and automated status verification. Specifically, by configuring power-down test parameters for test tasks via the Jenkins platform and triggering their distribution, centralized configuration and automated scheduling of test tasks are achieved; by establishing connections between the test control host and the device under test and the programmable power supply based on the parameters, standardized and programmable access to hardware interfaces in the test environment is achieved; by executing preset automated scripts through the SecureCRT terminal to control the power supply to perform power-on and power-off operations, precise and repeatable application of test stimuli is achieved; and by monitoring the device status during operation and applying string matching rules for verification and result generation, fully automated monitoring and judgment of the test process are achieved.

[0043] Specifically, in the technical solution of this embodiment, addressing the issues of high coupling and poor flexibility in the testing system described in the background technology, the Jenkins platform is introduced as a unified parameterized task scheduling entry point. This separates the test logic from the test data, enabling test cases to be quickly generated and switched through configuration parameters. This solves the shortcomings of existing technologies, which rely on customized software and dedicated tooling, resulting in long development cycles and high migration costs. Addressing the difficulty of existing solutions in achieving deep interaction and precise synchronization with the internal software state of the device, the script control capabilities and programmable power supply of the SecureCRT terminal are integrated to achieve precise status monitoring and synchronous trigger control based on the device's runtime output logs. This solves the drawbacks of traditional manual operation or simple hardware triggering, which cannot accurately control power-down timing under complex software logic. Addressing the issues of low automation in the testing process and lack of integration with the continuous integration system, a fully automated process from task scheduling and script execution to result generation is constructed, outputting structured test results. This provides direct support for incorporating test tasks into the continuous integration (CI) pipeline, filling the technical gap of existing solutions being closed and isolated, unable to achieve remote triggering and centralized management of test tasks. Therefore, the technical solution of this embodiment solves the technical problem that existing automated power-down testing technologies are difficult to synchronize with the internal state of the equipment, and improves the automation level, repeatability and integration with modern R&D systems of the testing process.

[0044] In some embodiments, the power-down test parameters include running node parameters, power control parameters, device-under-test (DUT) connection parameters, and anomaly detection rule parameters; the step of triggering a test task corresponding to the power-down test parameters and sending the test task to the test control host includes: Trigger test tasks that are bound to power failure test parameters through the Jenkins platform.

[0045] Binding refers to the process of associating and fixing the parameter values ​​defined by the user in the Jenkins task configuration interface with the current build task instance, ensuring that the user-specified configuration is used when the task is executed.

[0046] Specifically, after a user configures the various parameters for a task in the Jenkins web interface and clicks the "Build Now" button, the Jenkins server creates a specific task instance containing these parameter values. For example, if a user configures the power control parameter "COM3,9600,8,N,1" and the device under test connection parameter "10.0.0.5,22,admin,123456" for testing a certain model of switch, after clicking build, Jenkins generates a build instance with the task ID "#45", which internally stores and binds the aforementioned parameter values.

[0047] Using the Jenkins platform, test tasks are scheduled to the designated test control host based on the parameters of the running node.

[0048] Among them, the running node parameter refers to the configuration item used in the Jenkins distributed architecture to identify and select the physical or virtual computing environment for the specific task to be executed.

[0049] Specifically, the Jenkins server selects the corresponding test control host (i.e., Jenkins Agent) from its managed node list based on the "run node" parameter specified in the task configuration, and sends the task queue to the agent program on that node for execution. For example, the run node parameter is configured as "TestBench-Node_A". After the Jenkins master server finds that the agent program tagged "TestBench-Node_A" is online, it will place this power failure test task into the work queue of that node.

[0050] The test task and associated power-down test parameters are sent to the test control host.

[0051] In this context, "deployment" refers to the process by which the Jenkins master server transmits task execution instructions and related configuration data to the Jenkins agent on the target test control host via the network.

[0052] Specifically, the Jenkins server uses technologies such as Java serialization to transmit the build task object (containing all bound parameter values, build number, and other information) over the network to the Jenkins agent process running on the target test control host. For example, the task "#45" and its four bound parameters are fully packaged and transmitted to the agent program on the host "TestBench-Node_A" via Jenkins internal communication protocols (such as JNLP or SSH), where the agent program loads these parameters for use by the script.

[0053] The test control host initializes communication sessions with the programmable power supply and the device under test according to the power control parameters and the connection parameters of the device under test.

[0054] Initializing the communication session refers to the preparatory work on the test control host to establish a stable data connection with external devices (power supply, device under test) based on parameters and to perform basic handshake or configuration.

[0055] Specifically, the automated script running on the test control host parses the "power control parameters," uses the operating system API to open the specified serial port and configure attributes such as baud rate to establish a connection with the programmable power supply. Simultaneously, the script parses the "DUT connection parameters," calls SecureCRT's API or command-line tools, and initiates a connection with the DUT using the specified protocol (such as SSH), IP address, port, and authentication information. For example, the script parses the power control parameters "COM3,9600,8,N,1," uses VBScript's Scripting.FileSystemObject to open the COM3 port, sets the baud rate to 9600 bits per second (bit / s), data bits to 8, no parity, and stop bits to 1. At the same time, it parses the DUT connection parameters "10.0.0.5,22,admin,123456," establishes an SSH2 session connection to IP address 10.0.0.5 and port 22 (TCP) using SecureCRT's crt.Session.Connect method, and authenticates using the username "admin" and password "123456."

[0056] Therefore, according to the above implementation method, the system can realize centralized configuration and intelligent scheduling of test tasks and parameters, as well as automated preparation of the test environment, laying the foundation for subsequent execution of accurate automated power-down tests.

[0057] In some embodiments, the step of establishing a connection with the device under test and the programmable power supply based on power-down test parameters includes: Establish a serial communication session with the programmable power supply based on the power control parameters.

[0058] Among them, power control parameters refer to a set of information used to uniquely identify and configure the communication link with a specific programmable power supply, which typically includes serial port number, baud rate, data bits, parity bits, and stop bits.

[0059] Specifically, the automated script running on the test control host parses the power control parameter string, extracts the serial port identifier and communication format, and calls the serial communication library provided by the operating system or programming language to open the specified port and complete the initialization according to the parameter configuration, thereby establishing a stable command transmission channel.

[0060] For example, the power control parameters are "COM3,9600,8,N,1". An automation script (such as VBScript) parses this string and connects to the computer's COM3 port using the `crt.Session.Connect` method or a similar serial port object, setting the communication parameters to: baud rate of 9600 bits per second (bit / s), 8 data bits, no parity (N), and 1 stop bit. After a successful connection, the script can then send ASCII commands such as "OUTPUT ON" to the power supply through this session.

[0061] Establish a command-line communication session with the device under test based on the device's connection parameters.

[0062] The connection parameters of the device under test refer to the set of network or serial connection attributes required to establish a command-line interface with the device under test (such as a serial terminal or SSH service), which typically include IP address (or serial port number), port number, username and password.

[0063] Specifically, the automated script on the test control host parses the connection parameters of the device under test, determines the connection type (network or serial port) based on the parameters, and uses the session management function provided by SecureCRT software to create a new session configuration, initiates a connection using the authentication information in the parameters, and finally establishes a terminal session that can be used for interactive command sending and output.

[0064] For example, the connection parameters for the device under test are "192.168.1.100,22,root,admin123". After parsing, the script determines it to be a network connection (because it contains an IP address). The script will create a new session in SecureCRT using the SSH2 (Secure Shell version 2) protocol, setting the hostname to 192.168.1.100, the port number to 22 (TCP), and the authentication method to username and password. The username is "root" and the password is "admin123". Then, the script calls the connection command to establish the session. For serial devices, the parameters might be "COM5,115200,8,N,1", in which case the script will establish the corresponding serial terminal session.

[0065] Therefore, according to the above implementation method, the system can automatically complete the standardized and programmable connection with the key hardware (power supply and device under test) in the test environment based on structured parameters, laying a reliable foundation for subsequent precise power-on / off control and status monitoring.

[0066] In some embodiments, the automation script is configured to: Initialize the communication session with the programmable power supply and the device under test.

[0067] Initializing the communication session refers to the process by which the automated script calls relevant interfaces to establish a stable and usable data connection with the programmable power supply and the device under test before starting to execute the core test logic, and prepares for subsequent command sending and receiving.

[0068] Specifically, the script utilizes the script object model (such as the crt object) provided by SecureCRT to call connection methods to establish a session based on the connection parameters stored in variables. For programmable power supplies, a serial port object is typically used to establish the connection; for devices under test, an SSH or Telnet session is created to establish the connection.

[0069] For example, the script contains the following VBScript code snippet to establish a connection: Connect to a programmable power supply crt.Session.Connect(" / SERIAL COM3 / BAUD 9600") Connect to the device under test crt.Session.Connect(" / SSH2 / L admin / PASSWORD mypass123 192.168.1.1:22").

[0070] Once the connection is established, the script will wait and verify that the connection was successful, for example by checking the session status or reading the initial banner information.

[0071] Send a sequence of commands, including power-on and power-off commands, to the programmable power supply.

[0072] The command sequence refers to a set of ASCII string instructions sent to the programmable power supply according to preset logic and timing, in order to complete a complete "power-on-run-power-off" test cycle.

[0073] Specifically, the script uses the crt.Screen.Send method or the write method of the serial port object to send specific command strings sequentially through an initialized serial communication session. There is usually a waiting interval between power-on and power-off commands, or the command is triggered by device status feedback.

[0074] For example, the sequence of commands sent by the script might look like this: `crt.Screen.Send"OUTPUT ON"&chr(13)` sends the power-on command, where `chr(13)` represents a carriage return character. `WScript.Sleep 5000` waits for 5000 milliseconds (5 seconds) to simulate device runtime. crt.Screen.Send"OUTPUT OFF"&chr(13)' Sends the power-off command.

[0075] In more complex embodiments, the power-down command is triggered by monitoring a specific state of the device, rather than by a fixed delay.

[0076] Monitor the session output corresponding to the device under test in the SecureCRT terminal.

[0077] Session output refers to the stream of text information transmitted from the device under test to the SecureCRT terminal screen during a command-line communication session, including device startup logs, command response results, system prompts, etc.

[0078] Specifically, the script uses methods provided by the SecureCRT screen object (crt.Screen) to read text content within a specified area in real time, or wait for a specific string pattern to appear. This is a proactive polling or event-driven monitoring mechanism. For example, the script uses the crt.Screen.WaitForString function to wait for a flag indicating that the device has finished booting up. Waiting for the device login prompt to appear, with a timeout set to 120 seconds. bFound = crt.Screen.WaitForString("login:", 120) If bFound Then Perform login operation crt.Screen.Send "root"&chr(13) End If.

[0079] This code will continuously monitor the screen output until the string "login:" appears or more than 120 seconds have passed.

[0080] The session output is parsed and its status is determined based on string matching rules.

[0081] Among them, parsing and status determination refers to the logical process by which the script analyzes the text information captured by monitoring using predefined rules (keywords, regular expressions, etc.) and determines the current status of the device under test (such as successful startup, failed startup, normal operation, or abnormality) based on the matching results.

[0082] Specifically, the script compares the return value of the WaitForString function, or the text obtained through the crt.Screen.Get function, with multiple preset rules. Based on whether a "success" or "failure" rule is matched, different test branches are driven, and the judgment results are recorded. The WaitForString function is a key function provided in the SecureCRT terminal emulation software's script API, used to monitor the terminal session's output information in real time within the automated script and wait for the appearance of a preset key string (i.e., the "expected identifier"). The crt.Screen.Get function is a key function in the SecureCRT script API used to read text content from a specified area of ​​the terminal screen. For example, after the device powers on, the script will attempt to match successful startup rules (such as "Boot completed") and failure rules (such as "kernel panic" or "errorloading"). The judgment logic might be as follows: If crt.Screen.WaitForString("Boot completed", 60) Then testResult = "PASS" ElseIf crt.Screen.WaitForString("kernel panic", 10) Then testResult = "FAIL_Kernel" Else testResult = "FAIL_Timeout" End If Record the judgment result testResult to the log file.

[0083] Therefore, according to the above implementation method, the system can autonomously complete the connection establishment of the test environment, the precise application of test stimuli, the real-time monitoring of the device operating status, and the automatic determination of test results through configurable automated scripts, realizing a high degree of automation of the entire power failure test process and significantly improving the consistency and execution efficiency of the test.

[0084] In some embodiments, the steps of monitoring the session output corresponding to the device under test in the SecureCRT terminal and parsing and determining the status of the session output according to string matching rules include: Capture the data stream of session output in real time using automated scripts.

[0085] The data stream refers to the sequence of characters continuously transmitted from the device under test (DUT) with an established command-line communication session to the SecureCRT terminal screen and presented in chronological order. It includes real-time text content such as device startup information, command execution results, and system logs.

[0086] Specifically, the automation script uses the script object interface provided by SecureCRT to continuously read new text content from the screen buffer of the currently active terminal session in a polling or event-driven manner. For example, the script can be set up with a loop that calls the crt.Screen.Get function every 100 milliseconds (ms) to read all characters within a specified rectangular area on the screen (such as from row 1, column 1 to row 24, column 80), and appends these characters to a string variable, thereby simulating continuous capture of the data stream.

[0087] Calling the string matching function waits in the data stream for the expected identifier corresponding to the string matching rule.

[0088] Among them, the string matching function refers to the built-in function provided in the SecureCRT script API, which is used to search for specific string patterns in the terminal screen output, such as WaitForString; the expected identifier refers to a keyword or set of keywords or phrases predefined in the anomaly detection rule parameters to characterize that the device under test has entered a specific critical state.

[0089] Specifically, the automated script calls the `crt.Screen.WaitForString` function, passing the expected identifier string as one of its input parameters. This function blocks script execution and continuously monitors the screen output until a completely matching string is captured or a preset timeout is reached. For example, the preset exception detection rule defines the expected identifier as "file system check complete". In the script, the corresponding code is: `bFound=crt.Screen.WaitForString("file system check complete",90)`. This line of code means that the script will pause execution and wait for up to 90 seconds, monitoring the screen for the string "file system check complete".

[0090] In response to the capture of the expected identifier, an operation is triggered to send a power-down control command to the programmable power supply.

[0091] In this context, "trigger" refers to the immediate execution of a pre-defined code segment by the automated script, which controls the actions of external hardware, as a direct result of the successful string matching event.

[0092] Specifically, when the WaitForString function returns a signal indicating a successful match (for example, the function returns True), the script's execution flow enters the corresponding conditional branch, in which a standard shutdown command is sent to the programmable power supply through the established serial communication session.

[0093] For example, in the code branch after the WaitForString function successfully matches, the script executes the following command sending operation: If bFound Then crt.Screen.Send"Sends a power-down command to the power supply..."&chr(13) Suppose commands are sent through a serial port object named `comPort`. comPort.Send"OUTPUT OFF"&chr(13) End If.

[0094] This code segment will immediately send an "OUTPUT OFF" command (followed by a carriage return chr(13)) to the programmable power supply via the serial port after detecting "file system check complete", thereby performing a power-off operation.

[0095] Therefore, according to the above implementation method, the system can achieve millisecond-level precise power-off triggering based on the internal software running state of the device (rather than a fixed delay), ensuring that the timing of the power-off test is highly synchronized with the actual business logic of the device, thereby enabling more effective detection of potential faults related to specific operations and significantly improving the accuracy and effectiveness of the test.

[0096] In some embodiments, the step of controlling a programmable power supply to perform power-on and power-off operations on the device under test includes: Power-on control commands are sent to the programmable power supply via automated scripts.

[0097] Among them, the power-on control command refers to the standardized ASCII string command sent to the programmable power supply through a serial communication session to control the power supply of a specific output channel.

[0098] Specifically, after successfully establishing a serial communication session with the programmable power supply, the automated script writes a command string conforming to the programmable power supply communication protocol through the data transmission interface of the session, usually followed by a carriage return and line feed as the end-of-command. For example, for a certain model of programmable DC power supply, its power-on control command is "OUTPUT ON". The script executes via VBScript: comPort.Send "OUTPUT ON"&chr(13). Here, comPort is the object representing the serial port session, and chr(13) represents the carriage return character, used to submit the command.

[0099] After sending the power-on control command, wait for the device under test to enter a monitorable state.

[0100] The monitorable state refers to the stage after the device under test is powered on, when its core components such as the operating system kernel, basic services, and network stack are initialized, enabling the device to stably receive commands and return responses through command-line interfaces (such as SSH or serial ports).

[0101] Specifically, after sending the power-on command, the automated script calls a delay function (such as WScript.Sleep) to pause execution for a period of time. This allows time for the device under test (DUT) to power on, for the BIOS (Basic Input / Output System) to perform self-tests, and for the operating system to load, ensuring a higher success rate for subsequent connection attempts. For example, after sending the power-on command, the script executes WScript.Sleep 30000, meaning it waits for 30,000 milliseconds (30 seconds). This duration is based on empirical values ​​for the typical startup time of a specific DUT (such as an embedded industrial gateway).

[0102] The status of the device under test is monitored using automated scripts to see if it returns the expected identifier.

[0103] Among them, monitoring whether the status of the device under test returns the expected identifier means that after the preset waiting period ends, the automated script actively attempts to establish a command-line session with the device under test and checks whether the initial information output by the device contains a predefined key string that indicates that the system has successfully started to a specific stage.

[0104] Specifically, after the wait period ends, the script attempts to reconnect via SecureCRT or check the existing session, and calls the `crt.Screen.WaitForString` function to capture screen output within a set timeout period to determine if the expected identifier appears. For example, the expected identifier is "login:". After waiting 30 seconds, the script executes `bSuccess=crt.Screen.WaitForString("login:",15)`. This line of code attempts to capture the string "login:" from the terminal screen within 15 seconds and stores the result (True or False) in the variable `bSuccess`.

[0105] If the status of the device under test does not return the expected identifier, repeat the step of sending a power-on control command to the programmable power supply.

[0106] In this context, repetitive execution refers to the automated script controlling the flow to jump back to the starting point and trigger the power-on operation again after a "power-on-wait-monitor" cycle fails to detect a successful device startup, thus forming a new test attempt. This process is usually limited to a maximum number of repetitions to prevent infinite loops.

[0107] Specifically, the script implements a loop control structure (such as a For…Next loop or a Do While…Loop). Within this loop, steps include sending a power-on command, waiting, attempting a connection, and monitoring. If monitoring fails (i.e., the expected identifier is not captured), the loop condition checks if the number of attempts is less than the maximum allowed number. If so, the loop variable is incremented, and the process jumps back to the beginning of the loop to execute again. For example, the maximum number of retries, MaxRetries, is set to 3. The script structure is as follows: For retryCount=1 To MaxRetries comPort.Send“OUTPUT ON”&chr(13)' Sends the power-on command WScript.Sleep 30000' Waiting for the device to start `bSuccess = crt.Screen.WaitForString(“login:”, 15)` attempts to monitor... If bSuccess Then Exit For' If successful, exit the loop. Else comPort.Send“OUTPUT OFF”&chr(13)' Optional: Ensure power is off before retrying WScript.Sleep 2000' waits for the power to completely shut down. End If Next.

[0108] Therefore, according to the above implementation method, the system can automatically handle equipment startup failures caused by occasional faults in a single test task. The robustness and automation of the test process are improved through a limited number of automatic retry mechanisms, avoiding the interruption of the entire test task due to a single unexpected failure, and ensuring the continuity of long-term unattended testing.

[0109] In some embodiments, the operating status of the device under test (DUT) is monitored via a SecureCRT terminal, and based on the monitoring results, string matching rules are applied to verify the DUT's status and generate power-down test results, including: After the device under test returns the expected identifier, an automated script sends a device status query command to the device under test.

[0110] Among them, the device status query command refers to the native operating system command line instruction used to obtain the current detailed operating status, configuration information or performance indicators of the device under test.

[0111] Specifically, after detecting an expected identifier indicating device startup completion (such as a login prompt), the automated script sends one or more standard query commands to the device's command-line interface through an established SecureCRT session. For example, after receiving the "login:" prompt and automatically logging in, the script sends the following commands sequentially to query the status: crt.Screen.Send "cat / proc / uptime" &chr(13)' Query system uptime crt.Screen.Send "uname -a" &chr(13) 'Query kernel version information' crt.Screen.Send“df-h”&chr(13)' Query disk usage.

[0112] In response to the device under test's (DUT) response to the device status query command, string matching rules are applied to the response information to perform a status assertion check.

[0113] The response information refers to the text result returned and displayed on the SecureCRT terminal screen after the device under test executes the device status query command; the execution status assertion check refers to the process of comparing the captured response information text with a predefined string pattern (rule) used to determine whether the device status is normal, and making a logical judgment of "true" (pass) or "false" (failure) based on the comparison result.

[0114] Specifically, after sending a query command and waiting, the automated script captures the text of the command output area on the screen using the `crt.Screen.Get` function or a similar reading method. The script then uses string search functions (such as `InStr`) or regular expression objects to search for predefined key patterns in the text. For example, for the response to the `cat / proc / uptime` command, the script expects it to be formatted as two space-separated numbers (such as "12345.67 89.01"). The script can use the regular expression `^\d+\.\d+\s+\d+\.\d+$` to verify that the response matches this pattern. For the response to the `uname -a` command, the script can check if it contains the expected kernel version number substring, such as "4.19.0".

[0115] Based on the results of the state assertion check, generate assertion results indicating whether the test passed or failed.

[0116] The assertion result refers to the conclusive label given by a single state assertion check (or a comprehensive judgment of a set of checks), which is usually one of two discrete states: "PASS" or "FAIL".

[0117] Specifically, the automated script defines a Boolean variable for each query command check. If the response matches the corresponding string matching rule, the variable is set to True; otherwise, it is set to False. Finally, the script generates a global assertion result based on the logical AND operation of all checked variables, or according to the preset priority of key checks. For example, the script defines the variable diskCheck=False, and after parsing the output of the df -h command, it checks the usage rate of the root filesystem " / ". If the usage rate is below 90%, diskCheck is set to True. Ultimately, if all checks (runtime format, kernel version, disk usage) are True, the global assertion result finalAssertion is assigned the value "PASS"; if any check is False, finalAssertion is assigned the value "FAIL".

[0118] The power-down test results are generated and recorded based on the assertion results.

[0119] Recording power-down test results refers to the operation of writing the complete context information of this power-down test cycle (including timestamps, trigger parameters, operation sequence, monitoring and inspection results of each step, and the final assertion result) into a persistent storage medium (such as a text file or database) in a structured format.

[0120] Specifically, at the end of the testing process, the automated script creates a string that organizes the key information of the test line by line. Then, the script opens or creates a log file using a file system object (such as Scripting.FileSystemObject) and appends the string to the end of the file. For example, the script generates records in the following format and writes them to the file Power_Cycle_Test_Report.log: [2023-10-27 14:30:05] Test task #45 has started execution. - Running node: Lab-PC-01 - Device under test: 192.168.1.1 - Power-on for the first time: Successful (login detected:) -Status query 1 (uptime): PASS -Status query 2(uname): PASS -Status query 3(df): PASS -Result of this loop assertion: PASS - Precise power-down is triggered by: 'File system check complete' ==============================================

[0121] This record constitutes a complete and traceable result of a single power-down test cycle.

[0122] Therefore, according to the above implementation method, the system can automatically perform in-depth, multi-dimensional (such as system operation, kernel version, resource usage) status health checks after the device completes startup, and generate a standardized and traceable test report together with the automated judgment results based on string matching rules and test operation metadata. This achieves a leap from simple "whether it can start" judgment to comprehensive "whether the status after startup is completely correct" verification, which greatly enhances the depth of power-down testing and the reliability of the conclusions.

[0123] Figure 4 This is a structural block diagram of a power failure testing system based on Jenkins and SecureCRT according to an embodiment of the present invention.

[0124] like Figure 4 As shown, this power failure testing system based on Jenkins and SecureCRT includes: The test task distribution module 210 is used to trigger the test task corresponding to the power failure test parameters when configuring power failure test parameters for the test task through the Jenkins platform, and distribute the test task to the test control host.

[0125] The power connection execution module 220 is used to establish a connection with the device under test and the programmable power supply based on the power-down test parameters through the test control host.

[0126] The power-on / off operation execution module 230 is used to execute a preset automated script through the SecureCRT terminal on the test control host to control the programmable power supply to perform power-on and power-off operations on the device under test.

[0127] The power-down test result generation module 240 is used to monitor the operating status of the device under test through the SecureCRT terminal during the power-on and power-off operations, and to verify the status of the device under test based on the monitoring results by applying string matching rules, and generate power-down test results.

[0128] The specific functions and examples of each module and submodule of the device in this embodiment can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0129] According to embodiments of the present invention, the above-described method of the present invention can be applied to a computer device and a readable storage medium.

[0130] Figure 5 A schematic block diagram of an example computer device 600 that can be used to implement embodiments of the present invention is shown. The computer device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The computer device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0131] like Figure 5 As shown, the computer device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the computer device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0132] Multiple components in computer device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows computer device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0133] The computing unit 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as a power-down testing method based on Jenkins and SecureCRT. For example, in some embodiments, a power-down testing method based on Jenkins and SecureCRT can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the computer device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of a power-down testing method based on Jenkins and SecureCRT described above can be performed. Alternatively, in other embodiments, the computing unit 601 may be configured by any other suitable means (e.g., by means of firmware) to perform a power-down test method based on Jenkins and SecureCRT.

[0134] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0135] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0136] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0137] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0138] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0139] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0140] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0141] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this invention should be included within the scope of protection of this invention.

Claims

1. A power-down testing method based on Jenkins and SecureCRT, characterized in that, include: In response to configuring power failure test parameters for the test task through the Jenkins platform, the test task corresponding to the power failure test parameters is triggered, and the test task is sent to the test control host; The test control host establishes a connection with the device under test and the programmable power supply based on the power-down test parameters. The preset automation script is executed by the SecureCRT terminal on the test control host to control the programmable power supply to perform power-on and power-off operations on the device under test. During the power-on and power-off operations, the operating status of the device under test is monitored through the SecureCRT terminal, and based on the monitoring results, the status of the device under test is verified by applying string matching rules to generate power-off test results.

2. The method according to claim 1, characterized in that, The power failure test parameters include operating node parameters, power control parameters, device under test connection parameters, and anomaly detection rule parameters. The steps of triggering the test task corresponding to the power-down test parameters and sending the test task to the test control host include: The test task, which is bound to the power failure test parameters, is triggered through the Jenkins platform. Using the Jenkins platform, the test task is scheduled to the designated test control host according to the running node parameters; The test task and the associated power-down test parameters are sent to the test control host; The test control host initializes communication sessions with the programmable power supply and the device under test according to the power control parameters and the connection parameters of the device under test.

3. The method according to claim 2, characterized in that, The step of establishing a connection with the device under test and the programmable power supply based on the power-down test parameters includes: Establish a serial communication session with the programmable power supply based on the power control parameters; Establish a command-line communication session with the device under test based on the connection parameters of the device under test.

4. The method according to claim 1, characterized in that, The automation script is configured to be used for: Initialize the communication session with the programmable power supply and the device under test; Send a command sequence containing power-on and power-off commands to the programmable power supply; Monitor the session output in the SecureCRT terminal corresponding to the device under test; The session output is parsed and its status is determined according to the string matching rules.

5. The method according to claim 4, characterized in that, The steps of monitoring the session output in the SecureCRT terminal corresponding to the device under test, and parsing and determining the status of the session output according to the string matching rules, include: The automated script captures the data stream output from the session in real time. The string matching function is invoked to wait in the data stream for the expected identifier corresponding to the string matching rule; In response to the capture of the expected identifier, the operation of sending the power-down control command to the programmable power supply is triggered.

6. The method according to claim 5, characterized in that, The steps of controlling the programmable power supply to perform power-on and power-off operations on the device under test include: The automated script sends a power-on control command to the programmable power supply. After sending the power-on control command, wait for the device under test to enter a monitorable state; The automated script monitors whether the status of the device under test returns the expected identifier. If the status of the device under test does not return the expected identifier, the step of sending a power-on control command to the programmable power supply is repeated.

7. The method according to claim 6, characterized in that, The process of monitoring the operating status of the device under test (DUT) through the SecureCRT terminal, and verifying the DUT's status based on the monitoring results using string matching rules to generate power-down test results, includes: After the device under test returns the expected identifier, a device status query command is sent to the device under test through the automated script; In response to the response information received from the device under test to the device status query command, the string matching rule is applied to the response information to perform a status assertion check; Based on the results of the state assertion check, an assertion result is generated indicating whether the test passed or failed. The power-down test results are generated and recorded based on the assertion results.

8. A power failure testing system based on Jenkins and SecureCRT, characterized in that, include: The test task distribution module is used to trigger the test task corresponding to the power failure test parameters when configuring power failure test parameters for the test task through the Jenkins platform, and to distribute the test task to the test control host; The power connection execution module is used to establish a connection with the device under test and the programmable power supply through the test control host according to the power failure test parameters. The power-on / off operation execution module is used to execute a preset automated script through the SecureCRT terminal on the test control host to control the programmable power supply to perform power-on and power-off operations on the device under test; The power-down test result generation module is used to monitor the operating status of the device under test through the SecureCRT terminal during the power-on and power-off operations, and to verify the status of the device under test based on the monitoring results by applying string matching rules, and generate power-down test results.

9. A computer device, characterized in that, include: At least one processor; and a memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, in, Computer instructions are used to cause a computer to perform the method according to any one of claims 1-7.

Images