Test data processing method and device, computer device and storage medium

Abstract

The application relates to a test data processing method and device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: obtaining an initial test case for a to-be-tested object; determining a mutation point based on the initial test case, intercepting code content in the initial test case up to the mutation point, and writing code meeting a syntax standard based on the intercepted code content to obtain an initial variation test case; determining target code content to be replaced from the initial test case; determining code content with a structure attribute matching a structure attribute of the target code content in the initial variation test case as replacement code content; replacing the target code content in the initial test case based on the replacement code content to obtain a target variation test case, which is used for testing the to-be-tested object. The method can improve the accuracy of the test case obtained through variation.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a test data processing method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] With the development of computer technology, fuzz testing technology has emerged. The core idea of ​​fuzz testing is to input a large number of automatically generated test cases into the object under test, monitor and analyze anomalies that occur during execution, and finally determine whether they are defects. Fuzz testing technology has advantages such as high automation, high testing efficiency, and independence from the source code of the target program, making it one of the most effective defect detection methods currently available. The key to fuzz testing lies in the generation of test cases; the quality of the generated test cases determines the final effect of the fuzz test.

[0003] In traditional techniques, a large number of test cases are generated by randomly mutating the collected raw data samples. However, the test cases obtained by random mutation have low accuracy. Summary of the Invention

[0004] Therefore, it is necessary to provide a test data processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the accuracy of obtained test cases in response to the above-mentioned technical problems.

[0005] On one hand, this application provides a test data processing method. The method includes: obtaining initial test cases for an object to be tested; determining mutation points based on the initial test cases; extracting code content from the initial test cases up to the mutation points; and continuing to write grammatically correct code based on the extracted code content to obtain initial variant test cases; determining target code content to be replaced from the initial test cases; identifying code content in the initial variant test cases whose structural attributes match the structural attributes of the target code content as replacement code content; and replacing the target code content in the initial test cases based on the replacement code content to obtain target variant test cases, wherein the target variant test cases are used to test the object to be tested.

[0006] On the other hand, this application also provides a test data processing apparatus. The apparatus includes: an initial test case acquisition module, used to acquire initial test cases for an object to be tested; a code continuation module, used to determine mutation points based on the initial test cases, extract code content from the initial test cases up to the mutation point, and continue writing code conforming to syntax standards based on the extracted code content to obtain initial variant test cases; a target code determination module, used to determine target code content to be replaced from the initial test cases; a replacement code determination module, used to determine code content in the initial variant test cases whose structural attributes match the structural attributes of the target code content as replacement code content; and a code replacement module, used to replace the target code content in the initial test cases based on the replacement code content to obtain target variant test cases, wherein the target variant test cases are used to test the object to be tested.

[0007] On the other hand, this application also provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: obtaining initial test cases for the object to be tested; determining mutation points based on the initial test cases, extracting code content from the initial test cases up to the mutation points, and continuing to write code conforming to syntax standards based on the extracted code content to obtain initial variant test cases; determining target code content to be replaced from the initial test cases; determining code content in the initial variant test cases whose structural attributes match the structural attributes of the target code content as replacement code content; replacing the target code content in the initial test cases based on the replacement code content to obtain target variant test cases, which are used to test the object to be tested.

[0008] On the other hand, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps: obtaining initial test cases for an object to be tested; determining mutation points based on the initial test cases, extracting code content from the initial test cases up to the mutation points, and continuing to write code conforming to syntax standards based on the extracted code content to obtain initial variant test cases; determining target code content to be replaced from the initial test cases; determining code content in the initial variant test cases whose structural attributes match the structural attributes of the target code content as replacement code content; replacing the target code content in the initial test cases based on the replacement code content to obtain target variant test cases, wherein the target variant test cases are used to test the object to be tested.

[0009] On the other hand, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps: obtaining initial test cases for an object to be tested; determining mutation points based on the initial test cases, extracting code content from the initial test cases up to the mutation points, and continuing to write code conforming to syntax standards based on the extracted code content to obtain initial variant test cases; determining target code content to be replaced from the initial test cases; determining code content in the initial variant test cases whose structural attributes match the structural attributes of the target code content as replacement code content; replacing the target code content in the initial test cases based on the replacement code content to obtain target variant test cases, wherein the target variant test cases are used to test the object to be tested.

[0010] The aforementioned test data processing method, apparatus, computer equipment, storage medium, and computer program product obtain initial test cases for the object under test, determine mutation points based on the initial test cases, extract code content from the initial test cases up to the mutation points, and continue writing syntactically compliant code based on the extracted code content to obtain initial mutated test cases. The target code content to be replaced is determined from the initial test cases, and the code content in the initial mutated test cases whose structural attributes match those of the target code content is identified as replacement code content. The target code content in the initial test cases is replaced based on the replacement code content to obtain the target mutated test cases. Since the target mutated test cases are obtained by replacing the target code content in the initial test cases with replacement code content, and the replacement code content matches the structural attributes of the target code content, the target mutated test cases can retain as much semantic information as possible from the initial test cases, avoid destroying the structure of the initial test cases, and ensure syntactic correctness, thereby improving the accuracy of the mutated test cases. Attached Figure Description

[0011] Figure 1 This is a diagram illustrating the application environment of a test data processing method in one embodiment;

[0012] Figure 2 This is a flowchart illustrating a test data processing method in one embodiment;

[0013] Figure 3 This is a schematic diagram illustrating the extraction of code content in one embodiment;

[0014] Figure 4 This is a flowchart illustrating the test data processing method in another embodiment;

[0015] Figure 5 This is a flowchart illustrating the test data processing method in yet another embodiment;

[0016] Figure 6 This is a flowchart illustrating the test data processing method in yet another embodiment;

[0017] Figure 7 This is a flowchart illustrating the test data processing method in yet another embodiment;

[0018] Figure 8 This is an overall flowchart of the test data processing method in one embodiment;

[0019] Figure 9 This is a structural block diagram of a test data processing device in one embodiment;

[0020] Figure 10 This is an internal structural diagram of a computer device in one embodiment;

[0021] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0023] The test data processing method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store data that server 104 needs to process, such as original test cases and target variant test cases. The data storage system can be integrated on server 104 or placed in the cloud or on another server. In one embodiment, after receiving a test request for the object to be tested from terminal 102, server 104 can obtain initial test cases for the object to be tested, determine mutation points based on these initial test cases, extract the code content up to the mutation point from the test cases, continue writing code conforming to syntax standards based on the extracted code content to obtain initial variant test cases, determine the target code content to be replaced from the initial test cases, and determine the code content in the initial variant test cases whose structural attributes match the structural attributes of the target code content as replacement code content. Based on the replacement code content, the target code content in the initial test cases is replaced to obtain the target variant test cases. Based on the obtained target variant test cases, server 104 can test the object to be tested and return the test results to terminal 102.

[0024] Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminal 102 includes, but is not limited to, smartphones, tablets, laptops, desktop computers, smart voice interaction devices, smart home appliances, vehicle terminals, and aircraft. Terminals and servers can be directly or indirectly connected via wired or wireless communication; this application does not impose any restrictions on this connection.

[0025] The embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0026] In one embodiment, such as Figure 2 As shown, a test data processing method is provided. Taking the application of this method to a computer device as an example, the computer device can be... Figure 1 Terminal 102 in the middle can also be Figure 1 The server 104 in the diagram can also be a system composed of terminal 102 and server 104. Specifically, the test data processing method includes the following steps:

[0027] Step 202: Obtain initial test cases for the object to be tested.

[0028] The object to be tested refers to the program that needs to be tested. The object to be tested can be various compilers. For example, the object to be tested can be a JavaScript engine, a Java Virtual Machine (JVM), or GCC (GNU Compiler Collection). The initial test cases for the object to be tested refer to the original test cases. The test data processing method provided in this application can generate and mutate the original test cases to obtain a large number of test cases that can be used for continuous testing of the object to be tested. The initial test cases can be test cases containing only function bodies or complete executable files.

[0029] Specifically, a computer device can acquire one or more initial test cases for the object to be tested, and then perform a subsequent mutation process based on the initial test cases to generate target mutation test cases.

[0030] In one embodiment, when the object under test includes multiple different versions, the computer device can obtain initial test cases for each version of the object under test. These multiple different versions of the object under test can each correspond to different developers. For example, assuming the object under test is a JavaScript engine, and the JavaScript engine includes multiple different versions such as JavaScriptCore, JerryScript, and QuickJS, then for each version of the JavaScript engine, the computer device can obtain one or more initial test cases for that version of the JavaScript engine. Here, "multiple" as mentioned in this application refers to at least two.

[0031] Considering that random test cases can easily lead to testing of code modules unrelated to defects or vulnerabilities, reducing testing efficiency, and existing research confirms that continuous testing of code modules covered by test cases that have already triggered defects or vulnerabilities is highly likely to trigger defects or vulnerabilities in the object under test again. Therefore, in this application, the historical scripts that have triggered defects or vulnerabilities in the object under test, as well as standard test suites, are fully utilized to obtain initial test cases, thereby directing testing to code modules prone to vulnerabilities or defects, improving testing efficiency and the probability of vulnerability discovery. Based on this, the following embodiments are provided in this application for obtaining initial test cases for the object under test:

[0032] In one embodiment, the computer device can obtain initial test cases from a first set of test cases. The first test cases are test cases obtained based on standard test suites. A standard test suite refers to a test suite written based on a syntax standard. In this embodiment, the computer device can pre-obtain standard test suites from the official website of the object under test or the official test case library corresponding to the object under test, and obtain the first test cases based on these obtained standard test suites.

[0033] In another embodiment, the computer device can obtain initial test cases from a second set of test cases. These second test cases are derived from historical vulnerability scripts. In this embodiment, the computer device can pre-collect historical scripts that have triggered defects or vulnerabilities in the object under test to obtain the second test cases.

[0034] Furthermore, considering the limited number of initial test cases collected through the above methods, in other embodiments, the computer device can also use a pre-trained neural network model to continue writing code based on test cases in the first or second test case set, resulting in a third test case set composed of multiple third test cases. During the code continuation process, the computer device can select a mutation point based on test cases in the first or second test case set, extract the code content from the initial test case up to the mutation point, input the extracted code content into the trained neural network model for code continuation, or use a model generated based on syntax standards for code continuation. The continuation code and the extracted code content are then concatenated to obtain the third test case set. Thus, the computer device can obtain any test case from the third test case set as an initial test case.

[0035] Step 204: Determine the mutation point based on the initial test cases, extract the code content from the initial test cases up to the mutation point, and continue writing code that conforms to the syntax standard based on the extracted code content to obtain the initial mutation test cases.

[0036] The mutation point can be the index number of a character in the initial test case, which can be used to determine the corresponding character in the test case. The code content up to the mutation point refers to the portion of code from the beginning of the initial test case to the character at the mutation point index. The selection of the mutation point can be random or according to a specific rule. For example, Table 3 shows a diagram illustrating the extraction of code content. Figure 3 Figure (a) in the diagram shows the initial test cases. Figure 3 In Figure (b), the mutation point selected is the index number corresponding to ")". Therefore, the extracted code content is the code content up to ")". Figure 3 As shown in Figure (c). A syntax standard is a document used to standardize the process of writing code for test cases. Syntax standards can be, for example, ECMAScript, ECMA-262, etc.

[0037] Specifically, the computer device can determine the mutation point based on the initial test cases, extract the code content up to the mutation point from the initial test cases, use the extracted code content as a prefix, and continue writing code that conforms to the syntax standard to obtain the initial mutation test cases.

[0038] In one embodiment, after intercepting the code content, the computer device can use the intercepted code content as a prefix and input it into a pre-trained neural network model. The pre-trained neural network model then rewrites the code to conform to the grammatical standards. The rewritten code and the intercepted code content are then concatenated to obtain the initial variant test case. The neural network model can be a text generation model, treating the code as text. During training, the neural network model learns information related to the grammatical standards in the code, such as code format, grammatical structure, encoding rules, and various API call relationships, thereby enabling it to rewrite the intercepted code content to conform to the grammatical standards.

[0039] In a specific embodiment, the neural network model used for the writing and continuation function can be a Generative Pre-Training (GPT) model, such as GPT-2. GPT-2 is a model based on the Transformer architecture. Unlike conventional recurrent neural networks, which suffer from long-range dependency problems and high costs, the Transformer architecture uses an attention mechanism, giving different levels of attention to different segments of the input sequence at each processing step. Compared to recurrent neural networks, the layers of the Transformer model are highly parallelizable, with lower computational costs and stronger feature extraction capabilities, and it performs exceptionally well in natural language processing. The training process of GPT-2 is divided into two stages: pre-training and fine-tuning. The pre-training stage involves unsupervised word prediction based on a large monolingual corpus to train a generative language model; the fine-tuning stage involves further fine-tuning the training on the target dataset. In this embodiment, a base model of GPT-2 with 117M parameters is used, and test cases used as training data are used as the fine-tuning dataset to update the weights of the last two fully connected layers of the pre-trained GPT-2 model. The training time is determined based on the quality of the generated samples, ultimately resulting in a generative model that matches the training data. It is understood that in other embodiments, LSTM (Long Short-Term Memory) or RNN (Recurrent Neural Network) can also be used as the neural network model for writing and continuing. This application does not limit the model structure used.

[0040] It should be noted that, to ensure the accuracy of the continuation, the training data used when training the neural network model is in the same format as the initial test cases. For example, if the initial test cases are complete executable files, the complete test cases can be used directly to train the neural network model. However, if the initial test cases are test cases containing only functions, then individual functions need to be extracted from the collected data to train the neural network model. When the training data is functions, because functions are more concise than complete test cases, the neural network model can better learn the syntax structure, encoding rules, and various API call relationships, thus the continuation code can better conform to the syntax standards.

[0041] In another embodiment, the computer device can obtain a template written based on a syntax standard, and based on the obtained template, continue writing code that conforms to the syntax standard based on the extracted code content.

[0042] In one embodiment, for the obtained initial test cases, the computer device can first test the object to be tested using the initial test cases. Only if the test result is an abnormal test result can the mutation point be determined from the initial test cases for mutation, so that the obtained target mutation test cases can improve testing efficiency and the probability of vulnerability discovery.

[0043] Step 206: Determine the target code content to be replaced from the initial test cases.

[0044] Step 208: In the initial mutation test cases, the code content whose structural attributes match the structural attributes of the target code content is determined as the replacement code content.

[0045] The target code content refers to the code content in the initial test case that needs to be replaced. To preserve the semantic information of the initial test case as much as possible, the target code content can be a portion of the code content in the initial test case. In one embodiment, the target code content can be a few code blocks in the initial test case. In other embodiments, the target code content can be one or more variable values ​​in the initial test case. Structural attributes are used to describe the syntactic structure represented by the code content in the test case.

[0046] Specifically, the computer device can determine the target code content to be replaced from the initial test cases. The code content in the initial variant test cases whose structural attributes are consistent with the structural attributes of the target code content is determined as the replacement code content. Since the structural attributes of the replacement code content are consistent with the structural attributes of the target code content, the structure of the initial test cases can be avoided to the greatest extent.

[0047] Step 210: Replace the target code content in the initial test case with the replacement code content to obtain the target variant test case. The target variant test case is used to test the object to be tested.

[0048] Specifically, after obtaining the replacement code content, the computer device can replace the target code content in the initial test case based on the replacement code content to obtain the target variant test case. The syntax structure of the obtained target variant test case matches the syntax structure of the initial test case.

[0049] In one embodiment, if there are multiple target code contents to be replaced identified from the initial test cases, there will also be multiple replacement code contents identified from the initial mutation test cases. When performing the replacement, the computer device replaces each target code content with replacement code content that matches the structural attributes of that target code content. For example, assuming the target code content includes a code block and multiple variable values, the replacement code content also includes a code block and multiple variable values. The computer device can replace the code block in the target code content with the code block in the replacement code content, and replace the variable values ​​in the target code content with the variable values ​​in the replacement code content.

[0050] Understandably, since target variant test cases are obtained by replacing the target code content in the initial test cases, their format is consistent with the initial test cases. That is, when the initial test case is a complete executable file, the resulting target variant test case is a complete test case; when the initial test case only contains a Function, the resulting target variant test case is a Function test case. Since directly executing the Function test case would result in a syntax error, when using the target variant test case to test the object under test, it is necessary to assemble the target variant test case. Specifically, this can involve adding variable declarations, function names, random passing of function parameters, function calls, and output of call results to the Function to form a complete test case. Random passing of function parameters increases the randomness and diversity of the test cases, while function calls and result output facilitate the analysis of test results.

[0051] In one embodiment, after obtaining the target variant test case, the computer device can use the target variant test case as the initial variant test case and iteratively execute steps 204 to 210 until the iteration stop condition is met, thereby obtaining multiple target variant test cases through multiple mutations, improving the utilization rate of the initial test case.

[0052] In the above test data processing method, initial test cases for the object under test are obtained, mutation points are determined based on the initial test cases, code content up to the mutation point in the initial test cases is extracted, and code conforming to the syntax standard is continued based on the extracted code content to obtain initial mutated test cases. The target code content to be replaced is determined from the initial test cases, and the code content in the initial mutated test cases whose structural attributes match the structural attributes of the target code content is determined as the replacement code content. The target code content in the initial test cases is replaced based on the replacement code content to obtain the target mutated test cases. Since the target mutated test cases are obtained by replacing the target code content in the initial test cases with the replacement code content, and the structural attributes of the replacement code content match the target code content, the target mutated test cases can retain as much semantic information as possible from the initial test cases, avoid destroying the structure of the initial test cases, and ensure syntactic correctness, thereby improving the accuracy of the mutated test cases.

[0053] In one embodiment, such as Figure 4 As shown, a test data processing method is provided, which includes the following steps:

[0054] Step 402: Obtain initial test cases for the object to be tested.

[0055] Step 404: Determine the mutation point based on the initial test cases, extract the code content from the initial test cases up to the mutation point, and continue writing code that conforms to the syntax standard based on the extracted code content to obtain the initial mutation test cases.

[0056] Step 406: In the initial test cases, the code block that is ranked before the sorting threshold among the code blocks that do not contain the extracted code content is identified as the target code content to be replaced.

[0057] In this context, a code block refers to the complete semantic representation of the first-level statements within a test case. For example, in the following Function, the second line is the first code block (hereinafter referred to as code block 1), the third, fourth, and fifth lines are a code block (hereinafter referred to as code block 2), and the sixth line is a code block (hereinafter referred to as code block 3). Although the fourth line is a complete semantic representation of code, it belongs to the second-level code and therefore cannot be divided as a separate code block.

[0058]

[0059] Code blocks that do not contain mutation points, i.e., code blocks in the initial use case consisting entirely of continued code, can be sorted according to their position. Code blocks closer to the mutation point are sorted first, with the first code block containing the first line of code that does not contain any truncated code. In the example above, assuming the first line of code is the mutation point, then code blocks 1, 2, and 3 are all code blocks that do not contain any truncated code, and their order is: code block 1, code block 2, code block 3.

[0060] Specifically, considering that the code blocks closer to the mutation point in the resulting code blocks have a greater correlation and semantic matching degree with the initial test case, this embodiment can identify the code blocks in the initial test case that do not contain mutation points and whose positions are ranked before a sorting threshold as target code blocks. These target code blocks are the target code content to be replaced. The sorting threshold can be set as needed; the smaller the sorting threshold, the greater the semantic matching degree between the replaced target mutation test case and the initial test case. For example, in the example above, assuming the first line of code is the mutation point and the sorting threshold is 3, code block 1 and code block 2 can be identified as target code blocks. Assuming the sorting threshold is 2, code block 1 can be identified as the target code block.

[0061] Step 408: Among the code blocks in the initial mutation test cases that do not contain the extracted code content, the code block that corresponds to the sorting position of the target code block is determined as the replacement code block corresponding to the target code block.

[0062] Specifically, the computer device can identify the code block in the initial mutation test case that does not contain truncated code content and whose sorting position is the same as that of the target code block as the replacement code block. In the example above, assuming code block 1 is the target code block, the code block that is ranked first among the code blocks in the initial mutation test case that does not contain truncated code content is the code block containing the first line of code that does not contain truncated code content, and this code block is the replacement code block.

[0063] Step 410: Replace the target code block in the initial test case with the corresponding replacement code block to obtain the target variant test case.

[0064] Among them, the target mutation test case is used to test the object to be tested.

[0065] To preserve as much semantic information as possible from the original test cases, in a specific embodiment, the first code block in the initial test case that does not contain the truncated code (i.e., the code block containing the first line of code that does not contain the truncated code) can be identified as the target code block. Similarly, the code block that replaces the first code block in the initial mutated test case that does not contain the truncated code is replaced with the first code block in the initial mutated test case. For example, suppose the initial test case is Function1, and Function1 is as follows:

[0066]

[0067] Suppose we identify the third line of code in Function1, "var props=[];", as the mutation point. Based on this mutation point, we continue writing the code, resulting in an initial mutation test case, Function2, as shown below:

[0068]

[0069] In Function1, the first line that does not contain the truncated code is the fourth line of the test case. Its code block consists of lines four and five. The first line of the resulting initial mutated test case, Function2, which also does not contain the truncated code, is the fourth line of the test case. Its code block consists of lines four, five, and six. The first code block in Function2 is replaced with the first code block in Function1. This replacement results in Function3, as shown below:

[0070]

[0071]

[0072] Considering that there may be multiple target code blocks, in one embodiment, for each target code block, the computer device determines the code block corresponding to each target code block position from the code blocks in the initial mutation test cases that do not contain the truncated code content, and obtains the corresponding replacement code block for each target code block. Then, the corresponding target code block in the initial test case is replaced with each replacement code block to obtain the target mutation test case. For example, assuming code block 1 and code block 2 are target code blocks, code block 1 in the initial test case is replaced with the replacement code block corresponding to code block 1, and code block 2 in the initial test case is replaced with the replacement code block corresponding to code block 2, resulting in the target mutation test case with the mutation point in the first line.

[0073] In this embodiment, the computer device divides the initial test cases and initial variant test cases into code blocks. After determining the target code block, the code block in the initial variant test case that does not contain a mutation point and corresponds to the position of the target code block can be identified as the replacement code block. Then, the target code block in the initial test case is replaced with the replacement code block. Since the replacement code block and the target code block correspond in position, the syntax structure of the initial test case can be avoided, and the syntax correctness of the target variant test case obtained by replacement can be guaranteed.

[0074] In one embodiment, determining mutation points based on initial test cases, extracting code content from the initial test cases up to the mutation points, and continuing to write grammatically compliant code based on the extracted code content to obtain initial mutation test cases, includes: traversing multiple lines of code content in the initial test cases, determining mutation points sequentially based on each traversed line of code content; extracting code content from the initial test cases up to each mutation point respectively, and continuing to write grammatically compliant code based on each extracted code content to obtain initial mutation test cases corresponding to each extracted code content.

[0075] Specifically, the computer device can traverse from the first line of code in the initial test case to the second-to-last line, identifying mutation points sequentially from each line. For example, a character can be randomly selected as a mutation point, or the last character of the traversed line can be used. Then, the code content up to each mutation point in the initial test case is extracted. Based on these extracted code contents, syntactically correct code is written to obtain initial mutated test cases corresponding to each extracted code content. These initial mutated test cases retain varying degrees of the code content from the initial test case. Furthermore, since the first to the second-to-last line are all used as mutation points, the utilization of the initial test case can be maximized, thereby generating as many target mutated test cases as possible.

[0076] Furthermore, the code blocks in the initial mutated test cases that do not contain the extracted code content, and whose sorting position corresponds to the target code block, are identified as the replacement code blocks corresponding to the target code block. This includes: for each initial mutated test case, identifying the code blocks in the initial mutated test case that do not contain the extracted code content, and whose position corresponds to the target code block, as the replacement code blocks corresponding to the target code block, resulting in multiple replacement code blocks corresponding to the target code block; replacing the target code block in the initial test case with the replacement code blocks corresponding to the target code block to obtain the target mutated test case, including: replacing the target code block in the initial test case with each of the replacement code blocks corresponding to the target code block, resulting in multiple target mutated test cases.

[0077] For example, suppose an initial test case contains 4 lines of code, and each line selects a mutation point. Traversing from the first line to the second-to-last line yields 3 mutation points. For each mutation point, the corresponding initial mutated test case can be obtained by continuing the code up to that mutation point. Thus, this initial test case can generate 3 initial mutated test cases: code content 1 is obtained by using the first line as the mutation point, and initial mutated test case 1 is obtained by continuing the code based on code content 1; code content 2 is obtained by using the second line as the mutation point, and initial mutated test case 2 is obtained by continuing the code based on code content 2; and so on. The code is used as a mutation point to extract code content 3. Based on code content 13, the initial mutation test case 3 is written. The replacement code block corresponding to the target code block position is determined from the code block that does not contain code content 1 in the initial mutation test case 1. The replacement code block corresponding to the target code block position is determined from the code block that does not contain code content 2 in the initial mutation test case 2. The replacement code block corresponding to the target code block position is determined from the code block that does not contain code content 3 in the initial mutation test case 3. Finally, the target code block in the initial test case is replaced with these three replacement code blocks to obtain three target mutation test cases.

[0078] In the above embodiments, by traversing multiple lines of code in the initial test case, multiple mutation points are obtained. Multiple target mutated test cases can be obtained based on multiple mutation points, thereby improving the utilization of the initial test case and thus obtaining as many target mutated test cases as possible.

[0079] In one embodiment, such as Figure 5 As shown, a test data processing method is provided, which includes the following steps:

[0080] Step 502: Obtain initial test cases for the object to be tested.

[0081] Step 504: Determine the mutation point based on the initial test cases, extract the code content from the initial test cases up to the mutation point, and continue writing code that conforms to the syntax standard based on the extracted code content to obtain the initial mutation test cases.

[0082] In one specific embodiment, considering that variable declarations are generally defined at the beginning of a function, randomly selecting a mutation point might lead to a position after the variable definition in the function body. In this case, the code continuation would not involve variable declarations again. Therefore, in this embodiment, the computer device can determine the last character of the first line of code in the initial test case as the mutation point and perform code continuation based on this mutation point. For example, assuming the initial test case is Function1 as mentioned above, an initial mutated test case obtained through continuation could be Function4, as shown below:

[0083]

[0084] Step 506: Identify at least one variable value in the initial test case as the target code content to be replaced.

[0085] Specifically, the computer device can determine one or more variable values ​​from the initial test case as the target code content to be replaced.

[0086] Step 508: Extract the variable values ​​from the initial mutated test cases to obtain a set of variable values, and select the target variable value from the set of variable values.

[0087] Step 510: Replace the variable values ​​in the target code content with the target variable values ​​to obtain the target variant test cases.

[0088] Among them, the target mutation test case is used to test the object to be tested.

[0089] Specifically, the computer device can extract all variable values ​​from the initial mutation test cases to obtain a set of variable values. This set is then stored in a variable list. From this list, a variable value matching the number of variable values ​​in the target code content can be randomly selected as the target variable value. This target variable value is then used to replace the variable values ​​in the target code content of the initial test cases, resulting in the target mutation test cases. For example, for Function4 above, the variables "array.length" defined in the second line and "len" defined in the third line are stored in a variable list. Values ​​from this list are randomly selected and used in different orders to replace the variable values ​​defined in the initial test case Function1. The resulting target mutation test cases can be seen in Functions 5 and 6. Wherein:

[0090] Function 5 is as follows:

[0091]

[0092] Function 6 is as follows:

[0093]

[0094]

[0095] In the above embodiments, by using variable values ​​as target code content, the variable values ​​in the initial test cases are replaced with the variable values ​​in the initial mutated test cases. The generated target mutated test cases can retain the semantic information and syntactic structure of the initial test cases to the greatest extent, thereby further improving the syntactic correctness of the target mutated test cases.

[0096] In one embodiment, determining mutation points based on initial test cases, extracting code content from the initial test cases up to the mutation point, and continuing to write grammatically compliant code based on the extracted code content to obtain initial mutation test cases includes: determining mutation points based on the first line of code in the initial test cases, extracting code content from the initial test cases up to the mutation point, and continuing to write grammatically compliant code multiple times based on the extracted code content to obtain multiple initial mutation test cases; extracting variable values ​​from the initial mutation test cases to obtain a set of variable values, and selecting target variable values ​​from the set of variable values ​​includes: extracting variable values ​​from multiple initial mutation test cases to obtain a set of variable values; combining the variable values ​​in the set of variable values ​​according to the number of variable values ​​contained in the target code content to obtain multiple replacement variable groups; and replacing the variable values ​​corresponding to the target code content with the variable values ​​in each replacement variable group in turn to obtain multiple target mutation test cases.

[0097] Specifically, see Figure 6 After acquiring initial test cases, the computer device evaluates them. If the initial test case does not contain variable definitions, the mutation process for that initial test case ends, and a new initial test case is acquired for evaluation. If the initial test case contains variable definitions, the last character of the first line of the initial test case is identified as the mutation point. The code content of the first line is then extracted and rewritten multiple times to obtain multiple initial mutation test cases. By using the first line as a prefix for rewriting, the parameter information of the initial test case can be obtained. When declaring variables, variables related to the parameters may be generated, strengthening the connection between the generated variables and the initial test cases. The computer device can extract all variable values ​​from these initial mutation test cases to obtain a variable value set. To avoid excessive combinations during subsequent variable value combinations, leading to excessively long mutation times, the computer device can further determine whether the number of variable values ​​in the variable value set is greater than the target number. If the number of variable values ​​is greater than the target number, the target number of variable values ​​are selected from the variable value set and stored in the variable list; otherwise, all variable values ​​in the variable value set are stored in the variable list.

[0098] On the other hand, the computer device can extract variable values ​​from the initial test cases, combine the variable values ​​in the variable list according to the number of variable values ​​in the initial test cases, and obtain multiple replacement variable groups. Then, the variable values ​​in each replacement variable group are used to sequentially replace the variable values ​​corresponding to the target code content, resulting in multiple target mutation test cases. The number of targets can be set as needed; for example, it could be 10.

[0099] In the above embodiments, by performing multiple code continuations to obtain multiple initial mutation test cases, and by arranging and combining the variable values ​​extracted from the initial mutation test cases to obtain multiple replacement variable groups, the utilization rate of the initial test cases can be improved, and as many target mutation test cases as possible can be obtained.

[0100] In one embodiment, such as Figure 7 As shown, a test data processing method is provided, referencing Figure 7 After receiving the initial test cases, the computer device first assesses them. If the initial test cases do not contain variable definitions, it directly proceeds to the code block replacement step: first, it identifies the mutation point in the initial test cases, extracts the code content up to the mutation point, and continues writing the code to obtain the initial mutated test case. This initial mutated test case is then used as the target mutated test case. The target code block in the initial test cases is then identified and replaced with the corresponding replacement code block in the initial mutated test case to obtain the target mutated test case. If the initial test cases contain variable definitions, the variable definition line remains unchanged, and the code block replacement step proceeds: the line following the variable definition is used as the mutation point to continue writing the code to obtain the initial mutated test case. The target code block in the initial test cases is then replaced with the corresponding replacement code block in the initial mutated test case. Finally, the code block remains unchanged, and the variable is replaced to obtain the target mutated test case. For details on the code block replacement steps, please refer to the section above. Figure 4 For a description and specific steps on replacing variables, please refer to the section above. Figure 5 The description of the subject matter is not repeated here.

[0101] In one embodiment, determining mutation points based on initial test cases includes: testing the object under test based on the initial test cases to obtain test results corresponding to the initial test cases; if the test results are abnormal test results, determining mutation points from the initial test cases; if the test results are normal test results, re-acquiring test cases different from the initial test cases, determining the re-acquiring test cases as the initial test cases, and continuing execution in the step of testing the object under test based on the initial test cases.

[0102] In this embodiment, a test case that differs from the initial test case refers to a test case that is not the same as the initial test case. After obtaining the initial test case, the computer device can enter the testing process, use the initial test case to test the object under test, obtain the test results corresponding to the initial test case, and determine whether the test result is a normal test result or an abnormal test result. If the test result is an abnormal test result, it indicates that the code block corresponding to the initial test case in the object under test is abnormal, and is very likely to be a code block that is prone to vulnerabilities or defects. Then, the computer device can determine the mutation point from the initial test case to execute subsequent mutation steps to obtain the target mutation test case. Then, the object under test can be continuously tested through the target mutation test case, thereby improving the code coverage during the testing process and increasing the probability of vulnerability discovery during the testing process.

[0103] If the test result is normal, it indicates that the code block corresponding to the initial test case in the object under test is likely correct. The computer can then filter this initial test case, acquire a new test case that differs from the initial one, and designate this new test case as the initial test case. The process then continues, proceeding to test the object under test based on the initial test case. To avoid this step looping infinitely, a stopping condition can be set as needed, such as the loop time reaching a preset time or the number of loops reaching a preset number.

[0104] Understandably, in one embodiment, when the initial test case is a test case that only contains a Function, the Function needs to be assembled first to obtain a complete test case before the object to be tested can be tested.

[0105] In the above embodiments, when the mutation point is determined based on the initial test cases, the test process can be entered to test the object to be tested. On the one hand, the test cases to be tested can be continuously tested. On the other hand, the test results can be used to filter out test cases with correct code, so that the test process is directed to code modules that are prone to exceptions, thereby improving test efficiency and the probability of vulnerability discovery.

[0106] In one embodiment, testing the object to be tested based on the initial test cases to obtain the test results corresponding to the initial test cases includes: testing multiple different versions of the test objects based on the initial test cases to obtain the test results corresponding to each object to be tested; if the test results corresponding to each object to be tested are consistent, the test result of the initial test cases is determined to be a normal test result; if the test results corresponding to each object to be tested are inconsistent, the test result of the initial test cases is determined to be an abnormal test result.

[0107] Specifically, computer equipment can test multiple different versions of test objects based on initial test cases, obtain test results for each test object, and compare these test results. If the test results for each test object are consistent, the test result of the initial test case is a normal test result. If the test results of one or more test objects are inconsistent with the test results of other test objects, it indicates that there may be defects or vulnerabilities in the test object. In this case, the computer equipment can determine that the test result of the initial test case is an abnormal test result, which can then be mutated to obtain more target mutated test cases. This allows for continuous testing of the test object, thereby guiding the testing towards code modules that are prone to vulnerabilities or defects.

[0108] In the above embodiments, by comparing the differentiated behaviors of multiple different versions of the test object for the same initial test case, it is possible to accurately and quickly determine whether the initial test case is an abnormal test case, thereby improving testing efficiency and the probability of vulnerability discovery.

[0109] In one embodiment, the test data processing method further includes: obtaining a first preset mutation rule; mutating an initial test case based on the first preset mutation rule to obtain a first rule-mutated test case, the first rule-mutated test case being used to test the object to be tested.

[0110] The first preset mutation rule is obtained based on prior knowledge of the target, which is derived from summarizing historical vulnerability information, which consists of use cases or scripts that have historically triggered vulnerabilities. In this embodiment, the computer device can use one or more first preset mutation rules to mutate the initial test cases, obtaining first rule-mutated test cases, which can then be used to test the object under test.

[0111] In one embodiment, the computer device can test the initial test cases and obtain test results. Only when the test results are abnormal test results will the step of mutating the initial test cases based on the first preset mutation rule be executed to obtain the first rule mutated test cases, thereby filtering out the correct test cases and improving testing efficiency.

[0112] In one embodiment, a computer device can generate a syntax tree for initial test cases, traverse each node in the syntax tree, and perform corresponding mutation operations on nodes that conform to a first preset mutation rule. The mutation operations include at least one of modifying a node, adding a node, deleting a node, and replacing a node.

[0113] In the above embodiments, since the first preset mutation rule is based on prior knowledge summarized from use cases that have historically triggered vulnerabilities, this mutation strategy is more targeted and can conduct continuous and intensive testing on potentially defective modules, thereby increasing the probability of vulnerability discovery. The first preset mutation rule will be illustrated below with several examples.

[0114] In one embodiment, mutating the initial test case based on a first preset mutation rule includes: obtaining a plurality of pre-set application interface pairs; the application interface pair includes two semantically matching application interfaces; when the initial test case includes any one of the application interfaces in the application interface pair, the included application interface is replaced with the other application interface in the application interface pair.

[0115] Considering that semantically similar APIs (Application Programming Interfaces) often call the same underlying code modules during implementation by developers, replacing these APIs can guide variations to the same code modules, resulting in a more comprehensive testing engine. Computer devices can obtain multiple pre-set API pairs, each containing two semantically matching APIs. The APIs in the initial test cases are compared with the APIs involved in these API pairs. If the initial test case includes any API from a pair, that API is replaced with the other API from the pair.

[0116] In one specific embodiment, the pre-defined multiple application programming interface pairs include one or more of the following program interface pairs:

[0117] RegExp.prototype.exec and RegExp.prototype.test, RegExp.prototype[@@match] and String.prototype.match, RegExp.prototype[@@matchAll] and String.prototype.matchAll, Re gExp.prototype[@@search] and String.prototype.search, RegExp.prototype[@@replace] and String.prototype.replace, RegExp.prototype[@@split] and String.prototype.split.

[0118] For example, if the pre-defined application interface pairs include RegExp.prototype.exec and RegExp.prototype.test, then when the initial test case includes RegExp.prototype.exec, RegExp.prototype.exec can be replaced with RegExp.prototype.test.

[0119] In one embodiment, considering that replacing APIs with the same return value can ensure the syntactic correctness of test cases, and that APIs with the same return value have diverse forms, thus increasing the scope of testing, the pre-set multiple application interface pairs obtained by the computer device can also include interface pairs that include two application interfaces with the same return value. For example, String() and Object.prototype.toString() and String.prototype.substring, etc. Similarly, the computer device can compare the application interfaces in the initial test cases with the application interfaces involved in these application interface pairs. If the initial test case includes any application interface from the application interface pair, the included application interface is replaced with the other application interface from the application interface pair.

[0120] In one embodiment, mutating an initial test case based on a first preset mutation rule includes: identifying instance objects in the initial test case; and for at least one identified instance object, modifying the prototype chain attribute of the instance object to pollute the instance object's prototype chain.

[0121] Prototype chain pollution is a type of vulnerability that occurs when modifying the `__proto__` property of an instance object alters the object's prototype chain properties, causing pollution. In this embodiment, the computer device can analyze the syntax tree corresponding to the initial test case, identify the `Object` instance in the initial test case, and modify the prototype chain properties of the `Object` instance using `__proto__` and `Object.setPrototypeOf`.

[0122] For example, suppose part of the code for the initial test case looks like this:

[0123]

[0124] After modifying the prototype chain property corresponding to the instance object, the following is a partial code snippet of the first rule mutation test case:

[0125]

[0126] As can be seen, the prototype chain property was modified by adding the line "c.__proto__.foo='G';" in the first rule mutation test case, which allows testing for prototype chain pollution vulnerability types.

[0127] In one embodiment, mutating the initial test case based on a first preset mutation rule includes: identifying arrays in the initial test case; for at least one identified array, modifying the array's length attribute to either a boundary value or a target value, wherein the target value is a value greater than a preset value threshold.

[0128] Integer overflow is another type of vulnerability. It occurs when the system calculates the size of the allocated space too small, placing data into a storage space smaller than its actual size, resulting in an overflow. This type of vulnerability often exists in array operations. For example, when JavaScript performs array expansion operations, the function first calculates the length of the output array, and then the program allocates space and initializes it. However, the calculated array length is unknown, and no boundary checks are performed during execution, making overflow highly likely. Therefore, in this embodiment, the computer device can analyze the syntax tree corresponding to the initial test cases to identify the array definition, and then use getters / setters, `__defineGetter__(prop,func)`, and `__defineSetter__(prop,func)` to modify the array-related properties in the test cases. This primarily involves modifying the length to some boundary values ​​or target values. The target value is a value greater than a preset threshold value, which can be set as needed.

[0129] For example, suppose part of the code for the initial test case looks like this:

[0130]

[0131]

[0132] After modifying the array's length attribute, the first rule mutation example is shown below:

[0133]

[0134] In the example above, the length of the array is modified to -4294967295 by using o.__defineGetter__(0,function(o.length=-4294967295;)) to test for integer overflow vulnerabilities.

[0135] In one embodiment, mutating the initial test case based on a first preset mutation rule includes: identifying functions in the initial test case; and for at least one identified function, adding a preset number of loop calls to the function, where the preset number of calls is greater than a preset threshold number.

[0136] Specifically, to improve performance, some test objects have adopted a Just-In-Time (JIT) mechanism. This mechanism dynamically compiles JavaScript code into machine code at runtime for functions that are called multiple times consecutively within a short period, instead of using a traditional interpreter, thus improving execution speed. However, due to imperfections in the implementation, such as incomplete type checking between normal compilation and JIT execution, this part also contains numerous vulnerabilities. In this embodiment, functions in the test cases are identified based on the syntax tree corresponding to the initial test cases. Then, a loop is added to each function, performing the loop a preset number of times to trigger JIT optimization and discover related issues. The preset number of loops can be set as needed, for example, 1000 times.

[0137] For example, suppose part of the code for the initial test case looks like this:

[0138]

[0139]

[0140] The first rule mutation example obtained by identifying the function is shown below (partial code):

[0141]

[0142] As can be seen in the example above, the function func() identified in the initial test case was called 1000 times in a loop, which allows for testing of JIT-type vulnerabilities.

[0143] In one embodiment, the above method further includes:

[0144] Specifically, the computer device can mutate the initial test cases according to the second preset mutation rule to obtain the second rule mutated test cases, and then test the object to be tested using the second rule mutated test cases. The first preset mutation rule will be illustrated with several embodiments below.

[0145] In one embodiment, the computer device can replace operators in the initial test cases with operators having the same number of operands. Specifically, the computer device can determine the nodes in the code based on the syntax tree corresponding to the initial test cases. If a node is an operator node, it is replaced, and the replacement occurs among operators with the same number of operands. Operator nodes include, but are not limited to, arithmetic operators BinaryExpression and UpdateExpression, assignment operators AssignmentExpression, comparison operators BinaryExpression, logical operators LogicalExpression and UnaryExpression, and conditional operators ConditionalExpression. For example, addition (+) is a binary arithmetic operator that accepts only two operands, as is multiplication (*). Therefore, addition and multiplication can be replaced; for example, 1+3 becomes 1*3.

[0146] In one embodiment, conditional statements in the initial test cases are replaced with semantically matching conditional statements. Specifically, the computer device can pre-set mutually replaceable and semantically matching conditional statements. The nodes in the initial test cases are matched against the syntax tree of the initial test cases. If a pre-set conditional statement is matched, it is replaced with a semantically matching conditional statement. For example, the conditions in a while statement and an if statement without else are both Boolean values. Their syntactic structures are highly similar, but their semantic similarity is low. If, when matching these two types of nodes against the syntax tree of the initial test cases, one conditional statement is successfully matched, it can be replaced with the other conditional statement, forming a new syntax tree.

[0147] In one embodiment, a code block other than variable declarations is randomly removed from the initial test case. Specifically, after parsing the initial test case into a syntax tree, the computer device may randomly select a node other than variable declarations within the function body for deletion.

[0148] In one embodiment, a code block is randomly selected from the initial test cases, and a conditional statement is used to wrap the selected code block. Specifically, considering that wrapping a random code block in the initial test cases with a conditional statement can change the control flow of the initial test cases while ensuring the correctness of the syntax of the mutated test cases, adding certain variations, and that the insertion of an infinite loop can cause certain memory and optimization issues, in this embodiment, after the computer device parses the initial test cases into a syntax tree, it can randomly select a code block, insert a conditional while node (WhileStatement) before this node, and then insert this node into the body node of the WhileStatement as its loop body.

[0149] In one embodiment, code is added to the initial test case. Specifically, code addition mainly includes two methods: one is live code addition, where the computer device can add some code related to the test case to the initial test case, thereby changing the data flow and control flow of the initial test case; the other is dead code addition, the main purpose of which is to test the optimization problem of the object under test. The computer device can add code that is completely unrelated to the initial test case or code that is related to the initial test case but does not affect the final execution result.

[0150] In the above embodiments, the initial test cases are mutated according to the second preset mutation rule, which can quickly generate a large number of second rule mutated test cases and improve testing efficiency.

[0151] In one specific embodiment, this application also provides an application scenario where the test data processing method of this application is applied to test a JavaScript engine (hereinafter referred to as the JS engine) to test the security, functionality, and optimization issues of the JavaScript engine. In this embodiment, an initial test case seed pool is created by collecting JavaScript scripts containing historical triggers of JS engine defects or vulnerabilities, along with the official JS engine test suite. Deep learning technology is used to expand the initial test case seed pool. Based on prior knowledge of JavaScript vulnerability types and guided mutation rules combined with general test case mutation methods, test cases that produce abnormal test results during differential testing are targeted for mutation to generate guided test cases. This allows for high-intensity, continuous testing of code modules in the JS engine that are prone to defects or vulnerabilities. Compared to traditional testing methods, the test data processing method provided in this embodiment, while ensuring the effectiveness and diversity of test cases, can also guide testing towards code modules prone to defects or vulnerabilities, thereby improving testing efficiency and the probability of vulnerability discovery.

[0152] like Figure 8The diagram shown is an overall flowchart of the test data processing method provided in this embodiment. It can be divided into four modules: data collection and preprocessing module, test case initial seed pool expansion module, differential testing module, and iterative mutation module based on abnormal behavior. The functions of each module are as follows:

[0153] Data collection and preprocessing module: This module mainly collects two parts of data: one part is JavaScript programs collected from open source code repositories for training test case generation models; the other part is initial test scripts collected from various JavaScript engine test suites and vulnerability databases for building an initial test case seed pool.

[0154] Test Case Initial Seed Pool Expansion Module: The number of official test suites for each engine and JavaScript scripts that historically trigger JS engine defects or vulnerabilities is limited initially. The mutation generation method in the mutation module is used to expand the data, thereby increasing the amount and diversity of data in the seed pool.

[0155] Differential Testing Module: This module performs differential testing on test cases in the seed pool across multiple vendors' JS engines, saves and compares the test results, filters and marks test cases with abnormal results, and performs manual analysis and confirmation on these test cases.

[0156] The iterative mutation module based on abnormal behavior: This module generates new test cases based on test cases with abnormal results, using guided mutation rules and adds them to the seed pool. It then continues iterative testing using these newly generated test cases until no more abnormal behavior occurs. The next round of testing will randomly select a test case from the seed pool.

[0157] The following is the specific implementation process for each module:

[0158] 1. Data Collection and Preprocessing Module

[0159] This module first crawls a large number of JavaScript projects from GitHub based on the number of favorites. Then, it obtains engine test suites from the official websites of various JavaScript engines and the official test case library TEST262 for JavaScript engines, and collects JavaScript scripts that historically triggered JavaScript engine defects or vulnerabilities from the CVE website. Then, it retrieves these two parts of data, iterates through and retains the JavaScript scripts, and then extracts the scripts by function through data preprocessing. The first part of the data is used as model training data, and the second part of the data is used as the raw data for the initial test case seed pool.

[0160] 1.1 Acquisition of Model Training Data

[0161] This module uses the Transformer-based natural language generation model GPT-2, an unsupervised deep learning model. Using this model to generate code is essentially treating the code as text, allowing the model to generate new text based on the text format of the code in the training data and the interface calls. Therefore, it is necessary to ensure that the training data format is correct and the content is extensive.

[0162] GitHub is the world's largest open-source social coding and code hosting website, boasting a wide variety of fully functional open-source code repositories. It can be categorized by the language of the project source code. In this embodiment, the JavaScript category is selected based on GitHub's language classification. Then, these projects are sorted by the number of stars, and the top 4000 actual engineering projects are selected as the initial data for model training. After data preprocessing, these projects are divided into individual functions, which are then used as training data for model fine-tuning.

[0163] 1.2 Obtaining the raw data for the initial test case seed pool

[0164] If GPT-2 is used alone for test cases, the generated test cases are too random, which can easily lead to testing of code modules unrelated to defects or vulnerabilities, reducing testing efficiency. Existing research has confirmed that continuously testing engine code modules covered by test cases that have already triggered code bugs (faults or defects) is highly likely to trigger engine bugs again. Therefore, this embodiment makes full use of JavaScript scripts that have historically triggered JS engine defects or vulnerabilities, as well as official test cases from major engines, to build an initial test case seed pool. Then, the data is preprocessed into Functions with the same data format as the generation model. A test case generation model trained based on deep learning is used to generate and mutate the Functions to increase the amount of data in the seed pool and enrich its code content.

[0165] 1.3 Data Preprocessing

[0166] To ensure the learning effectiveness of the language model and facilitate subsequent testing and analysis, this module processes the raw training data collected from GitHub into independent functions. This module primarily uses three tools: Esprima, a high-performance, standards-compliant ECMAScript parser used for lexical or syntactic analysis of JS code; JSHint, a commonly used JS code style checker offering nearly 60 optional configurations with high flexibility; and UglifyJS, a practical tool integrating a JS interpreter, code minimization, code compression, and code beautification. First, all JavaScript projects are traversed, and JavaScript files are extracted. If a file has more than 1000 lines, functions are extracted using regular expressions; otherwise, Esprima is used to generate a syntax tree, and functions are extracted based on the syntax tree. After extracting functions, variable backfilling is performed to ensure that the function body retains the information from the original file and that no undefined variables appear. After obtaining complete functions, JSHint is used to perform syntax filtering to ensure the validity of the training data. To further improve the quality of the dataset, valid test cases are deduplicated, decommented, and filtered using rules manually formulated based on the characteristics of the dataset. Finally, UglifyJS is used to unify the code format, and the results are stored in the database for later use.

[0167] The model training data is used to fine-tune the test case generation model GPT-2, and the original data in the initial test case seed pool is used to expand the test case seed pool.

[0168] 1.4 Model Training

[0169] The training process of GPT-2 is divided into two stages: pre-training and fine-tuning. The pre-training stage involves unsupervised word prediction based on a large monolingual corpus to train a generative language model. The fine-tuning stage involves further fine-tuning the training on the target dataset. In this embodiment, a base model of GPT-2 with 117M parameters is used. Preprocessed JS code is used as the fine-tuning dataset to update the weights of the last two fully connected layers of the pre-trained GPT-2 model. The training duration is determined based on the quality of the generated samples, ultimately resulting in a generative model that matches the training data.

[0170] 2. Test Case Initial Seed Pool Expansion Module

[0171] Fuzz testing requires a sufficient amount of data to ensure the comprehensiveness of the test scope and the effectiveness of the test results. Obtaining official test suites from various JavaScript engine websites and collecting historical JavaScript scripts that trigger JS engine defects or vulnerabilities from the CVE website, even after data preprocessing, yields a relatively small amount, insufficient to meet the requirements of fuzz testing. Therefore, data expansion is necessary. Manual data expansion is time-consuming, labor-intensive, and requires significant manpower. A finely tuned and trained GPT-2 model, with excellent JavaScript coding capabilities, can replace manual expansion. The functions extracted from the initial test case seed pool are mutated to expand the size of the test case seed pool. The specific mutation process is detailed in section 4.2.

[0172] 3. Differential Testing Module

[0173] 3.1 Test Case Assembly

[0174] For functions extracted from the original file, direct execution using the engine results in syntax errors; therefore, a complete test case assembly is required first. For each extracted function, add variable declarations, function names, randomized parameter passing, function calls, and output of the call results to form a complete test case. Randomized parameter passing increases the randomness and diversity of the test cases, while function calls and output facilitate comparison of differential results from different engines.

[0175] For the random passing of function parameters, the number of parameters is determined according to the parameter definition in the AST. Each parameter is randomly selected from one of the seven basic types in JavaScript (Object, Boolean, Number, String, Array, null, undefined) and passed. Each test case is assembled ten times.

[0176] 3.2 Differential Test

[0177] Differential testing technology can automatically infer potentially faulty engines by comparing the differentiated behavior of multiple compilers for the same test case. Through test case simplification and error localization, it minimizes the need for manual intervention. If the execution result of one compiler is inconsistent with the results of other engines, it is very likely to contain a bug. After screening, the following eight engines were selected for differential testing (see Table 1). During installation, the JavaScript engine installation and update tool jsvu was used, which can easily install the latest versions of various JavaScript engines without compiling from source code.

[0178] Table 1

[0179] ID Test object Version 1 V8 v9.9.1 2 SpiderMonkey JavaScript-C96.0 3 ChakraCore v1.11.24.0 4 JavaScriptCore v286936 5 QuickJS v2021-03-27 6 JerryScript v3.0.0 (fea10bb7) 7 Gralljs v21.3.0

[0180] The initial test cases in the seed pool are subjected to differential testing one by one, compiled and executed on all engines. The execution results are then voted on, and test cases whose results differ from those of the majority of engines are marked as suspicious test cases (i.e., test cases with abnormal results). These test cases, along with their corresponding source functions, test results, and other relevant information, are stored in a suspicious test case database. Suspicious test cases undergo iterative mutation based on their abnormal behavior after being marked. The mutated test cases are then re-entered into the differential testing module for a loop. Furthermore, test cases with abnormal results require manual analysis. Combining the execution results from each engine with the differential test results, and adhering to the ECMA-262 standard, a step-by-step analysis is performed to determine whether the suspicious test case is a false positive or a bug. If it is determined to be a bug, an issue needs to be submitted to the corresponding engine developer for confirmation.

[0181] 4. Iterative mutation module based on abnormal behavior

[0182] 4.1 Generating Mutations

[0183] Generative mutation refers to using a fine-tuned GPT-2 model to supplement and extend the test cases of a Function, transforming an incomplete Function into a complete Function. There are three main methods for generative mutation:

[0184] 1) Direct code continuation

[0185] Determine the initial test cases, identify mutation points based on the code content from the first line to the second-to-last line of each initial test case, extract the code content from the initial test cases up to each mutation point, and continue writing grammatically correct code based on each extracted code content. Concatenate each extracted code content with its corresponding continuation code to obtain the initial mutation test cases corresponding to each extracted code content. The computer device can use the initial mutation test cases as target mutation test cases.

[0186] The initial test cases can be selected from the initial test case seed pool or from test cases with abnormal test results obtained from the differential test module.

[0187] 2) Replace code block

[0188] The code block containing the first line of code in the initial test case that does not contain the truncated code content is identified as the target code block. For each initial mutated test case, the code block containing the first line of code in the initial mutated test case that does not contain its corresponding truncated code content is identified as the replacement code block. The target code blocks in the initial test cases are replaced with the respective replacement code blocks to obtain multiple target mutated test cases.

[0189] 3) Replace variables

[0190] At least one variable value in the initial test case is identified as the target code content to be replaced. The last character of the first line of code in the initial test case is identified as the mutation point. The code content in the initial test case up to the mutation point is extracted. Based on the extracted code content, code conforming to the syntax standard is written multiple times to obtain multiple initial mutation test cases. Variable values ​​are extracted from multiple initial mutation test cases to obtain a variable value set. The variable values ​​in the variable value set are combined according to the number of variable values ​​contained in the target code content to obtain multiple replacement variable groups. The variable values ​​in each replacement variable group are used to replace the variable values ​​corresponding to the target code content in turn to obtain multiple target mutation test cases.

[0191] After the target variant test cases obtained by the above three methods are assembled into complete test cases through test case assembly, they can be added to the initial test case seed pool to expand the initial test case seed pool.

[0192] 4.2 Regular Variation

[0193] Rule-based mutation involves performing secondary mutations on test cases that produce abnormal test results in the differential testing module. This generates a large number of test cases with similar code content, increasing the testing scope for the module that triggers the problem. Unlike generating mutations where the mutated object is a function, rule-based mutation mutates pre-assembled, complete test cases.

[0194] The mutation process utilizes Esprima (a JavaScript parsing tool), Estraverse (an AST node traversal tool), and Escodegen (an AST source code generation tool) to implement mutation rules. The main steps are: first, use Esprima to parse the source code into an AST; then, use Estraverse to traverse and match nodes according to the mutation rules; finally, perform corresponding operations on the nodes, such as adding or replacing nodes; and finally, use Escodegen to generate JS source code from the AST, thus completing the entire mutation process. When replacing AST nodes, the main steps are: initializing AST nodes, parsing the input file into an AST, matching whether the AST contains replaceable method nodes, selecting the corresponding node for replacement if found, and saving the original node's corresponding method and variable names; finally, replacing the corresponding method and variable names in the replaced node. When adding AST nodes, the main steps are: initializing AST nodes, parsing the input file into an AST, matching the parent node of the node to be added, saving the variable names, function names, and the position of the node's parent node; then, adding the node after the matched node, and finally replacing the corresponding variable and function names.

[0195] 4.2.1 Regular Mutation Tool

[0196] 1. Esprima

[0197] Esprima is a high-performance, standards-compliant ECMAScript parser used for lexical or syntactic analysis of JavaScript code. It is currently one of the most widely used JavaScript syntax parsing tools. This tool features: full support for ECMAScript 2016; a well-structured syntax tree with optional monitoring of syntax node positions; rigorous experimental testing; and JSX support. Esprima primarily provides two APIs: parseScript and parseModule, which can be selected based on whether the code contains import / export statements. After being parsed by Esprima, the JavaScript code forms a properly formatted syntax tree, allowing for subsequent modifications to test cases at the syntax tree level.

[0198] 2. Estraverse

[0199] Estraverse is a widely used JavaScript syntax tree traversal tool, often used in conjunction with Esprima to traverse syntax trees. Estraverse includes two APIs: estraverse.traverse and estraverse.replace. estraverse.traverse is mainly used for node traversal, while estraverse.replace is mainly used for node replacement.

[0200] 3. Escodegen

[0201] Escodegen (escodegen) is a JavaScript syntax tree generator from Mozilla. Its main function is to reverse engineer the JavaScript source code from the parsed JavaScript syntax tree using `escodegen.generate`. Escodegen can be used in a browser or installed via npm.

[0202] 4.2.2 Main Contents of Rule Variation

[0203] Rule mutations mainly fall into two categories: one is general rule mutations applicable to most test cases (i.e., the second preset mutation rule mentioned above), which includes some commonly used mutation methods; the other is dedicated mutation rules obtained by summarizing historical vulnerability information (i.e., the first preset mutation rule mentioned above), which perform targeted mutations on test cases.

[0204] 1. General Mutation Rules. General mutation rules include one or more of the following rules:

[0205] 1) Replace the operators in the initial test cases with operators that have the same number of operands;

[0206] 2) Replace the conditional statements in the initial test cases with conditional statements that semantically match them;

[0207] 3) Randomly remove one code block from the initial test cases, excluding variable declarations;

[0208] 4) Randomly select a code block from the initial test cases and wrap the selected code block with a statement that is true;

[0209] 5) Add code to the initial test cases.

[0210] For details, please refer to the description of the above embodiments; this application will not repeat them here.

[0211] 2. Specific variation rules. Specific variation rules include one or more of the following rules:

[0212] 1) Obtain multiple pre-set application interface pairs; the application interface pair includes two semantically matching application interfaces or two application interfaces with the same return value; when the initial test case includes any one of the application interfaces in the application interface pair, replace the included application interface with the other application interface in the application interface pair.

[0213] 2) Identify instance objects in the initial test cases; for at least one identified instance object, modify the prototype chain property of the instance object to pollute the prototype chain of the instance object.

[0214] 3) Identify arrays in the initial test cases; for at least one identified array, modify the array's length attribute to either a boundary value or a target value, where the target value is a value greater than a preset threshold value.

[0215] 4) Identify functions in the initial test cases; for at least one identified function, add a preset number of loop calls to the function, where the preset number of calls is greater than a preset threshold.

[0216] For details, please refer to the description in the above embodiments; this application will not repeat them here.

[0217] 4.3 Iterative Differential Test

[0218] Test cases generated through both generative mutation and rule-based mutation require further differential testing. Generative mutation-generated test cases are classified as Functions and require test case assembly in section 3.1 before entering the differential testing module. Test cases generated through rule-based mutation can be tested directly. After differential testing, test cases that produce abnormal results, along with related execution information, are saved. These test cases then re-enter the "Iterative Mutation Module Based on Abnormal Behavior," thus achieving continuous iterative differential testing.

[0219] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0220] Based on the same inventive concept, this application also provides a test data processing apparatus for implementing the test data processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more test data processing apparatus embodiments provided below can be found in the limitations of the test data processing method described above, and will not be repeated here.

[0221] In one embodiment, such as Figure 9 As shown, a test data processing device 900 is provided, comprising:

[0222] Initial test case acquisition module 902 is used to acquire initial test cases for the object to be tested;

[0223] The code continuation module 904 is used to determine the mutation point based on the initial test case, extract the code content in the initial test case up to the mutation point, and continue writing code that conforms to the syntax standard based on the extracted code content to obtain the initial mutation test case.

[0224] The target code determination module 906 is used to determine the target code content to be replaced from the initial test cases;

[0225] The replacement code determination module 908 is used to determine the code content in the initial mutation test case whose structural attributes match the structural attributes of the target code content as the replacement code content;

[0226] The code replacement module 910 is used to replace the target code content in the initial test case based on the replacement code content, so as to obtain the target mutated test case. The target mutated test case is used to test the object to be tested.

[0227] The aforementioned test data processing device acquires initial test cases for the object under test, determines mutation points based on these initial test cases, extracts code content from the initial test cases up to the mutation points, and continues writing syntactically correct code based on the extracted code content to obtain initial mutated test cases. It then determines the target code content to be replaced from the initial test cases, identifies the code content in the initial mutated test cases whose structural attributes match those of the target code content as replacement code content, and replaces the target code content in the initial test cases based on the replacement code content to obtain target mutated test cases. Since the target mutated test cases are obtained by replacing the target code content in the initial test cases with replacement code content, and the replacement code content matches the structural attributes of the target code content, the target mutated test cases can retain as much semantic information as possible from the initial test cases, avoid disrupting the structure of the initial test cases, and ensure syntactic correctness, thereby improving the accuracy of the mutated test cases.

[0228] In one embodiment, the target code determination module is further configured to determine the target code block whose position in the code block that does not contain the truncated code content in the initial test case is before the sorting threshold as the target code content to be replaced; the replacement code determination module is further configured to determine the code block whose sorting position in the code block that does not contain the truncated code content in the initial mutation test case is corresponding to the target code block as the replacement code block corresponding to the target code block; the code replacement module is further configured to replace the target code block in the initial test case with the replacement code block corresponding to the target code block to obtain the target mutation test case.

[0229] In one embodiment, the code continuation module is further configured to traverse multiple lines of code in the initial test case, determine mutation points sequentially based on each traversed line of code, extract the code content in the initial test case up to each mutation point, and continuate the code content in accordance with the syntax standard based on each extracted code content to obtain the initial mutated test case corresponding to each extracted code content; the code replacement determination module is further configured to, for each initial mutated test case, determine the code block corresponding to the position of the target code block in the code block in the initial mutated test case that does not contain its corresponding extracted code content as the replacement code block corresponding to the target code block, to obtain multiple replacement code blocks corresponding to the target code block; the code replacement module is further configured to replace the target code block in the initial test case with each of the replacement code blocks corresponding to the target code block, to obtain multiple target mutated test cases.

[0230] In one embodiment, the target code determination module is further configured to determine at least one variable value in the initial test case as the target code content to be replaced; the replacement code determination module is further configured to extract the variable values ​​in the initial mutated test case to obtain a set of variable values, and select the target variable value from the set of variable values; the code replacement module is further configured to replace the variable value in the target code content with the target variable value to obtain the target mutated test case.

[0231] In one embodiment, the code continuation module is further configured to determine the mutation point based on the first line of code of the initial test case, extract the code content of the initial test case up to the mutation point, and repeatedly continuate the code content in accordance with the syntax standard to obtain multiple initial mutation test cases; the code replacement determination module is further configured to extract variable values ​​from the multiple initial mutation test cases to obtain a variable value set; combine the variable values ​​in the variable value set according to the number of variable values ​​contained in the target code content to obtain multiple replacement variable groups; the code replacement module is further configured to replace the variable values ​​corresponding to the target code content with the variable values ​​in each replacement variable group in turn to obtain multiple target mutation test cases.

[0232] In one embodiment, the code continuation module is further configured to: test the object to be tested based on the initial test cases and obtain the test results corresponding to the initial test cases; if the test results are abnormal test results, determine the mutation point from the initial test cases; if the test results are normal test results, re-acquire test cases that are different from the initial test cases, determine the re-acquired test cases as the initial test cases, and continue execution by proceeding to the step of testing the object to be tested based on the initial test cases.

[0233] In one embodiment, the code continuation module is further configured to: test multiple different versions of the test object based on the initial test case, and obtain the test results corresponding to each test object; if the test results corresponding to each test object are consistent, determine that the test result of the initial test case is a normal test result; if the test results corresponding to each test object are inconsistent, determine that the test result of the initial test case is an abnormal test result.

[0234] In one embodiment, the above apparatus further includes: a first rule mutation module, configured to obtain a first preset mutation rule, the first preset mutation rule being obtained based on target prior knowledge, the target prior knowledge being obtained based on historical vulnerability information; and to mutate an initial test case based on the first preset mutation rule to obtain a first rule mutated test case, the first rule mutated test case being used to test the object to be tested.

[0235] In one embodiment, the first rule mutation module is further configured to obtain a plurality of pre-set application interface pairs; the application interface pair includes two semantically matching application interfaces or two application interfaces with the same return value; when the initial test case includes any one of the application interfaces in the application interface pair, the included application interface is replaced with the other application interface in the application interface pair.

[0236] In one embodiment, the first rule mutation module is further configured to identify instance objects in the initial test case; and for at least one identified instance object, modify the prototype chain property of the instance object to pollute the instance object's prototype chain.

[0237] In one embodiment, the first rule mutation module is further configured to identify arrays in the initial test cases; for at least one identified array, the length attribute of the array is modified to either a boundary value or a target value, wherein the target value is a value greater than a preset value threshold.

[0238] In one embodiment, the first rule mutation module is further configured to identify functions in the initial test cases; for at least one identified function, the function is added to a preset number of loop calls, the preset number being greater than a preset threshold number.

[0239] In one embodiment, the apparatus further includes: a first rule mutation module, configured to mutate the initial test case according to a second preset mutation rule to obtain a second rule-mutated test case, the second rule-mutated test case being used to test the object to be tested; the second preset mutation rule includes at least one of the following: replacing operators in the initial test case with operators of the same number as the number of operands; replacing conditional statements in the initial test case with conditional statements that match its semantics; randomly deleting a code block other than variable declarations from the initial test case; randomly selecting a code block from the initial test case and wrapping the selected code block with a statement that is true; and adding code to the initial test case.

[0240] In one embodiment, the initial test case includes at least one of a first test case, a second test case, or a third test case; wherein the first test case is a test case obtained based on a standard test suite, the second test case is a test case obtained based on a historical vulnerability script, and the third test case is obtained by continuing the code based on the first or second test case.

[0241] Each module in the aforementioned test data processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0242] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores test case data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a test data processing method.

[0243] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a test data processing method. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0244] Those skilled in the art will understand that Figure 10 and Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0245] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the test data processing method described above.

[0246] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the test data processing method described above.

[0247] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the test data processing method described above.

[0248] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0249] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0250] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0251] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A test data processing method, characterized by, The method comprises: acquiring an initial test case for a to-be-tested object; determining a mutation point based on the initial test case, intercepting code content in the initial test case up to the mutation point, continuously writing code meeting a syntax standard based on the intercepted code content, splicing the continuously written code and the intercepted code content to obtain a plurality of initial mutation test cases, determining at least one variable value in the initial test case as target code content to be replaced, extracting variable values from the plurality of initial mutation test cases to obtain a variable value set, combining variable values in the variable value set according to a number of variable values contained in the target code content to obtain a plurality of replacement variable groups, and replacing variable values corresponding to the target code content with variable values in each replacement variable group in turn to obtain a plurality of target mutation test cases, which are used for testing the to-be-tested object; or determining a mutation point based on the initial test case, intercepting code content in the initial test case up to the mutation point, continuously writing code meeting a syntax standard based on the intercepted code content, splicing the continuously written code and the intercepted code content to obtain an initial mutation test case, determining a target code block in a code block not containing the intercepted code content in the initial test case and located before a sorting threshold as target code content to be replaced, determining a code block corresponding to the target code block in the initial mutation test case as a replacement code block corresponding to the target code block, and replacing the target code block in the initial test case with the replacement code block corresponding to the target code block to obtain a target mutation test case, which is used for testing the to-be-tested object.

2. The method of claim 1, wherein, The method of determining a mutation point based on the initial test case, intercepting code content in the initial test case up to the mutation point, continuously writing code meeting a syntax standard based on the intercepted code content, splicing the continuously written code and the intercepted code content to obtain an initial mutation test case comprises: traversing a plurality of lines of code content in the initial test case, and determining a mutation point based on each line of code content traversed in turn; intercepting code content in the initial test case up to each mutation point in turn, continuously writing code meeting a syntax standard based on each intercepted code content, and splicing the continuously written code and the corresponding intercepted code content to obtain an initial mutation test case corresponding to each intercepted code content; The method of determining a code block corresponding to the target code block in the initial mutation test case as a replacement code block corresponding to the target code block comprises: For each initial mutation case, a code block corresponding to a position of the target code block in a code block not containing corresponding intercepted code content in the initial mutation case is determined as a replacement code block corresponding to the target code block, to obtain a plurality of replacement code blocks corresponding to the target code block; The replacing the target code block in the initial test case with the replacement code block corresponding to the target code block to obtain a target mutation case comprises: Respectively replacing the target code block in the initial test case with each replacement code block corresponding to the target code block to obtain a plurality of target mutation cases.

3. The method of claim 1, wherein, The determining a mutation point based on the initial test case comprises: Determining a mutation point based on first line code content of the initial test case.

4. The method of claim 1, wherein, The determining a mutation point based on the initial test case comprises: Testing the to-be-tested object based on the initial test case to obtain a test result corresponding to the initial test case; In a case where the test result is an abnormal test result, determining a mutation point from the initial test case; In a case where the test result is a normal test result, reacquiring a test case different from the initial test case, determining the reacquired test case as an initial test case, and continuing to execute the step of testing the to-be-tested object based on the initial test case.

5. The method of claim 4, wherein, The testing the to-be-tested object based on the initial test case to obtain a test result corresponding to the initial test case comprises: Testing a plurality of different versions of to-be-tested objects based on the initial test case to obtain a test result corresponding to each to-be-tested object respectively; In a case where the test results corresponding to the to-be-tested objects are consistent, determining that a test result of the initial test case is a normal test result; In a case where the test results corresponding to the to-be-tested objects are inconsistent, determining that a test result of the initial test case is an abnormal test result.

6. The method of claim 1, wherein, The method further comprises: Acquiring a first preset mutation rule, the first preset mutation rule being obtained based on target prior knowledge, the target prior knowledge being obtained based on historical vulnerability information; Mutating the initial test case based on the first preset mutation rule to obtain a first rule mutation case, the first rule mutation case being used for testing the to-be-tested object.

7. The method of claim 6, wherein, The mutating the initial test case based on the first preset mutation rule comprises: Acquiring a plurality of application program interface pairs pre-set, the application program interface pairs including two application program interfaces with matched semantics or including two application program interfaces with consistent return values; When the initial test case includes any one application program interface in the application program interface pair, replacing the included application program interface with another application program interface in the application program interface pair.

8. The method of claim 6, wherein, The mutating the initial test case based on the first preset mutation rule comprises: Identifying an instance object in the initial test case; For the identified at least one instance object, modify the prototype chain attribute of the instance object to perform prototype chain pollution on the instance object.

9. The method of claim 6, wherein, The variation of the initial test case based on the first preset variation rule comprises: Identify an array in the initial test case; For the identified at least one array, modify the length attribute of the array to one of a boundary value or a target value, the target value being a value greater than a preset value threshold.

10. The method of claim 6, wherein, The variation of the initial test case based on the first preset variation rule comprises: Identify a function in the initial test case; For the identified at least one function, add a preset number of loop calls to the function, the preset number being greater than a preset number threshold.

11. The method of claim 1, wherein, The method further comprises: Variation of the initial test case according to a second preset variation rule to obtain a second rule variation case, the second rule variation case being used for testing the to-be-tested object; The second preset variation rule comprises at least one of: Replacing an operator in the initial test case with an operator consistent in number of operation objects; Replacing a conditional statement in the initial test case with a conditional statement matching in semantics; Randomly deleting a code block other than a variable declaration from the initial test case; Randomly selecting a code block from the initial test case and wrapping the selected code block with a statement with a true condition; Adding code in the initial test case.

12. The method according to any one of claims 1 to 11, characterized in that, The initial test case comprises at least one of a first test case, a second test case, or a third test case; The first test case is a test case obtained based on a standard test suite, the second test case is a test case obtained based on a historical vulnerability script, and the third test case is obtained based on code continuation of the first test case or the second test case.

13. A test data processing apparatus, characterized by comprising: The device comprises: An initial case acquisition module configured to acquire an initial test case for a to-be-tested object; A code continuation module configured to determine a mutation point based on the initial test case, intercept code content of the initial test case up to the mutation point, continuously write code conforming to a syntax standard based on the intercepted code content, splice each time of continuously written code with the intercepted code content to obtain a plurality of initial variation cases; a target code determination module configured to determine at least one variable value in the initial test case as target code content to be replaced; a replacement code determination module configured to extract variable values from the plurality of initial variation cases to obtain a variable value set; combine variable values in the variable value set according to a number of variable values contained in the target code content to obtain a plurality of replacement variable groups; and a code replacement module configured to replace variable values corresponding to the target code content with variable values in each replacement variable group in turn to obtain a plurality of target variation cases, the plurality of target variation cases being used for testing the to-be-tested object; or The code continuation module is configured to determine a mutation point based on the initial test case, intercept code content of the initial test case up to the mutation point, continue writing code meeting a syntax standard based on the intercepted code content, splice the continued code and the intercepted code content to obtain an initial variation case; the target code determination module is configured to determine a target code block in the initial test case as target code content to be replaced, the target code block being located before a sorting threshold in a position sorting; the replacement code determination module is configured to determine a code block corresponding to the target code block in the initial variation case as a replacement code block corresponding to the target code block; and the code replacement module is configured to replace the target code block in the initial test case with the replacement code block corresponding to the target code block to obtain a target variation case, the target variation case being used to test the object to be tested.

14. The apparatus of claim 13, wherein, The code continuation module is further configured to traverse multiple lines of code content in the initial test case, determine a mutation point based on each line of the code content, intercept code content of the initial test case up to each of the mutation points, continue writing code meeting a syntax standard based on each of the intercepted code contents, and splice the continued code and the corresponding intercepted code content to obtain an initial variation case corresponding to each of the intercepted code contents. The replacement code determination module is further configured to, for each initial variation case, determine a code block corresponding to the target code block in the initial variation case as a replacement code block corresponding to the target code block, to obtain multiple replacement code blocks corresponding to the target code block. The code replacement module is further configured to replace the target code block in the initial test case with each of the replacement code blocks corresponding to the target code block to obtain multiple target variation cases.

15. The apparatus of claim 13, wherein, The code continuation module is further configured to determine a mutation point based on a first line of code content of the initial test case.

16. The apparatus of claim 13, wherein, The code continuation module is further configured to test the object to be tested based on the initial test case to obtain a test result corresponding to the initial test case, determine a mutation point from the initial test case in a case where the test result is an abnormal test result. In a case where the test result is a normal test result, a test case different from the initial test case is reacquired, the reacquired test case is determined as an initial test case, and the step of testing the object to be tested based on the initial test case is continued to be executed.

17. The apparatus of claim 16, wherein, The code continuation module is further configured to test multiple different versions of the object to be tested based on the initial test case to obtain a test result corresponding to each of the objects to be tested, and determine a test result of the initial test case as a normal test result in a case where the test results corresponding to the objects to be tested are consistent. In a case where test results of respective to-be-tested objects are inconsistent, the test result of the initial test case is determined as an abnormal test result.

18. The apparatus of claim 13, wherein, The apparatus further includes a first rule variation module configured to: obtain a first preset variation rule, the first preset variation rule being obtained based on target prior knowledge, the target prior knowledge being obtained based on historical vulnerability information; and vary the initial test case based on the first preset variation rule to obtain a first rule variation case, the first rule variation case being configured to test the to-be-tested object.

19. The apparatus of claim 18, wherein, The first rule variation module is further configured to: obtain a plurality of application program interface pairs that are pre-set, the application program interface pairs including two application program interfaces that are semantically matched or two application program interfaces that return consistent values; and replace an included application program interface with another application program interface in the application program interface pairs in a case where the initial test case includes any one of the application program interface pairs.

20. The apparatus of claim 18, wherein, The first rule variation module is further configured to: identify an instance object in the initial test case; and modify a prototype chain attribute of the identified instance object to contaminate the instance object with a prototype chain in a case where at least one instance object is identified.

21. The apparatus of claim 18, wherein, The first rule variation module is further configured to: identify an array in the initial test case; and modify a length attribute of the identified array to one of a boundary value or a target value in a case where at least one array is identified, the target value being a value greater than a preset value threshold.

22. The apparatus of claim 18, wherein, The first rule variation module is further configured to: identify a function in the initial test case; and add a preset number of loop calls to the identified function in a case where at least one function is identified, the preset number being greater than a preset number threshold.

23. The apparatus of claim 13, wherein, The apparatus further includes a second rule variation module configured to: vary the initial test case based on a second preset variation rule to obtain a second rule variation case, the second rule variation case being configured to test the to-be-tested object; and the second preset variation rule including at least one of the following: replace an operator in the initial test case with an operator that is consistent in number with an operation object; replace a conditional statement in the initial test case with a conditional statement that is semantically matched; randomly delete a code block other than a variable declaration from the initial test case; randomly select a code block from the initial test case and wrap the selected code block with a statement that is true; add a code to the initial test case.

24. The apparatus of any one of claims 13 to 23, wherein, The initial test case includes at least one of a first test case, a second test case, or a third test case; The first test case is a test case obtained based on a standard test suite, the second test case is a test case obtained based on a historical vulnerability script, and the third test case is a test case obtained based on code continuation of the first test case or the second test case. 25.A computer device, comprising a memory and a processor, wherein the memory stores a computer program. The processor, when executing the computer program, implements the steps of the method of any one of claims 1 to 12.

26. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, which when executed by a processor, implements the steps of the method of any one of claims 1 to 12.

27. A computer program product comprising a computer program, characterised in that, The computer program, which when executed by a processor, implements the steps of the method of any one of claims 1 to 12.

Images