Test method, test data injection method, and test system

Abstract

This application discloses a testing method, a test data injection method, and a testing system. The method includes: obtaining a test plan for the system under test (SUT), wherein the test plan reflects the test requirements of the SUT under a target test scenario; determining test data corresponding to the test requirements; injecting the test data into the SUT through an upper-layer data interface, wherein the upper-layer data interface provides data services to upper-layer applications in the data link of the SUT; receiving the response result from the SUT after the test data injection, and determining the test result based on the response result. This application solves the technical problem of related technologies where testing methods directly inject data into the underlying server by modifying system configuration, resulting in strong invasiveness and poor flexibility in the SUT.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and more specifically, to a testing method, a test data injection method, and a testing system. Background Technology

[0002] In industrial instrumentation and control equipment monitoring systems, to verify the performance of predictive maintenance, anomaly detection, and other equipment monitoring applications (APPS), it is usually necessary to construct a controllable test environment to simulate normal, extreme, or fault conditions. However, the testing methods used in related technologies directly write test data to the server or the lower-level PLC (Programmable Logic Controller) by modifying the system configuration, and usually bypass the system's standard data flow, resulting in strong invasiveness and poor flexibility to the system under test.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a testing method, a test data injection method, and a testing system to at least solve the technical problem that the testing methods used in related technologies inject data directly into the underlying server by modifying system configuration, resulting in strong invasiveness and poor flexibility to the system under test.

[0005] According to one aspect of the embodiments of this application, a testing method is provided, comprising: acquiring a test plan for a system under test, wherein the test plan is used to reflect the test requirements of the system under test under a target test scenario; determining test data corresponding to the test requirements; injecting the test data into the system under test through an upper-layer data interface of the system under test, wherein the upper-layer data interface is used to provide data services to upper-layer applications in the data link of the system under test; receiving the response result of the system under test after the test data is injected, and determining the test result based on the response result.

[0006] In this embodiment, simulated test data is injected through an upper-layer data interface. The test plan is parsed to determine test data that meets the target test scenario. The test data is injected non-intrusively using the standard data service interface of the system under test for upper-layer applications. The system response results are received to evaluate its behavior. This achieves the goal of controllable and reproducible testing without changing the underlying system architecture. This enables independent or combined verification and performance evaluation of upper-layer components in the data link. It also solves the technical problem of related technologies that inject data directly into the underlying server by modifying the system configuration, resulting in strong invasiveness and poor flexibility to the system under test. Attached Figure Description

[0007] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0008] Figure 1 This is a hardware structure block diagram of a computer terminal according to a testing method of an embodiment of this application;

[0009] Figure 2 This is a flowchart of a testing method according to an embodiment of this application;

[0010] Figure 3 This is a flowchart of a test data injection method according to an embodiment of this application;

[0011] Figure 4 This is a schematic diagram of the structure of a testing system according to an embodiment of this application;

[0012] Figure 5 This is a schematic diagram of the overall test process of a test method according to an embodiment of this application;

[0013] Figure 6 This is a flowchart of the simulation data generation engine of a test method according to an embodiment of this application;

[0014] Figure 7 This is a flowchart of the injection client of a testing method according to an embodiment of this application;

[0015] Figure 8 This is a flowchart of the test scenario manager of a test method according to an embodiment of this application;

[0016] Figure 9 This is a schematic diagram of the structure of a testing device according to an embodiment of this application;

[0017] Figure 10 This is a schematic diagram of a test data injection device according to an embodiment of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0019] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0020] Industrial instrumentation and control equipment monitoring system: This refers to a software system architecture used for real-time acquisition, monitoring, analysis, and health management of the operating status of various instruments and control equipment (such as sensors, regulating valves, actuators, transmitters, etc.) during factory production. Its typical architecture includes a data acquisition layer, a communication transmission layer, and an application analysis layer. It typically acquires field equipment data through an OPC UA server and transmits it to the equipment monitoring application system (APPS) via upper-layer interfaces such as gRPC to achieve functions such as predictive maintenance, anomaly detection, and operational optimization. In this embodiment, the system is used as the test object, and its gRPC data acquisition interface is used for non-intrusive test data injection to verify the functional correctness and performance stability of the upper-layer algorithm application without interfering with production operations.

[0021] OPC UA server (Open Platform Communications for Unified Architecture, or OPC UA for short): A cross-platform, secure, and reliable industrial communication standard protocol server used to uniformly collect, encapsulate, and provide real-time data from field devices (such as PLCs and sensors), and provide access to upper-layer applications through a standardized interface. In this embodiment, the OPC UA server serves as the underlying data source of the industrial instrumentation and control equipment monitoring system, responsible for forwarding field device data to the gRPC collector. However, this application does not modify or directly inject it; it only tests through its upper-layer interface to achieve non-intrusive verification.

[0022] The gRPC (Google Remote Procedure Call) data acquisition component is a high-performance remote procedure call framework built on HTTP / 2 and Protocol Buffers. It receives industrial time-series data from data sources such as OPC UA servers and provides data services to upper-layer device monitoring applications (APPS) through standardized gRPC service interfaces (such as UpdateValue). In this embodiment, the gRPC data acquisition component serves as the access point for injecting test data. Its standard interface is used to securely and seamlessly inject simulated test data, enabling end-to-end functional and performance verification of upper-layer applications.

[0023] Equipment Monitoring Applications (APPS) are functional algorithmic applications deployed in industrial instrumentation and control equipment monitoring systems, such as predictive maintenance, anomaly detection, and fault diagnosis. They are used to analyze data from gRPC data collectors and generate operational status assessments or early warning information. In this embodiment, the equipment monitoring APPS is the final verification object of the test, and its response results are used to evaluate the accuracy, timeliness, and robustness of the algorithm under simulated operating conditions.

[0024] Modern industrial instrumentation and control equipment monitoring systems generally adopt a layered architecture: Industrial Equipment Management System → OPC UA Server → Data Transmission Medium → gRPC Data Acquisition Unit → Equipment Monitoring Applications (APPS). In this architecture, performance testing and verification of the equipment monitoring APPS become crucial for ensuring system stability. In practical engineering, long-term performance testing, extreme condition verification, and system capacity planning of equipment monitoring APPS all require a large amount of controllable test data. However, the testing methods employed by related technologies heavily rely on physical hardware, resulting in high testing costs, lengthy testing cycles, and limited application scenarios.

[0025] The relevant technologies mainly rely on three types of methods: First, hardware-in-the-loop simulation, which uses a dedicated real-time simulator to simulate the behavior of physical equipment and injects the generated data into the system's underlying interface. However, this method requires the purchase of expensive simulation hardware, has complex system configuration, and the accuracy of the simulation model is limited, making it difficult to seamlessly integrate with upper-layer data service architectures such as gRPC. Second, historical data playback, which involves collecting on-site operational data and replaying it during testing. However, its test scenarios are limited by historical records, making it impossible to generate fault modes or extreme operating conditions that have not occurred before. Furthermore, the data flow is fixed and lacks dynamic control capabilities, making it difficult to support stress testing and long-term stability verification. Third, direct injection of underlying data, which involves modifying the configuration of underlying devices such as OPC UA servers and PLCs or using debugging tools to forge data. However, this method is highly invasive, requires modification of the underlying logic of the production system, and poses risks of interfering with normal production and introducing system instability. Moreover, it has a high technical threshold, is difficult to implement, and is difficult to conduct testing without interrupting production.

[0026] To address the aforementioned technical problems, this application provides corresponding solutions, which are detailed below.

[0027] The testing methods and test data injection methods provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing a test method and a test data injection method is shown. Figure 1As shown, the computer terminal 10 may include one or more processors (shown as 102a, 102b, ..., 102n in the figure) (the processor may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions connected via wired and / or wireless networks. In addition, it may also include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, and a BUS bus. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0028] In the above operating environment, this application provides a test method and a test data injection method embodiment. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than that shown here.

[0029] Figure 2 This is a flowchart of a testing method according to an embodiment of this application, such as... Figure 2 As shown, the method includes the following steps:

[0030] Step S202: Obtain the test plan for the system under test, wherein the test plan is used to reflect the test requirements of the system under test in the target test scenario.

[0031] In step S202 above, the system under test refers to the complete software system architecture used in an industrial environment to monitor, analyze and predict the operating status of instruments and control equipment. For example, its structure may include underlying industrial equipment, OPC UA server, gRPC collector and equipment monitoring application deployed on the upper layer.

[0032] A test plan refers to a pre-designed, structured test configuration scheme to achieve specific test objectives. Its content covers elements such as the type of test scenario, data characteristics, injection timing, fault model parameters, and expected monitoring indicators. For example, in a test scenario for early warning of valve stickiness faults, the test plan can explicitly specify: using the historical operating data of a control valve as the background baseline, superimposing simulated "stickiness-slippage" dynamic characteristics between the 3rd and 5th hours, and setting the static friction threshold to 1% and the data injection frequency to once every 100 milliseconds. Test requirements refer to explicit test objectives proposed to verify the performance of industrial instrumentation and control equipment monitoring systems in specific functional or performance dimensions. Their content originates from the target test scenarios defined in the test plan and covers multi-dimensional constraints such as data type, anomaly patterns, timing characteristics, data quality changes, and injection frequency.

[0033] In some embodiments of this application, test plans can be automatically loaded based on a pre-built test scenario library. Specifically, the system has built-in multiple verified industrial typical fault and operating condition templates, such as "7×24-hour long-term stability test", "sensor data quality degradation simulation", and "multi-point concurrent pressure injection". When the user selects a scenario (such as "valve stickiness fault simulation") on the test front-end interface, the system automatically reads the corresponding complete test parameter configuration from the scenario library, including data mode (mixed mode), injection period, quality code change rules and monitoring item list, generates a structured test plan and passes it to the subsequent execution module.

[0034] Furthermore, users can also customize parameter configurations and dynamic arrangements. Testers can manually set test parameters through the graphical configuration interface according to actual needs, such as specifying the target label name (e.g., Area1.FC-101.PV), data generation type (historical playback + fault overlay), fault triggering conditions (controller output change exceeds 0.5%), viscosity duration (15 seconds), static friction threshold (3%), etc.

[0035] To fully simulate complex interactive behaviors across multiple scenarios under real-world working conditions, the test plan for the system under test can be obtained in the following ways: obtain at least one target test scenario; determine the test execution information for at least one target test scenario, wherein the test execution information reflects the execution order, test duration, and number of test loops for at least one target test scenario; and determine the test plan based on the test execution information.

[0036] It should be noted that the target test scenario refers to a set of test cases that are predefined and have clear input characteristics and expected output responses, which are used to verify the behavior of industrial instrumentation and control equipment monitoring systems under specific operating conditions or fault modes. For example, the "control valve stickiness fault simulation scenario" requires the introduction of a stepped delay response in the valve position feedback signal, while the "sensor data quality degradation scenario" requires the periodic insertion of anomalies with the data quality code "bad quality".

[0037] Test execution information refers to a set of metadata used to standardize how target test scenarios are organized and scheduled during actual execution. This includes the execution order of test scenarios, the duration of a single test, and the number of loop repetitions in the entire test process. Test execution information is the core scheduling basis for achieving automated and reproducible testing. It transforms fragmented test scenarios into structured, programmable test processes, enabling the system to execute complex test sequences according to a plan. A test plan is a complete test execution scheme composed of one or more target test scenarios and their corresponding test execution information. It serves as a bridge connecting test design and test execution. The test plan not only defines "what to test" (scenario content) but also specifies "how to test" (execution order, duration, loop), and serves as the sole source of instructions for subsequent simulation data generation and injection control.

[0038] Specifically, verified typical industrial scenarios can be selected from the pre-set scenario library or custom scenarios can be created through parameterized configuration tools. Further, when determining test execution information, the following two modes are included but not limited to: (1) Linear scheduling based on time axis. The system provides a visual time axis editor, which allows users to drag and arrange multiple scenarios and set precise start and end times, duration and repetition times for each scenario, such as "run background data in the 0-3 hour, inject faults in the 3-5 hour, recover in the 5-6 hour, and repeat 3 times in a loop". (2) Conditional triggering mechanism based on event-driven mechanism. The system supports setting conditional triggering rules, such as "when the device monitoring application outputs 3 consecutive 'high viscosity index' alarms, automatically start the 'data quality degradation' scenario and extend the test time by 1 hour", thereby realizing dynamic response testing. This method is suitable for verifying the behavioral logic of the algorithm in the process of multi-fault coupling or adaptive recovery.

[0039] Furthermore, all selected target test scenarios and their corresponding execution information are structurally integrated to generate a unified, machine-readable test instruction set. This instruction set includes fields such as scenario ID, start offset time, duration, number of loops, data generation configuration file path, and monitoring indicator binding relationship. After syntax verification and logical conflict detection (such as scenario overlap and resource conflict), it is solidified into a formal test plan.

[0040] By constructing a structured test plan that includes target test scenarios and test execution information, this application achieves systematic, automated, and refined management of the testing process for industrial instrumentation and control equipment monitoring systems. This mechanism eliminates the need for manual data injection or scenario switching, enabling one-click execution of complex test sequences involving multiple stages, cycles, and fault types, significantly improving test coverage and repeatability.

[0041] To avoid the inefficiency and resource waste caused by the traditional testing method of executing all scenarios one by one in a fixed order, the following steps can also be performed: obtain the first response result of the first test scenario, wherein the first test scenario includes any one of the at least one target test scenario; if the first response result meets the preset conditions, stop the test of the first test scenario and trigger the test of the second test scenario, wherein the second test scenario includes the next target test scenario in the execution order of the first test scenario.

[0042] It should be noted that preset conditions refer to logical criteria predefined by testers to determine whether a test scenario should terminate and trigger the next stage. These can be set based on key indicators in the response results, such as "when the viscosity index remains above 90% for 5 consecutive seconds," "when the number of system alarms reaches 3," or "when the gRPC collector's CPU utilization exceeds 80% for 2 minutes." Preset conditions are the core mechanism for implementing a response-driven testing process, enabling testing to move away from fixed time scheduling and instead evolve dynamically based on the system's actual response, more closely mirroring the adaptive logic in real-world operation.

[0043] Specifically, the initial response depends on the monitoring and analysis module's real-time capture mechanism of the device monitoring application's output. This includes a log listening mode, where the system subscribes to the device monitoring app's log output interface to extract time-series data of key diagnostic indicators (such as "stickiness index" and "health score") and alarm events in real time, and caches and parses them with millisecond-level precision; or an API polling mode, where, if the device monitoring app provides a standard query interface (such as REST or internal RPC), the test system proactively initiates queries at fixed intervals (such as 500 milliseconds) to obtain structured response values ​​of the current operating status. Both methods must ensure that the response results are strictly aligned with the timestamp of the injected test data to establish a causal relationship between input and output.

[0044] Furthermore, the system continuously compares the currently acquired first response result with the logical expression of preset conditions. For example, a preset condition can be defined as: "viscosity index > 0.85 for 5 seconds." Once the condition is met, the decision engine immediately sends a termination command to the current simulation data generation engine, stopping the data injection for that scenario. Simultaneously, based on the preset scenario dependencies in the test plan, it locates the configuration parameters (such as data model, injection frequency, and target label) of the second test scenario and immediately initiates its execution process. It should be noted that the system supports multi-condition combination judgments, such as "alarm count ≥ 3 and CPU utilization ≤ 75%", to avoid erroneously triggering subsequent tests when the system is abnormally overloaded, thus improving test safety.

[0045] By introducing a response-driven test triggering mechanism, a fundamental shift in the testing process from time-driven to behavior-driven has been achieved, freeing testing from being limited by a fixed schedule and allowing the testing rhythm to be dynamically adjusted based on the actual response of the equipment monitoring system.

[0046] Step S204: Determine the test data corresponding to the test requirements.

[0047] In step S204 above, test data refers to a time-series numerical sequence that conforms to industrial protocol specifications and is constructed to simulate real or extreme industrial operating conditions. Its content includes, but is not limited to, structured elements such as label name, numerical body (floating-point number or integer), timestamp (accurate to milliseconds), and data quality code (e.g., 192 represents "good quality" and 0 represents "bad quality").

[0048] In some embodiments of this application, test data corresponding to test requirements can be determined in the following ways: when the test requirements indicate that the actual operating conditions of the system under test are reproduced, the historical data of the system under test is determined as the first test data; when the test requirements indicate that the system under test is tested under extreme operating conditions, second test data for simulating extreme operating conditions is generated; when the test requirements indicate that the fault response of the system under test is tested, a simulated fault signal is superimposed on the historical data to obtain the third test data.

[0049] Specifically, the test data can be determined in the following ways according to the embodiments of this application:

[0050] (1) Historical data playback mode: The system accurately retrieves the original data files from the long-term stored industrial data warehouse by tag name, time range and sampling frequency, and reconstructs them into a data stream that conforms to the data acquisition interface specification. For example, if the test requirement is "to verify the stability of the predictive maintenance model during three months of normal operation", the system automatically loads the original SP, PV and OP sequences of all target devices during this period, and reassembles them into continuous UpdateValueRequest messages at 100-millisecond intervals according to the original timestamp, ensuring that the injected data is completely consistent with the history in terms of frequency, fluctuation pattern and noise characteristics.

[0051] The core objective of the historical data playback mode is to losslessly reproduce the complete dynamic behavior of real equipment during its historical operating cycle, providing a benchmark data stream with statistical authenticity and temporal continuity for testing. Its implementation process consists of three stages: data extraction, time-series reconstruction, and protocol encapsulation. Specifically, the system precisely retrieves the original data file from the industrial data storage system by tag name, acquisition time range, and sampling period. This file is typically in structured binary format or a standard time-series database (such as HDF5 or proprietary industrial formats), containing the numerical sequence of each monitoring point, acquisition timestamp (accurate to milliseconds), and original data quality code. After reading the file, the system resamples and interpolates the data according to the original acquisition frequency (e.g., 100 milliseconds, 1 second) to ensure complete timeline alignment and avoid signal distortion caused by inconsistent sampling rates. Subsequently, in the data injection stage, the system encapsulates each historical data point into an UpdateValueRequest message conforming to the gRPC collector interface definition, according to industrial protocol specifications. This message includes the tag name, numerical value, timestamp accurate to milliseconds, and original data quality code. This process strictly maintains the temporal order and sampling rhythm of the original data, without introducing any human interference.

[0052] The advantage of this mode is that the injected data completely replicates the real working conditions in terms of statistical distribution, fluctuation characteristics, and noise patterns. It is suitable for scenarios such as verifying the baseline performance, long-term stability, and false alarm rate assessment of equipment monitoring applications under normal operating conditions.

[0053] (2) Simulated data generation mode: Based on physical laws or statistical models, a virtual data stream that conforms to engineering logic is generated. That is, according to engineering logic and test objectives, a completely virtual test data stream that conforms to industrial physics and protocol specifications is dynamically constructed to cover extreme, abnormal or hypothetical working conditions not covered by historical data. Specifically, the system receives test scenario parameters specified by the user through the configuration file, such as: "Linearly increase the temperature sensor value from 25℃ to 180℃ within 5 seconds, and force the data quality code to 0 at the 3rd second" or "Apply a sinusoidal disturbance with an amplitude of ±15% to the pressure signal at a frequency of 2Hz for 2 minutes". Furthermore, based on these instructions, the system calls built-in mathematical function modules, such as linear ramp function, sine wave generator, step function, Poisson random pulse, Gaussian white noise, etc., to calculate the numerical output at each time point in real time. At the same time, according to preset rules, the system inserts data quality code change events (such as periodically setting to "bad quality"), signal jump events (such as suddenly jumping from normal value to over-limit value) or communication interruption simulations (such as continuously discarding 20 sampling points) at specified times.

[0054] To ensure the industrial compliance of the generated data, the system embeds a protocol constraint verification layer during the generation process. For example, all label names must come from the legal data dictionary of the system under test; the numerical range must conform to the device's measurement range; the timestamp must use the system's unified time base (such as NTP synchronization time); and the data quality code must adopt industry standard encoding (such as 192, 128, 0, etc.), and illegal values ​​are prohibited.

[0055] This mode is particularly suitable for testing the robustness of algorithms under extreme boundary conditions. For example, whether the system can remain safely shut down when the sensor fails completely (data quality is 0), and whether the diagnostic engine can correctly prioritize when multiple devices simultaneously trigger over-limit alarms, so as to shift the test from reviewing reality to predicting the unknown.

[0056] (3) Hybrid Mode: The physical fault mechanism of industrial equipment is transformed into mathematical operation rules and applied point by point on the real data stream. Its core is to accurately superimpose the fault disturbance signal driven by the physical model on the background of real historical data, thereby constructing test data that is "close to reality but contains controllable anomalies", and realizing high-fidelity verification of the ability of equipment monitoring application to identify faults in real noise. Specifically, the implementation of hybrid mode can be divided into three stages: base data loading, fault model matching and signal fusion superposition. In the first stage, the system selects a complete data stream that matches the target equipment and time period from the historical database as the base, including all relevant process parameters (such as setpoint SP, feedback value PV, control output OP, etc.), and aligns them according to the original timestamp to ensure the authenticity of the background signal. In the second stage, the system calls the corresponding industrial equipment fault physical model according to the test requirements. Taking "valve stickiness fault" as an example, the system loads a "viscous-slip" mechanical model: when the controller output (OP) changes effectively (ΔOP > dead zone threshold), the system calculates the cumulative deviation between the current OP and PV; if the deviation does not exceed the "static friction threshold", the PV value is forced to remain unchanged (simulating valve sticking); when the cumulative deviation accumulates to the threshold, PV jumps to the theoretical equilibrium position instantly, forming a "stepped response"; then the system resets the deviation count and waits for the next trigger. In the third stage, the system superimposes the above fault disturbance signals onto the original historical PV data item by item according to time points, while SP and OP remain unchanged, ensuring that only the target variable is modified. The entire superposition process must meet three major constraints: time synchronization, consistent sampling rate, and data type compatibility. Moreover, the quality code of the superimposed data must be dynamically adjusted according to the fault characteristics (such as maintaining "good quality" during the stickiness period, because the fault is mechanical rather than sensor failure).

[0057] The engineering advantage of this model lies in the fact that it retains the complex background noise caused by real process fluctuations (such as load fluctuations, ambient temperature drift, and interference from other equipment), while embedding reproducible, quantifiable, and adjustable fault characteristics. This allows the diagnostic capabilities of the equipment monitoring algorithm to be tested in a real interference environment. For example, it can verify whether the algorithm can still accurately distinguish between similar responses caused by "viscous" and "improper control parameter tuning" in the presence of multivariate coupled fluctuations, thereby significantly improving the accuracy of diagnosis and engineering applicability.

[0058] The above three modes construct a comprehensive test data generation system covering three types of test requirements: "real-world, extreme-world, and fault-world." This transforms the testing of industrial instrumentation and control equipment monitoring systems from a single, passive playback mode to a multi-modal, proactive, and semantically accurate simulation verification platform. By distinguishing and processing the three types of test requirements separately, the system can verify the stability of algorithms under real-world conditions, detect system limits under extreme conditions, and verify diagnostic accuracy in fault response. The three work together to form a complete test closed loop.

[0059] In some embodiments of this application, since the system is connected in parallel with the monitoring system of the industrial instrumentation and control equipment under test, data is injected through the standard UpdateValue interface of its data acquisition component (such as a gRPC collector) without interrupting or interfering with the normal data flow originating from the real device. Therefore, during the testing process, the normal data flow can be shielded for testing, or the test data can be combined with the normal data flow for joint testing.

[0060] (1) Block the normal data stream and inject test data independently.

[0061] The goal of this approach is to create a fully controlled testing environment where the device monitoring app only receives simulated data injected by the testing system, thus eliminating interference from real industrial signals. For example, the testing system establishes a secure connection with the target gRPC collector through pre-set connection information, completes authentication, and obtains legitimate data injection permissions. It then sends configuration commands to the gRPC collector's management interface, triggering the collector's internal data source arbitration module (it should be noted that the gRPC collector, as the central hub for data access, possesses multi-source data priority management and input routing control capabilities), automatically closing all raw data subscription channels from the OPC UA server. This causes real device data to be actively discarded or marked as invalid by the system, preventing it from entering the processing flow. The testing system continuously injects complete simulated test data packets into the collector through the authenticated gRPC interface. These packets contain standard tag names, values, timestamps, and quality codes, ensuring the format is completely consistent with real data. In shielded mode, the gRPC collector only uses the injected simulated data as the sole valid input source, forwarding it to the device monitoring app, ensuring that all data received and processed by the app originates from the testing system.

[0062] (2) Mixed injection of test data and real data stream.

[0063] In this scenario, the testing system does not shield the real data stream. Instead, it overlays and merges the simulated test data with the normal operation data from the field equipment in the time dimension and injects them into the gRPC collector to form a composite data stream of "real background + artificial disturbance". This scenario is closer to the real operating environment and is used to evaluate the algorithm's ability to identify abnormal signals in real working conditions.

[0064] Specifically, the key input variables (such as PV, temperature, etc.) used by APPS for fault diagnosis are identified, and their unique label names are defined as the only injection and overriding targets. The original data sources such as OPC UA continuously inject real data from all other labels into the gRPC collector to maintain the real operating environment of the system. Within a specified time period, simulated fault data (such as stickiness, jumps, etc.) targeting only the target label are generated according to the timestamps and formats of the real data. Using the priority mechanism of the gRPC collector, the simulated data overwrites the real values ​​of the target label, while other label data remains unchanged, ensuring the integrity of the system logic. A baseline is recorded before the test begins, the APPS output is monitored during the test, and injection is immediately stopped after the test ends, restoring the pure real data stream and observing whether the diagnostic results return to normal. Simulated injection events and APPS responses (such as alarms, exponential changes) are precisely matched with millisecond-level timestamps to ensure that all diagnostic actions are triggered by simulated disturbances.

[0065] It should be noted that during the testing process, the system only injected simulated data overlay for a single core variable label (such as "Area1.FC-101.PV") used for fault diagnosis by the equipment monitoring APPS. All other related variables (such as setpoint SP, controller output OP, temperature, pressure, etc.) were continuously transmitted from real industrial equipment via the OPC UA acquisition link, ensuring that the system control logic, process dynamics, and multi-variable coupling relationships remained completely realistic. Since the APPS diagnostic algorithms (such as the "viscosity index") are calculated solely based on the state changes of this core label, while other input variables remained undisturbed, any abnormal fluctuations in the diagnostic output must be driven by the injected data for this label. The real data stream serves only as an unchanging background condition and does not possess the independent causal capability to trigger abnormal responses.

[0066] Furthermore, simulated data is injected into the gRPC collector with timestamps, sampling frequencies, and data formats that are completely identical to real data, forming a high-conflict data stream with the same label and time point. Based on the preset data source priority arbitration strategy, the collector automatically overwrites the original real value with simulated data, so that the data with this label received by APPS during the test period is 100% artificially constructed, and the real data only exists as background and does not participate in the decision-making.

[0067] Furthermore, simulated data is embedded with anomalous patterns that cannot be naturally generated by real devices (such as precise stillness, step jumps, and threshold abrupt changes) to form identifiable digital fingerprints. This ensures that any diagnostic response is triggered by a manually set perturbation, not by real noise or fluctuations. Finally, through millisecond-level time-series alignment, the synchronicity of APPS outputs and injected events, the pattern of response intensity changes, and the regression behavior after fault resolution are analyzed. Only when the response occurs only during the perturbation period, has a reasonable delay, matches in intensity, and recovers consistently can the causal relationship be considered with a confidence level ≥99.9%, and the real data stream is excluded as the cause.

[0068] In some embodiments of this application, when the test data is the second test data or the third test data, a timestamp and a quality code are added to each data point to obtain the target test data. The timestamp is used to simulate the timing of real data, and the quality code is used to test the fault tolerance of the system under test for data quality. The target test data is encapsulated based on the industrial data semantics specification carried by the upper-layer data interface to obtain a structured test data sequence.

[0069] Specifically, since both the second and third test data involve simulated data, in order to maintain consistency with real data, for the second test data (extreme conditions), the system can automatically assign the following to each generated data point according to the test scenario configuration: First, a precise millisecond-level timestamp, which is generated based on a high-precision clock source synchronized with the target system to ensure complete consistency with the real acquisition cycle; Second, a quality code is set as needed. For example, when simulating "communication interruption", the system inserts 5 points with a quality code of 0 in every 50 data points, or when an over-limit value occurs, the quality code is forcibly set to 128 (suspicious) to simulate the unreliable state of data after sensor drift.

[0070] For the third test data (fault superposition), the system can dynamically correct the quality code of the superimposed fault disturbance points while retaining the original timestamps of historical data. For example, in the valve viscosity simulation, although the PV value is artificially delayed, the fault is mechanical rather than sensor failure, so the system still maintains the quality code at 192 (good). When simulating "sensor signal attenuation", the system gradually reduces the quality code from 192 to 128 while superimposing the attenuation curve, and finally sets it to 0 when the signal is completely distorted. This mechanism ensures that the "abnormality" of the test data has real industrial semantics, rather than being a purely mathematical disturbance.

[0071] Furthermore, the elements of the target test data (label name, value, timestamp, quality code) are strictly mapped to the standard interface message structure defined by the gRPC collector (as an example), including: (1) Label mapping: Ensure that the label name of each data point (such as "Area1.FC-101.PV") is completely consistent with the data dictionary of the system under test, and prohibit spelling errors or unregistered names; (2) Value type matching: According to the signal type of industrial equipment (such as temperature is floating point type, switch quantity is Boolean type), the test value is forcibly converted to the corresponding data type to avoid parsing failure due to type mismatch; (3) Timestamp alignment: All timestamps are uniformly converted to the UTC standard time zone and strictly aligned with the internal time base of the gRPC collector, with an error of no more than 10 milliseconds; (4) Quality code compliance: According to industrial communication standards (such as IEC 62591, OPC) (UA specification), only predefined legal quality code values ​​are allowed. The system automatically intercepts illegal values ​​and records warnings; (5) Batch packaging: In order to improve injection efficiency, the system encapsulates multiple data points into a group of 10 to 50 as an UpdateValueRequest message to ensure high throughput and low latency of gRPC communication.

[0072] The final output of the structured test data sequence is completely consistent with the data from real devices in terms of format, semantics, and timing, making it impossible for the gRPC collector and the upper-layer device monitoring application to distinguish between real data acquisition and artificial simulation.

[0073] Step S206: Inject test data into the system under test through the upper-layer data interface of the system under test. The upper-layer data interface is used in the data link of the system under test to provide data services to the upper-layer application.

[0074] In step S206 above, the upper-layer data interface refers to the communication access point located in the data link of the industrial instrumentation and control equipment monitoring system (i.e., the system under test), which provides standardized data services to upper-layer applications (such as predictive maintenance, anomaly detection, optimization control, and other equipment monitoring APPS). This interface is located at the application layer entry point of the system architecture and does not involve the underlying field devices, PLCs, or OPC UA servers, etc. (it can be understood as the boundary interface between the processing layer and the application layer in the data link). It is only responsible for receiving structured and semantically complete time-series data and distributing it to various algorithm modules, including but not limited to the server interface of the gRPC collector, the WebSocket long connection channel, the MQTT topic subscription endpoint, the REST-based batch data push API, or the system's self-developed internal RPC service bus, etc.

[0075] A data link refers to the complete data transmission and processing path in an industrial instrumentation and control equipment monitoring system, starting from the collection of raw data from the underlying physical equipment, undergoing multi-level protocol conversion, data aggregation and service encapsulation, and finally being delivered to the application layer algorithm module for analysis and decision-making. It is not a single communication line, but an end-to-end data flow channel containing multiple functional entities, protocol layers, and data processing nodes. Its core objective is to reliably transmit raw signals from the industrial field to structured information that can be understood and used by upper-layer intelligent applications.

[0076] For example, the data link may include: industrial equipment management system → OPC UA server → data acquisition component (such as gRPC collector) → equipment monitoring APPS. This application embodiment does not interfere with the first three layers (i.e., it does not modify the field equipment, OPC UA server, or data transmission medium), but only injects simulated test data into the equipment monitoring APPS through the upper-layer data interface exposed by the gRPC collector. This achieves independent, secure, and highly controllable testing of the latter half of the system (from the collector to the APPS), completely avoiding the impact and dependence of traditional testing methods on the underlying system.

[0077] In some embodiments of this application, when the system under test uses gRPC as its upper-layer data interface, the injection client first establishes a long-term connection with the gRPC collector based on configuration information (such as IP address and port), and completes authentication through the Verify RPC method to obtain a valid session token. Subsequently, the client packages the encapsulated structured test data sequence (including tag name, value, timestamp, and quality code) according to the UpdateValueRequest message format defined in the protocol. To improve efficiency, the system supports batch injection, such as sending a request packet consisting of 10-50 data points continuously to the collector via a streaming channel. After receiving the data, the collector pushes it to all device monitoring apps subscribed to that tag according to standard procedures, achieving transparent injection.

[0078] When the system under test does not use gRPC, but instead uses WebSocket or MQTT as the upper-layer data access protocol, the injection client adopts a more adaptable asynchronous publishing mode. For example, in the WebSocket scenario, the client establishes a secure long-lived connection with the system and continuously publishes test data to a specified data channel (such as " / sensor / inject") through a predefined JSON format message body (e.g., {"tag": "Area1.FC-101.PV", "value":65.3, "timestamp": 1712345678901, "quality": 192}). In the MQTT scenario, the client acts as the publisher, publishing data with the same structure as a UTF-8 encoded string to a specific topic (e.g., "industrial / testdata / valve1"), which is then received and distributed to the device monitoring apps by the system's internal subscription broker.

[0079] In some embodiments of this application, test data can be injected into the system under test in the following ways: establish a connection with the upper-layer data interface based on the configuration information of the system under test, and perform identity verification based on the authentication protocol of the upper-layer data interface to obtain a verification result; if the verification result indicates successful verification, construct the test data into a request message; and inject the test data into the system under test through the request message.

[0080] It should be noted that the configuration information refers to the set of system parameters necessary for establishing communication with the upper-layer data interface, including the interface's network address, port number, communication protocol type, session timeout settings, certificate path, etc. Its function is to provide a connection key for the test system, ensuring that the injection client can accurately locate the target service and establish a secure channel.

[0081] Specifically, if the upper-layer data interface is a gRPC service, the system will load the address and port (e.g., 10.10.58.222:32567) and establish a secure channel according to the protocol type (TCP / TLS); if it is a WebSocket, a connection request will be initiated through the HTTP Upgrade mechanism. During the connection establishment process, the system automatically detects network reachability, port open status, and service response, and triggers a retry mechanism in case of failure (e.g., a maximum of 5 retries, each with a 2-second interval), ensuring that the connection can still be restored after a brief network jitter, laying the communication foundation for subsequent verification.

[0082] Furthermore, the authentication request is initiated according to the authentication process defined by the interface. For example, if the interface uses a custom Verify RPC method, the client will construct an authentication request containing the device identifier and key, and send it to the gRPC collector. After internally verifying the key validity, device registration status, and access permissions, the collector returns a success response (carrying the session ID) or a failure response (such as "insufficient permissions" or "key expired"). After receiving the response, the system determines the verification result based on the return code. If successful, the session ID is cached for subsequent request signing; if it fails, an error log is recorded and the test process is terminated to avoid invalid injection.

[0083] Furthermore, based on the semantic specifications of the interface, the test data enhanced with timestamps and quality codes is mapped into a message structure that conforms to the protocol requirements. For example, if the interface requires each request message to contain multiple NamedValue entries, the system encapsulates a set of test data (such as valve position PV, setpoint SP, controller output OP) into an UpdateValueRequest. Each entry is precisely filled with a name, value, millisecond-level timestamp, and compliant quality code (such as 192), ensuring that the field order, data type (floating-point / boolean / integer), and encoding format (UTF-8) all conform to the protocol definition. Any format deviation is intercepted and an error is reported.

[0084] Finally, using the established connection and verified session, the encapsulated request message is continuously sent to the interface.

[0085] In the above embodiments, through the dual locking mechanism of configuration information and authentication protocol, only legitimate testing platforms can access the system, ensuring that the production environment is free from illegal interference. The request message fully complies with the interface semantic specification, making it impossible for the device monitoring APPS to recognize it as simulation data. This achieves a verification effect of seamless injection and real response.

[0086] Step S208: Receive the response result of the system under test after the test data is injected, and determine the test result based on the response result.

[0087] In step S208 above, the response result refers to the dynamic output feedback made by the internal device monitoring APPS and related services of the system under test after receiving the test data injection. This includes, but is not limited to: diagnostic output of the algorithm module (such as changes in the "stickiness index" value, fault warning signals), system resource usage (such as CPU load, memory usage), service processing latency, and log event recording (such as abnormal alarms, data discard prompts), etc. The test result refers to the final evaluation conclusion obtained after structured analysis, quantitative comparison, and logical judgment based on the response result. It is used to determine the functional integrity, performance compliance, and system robustness of the device monitoring APPS in a specific test scenario.

[0088] In some embodiments of this application, the response results include the intermediate state of the upper-layer application after test data injection and the warning events issued by the system under test. Based on this, the test results can be determined using the response results in the following manner: A first time axis corresponding to the intermediate state and a second time axis corresponding to the warning events are determined, wherein the first time axis represents the response behavior of the upper-layer application to the fault characteristics in the test data, and the second time axis represents the sequence of occurrence times of the warning events after test data injection; the first time axis, the second time axis, and a third time axis corresponding to the test data are aligned to obtain an alignment result, wherein the third time axis represents the sequence of fault simulation events in the test data; the test results are determined based on the alignment result.

[0089] It should be noted that the intermediate states of the upper-layer application are the internal calculation intermediate values ​​generated by the algorithm module during the processing of test data, such as "viscosity index", "vibration trend coefficient", and "energy efficiency deviation". These values ​​reflect the algorithm's dynamic analysis process of data characteristics. The early warning events issued by the system under test are the diagnostic alarms or maintenance prompts triggered by the system according to preset rules, such as "valve viscosity risk level increased" and "sensor abnormal fluctuation". These events are the final decision signals output by the algorithm.

[0090] The first timeline refers to the time sequence trajectory formed by the evolution of intermediate states of the upper-level application over time. It accurately depicts the algorithm's response process to fault characteristics in the test data. For example, when simulating a viscous valve fault, the "viscous index" calculated by the system in real time slowly climbs from the normal value of 0.2 to 0.8. This continuous change constitutes the first timeline. Its role is to reveal whether the algorithm can promptly perceive and quantify the gradual evolution of the fault, rather than only reacting when the fault is significant. The second timeline refers to the time sequence formed by the warning events actually triggered by the system during the test. It reflects the final output moment of the algorithm from perception to decision. For example, after the viscosity index exceeds the threshold, the system first issues a "Level 1 warning" at 3 hours, 15 minutes, and 02 seconds, and upgrades it to a "Level 2 alarm" at 3 hours, 22 minutes, and 17 seconds. The time points of these events constitute the second timeline. The third timeline refers to the set of time stamps corresponding to the sequence of fault simulation events injected by the test data generation engine. It accurately records the fault trigger points, intensity switching points, and recovery times set manually in the test scenario. For example, in the "valve viscosity test", the third timeline includes key events such as: starting to inject viscous disturbance at the end of the 3rd hour, increasing the static friction threshold from 1% to 3% at the end of the 3rd hour and 30 minutes, and stopping injection at the end of the 5th hour. It is used as a time benchmark for test behavior and provides an objective reference for the alignment and evaluation of all subsequent response behaviors.

[0091] Specifically, after obtaining the first and second time axes, event tagging and interpolation alignment algorithms can be used to achieve millisecond-level precise matching across data sources, including:

[0092] (1) Precise alignment based on event ID: When injecting test data, the system generates a unique global event identifier (such as UUID) for each fault simulation event and marks the event in the third time axis. At the same time, when the test data is injected into the gRPC collector, the identifier is written into the extended field of the data packet. When the device monitoring APPS processes the data and generates an intermediate state or warning event, the system embeds the same event ID in the output. The alignment module can achieve direct association from the injected event to the response behavior by scanning all response data and matching the ID, without relying on clock synchronization, which greatly improves the alignment accuracy.

[0093] (2) Time-interpolation-based assisted alignment: In cases where some systems cannot embed event IDs, the system uses dynamic time window interpolation. For example, if the "static friction threshold increase" in the third time axis occurs at 3 hours and 30 minutes, the system searches for the most significant inflection point of the "viscosity index" within 10 seconds before and after that moment in the first time axis and determines the corresponding moment by the rate of change of the curve slope; it searches for the moment when the "level 2 warning" first appears in the second time axis. If the deviation between the two and the third time axis is within ±200 milliseconds, it is considered to be effectively aligned; otherwise, manual review is triggered.

[0094] Furthermore, based on the aligned time relationship, multiple quantitative performance indicators are calculated, such as: (1) First alarm delay: Calculate the time difference between the first warning event in the second time axis and the fault start time in the third time axis. If it is less than 3 seconds, it is judged as "timely response"; (2) Feature response consistency: Analyze whether the upward trend of the equipment health status feature quantity (such as "viscous index") in the first time axis is positively correlated with the fault intensity change in the third time axis (such as the index jumps after the threshold is increased). If the correlation coefficient is >0.85, it is judged as "accurate feature recognition"; It should be noted that the equipment health status feature quantity refers to a single or composite numerical indicator that can objectively reflect the current operating health status or deterioration trend of the equipment by the equipment monitoring algorithm based on the collected multi-dimensional operating data, through signal processing, pattern recognition or physical modeling and other means. (3) Alarm coverage rate: Statistically determine whether the warning event in the second time axis continues to exist without interruption during the fault period defined in the third time axis. If the coverage rate is above 98%, it is judged as "no missed alarm".

[0095] Ultimately, the system integrates the above indicators into test conclusions and generates a visual report, achieving automated transformation from raw response data to engineering decisions.

[0096] Through steps S202 to S208, simulated test data is injected through the upper-layer data interface. The test plan is parsed to determine the test data that meets the target test scenario. The test data is injected non-intrusively using the standard data service interface of the system under test for upper-layer applications. The system response results are received to evaluate its behavior. This achieves the goal of controllable and reproducible testing without changing the underlying system architecture. This realizes the technical effect of independent or combined verification and performance evaluation of upper-layer components in the data link. It also solves the technical problem of the test methods used in related technologies that inject data directly into the underlying server by modifying the system configuration, resulting in strong intrusion and poor flexibility of the system under test.

[0097] Figure 3 This is a flowchart of a test data injection method according to an embodiment of this application, such as... Figure 3 As shown, the method includes:

[0098] Step S302: Receive test data, wherein the test data is determined based on the test requirements of the system under test.

[0099] Step S304: The test data is injected into the system under test through the upper-layer data interface of the system under test. The upper-layer data interface is used in the data link of the system under test to provide data services to the upper-layer application.

[0100] In some embodiments of this application, test data can be injected into the system under test (SUT) through the upper-layer data interface of the SUT in the following manner: a connection is established with the upper-layer data interface based on the configuration information of the SUT, and identity verification is performed based on the authentication protocol of the upper-layer data interface to obtain a verification result; if the verification result indicates successful verification, the test data is constructed into a request message, wherein the request message is constructed based on the industrial data semantic specification carried by the upper-layer data interface; and the test data is injected into the SUT through the request message.

[0101] It should be noted that, Figure 3 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 2 The corresponding solutions in the illustrated embodiments will not be described in detail here.

[0102] Figure 4 This is a schematic diagram of the structure of a testing system according to an embodiment of this application, such as... Figure 4 As shown, the system includes: a system under test 402, a test scenario manager 404, a simulation data generation engine 406, an injection client 408, and a monitoring and analysis module 410, wherein:

[0103] The Test Scenario Manager 404 is connected to the simulation data generation engine and is used to obtain the test plan of the system under test. The test plan reflects the test requirements of the system under test in the target test scenario.

[0104] In some embodiments of this application, the test scenario manager is connected to the injection client, and the test scenario manager is also used to control the injection client to execute tests in the order of execution of at least one target test scenario in the test plan.

[0105] The simulation data generation engine 406 connects to both the test scenario manager and the injection client to determine the test data corresponding to the test requirements.

[0106] In some embodiments of this application, the simulation data generation engine is further configured to: determine the historical data of the system under test as the first test data when the test requirements indicate that the real operating conditions of the system under test should be reproduced; generate the second test data for simulating the extreme operating conditions when the test requirements indicate that the system under test should be tested; and superimpose the simulated fault signal on the historical data to obtain the third test data when the test requirements indicate that the fault response of the system under test should be tested.

[0107] The injection client 408 is connected to both the simulation data generation engine and the system under test (SUT). It is used to inject test data into the SUT through the upper-layer data interface of the SUT. The upper-layer data interface is used in the data link of the SUT to provide data services to the upper-layer application.

[0108] In some embodiments of this application, the data link of the system under test includes a data acquisition service component, wherein the data acquisition service component is used to provide an upper-layer data interface for injecting test data.

[0109] It should be noted that the data link of the system under test refers to the complete data transmission path in the industrial instrumentation and control equipment monitoring system from the underlying field devices through the data acquisition middleware to the upper-layer diagnostic algorithm application. For example: industrial field devices → OPC UA server → data transmission medium → data acquisition service component → equipment monitoring algorithm application (APPS). Among them, the data acquisition service component is a middleware module deployed in the industrial instrumentation and control system architecture, responsible for receiving real-time industrial data from data sources such as OPC UA servers, and providing data services to the upper-layer equipment monitoring application using standardized protocols (such as gRPC). Its core function is to realize unified data access, format encapsulation, and distribution.

[0110] The monitoring and analysis module 410 is connected to both the injection client and the system under test, and is used to receive the response results of the system under test after the test data is injected, and to determine the test results based on the response results.

[0111] It should be noted that, Figure 4 The test system shown is used to perform Figure 2 The test method shown, therefore Figure 2 The relevant explanations in the test methods also apply to Figure 4 The test system shown will not be described in detail here.

[0112] Figure 5 This is a schematic diagram of the overall test process of a test method according to an embodiment of this application, as shown below. Figure 5 As shown, in some embodiments of this application, the following are included:

[0113] Step 502: The test scenario manager sends control signals to the simulation data generation engine. Specifically, based on the preset test plan, the test scenario manager sends control signals containing test mode, duration, disturbance parameters, and target labels to the simulation data generation engine, triggering the construction process of specific fault scenarios and realizing the automated orchestration and stage scheduling of the test process.

[0114] Step 504: The simulation data generation engine generates a test data stream based on the control signal. Specifically, after receiving the control signal, the simulation data generation engine selects historical data playback, pure simulation generation, or a hybrid mode according to the specified mode. Based on the industrial data format and time reference, it constructs a test data stream that conforms to the target label semantics, sampling frequency, and quality code specifications, ensuring that the data is consistent with the real data in terms of structure and semantics.

[0115] Step 506: The injection client performs a standard gRPC call (UpdateValue) based on the control signals of the test scenario manager and the test data stream. Specifically, under the scheduling instructions of the test scenario manager, the injection client reads the current test data stream, encapsulates it into an UpdateValue request message according to the gRPC protocol specification, including a tag identifier, value, precise timestamp, and data quality code, and initiates a standard remote procedure call through an authenticated network channel to achieve compliant injection of test data.

[0116] Step 508: The gRPC collector of the system under test receives the test data and inputs it into the algorithm APPs. Specifically, the gRPC collector of the system under test receives the UpdateValue request from the injection client, determines that the test data takes precedence over the original data from the OPC UA server according to the preset data source priority arbitration mechanism, completes the overwrite operation of the same-label data, and forwards the processed data stream to the algorithm application module according to the original protocol format to ensure the controllability and consistency of the input data.

[0117] Step 510: The algorithm applications respond to the test data. Specifically, the algorithm application module performs real-time diagnostic calculations based on the received test data. Its internal logic triggers expected responses based on the temporal characteristics and correlations of the input variables, such as an increase in the fault index or the generation of warning signals. The response behavior is entirely driven by the construction characteristics of the injected data and is not affected by the underlying production data.

[0118] Step 512: The monitoring and analysis module monitors the algorithm output and the performance of the system under test. Specifically, the monitoring and analysis module synchronously collects the algorithm application's output logs, system resource utilization, processing latency, and service status, and correlates them with the timeline of injected events with high precision to achieve dynamic evaluation and behavior tracking of the algorithm's performance, forming quantifiable test evaluation criteria.

[0119] Step 514, optionally, involves the physical device and the OPC UA server generating a normal production data stream, which is used in conjunction with the test data for testing. Specifically, the physical device and the OPC UA server continuously generate a normal production data stream as an input source for non-test tags, maintaining the authenticity of the system control logic and process dynamics. This ensures that only the target diagnostic tags are artificially disturbed in the test environment, while other variables remain completely authentic, achieving locality of test disturbance and integrity of the overall system state.

[0120] Figure 6 This is a flowchart of the simulation data generation engine for a testing method according to an embodiment of this application, as shown below. Figure 6 As shown, the steps performed by the simulation data generation engine include:

[0121] S602, Select Data Generation Mode. Specifically, the simulation data generation engine selects a data generation mode that suits the current test target based on the control instructions issued by the test scenario manager. It supports three operating modes: historical data playback, pure simulation generation, or hybrid mode, ensuring the flexibility and scalability of the test scenario.

[0122] S604a, in historical data playback mode, reads historical data sequences from a file. Specifically, in historical data playback mode, the engine reads the tag sequence from a pre-stored industrial time-series data file according to the original sampling period, reconstructs the numerical change trajectory during the actual operation, and retains the time distribution characteristics and statistical characteristics of the original data as the basic background for testing.

[0123] In simulation data generation mode, S604b generates data sequences based on a configured mathematical model. Specifically, in simulation data generation mode, the engine dynamically calculates and generates numerical sequences that conform to industrial data type specifications based on predefined physical fault models and mathematical functions, including but not limited to non-natural timing characteristics such as step jumps, ramps, periodic oscillations, and dead zone abrupt changes, to simulate extreme or hypothetical operating conditions.

[0124] In hybrid mode, the S604c combines historical data with simulation rules to generate data sequences. Specifically, in hybrid mode, the engine uses historical data sequences as a base and superimposes disturbance signals generated by the simulation model within a specified time interval. Through a nonlinear fusion algorithm, it achieves spatiotemporal coupling of real fluctuations and human-caused fault characteristics, forming composite test data that is close to reality but controllable.

[0125] S606 adds a timestamp and quality code to each data point. Specifically, the engine adds a timestamp accurate to the millisecond level to each generated data point to ensure that it is synchronized with the data acquisition time of the industrial system, and assigns a data quality code according to preset rules to represent the data validity status, such as good quality, bad quality, or unknown quality, to meet the semantic requirements of industrial protocols for data credibility.

[0126] S608 outputs a structured test data sequence. Specifically, the engine encapsulates all data points into a unified data sequence in a structured format of label name, value, timestamp, and quality code, and outputs it to the injection client. This ensures that the data maintains integrity, consistency, and parsability during transmission and processing, supporting accurate calls to the subsequent gRPC protocol.

[0127] Figure 7 This is a flowchart of the injection client workflow of a testing method according to an embodiment of this application, as shown below. Figure 7 As shown, it includes:

[0128] S702 reads the configuration to connect to the gRPC server. Specifically, the injection client reads the preset network configuration information, including the gRPC collector's address, port, communication protocol version, and authentication parameters, and establishes a low-level network connection channel with the target server to ensure the reachability and protocol compatibility of the communication link.

[0129] S704 calls the Verify interface for authentication. Specifically, the client, in accordance with industrial system security standards, calls the Verify interface provided by the gRPC collector, submits pre-set identity credentials and session keys, completes the two-way authentication process, and ensures the legality and controllability of the test operation.

[0130] S706 determines whether authentication was successful. Specifically, the client determines the validity of the authentication status based on the response returned by the Verify interface, serving as a prerequisite for subsequent data injection operations and preventing unauthorized access from interfering with the production system.

[0131] S708: In the event of authentication failure, the authentication error is logged. Specifically, if authentication fails, the client logs the error type and timestamp, including reasons such as invalid credentials, insufficient permissions, or network interruption, providing traceable diagnostic evidence for debugging and auditing.

[0132] Upon successful authentication, the S710 receives a sequence of test data. Specifically, after successful authentication, the client receives a structured test data sequence from the simulation data generation engine, caches the set of data points to be injected, and prepares the data for batch construction of request messages.

[0133] S712, Construct UpdateValueRequest messages. Specifically, the client encapsulates each piece of test data into an UpdateValueRequest message that conforms to the gRPC protocol definition, including the tag name, value, precise millisecond-level timestamp, and data quality code, ensuring that the message structure is completely consistent with the collector's expected format and guaranteeing semantic correctness.

[0134] S714 calls the UpdateValue interface via gRPC. Specifically, the client calls the UpdateValue interface synchronously or asynchronously through the established gRPC channel, sending the encapsulated request message to the gRPC collector and triggering the data injection process.

[0135] S716, determine whether the injection was successful. Specifically, the client determines whether the injection operation was successful based on the response code and status information returned by the interface, including abnormal situations such as network timeout, service rejection, or invalid parameters.

[0136] S718: If the injection is successful, record the success and prepare the next batch of data. Specifically, if the injection is successful, the client records the operation log, updates the local send counter, and retrieves the next batch of test data from the pending queue, maintaining a continuous and stable data injection rhythm.

[0137] In the case of injection failure, the S720 logs the error and retryes or terminates according to the strategy. Specifically, if injection fails, the client executes an automatic recovery mechanism according to the preset retry strategy, supporting a limited number of exponential backoff retries; if the retry threshold is exceeded or an unrecoverable error is encountered, the current test process is terminated and an alarm is triggered to ensure the controllability of the test process and the security of the system.

[0138] Figure 8 This is a flowchart of a test scenario manager for a test method according to an embodiment of this application, as shown below. Figure 8 As shown, it includes:

[0139] S802, Load Test Scenario Configuration. Specifically, the Test Scenario Manager loads predefined scenario configuration files, parses a complete test plan containing test objectives, mode selection, timing parameters, injection tags, fault models, and monitoring metrics, forming a set of executable test tasks to achieve standardization and reproducibility of the testing process.

[0140] S804 executes the test plan for each scenario. Specifically, the manager schedules each test scenario sequentially according to the configured order, ensuring that multi-stage and multi-mode test tasks are executed serially or in parallel according to predetermined logic, supporting complex verification requirements such as long-term stability, stress testing, and fault injection.

[0141] S806 initializes the data generation engine and injection client. Specifically, before each scenario starts, the manager initializes the simulation data generation engine and injection client, loads the parameters required for the corresponding mode, establishes communication connections, and completes resource pre-allocation and state initialization to ensure the continuity and consistency of test execution.

[0142] S808 determines whether the scenario has timed out. Specifically, the manager continuously monitors the current scenario's runtime, compares it with the configured duration, and determines whether the preset end point has been reached, thus achieving precise control over the test cycle.

[0143] S810 generates test data for the current cycle if the timeout does not occur. Specifically, if the timeout does not occur, the manager triggers the simulation data generation engine to generate the data sequence required for the current cycle, and dynamically outputs test data points that meet the timestamp and sampling frequency requirements according to the selected mode, ensuring that data generation is synchronized with the testing rhythm.

[0144] S812, invokes the client to inject data. Specifically, the manager invokes the injection client to perform a data injection operation, sending the test data of the current period to the gRPC collector. The driver device monitoring algorithm receives the controlled input, realizing the precise application of test disturbances.

[0145] S814, waits for the next cycle or reaches the traffic threshold. Specifically, after injection is completed, the manager enters a waiting state, determining the timing of the next injection based on the configured cycle interval or traffic threshold to avoid data overload and maintain system load within a stable range.

[0146] S816, in the event of a timeout, the scenario ends and the monitoring data for this scenario is collected. Specifically, when the scenario times out, the manager terminates the data generation and injection process, actively collects the algorithm output, system performance, and abnormal event data recorded by the monitoring and analysis module, forming a snapshot of the phased test results to provide a data foundation for subsequent analysis.

[0147] S818, all scenarios have been executed. Specifically, the manager executes all preset scenarios sequentially to ensure that the test covers all set conditions and achieves end-to-end system verification.

[0148] S820 generates an overall test report. Specifically, after all scenarios are completed, the manager integrates monitoring data, injection events, and diagnostic response records from each stage, and generates a structured test report based on a preset evaluation model. This report includes timing alignment analysis, response consistency indicators, and system impact assessment, thus completing the test loop.

[0149] To facilitate understanding of the testing methods of this application, the following explanation is provided in conjunction with some specific embodiments.

[0150] Test objective: To verify whether the "Early Warning Model for Valve Stickiness Fault" in the equipment monitoring APPS can detect the initial signs of slow response (stickiness) in the control valve in a timely and accurate manner.

[0151] Phase 1: Test scenario definition and configuration.

[0152] Step 1.1: Determine the test object and interface.

[0153] Target System: Locate the gRPC data acquisition unit responsible for data intake in the monitoring system of the industrial instrumentation and control equipment under test, and record its network address and authentication information; Target Equipment and Data Points: Determine the physical equipment to be simulated as a control valve, whose key monitoring parameters include:

[0154] (1) Valve position setting value (SP): Label name Area1.FC-101.SP;

[0155] (2) Valve position feedback value (PV): Label name Area1.FC-101.PV;

[0156] (3) Controller output (OP): Tag name Area1.FC-101.OP.

[0157] Theoretical basis: The typical characteristic of viscous faults is that when the controller output OP changes, the valve position feedback PV cannot follow smoothly, resulting in a "step-like" change or response delay.

[0158] Step 1.2: Configure the simulation data generation strategy.

[0159] Create a scenario named Valve_Stiction_Fault_Test in the Test Scenario Manager and configure it as follows: Baseline Operating Condition (Background Noise): Use "Historical Playback Mode" and import historical data files of the control valve running under normal conditions for 24 hours as the test background and benchmark. This data provides a realistic process fluctuation background; Fault Injection Logic: Use "Hybrid Mode" to overlay simulated viscosity effects on top of the normal historical data, configured as follows:

[0160] (1) Triggering condition: When the change in OP is detected to exceed the dead zone threshold (e.g., 0.5%), viscous simulation is triggered.

[0161] (2) Fault model: The “viscous-sliding” model algorithm is adopted. When the OP changes and triggers the fault, the PV value will remain unchanged for a short time (viscous stage). Only when the accumulated difference between OP and PV exceeds a simulated “static friction” threshold will PV suddenly jump (sliding stage) to a new equilibrium position.

[0162] (3) Fault severity parameters: The static friction threshold (e.g., 1% for simulating slight viscosity and 3% for moderate viscosity) and viscosity duration can be configured.

[0163] (4) Implementation period: Configure this fault simulation logic to be enabled between the 3rd and 5th hour after the start of the test.

[0164] Step 1.3: Configure data injection and monitoring. Injection parameters: Set the data injection frequency to 100ms / point to match the scanning cycle of most industrial systems. Enable flow control to prevent overload; monitoring item configuration includes:

[0165] (1) Application output: The output of the "valve health" module in the APPS is monitored by the designated monitoring equipment, especially the calculated value of "viscosity index" and the "pre-maintenance alarm" signal.

[0166] (2) System metrics: Monitor the CPU / memory usage of the server where the gRPC collector is located and assess the load brought about by the injected test data.

[0167] Phase 2: Automated test execution.

[0168] Step 2.1: System Initialization and Connection Establishment. Start the Valve_Stiction_Fault_Test scenario; test the scenario manager command gRPC protocol adaptation and injection to establish a connection between the client and the target address, complete authentication, and obtain a valid session ID.

[0169] Step 2.2: Background Data Stream Injection (Hours 0-3). The simulation data generation engine starts and enters "historical playback mode"; the engine strictly reads normal historical data of the SP, PV, and OP tags according to the original time series (100ms interval), generating a (SP_normal, PV_normal, OP_normal) data stream; the gRPC client encapsulates this data stream into continuous UpdateValueRequest messages and injects them stably into the system. At this time, the data received by the device monitoring APPS is identical to the historical data, and the "stickiness index" should be within the normal range.

[0170] Step 2.3: Sticky Fault Overlay Injection (Hours 3-5). Upon reaching the preset 3rd hour, the simulation data generation engine automatically switches to "Mixed Mode." For each new data point: the engine reads historical base values ​​(SP_base, PV_base, OP_base); the fault simulation algorithm calculates in real-time: it determines the change in OP_base relative to the previous time step, ΔOP. If |ΔOP| > 0.5% (dead zone threshold), it enters the sticky simulation logic, including:

[0171] (1) Calculate the deviation between the cumulative OP and the current PV output value.

[0172] (2) Judgment: If the cumulative deviation is less than the preset "static friction" threshold (e.g., 1%), the output value of PV will remain unchanged from the previous moment (simulating viscosity).

[0173] (3) Triggering sliding: If the cumulative deviation is greater than or equal to the threshold, then the output value of PV = PV_base + cumulative deviation The slip factor (simulating sudden slippage) is then used to reset the cumulative deviation.

[0174] If |ΔOP|≤0.5%, then the PV output value = PV_base. Finally, the generated and output test data is: SP_test=SP_base, OP_test=OP_base, PV_test=the value processed by the above algorithm. This data stream, containing artificially created "PV response delay and step-by-step transition" characteristics, is continuously injected into the system.

[0175] Step 2.4: Restore to normal data (after 5 hours). After 5 hours, the fault simulation algorithm stops; the engine reverts to pure "history playback mode" and continues to inject normal (SP, PV, OP) data streams, observing whether the fault index in APPS decreases accordingly after the fault source is removed.

[0176] Step 2.5: Synchronous Monitoring Throughout the Entire Test. During the entire test execution period (hour 0 to the end): The monitoring and analysis module continuously retrieves time-series data of the "stickiness index" and any generated alerts / alarms from the device monitoring APPS log interface. Simultaneously, it periodically records the system resource utilization of the target server.

[0177] Phase 3: Test Result Analysis and Reporting.

[0178] Step 3.1: Data Alignment and Correlation. After the test, the monitoring and analysis module performs offline analysis: timeline alignment, that is, synchronizing the fault injection event timeline accurate to milliseconds (i.e., the moment when the engine starts simulating stickiness and each simulated "slide" jump) with the "stickiness index" change timeline and early warning event timeline captured from APPS.

[0179] Step 3.2: Calculation of key performance indicators.

[0180] (1) Fault detection sensitivity, including: First alarm delay: the time difference ΔT_detect between the moment when obvious PV stickiness characteristics are first simulated (T_fault_start) and the moment when the "stickiness index" of APPS first exceeds the warning threshold (T_alert). The smaller this value, the more sensitive the algorithm is; and alarm consistency: checking whether the warning / alarm events generated by APPS during the fault simulation period (hours 3-5) continuously cover the main fault activity period.

[0181] (2) Accuracy of fault characterization: Analyze the curve shape of the "viscosity index" to see if it matches the trend of the injected fault intensity (simulated "static friction" threshold). For example, in the middle and late stages of the fault simulation (4.5 hours), the "static friction" threshold can be temporarily increased from 1% to 3% (simulating aggravated fault), and observe whether the APPS index has a corresponding significant jump.

[0182] (3) System impact assessment: Analyze whether the CPU / memory usage of the gRPC collector and subsequent services is within a safe range during high-rate data injection, and assess the system's resilience.

[0183] Step 3.3: Generate a visual test report. The system automatically generates a report, the core content of which includes:

[0184] (1) Three-curve comparison chart: Under the same time coordinate, three curves are plotted: injected OP test data (blue); injected PV test data (red, in which the 3rd to 5th hours show a step-like shape, which is not synchronized with the OP change); "viscosity index" calculated and output by APPS (green).

[0185] (2) Event marking: Clearly mark on the graph: the vertical line of the start / end of the fault simulation; the position of each simulation “slide” jump; the position of the APPS generating warning and alarm events.

[0186] (3) Summary of conclusions: Give quantitative conclusions, such as: "Under the simulated slight viscous fault (threshold 1%), the early warning algorithm successfully detects the fault ΔT_detect seconds after the fault begins, and the alarm coverage rate is XX%. The system load growth is within the expected range."

[0187] Through the above embodiments, this application can accurately reproduce complex fault mechanisms and precisely simulate the physical phenomenon of "viscous-slip" at the data level through algorithms, which is impossible to achieve by playing back historical data. Furthermore, the entire process is performed at the upper layer through a standard gRPC interface, without touching the actual PLC or controller of the control valve, thus eliminating production risks. It not only verifies "whether an alarm can be triggered," but also accurately measures "how quickly an alarm is triggered" and "how accurately an alarm is triggered," providing direct and quantitative evidence for algorithm optimization. In addition, by simply modifying the fault model parameters or selecting different models (such as simulating valve dead zones, nonlinearities, etc.), various fault scenarios can be tested using the same system without any hardware modifications.

[0188] This application embodiment, while maintaining the complete architecture of the existing industrial instrumentation and control equipment monitoring system, directly injects simulated test data through its standard upper-layer data interface (i.e., the data intake interface of the gRPC collector), thereby realizing independent or joint performance testing of each component in the data link (such as the gRPC collector and equipment monitoring APPS). It achieves full, controllable, and repeatable long-term performance testing and extreme condition verification of each link in the data link (especially the gRPC collector and equipment monitoring APPS) without relying on physical hardware, without modifying the underlying system configuration, and without affecting normal production.

[0189] Figure 9 This is a structural diagram of a testing apparatus according to an embodiment of this application, such as... Figure 9 As shown, the device includes:

[0190] The acquisition module 902 is used to acquire the test plan of the system under test, wherein the test plan reflects the test requirements of the system under test under the target test scenario; the determination module 904 is used to determine the test data corresponding to the test requirements; the injection module 906 is used to inject the test data into the system under test through the upper-layer data interface of the system under test, wherein the upper-layer data interface is used to provide data services to the upper-layer application in the data link of the system under test; and the response module 908 is used to receive the response result of the system under test after the test data injection, and determine the test result based on the response result.

[0191] It should be noted that, Figure 9 The test apparatus shown is used to perform Figure 2 The test method shown, therefore Figure 2 The relevant explanations in the test methods also apply to Figure 9 The test setup shown will not be described in detail here.

[0192] Figure 10 This is a structural diagram of a test data injection device according to an embodiment of this application, such as... Figure 10As shown, the device includes: a receiving module 1002 for receiving test data, wherein the test data is determined based on the test requirements of the system under test; and an execution module 1004 for injecting the test data into the system under test through the upper-layer data interface of the system under test, wherein the upper-layer data interface is used to provide data services to upper-layer applications in the data link of the system under test.

[0193] It should be noted that, Figure 10 Another test data injection device shown is used to perform... Figure 3 The method of injecting test data shown, therefore Figure 3 The explanations regarding the injection methods for test data in [the document] also apply to [other applications]. Figure 10 The device for injecting test data is not described in detail here.

[0194] This application also provides an electronic device, which includes a memory and a processor. The memory stores program instructions, and the processor is connected to the memory and is used to execute steps implementing the test methods and test data injection methods in various embodiments of this application. This application also provides a non-volatile storage medium including a stored computer program. The device containing the non-volatile storage medium executes the steps of the test methods and test data injection methods in various embodiments of this application by running the computer program. The sequence numbers of the above embodiments are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0195] In the above embodiments of this application, the descriptions of each embodiment have different focuses. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. The above descriptions are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A test method characterized by, include: Obtain the test plan for the system under test, wherein the test plan is used to reflect the test requirements for the system under test in the target test scenario; Determine the test data corresponding to the aforementioned test requirements; The test data is injected into the system under test through the upper-layer data interface of the system under test, wherein the upper-layer data interface is used in the data link of the system under test to provide data services to the upper-layer application; Receive the response result of the system under test after the test data is injected, and determine the test result based on the response result.

2. The method of claim 1, wherein, Determine the test data corresponding to the test requirements, including: When the test requirement indicates that the actual operating conditions of the system under test are reproduced, the historical data of the system under test is determined as the first test data; When the test requirement indicates that the system under test should be tested under extreme conditions, second test data is generated to simulate the extreme conditions. When the test requirement indicates that the fault response of the system under test is to be tested, a simulated fault signal is superimposed on the historical data to obtain the third test data.

3. The method of claim 2, wherein, The method further includes: When the test data is the second test data or the third test data, a timestamp and a quality code are added to each data point to obtain the target test data, wherein the timestamp is used to simulate the timing of real data, and the quality code is used to test the fault tolerance of the system under test for data quality. The target test data is encapsulated based on the industrial data semantics specifications carried by the upper-layer data interface to obtain a structured test data sequence.

4. The method of claim 1, wherein, Injecting the test data into the system under test through the upper-layer data interface of the system under test includes: A connection is established between the system under test and the upper-layer data interface based on the configuration information of the system under test, and the authentication is performed based on the authentication protocol of the upper-layer data interface to obtain the authentication result. If the verification result indicates that the verification was successful, the test data will be constructed into a request message; The test data is injected into the system under test through the request message.

5. The method of claim 1, wherein, Obtain the test plan for the system under test, including: Obtain at least one target test scenario; Determine the test execution information for the at least one target test scenario, wherein the test execution information is used to reflect the execution order, test duration, and test loop count of the at least one target test scenario; The test plan is determined based on the test execution information.

6. The method of claim 5, wherein, The method further includes: Obtain the first response result of the first test scenario, wherein the first test scenario includes any one of the at least one target test scenarios; If the first response result meets the preset conditions, the test of the first test scenario is stopped, and the test of the second test scenario is triggered, wherein the second test scenario includes the next target test scenario in the execution order of the first test scenario.

7. The method of claim 1, wherein, The response results include the intermediate state of the upper-layer application after the test data is injected and the warning events issued by the system under test. The test results are determined based on the response results, including: A first time axis corresponding to the intermediate state and a second time axis corresponding to the warning event are determined, wherein the first time axis is used to represent the response behavior of the upper-layer application to the fault characteristics in the test data, and the second time axis is used to represent the sequence of occurrence times of the warning event after the test data is injected; Align the first time axis, the second time axis and the third time axis corresponding to the test data to obtain the alignment result, wherein the third time axis is used to represent the fault simulation event sequence in the test data; The test result is determined based on the alignment result.

8. A method of injecting test data, characterized by, include: Receive test data, wherein the test data is determined based on the test requirements of the system under test; The test data is injected into the system under test through the upper-layer data interface of the system under test, wherein the upper-layer data interface is used in the data link of the system under test to provide data services to the upper-layer application.

9. The method of claim 8, wherein, Injecting the test data into the system under test through the upper-layer data interface of the system under test includes: A connection is established between the system under test and the upper-layer data interface based on the configuration information of the system under test, and the authentication is performed based on the authentication protocol of the upper-layer data interface to obtain the authentication result. If the verification result indicates successful verification, the test data is constructed into a request message, wherein the request message is constructed based on the industrial data semantic specification carried by the upper-layer data interface; The test data is injected into the system under test through the request message.

10. A test system, characterized by It includes the system under test, a test scenario manager, a simulated data generation engine, an injection client, and a monitoring and analysis module. The test scenario manager is connected to the simulation data generation engine and is used to obtain the test plan of the system under test, wherein the test plan is used to reflect the test requirements of the system under test in the target test scenario. The simulation data generation engine is connected to both the test scenario manager and the injection client, and is used to determine the test data corresponding to the test requirements. The injection client is connected to both the simulation data generation engine and the system under test, and is used to inject the test data into the system under test through the upper-layer data interface of the system under test. The upper-layer data interface is used to provide data services to upper-layer applications in the data link of the system under test. The monitoring and analysis module is connected to both the injection client and the system under test, and is used to receive the response results of the system under test after the test data is injected, and to determine the test results based on the response results.

11. A test device, characterized by include: The acquisition module is used to acquire the test plan of the system under test, wherein the test plan is used to reflect the test requirements of the system under test in the target test scenario; The determination module is used to determine the test data corresponding to the test requirements. An injection module is used to inject the test data into the system under test through the upper-layer data interface of the system under test, wherein the upper-layer data interface is used to provide data services to the upper-layer application in the data link of the system under test; The response module is used to receive the response result of the system under test after the test data is injected, and to determine the test result based on the response result.

12. A test data injection device, characterized in that, include: A receiving module is used to receive test data, wherein the test data is determined based on the test requirements of the system under test; An execution module is used to inject the test data into the system under test through the upper-layer data interface of the system under test, wherein the upper-layer data interface is used in the data link of the system under test to provide data services to the upper-layer application.

13. An electronic device, characterized in that, include: A memory and a processor, wherein the memory is used to store program instructions; the processor is connected to the memory and is used to execute the test method according to any one of claims 1 to 7, or to execute the test data injection method according to any one of claims 8 to 9.

Images