Automatic testing method and device for Internet of Things equipment and computer equipment

Abstract

The invention discloses an automatic testing method and device for Internet of Things equipment and computer equipment. The method comprises the following steps: configuring a protocol analysis rule through a regular expression and a finite-state machine model in combination with a binary pattern matching algorithm; generating a test case containing a normal scene and an abnormal scene based on the rule; on the basis of the test case, protocol layer and network layer anomalies are introduced, and a complex fault condition in a real Internet of Things environment is simulated, so that an implementation result is obtained; performing multi-dimensional integrity verification according to the implementation result to obtain a verification result; preprocessing and feature extraction are carried out based on the verification result of the historical data, and a clustering and association rule mining technology is used to construct an equipment-anomaly-root cause association graph to obtain a test report; and outputting a test report. By implementing the method provided by the invention, efficient integrity verification and anomaly detection of the communication protocol of the Internet of Things equipment can be realized, the test efficiency and accuracy are improved, full-process automation is supported, and various equipment and protocols are flexibly adapted.

Description

Technical Field

[0001] The present invention relates to the field of communication protocol testing technology, and more specifically to an automated testing method, device, and computer equipment for Internet of Things devices. Background Art

[0002] IoT device testing is crucial, ensuring not only the functionality and reliability of individual devices but also the security, efficiency, and user experience of the entire IoT ecosystem. Traditional testing methods present significant challenges in protocol testing, particularly in improving test efficiency and coverage. Manual testing is time-consuming and labor-intensive, and it struggles to fully encompass all logical branches and complex conditions. This is especially true for protocols like the Concus protocol, which feature multiple command interactions and dynamic packet lengths. Furthermore, the ability to simulate abnormal scenarios is limited, making it impossible to fully replicate the various conditions found in real-world network environments, such as signal interference and device concurrency.

[0003] While general open-source tools offer some assistance in packet capture and parsing, these tools are often unable to fully adapt to the needs of specific protocols, such as identifying specific packet headers and trailers, which can lead to frequent verification errors or misjudgments. Existing technologies have exposed several shortcomings in addressing these challenges: First, limitations in protocol parsing capabilities prevent them from automatically and accurately processing packet structures, especially for the specialized Conkeys protocol format. Second, coverage of abnormal situations is low, lacking a systematic approach to simulating key issues such as illegal headers / tailers and checksum errors. Furthermore, excessive reliance on manual intervention leads to low testing efficiency, making it impossible to automate the entire process from testing to result analysis and output. Finally, current testing frameworks fail to fully support simulating real-world IoT environments, including complex dynamic scenarios such as network jitter and device low-power sleep, limiting their utility in practical applications.

[0004] Therefore, it is necessary to design a new method to achieve efficient integrity verification and anomaly detection of IoT device communication protocols, improve test efficiency and accuracy, and support full-process automation and flexible adaptation to multiple devices and protocols. Summary of the Invention

[0005] The purpose of the present invention is to overcome the shortcomings of the prior art and provide an automated testing method, device and computer equipment for Internet of Things devices.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: an automated testing method for IoT devices, comprising:

[0007] Configure protocol parsing rules through regular expressions and finite state machine models combined with binary pattern matching algorithms;

[0008] Generate test cases including normal scenarios and abnormal scenarios based on the protocol parsing rules;

[0009] Based on the test cases, protocol layer and network layer anomalies are introduced to simulate complex fault conditions in a real IoT environment to obtain implementation results;

[0010] Performing multi-dimensional integrity verification based on the implementation results to obtain verification results;

[0011] Perform preprocessing and feature extraction based on historical data verification results, and use clustering and association rule mining techniques to build a device-anomaly-root cause association map to generate a test report.

[0012] The test report is output.

[0013] Its further technical solution is: the protocol parsing rules include: packet header and packet tail identification rules, packet length calculation rules, and checksum algorithm.

[0014] A further technical solution is: generating test cases including normal scenarios and abnormal scenarios based on the protocol parsing rules, including:

[0015] Based on the protocol parsing rules, an extended finite state machine and fuzz testing technology are used to inject abnormal data while simulating the normal interaction process to generate semantically valid but structurally abnormal test cases, so as to generate test cases that include normal scenarios and abnormal scenarios.

[0016] Its further technical solution is: based on the above test cases, introduce protocol layer and network layer anomalies to simulate complex fault conditions in a real IoT environment to obtain implementation results, including:

[0017] Based on the test cases, a proxy server and Linux TC tool are used to synchronously introduce protocol layer and network layer anomalies to simulate complex fault conditions in a real IoT environment to obtain implementation results.

[0018] A further technical solution is: performing multi-dimensional integrity verification based on the implementation results to obtain verification results, including:

[0019] Matching the packet header, packet tail and length of the data packet using a regular expression on the implementation result;

[0020] Intercept network requests through a proxy server to verify whether the operation after the device restarts or the network reconnects complies with the expected process;

[0021] Applying a sliding window technique to the implementation results to calculate the average response time, so as to ensure that the heartbeat interval does not exceed the maximum threshold specified by the protocol;

[0022] The verification rules and parameters are continuously adjusted based on the operational data for the implementation results.

[0023] A further technical solution is to pre-process and extract features based on the verification results of historical data, and use clustering and association rule mining technology to build a device-anomaly-root cause association map to obtain a test report, including:

[0024] Extract anomaly types and key features of device ID from the verification results of historical data;

[0025] Encoding the key features to obtain an encoding result;

[0026] By setting the eps and min_samples parameters of the DBSCAN algorithm, cluster analysis is performed on the encoding results according to the Euclidean distance to obtain analysis results;

[0027] Based on the analysis results, an Apriori algorithm is used to construct a device-anomaly-root cause association map to obtain anomaly nodes;

[0028] For the abnormal nodes, based on the co-occurrence frequency and the decision tree model, the root cause confidence is calculated according to specific conditions and the problem is classified to obtain a classification result;

[0029] The problem type is automatically marked according to the classification result to obtain a test report.

[0030] A further technical solution is: the test report includes a report on the classification of network environment or firmware defect problems.

[0031] The present invention also provides an automated testing device for Internet of Things devices, comprising:

[0032] A rule configuration unit is used to configure protocol parsing rules by combining regular expressions and finite state machine models with binary pattern matching algorithms;

[0033] A test case generating unit, configured to generate test cases including normal scenarios and abnormal scenarios based on the protocol parsing rules;

[0034] The simulation unit is used to introduce protocol layer and network layer anomalies based on the test cases to simulate complex fault conditions in a real IoT environment to obtain implementation results;

[0035] a verification unit, configured to perform multi-dimensional integrity verification based on the implementation result to obtain a verification result;

[0036] The test unit is used to perform preprocessing and feature extraction based on the verification results of historical data, and use clustering and association rule mining technology to build a device-anomaly-root cause association map to obtain a test report;

[0037] An output unit is used to output the test report.

[0038] Its further technical solution is: the test case generation unit is used to utilize the extended finite state machine and fuzz testing technology based on the protocol parsing rules to inject abnormal data while simulating the normal interaction process, to generate semantically valid but structurally abnormal test cases, so as to generate test cases that include normal scenarios and abnormal scenarios.

[0039] The present invention further provides a computer device, comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the above method when executing the computer program.

[0040] The beneficial effects of the present invention compared with the prior art are: the present invention configures protocol parsing rules by combining regular expressions with finite state machine models and binary pattern matching algorithms, intelligently generates test cases covering normal and abnormal scenarios based on these rules, and introduces protocol layer and network layer anomalies in these cases to simulate complex fault conditions in real environments, and then performs multi-dimensional integrity verification based on the implementation results, and uses historical data through clustering and association rule mining technology to construct a device-anomaly-root cause association map, thereby outputting a detailed test report, and realizing efficient integrity verification and anomaly detection of the communication protocol of the Internet of Things device; this method not only improves testing efficiency and accuracy, but also supports full-process automated operations from test case generation to result analysis report output, and has the ability to flexibly adapt to multiple devices and protocols.

[0041] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0043] Figure 1 A schematic diagram of a flow chart of an automated testing method for IoT devices provided by an embodiment of the present invention;

[0044] Figure 2 A schematic diagram of a sub-process of an automated testing method for an Internet of Things device provided by an embodiment of the present invention;

[0045] Figure 3 A schematic diagram of a sub-process of an automated testing method for an Internet of Things device provided by an embodiment of the present invention;

[0046] Figure 4 A schematic block diagram of an automated testing apparatus for an Internet of Things device according to an embodiment of the present invention;

[0047] Figure 5 A schematic block diagram of a verification unit of an automated testing apparatus for IoT devices provided by an embodiment of the present invention;

[0048] Figure 6 A schematic block diagram of a test unit of an automated testing apparatus for IoT devices provided by an embodiment of the present invention;

[0049] Figure 7 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0050] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0051] It will be understood that when used in this specification and the appended claims, the terms “comprises” and “comprising” indicate the presence of described features, integers, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0052] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the present invention. As used in the specification and appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise.

[0053] It should be further understood that the term "and / or" used in the present description and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0054] See also Figure 1 , Figure 1This is a schematic flow chart of an automated testing method for IoT devices provided by an embodiment of the present invention. This automated testing method for IoT devices is applied to a server. The server interacts with IoT devices and configures protocol parsing rules by combining regular expressions, finite state machine models, and binary pattern matching algorithms to generate test cases covering both normal and abnormal scenarios. Based on these test cases, protocol layer and network layer anomalies are introduced to simulate complex fault conditions in real environments. The implementation results ensure that data packet integrity and device operation conform to expected processes through multi-dimensional verification. Sliding window technology is also used to monitor response time and ensure compliance with heartbeat intervals. Based on historical data, cluster analysis and association rule mining techniques are used to construct a device-anomaly-root cause association map, automatically identifying and classifying problems, and outputting a test report containing network environment or firmware defect classifications. The entire process achieves efficient integrity verification and anomaly detection of IoT device communication protocols, improving test efficiency and accuracy, supporting full-process automation, and flexible adaptation to a variety of devices and protocols.

[0055] Figure 1 This is a flow chart of the automated testing method for IoT devices provided by an embodiment of the present invention. Figure 1 As shown, the method includes the following steps S110 to S160.

[0056] S110. Configure protocol parsing rules by combining regular expressions and finite state machine models with binary pattern matching algorithms.

[0057] In this embodiment, the protocol parsing rules include: packet header and packet tail identification rules, packet length calculation rules, and a checksum algorithm.

[0058] Specifically, the efficient parsing method for the Conkeys standard communication protocol configures the protocol parsing rules by combining regular expressions, finite state machine (FSM) models and binary pattern matching algorithms. Specifically:

[0059] First, regular expressions are used to perform preliminary filtering of the data stream, quickly locating packet headers that conform to the Conkeys protocol format (such as 7878 or 7979). Next, a finite state machine model is used to handle subsequent state transitions, ensuring accurate transitions from the initial state to the state where the complete packet header is identified. Furthermore, binary pattern matching algorithms (such as the Knuth-Morris-Pratt algorithm) are used to further confirm the presence of the packet header and quickly locate the corresponding packet tail marker (0D0A) to accurately identify packet boundaries.

[0060] According to the Concus protocol specification, the length field's position is variable and needs to be dynamically determined based on a specific offset after the packet header. During this process, information indicating the length of the data content is extracted from the Nth byte after the packet header using a predefined offset parameter. This length information is used to guide the FSM in correctly demarcating packet boundaries, ensuring that each packet is fully and accurately parsed.

[0061] For each identified and segmented data packet, its contents are verified using a checksum algorithm such as CRC16. This step not only ensures the integrity of data transmission but also provides a basis for subsequent anomaly detection. If the verification result does not meet expectations, the packet is considered an anomaly and the appropriate handling mechanism is triggered.

[0062] In summary, step S110, through the organic combination of the three aforementioned technologies, achieves efficient parsing of the Conkeys standard communication protocol. It not only automatically identifies packet headers and trailers, but also flexibly responds to changes in the length field position and ensures data accuracy through a checksum algorithm. This approach significantly improves the efficiency and reliability of IoT device communication protocol testing, laying a solid foundation for subsequent test case generation, anomaly injection, and multi-dimensional integrity verification.

[0063] S120: Generate test cases including normal scenarios and abnormal scenarios based on the protocol parsing rules.

[0064] In this embodiment, a test case refers to a set of input data and expected output results designed according to the specific specifications of the Concord standard communication protocol. These test cases are designed to simulate normal processes in actual operation as well as various abnormal situations that may be encountered, so as to comprehensively evaluate the communication quality between devices.

[0065] Specifically, based on the protocol parsing rules, an extended finite state machine and fuzz testing technology are used to inject abnormal data while simulating the normal interaction process to generate semantically valid but structurally abnormal test cases, so as to generate test cases that include normal scenarios and abnormal scenarios.

[0066] This embodiment aims to generate test cases that cover both normal and abnormal scenarios by combining an extended finite state machine (EFSM) with fuzzing technology. This process not only helps verify the integrity of IoT device communication protocols but also improves the ability to detect various abnormal situations.

[0067] First, according to the protocol parsing rules, the extended finite state machine (EFSM) model is used to describe the state transition path of the Conkeys protocol. For normal scenarios:

[0068] Device login: The simulated device initiates a connection request to the server and receives a successful response.

[0069] Heartbeat maintenance: Heartbeat packets are sent regularly to keep the connection active and ensure that the correct response is received.

[0070] Command issuance and response reception: Simulates sending control commands from the server to the device and verifies whether the device executes the commands as expected and returns the correct response.

[0071] These normal interaction processes are converted into a series of state transitions, each state representing a specific stage or action of the protocol, such as "device login" and "heartbeat maintenance".

[0072] To more realistically simulate the various challenges in a network environment, fuzzing technology is introduced based on EFSM. This method can dynamically inject mutated data during state transitions, thereby generating test cases that are semantically valid but structurally abnormal. Specific abnormal scenarios include but are not limited to:

[0073] Illegal packet header / end: ​​For example, sending 7879 as the packet header instead of the required 7878 or 7979.

[0074] Checksum tampering: Intentionally modifying the checksum field in a data packet so that it does not match the actual content in order to test the error handling mechanism at the receiving end.

[0075] Simulate network outages: For example, set a delay of more than 2000ms or simply drop some packets to observe how the system responds to timeouts or data loss.

[0076] In this way, not only can all logical branches of the protocol be covered, but also targeted mutation strategies can be designed for specific protocol features, rather than generating abnormal data completely randomly, which can more effectively discover potential problems.

[0077] In practice, these two approaches complement each other. EFSM provides a clear state transition path, ensuring that test cases cover all necessary business logic; while fuzz testing increases the depth and breadth of testing, helping to identify issues that are difficult to detect using conventional methods alone. Ultimately, this combined strategy significantly improves testing efficiency and anomaly detection rates, providing more robust communication assurance for IoT devices.

[0078] S130. Based on the test case, introduce protocol layer and network layer anomalies to simulate complex fault conditions in a real IoT environment to obtain implementation results.

[0079] In this embodiment, the implementation result is that by synchronously introducing protocol layer and network layer anomalies in the test case, the complex fault conditions in the real IoT environment are successfully simulated, and the reliability and compatibility of the Conkeys protocol under these conditions are verified, thereby providing data support for optimizing protocol design and device performance.

[0080] Specifically, based on the test case, a proxy server and Linux TC tool are used to synchronously introduce protocol layer and network layer anomalies to simulate complex fault conditions in a real IoT environment to obtain implementation results.

[0081] Based on the generated test cases, protocol layer and network layer anomalies are introduced to simulate complex fault conditions in a real IoT environment to verify the reliability and compatibility of the Conkeys standard communication protocol under different conditions.

[0082] Implementation results refer to the analytical data and conclusions obtained by injecting various types of protocol and network layer anomalies into test cases and observing the system responses. These results help identify potential problems, optimize protocol design, and improve device performance.

[0083] In order to simulate abnormalities at the protocol layer, a proxy server is used to intercept and modify TCP / UDP payloads. Specific abnormalities include but are not limited to:

[0084] Tampering with the packet header: For example, replacing the correct packet header (7878 or 7979) with an illegal value (such as 7879) to verify whether the receiving end can correctly handle illegal input.

[0085] Packet truncation: Intentionally shorten the packet length to check whether the receiver can detect the data loss and take appropriate measures.

[0086] Send checksum error packets: Modify the checksum field in the data packet to make it inconsistent with the actual content, and evaluate the system's fault tolerance.

[0087] In addition to protocol layer anomalies, there are also various challenges at the network layer that need to be considered. To this end, the Linux TC (Traffic Control) tool is used to implement the following anomalies:

[0088] Delay simulation: Add a delay of more than 2000ms to simulate the extended response time in a weak network environment and test the system's adaptability to high delays.

[0089] Packet loss simulation: Set a certain packet loss rate to simulate data loss when the network is unstable and evaluate the system's recovery mechanism.

[0090] Bandwidth limitation: By limiting the bandwidth, we simulate network congestion and examine the performance of the protocol in this environment.

[0091] In practice, these two types of anomalies are not used in isolation, but rather combined to create more realistic compound failure scenarios. For example, introducing both latency and checksum errors during the heartbeat maintenance phase can better simulate how a device maintains a connection under poor network conditions.

[0092] Configure the proxy server and Linux TC tool based on the normal and abnormal test cases generated in the previous steps. Run the test cases, dynamically introducing the various protocol and network layer anomalies mentioned above. Monitor the system's behavior in real time, specifically the response time and handling method for each abnormal situation, and record all relevant data in detail. Conduct in-depth analysis based on the collected data to identify which anomalies were successfully handled and which caused system crashes or other serious consequences, and attempt to identify the root cause. Finally, organize all findings into an automated test report that clearly indicates the performance of each test case and the recommended improvement measures.

[0093] This approach not only allows for a comprehensive understanding of the Conkeys protocol's performance in the face of various complex faults, but also provides strong support for subsequent optimization, ensuring its stability and reliability in practical applications. This approach greatly improves test efficiency and coverage, reduces the need for manual intervention, and makes the entire testing process more scientific and efficient.

[0094] Specifically, using a proxy server and Linux's Traffic Control (TC) tool to inject protocol and network layer anomalies is a very effective method for simulating complex failure scenarios in real IoT environments. This approach can help developers better understand and test how their applications respond to various complex network conditions and protocol errors.

[0095] By intercepting a specific data stream through a proxy server and artificially cutting off some or all data packets during transmission, this practice can be used to test how the receiving end handles incomplete or lost data.

[0096] Using a proxy server to identify and tamper with the checksum field in protocol data units (such as IP, TCP / UDP packets), for example, by locating the checksum field of the Concus protocol and flipping the bits in it, thereby generating a data packet with a checksum error.

[0097] Automatically create proxy server tampering policies based on protocol characteristics. This may include, but is not limited to, identifying the location of specific fields (such as checksums) and defining how to modify these fields to produce the desired abnormal effect.

[0098] Use the Linux TC tool to add delay to selected network traffic. For example, you can add a 2000ms delay to a specific outbound interface with the following command:

[0099] This command will introduce a 2000 millisecond delay on the eth0 interface to simulate high latency in a weak network environment.

[0100] Other network layer anomalies: In addition to latency, you can also simulate other types of network layer anomalies such as packet loss, packet duplication, and bandwidth limitations to more comprehensively test the system's performance under poor network conditions.

[0101] In practice, a proxy server can be configured to simulate protocol layer anomalies while simultaneously using the Linux TC tool to introduce network layer anomalies. This combination creates a highly realistic test environment, enabling developers to evaluate the robustness and stability of their systems under complex and unpredictable conditions.

[0102] For example, in a weak network environment (with latency and packet loss rates set by the TC), data packets with checksum errors (tampered by the proxy server) are sent simultaneously. This setting helps verify whether the device can properly handle such compound failures, such as whether it can promptly detect and correct data errors, or whether it can maintain basic functions when network conditions deteriorate.

[0103] This approach not only improves software quality and reliability, but also enhances understanding of potential issues, leading to more robust design decisions. This approach is particularly applicable to IoT devices, as they often need to operate under resource-constrained and unreliable network conditions.

[0104] S140: Perform multi-dimensional integrity verification based on the implementation result to obtain a verification result.

[0105] In this embodiment, the verification result refers to the results achieved through structural verification, business logic verification, and timing verification, ensuring that the data packet format is correct, the command response conforms to the expected state, and the heartbeat signal interval is compliant, thereby ensuring the integrity of the communication protocol and the correctness of system operation. In other words, a three-tiered verification system ensures the correctness of the data packet format, the correctness of the business logic, and the compliance of the heartbeat signal interval to maintain system stability and reliability.

[0106] In one embodiment, see Figure 2 , the above-mentioned step S140 may include steps S141 to S144.

[0107] S141. Match the packet header, packet tail and length of the data packet using a regular expression for the implementation result.

[0108] In this embodiment, regular expression matching is first performed on the data packets collected during the test to verify whether the packet header (7878 / 7979), packet trailer (0D0A), and length field of the data packet conform to the Concord protocol specification. This process ensures the correctness of the data packet structure.

[0109] S142. Intercepting network requests for the implementation results through a proxy server to verify whether the operation after the device is restarted or the network is reconnected complies with the expected process.

[0110] In this embodiment, a proxy server simulates network request interception to check whether the device's operational flow after a reboot or network reconnection is consistent with expectations. For example, whether the device requires a new login and whether the response is timely and accurate can be used to assess the correctness and robustness of the business logic.

[0111] S143: Apply a sliding window technique to the implementation result to calculate the average response time, so as to ensure that the heartbeat interval does not exceed the maximum threshold specified in the protocol.

[0112] In this embodiment, a sliding window technique is applied to perform statistical analysis on the data packet response time during the test, calculate the average response time, and ensure that the heartbeat signal remains within the maximum threshold specified by the protocol (e.g., T_max = 300s ± 5%). This helps to verify the stability and reliability of the system during long-term operation.

[0113] S144. Continuously adjust verification rules and parameters based on the implementation results and operation data.

[0114] In this embodiment, verification rules and parameters are dynamically adjusted based on continuously collected operational data, allowing the test solution to adapt to protocol changes or optimize the accuracy of anomaly detection. This approach not only improves the flexibility and adaptability of testing, but also enables continuous improvement of testing strategies as data accumulates, improving overall test effectiveness.

[0115] By combining the results of the above steps, the integrity of the IoT device communication protocol can be comprehensively evaluated, and specific improvement suggestions can be provided for the problems found, thereby providing strong support for improving the reliability and compatibility of the protocol.

[0116] In this embodiment, establishing a three-tier verification system is an effective strategy to ensure the compliance of the communication protocol and the stability of the system. The system includes three levels: structure verification, business logic verification, and timing verification.

[0117] Structural check is to ensure that the data packet conforms to the expected format in terms of physical structure and contains the correct header, trailer, and length fields.

[0118] Use regular expressions to define and match the packet header and trailer formats, and verify that the length field accurately reflects the actual data length. For example, if a protocol specifies that the packet header begins with a specific string (such as "START"), the trailer ends with another string (such as "END"), and the length field is located in a fixed position, you can write a corresponding regular expression to check for these characteristics.

[0119] When each packet is received, it is first filtered using the regular expression above to exclude packets that clearly do not conform to the format. This step helps quickly identify malformed information and reduces the burden of subsequent processing.

[0120] Business logic verification is to verify whether the instruction response meets the expected state and ensure the correctness of system operation.

[0121] When a device restarts or reconnects after a network problem causes a connection interruption, a proxy server is configured to monitor the process and check whether re-login or other specific operations are required according to protocol requirements.

[0122] The proxy server can automatically trigger relevant checks when it detects a network reconnection event. For example, in some application scenarios, after a device comes back online, it must complete identity verification before continuing communication. In this case, the proxy server can enforce this step to ensure the consistency and security of business processes.

[0123] Timing verification is to monitor the time interval of the heartbeat signal to ensure that it does not exceed the maximum threshold specified by the protocol, thereby maintaining the real-time performance and reliability of the system.

[0124] Use a sliding window technique to calculate the average heartbeat signal response time over a period of time as a basis for evaluation. For example, if the protocol stipulates that the heartbeat interval must not exceed 315 seconds, you can set a sliding window of appropriate size (such as the past 5 minutes), continuously monitor the time points when the heartbeat signal arrives, and calculate the average interval.

[0125] Define T_max = 300s ± 5%, that is, the maximum heartbeat interval allowed is 300 seconds with a fluctuation of 5% (i.e., between 285 seconds and 315 seconds). This design not only takes into account the delay caused by network fluctuations, but also ensures that potential problems are discovered in a timely manner.

[0126] Thus, the method of this embodiment can ensure the integrity and effectiveness of the communication protocol from multiple dimensions by constructing such a three-layer verification system:

[0127] Structure checksums prevent malformed data packets from entering the system;

[0128] Business logic verification ensures the accuracy of instruction execution;

[0129] Timing verification focuses on maintaining the regularity of heartbeat signals to avoid service interruptions caused by long periods of no response.

[0130] This method not only improves the stability and robustness of the system, but also provides strong support for fault diagnosis.

[0131] S150. Preprocess and extract features based on the verification results of historical data, and use clustering and association rule mining technology to build a device-anomaly-root cause association map to obtain a test report.

[0132] In this embodiment, the test report includes a report on the network environment or firmware defect classification.

[0133] In one embodiment, see Figure 3 , the above-mentioned step S150 may include steps S151 to S156.

[0134] S151. Extract the abnormality type and device ID key features from the verification results of the historical data.

[0135] In this embodiment, feature information directly related to the analysis purpose is extracted from historical data, such as the anomaly type (e.g., checksum error, illegal packet header, etc.) and the device ID (used to identify the specific device that has the problem). These key features provide the basis for subsequent data analysis.

[0136] S152: Encode the key features to obtain an encoding result.

[0137] In this embodiment, encoding refers to the result formed after encoding the key features.

[0138] Specifically, the extracted key features are converted into a form suitable for processing by machine learning algorithms. This includes:

[0139] Categorical variable encoding: For example, converting the exception type into a one-hot vector.

[0140] Numerical feature normalization: Z-score normalization is performed on numerical features such as delay time and packet loss rate to facilitate unified comparison at different scales.

[0141] S153 , by setting the eps and min_samples parameters of the DBSCAN algorithm, cluster analysis is performed on the encoding results according to the Euclidean distance to obtain analysis results.

[0142] In this embodiment, the analysis result refers to the result obtained by clustering the encoding results.

[0143] Specifically, the DBSCAN (density-based spatial clustering application) algorithm is used to perform cluster analysis on the encoded data. The appropriate eps (neighborhood radius) and min_samples (minimum number of core point samples) are set, and similarity is calculated based on Euclidean distance to discover data clusters with similar abnormal patterns.

[0144] S154. Construct a device-abnormality-root cause association graph using the Apriori algorithm according to the analysis results to obtain abnormal nodes.

[0145] In this embodiment, an abnormal node refers to a node with an abnormality.

[0146] Specifically, based on the results of cluster analysis, the Apriori algorithm is used to construct a device-anomaly-root-cause correlation map. This map shows the relationship between devices, occurring anomalies, and their possible root causes. For example, a specific type of anomaly might be associated with a firmware defect or network environment.

[0147] S155 . Calculate the root cause confidence of the abnormal nodes based on the co-occurrence frequency and the decision tree model according to specific conditions and classify the problems to obtain a classification result.

[0148] In this embodiment, the classification result refers to the result obtained by classifying the question.

[0149] Specifically, for each abnormal node, based on its co-occurrence frequency with other nodes, combined with a decision tree model, the root cause confidence is calculated according to specific conditions and the problem is classified. For example, if an anomaly is associated with a high packet loss rate and a specific type of parity error, it can be inferred that the problem is more likely caused by the network environment.

[0150] S156. Automatically mark the problem type according to the classification result to obtain a test report.

[0151] In this embodiment, the problem type is automatically labeled based on the classification results obtained from the above analysis, and a detailed test report is generated. This report not only clarifies whether the problem is caused by the network environment or a firmware defect, but also provides solutions or directions for further investigation, helping operations personnel quickly locate and resolve the problem.

[0152] This approach effectively improves the efficiency and accuracy of fault diagnosis, making the entire process from detection to location and even problem resolution in IoT device communications more systematic and automated. It also provides valuable data support for improving product design and optimizing maintenance strategies.

[0153] In this embodiment, first, key features are extracted from historical test data, including but not limited to:

[0154] Exception type (e.g. checksum_error, header_error, etc.);

[0155] Device ID (used to identify the specific device that has a problem);

[0156] Network metrics (such as latency, packet loss rate, etc.);

[0157] Protocol field error (error information specific to the communication protocol);

[0158] For these features, proper encoding and standardization are required:

[0159] Categorical variables (such as error_fields) are converted to one-hot vector representations. Numerical features (such as latency) are Z-score normalized to ensure that data of different scales can be compared on the same basis.

[0160] Use the DBSCAN algorithm to perform cluster analysis on the encoded and standardized data. Set the clustering parameters:

[0161] eps=0.5: defines the neighborhood radius, which is the maximum distance between two points for them to be considered neighbors.

[0162] min_samples=5: defines the minimum number of samples of core points, which affects the density of clustering.

[0163] The similarity is calculated based on the Euclidean distance, and the clustering results are output to group the data with similar abnormal patterns into one category.

[0164] Use the Apriori algorithm to perform association rule mining to discover the relationship between devices, anomalies, and their possible root causes. For example, the following associations can be established:

[0165] A[device:DEV_001]-|cause|B[exception:checksum_error];

[0166] B-|Associated root cause|C[Firmware defect: CRC algorithm error];

[0167] B-|Associated root cause|D[Network interference: electromagnetic noise];

[0168] D-|Frequent co-occurrence|E[Exception: Header error];

[0169] This step helps us understand which devices may exhibit what kind of anomalies under what conditions, and what are the potential root causes behind these anomalies.

[0170] Starting from the abnormal node, traverse all its associated root cause nodes and calculate the confidence of each root cause based on the historical co-occurrence frequency. Then use the decision tree model for classification, for example:

[0171] If packet loss rate > 0.2 and exception type = checksum_error: Classify as a network problem (confidence level 85%)

[0172] If packet loss rate ≤ 0.2 and latency < 2000ms: Classified as a firmware defect (92% confidence level)

[0173] This approach is effective in determining the specific cause of the problem, whether it is the network environment or a firmware defect in the device itself.

[0174] Finally, a detailed test report is automatically generated based on the above analysis results. For example:

[0175] If the timeout problem is caused by network connection, it is marked as a network environment problem.

[0176] If it is due to frequent packet checksum errors, it is marked as a device firmware defect.

[0177] This automated process not only improves the speed and accuracy of fault diagnosis, but also provides operations and maintenance personnel with clear problem location and solution guidance, helping to quickly resolve problems and optimize system performance.

[0178] S160: Output the test report.

[0179] The test report is output to the terminal for display.

[0180] The method in this embodiment is specifically designed for the Conkeys standard communication protocol, whose structural identifiers include the packet header (7878 / 7979), length, protocol type, data content, checksum, and packet trailer (0D0A). This method is particularly suitable for integrity verification and anomaly analysis and detection of communication protocols between IoT devices and servers.

[0181] Specifically, considering the variable position of the packet length field, the method of this embodiment employs dynamic parsing based on the packet header offset, ensuring accurate parsing of packets of varying formats. Throughout the data transmission process, from sending to receiving, the system automatically checks key fields such as the packet header, trailer, length, and checksum for compliance with the Concord protocol. This system can identify and locate various anomalies during communication, such as packet loss, checksum errors, timeout responses, and illegal commands, and provide timely warnings.

[0182] The method of this embodiment can fully cover the different branches of the Conkeys protocol state machine by intelligently generating test cases, which is at least 5 times more efficient than traditional testing methods. It supports the simulation of various abnormal scenarios, has the characteristics of high detection rate and low false alarm rate, and effectively improves the accuracy of abnormality detection. Through in-depth analysis, the problem location time is shortened to minutes, while traditional troubleshooting may take hours. It supports configurable protocol rule settings, which is not limited to the Conkeys protocol, but can also be easily extended to other similar protocols, such as JT / T808, Modbus, etc. It realizes the full process automation from test case generation, abnormality injection to result analysis report generation, greatly reducing the need for manual intervention and reducing labor costs by about 90%.

[0183] In summary, this automated testing method for the Concus standard communication protocol, with its efficient test coverage, powerful anomaly detection capabilities, significant O&M optimization effects, good adaptability, and highly automated features, provides a powerful solution for communication protocol testing of IoT devices. It not only significantly improves test efficiency and accuracy, but also greatly simplifies O&M tasks, making it an ideal choice for IoT device manufacturers and service providers.

[0184] The above-mentioned automated testing method for IoT devices configures protocol parsing rules by combining regular expressions with finite state machine models and binary pattern matching algorithms. Based on these rules, test cases covering normal and abnormal scenarios are intelligently generated, and protocol layer and network layer anomalies are introduced into these cases to simulate complex fault conditions in real environments. Subsequently, multi-dimensional integrity verification is performed based on the implementation results, and a device-anomaly-root cause association map is constructed using historical data through clustering and association rule mining technology to output a detailed test report, thereby achieving efficient integrity verification and anomaly detection of IoT device communication protocols. This method not only improves testing efficiency and accuracy, but also supports full-process automation from test case generation to result analysis report output, while having the ability to flexibly adapt to a variety of devices and protocols.

[0185] Figure 4 FIG is a schematic block diagram of an automated testing device 300 for an Internet of Things device provided by an embodiment of the present invention. Figure 4 As shown, corresponding to the above-mentioned method for automated testing of IoT devices, the present invention further provides an apparatus 300 for automated testing of IoT devices. The apparatus 300 for automated testing of IoT devices includes a unit for executing the above-mentioned method for automated testing of IoT devices, and the apparatus can be configured in a server. Figure 5 The IoT device automated testing apparatus 300 includes a rule configuration unit 301 , a test case generation unit 302 , a simulation unit 303 , a verification unit 304 , a testing unit 305 and an output unit 306 .

[0186] A rule configuration unit 301 is used to configure protocol parsing rules through regular expressions and finite state machine models combined with a binary pattern matching algorithm; a test case generation unit 302 is used to generate test cases containing normal scenarios and abnormal scenarios based on the protocol parsing rules; a simulation unit 303 is used to introduce protocol layer and network layer anomalies on the basis of the test cases to simulate complex fault conditions in a real Internet of Things environment to obtain implementation results; a verification unit 304 is used to verify the multi-dimensional integrity based on the implementation results to obtain verification results; a test unit 305 is used to perform preprocessing and feature extraction based on the verification results of historical data, and use clustering and association rule mining technology to construct a device-anomaly-root cause association map to obtain a test report; an output unit 306 is used to output the test report.

[0187] In one embodiment, the test case generation unit 302 is used to utilize an extended finite state machine and fuzz testing technology based on the protocol parsing rules to inject abnormal data while simulating the normal interaction process, thereby generating semantically valid but structurally abnormal test cases, so as to generate test cases that include normal scenarios and abnormal scenarios.

[0188] In one embodiment, the simulation unit 303 is used to use a proxy server and a Linux TC tool to synchronously introduce protocol layer and network layer anomalies based on the test case, simulate complex fault conditions in a real IoT environment, and obtain implementation results.

[0189] In one embodiment, if Figure 5 As shown, the verification unit 304 includes:

[0190] The matching sub-unit 3041 is used to match the header, tail and length of the data packet using a regular expression for the implementation result; the operation verification sub-unit 3042 is used to intercept the network request through the proxy server for the implementation result, and verify whether the operation complies with the expected process after the device is restarted or the network is reconnected; the statistical sub-unit 3043 is used to apply the sliding window technology to the implementation result to calculate the average response time to ensure that the heartbeat interval does not exceed the maximum threshold specified by the protocol; the adjustment sub-unit 3044 is used to continuously adjust the verification rules and parameters of the implementation result based on the operation data.

[0191] In one embodiment, if Figure 6 As shown, the testing unit 305 includes:

[0192] The extraction subunit 3051 is used to extract the abnormality type and key features of the device ID from the verification results of the historical data; the encoding subunit 3052 is used to encode the key features to obtain the encoding results; the clustering analysis subunit 3053 is used to perform cluster analysis on the encoding results according to the Euclidean distance by setting the eps and min_samples parameters of the DBSCAN algorithm to obtain the analysis results; the graph construction subunit 3054 is used to use the Apriori algorithm to construct a device-abnormality-root cause association graph based on the analysis results to obtain abnormal nodes; the classification subunit 3055 is used to calculate the root cause confidence of the abnormal nodes based on the co-occurrence frequency and the decision tree model according to specific conditions and classify the problems to obtain the classification results; the marking subunit 3056 is used to automatically mark the problem type according to the classification results to obtain a test report.

[0193] It should be noted that those skilled in the art can clearly understand that the specific implementation process of the above-mentioned IoT device automated testing device 300 and each unit can refer to the corresponding description in the aforementioned method embodiment. For the convenience and brevity of the description, it will not be repeated here.

[0194] The above-mentioned IoT device automated testing device 300 can be implemented in the form of a computer program. The computer program can be used in Figure 7 Runs on the computer equipment shown.

[0195] See also Figure 7 , Figure 7 1 is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device 500 may be a server, wherein the server may be an independent server or a server cluster composed of multiple servers.

[0196] See Figure 7 The computer device 500 includes a processor 502 , a memory, and a network interface 505 connected via a system bus 501 , wherein the memory may include a non-volatile storage medium 503 and an internal memory 504 .

[0197] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions, which, when executed, can enable the processor 502 to perform an automated testing method for an IoT device.

[0198] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.

[0199] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute an automated testing method for Internet of Things devices.

[0200] The network interface 505 is used to communicate with other devices through the network. Figure 7 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device 500 to which the solution of the present application is applied. The specific computer device 500 may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0201] The processor 502 is configured to execute a computer program 5032 stored in the memory to implement the following steps:

[0202] The protocol parsing rules are configured by combining regular expressions and finite state machine models with binary pattern matching algorithms; test cases containing normal scenarios and abnormal scenarios are generated based on the protocol parsing rules; based on the test cases, protocol layer and network layer anomalies are introduced to simulate complex fault conditions in a real IoT environment to obtain implementation results; multi-dimensional integrity verification is performed based on the implementation results to obtain verification results; preprocessing and feature extraction are performed based on the verification results of historical data, and a device-anomaly-root cause association map is constructed using clustering and association rule mining techniques to obtain a test report; and the test report is output.

[0203] The protocol analysis rules include: packet header and packet tail identification rules, packet length calculation rules, and checksum algorithm.

[0204] In one embodiment, when the processor 502 implements the step of generating a test case including a normal scenario and an abnormal scenario based on the protocol parsing rule, the processor 502 specifically implements the following steps:

[0205] Based on the protocol parsing rules, an extended finite state machine and fuzz testing technology are used to inject abnormal data while simulating the normal interaction process to generate semantically valid but structurally abnormal test cases, so as to generate test cases that include normal scenarios and abnormal scenarios.

[0206] In one embodiment, the processor 502 introduces protocol layer and network layer anomalies on the basis of implementing the test case to simulate complex fault conditions in a real IoT environment to obtain an implementation result, and specifically implements the following steps:

[0207] Based on the test cases, a proxy server and Linux TC tool are used to synchronously introduce protocol layer and network layer anomalies to simulate complex fault conditions in a real IoT environment to obtain implementation results.

[0208] In one embodiment, when the processor 502 implements the step of performing multi-dimensional integrity verification according to the implementation result to obtain a verification result, the processor 502 specifically implements the following steps:

[0209] The implementation results are matched with the packet header, packet tail and length using regular expressions; the implementation results are intercepted with a proxy server for network requests to verify whether the operation complies with the expected process after the device is restarted or the network is reconnected; the implementation results are statistically averaged using sliding window technology to ensure that the heartbeat interval does not exceed the maximum threshold specified in the protocol; the implementation results are continuously adjusted with verification rules and parameters based on operation data.

[0210] In one embodiment, when implementing the step of preprocessing and extracting features based on the verification results of historical data, and constructing a device-anomaly-root cause association map using clustering and association rule mining techniques to obtain a test report, the processor 502 specifically implements the following steps:

[0211] Extract the anomaly type and key features of the device ID from the verification results of historical data; encode the key features to obtain an encoding result; perform cluster analysis on the encoding result based on the Euclidean distance by setting the eps and min_samples parameters of the DBSCAN algorithm to obtain an analysis result; construct a device-anomaly-root cause association map using the Apriori algorithm based on the analysis result to obtain anomaly nodes; calculate the root cause confidence of the anomaly nodes based on specific conditions based on the co-occurrence frequency and decision tree model, and classify the problems to obtain a classification result; automatically mark the problem type based on the classification result to obtain a test report.

[0212] The test report includes a report on the classification of network environment or firmware defect problems.

[0213] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0214] Those skilled in the art will appreciate that all or part of the steps in the method of the above-described embodiment can be implemented by instructing the relevant hardware through a computer program. The computer program includes program instructions, which can be stored in a storage medium that is computer-readable. The program instructions are executed by at least one processor in the computer system to implement the steps in the method of the above-described embodiment.

[0215] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program, wherein when the computer program is executed by a processor, the processor performs the following steps:

[0216] The protocol parsing rules are configured by combining regular expressions and finite state machine models with binary pattern matching algorithms; test cases containing normal scenarios and abnormal scenarios are generated based on the protocol parsing rules; based on the test cases, protocol layer and network layer anomalies are introduced to simulate complex fault conditions in a real IoT environment to obtain implementation results; multi-dimensional integrity verification is performed based on the implementation results to obtain verification results; preprocessing and feature extraction are performed based on the verification results of historical data, and a device-anomaly-root cause association map is constructed using clustering and association rule mining techniques to obtain a test report; and the test report is output.

[0217] The protocol analysis rules include: packet header and packet tail identification rules, packet length calculation rules, and checksum algorithm.

[0218] In one embodiment, when the processor executes the computer program to implement the step of generating a test case including a normal scenario and an abnormal scenario based on the protocol parsing rule, the processor specifically implements the following steps:

[0219] Based on the protocol parsing rules, an extended finite state machine and fuzz testing technology are used to inject abnormal data while simulating the normal interaction process to generate semantically valid but structurally abnormal test cases, so as to generate test cases that include normal scenarios and abnormal scenarios.

[0220] In one embodiment, when the processor executes the computer program to implement the step of introducing protocol layer and network layer anomalies on the basis of the test case to simulate complex fault conditions in a real IoT environment to obtain an implementation result, the processor specifically implements the following steps:

[0221] Based on the test cases, a proxy server and Linux TC tool are used to synchronously introduce protocol layer and network layer anomalies to simulate complex fault conditions in a real IoT environment to obtain implementation results.

[0222] In one embodiment, when the processor executes the computer program to implement the step of performing multi-dimensional integrity verification based on the implementation result to obtain a verification result, the processor specifically implements the following steps:

[0223] The implementation results are matched with the packet header, packet tail and length using regular expressions; the implementation results are intercepted with a proxy server for network requests to verify whether the operation complies with the expected process after the device is restarted or the network is reconnected; the implementation results are statistically averaged using sliding window technology to ensure that the heartbeat interval does not exceed the maximum threshold specified in the protocol; the implementation results are continuously adjusted with verification rules and parameters based on operation data.

[0224] In one embodiment, when the processor executes the computer program to implement the steps of preprocessing and feature extraction based on the verification results of historical data, constructing a device-anomaly-root cause association map using clustering and association rule mining techniques, and obtaining a test report, the processor specifically implements the following steps:

[0225] Extract the anomaly type and key features of the device ID from the verification results of historical data; encode the key features to obtain an encoding result; perform cluster analysis on the encoding result based on the Euclidean distance by setting the eps and min_samples parameters of the DBSCAN algorithm to obtain an analysis result; construct a device-anomaly-root cause association map using the Apriori algorithm based on the analysis result to obtain anomaly nodes; calculate the root cause confidence of the anomaly nodes based on specific conditions based on the co-occurrence frequency and decision tree model, and classify the problems to obtain a classification result; automatically mark the problem type based on the classification result to obtain a test report.

[0226] The test report includes a report on the classification of network environment or firmware defect problems.

[0227] The storage medium may be any computer-readable storage medium that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk, or an optical disk.

[0228] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0229] In the several embodiments provided herein, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the various units is merely a logical functional division, and actual implementation may employ other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented.

[0230] The steps in the methods of the embodiments of the present invention may be adjusted in order, combined, or deleted as needed. The units in the devices of the embodiments of the present invention may be combined, divided, or deleted as needed. Furthermore, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit.

[0231] If this integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the existing technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, terminal, or network device, etc.) to execute all or part of the steps of the method described in various embodiments of the present invention.

[0232] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. An automated testing method for IoT devices, characterized in that: include: Configure protocol parsing rules through regular expressions and finite state machine models combined with binary pattern matching algorithms; Generate test cases including normal scenarios and abnormal scenarios based on the protocol parsing rules; Based on the test cases, protocol layer and network layer anomalies are introduced to simulate complex fault conditions in a real IoT environment to obtain implementation results; Performing multi-dimensional integrity verification based on the implementation results to obtain a verification result; Preprocess and extract features based on historical data verification results, and use clustering and association rule mining techniques to build a device-anomaly-root cause association map to generate a test report. The test report is output.

2. The method for automated testing of IoT devices according to claim 1, wherein: The protocol analysis rules include: packet header and packet tail identification rules, packet length calculation rules, and checksum algorithm.

3. The method for automated testing of IoT devices according to claim 1, wherein: Generating test cases including normal scenarios and abnormal scenarios based on the protocol parsing rules includes: Based on the protocol parsing rules, an extended finite state machine and fuzz testing technology are used to inject abnormal data while simulating the normal interaction process to generate semantically valid but structurally abnormal test cases, so as to generate test cases that include normal scenarios and abnormal scenarios.

4. The method for automated testing of IoT devices according to claim 1, wherein: Based on the above test cases, protocol layer and network layer anomalies are introduced to simulate complex fault conditions in a real IoT environment to obtain implementation results, including: Based on the test cases, a proxy server and Linux TC tool are used to synchronously introduce protocol layer and network layer anomalies to simulate complex fault conditions in a real IoT environment to obtain implementation results.

5. The method for automated testing of IoT devices according to claim 1, wherein: The multi-dimensional integrity verification is performed according to the implementation results to obtain a verification result, including: Matching the packet header, packet tail and length of the data packet using a regular expression on the implementation result; Intercept network requests through a proxy server to verify whether the operation after the device restarts or the network reconnects complies with the expected process; Applying a sliding window technique to the implementation results to calculate the average response time, so as to ensure that the heartbeat interval does not exceed the maximum threshold specified by the protocol; The verification rules and parameters are continuously adjusted based on the operational data for the implementation results.

6. The method for automated testing of IoT devices according to claim 1, wherein: The verification results based on historical data are preprocessed and feature extracted, and clustering and association rule mining techniques are used to construct a device-anomaly-root cause association map to obtain a test report, including: Extract anomaly types and key features of device ID from the verification results of historical data; Encoding the key features to obtain an encoding result; By setting the eps and min_samples parameters of the DBSCAN algorithm, cluster analysis is performed on the encoding results according to the Euclidean distance to obtain analysis results; Based on the analysis results, an Apriori algorithm is used to construct a device-anomaly-root cause association map to obtain anomaly nodes; For the abnormal nodes, based on the co-occurrence frequency and the decision tree model, the root cause confidence is calculated according to specific conditions and the problem is classified to obtain a classification result; The problem type is automatically marked according to the classification result to obtain a test report.

7. The method for automated testing of IoT devices according to claim 6, wherein: The test report includes a report on the classification of network environment or firmware defect issues.

8. An automated testing device for Internet of Things devices, characterized in that: include: A rule configuration unit is used to configure protocol parsing rules by combining regular expressions and finite state machine models with binary pattern matching algorithms; A test case generating unit, configured to generate test cases including normal scenarios and abnormal scenarios based on the protocol parsing rules; The simulation unit is used to introduce protocol layer and network layer anomalies based on the test cases to simulate complex fault conditions in a real IoT environment to obtain implementation results; a verification unit, configured to perform multi-dimensional integrity verification based on the implementation result to obtain a verification result; The test unit is used to perform preprocessing and feature extraction based on the verification results of historical data, and use clustering and association rule mining technology to build a device-anomaly-root cause association map to obtain a test report; An output unit is used to output the test report.

9. The automated testing device for Internet of Things devices according to claim 8, characterized in that: The test case generation unit is used to utilize an extended finite state machine and fuzz testing technology based on the protocol parsing rules to inject abnormal data while simulating a normal interaction process, thereby generating a semantically valid but structurally abnormal test case, thereby generating a test case that includes normal scenarios and abnormal scenarios.

10. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 7 when executing the computer program.

Images