A low-code generation method and system for security vulnerability test cases

Abstract

The present invention relates to a low-code generation method and system for security vulnerability test cases, and relates to the field of security vulnerability testing technology. The method comprises the following steps: obtaining vulnerability type, function description, input constraints, and expected results, inputting a test case generation network, obtaining test cases, and retrieving a set of similar use cases based on a similarity threshold; calculating the effective code percentage of the similar use case set and setting it as the effective probability of the test case; and sending the test case to a test terminal when the effective probability of the test case is greater than or equal to the effective probability threshold. The method solves the technical problem that the prior art cannot implement feasibility verification of security vulnerability test cases, resulting in a large number of invalid use cases in the generated test cases.

Description

Technical Field

[0001] The present invention relates to the field of security vulnerability testing technology, and in particular to a low-code generation method and system for security vulnerability test cases. Background Art

[0002] In the research on automated generation of security vulnerability test cases, although AI models can quickly generate a large number of test cases, the feasibility of these cases cannot be verified in advance, resulting in a large number of invalid cases in the generated test cases. This not only wastes test resources but also reduces test efficiency, requiring additional manual screening to remove redundant cases in actual applications. Summary of the Invention

[0003] The present invention aims to solve the technical problem that the feasibility verification of security vulnerability test cases cannot be realized in the existing technology, resulting in a large number of invalid cases in the generated test cases. A low-code generation method and system for security vulnerability test cases are provided to solve the problem.

[0004] The technical solution of the present invention to solve the above technical problems is as follows:

[0005] In a first aspect, the present invention provides a low-code generation method for security vulnerability test cases, including: obtaining vulnerability type, function description, input constraints and expected results, inputting a test case generation network, and obtaining a test case; performing similar code retrieval on the test case based on a similarity threshold to obtain a set of similar use cases; counting the proportion of valid code in the set of similar use cases, and setting it as the valid probability of the test case; when the valid probability of the test case is greater than or equal to the valid probability threshold, sending the test case to a test terminal.

[0006] In the second aspect, the present invention provides a low-code generation system for security vulnerability test cases, including: a test case generation unit, used to obtain vulnerability type, function description, input constraints and expected results, input a test case generation network, and obtain a test case; a similar code retrieval unit, used to perform similar code retrieval on the test case based on a similarity threshold, and obtain a similar use case set; an effective code analysis unit, used to count the effective code ratio of the similar use case set, and set it as the effective probability of the test case; a test case feedback unit, used to send the test case to the test terminal when the effective probability of the test case is greater than or equal to the effective probability threshold.

[0007] The beneficial effects of the present invention are as follows: by providing a method of inputting vulnerability types, function descriptions, input constraints and expected results into a test case generation network to generate preliminary test cases; then performing similar code retrieval on the generated test cases based on a similarity threshold to obtain a set of similar use cases; then counting the proportion of valid codes in the set of similar use cases and defining it as the effective probability of the test case; finally, when the effective probability of the test case is greater than or equal to a preset effective probability threshold, sending the test case to a test terminal. By performing similar code retrieval on the test cases after automatic generation to obtain a set of similar use cases, then counting the proportion of valid codes in the set of similar use cases and setting it as the effective probability of the test case as an evaluation criterion for sorting test cases, the technical effect of improving the availability of test cases is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A flowchart of a low-code generation method for security vulnerability test cases provided by the present invention;

[0009] Figure 2 A structural diagram of a low-code generation system for security vulnerability test cases provided by the present invention.

[0010] In the accompanying drawings, the components represented by the reference numerals are described as follows:

[0011] Test case generation unit 100, similar code retrieval unit 200, valid code analysis unit 300, test case feedback unit 400. DETAILED DESCRIPTION

[0012] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making any creative efforts shall fall within the scope of protection of the present invention.

[0013] In the description of the present invention, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature specified as "first" or "second" may explicitly or implicitly include one or more of the specified features. In the description of the present invention, "plurality" means two or more, unless otherwise specifically defined.

[0014] In the description of the present invention, the term "for example" is used to mean "used as an example, illustration or illustration". Any embodiment of the present invention described as "for example" is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is given to enable any person skilled in the art to implement and use the present invention. In the following description, details are listed for the purpose of explanation. It should be understood that a person of ordinary skill in the art can recognize that the present invention can be implemented without using these specific details. In other examples, well-known structures and processes are not elaborated in detail to avoid obscuring the description of the present invention with unnecessary details. Therefore, the present invention is not intended to be limited to the embodiments shown, but is consistent with the widest scope consistent with the principles and features disclosed herein.

[0015] Example 1:

[0016] like Figure 1 As shown, an embodiment of the present invention provides a low-code generation method for security vulnerability test cases, including the steps of:

[0017] S10: Obtain vulnerability type, function description, input constraints and expected results, input test case generation network, and obtain test cases;

[0018] Specifically, vulnerability type refers to the type of security defect existing in the software system, such as SQL injection, cross-site scripting (XSS) or buffer overflow; functional description: a detailed description of the software functional point, describing the expected behavior and operation logic of the functional point; input constraints: restrictions on test case input data, such as data type, range or format, etc., used to ensure that the input data meets the test requirements; expected results: the expected results after the test case is executed, used to verify whether the software function is normal; test case generation network: a model based on artificial intelligence or machine learning, used to generate test cases based on the input vulnerability type, functional description, input constraints and expected results; test case: a specific test scenario used to verify whether the software function is normal or whether there is a vulnerability, including input data and expected output. The vulnerability type, functional description, input constraints and expected results can be user-defined input content, used to constrain the generation of test cases.

[0019] Preferably, the test case generation network construction steps are as follows:

[0020] A generative adversarial network is constructed, including a generator and an adversary. First, a test case dataset is collected and mixed with a false test case dataset to obtain an adversary training dataset. The supervisory data value of the test case data is 1, indicating that it is true, and the supervisory data value of the false test case data is 0, indicating that it is false. Using the supervisory data, the adversary training dataset is retrieved as input to train the adversary, which can achieve the distinction between false test cases and real test cases. Then, a vulnerability type record dataset, a function description record dataset, an input constraint record dataset, an expected result record dataset, and a test case identification dataset are collected. The generator is trained with the test case identification dataset as supervision and the vulnerability type record dataset, function description record dataset, input constraint record dataset, and expected result record dataset as input. Finally, the output of the generator is used as the input of the adversary. Whenever the adversary output is 1, it means that the case generated by the generator can be mistaken for the real test case, and it can be added to the test case.

[0021] By obtaining vulnerability types and related description information, the generated test cases can be ensured to be targeted, providing high-quality input for subsequent similar code retrieval and effectiveness evaluation, thereby improving the efficiency and accuracy of the entire test case generation system.

[0022] S20: performing similar code retrieval on the test case based on a similarity threshold to obtain a set of similar test cases;

[0023] Furthermore, similar code retrieval is performed on the test case based on a similarity threshold to obtain a set of similar test cases, including:

[0024] Obtaining the benchmark code of the test case to perform AST tree configuration and obtain a benchmark abstract syntax tree;

[0025] Obtain the comparison code of the use case to be analyzed, configure the AST tree, and obtain the comparison abstract syntax tree;

[0026] Encode the reference abstract syntax tree and the comparison abstract syntax tree respectively through the Tree-LSTM model to obtain a reference encoding vector and a comparison encoding vector;

[0027] performing a weighted mean evaluation on the structural similarity between the reference abstract syntax tree and the comparison abstract syntax tree and the cosine similarity between the reference code vector and the comparison code vector according to a similarity evaluation function to obtain a similarity evaluation value;

[0028] When the similarity evaluation value is greater than or equal to a similarity threshold, the use case to be analyzed is added to the similar use case set.

[0029] Specifically, the similarity threshold is a preset value used to measure the degree of similarity between codes. Two code segments are considered similar when their similarity is greater than or equal to the threshold. For example, setting a similarity threshold of 0.8 means that two code segments are considered similar only when their similarity reaches 80% or above. Similar code retrieval compares the similarity between the test case code and other known codes to identify code segments or use cases that are similar to the target test case. Similar use case collection is a collection of all use cases that are similar to the target test case. These use cases have a high degree of similarity with the target use case in terms of code structure or functionality.

[0030] The specific process is: first, configure the baseline code of the test case into an abstract syntax tree (AST), and then perform the same AST configuration on the codes of other use cases to be analyzed. For example, assuming that the baseline code is a simple login function code, its AST tree will reflect the structure and logic of the code; then, use the Tree-LSTM model to encode the baseline AST and the comparison AST to generate an encoding vector; through the similarity evaluation function, combine the structural similarity of the AST and the cosine similarity of the encoding vector to calculate the similarity evaluation value; if the value is greater than or equal to the similarity threshold (for example, 0.8), the use case to be analyzed is added to the set of similar use cases.

[0031] S30: Count the percentage of valid codes in the similar use case set and set it as the valid probability of the test case;

[0032] S40: When the validity probability of the test case is greater than or equal to the validity probability threshold, the test case is sent to the test terminal.

[0033] Furthermore, the effective code ratio of the similar use case set is counted and set as the effective probability of the test case, including:

[0034] Obtaining a first similar use case in the set of similar use cases;

[0035] Construct validity evaluation function:

[0036]

[0037] Among them, w1, w2, w3, w4 and w5 represent weight parameters, which sum to 1, R represents the use case repeatability parameter, C represents the use case coverage parameter, Cl represents the use case clarity parameter, Co represents the use case completeness parameter, Ru represents the use case reusability parameter, and θ represents the threshold parameter, which is used to adjust the offset of the function;

[0038] analyzing, according to the effectiveness evaluation function, a first similar use case effectiveness parameter of the first similar use case;

[0039] When the validity parameter of the first similar use case is greater than or equal to a validity parameter threshold, performing a validity code identification on the first similar use case;

[0040] The proportion of similar use cases with the valid code identifier in the set of similar use cases is counted and set as the valid probability of the test case.

[0041] Furthermore, the similarity evaluation function is:

[0042] S(T1,T2)0=αS(T1,T2)1+(1-α)S(E(T1),E(T2))2,

[0043]

[0044] Among them, S(T1, T2)0 represents the comprehensive similarity, S(T1, T2)1 represents the structural similarity between the baseline abstract syntax tree and the comparison abstract syntax tree, S(E(T1), E(T2))2 represents the cosine similarity between the baseline encoding vector and the comparison encoding vector, E(T1) represents the baseline encoding vector, E(T2) represents the comparison encoding vector, T1 represents the baseline abstract syntax tree, T2 represents the comparison abstract syntax tree, V1 represents the node set of the baseline abstract syntax tree, V2 represents the node set of the comparison abstract syntax tree, λ is the regularization parameter, v represents the intersection node, sim(v) represents the intersection node similarity, children(v) represents the intersection child nodes of the intersection node, n[children(v)]1 represents the number of child nodes of the intersection node whose similarity in V1 and V2 is greater than or equal to the similarity threshold, n[children(v)]2 is the total number of intersection child nodes, and α represents the preset weight.

[0045] Furthermore, it also includes:

[0046] Count the length of arithmetic operator code snippets at intersection nodes;

[0047] Get the total length of the code snippet of the intersection node;

[0048] The ratio of the length of the arithmetic operator code snippet to the total length of the code snippet is calculated and set as the preset weight.

[0049] Specifically, the effective code ratio refers to the proportion of use cases corresponding to code snippets that can effectively trigger vulnerabilities or meet test requirements in a set of similar use cases; effective code is verified to accurately reflect the characteristics of vulnerabilities or test targets of similar use cases; test case effectiveness probability: a probability value calculated based on the effective code ratio, used to evaluate the overall effectiveness of the test case, and is an important indicator for measuring whether a test case is worth adopting.

[0050] The specific process is as follows: First, select a use case from the set of similar use cases as the analysis object, for example, select the first similar use case; then, construct the effectiveness evaluation function Analyze the effectiveness parameters of the use case, such as repeatability = number of executions with consistent results / total number of executions; coverage = (number of executed statements / number of executable statements + number of tested branches / total number of branches + number of tested conditions / total number of conditions) / 3; clarity = number of clear test steps and expected results / total number of test steps and expected results; completeness = number of covered function points and boundary conditions / total number of function points and boundary conditions; reusability = number of reusable test cases / total number of tested function points, etc.; combine them into a comprehensive effectiveness index through weight allocation; if the index is greater than or equal to the preset effectiveness parameter threshold, the use case is marked as valid code; finally, count the proportion of all use cases marked as valid code in the set of similar use cases, and set this proportion value as the effectiveness probability of the test case.

[0051] For example, assuming that there are 100 use cases in a set of similar use cases, after effectiveness evaluation, it is found that the effectiveness parameters of 70 of them are higher than the threshold and are identified as valid use cases. Then, the effective code ratio is 70%, and the effective probability of the test case is also 70%. By counting the effective code ratio, the quality of the test case can be quantified, so as to screen out the truly valuable test cases. For example, if the effectiveness probability of a test case is low (such as less than 50%), it may be judged as redundant or invalid, thereby avoiding sending it to the test terminal and saving test resources. On the contrary, if the effectiveness probability is high (such as more than 80%), it means that the test case has higher feasibility and value and can be adopted first.

[0052] Furthermore, the similar use case screening process is as follows:

[0053] The similarity evaluation function is constructed as: S(T1,T2)0=αS(T1,T2)1+(1-α)S(E(T1),E(T2))2,

[0054] Then, based on the compared V1 and V2, the weight α is dynamically configured. After the configuration is completed, the use case similarity is analyzed through the similarity evaluation function. By analyzing the use case similarity from both structural and semantic aspects, the comprehensiveness of the analysis results is guaranteed. Dynamic configuration of weights can be dynamically assigned based on the compared real-time code data, thereby improving individual characteristics.

[0055] Furthermore, the vulnerability type, function description, input constraints and expected results are obtained. Step S10 includes the following steps:

[0056] S110: Traverse the test environment function points to perform frequent vulnerability statistics on the same function points and obtain the first frequent vulnerability type;

[0057] S120: Scan the test environment code to obtain abnormal functions and error types;

[0058] S130: Counting frequent vulnerabilities of the same state based on the abnormal function and the error type to obtain a second frequent vulnerability type;

[0059] S140: Traverse the test environment function points, take the union of the first frequent vulnerability type and the second frequent vulnerability type, and obtain a comprehensive frequent vulnerability type, wherein the comprehensive frequent vulnerability type corresponds to the function point one by one;

[0060] S150: Set the comprehensive frequent vulnerability type as the test case, and configure the function description, the input constraints, and the expected results according to the function point.

[0061] Specifically, test environment function points: refers to modules or operation points with independent functions in the software system, such as user login modules, file upload functions, etc.; statistics of frequent vulnerabilities in the same function points: by analyzing historical vulnerability data, find out the types of vulnerabilities that frequently appear in the same type of function points; abnormal functions and error types: functions or code snippets that may cause vulnerabilities detected by code scanning tools, as well as the types of errors that may occur at runtime; statistics of frequent vulnerabilities in the same state: based on abnormal functions and error types, statistics on frequently occurring vulnerability types caused by the same function and the same error type; comprehensive frequent vulnerability types: a set of vulnerability types obtained by merging the vulnerability types obtained through function point statistics and code scanning statistics; functional description, input constraints and expected results: detailed information for the generated test case configuration, used to guide the generation and verification of test cases.

[0062] The specific process is as follows:

[0063] Traversing the test environment's functional points: The system checks each functional point in the software, such as the user login module and the data query module. For each functional point, it calculates the historically most frequently occurring vulnerability types and determines the most frequently occurring vulnerability type. For example, SQL injection vulnerabilities may frequently occur in the user login module.

[0064] Scan the test environment code: Use static code analysis tools to scan the code for abnormal functions and error types. For example, you may detect that a function may cause a buffer overflow, or that a code snippet may trigger an XSS attack.

[0065] Counting frequent vulnerabilities in the same state: Based on the abnormal function and error type, further count the vulnerability types that frequently appear in the same running state or code structure to obtain the second most frequent vulnerability type.

[0066] Merge vulnerability types: Take the union of the first and second most frequent vulnerability types to obtain a comprehensive set of frequent vulnerability types. These vulnerability types correspond to function points one by one, ensuring that each function point has a targeted vulnerability type.

[0067] Configure test cases: Use common vulnerability types as the target vulnerability types for the test cases. Configure the functional description, input constraints, and expected results based on the characteristics of the function point. For example, for a SQL injection vulnerability in the user login module, the functional description is "user login function," the input constraints are "username and password fields," and the expected result is "return an error message when a SQL injection attack is detected."

[0068] By traversing function points and scanning code, we can uncover high-risk vulnerability types in the actual environment and avoid blindly generating test cases. At the same time, we configure the detailed information of the test cases according to the characteristics of the function points to ensure that the generated test cases are targeted and effective.

[0069] Furthermore, the test environment function points are traversed to perform frequent vulnerability statistics of the same function points to obtain a first frequent vulnerability type. Step S110 includes the following steps:

[0070] S111: Obtain a first function point of the test environment function points, wherein the first function point has a function description tag;

[0071] S112: Retrieving historical vulnerability test data having the same function description tag as the function description tag;

[0072] S113: Counting vulnerability types and trigger frequencies of the historical vulnerability test data, screening vulnerability types whose trigger frequencies are greater than or equal to a trigger frequency threshold, and adding them to the frequent vulnerability types of the first functional point;

[0073] S114: Add the first function point frequent vulnerability type to the first frequent vulnerability type.

[0074] Specifically, the process of counting frequent vulnerabilities in the same state and the same function point is the same. The following example uses the same function point as an example:

[0075] Functional description label: a label used to identify the characteristics or functions of a test environment function point, such as "user login", "file upload" or "data query", etc., used to quickly locate and classify function points; historical vulnerability test data: vulnerability data recorded in the same or similar function points in the past, including vulnerability type, trigger conditions, occurrence frequency and other information; trigger frequency: the number of times or frequency a vulnerability appears in historical vulnerability test data, used to assess the commonness of the vulnerability; trigger frequency threshold: a preset value used to filter out frequently occurring vulnerability types. For example, if the threshold is set to 10 times, then only vulnerability types with a trigger frequency greater than or equal to 10 times will be included in the statistics.

[0076] The specific process is as follows:

[0077] Get function points and their description labels: Extract the first function point (such as "user login module") from the test environment and get its function description label (such as "user login").

[0078] Retrieve historical vulnerability data: Retrieve historical vulnerability test data for the same function point based on the function description tag. For example, search for all vulnerability records related to "user login" in the vulnerability database.

[0079] Statistics on vulnerability types and trigger frequencies: Analyze the retrieved historical vulnerability data and count the occurrence frequency of each vulnerability type. For example, statistics show that SQL injection vulnerabilities appeared 20 times, XSS vulnerabilities appeared 15 times, and other vulnerability types appeared less frequently.

[0080] Filter high-frequency vulnerability types: Based on a preset trigger frequency threshold (e.g., 10 times), filter out vulnerability types with a trigger frequency greater than or equal to the threshold. For example, if the threshold is 10 times, SQL injection and XSS vulnerability types are included in the first function point frequent vulnerability types.

[0081] Add to the first frequent vulnerability type set: Add the filtered high-frequency vulnerability types to the first frequent vulnerability type set for subsequent vulnerability test case generation.

[0082] By analyzing historical vulnerability data, we can accurately identify the high-risk vulnerability types in a certain functional point, rather than relying on a general vulnerability list.

[0083] The low-code generation method for security vulnerability test cases provided by the embodiment of the present invention has at least the following technical effects:

[0084] The technical solution provides a test case generation network that inputs vulnerability types, functional descriptions, input constraints, and expected results into a test case generation network to generate preliminary test cases. Similar code retrieval is then performed on the generated test cases based on a similarity threshold to obtain a set of similar test cases. The percentage of valid code in the similar test case set is then counted and defined as the effective probability of the test case. Finally, when the effective probability of the test case is greater than or equal to a preset effective probability threshold, the test case is sent to the test terminal. By performing similar code retrieval on the automatically generated test cases to obtain a set of similar test cases, the percentage of valid code in the similar test case set is counted and defined as the effective probability of the test case, which serves as the evaluation criterion for sorting test cases, thereby achieving the technical effect of improving the availability of test cases.

[0085] Example 2:

[0086] like Figure 2 As shown, based on the same inventive concept as the low-code generation method for security vulnerability test cases provided in Example 1, an embodiment of the present invention further provides a low-code generation system for security vulnerability test cases, including:

[0087] The test case generation unit 100 is used to obtain vulnerability type, function description, input constraints and expected results, input the test case generation network, and obtain the test case;

[0088] A similar code retrieval unit 200 is configured to perform similar code retrieval on the test case based on a similarity threshold to obtain a set of similar test cases;

[0089] The effective code analysis unit 300 is used to count the effective code ratio of the similar use case set and set it as the effective probability of the test case;

[0090] The test case feedback unit 400 is configured to send the test case to the test terminal when the validity probability of the test case is greater than or equal to a validity probability threshold.

[0091] Furthermore, the test case generation unit 100 performs the following steps:

[0092] Traverse the test environment function points to count the frequent vulnerabilities of the same function points and obtain the first frequent vulnerability type;

[0093] Traverse the test environment code to scan and obtain the abnormal function and error type;

[0094] Count the frequent vulnerabilities in the same state based on the abnormal function and error type, and obtain the second most frequent vulnerability type;

[0095] Traversing the test environment function points, taking the union of the first frequent vulnerability type and the second frequent vulnerability type to obtain a comprehensive frequent vulnerability type, wherein the comprehensive frequent vulnerability type corresponds to the function point one by one;

[0096] The comprehensive frequent vulnerability type is set as the test case, and the function description, the input constraint and the expected result are configured according to the function point.

[0097] Furthermore, the test case generation unit 100 executes the steps further including:

[0098] Obtaining a first function point of the test environment function points, wherein the first function point has a function description tag;

[0099] Retrieving historical vulnerability test data having the same function description tag as the function description tag;

[0100] Counting vulnerability types and trigger frequencies of the historical vulnerability test data, screening the vulnerability types whose trigger frequencies are greater than or equal to a trigger frequency threshold, and adding them to the frequent vulnerability types of the first functional point;

[0101] Add the first function point frequent vulnerability type to the first frequent vulnerability type.

[0102] Furthermore, the similar code retrieval unit 200 performs the following steps:

[0103] Obtaining the benchmark code of the test case to perform AST tree configuration and obtain a benchmark abstract syntax tree;

[0104] Obtain the comparison code of the use case to be analyzed, configure the AST tree, and obtain the comparison abstract syntax tree;

[0105] Encode the reference abstract syntax tree and the comparison abstract syntax tree respectively through the Tree-LSTM model to obtain a reference encoding vector and a comparison encoding vector;

[0106] performing a weighted mean evaluation on the structural similarity between the reference abstract syntax tree and the comparison abstract syntax tree and the cosine similarity between the reference code vector and the comparison code vector according to a similarity evaluation function to obtain a similarity evaluation value;

[0107] When the similarity evaluation value is greater than or equal to a similarity threshold, the use case to be analyzed is added to the similar use case set.

[0108] Furthermore, the similarity evaluation function is:

[0109] S(T1,T2)0=αS(T1,T2)1+(1-α)S(E(T1),E(T2))2,

[0110]

[0111]

[0112] Among them, S(T1, T2)0 represents the comprehensive similarity, S(T1, T2)1 represents the structural similarity between the baseline abstract syntax tree and the comparison abstract syntax tree, S(E(T1), E(T2))2 represents the cosine similarity between the baseline encoding vector and the comparison encoding vector, E(T1) represents the baseline encoding vector, E(T2) represents the comparison encoding vector, T1 represents the baseline abstract syntax tree, T2 represents the comparison abstract syntax tree, V1 represents the node set of the baseline abstract syntax tree, V2 represents the node set of the comparison abstract syntax tree, λ is the regularization parameter, v represents the intersection node, sim(v) represents the intersection node similarity, children(v) represents the intersection child nodes of the intersection node, n[children(v)]1 represents the number of child nodes of the intersection node whose similarity in V1 and V2 is greater than or equal to the similarity threshold, n[children(v)]2 is the total number of intersection child nodes, and α represents the preset weight.

[0113] Furthermore, the similar code retrieval unit 200 performs the following steps:

[0114] Count the length of arithmetic operator code snippets at intersection nodes;

[0115] Get the total length of the code snippet of the intersection node;

[0116] The ratio of the length of the arithmetic operator code snippet to the total length of the code snippet is calculated and set as the preset weight.

[0117] Furthermore, the effective code analysis unit 300 performs the following steps:

[0118] Obtaining a first similar use case in the set of similar use cases;

[0119] Construct validity evaluation function:

[0120]

[0121] Among them, w1, w2, w3, w4 and w5 represent weight parameters, which sum to 1, R represents the use case repeatability parameter, C represents the use case coverage parameter, Cl represents the use case clarity parameter, Co represents the use case completeness parameter, Ru represents the use case reusability parameter, and θ represents the threshold parameter, which is used to adjust the offset of the function;

[0122] analyzing, according to the effectiveness evaluation function, a first similar use case effectiveness parameter of the first similar use case;

[0123] When the validity parameter of the first similar use case is greater than or equal to a validity parameter threshold, performing a validity code identification on the first similar use case;

[0124] The proportion of similar use cases with the valid code identifier in the set of similar use cases is counted and set as the valid probability of the test case.

[0125] It should be noted that, in the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0126] It will be understood by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Thus, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0127] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts 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, an embedded computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0128] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0130] Although preferred embodiments of the present invention have been described, additional changes and modifications to these embodiments may occur to those skilled in the art once the basic inventive concepts become known.

[0131] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the present invention and its equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A low-code generation method for security vulnerability test cases, characterized in that: include: Obtain vulnerability type, function description, input constraints and expected results, input test case generation network, and obtain test cases; For the test case, similar code retrieval is performed based on a similarity threshold to obtain a similar case set; Count the percentage of valid codes in the similar test case set and set it as the test case validity probability; When the validity probability of the test case is greater than or equal to the validity probability threshold, sending the test case to the test terminal; The method of searching for similar codes based on a similarity threshold for the test case to obtain a set of similar test cases includes: Obtaining the benchmark code of the test case to perform AST tree configuration and obtain a benchmark abstract syntax tree; Obtain the comparison code of the use case to be analyzed, configure the AST tree, and obtain the comparison abstract syntax tree; Encode the reference abstract syntax tree and the comparison abstract syntax tree respectively through the Tree-LSTM model to obtain a reference encoding vector and a comparison encoding vector; performing a weighted mean evaluation on the structural similarity between the reference abstract syntax tree and the comparison abstract syntax tree and the cosine similarity between the reference code vector and the comparison code vector according to a similarity evaluation function to obtain a similarity evaluation value; When the similarity evaluation value is greater than or equal to a similarity threshold, adding the use case to be analyzed to the similar use case set; Wherein, the similarity evaluation function is: ， ， when exist and are exactly the same as: ; when exist and Different in and There are intersection subnodes in both: ; when exist and Different in and At least one of them does not have an intersection child node: ; in, Representing the comprehensive similarity, Characterizing the structural similarity between the reference abstract syntax tree and the comparison abstract syntax tree, Characterize the cosine similarity between the reference code vector and the comparison code vector, Characterize the benchmark encoding vector, Characterize the alignment encoding vector, Representing the baseline abstract syntax tree, Representation comparison abstract syntax tree, The set of nodes representing the base abstract syntax tree, The node set representing the comparison abstract syntax tree, λ is the regularization parameter, Represents the intersection node, Represents the similarity of intersection nodes, The intersection subnode representing the intersection node, Representing the intersection node The number of child nodes in whose similarity is greater than or equal to the similarity threshold, The total number of intersection child nodes, Represents the preset weight.

2. The method according to claim 1, wherein Obtain vulnerability type, functional description, input constraints, and expected results, including: Traverse the test environment function points to count the frequent vulnerabilities of the same function points and obtain the first frequent vulnerability type; Traverse the test environment code to scan and obtain the abnormal function and error type; Count the frequent vulnerabilities in the same state based on the abnormal function and error type, and obtain the second most frequent vulnerability type; Traversing the test environment function points, taking the union of the first frequent vulnerability type and the second frequent vulnerability type to obtain a comprehensive frequent vulnerability type, wherein the comprehensive frequent vulnerability type corresponds to the function point one by one; The comprehensive frequent vulnerability type is set as the test case, and the function description, the input constraint and the expected result are configured according to the function point.

3. The method according to claim 2, wherein Traverse the test environment function points to collect frequent vulnerability statistics for the same function points and obtain the most frequent vulnerability types, including: Obtaining a first function point of the test environment function points, wherein the first function point has a function description tag; Retrieving historical vulnerability test data having the same function description tag as the function description tag; Counting vulnerability types and trigger frequencies of the historical vulnerability test data, screening the vulnerability types whose trigger frequencies are greater than or equal to a trigger frequency threshold, and adding them to the frequent vulnerability types of the first functional point; Add the first function point frequent vulnerability type to the first frequent vulnerability type.

4. The method according to claim 1, wherein Also includes: Count the length of arithmetic operator code snippets at intersection nodes; Get the total length of the code snippet of the intersection node; The ratio of the length of the arithmetic operator code snippet to the total length of the code snippet is calculated and set as the preset weight.

5. The method according to claim 1, wherein The effective code percentage of the similar use case set is counted and set as the effective probability of the test case, including: Obtaining a first similar use case in the set of similar use cases; Construct validity evaluation function: ， in, 、 、 、 and Both represent weight parameters, 、 、 、 and The sum of is 1, Characterize the use case repeatability parameter, C characterizes the use case coverage parameter, Characterize the use case clarity parameters, Characterize the use case completeness parameters, Characterize the reusability parameters of use cases, Characterize the threshold parameter, which is used to adjust the offset of the function; analyzing, according to the effectiveness evaluation function, a first similar use case effectiveness parameter of the first similar use case; When the validity parameter of the first similar use case is greater than or equal to a validity parameter threshold, performing a validity code identification on the first similar use case; The proportion of similar use cases with the valid code identifier in the set of similar use cases is counted and set as the valid probability of the test case.

6. A low-code generation system for security vulnerability test cases, characterized by: A method for implementing a low-code generation method for security vulnerability test cases according to any one of claims 1 to 5, comprising: A test case generation unit is used to obtain vulnerability type, function description, input constraints and expected results, input the test case generation network, and obtain test cases; A similar code retrieval unit, configured to perform similar code retrieval on the test case based on a similarity threshold to obtain a similar case set; An effective code analysis unit is used to count the effective code ratio of the similar use case set and set it as the effective probability of the test case; The test case feedback unit is configured to send the test case to the test terminal when the validity probability of the test case is greater than or equal to a validity probability threshold.

Images