A test case automatic generation method and system for power system terminal

Abstract

The application provides a power system terminal-oriented test case automatic generation method and system, classifies test input data, constructs a test case generation strategy based on variation, generates a test case of unstructured input by using the test case generation strategy, generates a test case of structured input by using syntax description and variation, and forms a power terminal-oriented test case library; based on the power terminal-oriented test case library, a fuzzy test model is trained, a test case is executed, and fuzzy testing is performed. The application can improve the efficiency of test case generation, help to discover security risks existing in the power system terminal itself in a timely manner, improve the network attack security defense capability, and ensure the safe and reliable operation of the power system terminal.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things security technology, and relates to a method and system for automatically generating test cases for power system terminals. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] Fuzzing is a security testing technique primarily used to detect security vulnerabilities, and it has seen rapid development in recent years. Fuzzing is a vulnerability detection technique that uses a randomly generated stream of characters to repeatedly test a target program to detect potential vulnerabilities. Compared to static analysis, dynamic analysis, and binary comparison methods, fuzzing avoids problems such as state explosion, path explosion, difficulty in constraint solving, long processing times, and high false positive rates. It also offers advantages such as high automation, low system overhead, low false positive rate, and independence from the target program's source code.

[0004] Research on fuzzing focuses on two main areas: improving its vulnerability detection capabilities and expanding its applications. Currently, fuzzing has become an important component of information security. With the continuous evolution of technological concepts, fuzzing now encompasses not only traditional black-box fuzzing but also gray-box and white-box fuzzing techniques, attracting widespread attention in industry, academia, and research. To date, numerous security vendors both domestically and internationally have released software and hardware fuzzing products, but none have yet achieved fully automated fuzzing.

[0005] With the continuous development of new power systems, new applications such as the widespread grid connection of distributed renewable energy and the control of massive load resources are constantly emerging. The increasing number and variety of heterogeneous terminals connected to the power system have led to a surge in the potential for exploiting terminal vulnerabilities to threaten power grid security, posing a serious threat to the security of the power system. Traditional methods relying on manual terminal security testing are insufficient to guarantee the security of the massive number of terminals in the power system. Therefore, there is an urgent need to develop an efficient and convenient fuzzy testing system for the massive number of terminals in the power system.

[0006] Currently, fuzz testing for embedded terminals is still in its early stages both domestically and internationally, with limited support for various terminal types. Current research on terminal fuzz testing encompasses white-box, black-box, and gray-box approaches. White-box fuzz testing requires the terminal firmware source code and necessitates support from the terminal manufacturer or decompilation of the terminal product. Gray-box fuzz testing requires guidance from terminal feedback during the testing process. Black-box fuzz testing typically focuses on detecting the terminal's network protocols. Addressing the challenges of effectively ensuring power system terminal security and low automation in the context of the development of the power Internet of Things (IoT), adaptive modifications and targeted research are necessary. Summary of the Invention

[0007] To address the aforementioned problems, this invention proposes an automated test case generation method and system for power system terminals. This invention can improve the efficiency of test case generation, help to promptly identify security vulnerabilities in power system terminals, enhance network attack security defense capabilities, and ensure the safe and reliable operation of power system terminals.

[0008] According to some embodiments, the present invention adopts the following technical solution:

[0009] A method for automatically generating test cases for power system terminals includes the following steps:

[0010] The test input data is classified, and a mutation-based test case generation strategy is constructed. This strategy is used to generate test cases for unstructured inputs and to generate test cases for structured inputs using syntax description and mutation, thus forming a test case library for power terminals.

[0011] Based on the aforementioned test case library for power terminals, a fuzzy testing model is trained, test cases are executed, and fuzzy testing is performed.

[0012] As an alternative implementation method, it also includes analyzing the security threats to vulnerabilities of each terminal from a network attack and defense perspective based on security protection requirements, considering the security role involved in power business terminals, and determining the security aspects involved in power business terminals.

[0013] As an alternative implementation method, a mutation-based test case generation strategy is constructed. The specific process of generating test cases for unstructured input using this strategy includes: determining the message content, dividing the content into content that participates in mutation and content that does not participate in mutation, and for the content that participates in mutation, mutating the content of the seed according to a fixed pattern. Test cases generated by deterministic mutation of the same seed are the same. Mutation starts from the beginning of the seed content according to the set mutation length and step size.

[0014] As a further implementation, the mutation process also includes performing a large number of random mutations on the seed to be mutated. Each time, a certain bit or several bits in the seed are randomly selected, and a mutation strategy is randomly applied to the selected byte to generate new test cases. However, the length of the seed is not changed during this process.

[0015] As an alternative implementation method, the specific process of generating test cases with structured input using syntax description and mutation includes:

[0016] The existing test cases are decomposed into grammar fragments according to the grammar G to obtain a grammar fragment pool. A sub-grammar G′ is derived from the existing test cases. It is a subset of the grammar G and has a mapping relationship with the test suite.

[0017] Repeatedly execute the process of replacing a fragment in the fragment pool with a subsyntactic G′. The two syntactic fragments represent the same syntactic components but have different structures, generating new test cases.

[0018] As a further implementation, a mutation filtering mechanism is added during the repeated execution of replacing a fragment in the fragment pool according to the subsyntax G′. Multiple monitoring points are set during the repeated execution, and each monitoring point contains a user-defined callback program. When a monitoring point is executed, the callback program is called with context information as a parameter to check the context and determine the next execution instruction.

[0019] As a further implementation, during the repeated execution of replacing a fragment in the fragment pool based on subsyntax G′, an output rewriting mechanism is added. After generating a new test case string, a user-defined callback program is immediately executed on it. At the same time, the derivation sequence of the string is also passed as a parameter to the callback program for further operations on the generated test case.

[0020] As an alternative implementation method, the generated test cases are named and categorized according to predefined rules.

[0021] As an alternative implementation method, the specific process of training a fuzzy testing model and executing test cases based on the aforementioned test case library for power terminals includes:

[0022] Based on the input syntax format of the target program, corresponding malformed data is generated. After generation, the data is filtered according to its validity. Test cases that trigger the vulnerability with a probability exceeding the set value are sent to the target program for fuzzing.

[0023] The generated test cases are input into the target program for execution, and the execution process and the state of the program's end are monitored. When abnormal information is detected in the program execution, the test cases that triggered the abnormal event are saved, and relevant information is recorded for subsequent judgment and analysis of program vulnerabilities.

[0024] An automated test case generation system for power system terminals, comprising:

[0025] The security protection analysis module is configured to target business terminals in all aspects of the power system, and based on security protection requirements, analyze the impact of vulnerability exploitation attacks on each terminal on the safe and stable operation of the power grid from a network attack and defense perspective.

[0026] The automatic generation module is configured to build a mutation-based test case generation strategy, which is used to generate test cases for unstructured inputs and to generate test cases for structured inputs using syntax descriptions and mutations, forming a test case library for power terminals.

[0027] The fuzzing module is configured to train a fuzzing model, execute test cases, and perform fuzzing tests based on the test case library for power terminals.

[0028] A computer-readable storage medium storing a plurality of instructions adapted for loading by a processor of a terminal device and executing steps in the method.

[0029] A terminal device includes a processor and a computer-readable storage medium, the processor being configured to implement instructions; the computer-readable storage medium being configured to store a plurality of instructions adapted to be loaded by the processor and executed in accordance with the steps of the method described therein.

[0030] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0031] This invention modifies pre-provided seed test cases by applying a set of mutation operations (deterministic mutation and random mutation) to generate new test inputs. This method is simple, easy to implement, and highly scalable, improving the efficiency of test case generation for unstructured data.

[0032] This invention addresses the test case generation process for highly structured input programs by using syntax to guide the generation of test input, effectively constructing test cases, achieving better program coverage, and ensuring that the generated test cases can pass the initial lexical analysis and parsing phases of the program. It can systematically generate test input, covering as many edge cases and complex structures as possible, which helps to expose the target program's improper handling of these anomalies and related security issues.

[0033] This invention incorporates mutation filtering and output rewriting mechanisms into the test case generation process for highly structured inputs. These mechanisms allow users to guide the behavior of the generation engine when performing data mutations and to fine-tune the content of the generated test cases. This gives users control over whether to perform mutations on the current derivation sequence, whether the current tuple of the derivation sequence can be used as a branch point, and which syntax rules to select to replace the subtree rooted at the current branch point. It also allows for further improvement of the generated test cases.

[0034] This invention can name and classify test cases according to predefined rules, providing advantageous initial seeds for terminal fuzz testing, supporting the fuzz testing engine to quickly cover target programs, and improving the ability to discover deep-level terminal vulnerabilities.

[0035] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0036] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0037] Figure 1 This is a schematic diagram of a technical solution according to an embodiment of the present invention;

[0038] Figure 2 This is a schematic diagram of a structured test case generation framework according to an embodiment of the present invention;

[0039] Figure 3 This is a schematic diagram of the fuzz test execution process according to an embodiment of the present invention;

[0040] Figure 4 This is a schematic diagram of a fuzzy testing process for power system terminals according to an embodiment of the present invention. Detailed Implementation

[0041] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0042] It should be noted that the following detailed description is illustrative and intended to provide further explanation of the invention. Unless otherwise specified, 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.

[0043] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0044] Example 1

[0045] As mentioned in the background section, considering the complexity of power system applications, the use of numerous proprietary protocols and dedicated terminals, and the closed nature of dedicated power terminals, this study investigates fuzz testing of power system terminals. The aim is to construct an attack and protection system suitable for the massive number of terminals in new power systems, promptly identify security vulnerabilities inherent in the power system terminals themselves, improve network attack security defense capabilities, and ensure the safe and reliable operation of power system terminals. This research has extremely high value.

[0046] This embodiment provides a method for automatically generating test cases for fuzz testing in power system terminals.

[0047] Of course, in order to generate test cases more effectively, we can first analyze the terminal security involved in each link of the power business, the security vulnerabilities of power business terminals and the security threats they face, and the security protection requirements of power terminals.

[0048] For example, typical terminal software vulnerabilities include buffer overflows, stack overflows, heap overflows, out-of-bounds read / write, integer overflows, null pointer deference, double-free, and divide-by-zero vulnerabilities. Taking some actual vulnerabilities and attacks in power industrial control systems as examples, this paper analyzes the security threats faced by power industrial control terminals, mainly including replay attacks, denial-of-service attacks, authentication bypass, vendor backdoors, and APT attacks.

[0049] Based on the analysis results, we can add relevant test cases specifically for the aforementioned vulnerabilities during the test case generation process.

[0050] like Figure 1As shown, fuzzing involves constructing a large number of semi-effective test inputs and providing them to the program during the testing process. By monitoring the program's execution, abnormal situations are detected, and these abnormalities often indicate potential security vulnerabilities. Since the data structure of the generated test cases determines the scope of the program's testing, and the data quality directly affects the test results, test case generation is a crucial step in fuzzing.

[0051] Data can be broadly categorized into two types: unstructured data and structured data. Unstructured data refers to data that does not follow a fixed logical structure, such as text, images, audio, and video. Structured data, on the other hand, has a clear structure, follows a certain syntax or model, and is pre-organized by humans, such as the two-dimensional table structure in relational databases, as well as typical data structures like trees and graphs.

[0052] There are two existing methods for generating fuzzy test cases: generation-based and mutation-based. Generation-based fuzzing tools typically generate test inputs by modeling the input data format and state behavior. This method is effective for programs handling highly structured inputs. Mutation-based fuzzing tools modify pre-provided seed test cases by applying a set of mutation operations, thereby generating new test inputs. This method is simple, easy to implement, and highly scalable, and is widely used for generating test cases for unstructured data.

[0053] This embodiment adopts a technical solution of constructing a mutation-based test case generation strategy for the automated generation of test cases for unstructured input.

[0054] This will be explained using fuzzy testing of industrial control protocols as an example.

[0055] 1) Protocol message variation methods

[0056] A message is usually composed of multiple protocols stacked together. However, in protocol fuzzing, only one protocol is often the object of testing. Therefore, before officially starting the mutation of the message content, it is necessary to first determine which content will participate in the mutation and which content will not be mutated.

[0057] 2) Deterministic variation

[0058] Deterministic mutation involves modifying the content of a seed according to a fixed pattern. Test cases generated from the same seed through deterministic mutation will always be identical. When deterministic mutation begins on a seed, it starts from the beginning of the seed content and proceeds according to a predetermined mutation length and step size. Deterministic mutation strategies include bitflip, arithmetic, and interestingvalue.

[0059] 3) havoc

[0060] Havoc refers to a mutation method that involves performing a large number of random mutations on a seed. Each time a seed undergoes havoc, the test cases generated by the mutation may be different. The havoc strategy randomly selects one or more bits in the seed each time, applies a random mutation strategy to the selected bits, and generates new test cases.

[0061] In fuzz testing of industrial control protocols, since binary protocols mostly determine field positions through offsets, arbitrarily inserting or deleting bytes often only generates invalid test cases. Therefore, the havoc strategy in this paper does not change the seed length. The havoc mutation strategies include: bitflip, arithmetic, interestingvalue, and randomvalue, and each mutation strategy has an equal probability of being selected.

[0062] Test cases for structured input:

[0063] When faced with programs that only accept highly structured data input, traditional fuzzing techniques often result in test data being discarded during the program verification phase, preventing deeper exploration and reducing the likelihood of discovering vulnerabilities. Therefore, it's necessary to consider how to effectively construct test cases to achieve better program coverage when testing programs that only allow highly structured data input.

[0064] This embodiment proposes a novel solution for fuzz testing of highly structured input programs. It utilizes syntax to guide the generation of test input: for a target grammar G and a program capable of accepting strings defined by the target language L(G), syntactically valid test input is constructed. This ensures that the generated test cases pass the initial lexical analysis and parsing phases of the program. Furthermore, this method systematically generates test input, thus covering as many edge cases and complex structures as possible, helping to uncover improper handling of these anomalies and related security issues by the target program. To achieve this goal, our method consists of the following two phases:

[0065] Model inference. This stage requires the tester to provide two inputs: a target grammar G and an initial valid test suite. First, the test cases are decomposed into grammatical fragments according to grammar G, resulting in a pool of grammatical fragments, which will be used as the basic building blocks for the next stage. Simultaneously, a subgrammar G′ is derived from the existing test cases; it is a subset of G and maps to the test suite. G′ will be used to guide data generation in the next stage.

[0066] Grammar-aware mutation is used in this phase to mutate existing test cases using the materials provided in the first phase. Specifically, a grammatical fragment is selected, and according to G′, it replaces a fragment in the fragment pool. These two fragments represent the same grammatical components but have different structures. This process is then systematically repeated to generate a large number of new test cases, diversifying their structures.

[0067] The detailed process is described below, such as Figure 2 As shown, the user or tester needs to provide two inputs: the grammar rules of the target grammar G and a set of existing test cases for the target language L(G). This set of test cases will serve as the seed set for our implementation framework. In the first phase, the framework first calls the parser generator to construct a parser for G according to the grammar rules, and uses this parser to transform the test cases in the seed set into a set of parse trees. Then, the framework examines each tree in a bottom-up manner, deriving grammatical components (including non-terminal symbols and corresponding grammar rules) from the tree structure, while also collecting some grammar instance fragments (i.e., a set of derivation sequences). This information is then passed to the test case generation engine in the second phase. When generating new test cases, the generation engine has the opportunity to consult the user on how to perform the next mutation through a mechanism called mutation filtering. In addition, after generating new test cases, the user code also has the opportunity to fine-tune the content of the test string by rewriting certain parts of the test cases. This string is finally added to the generated test case suite.

[0068] This embodiment also considers mutation control mechanisms, allowing users to flexibly control runtime timeout behavior. To achieve this, two mechanisms are introduced: mutation filtering and output rewriting. Their functions are to allow users to guide the behavior of the generation engine when performing data mutation, and to fine-tune the content of the generated test cases, respectively.

[0069] To implement mutation filtering, several checkpoints are set up throughout the main loop of Phase II (syntax-based mutation). Each checkpoint contains a user-defined callback. When the program executes to a checkpoint, it calls the corresponding callback with context information as parameters. The user-defined callback then checks the context, determines the next step, and returns one of the following codes to instruct the engine: CONTINUE, SKIP, or STOP, which respectively indicate continuing the current operation, skipping the current operation to proceed to the next loop, or stopping generation. With the mutation filtering mechanism, the user has the following control:

[0070] Should mutation be performed on the current derived sequence?

[0071] Determine whether the current tuple of the derivation sequence can serve as a branch point;

[0072] Choose which syntax rules to replace the subtree rooted at the current branch point.

[0073] Mutation filtering is most commonly used to set termination conditions for Phase II (syntax-based mutation) iterations, such as terminating the iteration algorithm when the count of generated test cases exceeds a certain threshold. Furthermore, exhaustive strategies for Phase II (syntax-based mutation) may not scale well to certain complex programs. In such cases, testers can use mutation filtering to selectively explore language features of interest or randomly select the branch to perform mutation.

[0074] Another mechanism for controlling the behavior of the generation engine is output rewriting, which allows testers to modify strings before the framework generates the final strings. It works by executing a user-defined callback function on the generated test string immediately after it is generated. Simultaneously, the derivation sequence of the string is passed as an argument to the callback. The derivation sequence faithfully preserves every detail of the corresponding string's syntactic structure. This allows the user code in the callback to further refine the generated test cases.

[0075] The validity of the initial seed input data in fuzzing is quite sensitive to whether vulnerabilities can be discovered when the target program is executed. Therefore, obtaining valid initial input data is an essential part of fuzzing.

[0076] This embodiment of building a test case library for power terminals mainly includes three stages:

[0077] First, initial test cases are collected. Initial input data for fuzzing can be obtained through various methods, including web scraping, generation by the fuzzing tool itself, creation by analysts, and utilizing publicly available datasets. Web scraping typically targets data in specific file formats. Data generated by the fuzzing tool is produced after learning some syntax information of the target program using a specific algorithm. Self-created data is often obtained by analysts from real-world environments, such as captured network packets or input data files in specific formats.

[0078] Secondly, a large number of diverse test cases are generated. Based on the initial test cases, the aforementioned automated test case generation techniques for unstructured input and structured input are used to automatically generate test cases, enriching both the quantity and diversity of test cases.

[0079] Finally, test cases are categorized based on their data type. According to different file and data formats, such as Modbus protocol messages and XML, test cases are named and stored according to predefined rules. This provides an advantageous initial seed for terminal fuzzing, supports the fuzzing engine in quickly covering the target program, and enhances the ability to discover deep-level terminal vulnerabilities.

[0080] Based on the above test cases, fuzz testing can be performed.

[0081] Existing technologies can be used for fuzz testing models / frameworks / tools.

[0082] like Figure 3 As shown, the vulnerability detection process of fuzzing generally consists of several stages, including target identification, input vector determination, test case generation, program execution, anomaly monitoring, vulnerability analysis and assessment.

[0083] After generating test case data, the fuzzing model / framework / tool ​​inputs this data into the target program for execution, monitoring its execution process and the program's termination status. Generally, program termination states include normal exit, execution timeout, suspension, or program crash. Normal program exit indicates that the input data matches the target program's normal execution process, therefore test cases matching this condition are not considered.

[0084] The other three scenarios often arise from potential security issues in the target program, and the test case data that triggers these abnormal events is also the object of further analysis and processing of the target program.

[0085] When an anomaly is detected in program execution, the fuzzing model / framework / tool ​​saves the test cases that triggered the anomaly and records relevant information for subsequent assessment and analysis of program vulnerabilities. Feedback-based fuzzing models / frameworks / tools also provide effective test case variation data and detection information to the test case generator to facilitate the generation of better test cases.

[0086] After successfully obtaining information that could crash the target program through fuzzing, the vulnerability analysis phase begins. In this phase, analysts use various debuggers to analyze the crash data obtained from fuzzing, thereby determining the type, severity, and cause of the vulnerability.

[0087] As one implementation method, such as Figure 4As shown, the components involved in execution include five main parts: a test case generator, a target program execution engine, a monitor, a vulnerability detector, and a vulnerability filter. Static analysis technology primarily assists the fuzzing tool in collecting relevant information about the target program in the early stages. Furthermore, apart from static analysis, the other components in the diagram are mostly completed using dynamic analysis methods.

[0088] Test case generator: Test cases can be generated using the above generation strategies.

[0089] The main considerations in a test case generator are how to formulate an efficient test case generation strategy and ensure the quality of generated test cases. The test case generator generates corresponding malformed data based on the input syntax format of the target program. After generation, it further filters the data based on its validity, sending test cases with a high probability of triggering vulnerabilities to the target program for fuzzing. This avoids the performance overhead caused by too many inefficient test cases and also improves the efficiency of fuzzing to a certain extent.

[0090] Target program execution engine: The target program is the terminal program on which fuzzing tools will be used to detect vulnerabilities, and the purpose of fuzzing is to discover potential software security vulnerabilities in the target program. In practice, a wide variety of target programs can be used for fuzzing, such as network programs, compilers, library files, operating system kernel programs, and other executable programs. Existing technologies can be used, and will not be elaborated further here.

[0091] Fuzzing for terminal firmware can be performed in two environments: real-device fuzzing and simulation-environment fuzzing. Real-device fuzzing involves sending large amounts of data packets to the terminal, monitoring CPU usage, and checking system logs to detect routing protocol vulnerabilities, observe the different behaviors of memory corruption and memory error vulnerabilities on embedded devices, and analyze firmware vulnerabilities. Simulation-environment fuzzing utilizes real devices to handle firmware I / O interactions, executes firmware programs using emulators, and forwards access to real peripherals encountered during execution to the real devices for processing. For peripheral hardware that cannot be accessed, corresponding software abstraction is implemented.

[0092] Monitors: During the execution of the target program, various operational metrics are monitored to collect information about the program's runtime, such as the program execution path, triggered system signals, whether the program exits normally, whether it crashes, whether it hangs, and many other monitoring indicators. By monitoring the target program's execution process, not only can specific events be used to analyze and determine whether input data is valid and whether vulnerabilities are triggered, but also the collected information can be fed back in real time during fuzzing to improve the quality of test case generation.

[0093] Vulnerability detectors analyze the execution results of the target program after receiving input data. They determine whether a potential vulnerability in the target program has been successfully triggered by using the input data and the execution results. If a vulnerability is triggered, it is passed to a vulnerability filter for further screening; otherwise, no action is taken. Commonly used methods in this stage include symbolic execution, coverage feedback, and taint analysis, which will not be elaborated upon here. It can monitor the program's execution status in real time.

[0094] Vulnerability filter: Used to screen for vulnerabilities. After the vulnerability filter stage is completed, the entire fuzzing detection task is finished.

[0095] Example 2

[0096] An automated test case generation system for power system terminals, comprising:

[0097] The security protection analysis module is configured to target business terminals in all aspects of the power system, and based on security protection requirements, analyze the impact of vulnerability exploitation attacks on each terminal on the safe and stable operation of the power grid from a network attack and defense perspective.

[0098] The automatic generation module is configured to build a mutation-based test case generation strategy, which is used to generate test cases for unstructured inputs and to generate test cases for structured inputs using syntax descriptions and mutations, forming a test case library for power terminals.

[0099] The fuzzing module is configured to train a fuzzing model, execute test cases, and perform fuzzing tests based on the test case library for power terminals.

[0100] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0101] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0102] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0103] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0104] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0105] While the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, this is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solutions of the present invention are still within the scope of protection of the present invention.

Claims

1. A method for power system terminal oriented test case automatic generation, characterized in that, Includes the following steps: The test input data is classified, and a mutation-based test case generation strategy is constructed. This strategy is used to generate test cases for unstructured inputs and to generate test cases for structured inputs using syntax description and mutation, thus forming a test case library for power terminals. The specific process of generating test cases with structured input using syntax description and mutation includes: The existing test cases are decomposed into grammar fragments according to the grammar G to obtain a grammar fragment pool. A sub-grammar G′ is derived from the existing test cases. It is a subset of the grammar G and has a mapping relationship with the test suite. Repeatedly execute the process of replacing a fragment in the fragment pool based on the subsyntactic G′. The two syntactic fragments represent the same syntactic components but have different structures, generating new test cases. Based on the aforementioned test case library for power terminals, a fuzzy testing model is trained, test cases are executed, and fuzzy testing is performed.

2. The method for power system terminal oriented test case automatic generation as claimed in claim 1, wherein, The specific process of constructing a mutation-based test case generation strategy and using it to generate test cases for unstructured input includes: determining the message content, dividing it into content that participates in mutation and content that does not participate in mutation, and for content that participates in mutation, mutating the seed content according to a fixed pattern. Test cases generated by deterministic mutation of the same seed are the same. Mutation starts from the beginning of the seed content according to the set mutation length and step size.

3. A method for power system terminal oriented test case automatic generation as claimed in claim 2, wherein The mutation process also includes performing a large number of random mutations on the seed to be mutated. Each time, a certain bit or several bits in the seed are randomly selected, and a mutation strategy is randomly applied to the selected bytes to generate new test cases. However, the length of the seed is not changed during this process.

4. The method for power system terminal oriented test case automatic generation as claimed in claim 1, wherein, In the process of repeatedly replacing a fragment in the fragment pool according to the subsyntax G′, a mutation filtering mechanism is added. Multiple monitoring points are set during repeated execution, and each monitoring point contains a user-defined callback program. When a monitoring point is executed, the callback program is called with context information as a parameter, the context is checked, and the next execution instruction is determined.

5. The method for power system terminal oriented test case automatic generation as claimed in claim 1 or 4, characterized in that, During the repeated execution of replacing a fragment in the fragment pool based on subsyntax G′, an output rewriting mechanism is added. After generating a new test case string, a user-defined callback is immediately executed on it. At the same time, the derivation sequence of the string is also passed as a parameter to the callback to perform further operations on the generated test case. Alternatively, the generated test cases can be named and categorized according to predefined rules.

6. A method for power system terminal oriented test case automatic generation as claimed in claim 1 wherein, Based on the aforementioned test case library for power terminals, the specific process of training a fuzzy testing model, executing test cases, and performing fuzzy testing includes: Based on the input syntax format of the target program, corresponding malformed data is generated. After generation, the data is filtered according to its validity. Test cases that trigger the vulnerability with a probability exceeding the set value are sent to the target program for fuzzing. The generated test cases are input into the target program for execution. The execution process and the state of the program's end are monitored. When abnormal information is detected in the program execution, the test cases that triggered the abnormal information are saved, and relevant information is recorded for subsequent judgment and analysis of program vulnerabilities.

7. A system for power system terminal oriented test case automatic generation method as claimed in any one of the claims 1 to 6, wherein, include: The security protection analysis module is configured to target business terminals in all aspects of the power system, and based on security protection requirements, analyze the impact of vulnerability exploitation attacks on each terminal on the safe and stable operation of the power grid from a network attack and defense perspective. The automatic generation module is configured to build a mutation-based test case generation strategy, which is used to generate test cases for unstructured inputs and to generate test cases for structured inputs using syntax descriptions and mutations, forming a test case library for power terminals. The fuzzing module is configured to train a fuzzing model, execute test cases, and perform fuzzing tests based on the test case library for power terminals.

8. A computer-readable storage medium, characterized in that, It stores multiple instructions adapted for loading by the processor of a terminal device and executing the steps of the method according to any one of claims 1-6.

9. A terminal device, characterized in that, It includes a processor and a computer-readable storage medium, the processor being used to implement various instructions; the computer-readable storage medium being used to store a plurality of instructions adapted to be loaded by the processor and executed in the steps of the method of any one of claims 1-6.

Images