Edge gateway test method, system and device based on multi-protocol compatibility and medium

Abstract

The invention relates to the technical field of data processing, and particularly provides an edge gateway test method, system and device based on multi-protocol compatibility and a medium, and the method comprises the steps: recognizing all edge gateways and connection devices thereof in a system, and building a topological relation; the topological relation is abstracted into a hypergraph model, each gateway is mapped into a vertex, and the gateway and all equipment sets of the gateway are mapped into a hyperedge; based on the hypergraph model, automatically generating a test case set covering all gateways; testing is executed, and the operation state and performance data of each gateway are monitored in real time; and finally, evaluating the system according to the monitoring data and a preset evaluation index and generating a test report. According to the method, automation and intelligentization of the testing process are achieved through hypergraph modeling, testing key points can be accurately recognized, and the system verifies the capacity of the gateway in the aspects of multi-protocol compatibility, processing performance, fault tolerance and the like.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a testing method, system, device, and medium for edge gateways based on multi-protocol compatibility. Background Technology

[0002] As a critical hub in IoT systems, edge gateways need to manage a large number of heterogeneous devices and ensure multi-protocol compatibility, low-latency processing, and high-reliability operation. Traditional testing methods often rely on manual experience or simple scripts, making it difficult to systematically describe the complex one-to-many relationships between gateways and devices. This results in incomplete test case coverage and a lack of focus, particularly in insufficient verification of complex fault scenarios and edge autonomy capabilities. Existing technologies lack a modeling method that can automatically abstract system topology, intelligently identify test priorities, and drive comprehensive testing, making the verification of edge gateway reliability and intelligence inefficient and inadequate. Therefore, a more automated, systematic, and comprehensive testing solution is urgently needed to address these issues. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a multi-protocol compatible edge gateway testing method, system, device and medium to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a testing method for edge gateways based on multi-protocol compatibility, comprising: Identify all edge gateways in the system under test and the devices connected to each edge gateway, and establish the topological relationship between the edge gateways and the devices they are connected to; Based on the aforementioned topological relationship, a hypergraph model is constructed, wherein each edge gateway is mapped to a vertex in the hypergraph model, and each edge gateway and all the devices connected to it are mapped together to a hyperedge; Based on the hypergraph model, a test case set is generated for all edge gateways; Execute the test case set and monitor the running status and performance data of each edge gateway during the execution process; Based on the operational status and performance data obtained from monitoring, and combined with preset evaluation indicators, the edge gateway system is evaluated and a test report is generated.

[0005] In one optional implementation, identifying all edge gateways in the system under test and the devices connected to each edge gateway, and establishing the topological relationship between the edge gateways and their connected devices, includes: Discovery messages are sent to the network address range of the system under test to discover and identify online edge gateways; Establish a test management connection with each identified edge gateway; Through the test management connection, query and obtain the list of devices connected to each edge gateway; Based on all identified edge gateways and their respective device lists, the topology relationship representing the subordinate relationship between the edge gateway and its connected devices is constructed.

[0006] In an optional implementation, a hypergraph model is constructed based on the topological relationships, including: Based on the aforementioned topology, each edge gateway and each device connected to that edge gateway are created as a vertex in the hypergraph model; wherein, gateway vertices are assigned gateway attribute information, and device vertices are assigned device attribute information, the device attribute information including at least the device type and the supported communication protocols; Based on the aforementioned topology, a hyperedge is created for each edge gateway. The member vertices of the hyperedge include: the gateway vertex corresponding to the edge gateway, and the device vertices corresponding to each device connected to the edge gateway. For each hyperedge, a weight value is calculated based on the device attribute information of its member device vertices; wherein, the factors considered in calculating the weight value include at least one of the following: the number of communication protocols involved in the member device vertices within the hyperedge and the number of device types; The hypergraph model is generated based on the constructed vertex set, hyperedge set, and weight values ​​of each hyperedge.

[0007] In an optional implementation, based on the hypergraph model, a test case set is generated for all edge gateways, including: Key hyperedges are identified from the hypergraph model, and connected component analysis is performed on the hypergraph model to identify disconnected subgraphs. Based on key hyperedges and disconnected subgraphs, generate test case sets for all edge gateways and determine execution strategies.

[0008] In an optional implementation, identifying key hyperedges from the hypergraph model includes: Traverse the set of hyperedges in the hypergraph model, and for each hyperedge, calculate a quantized weight value based on the attribute information of its associated member device vertices; Sort all the hyperedges in the set of hyperedges according to their respective weight values; According to the preset identification rules, a subset is selected from the sorted set of superedges, and the superedges contained in the subset are identified as the key superedges; wherein, the identification rules include: selecting the superedges with the top N weight values, or selecting the superedges with weight values ​​exceeding a preset threshold.

[0009] In one optional implementation, based on key hyperedges and disconnected subgraphs, a test case set for all edge gateways is generated and an execution strategy is determined, including: Based on the critical hyperedges identified in the model analysis step, a first type of test task with a first test intensity is generated for the gateway vertices associated with the critical hyperedges, and a second type of test task with a second test intensity is generated for the gateway vertices associated with non-critical hyperedges, wherein the first test intensity is higher than the second test intensity; and based on the disconnected subgraphs identified in the model analysis step, mutually independent parallel test queues are generated for the system parts belonging to different subgraphs. Based on the test intensity and queue arrangement determined in the strategy generation steps, the hypergraph model is traversed to generate the following test cases: For each hyperedge, generate protocol compatibility test cases covering all communication protocols supported by the vertices of its member devices; For each gateway vertex, generate stress test cases that simulate high-frequency data reporting by all associated device vertices simultaneously. Based on a predefined fault model, fault injection test cases are generated for selected elements in the hypergraph model.

[0010] In an optional implementation, based on a predefined fault model, fault injection test cases are generated for selected elements in the hypergraph model, including: Fault injection instructions are generated based on a predefined hierarchical fault model, which includes: fault types acting on device node-level targets to simulate communication interruptions, data anomalies, or protocol violations of single or multiple device nodes within the hyperedge; fault types acting on hyperedge internal-level targets to simulate gateway computing resource overload, storage resource exhaustion, or critical process anomalies; and faults acting on network connection-level targets to simulate increased latency, bandwidth limitations, or complete network outages between the gateway and the cloud platform. Based on the hypergraph model and the critical hyperedges identified in the model analysis steps, a target selection strategy and execution parameters for fault injection are determined. The target selection strategy includes: for the critical hyperedges, a first target selection strategy is executed, which includes implementing more comprehensive or more stringent fault injection tests on the critical hyperedges or their associated device nodes; for non-critical hyperedges, a second target selection strategy is executed, which includes an injection target selection method that combines random sampling and conditional coverage to ensure that the test covers all predefined device types and communication protocol types. Generate fault test cases containing different injection timings and sequences, wherein the injection timings include at least one of steady-state injection, peak injection, and chain injection.

[0011] Secondly, the present invention provides an edge gateway testing system based on multi-protocol compatibility, comprising: The topology identification module is used to identify all edge gateways in the system under test and the devices connected to each edge gateway, and to establish the topology relationship between the edge gateway and the devices connected to it. A hypergraph construction module is used to construct a hypergraph model based on the topological relationship, wherein each edge gateway is mapped to a vertex in the hypergraph model, and each edge gateway and all the devices connected to it are mapped together to a hyperedge; The task generation module is used to generate a test case set for all edge gateways based on the hypergraph model. The task execution module is used to execute the test case set and monitor the running status and performance data of each edge gateway during the execution process. The report generation module is used to evaluate the edge gateway system and generate a test report based on the operating status and performance data obtained from monitoring and in combination with preset evaluation indicators.

[0012] Thirdly, a device is provided, comprising: The memory is used to store test programs for multi-protocol compatible edge gateways; A processor is configured to implement the steps of the multi-protocol compatible edge gateway testing method provided in the first aspect when executing the multi-protocol compatible edge gateway testing program.

[0013] Fourthly, a computer-readable medium is provided, on which a multi-protocol compatible edge gateway test program is stored, wherein when the multi-protocol compatible edge gateway test program is executed by a processor, the steps of the multi-protocol compatible edge gateway test method provided in the first aspect are implemented.

[0014] The beneficial effects of this invention are as follows: the edge gateway testing method, system, device, and medium based on multi-protocol compatibility provided by this invention achieve automation and intelligence in the testing process by abstracting the system topology into a hypergraph model. Its advantages include: automatically identifying and focusing on testing the most complex and heavily loaded critical gateways in the system, significantly improving testing targeting and efficiency; systematically verifying the fault tolerance and edge autonomy level of gateways under various abnormal scenarios based on multi-level fault models and policy-based injection methods; and objectively and comprehensively evaluating gateway performance through preset quantitative evaluation indicators, effectively overcoming the coverage blind spots and subjective biases of traditional manual testing, and providing a systematic and efficient solution for the reliability verification of edge gateways. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0017] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

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

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0021] The multi-protocol compatible edge gateway testing method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the multi-protocol compatible edge gateway testing system runs on the computer device.

[0022] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The implementing entity can be a multi-protocol compatible edge gateway testing system. Depending on different requirements, the order of the steps in this flowchart can be changed, and some can be omitted.

[0023] like Figure 1 As shown, the method includes: S1. Identify all edge gateways in the system under test and the devices connected to each edge gateway, and establish the topological relationship between the edge gateway and the devices connected to it; S2. Based on the topological relationship, construct a hypergraph model, wherein each edge gateway is mapped to a vertex in the hypergraph model, and each edge gateway and all the devices connected to it are mapped together to a hyperedge; S3. Based on the hypergraph model, generate a test case set for all edge gateways; S4. Execute the test case set and monitor the running status and performance data of each edge gateway during the execution process; S5. Based on the operating status and performance data obtained from monitoring, and combined with preset evaluation indicators, evaluate the edge gateway system and generate a test report.

[0024] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0025] S101. Proactive Network Discovery: The topology discovery module first sends discovery messages to the pre-configured range of network addresses to be tested (e.g., 192.168.1.0 / 24). These messages can be based on ICMP (Ping), ARP, or specific device discovery protocols (such as mDNS, SSDP). By analyzing the response messages, the system can identify edge gateway devices reachable at the network layer and obtain their basic network identifiers (such as IP address and MAC address).

[0026] S102. Management Connection Establishment: For each identified online edge gateway, the system attempts to establish a stable test management connection with it. This connection is typically based on a secure network protocol, such as calling the gateway's management interface via HTTPS, or establishing an SSH tunnel to ensure reliable transmission and secure authentication of subsequent control and query commands.

[0027] S103. Device List Query: After successfully establishing a management connection, the system uses this connection to call the management interface provided by the edge gateway to query details of its connected devices. This is typically achieved by calling a RESTful API (such as GET / api / v1 / devices) or executing a specific CLI command. The query response contains identifiers (such as device IDs and serial numbers) and basic status information for all devices managed by the gateway.

[0028] S104. Topology Relationship Construction: The system aggregates the device list obtained from all online gateways and performs data fusion and cleaning (such as deduplication and filtering invalid devices). Subsequently, the system structures this information to construct a clear topology data object that represents the "gateway-device" hierarchical relationship. This object explicitly records the correspondence between each gateway instance and the set of devices it manages, providing accurate and complete input data for the next stage of hypergraph modeling.

[0029] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0030] Transform physical connections into semantically rich graph computation models: Vertex set construction: The engine traverses all entities in the topology data. For each unique edge gateway, a corresponding gateway vertex (V) is created. gateway For each unique device under the gateway, create a corresponding device vertex (V). device Each vertex is assigned a set of attributes: gateway vertices typically include their unique identifier (ID), IP address, and device model; device vertices, on the other hand, include at least their unique identifier, device type (e.g., photovoltaic inverter, energy storage converter PCS, charging pile), and supported communication protocols (e.g., Modbus-TCP, IEC61850, OCPP). These attributes are derived from information collected and completed during the topology discovery phase.

[0031] Hyperedge set construction: The engine creates hyperedges based on the hierarchical relationships defined in the topology. Specifically, for each edge gateway, a corresponding hyperedge (E) is created. i The set of member vertices of this hyperedge includes the gateway vertex created in step 1 that corresponds to the gateway, as well as the device vertices corresponding to all devices managed by the gateway. This hyperedge represents the logical set of the gateway and all devices within its management domain.

[0032] Hyperedge weight calculation: To quantify the complexity and importance of each hyperedge (i.e., each gateway management domain), the engine calculates a weight value for each hyperedge. The calculation process is based on the analysis of attribute information of its member device vertices. Specifically, the weight calculation considers at least one or more of the following factors: Protocol diversity: This counts the number of distinct communication protocols used by all device vertices within the hyperedge. Gateways managing multiple protocols are considered more complex.

[0033] Device heterogeneity: This counts the number of distinct device types belonging to all device vertices within the hyperedge. Gateways managing multiple device types are considered to have a heavier functional load.

[0034] A typical implementation is to use a weighted summation model with configurable coefficients, for example: weights (E) i = α * number of protocol types + β * number of device types (where α and β are adjustable weight coefficients). The higher the weight value, the more critical the gateway corresponding to the hyperedge.

[0035] Model Generation and Persistence: Finally, the engine integrates the vertex set (V), hyperedge set (E), and the weight value of each hyperedge generated in the above steps into a complete, computable data structure, namely the hypergraph model. This model is typically serialized into a standard graph data format (such as JSON Graph Format) and stored in an in-memory database (such as Redis) or a file for efficient reading and use by subsequent modules such as model analysis and test case generation.

[0036] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0037] S301. Identify key hyperedges from the hypergraph model and perform connectivity component analysis on the hypergraph model to identify disconnected subgraphs.

[0038] Key Hyperedge Identification: This task aims to locate the gateway management domain that is the most complex and requires the most intensive testing in the system.

[0039] Weight calculation: The module traverses the set of hyperedges (EE) in the hypergraph model. For each hyperedge E... i The module reads the attributes of its member device vertices and calculates a quantized weight value based on a predefined algorithm. This calculation takes into account key factors such as the number of device types within the hyperedge and the number of supported communication protocols (see the aforementioned weight calculation implementation method for the specific calculation formula).

[0040] Sorting and Filtering: After calculation, the module uses an efficient sorting algorithm (such as quicksort) to sort all hyperedges in descending order according to their weight values. Then, according to preset recognition rules, a subset is selected from the sorted list. Typical rules include: selecting the top N hyperedges by weight (e.g., the top 5), or selecting all hyperedges whose weights exceed a certain set threshold (e.g., greater than 1.5 times the average weight).

[0041] Result Identification: Ultimately, the selected subset of hyperedges was identified as "critical hyperedges." These critical hyperedges directly correspond to "critical gateways" in the physical network and are the primary targets of subsequent high-intensity, high-priority testing.

[0042] Connectivity component analysis: This task aims to understand the modular structure of the system in order to optimize test resource scheduling.

[0043] Algorithm Execution: The module performs connected component analysis on the hypergraph model. Since hyperedges represent gateways and their device groups, two hyperedges (i.e., two gateway management domains) are not connected if they do not share any common device vertices. The module uses graph theory algorithms (such as depth-first search or disjoint-set data structures) to traverse and label the entire hypergraph, identifying all maximally connected subgraphs, i.e., "connected components".

[0044] Application of Results: After analysis, the system will obtain a set of mutually disconnected subgraphs. Each subgraph represents an independent functional module or network partition within the system. This analysis result will be directly used to guide the parallel scheduling of test tasks, allowing simultaneous and non-interfering testing of system parts corresponding to different connected components, thereby significantly improving overall test execution efficiency.

[0045] S302. Based on key hyperedges and disconnected subgraphs, generate test case sets for all edge gateways and determine execution strategies.

[0046] Phase 1: Test Strategy Development Based on the results of model analysis, the system generates differentiated test intensity strategies and parallel scheduling schemes: Differentiated Intensity Strategy: Based on the identified list of critical hyperedges, the system assigns a first test intensity to each gateway vertex associated with a critical hyperedge. This intensity means that more comprehensive and rigorous testing will be performed on it, such as higher concurrency pressure and more complex fault combination injections. For gateway vertices associated with non-critical hyperedges, a second test intensity is assigned, and standard or basic level testing is performed. The first test intensity is higher than the second test intensity.

[0047] Parallelization queue strategy: Based on the results of connected component analysis, the system creates an independent parallel test queue for each identified disconnected subgraph (connected component). Test tasks belonging to different subgraphs will be assigned to different execution threads or test resource pools to run simultaneously, thereby maximizing the utilization of test resources and improving overall efficiency. This ensures that testing one system module will not block the test process of other independent modules.

[0048] Phase Two: Generation of Specific Test Cases After determining the overall strategy, the system traverses the hypergraph model and generates three main categories of test cases: Protocol compatibility test cases: For each hyperedge (i.e., each gateway management domain), the system traverses the "Supported Communication Protocols" attribute of its member device vertices, generating test cases covering all protocol types within the hyperedge. For example, if a hyperedge contains Modbus, IEC 61850, and OCPP devices, a test scenario is generated to simultaneously verify the correct parsing and processing of these three protocols.

[0049] Stress test cases: For each gateway vertex, the system generates a test scenario that simulates all subordinate devices simultaneously reporting data at the highest frequency, based on the information of all associated device vertexes, in order to verify the gateway's processing performance and stability under high concurrency load.

[0050] Fault injection test cases: The system intelligently selects injection targets based on predefined, layered fault models (such as device node level, hyperedge internal level, and network connection level faults) and the strength strategy established in the first phase. For example, for devices associated with key hyperedges, more complex combinations of "protocol violation" or "data anomaly" faults are injected; at the same time, it ensures that all device types and protocol types are covered in the entire test set to verify the overall fault tolerance capability of the system.

[0051] Generating fault injection test cases is a crucial step in the test generation process, aiming to systematically verify the anomaly handling and fault tolerance capabilities of the edge gateway. Its implementation comprises three core sub-steps: Step 1: Instruction generation based on a hierarchical fault model The system maintains a predefined hierarchical fault model library. This library is hierarchically structured according to the logical location and target of the fault, and mainly includes: Device node-level faults: The target is one or more device vertices within the hyperedge. Fault types include: communication interruption (simulating device offline), data anomaly (simulating sending data that is out of range or has an incorrect format), and protocol violation (simulating sending data frames that violate the protocol).

[0052] Hyperedge internal level faults: The target is the entire gateway domain represented by the hyperedge. Fault types include: computing resource overload (simulating CPU / memory exhaustion), storage resource exhaustion (simulating local disk full), and critical process anomalies (simulating service crashes such as protocol parsing).

[0053] Network connectivity level failure: The target is the uplink between the gateway and the cloud. Failure types include: increased network latency, bandwidth limitation, and complete network outage.

[0054] For the selected test target and fault type, the system generates specific fault injection instructions that can be executed by the fault simulator.

[0055] Step 2: Intelligent Target Selection Based on Hypergraph Analysis The system does not randomly select injection targets, but rather relies heavily on the hypergraph model and analysis results to implement a differentiated strategy: Key strategy for critical hyperedges: For critical hyperedges (and their associated critical gateways) identified in the model analysis step, the system executes a first target selection strategy. This strategy manifests as generating more comprehensive (e.g., covering the three-tier fault model mentioned above) and more stringent (e.g., combining multiple faults injected in the same test) test cases for these targets.

[0056] Coverage strategy for non-critical hyperedges: For non-critical hyperedges, the system implements a second target selection strategy. This strategy combines random sampling (e.g., randomly selecting 30% of non-critical hyperedges for basic fault testing) with conditional coverage. "Conditional coverage" ensures that at least one typical fault injection test is performed for each device type (e.g., photovoltaic inverter, energy storage PCS) and each communication protocol (e.g., Modbus, IEC 61850) throughout the test set, guaranteeing broad test representativeness.

[0057] Step 3: Multi-dimensional injection timing and sequence design To simulate the complexity of real-world faults, the system's test cases include different injection timings and sequences: Steady-state injection: Injecting faults into the gateway when it is in a stable operating state to test its normal monitoring and response mechanisms.

[0058] Peak injection: Injecting faults into the gateway while it is under high load (such as when performing stress tests simultaneously) tests its stability and isolation capabilities under resource constraints.

[0059] Chain injection: Simulates a chain reaction of failures (“avalanche” effect). For example, first inject a fault that increases network latency, and before the gateway has fully adapted or recovered, immediately inject a communication interruption fault in one of its critical devices to verify the system’s resilience under continuous impact and the correctness of the fault handling logic.

[0060] Finally, the system encapsulates the generated fault instructions, target information, injection timing, and sequence parameters into a complete fault injection test case and adds it to the test task queue to await scheduling and execution.

[0061] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0062] S401. Test Task Execution: The task execution engine retrieves test cases sequentially based on the test queue allocated by the scheduler (considering parallel queues and priorities).

[0063] For different types of test cases, the engine invokes corresponding dedicated components such as protocol simulators, load generators, or fault injectors. For example, when performing protocol compatibility tests, the engine controls protocol simulators such as Modbus, IEC 61850, and OCPP to send data frames that conform to or violate the protocols to the target gateway according to the test case definition; when performing stress tests, the engine drives the load generator to simulate all devices under the target gateway reporting data concurrently at the highest frequency; when performing fault injection tests, the engine instructs the fault injector to apply preset fault disturbances to the selected target (device, gateway, or network link) at a specified time.

[0064] The execution engine ensures the precise triggering of test commands and keeps the clock synchronized with the monitoring center, giving each command a precise timestamp.

[0065] S402. Real-time monitoring and data acquisition: While the test task is being executed, the distributed monitoring center is started, continuously and in parallel collecting the operating status and performance data of each edge gateway through multiple channels.

[0066] The monitoring center periodically polls or receives event pushes through the northbound management API (such as HTTPS interface) provided by the gateway to obtain the gateway's real-time performance indicators, including but not limited to CPU utilization, memory usage, disk I / O, network bandwidth, number of active connections, process status, etc.

[0067] The monitoring center also collects the gateway's system logs and application logs in real time through log collection agents (such as those deployed on the gateway side or through network syslog) for post-event analysis of fault alarms, error messages, etc.

[0068] For network-level fault injection tests (such as simulating a complete network outage), the monitoring center will start an independent monitoring link based on an out-of-band management channel (such as 4G / 5G cellular network), or rely on a lightweight monitoring agent pre-deployed locally on the gateway to ensure that the local operating status and edge autonomous behavior of the gateway can be continuously recorded during network outages.

[0069] S403. Data Correlation and Preliminary Analysis: The monitoring center compares and correlates the collected performance data, log events, and test commands sent by the execution engine using timestamps. Through this correlation, the system can accurately calculate key metrics such as end-to-end processing latency, fault detection time, and alarm triggering delay.

[0070] All raw monitoring data, correlated metric data, and test metadata (such as test case ID, target gateway ID, and execution status) are written in real time to a high-performance time-series database (such as InfluxDB) or a big data platform for in-depth analysis in the subsequent evaluation phase.

[0071] In one embodiment of the present invention, based on step S5, a possible embodiment will be given below, and its specific implementation will be described in a non-limiting manner.

[0072] S501. Data Aggregation and Metric Calculation: The evaluation center extracts all performance data and log events related to this test task from time-series databases or big data platforms. Based on a pre-defined, quantifiable evaluation metric model, the system automatically calculates various core metrics. This model defines the specific calculation logic, for example: Fault detection time: The interval between the timestamp of the fault injection command and the timestamp of the first occurrence of a related error alarm in the target gateway log.

[0073] Fault isolation effectiveness: Analyze whether the communication success rate of other normal devices under the same gateway significantly decreases during a failure of a specific device node.

[0074] System self-healing / recovery time: For recoverable faults (such as process restarts), calculate the time elapsed from fault injection to the return of critical system service metrics to normal levels.

[0075] Correctness and duration of edge autonomous behavior: For network outage testing, verify whether the local control logic executed by the gateway during the network outage (such as starting and stopping charging piles according to local power balance instructions) conforms to the preset strategy, and accurately record the continuous duration of its stable independent operation (the core KPI is whether it exceeds 48 hours).

[0076] Resource utilization: Analyze the CPU and memory utilization curves of the gateway during stress or fault testing to determine whether there is continuous saturation (such as 100%) that leads to service blockage.

[0077] S502. Pass / Fail Judgment: The system automatically compares the calculated measured values ​​of various indicators with the preset pass thresholds and the performance indicators promised in the patent or specification (e.g., parsing latency ≤ 80 microseconds, end-to-end latency ≤ 50 milliseconds). Based on preset judgment rules (e.g., all key indicators must meet the standards), the system provides a clear "pass" or "fail" conclusion for each test case and the overall test task. For failed test cases, the system automatically identifies and locates possible causes (e.g., performance bottlenecks, functional defects).

[0078] S503. Structured Report Generation and Visualization: The evaluation report generator integrates all judgment results, raw data snapshots, and indicator trend charts to automatically generate a detailed comprehensive test report. The report not only includes tabular summaries of test case execution and pass rates but also visually displays the results through charts: Gateway vertices and hyperedges that passed or failed tests are highlighted in different colors (e.g., red / green) on a system topology map rendered based on the original hypergraph model; trend curves of key performance indicators (such as latency and throughput) throughout the entire test cycle; a time-series heatmap of resource utilization; and a time-series correlation diagram of fault injection and system response.

[0079] The report is ultimately output in a standard document format (such as PDF or HTML), providing authoritative and intuitive data for product acceptance, performance tuning, and troubleshooting.

[0080] In some embodiments, the multi-protocol compatible edge gateway testing system may include multiple functional modules composed of computer program segments. The computer programs for each program segment in the multi-protocol compatible edge gateway testing system may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) Functionality for testing edge gateways based on multi-protocol compatibility.

[0081] In this embodiment, the multi-protocol compatible edge gateway testing system can be divided into multiple functional modules according to the functions it performs, such as... Figure 2 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0082] The topology identification module is used to identify all edge gateways in the system under test and the devices connected to each edge gateway, and to establish the topology relationship between the edge gateway and the devices connected to it. A hypergraph construction module is used to construct a hypergraph model based on the topological relationship, wherein each edge gateway is mapped to a vertex in the hypergraph model, and each edge gateway and all the devices connected to it are mapped together to a hyperedge; The task generation module is used to generate a test case set for all edge gateways based on the hypergraph model. The task execution module is used to execute the test case set and monitor the running status and performance data of each edge gateway during the execution process. The report generation module is used to evaluate the edge gateway system and generate a test report based on the operating status and performance data obtained from monitoring and in combination with preset evaluation indicators.

[0083] Figure 3 The multi-protocol compatible edge gateway testing method provided in this application embodiment can be applied to devices. Those skilled in the art will understand that the device structure involved in the embodiments of this invention does not constitute a limitation on the device. A device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0084] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0085] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.

[0086] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0087] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0088] The present invention also provides a computer medium, wherein the computer medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0089] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0090] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0091] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or modules may be electrical, mechanical, or other forms.

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

[0093] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0094] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A method for testing a multi-protocol compatible edge gateway, characterized in that, The method comprises the following steps: identifying all edge gateways in the system to be tested and the devices connected to each edge gateway, and establishing a topological relationship between the edge gateways and the devices connected thereto; based on the topological relationship, constructing a hypergraph model, wherein each edge gateway is mapped to a vertex in the hypergraph model, and each edge gateway and all the devices connected thereto are collectively mapped to a hyperedge; based on the hypergraph model, generating a test case set for all edge gateways; executing the test case set and monitoring the running state and performance data of each edge gateway during execution; based on the running state and performance data obtained by monitoring, in combination with preset evaluation indicators, evaluating the edge gateway system and generating a test report.

2. The method of claim 1, wherein, identifying all edge gateways in the system to be tested and the devices connected to each edge gateway, and establishing a topological relationship between the edge gateways and the devices connected thereto, comprising: sending a discovery packet to the network address range of the system to be tested to discover and identify online edge gateways; establishing a test management connection with each identified edge gateway; querying and obtaining a device list connected to each edge gateway through the test management connection; based on all identified edge gateways and their respective device lists, constructing the topological relationship representing the subordinate relationship between the edge gateways and the devices connected thereto.

3. The method of claim 1, wherein, based on the topological relationship, constructing a hypergraph model, comprising: based on the topological relationship, creating each edge gateway and each device connected to the edge gateway as a vertex in the hypergraph model, respectively; wherein the gateway vertex is assigned with gateway attribute information, and the device vertex is assigned with device attribute information, the device attribute information at least including device type and supported communication protocol; based on the topological relationship, for each edge gateway, creating a hyperedge, the member vertices of the hyperedge including the gateway vertex corresponding to the edge gateway and the device vertices corresponding to the devices connected to the edge gateway; for each hyperedge, calculating the weight value of the hyperedge based on the device attribute information of the member device vertices; wherein the factors considered in calculating the weight value include at least one of the number of types of communication protocols involved in the member device vertices of the hyperedge and the number of device types; based on the constructed vertex set, hyperedge set and weight value of each hyperedge, generating the hypergraph model.

4. The method of claim 1, wherein, based on the hypergraph model, generating a test case set for all edge gateways, comprising: identifying critical hyperedges from the hypergraph model, and performing connected component analysis on the hypergraph model to identify subgraphs that are not connected to each other; based on the critical hyperedges and the subgraphs that are not connected to each other, generating a test case set for all edge gateways and determining an execution strategy.

5. The method of claim 4, wherein, identifying critical hyperedges from the hypergraph model, comprising: traversing the hyperedge set in the hypergraph model, and for each hyperedge, calculating a quantitative weight value based on the attribute information of the member device vertices associated therewith; sorting all hyperedges in the hyperedge set according to their respective weight values; According to a preset identification rule, a subset is selected from the sorted hyperedge set, and a hyperedge included in the subset is identified as the key hyperedge; wherein the identification rule includes: selecting hyperedges with top N ranked weight values, or selecting hyperedges with weight values exceeding a preset threshold.

6. The method of claim 4, wherein, Based on the key hyperedge and the mutually disconnected subgraphs, a test case set for all edge gateways is generated and an execution strategy is determined, including: Based on the key hyperedge identified in the model analysis step, a first type of test task with a first test intensity is generated for the gateway vertex associated with the key hyperedge, and a second type of test task with a second test intensity is generated for the gateway vertex associated with the non-key hyperedge, wherein the first test intensity is higher than the second test intensity; and based on the mutually disconnected subgraphs identified in the model analysis step, independent parallel test queues are generated for system parts belonging to different subgraphs; According to the test intensity and queue arrangement determined in the strategy generation step, the hypergraph model is traversed to generate the following test cases: For each hyperedge, a protocol compatibility test case covering all communication protocols supported by its member device vertices is generated; For each gateway vertex, a stress test case is generated to simulate simultaneous high-frequency data reporting by all device vertices associated with it; Based on a predefined fault model, fault injection test cases for selected elements in the hypergraph model are generated.

7. The method of claim 6, wherein, Based on a predefined fault model, fault injection test cases for selected elements in the hypergraph model are generated, including: Based on a predefined hierarchical fault model, fault injection instructions are generated, including: fault types acting on device node level targets, used to simulate communication interruption, data anomaly or protocol violation of a single or multiple device nodes within a hyperedge; fault types acting on hyperedge internal level targets, used to simulate gateway computing resource overload, storage resource depletion or critical process anomaly; faults acting on network connection level targets, used to simulate network delay increase, bandwidth limitation or complete interruption between gateway and cloud platform; Based on the hypergraph model and the key hyperedge identified in the model analysis step, a target selection strategy and execution parameters for fault injection are determined, including: for the key hyperedge, a first target selection strategy is executed, including implementing more comprehensive or more stringent fault injection testing on the key hyperedge or its associated device nodes; for non-key hyperedges, a second target selection strategy is executed, including a random sampling and condition coverage combined injection target selection method to ensure test coverage of all predefined device types and communication protocol types; Fault test cases containing different injection time and sequence are generated, including at least one of steady-state injection, peak injection and chain injection.

8. A multi-protocol compatible based edge gateway testing system, characterized by, Including: A topology identification module is used to identify all edge gateways in the system under test and the devices connected to each edge gateway, and establish the topology relationship between the edge gateway and its connected devices; a hypergraph construction module, configured to construct a hypergraph model based on the topological relations, wherein each edge gateway is mapped as a vertex in the hypergraph model, and each edge gateway and all the devices connected thereto are collectively mapped as a hyperedge; a task generation module, configured to generate a test case set for all the edge gateways based on the hypergraph model; a task execution module, configured to execute the test case set and monitor the running state and performance data of each edge gateway during the execution; a report generation module, configured to evaluate the edge gateway system according to the monitored running state and performance data and in combination with preset evaluation indexes and generate a test report.

9. A multi-protocol compatible based edge gateway testing device, characterized by, comprise: a memory, configured to store a multi-protocol compatible edge gateway test program; a processor, configured to implement the steps of the multi-protocol compatible edge gateway test method according to any one of claims 1-7 when executing the multi-protocol compatible edge gateway test program.

10. A computer readable medium having stored thereon a computer program, characterized in that, The readable medium stores a multi-protocol compatible edge gateway test program, and the multi-protocol compatible edge gateway test program implements the steps of the multi-protocol compatible edge gateway test method according to any one of claims 1-7 when executed by the processor.

Images