Communication module instruction fuzzy test method and system

Abstract

The invention discloses a communication module instruction fuzzy test method and system. The method comprises the steps of analyzing a historical communication module instruction, determining an instruction parameter type, and determining test record data based on historical fuzzy test data. And determining variation experience data of the instruction parameter type according to the test record data. And on the basis of the variation experience data, constructing a variator scheduling model corresponding to each instruction parameter type. And based on the previously constructed variator scheduling model, predicting a target variator of each instruction parameter type in the to-be-tested instruction, and executing a fuzzy test through the target variator. According to the technical scheme provided by the invention, the hit rate and convergence rate of fuzzy testing are remarkably improved by reusing historical experience, intelligent scheduling of variation strategies is realized, the testing resources are enabled to act on variation combinations which are easier to trigger abnormal states in a centralized manner, the exploration capability of deep states and potential problems of the communication module is enhanced, and the development efficiency of the communication module is improved. And the test efficiency and precision of the fuzzy test process are obviously improved.

Description

Technical Field

[0001] This application belongs to the field of software testing technology, and in particular relates to a fuzzy testing method and system for communication module instructions. Background Technology

[0002] In the field of existing software testing technology, fuzzing is a highly efficient automated testing technique that discovers potential problems and defects by injecting unexpected inputs into the test target. For example, for communication modules that handle complex instructions and proprietary protocols, this technique can effectively detect module crashes or abnormal states that may be caused by abnormal instruction interactions, significantly improving test coverage and efficiency.

[0003] Currently, seed selection and mutation strategies are key factors affecting testing efficiency in existing fuzzing schemes. Existing testing methods typically rely on coverage feedback from the current test to evaluate seed value and then sort and schedule them accordingly. However, during software version iterations or when software modules are reused between similar products, the initial testing phase struggles to quickly guide the test to parameter combinations or instruction sequences prone to triggering problems, resulting in severely low testing efficiency. Numerous ineffective attempts are required to reach high-value state spaces. Furthermore, when mutating instruction parameters, traditional methods generally perturb the seed by traversing all mutants, failing to perform targeted mutant selection. A significant amount of testing resources is consumed on mutant combinations with low probability of triggering anomalies, leading to high redundancy in the overall fuzzing process. This hinders effective exploration of the deep states and potential problems of test targets, such as communication modules, severely reducing the efficiency and effectiveness of fuzzing.

[0004] Therefore, how to perform more effective mutant scheduling during fuzz testing is an important problem that urgently needs to be solved. Summary of the Invention

[0005] This application provides a method and system for fuzz testing of communication module instructions. It can perform effective and practical mutant prediction when fuzz testing communication module instructions, so that fuzz testing can discover potential problems and defects in communication modules more quickly, and significantly improve the testing efficiency and accuracy of fuzz testing.

[0006] In a first aspect, embodiments of this application provide a method for fuzzy testing of communication module instructions, including: Obtain historical communication module commands and historical fuzzy test data of historical communication module commands; Analyze historical communication module instructions to determine at least one instruction parameter type contained in the historical communication module instructions, and based on historical fuzzy test data, determine the test record data for each instruction parameter type. The test record data represents the changes in the fuzzy test state of the communication module after the instruction parameter type has been mutated by multiple mutants. For each instruction parameter type, based on the test record data for that instruction parameter type, determine the variation experience data for that instruction parameter type; Based on mutation experience data, a mutant scheduling model for this instruction parameter type is constructed; Obtain the instruction to be tested, and based on the mutant scheduling model, predict the target mutant of at least one instruction parameter type in the instruction to be tested, and perform fuzz testing on the instruction to be tested through the target mutant.

[0007] Secondly, embodiments of this application provide a communication module instruction fuzzy testing system, comprising: The data collection module is used to acquire historical communication module instructions and historical fuzzy test data of historical communication module instructions; The instruction parsing module is used to parse historical communication module instructions, determine at least one instruction parameter type contained in the historical communication module instructions, and determine the test record data for each instruction parameter type based on historical fuzzy test data. The test record data represents the changes in the fuzzy test state of the communication module after the instruction parameter type has been mutated by multiple mutants. The experience determination module is used to determine the variation experience data of each instruction parameter type based on the test record data of that instruction parameter type. The model building module is used to build a mutant scheduling model for this instruction parameter type based on mutation experience data; The fuzzing module is used to obtain the instruction to be tested and, based on the mutant scheduling model, predict the target mutant of at least one instruction parameter type in the instruction to be tested, and perform fuzzing on the instruction to be tested through the target mutant.

[0008] Thirdly, embodiments of this application provide a terminal device, the device including: a processor and a memory storing computer program instructions; When the processor executes computer program instructions, it implements a fuzzy testing method for communication module instructions, as described in the first aspect.

[0009] Fourthly, embodiments of this application provide a computer storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, they implement the communication module instruction fuzzing method as described in the first aspect.

[0010] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by the processor of an electronic device, cause the electronic device to perform a communication module instruction fuzzy testing method as described in the first aspect.

[0011] The technical solutions provided by the embodiments of this application bring at least the following beneficial effects: This application provides a fuzz testing method for communication module instructions, comprising: First, parsing acquired historical communication module instructions to determine the types of each instruction parameter contained therein, and determining test record data for each instruction parameter type based on the corresponding historical fuzz test data. Then, based on the test record data for each instruction parameter type, determining the mutation experience data for each instruction parameter type. Further, based on the mutation experience data, constructing a corresponding mutant scheduling model for each instruction parameter type. Finally, for the acquired instruction to be tested, predicting the target mutants for each instruction parameter type in the instruction to be tested based on the previously constructed mutant scheduling model, and then performing fuzz testing on the instruction to be tested using the target mutants.

[0012] The technical solution provided in this application can automatically learn the correlation between different instruction parameter types and effective mutants based on historical test data, thereby accurately calling high-value mutants in the actual testing phase. This significantly improves testing efficiency and depth, effectively avoiding the resource waste of traditional traversal mutation methods. The technical solution provided in this application significantly improves the hit rate and convergence speed of fuzz testing by reusing historical experience. The model-driven mutant prediction mechanism realizes intelligent scheduling of mutation strategies, allowing test resources to be concentrated on mutation combinations that are more likely to trigger abnormal states. This enhances the ability to explore the deep state and potential problems of the communication module, greatly improving the vulnerability discovery efficiency and testing quality of the fuzz testing process.

[0013] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 A flowchart illustrating a communication module instruction fuzzy testing method provided in one embodiment of this application; Figure 2(a) is one of the example schematic diagrams of a variation processing of communication module instructions provided in an embodiment of this application; Figure 2(b) is a second example of a variation processing of communication module instructions provided in an embodiment of this application; Figure 2(c) is a third example of a variation processing of communication module instructions provided in an embodiment of this application; Figure 3(a) is one of the flowcharts of a fuzz testing process provided in an embodiment of this application; Figure 3(b) is a second schematic flowchart of a fuzz testing process provided in one embodiment of this application; Figure 4 A schematic diagram illustrating the construction process of a novel instruction parameter mutant scheduling model provided in one embodiment of this application; Figure 5 A schematic diagram of a communication module instruction fuzzy testing system provided in another embodiment of this application; Figure 6 This is a schematic diagram of the structure of a terminal device provided in another embodiment of this application. Detailed Implementation

[0016] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0017] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0018] In the field of software testing technology, fuzz testing, as a highly efficient automated testing method, has significant application value by inputting unexpected data into the target under test to detect potential defects. Especially when testing communication modules, this technology can effectively simulate abnormal command interaction scenarios, detect problems such as module crashes and abnormal states caused by command parsing errors or improper protocol processing, and significantly improve the test coverage and system robustness of communication modules.

[0019] In current fuzzing techniques, seed selection and mutation strategy settings are the core aspects affecting fuzzing performance. Existing methods mainly rely on real-time feedback from a single test run to evaluate seed value and guide scheduling, lacking effective utilization of historical testing experience. When facing software version iterations or cross-product module reuse, this strategy struggles to quickly locate defect-prone instruction parameter combinations in the early stages of testing, resulting in severely reduced testing efficiency. In reality, it requires numerous ineffective attempts to barely penetrate the high-value state space.

[0020] Furthermore, in the process of parameter mutation of seed data, traditional methods typically employ a traversal mutation strategy, lacking a targeted arrangement for mutant selection. This indiscriminate and cumbersome mutation method results in a large consumption of testing resources on mutant combinations with weak testing effects, not only causing redundancy in the testing process but also making it difficult to systematically explore the deep state and potential defects of the communication module, severely restricting the overall efficiency and effectiveness of fuzz testing.

[0021] To address the aforementioned technical issues, this application provides a method and system for fuzz testing communication module instructions. The method includes: parsing acquired historical communication module instructions, determining the types of each instruction parameter contained therein, and determining test record data for each instruction parameter type based on the corresponding historical fuzz test data. Based on the test record data for each instruction parameter type, mutation experience data for each instruction parameter type can be determined. Based on the mutation experience data, a corresponding mutant scheduling model can be constructed for each instruction parameter type. For the acquired instruction to be tested, based on the previously constructed mutant scheduling model, the target mutant for each instruction parameter type in the instruction to be tested can be predicted, and then fuzz testing can be performed on the instruction to be tested using the target mutant.

[0022] The technical solution provided in this application can automatically learn the correlation between different instruction parameter types and effective mutants based on historical test data, thereby accurately calling high-value mutants in the actual testing phase. This significantly improves testing efficiency and depth, and effectively avoids the resource waste of traditional traversal mutation methods. The technical solution provided in this application significantly improves the fuzzing hit rate and convergence speed by reusing historical experience. The model-driven mutant prediction mechanism realizes intelligent scheduling of mutation strategies, allowing test resources to be concentrated on mutation combinations that are more likely to trigger abnormal states. This enhances the ability to explore the deep state and potential problems of the communication module, significantly improving the testing efficiency and accuracy of the fuzzing process.

[0023] Regarding the execution subject used in the technical solutions provided in the embodiments of this application, it can specifically be a terminal device capable of acquiring historical fuzzy testing data, such as a desktop computer or laptop computer, or it can be a remote device, such as a server. In addition, the execution subject used in the embodiments of this application can also be a software execution subject, such as a client or software program installed on a terminal device. The specific type of execution subject corresponding to the communication module instruction fuzzy testing method and system provided in the embodiments of this application is not strictly limited here; it can be flexibly selected and set according to the application scenario and actual needs.

[0024] It should be noted that the specific application scenarios of the communication module instruction fuzzing test method and system provided in the embodiments of this application are not limited. The technical solutions provided in the embodiments of this application can be flexibly applied to various actual scenarios that require fuzzing test of communication modules according to actual needs.

[0025] For example, in scenarios where the communication module in a device undergoes remote firmware upgrades, the technical solution provided in this application can analyze and learn from historical upgrade commands and their test data before the upgrade, establishing a mutant scheduling model for each known command parameter type. After the communication module is updated, when performing fuzz testing on the new commands, the technical solution provided in this application can automatically parse the parameter types in the update commands and accurately call the corresponding mutant scheduling model to intelligently select the most effective mutant for testing. During the testing process, the model will also dynamically adjust the mutant switching strategy according to the parameter type, making test resources more concentrated on mutation combinations that may trigger abnormal states of the updated communication module, improving fuzz testing efficiency and the accuracy of vulnerability detection for the updated communication module.

[0026] The technical solutions provided by the embodiments of this application can achieve accurate and efficient fuzz testing for communication modules. For example, in key scenarios such as communication module upgrade testing in the above-mentioned devices, it can significantly improve the efficiency of anomaly detection and testing depth of the updated communication module, thereby providing strong protection for the stability and reliability of the communication system in the device, ensuring the functional safety of the device in complex communication environments, and further improving the user experience.

[0027] It should be noted that the application scenarios described in the above embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems. The communication module instruction fuzzing testing method and system provided in the embodiments of this application can be applied to various practical scenarios that require fuzzing testing of communication modules.

[0028] Figure 1 This is a flowchart illustrating a communication module instruction fuzzy testing method provided in one embodiment of this application.

[0029] S101: Obtain historical communication module instructions and historical fuzzy test data of historical communication module instructions.

[0030] In step S101, the technical solution provided in this application embodiment can record multiple communication module instructions that have been fuzz tested in history, as well as the corresponding fuzz test data, which are respectively used as historical communication module instructions and historical fuzz test data.

[0031] In this embodiment, the specific instruction type and format of the historical communication module commands are not strictly limited and can be flexibly selected based on actual test history and application scenarios. In some embodiments, the historical communication module commands may be AT+. <cmd> = <p1> [, <p2> [, <p3>[...], where p1, p2 and p3 are instruction parameters, corresponding to the same or different instruction parameter types respectively.

[0032] Historical fuzz test data accurately records the test performance of corresponding communication module instructions after undergoing multiple mutants and rounds of mutation during fuzz testing. For example, after an instruction is processed by a certain mutant, new code execution paths, new runtime error codes, abnormal resource usage, and other new states or problems may appear during the operation of the communication module. Historical fuzz test data can be used to determine the corresponding mutation experience data for different instruction parameter types, thereby providing sufficient data support for the construction of the mutant scheduling model.

[0033] S102: Parse historical communication module instructions, determine at least one instruction parameter type contained in the historical communication module instructions, and determine test record data for each instruction parameter type based on historical fuzzy test data.

[0034] In step S102, the technical solution provided in this application embodiment can perform parameter parsing on the collected historical communication module instructions, determine the multiple instruction parameters contained in the instruction, and determine the instruction parameter type corresponding to each instruction parameter.

[0035] Simultaneously, based on historical fuzzing data, the mutation processing and test records for each instruction parameter during the historical fuzzing process can be determined, thereby obtaining statistical test record data for each instruction parameter type. The test record data can represent the state changes of the communication module during fuzzing after multiple rounds of mutation processing by various mutants during the historical fuzzing process for the corresponding instruction parameter type.

[0036] Specifically, in the embodiments provided in this application, for each instruction parameter in the historical communication module instructions, the fuzz test data corresponding to the instruction parameter can be determined from the historical fuzz test data. Specifically, it can include which mutation processes the instruction parameter has undergone in the historical fuzz test and the new state of the communication module that has occurred.

[0037] Furthermore, based on the fuzzy test data corresponding to the instruction parameter, the fuzzy test state after each round of mutation processing by the various mutants can be extracted. Specifically, the fuzzy test state represents the test state of the communication module after the instruction parameter mutation, and can be one of three test states: normal test pass, test fail, or the occurrence of a new state or problem as shown in the example above.

[0038] For example, the fuzzy test data corresponding to a certain instruction parameter can represent the test state of the communication module after the instruction parameter has been processed by one or more mutants in the first round of mutation, and the test state of the communication module after the second round of mutation based on the first round of mutation, that is, after being processed by one or more mutants again, and so on until the maximum number of mutation rounds.

[0039] To facilitate understanding, based on the examples of historical communication module instructions mentioned above, fuzzy test data corresponding to each instruction parameter in the historical communication module instructions are illustrated in Table 1.

[0040]

[0041] Table 1. Fuzzy test data corresponding to instruction parameters As shown in Table 1, the historical communication module command AT+ <cmd> = <p1> [, <p2> [, <p3>[...], the fuzzy test data for each parameter instruction is determined separately. Instruction parameter p1 corresponds to an Array, which undergoes mutation processing by mutants 1-N in three rounds of mutation. The corresponding state changes of the communication module are shown in Table 1. P indicates passing the test; if no new state or problem appears, it is recorded as no problem; if a new state appears, it is recorded as a new state. F indicates failing the test, and the specific reason for the failure is recorded. Instruction parameter p2 has the same instruction parameter type as instruction parameter p1, both being Arrays. Instruction parameters p3 and p4 correspond to different instruction parameter types, and their corresponding fuzzy test data can also be recorded in Table 1.

[0042] It should be noted that the instruction parameter types in the above examples are for illustrative purposes only. The embodiments of this application do not strictly limit the specific types and number of instruction parameter types, and can be flexibly selected and set according to the actual communication module instructions and application scenarios.

[0043] Based on each historical communication module instruction, the fuzzy test data shown in Table 1 is determined. Further, the fuzzy test data for the same type of instruction parameters in different instructions can be statistically organized to determine the fuzzy test data for the corresponding instruction parameter type, which serves as the number of test records for determining subsequent mutation experience data. Taking the instruction parameter type Array in Table 1 as an example, in some embodiments, the fuzzy test data corresponding to a single instruction parameter type can be referenced in Table 2.

[0044]

[0045] Table 2. Fuzzy test data corresponding to instruction parameter types As shown in Table 2, fuzzy test data corresponding to each instruction parameter of type Array can be statistically analyzed from multiple historical communication module instructions. P1, P3, and P5 are in different instructions, but their instruction parameter types are the same, so they can be included in the fuzzy test data shown in Table 2. The conversion from Table 1 to Table 2 transforms fuzzy test data based on communication module instructions into fuzzy test data based on instruction parameter types, providing data support for subsequent construction of mutation experience data and mutant scheduling models for each instruction parameter type.

[0046] The above embodiments, by structurally recording the specific test states of the communication module resulting from different mutants processing each instruction parameter type in historical tests, construct a high-quality labeled dataset for subsequent model training. Through the refined data accumulation in these embodiments, the actual test effects of different mutants on each parameter type can be accurately quantified. This provides a highly discriminative and learnable data foundation for the mutant scheduling model, effectively supporting the accuracy and relevance of subsequent model predictions, thereby improving the accuracy and efficiency of fuzzy testing.

[0047] It should be noted that the types of mutants used for fuzz testing are not strictly limited in the embodiments of this application, and can be flexibly selected according to actual needs and application scenarios. In some embodiments, multiple mutants may include mutation operations at the instruction field level, such as copying, adding, deleting, or modifying instruction fields, or they may also include mutation operations at the instruction set level, such as repeating or reordering some instruction sequences. Examples of specific mutation processing can be found in Figures 2(a), 2(b), and 2(c).

[0048] Figures 2(a), 2(b), and 2(c) are schematic diagrams illustrating an example of variation processing of communication module instructions provided in an embodiment of this application.

[0049] Figure 2(a) is a schematic diagram of the mutation process for modifying instruction fields in the communication module instruction. As shown in Figure 2(a), fields S3 and S4 in the original instruction sequence are modified and mutated into F3 and F4, resulting in the mutated instruction sequence.

[0050] Figure 2(b) is a schematic diagram of the mutation processing of partial instruction sequence repetition for communication module instructions. As shown in Figure 2(b), the field S2 in the original instruction sequence is repeated, so that the sequence contains a partially repeated sequence consisting of three consecutive fields S2, and the mutated instruction sequence is obtained.

[0051] Figure 2(c) is a schematic diagram of the mutation processing of partial instruction sequence scrambling for communication module instructions. As shown in Figure 2(c), field S4 in the original sequence is moved before field S2, and the original field order is shuffled to obtain the mutated instruction sequence. The above example is only for illustration and understanding. Other embodiments may also use other mutation processing methods. The specific choice and use can be flexible according to actual needs and application scenarios.

[0052] S103: For each instruction parameter type, determine the variation experience data of that instruction parameter type based on the test record data of that instruction parameter type.

[0053] In step S103, the technical solution provided in this application embodiment can perform mutation experience and reward analysis based on the test record data corresponding to each instruction parameter type to determine the mutation experience data corresponding to each instruction parameter type.

[0054] Among them, the mutation experience data can represent the mutation direction that is most likely to cause the communication module to have a new state or problem during the historical fuzzing process for the corresponding instruction parameter type. The specific data form can be represented in the form of a matrix, where the rows and columns of the matrix represent the mutants before and after the switch, and each element represents the reward value of the change in the state of the communication module after the mutant switch.

[0055] Specifically, in the embodiments provided in this application, for each instruction parameter corresponding to the instruction parameter type, a mutation reward matrix corresponding to the instruction parameter can be constructed based on the test record data corresponding to the instruction parameter.

[0056] Similar to the mutation experience data mentioned above, each element in the mutation reward matrix represents the reward value for the change in the fuzzy test state of the communication module after the instruction parameter has been processed by the same or different mutants. The rows and columns can be the mutants before and after the switch, respectively.

[0057] Then, the mutation reward matrices of multiple instruction parameters corresponding to a single instruction parameter type can be summed to obtain the mutation reward matrix corresponding to that instruction parameter type, which can be used as the mutation experience data for that instruction parameter type.

[0058] Based on the instruction parameter P1 in Table 2 above, an example of the mutation reward matrix is ​​provided. For details, please refer to formula (1): (1) Where R1 represents the mutation reward matrix for instruction parameter P1 in Table 2, the rows of the matrix on the right side of the equation are B1-Bn, representing the unswitched mutants in the current mutation round, and the columns are also B1-Bn, representing the switched mutants in the current mutation round. For example, (B1, B2) means that in the fuzz test, instruction parameter P1 is processed by mutant B1 and then switched to mutant B2 for mutation processing. A matrix element of 0 indicates that after mutation processing of instruction parameter P1, the communication module passes the test without new states or new problems; 100 indicates that after mutation processing of instruction parameter P1, the communication module passes the test but a new state appears, or the communication module fails the test and a new problem occurs; -1 indicates that instruction parameter P1 has not undergone the corresponding mutant combination processing.

[0059] Based on the test record data shown in Table 2, the mutation reward matrix for each instruction parameter can be accurately constructed as shown in Formula (1). Furthermore, the mutation reward matrices for each instruction parameter of the same type can be summed, i.e., element-wise added together, to obtain the mutation reward matrix for the corresponding instruction parameter type, i.e., the mutation experience data. Examples of the specific summation process can be found in Formulas (2) and (3) below: (2) (3) in, Indicates that the instruction parameter type is The corresponding mutation reward matrix, and Each parameter is of type 1. The mutation reward matrix corresponding to the instruction parameters. Similarly, Indicates that the instruction parameter type is The corresponding mutation reward matrix, and Each parameter is of type 1. The mutation reward matrix corresponding to the instruction parameters.

[0060] Based on the summation process of similar formulas (2) or (3), the variation experience data corresponding to each instruction parameter type in the historical communication module instructions can be accurately calculated, providing sufficient and practical data support for the construction of subsequent mutant scheduling models, and providing accurate and effective guidance for mutant combination selection and scheduling in actual fuzzy testing.

[0061] In the above embodiments, a mutation reward matrix is ​​constructed for each instruction parameter, and the results are aggregated into mutation experience data at the parameter type level, transforming scattered historical test results into quantifiable decision-making basis. This embodiment effectively integrates the test results of multiple specific instruction parameters, eliminating random fluctuations in individual test cases and forming stable empirical knowledge that reflects the overall effectiveness of the mutant for that parameter type. Based on the matrix aggregation quantification method in this embodiment, a more comprehensive and robust learning objective is provided for subsequent model construction and parameter training, significantly improving the accuracy and reliability of subsequent mutant scheduling and prediction, thereby enhancing the processing efficiency and testing accuracy of the actual fuzzy testing process.

[0062] S104: Based on mutation experience data, construct a mutant scheduling model for this instruction parameter type.

[0063] In step S104, the technical solution provided by this application can perform multiple rounds of iteration and optimization of the mutant scheduling model parameters based on the mutation experience data of each instruction parameter type, and construct a mutant scheduling model corresponding to each known instruction parameter type.

[0064] Among them, the mutant scheduling model can be used in the actual fuzzing process to predict the mutant most likely to cause new states or new problems in the communication module in the next round of mutation processing for the corresponding instruction parameter type, without having to traverse all mutants, which significantly improves the testing efficiency of fuzzing and the accuracy of discovering new states or new problems in the communication module.

[0065] Specifically, in the embodiments provided in this application, for each instruction parameter type, multiple rounds of parameter iteration can be performed on the model parameter matrix corresponding to the instruction parameter type based on the variation experience data of that instruction parameter type to obtain the iterated model parameter matrix.

[0066] The matrix form of the model parameter matrix is ​​similar to that of the mutation reward matrix in the above embodiment. The rows of the matrix can represent the unswitched mutants before each round of mutation processing, and the columns can represent the switched mutants after each round of mutation processing. Each matrix element represents the reward value for switching the instruction parameter type from the unswitched mutant to the switched mutant. The elements in the initial model parameter matrix can all be zero. For a specific example, please refer to formula (4): (4) Where Q(Array) represents the initial model parameter matrix corresponding to the instruction parameter type Array, and the row and column representations of the matrix on the right side of the equation have the same meaning as in the above formula (2). Based on the mutation reward matrix shown in, for example, formula (2), multiple rounds of parameter iteration can be performed on the model parameter matrix described in, for example, formula (4), until the parameters converge, and further, a mutant scheduling model of the instruction parameter type can be constructed.

[0067] Based on the iterative model parameter matrix, a corresponding mutant scheduling model can be constructed. The constructed mutant scheduling model can predict the mutant for each round of instruction mutation for the corresponding instruction parameter type during subsequent fuzz testing, and provide optimal guidance for the mutation direction, so as to discover new states or potential problems of the communication module more efficiently and accurately.

[0068] Regarding the specific iterative process of the aforementioned model parameter matrix, in the embodiments provided in this application, for each round of parameter iteration, the mutation switching direction corresponding to each unswitched mutant (row of the matrix) in that round of parameter iteration can be determined based on the model parameter matrix after the previous round of iteration. Specifically, the mutation switching direction points from the unswitched mutant to the mutant with the highest reward value after switching.

[0069] Furthermore, based on the element values ​​of the mutant switching direction in the model parameter matrix after the previous iteration, and combined with the mutation experience data corresponding to the instruction parameter type, the parameter adjustment matrix for this round of parameter iteration can be calculated. Then, based on preset iteration parameters, a weighted sum of the parameter adjustment matrix and the model parameter matrix after the previous iteration can be performed to obtain the model parameter matrix after this round of iteration.

[0070] In some embodiments, the model parameter matrix can specifically be the Q matrix in Q-learning, and the corresponding matrix parameter iteration process can be referred to as shown in the following formula (5): (5) For each round of parameter iteration, the left side of the equation is... This represents the model parameter matrix after parameter iteration in this round, and the right side of the equation... This represents the model parameter matrix after the previous round of parameter iterations. The mutation reward matrix is ​​similar to that in formula (2). This represents the unswitched mutant in this round of parameter iteration, i.e., the row number in the matrix. Indicates that the mutant was never switched. Switch to the switched mutant Maximum reward value, after switching mutants That is, the unswitched mutant. The mutant corresponding to the column containing the largest element in the current row. This means the mutant has never been switched. Switch to the switched mutant The switching action, i.e., the switching direction of the aforementioned mutant. and For preset iteration parameters, For learning rate, This is the discount factor.

[0071] Through formula (5) The model parameter matrix can be accurately determined. Each unswitched mutant (Line) switching action Mutant pointing to the maximum reward value after switching Further combined with the mutation reward matrix It was determined that the mutant had not been switched. Parameter adjustment matrix .

[0072] Then, it can be based on The learning rate is the model parameter matrix after the previous round of parameter iterations. With parameter adjustment matrix The model parameter matrix after the parameter iteration in this round is obtained by performing a weighted summation. After multiple rounds of parameter iteration, such as that shown in formula (5), the model parameter matrix can be gradually converged. Based on the converged model parameter matrix, a mutant scheduling model with the corresponding instruction parameter type can be constructed.

[0073] Taking the instruction parameter type Array in the above example as an example, the specific iteration process of the model parameter matrix can be referred to Table 3 below.

[0074]

[0075] Table 3 Iteration process of model parameter matrix As shown in Table 3, through each round of parameter iteration in the above embodiments, each element in the model parameter matrix of the instruction parameter type Array can be numerically iterated successively, gradually reflecting the impact of switching between different mutants on the emergence of new states or problems in the communication module. Based on the model parameter matrix after iterative convergence, a mutant scheduling model corresponding to the instruction parameter type can be constructed, thereby predicting the optimal mutation path that leads to new states or problems in the communication module during each round of mutation processing in actual fuzzy testing.

[0076] The above embodiments, by introducing a directional switching strategy and an incremental parameter update mechanism, enable the iterative process of model parameters to achieve both high efficiency and stability. This embodiment ensures that model parameters converge rapidly to high-reward regions during training, and avoids drastic parameter fluctuations through weighted summation, significantly improving the effectiveness and reliability of the model training process. The dynamic optimization process in this embodiment guarantees that the actual prediction scheduling strategy can respond promptly to effective mutations from historical experience while maintaining good generalization ability, laying a better decision-making foundation for mutant scheduling.

[0077] The above embodiments enable the construction of a mutant scheduling model corresponding to each instruction parameter type. These embodiments optimize the model parameter matrix through multiple rounds of iteration, allowing the model to accurately learn the long-term rewards resulting from switching between different mutants. The final constructed scheduling model possesses forward-looking mutant decision-making capabilities, predicting the mutant most likely to trigger high-value state changes based on the mutants at the current stage. This achieves dynamic optimization and adaptive adjustment of the mutation strategy, effectively improving the accuracy and effectiveness of fuzz testing.

[0078] S105: Obtain the instruction to be tested, and based on the mutant scheduling model, predict the target mutant of at least one instruction parameter type in the instruction to be tested, and perform fuzz testing on the instruction to be tested through the target mutant.

[0079] In step S105, the technical solution provided in this application embodiment can, during the actual fuzz testing of the instruction to be tested, analyze the types of each instruction parameter contained in the instruction to be tested, select the corresponding mutant scheduling model, and predict the mutant selection for each round. The target mutant is predicted, and the instruction to be tested is mutated using the target mutant. The mutated instruction is then used to perform fuzz testing on the communication module.

[0080] Specifically, in the embodiments provided in this application, the obtained instruction to be tested can be parsed to determine the types of target parameters contained in the instruction to be tested. Then, parameter type matching can be performed to match each target parameter type from the aforementioned known instruction parameter types.

[0081] For each target parameter type, if the target parameter type is one of the known instruction parameter types, the target parameter of the target parameter type can be predicted by the corresponding mutant scheduling model. The mutant most likely to cause new states and new problems in the communication module in each round of mutation processing is predicted as the target mutant.

[0082] Furthermore, after performing multiple rounds of mutation on the instruction to be tested through the above embodiments, and conducting fuzz testing on the communication module based on the mutated instructions, the instruction to be tested can be used as the historical communication module instruction in the above embodiments, and the corresponding test data is the historical fuzz test data. Further, based on the newly collected historical communication module instructions and historical fuzz test data, the above steps are executed again to continuously optimize the parameters of the mutator scheduling model for each instruction parameter type.

[0083] To facilitate understanding of the above fuzzing process for the instruction to be tested, the following comparison and explanation uses the flowchart of the traditional fuzzing process and the flowchart of the fuzzing method for communication module instructions provided in this application. For details, please refer to Figures 3(a) and 3(b).

[0084] Figures 3(a) and 3(b) are schematic flowcharts of a fuzz testing process provided in one embodiment of this application.

[0085] Figure 3(a) is a flowchart illustrating a traditional fuzzing process provided in an embodiment of this application. As shown in Figure 3(a), after the test begins, communication module instructions can be captured from the test log 311 as initial seeds, and a seed pool 312 can be constructed. During actual fuzzing, instructions can be extracted from the seed pool 312 as test seeds 313.

[0086] Then, the test seed 313 can be traversed using a mutant or a randomly selected mutant can be used to mutate the instructions, resulting in a mutant seed 314. Mutant seed 314 can be used to perform fuzz testing on the communication module, yielding a test result 315. Based on the test result, it can be determined whether the current mutation process has caused a new state or problem in the communication module. If so, the seed pool 312 can be updated and optimized; otherwise, another mutation path can be selected to re-execute the mutation process.

[0087] As can be seen from Figure 3(a), the traditional fuzzing process does not fully incorporate historical test data, and the mutation processing of instruction parameters is completely random or involves a complete traversal, which seriously affects the testing efficiency of fuzzing and the accuracy of discovering new states or new problems of the communication module.

[0088] Figure 3(b) is a flowchart of a test process based on a communication module instruction fuzzy testing method provided in an embodiment of this application. As shown in Figure 3(b), after the test starts, a mutant scheduling model 321 corresponding to each known instruction parameter type can be constructed based on historical communication module instructions and historical fuzzy test data.

[0089] During actual model testing, an initial seed can be extracted from the test log 322 to construct a seed pool 323. The instruction to be tested 324 can be extracted from the seed pool 323 and matched with known instruction parameter types. For successfully matched target parameters, the corresponding mutant scheduling model 321 can predict the target mutant 325 in each round. The target mutant 325 in each round can mutate the instruction to obtain the mutated instruction 326, and then perform fuzz testing on the communication module to obtain the test result 327.

[0090] Based on the test result 327, it can be determined whether the current mutation process has caused a new state or problem in the communication module. If so, the seed pool 323 can be fed back and updated for optimization. If not and the test is not yet complete, the target mutant 325 for the next round can be predicted using the mutant scheduling model 321. After the fuzz test is completed, each instruction to be tested and the test data can be used as historical communication module instructions and historical fuzz test data to iterate and update the parameters of the mutant scheduling model 321.

[0091] As can be seen from Figure 3(b), the technical solution provided by the embodiments of this application can provide accurate directional guidance for the selection of mutants in fuzz testing, unlike the blind traversal or random selection of mutants in Figure 3(a), which greatly improves the testing efficiency of the communication module and the accuracy of discovering new states or new problems.

[0092] In the above embodiments, precise matching and dynamic decision-making for mutant invocation are achieved through instruction parsing and parameter type identification. This embodiment enables the real-time invocation of corresponding dedicated scheduling models for different parameter types in the instruction under test, thus adaptively selecting the most effective target mutant in each round of mutation. The fine-grained scheduling mechanism in this embodiment significantly improves the targeting and response speed of fuzz testing, ensuring that historical testing experience can be accurately applied to new testing scenarios, driving a higher degree of automation and intelligence in the fuzz testing process.

[0093] In addition to the above, in some other embodiments provided in this application, when a novel instruction parameter exists in the instruction to be tested, it indicates that the target parameter type is not one of the known instruction parameter types. In this case, fuzz testing of the target parameter type can be performed based on multiple mutants, and fuzz test data can be collected simultaneously. Furthermore, based on the instruction to be tested and the fuzz test data, the above steps are performed to construct a mutant scheduling model corresponding to the target parameter type.

[0094] Specifically, the presence of novel instruction parameters in the test instruction falls into two categories: one is the appearance of novel instruction parameters within known communication module instructions, and the other is the appearance of novel instruction parameters within novel module instructions. For these two special cases, various mutants can be used to mutate the novel instruction parameters, and fuzz testing can be performed on the communication module to collect fuzz test data.

[0095] Then, through the above steps and corresponding embodiments, a mutant scheduling model corresponding to the parameter type of the new instruction parameters can be constructed based on the new instruction parameters and the corresponding fuzzy test data. For specific processing details, please refer to... Figure 4 Example shown.

[0096] Figure 4 This is a schematic diagram illustrating the construction process of a novel instruction parameter mutant scheduling model provided in one embodiment of this application.

[0097] like Figure 4 As shown, firstly, instruction type matching and instruction parameter type matching can be performed on the instruction to be tested 401. For known instructions and known instruction parameters 402, the corresponding mutant scheduling model 403 is used for mutant prediction and mutation processing. The mutated instructions are used to perform fuzz testing on the communication module.

[0098] For a known instruction but with a new instruction parameter 404, we can first determine whether the new instruction parameter 404 is a completely new parameter, a modification of a known parameter, or a deletion. For new instruction parameters of type 405 (new or modified), we can first perform instruction mutation and fuzzing tests using multiple mutants, collect test data, and construct a mutant scheduling model 403 for the corresponding instruction parameter type. When performing mutation processing on instruction parameters of this type later, we can directly process them using the corresponding mutant scheduling model 403. The mutated instruction is then used for fuzzing tests on the communication module. Instructions involving type deletion can be directly mutated using the mutant scheduling model 403 for other instruction types, and then fuzzed on the communication module.

[0099] For the new instruction 406, the types of parameters contained therein can be parsed first. For the known instruction parameter 402, instruction mutation can be performed through the corresponding mutant scheduling model 403. For the new instruction parameter 404, instruction mutation and fuzzing can be performed through multiple mutants, test data can be collected, and a mutant scheduling model 403 corresponding to the instruction parameter type can be constructed. In the subsequent fuzzing process, instruction mutation can be performed based on the constructed mutant scheduling model 403. The mutated instruction can be used to perform fuzzing tests on the communication module.

[0100] The above describes a specific implementation of a fuzzy testing method for communication module instructions provided in this application. The technical solution provided in this application can automatically learn the correlation between different instruction parameter types and effective mutants based on historical test data, thereby accurately calling high-value mutants during the actual testing phase. This significantly improves testing efficiency and depth, and effectively avoids the resource waste of traditional traversal mutation methods. The technical solution provided in this application significantly improves the fuzzy testing hit rate and convergence speed by reusing historical experience. The model-driven mutant prediction mechanism realizes intelligent scheduling of mutation strategies, allowing test resources to be concentrated on mutation combinations that are more likely to trigger abnormal states. This enhances the ability to explore the deep state and potential problems of the communication module, significantly improving the testing efficiency and accuracy of the fuzzy testing process.

[0101] Based on the communication module instruction fuzzing method provided in the above embodiments, this application also provides an embodiment of a communication module instruction fuzzing testing system.

[0102] Figure 5 This is a schematic diagram of the structure of a communication module instruction fuzzy testing system provided in another embodiment of this application.

[0103] As shown in Figure 3, this application embodiment also provides a communication module instruction fuzzy testing system 500, the system including: The data collection module 501 is used to acquire historical communication module instructions and historical fuzzy test data of historical communication module instructions; The instruction parsing module 502 is used to parse historical communication module instructions, determine at least one instruction parameter type contained in the historical communication module instructions, and determine test record data for each instruction parameter type based on historical fuzzy test data. The experience determination module 503 is used to determine the variation experience data of each instruction parameter type based on the test record data of that instruction parameter type. Model building module 504 is used to build a mutant scheduling model for this instruction parameter type based on mutation experience data; The fuzzing module 505 is used to obtain the instruction to be tested, and based on the mutant scheduling model, predict the target mutant of at least one instruction parameter type in the instruction to be tested, and perform fuzzing on the instruction to be tested through the target mutant.

[0104] In some embodiments, the instruction parsing module 502 described above is specifically used for: From historical fuzz test data, determine the fuzz test data for at least one instruction parameter corresponding to each instruction parameter type; Based on the fuzz test data, determine the fuzz test state of at least one instruction parameter after each round of mutation processing by multiple mutants during the historical fuzz test process. This state is used as test record data. The fuzz test state is one of the following: passed test, failed test, or the communication module has a new state.

[0105] In some embodiments, the experience determination module 503 described above is specifically used for: For each instruction parameter corresponding to the instruction parameter type, a mutation reward matrix is ​​constructed based on the test record data. Each element in the mutation reward matrix represents the reward value for the change of the fuzzy test state of the communication module after the instruction parameter has been processed by the same or different mutants. The mutation reward matrices of multiple instruction parameters are summed to obtain the mutation reward matrix of that instruction parameter type, which is used as mutation experience data.

[0106] In some embodiments, the model building module 504 described above is specifically used for: Based on mutation experience data, the model parameter matrix corresponding to the instruction parameter type is subjected to multiple rounds of parameter iteration to obtain the iterated model parameter matrix. Each element in the model parameter matrix represents the reward value for switching the mutant for the instruction parameter type. The rows of the model parameter matrix represent multiple unswitched mutants, and the columns represent multiple switched mutants. Based on the model parameter matrix after iteration, a mutant scheduling model for this instruction parameter type is constructed.

[0107] In some embodiments, the model building module 504 described above is specifically used for: For each round of parameter iteration, based on the model parameter matrix after the previous round of parameter iteration, the mutant switching direction corresponding to each unswitched mutant in the current round of parameter iteration is determined. The mutant switching direction is used to indicate whether the unswitched mutant switches to the switched mutant with the largest reward value. Based on the mutant switching direction and mutation experience data, calculate the parameter adjustment matrix for this round of parameter iteration; Based on preset iteration parameters, the parameter adjustment matrix and the model parameter matrix after the previous round of parameter iteration are weighted and summed to obtain the model parameter matrix after the current round of parameter iteration.

[0108] In some embodiments, the fuzz testing module 505 described above is specifically used for: Parse the instruction to be tested and determine the type of at least one target parameter contained in the instruction to be tested; For each target parameter type, determine whether the target parameter type is one of at least one instruction parameter type; If so, the target mutant type that needs to be switched to in each round of mutation processing is predicted by the mutant scheduling model of that target parameter type.

[0109] In some embodiments, the fuzz testing module 505 described above is specifically used for: If the target parameter type is not one of at least one instruction parameter type, fuzz testing is performed on the target parameter type based on multiple mutants, and fuzz test data is collected. Based on the fuzzy test data, construct a mutant scheduling model for this target parameter type.

[0110] Figure 6 This is a schematic diagram of the structure of a terminal device provided in another embodiment of this application.

[0111] The terminal device may include a processor 601 and a memory 602 storing computer program instructions.

[0112] Specifically, the processor 601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0113] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0114] In a particular embodiment, memory 602 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the communication module instruction fuzzing method disclosed in this application.

[0115] The processor 601 reads and executes computer program instructions stored in the memory 602 to implement any of the communication module instruction fuzzy testing methods in the above embodiments.

[0116] In one example, the terminal device may also include a communication interface 603 and a bus 610. Wherein, as... Figure 6 As shown, the processor 601, memory 602, and communication interface 603 are connected through bus 610 and complete communication with each other.

[0117] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0118] Bus 610 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0119] Furthermore, in conjunction with the communication module instruction fuzzing method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the communication module instruction fuzzing methods in the above embodiments.

[0120] This application also provides a computer program product, including a computer program, which, when executed, implements any of the communication module instruction fuzzing methods described in the above embodiments.

[0121] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0122] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0123] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0124] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in 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, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0125] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application. < / p2> < / p1> < / cmd> < / p2> < / p1> < / cmd>

Claims

1. A method for fuzzy testing of communication module instructions, characterized in that, include: Obtain historical communication module instructions, and historical fuzzy test data of the historical communication module instructions; The historical communication module instructions are parsed to determine at least one instruction parameter type contained in the historical communication module instructions, and based on the historical fuzzy test data, test record data for each instruction parameter type is determined. The test record data represents the fuzzy test state changes of the communication module after the instruction parameter type has been mutated by multiple mutants. For each instruction parameter type, based on the test record data of that instruction parameter type, determine the variation experience data of that instruction parameter type; Based on the aforementioned mutation experience data, a mutant scheduling model for this instruction parameter type is constructed; Obtain the instruction to be tested, and based on the mutant scheduling model, predict at least one target mutant of the instruction parameter type in the instruction to be tested, and perform fuzz testing on the instruction to be tested through the target mutant.

2. The method according to claim 1, characterized in that, Based on the historical fuzzy test data, test record data for each instruction parameter type is determined, including: From the historical fuzz test data, determine the fuzz test data for at least one instruction parameter corresponding to each instruction parameter type; Based on the fuzz test data, the fuzz test state of the at least one instruction parameter after each round of mutation processing by the multiple mutants during the historical fuzz test is determined as the test record data. The fuzz test state is one of the following: passing the test, failing the test, or the communication module exhibiting a new state.

3. The method according to claim 1, characterized in that, For each instruction parameter type, based on the test record data for that instruction parameter type, determine the variation experience data for that instruction parameter type, including: For each instruction parameter corresponding to the instruction parameter type, a mutation reward matrix is ​​constructed based on the test record data. Each element in the mutation reward matrix represents the reward value for the change in the fuzzy test state of the communication module after the instruction parameter has been processed by the same or different mutants. The mutation reward matrices of multiple instruction parameters are summed to obtain the mutation reward matrix of that instruction parameter type, which is used as the mutation experience data.

4. The method according to claim 1, characterized in that, Based on the aforementioned mutation experience data, a mutant scheduling model for this instruction parameter type is constructed, including: Based on the mutation experience data, the model parameter matrix corresponding to the instruction parameter type is subjected to multiple rounds of parameter iteration to obtain the iterated model parameter matrix. Each element in the model parameter matrix represents the reward value for switching the mutant for the instruction parameter type. The rows of the model parameter matrix represent multiple unswitched mutants, and the columns represent multiple switched mutants. Based on the iteratively obtained model parameter matrix, the mutant scheduling model of this instruction parameter type is constructed.

5. The method according to claim 4, characterized in that, Based on the aforementioned mutation experience data, multiple rounds of parameter iteration are performed on the model parameter matrix corresponding to the instruction parameter type to obtain the iterated model parameter matrix, including: For each round of parameter iteration, based on the model parameter matrix after the previous round of parameter iteration, the mutant switching direction corresponding to each unswitched mutant in the current round of parameter iteration is determined. The mutant switching direction is used to indicate that the unswitched mutant switches to the switched mutant with the largest reward value. Based on the mutant switching direction and the mutation experience data, calculate the parameter adjustment matrix for this round of parameter iteration; Based on preset iteration parameters, the parameter adjustment matrix and the model parameter matrix after the previous round of parameter iteration are weighted and summed to obtain the model parameter matrix after the current round of parameter iteration.

6. The method according to claim 1, characterized in that, Based on the mutant scheduling model, predicting the target mutant of at least one of the instruction parameter types in the instruction to be tested includes: Parse the instruction to be tested to determine at least one type of target parameter contained in the instruction to be tested; For each of the target parameter types, determine whether the target parameter type is one of the at least one instruction parameter types; If so, the target mutant that needs to be switched to in each round of mutation processing can be predicted using the mutant scheduling model of the target parameter type.

7. The method according to claim 6, characterized in that, The method further includes: If the target parameter type is not one of the at least one instruction parameter type, fuzz testing is performed on the target parameter type based on the multiple mutants, and fuzz test data is collected; Based on the fuzzy test data, a mutant scheduling model for this target parameter type is constructed.

8. A fuzzy testing system for communication module instructions, characterized in that, include: The data collection module is used to acquire historical communication module instructions and historical fuzzy test data of the historical communication module instructions; The instruction parsing module is used to parse the historical communication module instructions, determine at least one instruction parameter type contained in the historical communication module instructions, and determine test record data for each instruction parameter type based on the historical fuzzy test data. The test record data represents the fuzzy test state changes of the communication module after the instruction parameter type has been mutated by multiple mutants. An experience determination module is used to determine the variation experience data of each instruction parameter type based on the test record data of that instruction parameter type. The model building module is used to build a mutant scheduling model for this instruction parameter type based on mutation experience data; The fuzzing module is used to acquire the instruction to be tested, and based on the mutant scheduling model, predict at least one target mutant of the instruction parameter type in the instruction to be tested, and perform fuzzing on the instruction to be tested through the target mutant.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the communication module instruction fuzzing test method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the communication module instruction fuzzy testing method as described in any one of claims 1-7.

Images