Multi-protocol automatic testing method and system

Abstract

The embodiment of the invention provides a multi-protocol automatic test method and system, and the method comprises the steps: receiving a test instruction of a simulated equipment case input by a user in a test case management interface, and building the communication connection between simulated equipment and a coordination controller; analyzing a test instruction of the simulated equipment case, determining a protocol type and a protocol plug-in of the simulated equipment, and loading at least one protocol plug-in instance corresponding to the type of the simulated equipment based on a protocol abstraction layer; according to a test case, driving the at least one protocol plug-in instance through a data point scene engine so as to simulate a dynamic operation condition of at least one simulated device, and performing message interaction following a corresponding communication protocol with the coordination controller through the at least one protocol plug-in instance; and monitoring and recording the message interaction, and generating a test result report according to an expected response.

Description

Technical Field

[0001] This application relates to the field of energy storage system control technology, and in particular to a multi-protocol automated testing method and system. Background Technology

[0002] With the widespread application of renewable energy, energy storage systems are playing an increasingly prominent role in the power system. As the "central nervous system" of an energy storage power station, the coordinating controller is responsible for receiving EMS / grid dispatch instructions and issuing them to the PCS and BMS for execution, while also monitoring the overall system status. However, existing technologies have the following drawbacks: Protocol diversity: The coordination controller needs to interface with a variety of devices with different protocols (such as CAN / MODBUS commonly used in BMS, and IEC 104 / 61850 commonly used in power grid dispatching), making testing complex.

[0003] The testing scenarios are complex: a large number of real and extreme operating conditions need to be simulated (such as short circuits in battery clusters and sudden changes in power commands). Using real equipment for testing is costly, risky, and difficult to reproduce.

[0004] Limitations of manual testing: It relies on manual operation by testers, which is inefficient, prone to errors, and difficult to guarantee coverage. It also cannot achieve regression testing and continuous integration (CI).

[0005] Lack of specialized tools: General protocol testing tools (such as Modbus Poll) have limited functionality and cannot meet the specific, system-level testing needs of the energy storage field. Summary of the Invention

[0006] In view of this, to address the problems of low efficiency, insufficient coverage, and difficulty in scenario reproduction in traditional manual testing, embodiments of this application provide a multi-protocol automated testing method. One or more embodiments of this application also relate to a multi-protocol automated testing system, a computing device, a computer-readable storage medium, and a computer program, to resolve the technical deficiencies existing in the prior art.

[0007] According to a first aspect of the embodiments of this application, a multi-protocol automated testing method is provided, comprising: Receive test instructions for the simulated device test cases input by the user in the test case management interface, and establish a communication connection between the simulated device and the coordination controller; By parsing the test instructions of the simulated device test cases, the protocol type and protocol plugin of the simulated device are determined, and at least one protocol plugin instance corresponding to the simulated device type is loaded based on the protocol abstraction layer. The protocol abstraction layer provides a unified interface to manage multiple heterogeneous communication protocols. According to the test cases, the at least one protocol plugin instance is driven by the data point scenario engine to simulate the dynamic operating conditions of at least one simulated device. The data point scenario engine controls the changes in the data point state of the simulated device based on a preset device data point model and scenario time sequence. Through the at least one protocol plugin instance, message interaction with the coordination controller is performed in accordance with the corresponding communication protocol; Monitor and record the message interactions, and generate a test result report based on the expected response.

[0008] Preferably, the protocol types include at least: Modbus TCP, IEC 104, IEC 61850, MQTT, CAN, and custom; the protocol plugins include at least: Modbus TCP plugin, IEC 104 plugin, IEC 61850 plugin, MQTT plugin, CAN plugin, and custom plugin.

[0009] Preferably, after loading the protocol plugin instance, the method further includes: Configure the network parameters of the simulated device, including IP address, port and site address, and the test parameters, including timeout, number of retries and sampling interval; Define the master or slave station role and communication parameters; Organize the test case set, establish dependencies and execution order.

[0010] Preferably, the test instructions for the simulated device use cases include one or more use cases for multiple simulated devices.

[0011] Preferably, after generating the test result report, the method further includes: The report summary, detailed results, failure analysis, and environmental information sections are extracted from the test result report. The test results and recommendations are generated using the report summary section, detailed results section, failure analysis section, and environmental information section.

[0012] Preferably, the test results and recommendations generated using the report summary section, detailed results section, failure analysis section, and environmental information section include: By analyzing and processing the report summary section, the total number of test cases, the number of passed cases, and the number of failed cases of the test execution overview are statistically determined. Based on the total number of test cases, the number of passed cases, and the number of failed cases, the test pass rate is calculated, and a visualization result of the test pass rate is generated. By analyzing and processing the detailed results section, a detailed result is obtained, which includes the results of all test cases, the execution time of each test case, the protocol type, and the test status. By analyzing and processing the failure analysis section, a failure analysis result is obtained, which includes detailed information on failed test cases, message tracing information, comparison of expected and actual values ​​of assertion failures, and the reasons for failure analysis. By analyzing and processing the environmental information, environmental information results containing the test system version, the device under test information, and the protocol plugin version are obtained; Based on the test pass rate visualization results, the detailed results including all test case results, the execution time, protocol type, and test status of each test case, the detailed information of failed test cases, message tracing information, and the failure analysis results including the comparison of expected and actual values ​​of assertion failures and the reasons for failure, as well as the environmental information including the test system version, the information of the device under test, and the protocol plugin version, test results and suggestions are generated.

[0013] According to a second aspect of the embodiments of this application, a multi-protocol automated testing system is provided, comprising: The test case management module is used to receive test instructions for simulated device test cases input by the user in the test case management interface, and to establish a communication connection between the simulated device and the coordination controller. The protocol abstraction layer module is used to parse the test instructions of the simulated device test cases, determine the protocol type and protocol plugin of the simulated device, and load at least one protocol plugin instance corresponding to the simulated device type. The protocol abstraction layer module is also used to provide a unified interface to manage multiple heterogeneous communication protocols. The data point scenario engine module is used to drive at least one protocol plugin instance according to test cases to simulate the dynamic operating conditions of at least one simulated device. The data point scenario engine is also used to establish a parameterized data point model of the simulated device, edit and execute dynamic scenario sequences to drive the state of the data point model to change over time or script logic, so as to control the data point state changes of the simulated device based on the preset simulated device data point model and scenario time sequence. The results analysis and diagnosis module is used to interact with the coordination controller through at least one protocol plugin instance, following the corresponding communication protocol, monitor and record the message interaction, and generate a test result report based on the expected response.

[0014] Preferably, the result analysis and diagnosis module is further configured to extract the report summary, detailed results, failure analysis, and environmental information from the test result report; and to generate test results and recommendations using the report summary, detailed results, failure analysis, and environmental information.

[0015] According to a third aspect of the embodiments of this application, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement any of the steps of the multi-protocol automated testing method.

[0016] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of any one of the multi-protocol automated testing methods.

[0017] According to a fifth aspect of the embodiments of this application, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described multi-protocol automated testing method.

[0018] The multi-protocol automated testing solution provided in this application has the following beneficial effects: 1) High efficiency: Automated testing replaces a large number of manual operations, enabling 24 / 7 unattended testing, which can significantly improve the efficiency and reliability of development, acceptance, and operation and maintenance testing of energy storage coordinating controllers. 2) High coverage: It can easily simulate thousands of normal, boundary, and abnormal scenarios. 3) High fidelity: It accurately simulates the behavior of multiple protocols and complex devices, resulting in a highly realistic testing environment. 4) Ease of use: The graphical interface lowers the barrier to entry, and test cases are reusable and shareable. 5) Security: It avoids the potential damage risks that may arise from fault testing of real physical devices. Attached Figure Description

[0019] Figure 1 This is a flowchart of a multi-protocol automated testing method provided in one embodiment of this application; Figure 2 This is a schematic diagram of a multi-protocol automated testing system provided in one embodiment of this application; Figure 3 This is a block diagram of the overall architecture of a multi-protocol automated testing system provided in one embodiment of this application; Figure 4 This is a schematic diagram of a test case editing interface provided in one embodiment of this application; Figure 5 This is a flowchart of a test report generation process provided in one embodiment of this application; Figure 6 This is an overall flowchart of a multi-protocol automated testing method provided in one embodiment of this application; Figure 7 This is a data interaction diagram of data flow and control flow provided in one embodiment of this application. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the purpose of illustrative purposes and have no inherent meaning. Therefore, "module," "part," or "unit" may be used interchangeably.

[0021] This application provides a multi-protocol automated testing method, and also relates to a multi-protocol automated testing system, a computing device, a computer-readable storage medium, and a computer program, which will be described in detail in the following embodiments.

[0022] Figure 1 This is a flowchart of a multi-protocol automated testing method provided in one embodiment of this application, which specifically includes the following steps: Step S101: Receive the test instructions for the simulated device test cases entered by the user in the test case management interface, and establish a communication connection between the simulated device and the coordination controller; The test instructions for the simulated device use cases include one or more use cases for multiple simulated devices.

[0023] Step S102: By parsing the test instructions of the simulated device use case, the protocol type and protocol plugin of the simulated device are determined, and at least one protocol plugin instance corresponding to the simulated device type is loaded based on the protocol abstraction layer. The protocol abstraction layer provides a unified interface to manage multiple heterogeneous communication protocols. Furthermore, the protocol types include at least: Modbus TCP, IEC 104, IEC 61850, MQTT, CAN, and custom; the protocol plugins include at least: Modbus TCP plugin, IEC 104 plugin, IEC 61850 plugin, MQTT plugin, CAN plugin, and custom plugin.

[0024] Step S103: According to the test cases, drive the at least one protocol plugin instance through the data point scene engine to simulate the dynamic operating conditions of at least one simulated device, wherein the data point scene engine controls the data point state changes of the simulated device based on a preset device data point model and scene time sequence. Step S104: Through the at least one protocol plugin instance, perform message interaction with the coordination controller following the corresponding communication protocol; Step S105: Monitor and record the message interactions, and generate a test result report based on the expected response.

[0025] In one embodiment of this application, the embodiment further includes: Configure the network parameters of the simulated device, including IP address, port and site address, and the test parameters, including timeout, number of retries and sampling interval; Define the master or slave station role and communication parameters; Organize the test case set, establish dependencies and execution order.

[0026] In another embodiment of this application, after generating the test result report based on the expected response, the method further includes: The report summary, detailed results, failure analysis, and environmental information sections are extracted from the test result report. The test results and recommendations are generated using the report summary section, detailed results section, failure analysis section, and environmental information section.

[0027] Specifically, the test results and recommendations generated using the report summary section, detailed results section, failure analysis section, and environmental information section include: By analyzing and processing the report summary section, the total number of test cases, the number of passed cases, and the number of failed cases of the test execution overview are statistically determined. Based on the total number of test cases, the number of passed cases, and the number of failed cases, the test pass rate is calculated, and a visualization result of the test pass rate is generated. By analyzing and processing the detailed results section, a detailed result is obtained, which includes the results of all test cases, the execution time of each test case, the protocol type, and the test status. By analyzing and processing the failure analysis section, a failure analysis result is obtained, which includes detailed information on failed test cases, message tracing information, comparison of expected and actual values ​​of assertion failures, and the reasons for failure analysis. By analyzing and processing the environmental information, environmental information results containing the test system version, the device under test information, and the protocol plugin version are obtained; Based on the test pass rate visualization results, the detailed results including all test case results, the execution time, protocol type, and test status of each test case, the detailed information of failed test cases, message tracing information, and the failure analysis results including the comparison of expected and actual values ​​of assertion failures and the reasons for failure, as well as the environmental information including the test system version, the information of the device under test, and the protocol plugin version, test results and suggestions are generated.

[0028] Figure 3 This is a block diagram of the overall architecture of a multi-protocol automated testing system provided in one embodiment of this application, as shown below. Figure 3As shown, the development environment of this application uses C++ to develop the core engine and Python / Lua for scripts and interfaces. Protocol plugin implementation example: Taking the Modbus TCP plugin as an example, this describes how to inherit the protocol abstract interface to implement function code processing, transaction processing, etc. The testing process is as follows: The user creates a test project and imports or defines the protocol specification of the coordinating controller. The simulation environment is configured by adding simulated BMS (2 units, CAN protocol) and simulated EMS (1 unit, IEC 104 protocol). Test cases are edited by writing a "SOC balancing function test" case, simulating a SOC of 90% for BMS1 and 80% for BMS2, and checking whether the coordinating controller issues the correct balancing command. Automated testing is executed by selecting and running the test case. The report is viewed by the system, which reports the test results, showing whether the assertions passed and attaching communication message records for fault diagnosis.

[0029] Specific implementation of the Protocol Abstraction Layer (PAL): such as Figure 4 As shown, the Protocol Abstraction Layer (PAL), as the core of the protocol simulation engine, defines a unified device simulation interface, message sending / receiving interface, and status callback interface. Each protocol plugin in the protocol plugin library (such as the Modbus TCP plugin) implements this set of interfaces. When a test case needs to simulate a BMS device, the PAL loads a CAN protocol plugin instance according to the configuration and "packages" it as a virtual BMS device. This provides standardized data reading / writing and command issuance functions to the upper layer, while the lower layer handles CAN frame encoding, decoding, and bus status management.

[0030] The data point scenario engine is implemented as follows: It maintains a device model library, where each model defines a data point table for the device (point number, name, type, scaling factor, etc.). In the "SOC Balancing Function Test" case, the user sets initial SOC values ​​(90% and 80%) for two simulated BMS devices and may configure a scenario script to dynamically change the SOC values ​​according to a virtual charge / discharge curve. During test execution, the scenario engine updates the data point values ​​in the real-time database at time steps, while the protocol plugin reads the latest values ​​from the database and generates a protocol message containing those values, which is then sent to the coordinating controller.

[0031] Figure 6 This is an overall flowchart of a multi-protocol automated testing method provided in one embodiment of this application, including: 1.1. First Phase: Test Preparation Test requirements analysis: Define test objectives: functional verification, protocol compatibility, robustness, and performance testing; determine the type and version of the protocol to be tested; identify key test scenarios and boundary conditions.

[0032] Test case design and configuration: Create / import test cases using a graphical interface; configure test parameters: timeout, number of retries, sampling interval; organize test case sets, establish dependencies and execution order.

[0033] Protocol simulation environment setup: Select the required protocol plugins (Modbus TCP, IEC 104, MQTT, etc.); configure the network parameters (IP, port, site address) of each simulation device; define the master / slave roles and communication parameters.

[0034] Data point scenario modeling: Establish equipment models (BMS, PCS, EMS, etc.); configure the data point table and initial values ​​for each equipment; design dynamic scenario sequences (normal operating conditions, fault operating conditions, boundary conditions). 1.2. Second Phase: Test Execution Automated scheduling startup: Load test case sequence; initialize all protocol simulation instances; establish physical / network connection with the coordination controller.

[0035] Multi-protocol parallel simulation: The protocol abstraction layer uniformly schedules various protocol instances; simulates concurrent communication of multiple devices; and parses and generates protocol messages in real time.

[0036] Dynamic scene injection: Execute scene scripts according to the timeline; dynamically update device data point status; simulate fault injection and recovery process.

[0037] Response monitoring and data acquisition: Capture all messages sent by the coordinating controller; parse message content in real time; record timestamps and communication quality indicators.

[0038] 1.3. Third Stage: Analysis Stage Automated assertion checks: Compare actual responses with expected responses; check communication timing and protocol compliance; verify the correctness of business logic.

[0039] Test result classification: Pass: All checkpoints meet expectations; Fail: Critical checkpoints fail; Warning: Non-critical checkpoints are abnormal but the function is normal.

[0040] Intelligent diagnostic analysis: Automatically analyzes the cause of failure; locates the error in protocol parsing; and provides debugging suggestions and repair directions.

[0041] Test report generation: Summarizes all test results; generates visual charts and statistics; includes detailed message tracing and timing analysis; outputs reports in multiple formats (HTML / PDF / Excel), such as... Figure 5 As shown.

[0042] Test case maintenance: Optimize test cases based on test results; add new test scenarios; update protocol version support.

[0043] Continuous Integration: Interacts with CI / CD pipelines; supports automated regression testing at night; enables automatic notification of test results.

[0044] The following is combined with Figure 7 The technical solution of the present invention will be explained using data flow and control flow as specific examples. I. Data Flow in Test Scenarios (Taking Charge and Discharge Test as an Example) 1. Application layer: Send "simulate BMS charging" test command; 2. Protocol Abstraction Layer: Parses instructions and determines whether to use the Modbus protocol; 3. Protocol Plugin Manager: Loads Modbus plugin instances; 4. Data Management Layer: Provides BMS device models and charging curve data; 5. Protocol State Manager: Establishes a Modbus connection and enters the data exchange state; 6. Timing Synchronization Controller: Triggers data point updates according to the time axis; 7. Scene Sequence Engine: Gradually updates SOC, voltage, and current values; 8. Real-time database: Stores the updated state of data points; 9. Modbus plugin: Reads the latest values ​​from the database and encodes them into Modbus messages; 10. Message Router / Distributor: Sends messages to the corresponding device instance; 11. Communication Interface Layer: Sends messages to the coordinating controller via TCP; 12. Coordination Controller: Returns a response message; 13. Communication Interface Layer: Receives raw response data; 14. Modbus plugin: Decodes messages and updates internal state; 15. Protocol State Manager: Verifies the correctness of responses; 16. Results Analyzer: Records test results and compares them with expected values; 17. Support Services - Performance Analyzer: Statistics on communication latency and success rate.

[0045] II. Control Flow Example (Fault Injection Test) 1. Support Services - Fault Injector: Configure "Simulate network interruption for 5 seconds"; 2. Protocol Abstraction Layer: Receives fault injection commands; 3. Timing synchronization controller: scheduled to execute at time T+10s; 4. Upon reaching the designated time: a network interruption event is triggered; 5. Communication interface layer: Simulates TCP connection termination; 6. Protocol Status Manager: If a connection loss is detected, update the status to "Disconnected"; 7. Protocol Plugin: Handles connection exceptions and attempts to reconnect; 8. Communication interface layer: Connection restored after 5 seconds; 9. Protocol Status Manager: Detects successful reconnection and verifies status restoration; 10. Results Analyzer: Records fault recovery time and behavioral correctness.

[0046] This application also provides an embodiment of a multi-protocol automated testing system. Figure 2 This is a schematic diagram of the structure of a multi-protocol automated testing system provided in one embodiment of this application, as shown below. Figure 2 As shown, the system includes a test case management module, a protocol simulation engine module, a data point scenario engine module, an automated scheduling module, and a result analysis and diagnosis module. Its core function lies in managing multiple heterogeneous communication protocols (such as ModbusTCP, IEC 104, MQTT, IEC61850, CAN, etc.) uniformly through the protocol abstraction layer of the protocol simulation engine; simulating the operating status and fault conditions of a real energy storage system through the data point scenario engine; and executing test case sequences through the automated scheduling module to automatically generate detailed test reports.

[0047] More specifically, the test case management module: Provides a graphical user interface (GUI) for editing, managing, and organizing test cases. Test cases are presented in a tree structure and can be parameterized.

[0048] Protocol emulation engine: Protocol Abstraction Layer (PAL): Defines a unified interface that allows various protocol parsers to be dynamically loaded as plugins. Specifically, it provides standardized APIs for upper-layer test cases to call, shields the technical differences between different protocols, uniformly manages the lifecycle of all protocol instances, and serves as the sole entry point for all protocol plugins.

[0049] Protocol Plugin Library: Contains various pre-built protocol plugins (Modbus, IEC 104, MQTT, CAN, etc.). Each plugin is responsible for the encoding, decoding, and state machine maintenance of its protocol messages. Standard protocol plugins: Modbus, IEC 104, IEC61850, MQTT, CANopen, etc.; Custom protocol plugins: Supports user-defined private protocols; Each plugin includes: message encoder / decoder, protocol state machine, configuration parameter template, and consistency test cases.

[0050] Supports role simulation: It can simultaneously simulate multiple host computers (such as EMS) and slave computers (such as multiple BMS and PCS).

[0051] Data point scene engine: Device modeling: Define a data point table (such as voltage, current, SOC, alarm bits) for each simulated device (battery cluster, PCS).

[0052] Scene sequence editing: Supports defining the dynamic change patterns of data points using a timeline or script (Python / Lua) to simulate charging and discharging processes, fault injection, and recovery.

[0053] Automated scheduling module: Executes test case sets in a predetermined order and logic without manual intervention. Supports scheduled tasks and external calls (CI / CD pipeline integration).

[0054] Results Analysis and Diagnostic Module: Real-time monitoring: Capture and parse all communication messages, displaying them as raw frames and parsed data.

[0055] Assertions and checks: Automatically compare the actual response of the coordinating controller with the expected response.

[0056] Report generation: Automatically generates detailed test reports (HTML / PDF format) including test pass rate, logs, and packet captures.

[0057] The test case management module is used to receive test instructions for simulated device test cases input by the user in the test case management interface, and to establish a communication connection between the simulated device and the coordination controller. The protocol abstraction layer module is used to parse the test instructions of the simulated device test cases, determine the protocol type and protocol plugin of the simulated device, and load at least one protocol plugin instance corresponding to the simulated device type. The protocol abstraction layer module is also used to provide a unified interface to manage multiple heterogeneous communication protocols. The data point scenario engine module is used to drive at least one protocol plugin instance according to test cases to simulate the dynamic operating conditions of at least one simulated device. The data point scenario engine is also used to establish a parameterized data point model of the simulated device, edit and execute dynamic scenario sequences to drive the state of the data point model to change over time or script logic, so as to control the data point state changes of the simulated device based on the preset simulated device data point model and scenario time sequence. The results analysis and diagnosis module is used to interact with the coordination controller through at least one protocol plugin instance, following the corresponding communication protocol, monitor and record the message interaction, and generate a test result report based on the expected response.

[0058] Furthermore, the result analysis and diagnosis module is also used to extract the report summary, detailed results, failure analysis, and environmental information from the test result report; and to generate test results and suggestions using the report summary, detailed results, failure analysis, and environmental information.

[0059] The above is an illustrative scheme of a multi-protocol automated testing system according to this embodiment. It should be noted that the technical solution of this multi-protocol automated testing system and the technical solution of the multi-protocol automated testing method described above belong to the same concept. For details not described in detail in the technical solution of the multi-protocol automated testing system, please refer to the description of the technical solution of the multi-protocol automated testing method described above.

[0060] One embodiment of this application provides a computing device. The components of this computing device include, but are not limited to, a memory and a processor. The processor and memory are connected via a bus, and a database is used to store data.

[0061] The computing device also includes access devices that enable the computing device to communicate via one or more networks. Examples of such networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. Access devices may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0062] Computing devices can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. Computing devices can also be mobile or stationary servers.

[0063] The processor is used to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described multi-protocol automated testing method.

[0064] An embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described multi-protocol automated testing method.

[0065] An embodiment of this application also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described multi-protocol automated testing method.

[0066] The above are illustrative schemes of a computing device, a computer-readable storage medium, and a computer program according to this embodiment. It should be noted that each technical solution belongs to the same concept as the above-described multi-protocol automated testing method, and details not described in detail for each technical solution can be found in the description of the above-described multi-protocol automated testing method.

[0067] The preferred embodiments of the present invention have been described above with reference to the accompanying drawings, but this does not limit the scope of the invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of the present invention should be within the scope of the present invention.

Claims

1. A multi-protocol automated testing method, characterized in that, include: Receive test instructions for the simulated device test cases input by the user in the test case management interface, and establish a communication connection between the simulated device and the coordination controller; By parsing the test instructions of the simulated device test cases, the protocol type and protocol plugin of the simulated device are determined, and at least one protocol plugin instance corresponding to the simulated device type is loaded based on the protocol abstraction layer. The protocol abstraction layer provides a unified interface to manage multiple heterogeneous communication protocols. According to the test cases, the at least one protocol plugin instance is driven by the data point scenario engine to simulate the dynamic operating conditions of at least one simulated device. The data point scenario engine controls the changes in the data point state of the simulated device based on a preset device data point model and scenario time sequence. Through the at least one protocol plugin instance, message interaction with the coordination controller is performed in accordance with the corresponding communication protocol; Monitor and record the message interactions, and generate a test result report based on the expected response.

2. The method according to claim 1, characterized in that, The protocol types include at least: Modbus TCP, IEC104, IEC 61850, MQTT, CAN, and custom; the protocol plugins include at least: Modbus TCP plugin, IEC 104 plugin, IEC 61850 plugin, MQTT plugin, CAN plugin, and custom plugin.

3. The method according to claim 1, characterized in that, Also includes: Configure the network parameters of the simulated device, including IP address, port and site address, and the test parameters, including timeout, number of retries and sampling interval; Define the master or slave station role and communication parameters; Organize the test case set, establish dependencies and execution order.

4. The method according to claim 1, characterized in that, The test instructions for the simulated device use cases contain one or more use cases for multiple simulated devices.

5. The method according to claim 1, characterized in that, After generating the test result report based on the expected response, it also includes: The report summary, detailed results, failure analysis, and environmental information sections are extracted from the test result report. The test results and recommendations are generated using the report summary section, detailed results section, failure analysis section, and environmental information section.

6. The method according to claim 5, characterized in that, Using the report summary section, detailed results section, failure analysis section, and environmental information section, test results and recommendations are generated, including: By analyzing and processing the report summary section, the total number of test cases, the number of passed cases, and the number of failed cases of the test execution overview are statistically determined. Based on the total number of test cases, the number of passed cases, and the number of failed cases, the test pass rate is calculated, and a visualization result of the test pass rate is generated. By analyzing and processing the detailed results section, a detailed result is obtained, which includes the results of all test cases, the execution time of each test case, the protocol type, and the test status. By analyzing and processing the failure analysis section, a failure analysis result is obtained, which includes detailed information on failed test cases, message tracing information, comparison of expected and actual values ​​of assertion failures, and the reasons for failure analysis. By analyzing and processing the environmental information, environmental information results containing the test system version, the device under test information, and the protocol plugin version are obtained; Based on the test pass rate visualization results, the detailed results including all test case results, the execution time, protocol type, and test status of each test case, the detailed information of failed test cases, message tracing information, and the failure analysis results including the comparison of expected and actual values ​​of assertion failures and the reasons for failure, as well as the environmental information including the test system version, the information of the device under test, and the protocol plugin version, test results and suggestions are generated.

7. A multi-protocol automated testing system, characterized in that, include: The test case management module is used to receive test instructions for simulated device test cases input by the user in the test case management interface, and to establish a communication connection between the simulated device and the coordination controller. The protocol abstraction layer module is used to parse the test instructions of the simulated device test cases, determine the protocol type and protocol plugin of the simulated device, and load at least one protocol plugin instance corresponding to the simulated device type. The protocol abstraction layer module is also used to provide a unified interface to manage multiple heterogeneous communication protocols. The data point scenario engine module is used to drive at least one protocol plugin instance according to test cases to simulate the dynamic operating conditions of at least one simulated device. The data point scenario engine is also used to establish a parameterized data point model of the simulated device, edit and execute dynamic scenario sequences to drive the state of the data point model to change over time or script logic, so as to control the data point state changes of the simulated device based on the preset simulated device data point model and scenario time sequence. The results analysis and diagnosis module is used to interact with the coordination controller through at least one protocol plugin instance, following the corresponding communication protocol, monitor and record the message interaction, and generate a test result report based on the expected response.

8. The system according to claim 7, characterized in that, The result analysis and diagnosis module is also used to extract the report summary, detailed results, failure analysis, and environmental information from the test result report; and to generate test results and suggestions using the report summary, detailed results, failure analysis, and environmental information.

9. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the multi-protocol automated testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the multi-protocol automated testing method according to any one of claims 1 to 7.

Images