Fuzzing method and system
By dynamically adjusting the testability of interfaces and test programs, and combining multi-agent systems for mutation testing, the problem of low coverage in existing fuzz testing is solved, improving testing efficiency and vulnerability discovery capabilities, and adapting to various APIs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SAMSUNG (CHINA) SEMICONDUCTOR CO LTD
- Filing Date
- 2026-05-29
- Publication Date
- 2026-06-30
AI Technical Summary
Existing fuzzing solutions lack effective methods to improve test coverage, resulting in poor testing efficiency and effectiveness. Furthermore, traditional mutation strategies have limited generalization capabilities and are difficult to adapt to a wide variety of APIs.
By analyzing the code coverage of the previous round of tests, the likelihood of interfaces and test programs being tested in the next round of tests is dynamically adjusted. A multi-agent system is used to mutate the test programs, generating semantically reasonable and structurally effective mutated test programs, and optimizing the call sequence to improve coverage.
It enables rapid breakthroughs in coverage bottlenecks, improves the efficiency of fuzz testing and vulnerability discovery capabilities, supports complex logic and semantically reasonable mutations, and possesses good flexibility and versatility.
Smart Images

Figure CN122310550A_ABST
Abstract
Description
Technical Field
[0001] This disclosure generally relates to the field of fuzz testing technology, and more specifically, to a fuzz testing method, system, electronic device, non-transitory storage medium, and program product. Background Technology
[0002] Code vulnerabilities can seriously threaten the security of system and application software, leading to irreparable accidents across various industries. Fuzzing plays a crucial role in the software development process by proactively identifying potential vulnerabilities.
[0003] Fuzz testing is an automated testing method that discovers software vulnerabilities by inputting unexpected data into a target program and monitoring abnormal results. For example, it can generate random or semi-random data as test input to trigger abnormal behaviors such as program crashes and memory errors, thereby exposing code defects. It is suitable for discovering system security vulnerabilities.
[0004] In fuzz testing, the ability to quickly improve test coverage is key to testing efficiency and effectiveness. However, existing testing solutions still lack effective methods to guide the improvement of coverage.
[0005] The information disclosed in this background section was known to the inventors prior to the disclosure of this application, or was technical information obtained during the process of implementing the disclosure. Therefore, it may include information that will not form prior art known to the public. Summary of the Invention
[0006] Various embodiments of this disclosure provide a fuzz testing method, system, electronic device, non-transitory storage medium, or program product that can solve at least one of the aforementioned problems existing in the related art.
[0007] According to a first aspect of the embodiments of this disclosure, a fuzzing method is provided, wherein the fuzzing method includes: performing fuzzing tests on an object under test using test programs based on executing at least one round of test operations, wherein the object under test includes one or more interfaces, each test program is used to test the one or more interfaces, wherein each round of test operations includes: determining a first metric for each interface and a second metric for each test program based on the code coverage of at least the previous round of test operations, wherein the first metric is based on the probability that the interface is tested, and the second metric is based on the probability that the test program is tested, wherein in the first round of test operations, the first metric and the second metric are initial values; selecting a target interface for the current round of test operations from the one or more interfaces based on the first metric of each interface; selecting a target test program for the current round of test operations from test programs used to test the target interface based on the second metric of each test program; and performing fuzzing tests on the target interface using the target test program to obtain the result of the current round of test operations.
[0008] Optionally, determining the first metric for each interface and the second metric for each test program includes: determining the first code coverage of the target interface and the second code coverage of the target test program in at least the previous round of test operations based on the code coverage of at least the previous round of test operations; updating the first metric for each of the one or more interfaces based on the first code coverage; and updating the second metric for each test program based on the second code coverage.
[0009] Optionally, updating the first metric of each of the one or more interfaces includes: adjusting the first metric of the target interface in at least the previous round of test operations in a negative correlation with the first code coverage, wherein updating the second metric of each test program includes: adjusting the second metric of the target test program in at least the previous round of test operations in a positive correlation with the second code coverage.
[0010] Optionally, the step of fuzzing the target interface includes: obtaining a first test result based on a first fuzzing test of the target interface, wherein the first fuzzing test is based on the target testing program; obtaining a second test result based on at least one second fuzzing test of the target interface, wherein in each of the at least one second fuzzing test, the target interface is fuzzed using a mutation testing program based on a mutation of the target testing program; and obtaining the result of this round of testing based on the first test result and the second test result.
[0011] Optionally, in each of the at least one second fuzz test, the mutated test program is determined at least in the following ways: mutating the target test program based on the currently fed-out test result and the semantics of the target test program, wherein the currently fed-out test result includes at least one of the first test result and the test result of the previous second fuzz test; obtaining candidate mutated programs based on the mutated target test program; and obtaining the mutated test program based on the candidate mutated programs.
[0012] Optionally, the mutation of the target test program includes: determining a first interface called by the target test program based on the semantics of the target test program, wherein the first interface includes the target interface and a second interface; determining a target mutation strategy for the first interface based on the current feedback test results; mutating the first interface based on the target mutation strategy; and obtaining a candidate mutated program based on the mutated first interface.
[0013] Optionally, the target mutation strategy includes at least one of the following: replacing the second interface with a new second interface; adding the new interface to the call relationship of the first interface; changing the call mode of the second interface to parallel call.
[0014] Optionally, replacing the second interface with a new second interface includes: selecting a second interface to be replaced based on a first indicator of each second interface; and selecting a third interface from the interfaces of the tested object other than the first interface to replace the second interface to be replaced, wherein the first indicator of the third interface is greater than the first indicator of the second interface to be replaced.
[0015] Optionally, adding a new interface to the call relationship of the first interface includes: selecting a fourth interface to add to the interface call relationship of the target test program based on a first indicator of the interfaces of the tested object other than the first interface.
[0016] Optionally, obtaining the mutation test program based on the candidate mutation program includes: optimizing the code of the candidate mutation program to obtain an optimized program; performing at least one syntax verification on the optimized program to obtain the mutation test program, wherein each syntax verification includes: verifying the syntax correctness of a target verification program, wherein in the first syntax verification, the target verification program is the optimized program; selecting the target verification program as the mutation test program based on the first verification passing; performing syntax repair on the target verification program based on the first verification failing; and obtaining a second target verification program based on the syntax repair, wherein the second syntax verification is based on the second target verification program.
[0017] Optionally, each second fuzz test includes: performing a fuzz test on the target interface using the mutation test program of this second fuzz test to obtain the code coverage of this second fuzz test; taking the result of this second fuzz test as the second test result based on the code coverage of this second fuzz test being greater than the code coverage of the first fuzz test; and executing the next second fuzz test based on the code coverage of this second fuzz test being less than or equal to the code coverage of the first fuzz test, wherein the code coverage includes: the code coverage of the target interface and / or the code coverage of the target test program.
[0018] According to a second aspect of the embodiments of this disclosure, a fuzz testing system is provided. The fuzz testing system performs fuzz testing on a test object using test programs based on executing at least one round of test operations. The test object includes one or more interfaces, and each test program is used to test at least one of the one or more interfaces. The fuzz testing system includes: a memory configured to store instructions; and at least one processor configured to execute the instructions to: determine a first metric for each interface and a second metric for each test program based on code coverage of at least the previous round of test operations. The first metric is based on the probability that the interface is tested, and the second metric is based on the probability that the test program is tested. In the first round of test operations, the first metric and the second metric are initial values. Based on the first metric of each interface, a target interface for the current round of test operations is selected from the one or more interfaces. Based on the second metric of each test program, a target test program for the current round of test operations is selected from test programs used to test the target interface. Based on the target test program, fuzz testing is performed on the target interface to obtain the result of the current round of test operations.
[0019] Optionally, the at least one processor is further configured to: determine a first code coverage of the target interface in at least the previous round of test operations and a second code coverage of the target test program in at least the previous round of test operations based on the code coverage of the previous round of test operations; update a first metric for each of the one or more interfaces based on the first code coverage; and update a second metric for each test program based on the second code coverage.
[0020] Optionally, the at least one processor is further configured to: adjust a first metric of the target interface in at least the previous round of test operations in a negative correlation with the first code coverage; and adjust a second metric of the target test program in at least the previous round of test operations in a positive correlation with the second code coverage.
[0021] Optionally, the at least one processor is further configured to: obtain a first test result based on a first fuzz test of the target interface, wherein the first fuzz test is based on the target test program; obtain a second test result based on at least one second fuzz test of the target interface, wherein in each second fuzz test, the target interface is fuzz tested using a mutation test program based on a mutation of the target test program; and obtain the result of the current round of testing based on the first test result and the second test result.
[0022] Optionally, the at least one processor is further configured to: mutate the target test program based on the currently fed-out test results and the semantics of the target test program, wherein the currently fed-out test results include at least one of the first test results and the test results of the previous second fuzz test; obtain candidate mutated programs based on the mutated target test program; and obtain the mutated test program based on the candidate mutated programs.
[0023] Optionally, the at least one processor is further configured to: determine a first interface invoked by the target test program based on the semantics of the target test program, wherein the first interface includes the target interface and a second interface; determine a target mutation strategy for mutating the first interface based on the currently fed-out test results; mutate the first interface based on the target mutation strategy; and obtain a candidate mutation program based on the mutated first interface.
[0024] Optionally, the target mutation strategy includes at least one of the following: replacing the second interface with a new second interface; adding the new interface to the call relationship of the first interface; changing the call mode of the second interface to parallel call.
[0025] Optionally, the at least one processor is further configured to: select a second interface to be replaced based on a first index of each second interface; and select a third interface from the interfaces of the test program other than the first interface to replace the second interface to be replaced, wherein the first index of the third interface is greater than the first index of the second interface to be replaced.
[0026] Optionally, the at least one processor is further configured to: select a fourth interface to be added to the interface call relationship of the target test program based on a first indicator of the interfaces of the test program other than the first interface.
[0027] Optionally, the at least one processor is further configured to: optimize the candidate mutation program to obtain an optimized program; perform at least one syntax verification on the optimized program to obtain the mutation test program, wherein each syntax verification includes: verifying the syntax correctness of a target verification program, wherein in the first syntax verification, the target verification program is the optimized program; based on the first verification passing, using the target verification program as the mutation test program; based on the first verification failing, performing syntax repair on the target verification program; and based on the syntax repair, obtaining a second target verification program, wherein the second syntax verification is based on the second target verification program.
[0028] Optionally, the at least one processor is further configured to perform each second fuzz test by: performing a fuzz test on the target interface using the mutation test program of this second fuzz test to obtain the code coverage of this second fuzz test; taking the result of this second fuzz test as the second test result based on the code coverage of this second fuzz test being greater than the code coverage of the first fuzz test; and performing the next second fuzz test based on the code coverage of this second fuzz test being less than or equal to the code coverage of the first fuzz test, wherein the code coverage includes: the code coverage of the target interface and / or the code coverage of the target test program.
[0029] According to a third aspect of the embodiments of the present disclosure, an electronic device is provided, wherein the electronic device includes: a processor; and a memory for storing processor-executable instructions, wherein the processor-executable instructions, when executed by the processor, cause the processor to perform a fuzz testing method according to the embodiments of the present disclosure.
[0030] According to a fourth aspect of the embodiments of the present disclosure, a computer-readable storage medium is provided, wherein when instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform a fuzz testing method according to embodiments of the present disclosure.
[0031] According to a fifth aspect of the embodiments of the present disclosure, a computer program product is provided, including computer-executable instructions, wherein the computer-executable instructions, when executed by at least one processor, implement the fuzzing method as described in the embodiments of the present disclosure.
[0032] According to the fuzzing scheme of this disclosure, during the testing process, the probability of each interface and each test program being tested in the next round of testing can be dynamically adjusted by analyzing the code coverage of the previous round of testing. This allows for test scheduling at both the interface and test program levels, guiding testing towards improved coverage. Consequently, it enables rapid access to and overcoming of coverage bottlenecks, quick discovery of potential vulnerabilities, and more intelligent allocation of resources and tasks. Furthermore, the interface-level scheduling strategy achieves efficient call sequence optimization, improving coverage of deep test logic.
[0033] Furthermore, the fuzzing scheme according to the embodiments of this disclosure utilizes an intelligent agent to mutate the test program, which can generate a mutated test program that is semantically reasonable, structurally effective, and logically coherent, thereby helping to improve the efficiency of fuzzing and the ability to discover vulnerabilities.
[0034] Furthermore, the fuzzing scheme according to embodiments of this disclosure, through a semantic-level mutation strategy, can overcome the coverage bottleneck of fuzzing, achieving high-coverage intelligent exploration, and supporting mutations with complex logic and semantic rationality. Moreover, this mutation strategy supports multiple programming languages, possessing good flexibility and versatility.
[0035] In the following description, some aspects and / or advantages of the general concept of this disclosure will be set forth, and other aspects and / or advantages will become apparent from the following description or from practice of the general concept of this disclosure. Attached Figure Description
[0036] These and / or other aspects and advantages of this disclosure will become clearer and more readily understood from the following detailed description of embodiments of this disclosure taken in conjunction with the accompanying drawings.
[0037] Figure 1 A schematic flowchart illustrating the test operations in a fuzz testing method according to an embodiment of the present disclosure is shown.
[0038] Figure 2 A schematic architecture diagram of a fuzz testing method according to an embodiment of the present disclosure is shown.
[0039] Figure 3 A schematic diagram of a two-dimensional fuzzy testing scheduling mechanism according to an embodiment of the present disclosure is shown.
[0040] Figure 4 A schematic flowchart illustrating fuzz testing of a target interface according to an embodiment of the present disclosure is shown.
[0041] Figure 5 A schematic diagram illustrating a multi-agent semantic level test procedure mutation strategy according to an embodiment of the present disclosure is shown.
[0042] Figure 6A schematic flowchart of a mutation determination test procedure according to an embodiment of the present disclosure is shown.
[0043] Figure 7A , Figure 7B and Figure 7C A schematic diagram illustrating a semantic-level variation strategy according to an embodiment of the present disclosure is shown.
[0044] Figure 8 A schematic diagram showing the coverage growth curve of a fuzz testing method according to an embodiment of the present disclosure is provided.
[0045] Figure 9 A structural block diagram of a fuzz testing system according to an embodiment of the present disclosure is shown.
[0046] Figure 10 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation
[0047] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings, examples of which are illustrated in the drawings, wherein the same reference numerals always refer to the same parts. The embodiments will be described below with reference to the accompanying drawings in order to explain this disclosure. The embodiments described herein are non-limiting exemplary embodiments, and therefore, this disclosure is not limited thereto and can be implemented in various other forms. Each embodiment provided herein does not exclude association with one or more features in other examples or other embodiments also provided herein or not provided herein but consistent with this disclosure.
[0048] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the steps of this disclosure can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than those illustrated or described herein. The embodiments described below do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0049] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" and "including at least one of A or B" include the following three parallel cases: (1) including A; (2) including B; (3) including A and B. For another example, "performing at least one of step one and step two" indicates the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.
[0050] As mentioned earlier, existing fuzz testing schemes still lack effective methods to guide improvements in coverage.
[0051] For example, in testing solutions for related technologies, there is a lack of efficient interface and test program (or driver) scheduling mechanisms, and a lack of semantic understanding of the code regarding the mutation strategies of test programs, resulting in low mutation efficiency. Furthermore, traditional mutation strategies have limited generalization capabilities and are difficult to adapt to a wide variety of APIs.
[0052] In view of the above problems, embodiments of this disclosure provide a fuzz testing method, a fuzz testing system, an electronic device, a computer non-transitory storage medium, and a computer program product to at least solve or alleviate at least one of the above problems.
[0053] According to a first aspect of the embodiments of this disclosure, a fuzzing method is provided. According to the embodiments, the fuzzing method can be executed by an electronic device. According to the embodiments, the electronic device can be at least one of a tablet computer, a laptop computer, a digital assistant, etc. According to the embodiments, the electronic device can perform fuzzing tests on a target program / system / code by executing the fuzzing method using a fuzzing test program or driver. The fuzzing method according to the embodiments of this disclosure can also be applied to other application scenarios. For example, the electronic device can request a training model from a server via a network, and the server can complete the request by executing the fuzzing method. According to the embodiments, the server can be at least one of a standalone server, a server cluster, a cloud computing platform, and a virtualization center.
[0054] According to embodiments of this disclosure, the fuzzing method may include: performing fuzzing tests on the object under test by executing at least one round of test operations using a test program.
[0055] According to an embodiment, the object under test may include interfaces, and each test program may be used to test at least one of the interfaces.
[0056] As an example, the object under test can be at least one of an application, a system, code, etc. However, the object under test is not limited to these examples. According to an embodiment, the interface can be an API. According to an embodiment, the test program can serve as a test case, which can test the corresponding interface by calling the interface of the object under test. The test program can be generated or obtained in any way, and the embodiments of this disclosure do not impose any particular limitations on the test program, the object under test, or the fuzzing tools described below.
[0057] During fuzz testing, the above testing operations can be performed one or more rounds until the test termination condition is met. According to an embodiment, the test termination condition may be achieving the expected code coverage or reaching a preset number of test rounds, etc.
[0058] like Figure 1 As shown, according to embodiments of this disclosure, each round of testing may include the following steps: In step S110, the first metric for each interface and the second metric for each test program can be determined based on the code coverage of the previous round of test operations.
[0059] According to the embodiment, the first indicator can characterize the likelihood of the interface being tested, and the second indicator can characterize the likelihood of the test program being tested. In the first round of testing, the first and second indicators can be initial values, which can be set as needed.
[0060] For example, in step S110, the probability (e.g., the likelihood) of each interface and each test program being tested in the current test operation can be adjusted based on the coverage of the previous round of test operations. According to an embodiment, the first indicator may be, for example, the energy of the interface in fuzz testing (e.g., sampling probability), and the second indicator may be, for example, the energy of the test program in fuzz testing.
[0061] According to an embodiment, step S110 may include: determining a first code coverage of the target interface and a second code coverage of the target test program in the previous round of testing based on the code coverage of the previous round of testing; updating a first metric for each interface based on the first code coverage; and updating a second metric for each test program based on the second code coverage.
[0062] According to an embodiment, each interface may have its own first metric, and each test program may have its own second metric. After each round of testing, the first metrics of all interfaces can be updated based on the code coverage of the target interface being tested. According to an embodiment, after each round of testing, the second metrics of all test programs can also be updated based on the code coverage of the target test program being tested. According to an embodiment, the update may include at least one of increasing, decreasing, or remaining unchanged. According to an embodiment, updating the first and second metrics may include updating the first and second metrics from the interface dimension and the test program dimension, respectively.
[0063] Figure 2 An example architecture for implementing a fuzz testing method according to embodiments of the present disclosure is shown. Figure 2In the embodiment shown, at least one test program 10 can be input into a two-dimensional fuzzing scheduler, which can update the first index of each interface and the second index of each test program 10 based on the test results obtained after each round of testing.
[0064] According to an embodiment, updating the first metric for each interface may include adjusting the first metric of the target interface in the previous round of testing in a negative correlation with the first code coverage. According to an embodiment, updating the second metric for each test program may include adjusting the second metric of the target test program in the previous round of testing in a positive correlation with the second code coverage.
[0065] According to the embodiment, for the target interface being tested, the higher the first code coverage, the greater the likelihood that the target interface will be covered; conversely, the lower the first code coverage, the less likely that the target interface will be covered. Therefore, the first index of each target interface can be adjusted in a negative correlation with the first code coverage, so that the interface with low first code coverage is more likely to be called in the next round of testing, thereby allocating more test resources to the interface.
[0066] According to the embodiment, for the target test program being tested, the higher the second code coverage, the greater the likelihood that the target test program will cover the lines of code in the interface; conversely, the lower the second code coverage, the less likely that the target test program will cover the lines of code in the interface. Therefore, the second index of each target test program can be adjusted in a positive correlation with the second code coverage, so that the test program with a high second code coverage is more likely to be called in the next round of testing, thereby better covering the lines of code of the interface under test.
[0067] As an example, the first code coverage and the second code coverage can be represented by the basic block coverage.
[0068] Figure 3 A two-dimensional fuzzy testing scheduling mechanism according to an embodiment of this disclosure is illustrated. For example... Figure 3 As shown, the Coverage Parser 200 can be used to analyze the basic block (BB) offsets covered by the test program 10 used in this round of testing, so as to accurately count the basic block offsets involved in each target interface.
[0069] According to an embodiment, the input to the coverage parser 200 may be the test program 10 used in this round of testing and the basic blocks it covers. The coverage parser 200 may utilize at least one of Static Code Analysis (SCA) tools and Dynamic Code Analysis (DCA) tools, as well as the interface call graph corresponding to the binary file of the fuzzing target, to pre-analyze the offset range of the basic blocks involved in the interface calls. According to an embodiment, the output of the coverage parser 200 may be the basic blocks covered by the interfaces involved in the target test program.
[0070] According to an embodiment, the two-dimensional fuzz test scheduler can receive the output of the coverage parser 200. For example, the input of the two-dimensional fuzz test scheduler can be the target test program of the previous round of testing operations and the basic blocks it covers, as well as the basic blocks covered by the target interface involved in the target test program. In order to obtain the first code coverage and the second code coverage, the two-dimensional fuzz test scheduler can determine the basic block coverage of the target interface and the basic block coverage of the target test program based on the output of the coverage parser 200.
[0071] According to the embodiments and as follows Figure 3 As shown, the two-dimensional fuzz test scheduler may include an API scheduler 110, which can update a first metric for each interface based on a first code coverage rate. According to an embodiment, the two-dimensional fuzz test scheduler may include a fuzz driver scheduler 120, which can update a second metric for each test program 10 based on a second code coverage rate.
[0072] Return to reference Figure 1 According to the embodiment, in step S120, the target interface for this round of test operations can be selected from the interfaces based on the first indicator.
[0073] According to an embodiment, given a first metric for each interface, the target interface to be tested in this round of testing can be selected from all interfaces using a method such as sampling. According to the embodiment, the probability of each interface being sampled can be determined based on the first metric.
[0074] For example, such as Figure 3 As shown, at the interface level, the energy (e.g., sampling probability) corresponding to different interfaces can be different (but they can also be the same). Interfaces with higher energy have a higher probability of being sampled and therefore may be tested more often.
[0075] In step S130, the target test program for this round of testing operations can be selected from the test programs used to test the target interface based on the second metric.
[0076] According to the embodiment, once the target interface is determined, the target test program can be sampled based on the second indicator in the test program corresponding to the target interface.
[0077] According to the embodiments, such as Figure 3 As shown, each interface can correspond to multiple test programs. In terms of test programs, for a certain target interface, the energy (e.g., sampling probability) of different test programs can be different (but they can also be the same). Test programs with higher energy have a greater probability of being sampled, so test programs with higher energy are more likely to be selected for testing the target interface.
[0078] According to an embodiment, Figure 3 The output of the two-dimensional fuzzing scheduler shown may include target test programs and target interfaces, which may have the potential to improve code coverage. The two-dimensional fuzzing scheduler may include at least one of an interface scheduler 110 (e.g., an interface scheduler) and a test program scheduler 120. The interface scheduler 110 may update a first metric for each interface based on a first code coverage, and the test program scheduler 120 may update a second metric for each test program 10 based on a second code coverage.
[0079] Return to reference Figure 1 In step S140, according to the embodiment, the target interface can be fuzz-tested using the target testing program to obtain the results of this round of testing operations.
[0080] According to the embodiments, various existing fuzzing methods can be used to perform fuzzing tests on the target interface using a target testing program; according to the embodiments, fuzzing testing can be based on a multi-agent system, such as... Figure 2 As shown, the target test program and target interface will be provided to the multi-agent system 300, which will be described in more detail below.
[0081] Based on the above reference Figures 1 to 3 The various embodiments described can predict (e.g., sample) test procedures and interfaces with coverage improvement potential for use in the current round of testing, based on the results of the previous round of testing. According to embodiments, such test procedures and interfaces with improvement potential can accelerate the rate of coverage growth.
[0082] According to the implementation, the bottleneck of fuzz test coverage can be quickly reached. By dynamically parsing code coverage such as basic block offsets from the feedback of fuzz testing, two different types of code coverage are obtained from two dimensions (or levels) of interface and test program. The code coverage of these two dimensions can efficiently guide the scheduling and mutation in the next round of fuzz testing.
[0083] The fuzz testing mechanism based on a multi-agent system according to an embodiment of the present disclosure in step S140 will now be described.
[0084] like Figure 4 As shown, step S140 above may include the following steps: In step S410, the first intelligent agent can perform a first fuzz test on the target interface to obtain a first test result.
[0085] According to an embodiment, the first intelligent agent can act as a fuzzing agent, which performs fuzzing tests based on the target testing program of the current round by invoking tools such as fuzzers.
[0086] In step S420, the second intelligent agent can perform at least one second fuzz test on the target interface to obtain the second test result.
[0087] According to an embodiment, in each second fuzz test, a mutation test program based on the mutation of the target test program can be used to perform a second fuzz test on the target interface.
[0088] As an example, the second agent can act as a fuzzing valid agent, performing fuzzing by invoking tools such as fuzzers to utilize mutation testers.
[0089] According to the embodiments, the target test program can be mutated based on preset rules and / or preset mutation strategies to obtain a mutated test program.
[0090] In the example, according to embodiments of this disclosure, a mutated fuzz driver (MFD) can also be obtained by an intelligent agent based on a semantic understanding of the target test program.
[0091] According to the embodiments, such as Figure 6 As shown, in each second fuzz test, the mutation testing procedure can be determined based on the following method: In step S610, a third intelligent agent can mutate the target test program based on the currently fed-back test results and the semantics of the target test program to obtain candidate mutated programs. According to the embodiment, the currently fed-back test results include the first test result and / or the test result of the previous second fuzz test.
[0092] As an example, the third agent can act as a mutation manager agent, which can apply mutation strategies to the target test program in the current round of mutation testing based on the results of the first test and / or the fuzzy test results obtained from the previous round of mutation testing.
[0093] According to an embodiment, step S610 may include: determining a first interface to be called by the target test program based on the semantics of the target test program, wherein the first interface includes a target interface and a second interface. According to an embodiment, step S610 may include: determining a target mutation strategy for mutating the first interface based on the currently fed-back test results. According to an embodiment, step S610 may include: obtaining candidate mutation programs based on mutating the first interface according to the target mutation strategy.
[0094] According to an embodiment, when testing a target interface, the target test program may call a second interface that has a dependency / calling relationship with the target interface. For example, according to an embodiment, for a target interface T, there may be second interfaces a, b, c, d, and e, and T and its second interfaces may have a calling relationship of "a→b→T→c→d→e". In an embodiment, during testing, the target test program also needs to call at least one second interface in order to test the target interface T.
[0095] According to an embodiment, the third intelligent agent can model the target test program to parse out the first interface called by the target test program and the corresponding call relationships between the first interfaces, such as "a→b→T→c→d→e" as mentioned above. The mutation of the target test program can be achieved by mutating the first interface.
[0096] According to an embodiment, the third agent can analyze, based on the current feedback test results, which mutation strategy to use to mutate the first interface of the target test program. According to an embodiment, one or more preset mutation strategies can be selected for mutation.
[0097] For example, such as Figures 7A to 7C As shown, the mutation strategy for the first interface may include at least one of the following: replacement mutation strategy, insertion mutation strategy, and parallel invocation mutation strategy.
[0098] According to an embodiment, the first interface can be modified in at least one of the following ways: replacing the second interface with a new interface; adding a new interface to the calling relationship of the first interface; changing the calling method of the second interface to parallel calling.
[0099] According to an embodiment, replacing the second interface with a new interface may include at least one of the following methods: selecting the second interface to be replaced based on a first indicator of each second interface; and selecting a third interface from the interfaces of the tested object other than the first interface to replace the second interface to be replaced.
[0100] According to an embodiment, the first index of the third interface can be greater than the first index of the second interface to be replaced.
[0101] According to an embodiment, based on a first metric of the second interface, a second interface with a relatively low first metric can be selected as the second interface to be replaced; according to an embodiment, an interface with a relatively high first metric can be selected from other interfaces besides the first interface to replace the aforementioned second interface to be replaced. Since the interface with a higher first metric is more likely to improve coverage, the test results of the candidate mutation program are also more likely to improve coverage after the replacement mutation. According to an embodiment, "selection" can be based on sampling based on the first metric.
[0102] Figures 7A to 7C Examples of semantic-level mutation strategies are shown, wherein the first interface invoked by the target test program 10 includes a, b, c, T, d, and c, where T is the target interface and a, b, c, d, and c are second interfaces. However, this disclosure is not limited to such example strategies.
[0103] According to the embodiments, such as Figure 7A As shown, in the example of replacement mutation, the first interface can be input into the interface scheduler 110 described above. Through the interface scheduler 110, a low-energy (or with a smaller first metric) interface can be sampled from the second interface and removed. Figure 7A In this process, the second interface d can be sampled as the interface to be replaced. Alternatively, the interface scheduler 110 can sample a high-energy (or with a larger first index) third interface (e.g., interface f) from among the interfaces other than the first interface to replace the aforementioned second interface d. According to an embodiment, candidate mutation programs are obtained using tools such as SCA, and the interface call relationship of the candidate mutation programs can be "a→b→T→c→f→e".
[0104] According to an embodiment, adding a new interface to the calling relationship of the first interface may include: selecting a fourth interface to add to the interface calling relationship of the target test program based on the first index of the interfaces of the object under test other than the first interface.
[0105] Specifically, from among the interfaces other than the first interface, an interface with a relatively high first metric can be selected and inserted into any position in the interface call relationship of the target test program. Since interfaces with higher first metrics are more likely to improve coverage, the test results of the candidate mutated program are also more likely to improve coverage after insertion and mutation.
[0106] like Figure 7B As shown in the embodiment, in the example of insertion mutation, the first interface can be input into the interface scheduler mentioned above. Through the interface scheduler, a high-energy (or with a large first index) fourth interface (e.g., interface f) is sampled from the second interface and added to the call relationship "a→b→T→c→d→e". Through tools such as SCA, candidate mutation programs are obtained. The interface call relationship of the candidate mutation program can be "a→b→T→c→d→f→e".
[0107] According to the embodiment, the calling method of the second interface can be changed to parallel calling.
[0108] In the example of parallel call mutation, LLM analysis can be used to analyze the code semantics of the target test program and modify some interfaces to be called in parallel to explore the performance of the fuzzing target in complex scenarios. For example... Figure 7C As shown, in the candidate mutation procedure, the second interfaces b, c, and e are called in parallel.
[0109] It should be noted that the above mutation strategies can be used individually or in combination. For example, after the mutation is replaced, some interfaces can be modified to be called in parallel.
[0110] Return to reference Figure 6 According to an embodiment, in step S620, a mutation test program can be obtained based on the candidate mutation program.
[0111] According to an embodiment, candidate mutation programs can be used as mutation testing programs.
[0112] According to an embodiment, step S620 may include: optimizing the candidate mutation program based on the fourth intelligent agent to obtain an optimized program. According to an embodiment, step S620 may include: performing at least one syntax verification on the optimized program to obtain a mutation test program.
[0113] According to an embodiment, in order to improve the compilation success rate of the optimized program, the fourth agent can act as an optimization management agent (Fuzz Driver Refine Manager Agent), which can optimize the candidate mutated program obtained from the mutation based on preset rules. According to the embodiment, the preset rules can be given according to actual needs, for example, they can be existing code optimization rules.
[0114] According to an embodiment, in step S620, each syntax verification may include: verifying the grammatical correctness of the target verification program by a fifth agent; selecting the target verification program as a mutation test program in response to a successful verification; and performing syntax repair on the target verification program by a sixth agent in response to a failed verification, to obtain the target verification program for the next syntax verification. According to an embodiment, in the first syntax verification, the target verification program may be an optimized program.
[0115] According to an embodiment, the correctness of the syntax of a target verification program can be verified by compiling it.
[0116] According to an embodiment, the fifth agent can act as a compile validator, which can invoke tools such as a compiler to verify the syntax correctness of the target validator obtained by mutation and provide the verification results.
[0117] If the verification result indicates that the verification passed, the target verification program can be used as a mutation test program for fuzzing; if the verification result indicates that the verification failed, the sixth agent can act as a code fix agent, which can use the compilation error log to fix the syntax errors in the target verification program.
[0118] As an example, the agents according to embodiments of this disclosure can constitute a multi-agent system (MAS), and these agents can all be implemented based on LLM.
[0119] In embodiments of this disclosure, the second fuzz test can be performed at least once. In each second fuzz test, the code coverage of the current test can be used to determine whether to end the second fuzz test.
[0120] According to an embodiment, each second fuzz test may include: using a second intelligent agent to perform fuzz testing on the target interface using the mutation testing program of this second fuzz test, and obtaining the code coverage of this second fuzz test; taking the result of this second fuzz test as the second test result based on the fact that the code coverage of this second fuzz test is greater than the code coverage of the first fuzz test; and executing the next second fuzz test based on the fact that the code coverage of this second fuzz test is less than or equal to the code coverage of the first fuzz test.
[0121] According to an embodiment, code coverage may include: code coverage of the target interface and / or code coverage of the target test program.
[0122] According to the embodiment, after each second fuzz test, it can be verified whether the test brings a new increase in coverage. If there is no increase, different mutations can be introduced, and the second fuzz test can be executed again using the new mutation test procedure; if there is an increase, the second test result can be output.
[0123] Return to Figure 4 In step S430, the results of this round of testing can be obtained based on the first test results and the second test results.
[0124] like Figure 2 As shown, according to the embodiment, the first test result and the second test result can be used as input for the next round of testing operations. For example, they can be parsed by the coverage parser 200 to guide the selection of the interface and test program for the next round of testing operations.
[0125] The fuzzing method according to embodiments of this disclosure can employ a two-dimensional fuzzing scheduling strategy. The fuzzing method according to embodiments of this disclosure can apply a multi-agent test program semantic mutation algorithm to security testing of various types of software. The fuzzing method according to embodiments of this disclosure can be seamlessly integrated into any fuzzing tool that relies on a test program, such as AFL++ or LibFuzzer.
[0126] Experimental data To evaluate this fuzz testing method, embodiments of this disclosure used an NPU kernel driver as the test object to test the method. The basic information of the experimental target object is shown in Table 1 below: Table 1
[0127] The basic information about the experimental environment is shown in Table 2 below: Table 2
[0128] For fuzz testing of kernel drivers, the state-of-the-art solutions Syzkaller and AFL++ were selected as baseline methods for comparison with this method.
[0129] For example, in Experiment 1, Syzkaller was used to perform fuzzing on the NPU kernel module using the NPU module description file; in Experiment 2, a set of high-quality test programs was provided to AFL++ to perform fuzzing on the NPU module; in Experiment 3, AFL++ was selected as the fuzzing tool for this method, and this set of high-quality test programs was shared with Experiment 2.
[0130] Three different experiments were conducted under the same experimental environment, with the fuzz test duration set to 24 hours for each experiment. The experimental results are shown in Table 3 below: Table 3
[0131] As shown in Table 3 above, after 24 hours of fuzz testing, this method covered 1,749 basic blocks, achieving a 63.15% improvement over Syzkaller and a 21.97% improvement over AFL++ using the same test program.
[0132] Figure 8 The coverage growth curves for the three experiments over 24 hours are shown, as follows: Figure 8 As shown, this method can quickly reach the coverage bottleneck and efficiently overcome it.
[0133] The experimental results above show that the fuzzing method according to the embodiments of this disclosure is applicable to a wider range of tasks, including not only application layer library fuzzing, but also kernel device drivers with more complex internal states.
[0134] Furthermore, the fuzzing method according to the embodiments of this disclosure constructs a dual scheduling framework. On the one hand, it can schedule the test program according to the energy of the test program. On the other hand, it can also schedule the interface from a fine-grained level according to the interface energy, thereby guiding the rapid improvement of coverage from multiple dimensions.
[0135] Furthermore, the fuzz testing method according to the embodiments of this disclosure can achieve high-precision interface coverage feedback by statistically analyzing basic block offsets, thereby improving the accuracy of interface coverage feedback.
[0136] Furthermore, the fuzzing method according to the embodiments of this disclosure introduces a multi-agent fuzzing-driven mutation mechanism, which applies a large language model to fuzzing mutation. This breaks through the limitations of traditional syntax-based mutation methods and directly generates semantically reasonable, structurally effective, and logically coherent test programs, which can significantly improve the efficiency of fuzzing and the vulnerability discovery capability.
[0137] A second aspect of the embodiments of the present disclosure provides a fuzz testing system. Figure 9 A structural block diagram of a fuzz testing system according to an embodiment of the present disclosure is shown.
[0138] A fuzzing system can perform fuzzing tests on an object under test by executing at least one round of test operations. According to an embodiment, the object under test may include interfaces, and each test program can be used to test at least one of the interfaces.
[0139] According to an embodiment, the fuzzing system may include a memory and at least one processor. The memory may be configured to store instructions. The processor may be configured to execute the instructions to implement the fuzzing method described above.
[0140] According to embodiments of this disclosure, such as Figure 9 As shown, the processor may include at least one of a determination unit 910, an interface selection unit 920, a program selection unit 930, and a test unit 940.
[0141] The determination unit 910 can be configured to determine a first metric for each interface and a second metric for each test program based on the code coverage of the previous round of test operations. The first metric is based on the probability that the interface will be tested, and the second metric is based on the probability that the test program will be tested. In the first round of test operations, the first and second metrics are initial values.
[0142] The interface selection unit 920 can be configured to select the target interface for this round of test operations from the interfaces based on a first indicator.
[0143] The program selection unit 930 can be configured to select the target test program for the current test operation from the test programs used to test the target interface based on a second metric.
[0144] Test unit 940 can be configured to perform fuzz testing on the target interface using the target test program to obtain the results of this round of test operations.
[0145] According to an embodiment, the determining unit 910 can be configured to: determine a first code coverage of the target interface and a second code coverage of the target test program in the previous round of test operations based on the code coverage of the previous round of test operations; update a first indicator for each interface based on the first code coverage; and update a second indicator for each test program based on the second code coverage.
[0146] According to an embodiment, updating the first metric for each interface may include adjusting the first metric of the target interface in the previous round of testing in a negative correlation with the first code coverage. According to an embodiment, updating the second metric for each test program may include adjusting the second metric of the target test program in the previous round of testing in a positive correlation with the second code coverage.
[0147] According to an embodiment, the determining unit 910 can be configured to: perform a first fuzz test on the target interface using a target testing program through a first intelligent agent to obtain a first test result; perform at least one second fuzz test on the target interface using a second intelligent agent to obtain a second test result, wherein in each second fuzz test, a mutation testing program based on the mutation of the target testing program is used to perform fuzz testing on the target interface; and obtain the result of the current round of testing operation based on the first test result and the second test result.
[0148] According to an embodiment, in each second fuzz test, the determining unit 910 may be configured to determine the mutation test program by: mutating the target test program based on the currently fed-out test results and the semantics of the target test program by a third agent to obtain a candidate mutation program, wherein the currently fed-out test results may include the first test result and / or the test result of the previous second fuzz test; and obtaining the mutation test program based on the candidate mutation program.
[0149] According to an embodiment, the determining unit 910 can be configured to: determine a first interface to be called by the target test program based on the semantics of the target test program, wherein the first interface may include a target interface and a second interface; determine a target mutation strategy for mutating the first interface based on the current feedback test results; and mutate the first interface based on the target mutation strategy to obtain a candidate mutation program.
[0150] According to an embodiment, the target mutation strategy may include at least one of the following: replacing the second interface with a new interface; adding the new interface to the call relationship of the first interface; or changing the call mode of the second interface to parallel call.
[0151] According to an embodiment, the determining unit 910 can be configured to: select a second interface to be replaced based on a first index of each second interface; and select a third interface from the interfaces of the tested object other than the first interface to replace the second interface to be replaced, wherein the first index of the third interface is greater than the first index of the second interface to be replaced.
[0152] According to an embodiment, the determining unit 910 can be configured to: select a fourth interface to be added to the interface call relationship of the target test program based on a first indicator of the interfaces of the object under test other than the first interface.
[0153] According to an embodiment, the determining unit 910 can be configured to: optimize the candidate mutation program through a fourth intelligent agent to obtain an optimized program. According to an embodiment, the determining unit 910 can be configured to: perform at least one syntax verification on the optimized program to obtain a mutation test program, wherein each syntax verification may include: verifying the syntax correctness of the target verification program through a fifth intelligent agent, wherein in the first syntax verification, the target verification program is the optimized program; based on passing the verification, the target verification program is used as the mutation test program; based on failing the verification, a sixth intelligent agent performs syntax repair on the target verification program. According to an embodiment, the target verification program for the next syntax verification can be obtained based on syntax correction.
[0154] According to an embodiment, the determining unit 910 can be configured to perform each second fuzz test in the following manner: using a second agent and a mutation testing program from the current second fuzz test, fuzz the target interface to obtain the code coverage of the current second fuzz test; in response to the code coverage of the current second fuzz test being greater than the code coverage of the first fuzz test, the result of the current second fuzz test is taken as the second test result; in response to the code coverage of the current second fuzz test being less than or equal to the code coverage of the first fuzz test, the next second fuzz test is performed. According to an embodiment, the code coverage may include: the code coverage of the target interface and / or the code coverage of the target testing program.
[0155] It should be understood that the specific processing performed by the aforementioned device has been referenced. Figures 1 to 8 The above description has been detailed and will not be repeated here. It should be understood that the various units in the above-described apparatus can be implemented as hardware components and / or software components.
[0156] Figure 10 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown.
[0157] Reference Figure 10 The electronic device 1000 may include: at least one processor 1001; and a memory 1002 for storing processor-executable instructions, which, when executed by the processor 1001, enable the processor 1001 to perform the fuzzing method according to embodiments of the present disclosure.
[0158] According to embodiments, the electronic device may be at least one of a PC computer, tablet device, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. According to embodiments, the electronic device may not be a single electronic device, but may be a collection of any devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. The electronic device may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.
[0159] In an electronic device, processor 1001 may include at least one of a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. As a non-limiting example, processor 1001 may also include at least one of an analog processor, a digital processor, a microprocessor, a multi-core processor, a processor array, a network processor, etc.
[0160] The processor 1001 can execute instructions or code stored in the memory 1002, which can also store data. Instructions and data can also be sent and received via a network through a network interface device, which can employ any transmission protocol.
[0161] The memory 1002 may be integrated with the processor 1001, for example, by arranging RAM or flash memory within an integrated circuit microprocessor. According to embodiments, the memory 1002 may include a separate device, such as an external disk drive, a storage array, or any other storage device usable by a database system. The memory 1002 and the processor 1001 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., allowing the processor 1001 to read files stored in the memory.
[0162] According to embodiments, the electronic device may further include at least one of a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device may be interconnected via a bus and / or network.
[0163] According to embodiments of this disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the fuzz testing method according to embodiments of this disclosure. Examples of computer-readable storage media herein include at least one of the following: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. According to embodiments, the computer program and any associated data, data files, and data structures can be distributed across networked computer systems, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.
[0164] According to embodiments of this disclosure, a computer program product may also be provided, the computer program product including computer-executable instructions that, when executed by at least one processor, implement the fuzzing method as described in embodiments of this disclosure.
[0165] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.
[0166] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.
Claims
1. A fuzz testing method, wherein, The fuzz testing method includes: Based on executing at least one round of test operations, a test program is used to perform fuzz testing on the object under test, wherein the object under test includes one or more interfaces, and each test program is used to test the one or more interfaces. Each round of testing includes the following operations: Based on the code coverage of at least the previous round of test operations, a first metric for each interface and a second metric for each test program are determined, wherein the first metric is based on the probability that the interface is tested and the second metric is based on the probability that the test program is tested, wherein the first metric and the second metric are initial values in the first round of test operations. Based on the first metric of each interface, select the target interface for this round of testing from the one or more interfaces; Based on the second metric of each test program, the target test program for this round of testing operations is selected from the test programs used to test the target interface; Based on the target testing program, fuzz testing is performed on the target interface to obtain the results of this round of testing.
2. The fuzz testing method according to claim 1, wherein, The determination of the first metric for each interface and the second metric for each test program includes: Based on the code coverage of at least the previous round of test operations, determine the first code coverage of the target interface of at least the previous round of test operations and the second code coverage of the target test program of at least the previous round of test operations; Based on the first code coverage, update the first metric of each of the one or more interfaces; Based on the second code coverage, update the second metric for each test program.
3. The fuzz testing method according to claim 2, wherein, Updating the first metric for each of the one or more interfaces includes: adjusting the first metric of the target interface in at least the previous round of test operations in a negative correlation with the first code coverage. The updating of the second metric for each test program includes: adjusting the second metric of the target test program in at least the previous round of test operations in a positive correlation with the second code coverage.
4. The fuzz testing method according to claim 1, wherein, The fuzzing test on the target interface includes: A first test result is obtained by performing a first fuzz test on the target interface, wherein the first fuzz test is based on the target test program; A second test result is obtained by performing at least one second fuzz test on the target interface, wherein in each of the at least one second fuzz test, the target interface is fuzz tested using a mutation test program based on the mutation of the target test program. Based on the first test result and the second test result, the result of this round of test operation is obtained.
5. The fuzz testing method according to claim 4, wherein, In each of the at least one second fuzz test, the mutation test procedure is determined at least in the following ways: Based on the current feedback test results and the semantics of the target test program, the target test program is mutated, wherein the current feedback test results include at least one of the first test results and the test results of the previous second fuzz test; Based on the target test program of the mutation, candidate mutant programs are obtained; Based on the candidate mutation program, the mutation test program is obtained.
6. The fuzz testing method according to claim 5, wherein, The mutation of the target test program includes: Based on the semantics of the target test program, a first interface called by the target test program is determined, wherein the first interface includes the target interface and a second interface; Based on the current test results, determine the target mutation strategy for mutating the first interface; Based on the target mutation strategy, the first interface is mutated; Based on the first interface of mutation, candidate mutation programs are obtained.
7. The fuzz testing method according to claim 6, wherein, The target mutation strategy includes at least one of the following: Replace the second interface with the new second interface; Add the new interface to the call relationship of the first interface; Change the calling method of the second interface to parallel calling.
8. The fuzz testing method according to claim 7, wherein, The method of replacing the second interface with a new second interface includes: Based on the first indicator of each second interface, select the second interface to be replaced; From the interfaces of the object under test, excluding the first interface, select a third interface to replace the second interface to be replaced. Wherein, the first index of the third interface is greater than the first index of the second interface to be replaced.
9. The fuzz testing method according to claim 7, wherein, Adding the new interface to the call relationship of the first interface includes: Based on the first index of the interfaces of the object under test other than the first interface, a fourth interface is selected and added to the interface call relationship of the target test program.
10. The fuzz testing method according to claim 5, wherein, The process of obtaining the mutation testing program based on the candidate mutation program includes: Based on code optimization of the candidate mutation program, an optimized program is obtained; The mutation test program is obtained by performing at least one syntax verification on the optimized program, wherein each syntax verification includes: The syntax correctness of the target validator is verified, wherein, in the first syntax verification, the target validator is the optimized program; Based on the successful initial verification, the target verification program is selected as the mutation test program; Based on the failure of the initial verification, the target verification program is subjected to syntax repair. Based on the syntax repair, a second target verification procedure is obtained, wherein the second syntax verification is based on the second target verification procedure.
11. A fuzz testing system, wherein, The fuzz testing system performs fuzz testing on the object under test by executing at least one round of test operations. The object under test includes one or more interfaces, and each test program is used to test at least one of the one or more interfaces. The fuzz testing system includes: The memory is configured to store instructions; At least one processor is configured to execute the instructions to achieve: Based on the code coverage of at least the previous round of test operations, a first metric for each interface and a second metric for each test program are determined, wherein the first metric is based on the probability that the interface is tested and the second metric is based on the probability that the test program is tested, wherein the first metric and the second metric are initial values in the first round of test operations. Based on the first metric of each interface, select the target interface for this round of testing from the one or more interfaces; Based on the second metric of each test program, the target test program for this round of testing operations is selected from the test programs used to test the target interface; Based on the target testing program, fuzz testing is performed on the target interface to obtain the results of this round of testing.
12. A computer-readable storage medium, wherein, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device performs a fuzzing method, the fuzzing method comprising: Based on executing at least one round of test operations, a test program is used to perform fuzz testing on the object under test, wherein the object under test includes one or more interfaces, and each test program is used to test at least one of the one or more interfaces. Each round of testing includes the following operations: Based on the code coverage of at least the previous round of test operations, a first metric for each interface and a second metric for each test program are determined, wherein the first metric is based on the probability that the interface is tested and the second metric is based on the probability that the test program is tested, wherein the first metric and the second metric are initial values in the first round of test operations. Based on the first indicator, select the target interface for this round of testing from the one or more interfaces; Based on the second metric of each test program, the target test program for this round of testing operations is selected from the test programs used to test the target interface; Based on the target testing program, fuzz testing is performed on the target interface to obtain the results of this round of testing.