An artificial intelligence-based software test case automatic generation system and method

Abstract

The application provides an artificial intelligence-based software test case automatic generation system and method, relates to the technical field of software testing, and comprises the following modules: a project management data acquisition module that collects code metadata and project management data; a dynamic risk weight allocation module that inputs the two types of data into a risk prediction model, outputs a risk heat map, and allocates the dynamic risk weight of the input parameters; a basic test suite generation module that generates a basic test suite according to the input parameters and the dynamic risk weight; and a software test algorithm execution module that starts a software test algorithm and iteratively evolves to generate a test case set. The application solves the technical problem that the existing software test case generation mode is difficult to effectively integrate software related data to identify high-risk links, and the generated test cases are insufficient in covering key areas and low in accuracy, achieves the technical effect of accurately identifying high-risk links of software, and the generated test cases are more targeted, thereby improving software testing efficiency and software quality evaluation accuracy.

Description

Technical Field

[0001] This application relates to the field of software testing technology, specifically to an artificial intelligence-based automatic software test case generation system and method. Background Technology

[0002] Software test case generation is crucial for ensuring software quality and improving development efficiency, with data processing being a key supporting link. Current technologies often rely on manual design or simple rules for test case generation, and data processing is largely limited to basic input parameter analysis, failing to effectively integrate code and project-related data. However, in complex software version testing, traditional data processing methods struggle to uncover information about high-risk code modules, resulting in inaccurate test case coverage, omissions of high-risk areas, and low data processing efficiency. This fails to meet the accuracy and efficiency requirements of software testing, and cannot support accurate software quality assessment and effective control. Summary of the Invention

[0003] This application provides an AI-based automatic software test case generation system and method, which solves the technical problems of existing software test case generation methods that are difficult to effectively integrate software-related data to identify high-risk links, and generate test cases with insufficient coverage of key areas and low accuracy. It achieves accurate identification of high-risk links in software, generates more targeted test cases, and improves the technical effects of improving software testing efficiency and the accuracy of software quality assessment.

[0004] In view of the above problems, this application provides an artificial intelligence-based automatic software test case generation system. The system includes: a project management data acquisition module, used to collect code metadata of the software version under test and obtain related project management data from the project management system; a dynamic risk weight allocation module, used to input the code metadata and project management data into a pre-trained risk prediction model, output a risk heatmap for identifying high-risk code modules and functions, and assign dynamic risk weights to the software's input parameters; a basic test suite generation module, used to generate a basic test suite based on the input parameters and the dynamic risk weights, using combined test design rules; and a software test algorithm execution module, used to start a search-based software test algorithm with the basic test suite as the initial population, wherein the fitness function of the software test algorithm is composed of the code coverage index and the dynamic risk weights, and generates a risk-oriented test case set through iterative evolution.

[0005] On the other hand, this application also provides an artificial intelligence-based method for automatically generating software test cases. The method includes: collecting code metadata of the software version under test and obtaining associated project management data from a project management system; inputting the code metadata and project management data into a pre-trained risk prediction model, outputting a risk heatmap for identifying high-risk code modules and functions, and assigning dynamic risk weights to the software's input parameters; generating a basic test suite based on the input parameters and the dynamic risk weights using combined test design rules; and starting a search-based software testing algorithm using the basic test suite as an initial population, wherein the fitness function of the software testing algorithm is composed of a code coverage index and the dynamic risk weights, and generating a risk-oriented test case set through iterative evolution.

[0006] One or more technical solutions provided in this application have at least the following technical effects:

[0007] The project management data acquisition module collects code metadata of the software version under test and retrieves related project management data from the project management system to construct a basic software testing dataset. The dynamic risk weight allocation module inputs this basic dataset into a pre-trained gradient boosting decision tree risk prediction model, outputs a risk heatmap identifying high-risk code modules and functions, and assigns dynamic risk weights to the input parameters based on the frequency and depth of their use in high-risk areas. The basic test suite generation module, based on the possible value set of the input parameters and the dynamic risk weights, first uses a pairwise combination test design method to generate basic test cases covering all pairwise combinations of parameters, then identifies the top N high-risk parameters with risk weights greater than a preset threshold, and generates supplementary test cases with their complete value combinations, integrating them to form a complete basic test suite. The software testing algorithm execution module uses this basic test suite as the initial population to launch a search-based software testing algorithm. Its fitness function is composed of code coverage metrics and dynamic risk weights, and it generates a risk-oriented test case set through iterative evolution.

[0008] In summary, this application collects code metadata and associated project management data of the software version under test, processes it through a pre-trained risk prediction model to obtain high-risk code modules, function identifiers, and dynamic risk weights of software input parameters, generates a basic test suite, and then uses it as the initial population to launch a search-based software testing algorithm. By combining code coverage and dynamic risk weights for iterative evolution, a risk-oriented test case set is generated. It can also improve the test case verification logic and realize parallel execution and result analysis, making the generation of software test cases more accurate and efficient, and supporting the accurate assessment and control of software quality.

[0009] The above description is merely an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the structure of an AI-based automatic software test case generation system provided in an embodiment of this application.

[0012] Figure 2 This is a flowchart illustrating an artificial intelligence-based method for automatically generating software test cases, as provided in an embodiment of this application.

[0013] Figure labeling: Project management data acquisition module 10, dynamic risk weight allocation module 20, basic test suite generation module 30, software test algorithm execution module 40. Detailed Implementation

[0014] This application provides an AI-based automatic software test case generation system and method, which solves the technical problems of existing software test case generation methods that are difficult to effectively integrate software-related data to identify high-risk links, and the generated test cases have insufficient coverage of key areas and low accuracy.

[0015] Example 1, as Figure 1 As shown in the figure, this application provides an artificial intelligence-based automatic software test case generation system, the system comprising:

[0016] The project management data acquisition module 10 is used to collect code metadata of the software version under test, and at the same time obtain related project management data from the project management system.

[0017] In this embodiment, the software version under test refers to a specific version in the software development process that is in the testing phase and whose functional integrity, stability, and security are to be verified, such as a beta version generated after iterative development or a candidate version before deployment. The project management system is a tool platform used to coordinate the entire software project process, recording and managing data such as the priority of software project requirements, historical defects, and code submitter information.

[0018] Specifically, firstly, when collecting code metadata for the software version under test, those skilled in the art can use version control systems (such as Git and SVN) and static code analysis tools. First, using the command-line tool of the version control system, such as Git's `git clone` command, the code repository of the software version under test is cloned to the local machine. Then, the `git log` command is used to filter out code commit records related to that version, counting the number of code commits within a specified time range to obtain the code change frequency. Next, a static code analysis tool, such as PMD (Programming Mistake Detector), is invoked, taking the code files of the software under test as input. This tool automatically traverses the code structure, analyzing the number of control flow statements such as branches and loops in the code to calculate the cyclomatic complexity of each function and module, while also counting the total number of lines in each code file. Finally, structured data containing code cyclomatic complexity, code change frequency, and code line count is exported, completing the collection of code metadata.

[0019] Next, when retrieving associated project management data from the project management system, we utilize the open APIs provided by existing project management systems such as Jira and ZenTao. First, we locate the project corresponding to the version of the software under test within the project management system and generate an API key with data read permissions through the system backend. Then, using the curl command of an HTTP request tool, we construct a request link containing the API key and the required data types, including feature priority, historical defect density, and code submitter experience level, according to the API documentation format of the project management system, and send a data retrieval request to the system. Upon receiving the request, the project management system returns the corresponding structured data in JSON format. Then, using data parsing scripts familiar to those skilled in the art, such as Python's json module, we extract the feature priority from the priority field of the requirement module; historical defect density is calculated by dividing the number of closed defects in the project by the total number of lines of code in the software under test; and code submitter experience level is determined by classifying submitters into three levels—basic, proficient, and senior—based on their past participation in the project and the number of code submissions. This completes the retrieval of the project management data.

[0020] By leveraging existing and widely used version control tools, static code analysis tools, project management system APIs, and basic data processing tools, the collection of metadata of the software version code and related project management data under test is completed step by step. This achieves the effect of simply and efficiently obtaining two types of core data and providing complete input for subsequent risk prediction models.

[0021] The dynamic risk weight allocation module 20 is used to input the code metadata and project management data into the pre-trained risk prediction model, output a risk heatmap for identifying high-risk code modules and functions, and allocate dynamic risk weights to the software's input parameters.

[0022] Specifically, training samples are first extracted from historical data of version control systems and project management systems. Each sample contains code metadata, project management data, and risk probability labels for code modules. Then, a risk prediction model is generated by training the samples using a gradient boosting decision tree. Subsequently, the risk prediction model is used to analyze the code metadata and project management data of the software under test, marking code modules and functions with risk probabilities exceeding a preset threshold as high-risk areas and generating corresponding risk heatmaps. Finally, all input parameters of the software under test are identified, and their correlation with high-risk areas is analyzed. Based on the correlation, quantitative weights are assigned to each input parameter to obtain dynamic risk weights.

[0023] The basic test suite generation module 30 generates a basic test suite based on the input parameters and the dynamic risk weights, using combined test design rules.

[0024] Specifically, based on input parameters and dynamic risk weights, the basic test suite is generated using combined test design rules: on the one hand, all input parameters of the test software are analyzed to clarify the possible value set corresponding to each input parameter; on the other hand, based on the value set obtained above, a basic test suite that can cover the pairwise combinations of all parameters is generated using pairwise combined test design methods.

[0025] The software testing algorithm execution module 40 is used to start a search-based software testing algorithm with the basic test suite as the initial population. The fitness function of the software testing algorithm is composed of the code coverage index and the dynamic risk weight, and generates a risk-oriented test case set through iterative evolution.

[0026] Specifically, firstly, the basic test suite is converted into an initial population recognizable by the genetic algorithm. Each test case in the basic test suite contains multiple combinations of input parameter values, which are broken down into gene fragments. Each input parameter value corresponds to a gene. For example, a test case of an order amount of 100 + payment method WeChat Pay can be broken down into a gene sequence of [100, WeChat Pay]. Using Python's list structure, the gene sequences of all test cases are integrated into an initial population list, where each list element represents an individual, i.e., a test case, allowing the genetic algorithm to directly perform subsequent optimization operations on the population.

[0027] Next, a fitness function is constructed, consisting of code coverage metrics and dynamic risk weights:

[0028] In small-scale software or simple testing scenarios, code coverage metrics can be achieved through manual tracking and statistics: When executing a single test case, simultaneously compare it with the source code of the software under test, check and mark the lines of code that are actually executed during the execution of the test case. Non-executable lines of code such as comments and blank lines are not included in the marking and statistics. For example, mark them as executed with specific symbols in the source code file. After the test case is executed, count the number of marked valid lines of code and compare it with the total number of valid lines of code in the software under test. When obtaining the total number of valid lines of code and the number of lines of valid code executed, non-executable lines such as comments and blank lines must be excluded. Divide the number of valid lines of code executed by the total number of valid lines of code to obtain the coverage value in the range of 0-1.

[0029] In large-scale software or complex testing scenarios, the code coverage tool JaCoCo can be used to obtain coverage data for each test case: the test case is executed on the software under test, JaCoCo automatically traces the code execution path, generates a coverage report, and extracts the proportion of the effective lines of code covered by the test case to the total number of lines of code in the software under test, resulting in a coverage value in the range of 0-1.

[0030] Next, the dynamic risk weight score is calculated: All input parameters and their corresponding dynamic risk weights for each test case are statistically analyzed, and the average of these weights is taken. For example, if a test case contains two input parameters with weights of 0.8 and 0.6, the average value is 0.7. Finally, the weights of the code coverage metric and the dynamic risk weight are set to 0.5 each, which facilitates calculation and balances the influence of both. The fitness score is quantified using the formula: Fitness Score = Code Coverage Value × 0.5 + Weight Score × 0.5. A higher score indicates that the test case better meets the requirements of broad coverage and strong risk orientation.

[0031] Next, the selection operation of the genetic algorithm is performed to select parent individuals. The roulette wheel selection method, familiar to those skilled in the art, is used, implemented through Python's DEAP library (an open-source genetic algorithm tool library). First, the sum of the fitness scores of all individuals in the initial population is calculated. Then, a selection probability is assigned to each individual, i.e., individual fitness score / sum. Individuals with higher probabilities are more likely to be selected. For example, if the fitness scores of three individuals in the initial population are 0.8, 0.6, and 0.5, with a sum of 1.9, the corresponding selection probabilities are approximately 0.42, 0.32, and 0.26. Random numbers are generated using the `selRoulette` function of the DEAP library, and individuals are selected from the population according to probability. This results in a parent set of the same size as the original population, ensuring that test cases with high fitness are more likely to enter the subsequent optimization stage.

[0032] Next, offspring individuals are generated through crossover operations to combine the advantages of the parents. A single-point crossover method is used. First, the DEAP library's `random` module randomly pairs parent individuals; for example, the first parent [100, WeChat Pay] is paired with the second parent [5000, Alipay Pay]. Then, a crossover point is randomly selected, for example, after the first gene. The gene fragments after the crossover point are exchanged, resulting in the first offspring [100, Alipay Pay] and the second offspring [5000, WeChat Pay]. The crossover operation generates new parameter value combinations through gene fragment exchange, expanding the coverage of test cases. Furthermore, the DEAP library's `cxOnePoint` function can directly implement this operation, reducing the development difficulty for those skilled in the art.

[0033] Subsequently, mutation operations are performed to introduce new mutations, with a focus on optimizing high-risk parameters. First, a base mutation probability of 0.05 is set, an industry-standard value to avoid excessive mutation. Then, for high-risk parameters with dynamic risk weights greater than a preset weight threshold of 0.6, the mutation probability of their corresponding gene fragments is increased to 0.2, prioritizing the adjustment of high-risk parameter values. For example, order amount is a high-risk parameter with a weight of 0.8, greater than the preset weight threshold of 0.6, so its gene fragment mutation probability is 0.2; user ID is a low-risk parameter with a weight of 0.3, so its mutation probability is 0.05. Using the `mutUniformInt` function from the DEAP library, a random number between 0 and 1 is generated for each gene fragment. If the number is less than the corresponding mutation probability, a new value is randomly selected from the parameter's value set to replace the original gene. For example, order amount 100 is mutated to order amount -10, thereby increasing the diversity of high-risk parameter values ​​and making it easier to generate test cases that can detect defects in high-risk areas.

[0034] Finally, after completing one selection, crossover, and mutation cycle, a new generation of the population is obtained. The iteration termination condition is then determined, for example, by setting 50 iterations or a change in the average fitness score of the population over five consecutive generations of less than 0.01. If not, the above operations are repeated based on the new generation of the population. If the condition is met, test cases with the top 80% fitness scores are selected from the final population to form a risk-oriented test case set. The entire iteration process can be controlled using a Python for loop, and the logging module is used to record the average fitness of each generation, monitoring the optimization progress in real time and ensuring the traceability of the iteration effect.

[0035] By transforming the basic test suite into an initial population of a genetic algorithm, constructing a fitness function that combines code coverage and dynamic risk weights, performing selection, crossover, and mutation operations, and iteratively optimizing, the system achieves the effect of efficiently generating a risk-oriented test case set that covers a wide range of areas and can focus on high-risk areas of the software.

[0036] In one possible implementation, the project management data acquisition module 10 further includes:

[0037] The code metadata includes code cyclomatic complexity, code change frequency, and lines of code; the project management data includes the functional priority of related requirements, historical defect density, and the experience level of the code contributor.

[0038] Specifically, code cyclomatic complexity is a technical indicator that measures the complexity of code logic. It is mainly calculated by counting the number of control flow statements such as branches, loops, and conditional statements in the code. Its purpose is to provide a basis for judgment for subsequent pre-trained risk prediction models. The more complex the logic of a code module, the higher the probability of logical vulnerabilities or defects. This indicator can be used to initially identify high-risk logical areas in the code, laying the foundation for subsequent location of high-risk code modules.

[0039] Code change frequency refers to the number of times a code module or function is modified or committed within a certain time frame, such as within a project iteration cycle. Its purpose is to reflect the stability of the code: the more frequently the code changes, the more temporary adjustments or feature iterations there may be, and the greater the possibility of introducing new defects. This indicator can help risk prediction models judge the dynamic risks of code modules and avoid overlooking potential problems caused by frequent changes.

[0040] Lines of code is an indicator of the number of valid lines of code in a code file or module that do not contain comments or blank lines. Its purpose is to reflect the size of the code module: the more lines of code a module has, the richer the functional logic it usually contains, and the more potential defects it may have. This indicator can be used as a reference for risk prediction models to judge the basic risk of a code module and help to initially classify the risk levels of code modules of different sizes.

[0041] The functional priority of related requirements refers to the importance level set for the software requirements corresponding to the code modules, such as core functions, secondary functions, and auxiliary functions. Its purpose is to clarify the testing focus: if a high-priority function has a defect, it will have a greater impact on the overall operation of the software or the user experience. This data can enable the risk prediction model to tilt towards the code modules related to the core functions when judging risks, ensuring that the code corresponding to the key functions receives key attention.

[0042] Historical defect density refers to the ratio of the number of defects discovered in a code module during past testing or use to the size of the module's code (usually based on the number of lines of code). Its purpose is to provide a historical risk reference: a module with a high historical defect density indicates that the code module may have inherent problems in its design or implementation, and the probability of new defects appearing in the future is also higher. This indicator can significantly improve the accuracy of risk prediction models in locating high-risk modules.

[0043] The experience level of a code submitter is assessed based on dimensions such as the number of code submissions, the defect rate of submitted code, and the efficiency of problem-solving. For example, it is categorized as basic, proficient, and senior. Its role is to supplement the indirect judgment of code quality: submitters with relatively less experience may have deficiencies in code writing standards and logical completeness, and the risk of their submitted code introducing defects is relatively higher. Combining this data can make the risk prediction model more comprehensive in judging code risks and avoid ignoring potential risks brought about by human factors.

[0044] In one possible implementation, the dynamic risk weight allocation module 20 further includes:

[0045] The training sample acquisition unit is used to extract training samples from historical data of the version control system and project management system, where each sample contains code metadata, project management data, and a label indicating the risk probability of the code module; the risk prediction model construction unit is used to train the training samples using a gradient boosting decision tree to generate the risk prediction model; the risk heatmap generation unit is used to analyze the code metadata and project management data through the risk prediction model, mark code modules and functions with risk probability values ​​higher than a preset threshold as high-risk areas, and generate the risk heatmap; the dynamic risk weight acquisition unit is used to identify all input parameters of the software under test, analyze the correlation between each input parameter and the high-risk areas, and assign a quantified weight to each input parameter based on the correlation to obtain the dynamic risk weight.

[0046] In this embodiment of the application, the version control system is a tool used to manage software code versions, record code modification history, including changes, modification time, committer, support team collaborative development, and track information such as code change frequency. Common examples include Git and SVN.

[0047] Specifically, when extracting training samples, existing version control systems like Git and project management systems like Jira can be used to acquire data. First, using Git's command-line tools, the historical commit records of the software under test are obtained by executing corresponding operations to view code commit history and change statistics. From these, historical code metadata for each code module is extracted, including past cyclomatic complexity, code change frequency, and line count. Simultaneously, Jira's open API is used to call data query interfaces to obtain historical defect records for the software project, filtering out defect information associated with each code module. Next, the risk probability label for each code module is calculated: the number of times a defect occurred in the code module over multiple iterations is counted, divided by the total number of iterations, resulting in a risk probability between 0 and 1. For example, if a code module has 3 defects in 6 iterations, the risk probability is 0.5. Finally, the historical code metadata, historical project management data, and corresponding risk probability labels for each code module are combined to form the training sample set.

[0048] Next, a risk prediction model is constructed and trained using a gradient boosting decision tree. The specific steps are as follows: First, the training sample set is preprocessed: For missing feature values, such as the lack of historical defect density data for individual code modules, mean imputation is used to supplement the missing features by using the mean defect density of similar code modules; for non-numerical features, such as the experience level of the code submitter, a label encoding method is used to map basic, proficient, and senior to 1, 2, and 3, respectively.

[0049] The preprocessed training sample set was then divided into training and test sets in a 7:3 ratio. Model parameters were set with a learning rate of 0.1, a tree depth of 3, and 100 iterations. These are commonly used industry parameters, easy to debug, and provide stable results. Model training was then initiated, using code metadata from the training set (including historical code cyclomatic complexity, change frequency, and line count) and project management data (including historical feature priority, historical defect density, and submitter experience level) as input features. Risk probability labels were used as the output target. The model parameters were iteratively optimized to minimize the error between the model's predicted risk probability and the actual risk probability label. After training, the model accuracy was verified using the test set, ensuring the prediction error was below 10%. Finally, a usable risk prediction model was generated. The input to this model is the code metadata and project management data of the code module to be analyzed, and the output is the risk probability value between 0 and 1 for that module.

[0050] Next, the code metadata and project management data of the current version of the software under test are preprocessed in the same way as in the training phase, including missing value imputation and non-numerical feature label encoding. The processed data is then input into the risk prediction model trained in the previous steps to obtain the risk probability value for each code module and function. The setting of the preset threshold should refer to the historical test data of the existing project: specifically, the risk probability of code modules that have been verified as high-risk and have actually had defects in the past three tests can be counted, and the minimum of these probabilities can be taken as the preset threshold. For example, if the minimum risk probability of a high-risk code module in the past is 0.6, then the threshold is set to 0.6.

[0051] Next, visualization tools, such as Python's Matplotlib library, are used to draw risk heatmaps: the software's module structure is used as the coordinate axis, with the horizontal axis representing functional modules and the vertical axis representing sub-functions. Different colors are used to represent risk levels. For example, red represents high-risk areas with a risk probability ≥ 0.6, yellow represents medium-risk areas with a risk probability of 0.3-0.6, and green represents low-risk areas with a risk probability < 0.3. Code modules and functions with a risk probability higher than a preset threshold are marked in red to generate an intuitive risk heatmap.

[0052] Finally, when identifying the input parameters of the software under test, the static code analysis tool PMD is used. The `pmdcheck` command is executed to scan the code files of the software under test, parse the interface definitions and function parameter lists, and extract all input parameters, such as the username and password parameters of the user login module. Then, the correlation between each input parameter and high-risk areas is analyzed. This step will be explained in detail later. Based on the obtained correlation, quantitative weights are assigned to the input parameters: the higher the correlation, the larger the weight value. The correlation value is used as the dynamic risk weight of the input parameter. When calculating the correlation, normalization is used to make the correlation itself a quantitative value of 0-1, and this value reflects the characteristic that the higher the correlation, the larger the value. Finally, the dynamic risk weight of each input parameter is obtained.

[0053] By extracting training samples, using algorithms to train risk prediction models, combining historical data to set thresholds to generate heatmaps and assigning dynamic weights, the system effectively identifies high-risk areas in the software under test and provides risk-oriented guidance for the generation of subsequent test cases.

[0054] In one possible implementation, the dynamic risk weight allocation module 20 further includes:

[0055] The correlation is calculated by the frequency and depth at which parameters are used in functions or code modules in high-risk areas.

[0056] Specifically, firstly, identify the high-risk functions and code modules in the software to be tested. Based on the risk heat map generated in the previous steps, select all function names and their corresponding code modules that are marked as high-risk areas from the heat map. That is, code modules and functions with risk probability values ​​higher than the preset threshold are selected to form a list of high-risk code units, which will help to lock the analysis scope for subsequent correlation calculations.

[0057] Next, all input parameters and the code structure of high-risk code units in the software under test are extracted, which can be achieved using the static code analysis tool PMD. This tool scans the source files corresponding to the high-risk code units, parsing all input parameters of the software under test and creating a parameter list. It also extracts the internal code logic, parameter reference records, and function call relationships of high-risk functions, generating a high-risk code structure analysis report, providing a foundation for tracking parameter usage.

[0058] The frequency of input parameters in high-risk areas was then calculated using text retrieval and statistical counting methods: each input parameter in the parameter list was used as the retrieval object, and the number of times each parameter was cited was retrieved in the high-risk code structure analysis report. For example, if an input parameter was cited 2 times, 1 time, and 3 times in 3 high-risk functions, its total citation count would be 6 times. The total citation count was then divided by the total number of high-risk functions to obtain the frequency of use of the parameter. If there are 5 high-risk functions, the frequency of use of the parameter would be 6 / 5 = 1.2. The higher the frequency value, the higher the activity level of the input parameter in the high-risk area.

[0059] The usage depth of the input parameter in the high-risk region is then calculated, which can be achieved by tracing the call chain hierarchy. Specifically, starting from the entry point where the input parameter is first passed to a high-risk function, the propagation path of the input parameter between high-risk code units is traced. If the input parameter is only used within the first high-risk function and is not passed to other high-risk functions, the usage depth is recorded as 1. If the input parameter is passed from the first high-risk function to the second high-risk function and continues to be used within the second high-risk function, the usage depth is recorded as 2, and so on. The maximum propagation level is the usage depth of the input parameter. The higher the depth value, the wider the influence range of the input parameter on the high-risk region.

[0060] Finally, the obtained usage frequency and usage depth are quantified and integrated to obtain the correlation degree: the usage frequency and usage depth are normalized to the range of 0-1 respectively. For example, if the maximum usage frequency is 2 and the frequency of a certain parameter is 1.2, it is normalized to 1.2 / 2=0.6; if the maximum usage depth is 3 and the depth of a certain parameter is 2, it is normalized to 2 / 3=0.67. Then, the same weight is assigned to both, that is, each accounts for 0.5. The correlation degree value of each input parameter is calculated by the formula: correlation degree = usage frequency × 0.5 + usage depth × 0.5. For example, the correlation degree of the input parameter in the above example is 0.6×0.5+0.67×0.5=0.635.

[0061] By using static code analysis tools to define the scope of analysis, combining text retrieval and call chain tracing to calculate usage frequency and depth, and then obtaining the correlation degree through simple weighting, the system achieves the effect of accurately quantifying the correlation between input parameters and high-risk areas, providing a reliable basis for the subsequent dynamic risk weight allocation of input parameters.

[0062] In one possible implementation, the basic test suite generation module 30 further includes:

[0063] The value set acquisition unit is used to analyze the possible value sets of all input parameters of the software under test; the basic test suite generation unit generates the basic test suite covering all pairwise combinations of parameters based on the value set and using a pairwise combination test design method.

[0064] Specifically, firstly, the input parameters of the software under test have been obtained using the static code analysis tool PMD in the aforementioned steps. Next, the possible value set of the input parameters is determined. For each input parameter, the parameter validation logic in the code is examined. For example, if the input parameter is that the order amount must be greater than 0 and less than 100,000, a reasonable value range is determined. Simultaneously, referring to historical test cases and defect records, edge values ​​such as null values, out-of-range values, and special characters are added. For example, the value set for the payment method input parameter is organized into WeChat Pay, Alipay, null values, invalid codes, etc., ultimately forming a complete set of possible values ​​for each input parameter.

[0065] Then, based on the aforementioned set of values, the AllPairs pairwise test design tool is used to generate a basic test suite. First, the input parameters and their value sets are organized into an Excel spreadsheet in the format of parameter name-value list, and then this spreadsheet is imported into the AllPairs tool. The tool automatically iterates through all the combinations between parameters according to the pairwise combination rules, generating test cases that are unique and cover all pairwise combinations. For example, if there are order amounts with value ranges of 100, 5000, and -10, and payment methods with value ranges of WeChat Pay and Alipay, the test design tool will generate test cases for 100+ WeChat Pay, 100+ Alipay, 5000+ WeChat Pay, 5000+ Alipay, -10+ WeChat Pay, and -10+ Alipay, ensuring coverage of all pairwise combinations between input parameters, ultimately forming the basic test suite.

[0066] By using static code analysis tools to determine the input parameters and their value sets, and using pairwise combination testing tools to generate test cases, the goal of controlling the number of test cases while fully covering key parameter interaction scenarios was achieved, providing a reliable foundation for subsequent test case optimization.

[0067] In one possible implementation, the basic test suite generation module 30 further includes:

[0068] The high-risk parameter acquisition subunit is used to identify the top N high-risk parameters whose risk weights are greater than a preset weight threshold based on the dynamic risk weights; the supplementary test case generation subunit is used to generate supplementary test cases covering all possible combinations of parameter values ​​based on the pairwise combinations of the top N high-risk parameters; the basic test suite supplementary subunit is used to add the supplementary test cases to the basic test suite.

[0069] Specifically, first, organize the input parameters and their corresponding dynamic risk weight data, and identify the top N high-risk parameters. First, organize all the input parameters and their corresponding dynamic risk weights obtained in the previous steps into structured data in the format of parameter name-risk weight, which can be quickly recorded and managed using an Excel spreadsheet.

[0070] Next, a preset weight threshold is set. This threshold can be referenced from the weight distribution of high-risk parameters in past tests. For example, if the lowest weight value of a high-risk parameter in historical data is 0.6, the preset weight threshold is set to 0.6. Then, the input parameters are sorted in descending order of risk weight in Excel. The filter function is then used to retain input parameters with a weight value greater than 0.6. Finally, the top N high-risk parameters are selected from the filter results, such as N=3. These three input parameters are the high-risk parameters that need to be focused on, thus completing the identification of high-risk parameters.

[0071] Then, supplementary test cases are generated for the first N high-risk parameters. Specifically: First, the possible value set of each high-risk parameter is defined, similar to the value set obtained in the aforementioned value set acquisition unit. For example, three high-risk parameters are obtained: order amount (values: 100, 5000, -10); payment method (values: WeChat Pay, Alipay); and user level (values: VIP, regular user). Next, the Cartesian product nested formula in Excel is used to perform full permutations and combinations of the value sets of the three parameters. By constructing multi-level formulas, each value of each parameter can be matched one-to-one with all values ​​of other parameters, generating all possible value combinations, such as 100 + WeChat Pay + VIP, 100 + WeChat Pay + Regular User, 5000 + Alipay + VIP, etc. These combinations are supplementary test cases generated on the basis of pairwise combinations, covering all possible combinations of parameter values.

[0072] Finally, the supplementary test cases are added to the basic test suite obtained from the aforementioned value set acquisition unit. First, the generated supplementary test cases are organized according to the format specifications of the basic test suite, uniformly including fields such as supplementary test case ID, input parameter combination, and test scenario description, ensuring consistent formatting. Then, using the test case management tool TestRail, the existing basic test suite is imported into the tool. Next, the tool's batch import function is used to select the supplementary test case file (Excel format), specifying the option to add it to the existing basic test suite. The tool automatically merges the supplementary test cases with the original test cases in the basic test suite, forming a complete basic test suite containing the supplementary test cases.

[0073] By using Excel to organize and filter high-risk parameters, using spreadsheet tools to generate complete combination supplementary test cases, and using test management tools to merge test suites, the effectiveness of the basic test suite in testing high-risk aspects of the software was enhanced.

[0074] In one possible implementation, the software testing algorithm execution module 40 further includes:

[0075] The interface definition parsing unit is used to parse the interface definition and extract the input parameter type and return type for each test case in the test case set; the attribute test template matching unit is used to match one or more general attribute test templates from a predefined attribute template library based on the input parameter type and return type; the input data substitution unit is used to substitute the specific input data of the test case into the attribute test template and instantiate it into an executable attribute test assertion; the complete test case acquisition unit is used to bind the attribute test assertion with the corresponding test case to form a complete test case containing input data and expected output verification.

[0076] Specifically, firstly, for each test case in the test case set, parse the interface definition and extract the input parameter types and return types. Locate the software interface corresponding to the test case. If the project has standardized interface documentation, such as Swagger documentation or Postman interface collections, directly open the interface details page in the documentation and check the type label of each input parameter in the request parameter module. For example, the username is labeled as a string type and the age is labeled as an integer type. Determine the return type of the interface in the response example or return parameter module, such as returning a JSON object, a boolean value, or a string. If there is no interface documentation, the source code file to which the interface belongs can be scanned using a static code analysis tool such as PMD. This tool will automatically identify the parameter declarations and return value definitions of the interface functions and output a list of input parameter types and return types. Finally, a clear parameter type and return type information is compiled for each test case.

[0077] Next, based on the extracted input parameter types and return types, a general attribute test template is matched from a predefined attribute template library. Specifically: first, an attribute template library is built, using Excel spreadsheets or text files to categorize and store templates. The table uses the input parameter type combination - return type as the row header, and the corresponding columns are filled with general template content. For example, the template for string + integer - boolean value is: the first input parameter (string) should satisfy the non-empty validation, the second input parameter (integer) should be within a reasonable value range, and the return result (boolean value) should be consistent with the business rules. During matching, based on the parameter type and return type of a test case obtained in the above steps, the completely corresponding row header is searched in the attribute template library, and the template content of that row is directly obtained. If multiple matching templates exist, such as two templates for the same type combination corresponding to non-empty validation and format validation, all of them are extracted for later use.

[0078] Then, substitute the specific input data of the test cases into the attribute test template to instantiate executable attribute test assertions. This can be achieved using a text replacement method. First, examine the specific input data of the test cases. For example, the input parameters of a test case are username: test001, age: 25, and the return type is a boolean value. Next, open the matched attribute test template and identify the placeholders in the template, such as first input parameter, second input parameter, and return result. Replace the placeholders one by one with the specific input data. For example, replace the "first input parameter (string) should satisfy non-empty validation" in the attribute test template with "input parameter username (string) should satisfy non-empty validation", specifically the value test001. Retain the core validation logic that the return result (boolean value) should be consistent with the business rules, forming the business judgment rule that the return result (boolean value) should conform to the user login success / failure. Finally, you obtain attribute test assertions that can be directly used for verification.

[0079] Finally, bind the attribute test assertions with the corresponding test cases to form complete test cases. If using a test case management tool, such as TestRail or ZenTao, first find the target test case in the tool, enter the test case editing page, and enter the instantiated attribute test assertions line by line in the expected results or assertion configuration module. If using an Excel spreadsheet to manage test cases, you can add an attribute test assertion column to the Excel spreadsheet and fill in the assertion content corresponding to each test case in the corresponding row column to ensure that each test case has a unique assertion associated with it. Finally, a complete test case containing input data, execution steps, and expected output verification, i.e., attribute test assertions, is formed.

[0080] By leveraging interface documentation and static analysis tools to extract type information, managing and matching templates with basic tables, generating assertions by replacing text, and binding test cases and attribute test assertions, the system achieves the effect of supplementing risk-oriented test cases with expected output verification logic, making test cases more complete, and improving the accuracy of software testing.

[0081] In one possible implementation, the software testing algorithm execution module 40 further includes:

[0082] The Docker image acquisition unit is used to package the test case set, the software version under test, and the runtime environment into multiple independent Docker images. The test case set execution unit is used to launch instances of the multiple Docker images in parallel in an isolated container cluster by calling container orchestration tools in the continuous deployment platform to execute the test case set concurrently. During execution, the execution results, code coverage data, and system resource consumption indicators of each test case are monitored and collected in real time. The test report acquisition unit is used to aggregate the execution results, code coverage data, and system resource consumption indicators of each test case to the central analysis platform and generate a test report.

[0083] In this embodiment of the application, the Docker image is a lightweight and portable packaging format that contains the application, including test case sets, the software under test, and the dependent environment required for running, which can ensure that the application has consistent running performance in different environments.

[0084] Specifically, first, create a Dockerfile locally using the Docker tool, specifying the base image in the file. For example, select the openjdk:11 image for a Java project and the python:3.9 image for a Python project. Then, use the COPY command to copy the installation package of the software under test, the test case set folder, and the environment dependency files required for running, including configuration files and third-party library installation scripts, to the specified directory of the image.

[0085] Next, add the `RUN` command to perform environment initialization operations, such as installing dependency libraries and configuring environment variables, to ensure that the image can run tests directly after startup. Then, navigate to the directory containing the Dockerfile in the command line and execute the Docker build command. Based on the module division of the test case set, such as dividing it into payment tests, login tests, etc. according to functional modules, generate multiple independent images, each corresponding to a test module, to facilitate subsequent parallel execution. Finally, you will obtain a collection of independent Docker images containing the test case set, the software under test, and the runtime environment.

[0086] Then, executing test case sets in the continuous deployment platform can be achieved using the commonly used continuous deployment tool Jenkins and the container orchestration tool Docker Compose. First, create a new build task in Jenkins, configure the source code pull address for the task to ensure that the pre-packaged Docker image can be obtained, and then add an execution command to the build step of the task to call the Docker Compose tool. The Docker Compose configuration file defines the number of instances, network mode, and resource limits for each Docker image. After executing the command, the tool will start all Docker image instances in parallel in an isolated container cluster, with each instance independently running the test case set for its corresponding module. During execution, the test progress can be viewed in real time through the Jenkins console output function. Simultaneously, the CPU and memory usage of each container (i.e., system resource consumption metrics) is monitored using the Docker built-in `stats` command. Code coverage data is collected using the code coverage tool JaCoCo, and the execution results of each test case (success, failure, and reason for failure) are recorded in text logs to ensure that all critical data is captured in real time.

[0087] Finally, the execution result logs, code coverage reports, and system resource consumption statistics collected during the execution process are integrated using a Jenkins plugin or a Python script. The script parses the log files to extract the execution status of the test cases, converts the coverage data into intuitive percentages, and summarizes the average and peak resource consumption. The integrated data is then used to generate an HTML-formatted test report, including test pass rate, coverage achievement status, and resource consumption trend charts. This report is uploaded to a central analysis platform, which can be built using Nginx and is accessible via a browser. Simultaneously, the raw data, including detailed execution results and raw coverage data, is stored in the central analysis platform's database for easy tracking and analysis, ultimately forming a complete test report that can be viewed at any time.

[0088] By packaging images using Docker, implementing concurrent test execution using Jenkins and Docker Compose, and aggregating data to generate reports through a central analysis platform, the system achieves efficient concurrent execution of test case sets, real-time monitoring of key indicators during the testing process, and generation of traceable and complete test reports, thereby improving software testing efficiency and the usability of results.

[0089] In one possible implementation, the software testing algorithm execution module 40 further includes:

[0090] The real defect information acquisition subunit is used to extract all newly discovered and verified real defect information in high-risk areas from the test report; the positive sample acquisition subunit is used to add the defect information and associated code metadata and project management data as new positive samples to the training samples of the risk prediction model; the prediction accuracy optimization subunit is used to periodically use the updated training samples to incrementally train the risk prediction model in order to optimize the model's prediction accuracy for high-risk areas in future software versions.

[0091] Specifically, firstly, extract real defect information for high-risk areas from the test report. The test report is presented in HTM format. Open the defect statistics module in the test report and find the defect entries marked with high-risk areas. The test report will clearly indicate the code module to which the defect belongs. Match this with the risk heatmap generated in the previous steps to determine if it belongs to a high-risk area. Next, verify the authenticity of these defects: re-execute the tests in the test environment of the software under test according to the test case steps recorded in the test report, and observe whether the same defect can be reproduced. If it is reproduced multiple times, it is determined to be a real defect. Then, compile the key information of these real defects, including defect description, code module, and triggering conditions, into a list to complete the extraction of real defect information for high-risk areas.

[0092] Then, the defect information and related data are organized into new positive samples and added to the training samples: First, the code metadata associated with the defect is obtained. The historical records of the code module to which the defect belongs are searched from the version control system, and the code cyclomatic complexity, recent change frequency, and number of lines of code for that module are calculated. Then, the associated project management data is retrieved from the project management system, including the functional priority of the requirement to which the defect belongs, the historical defect density of that module, and the experience level of the code submitter. Subsequently, referring to the format of the original training samples, such as CSV file format, which includes code metadata, project management data, and risk probability label fields, the organized defect information and related data are filled in. At the same time, risk probability labels are labeled for the new samples. For real defect information, a label value is set to represent high risk. Finally, the new sample file is merged with the original training sample file to update the training sample set.

[0093] Finally, the risk prediction model is incrementally trained periodically using updated samples. The Python XGBoost library is chosen as the incremental training tool. In the previous steps, the risk prediction model was initially trained using a gradient boosting decision tree. During incremental training, the saved original model file is loaded first, followed by the updated training sample set. A training cycle is set, for example, once a week, synchronized with the project iteration cycle. Incremental training is performed using the XGBoost incremental training interface, fine-tuning the parameters of the original model using only the newly added samples, avoiding retraining all samples to save time. After training, the model accuracy is verified using a reserved test sample set, i.e., comparing the prediction accuracy of the model for high-risk areas before and after training, ensuring that the prediction accuracy of the risk prediction model for high-risk areas in future software versions is optimized.

[0094] By screening and reproducing to verify the extraction of real defects, linking and retrieving data and organizing new samples, and using common tools to regularly and incrementally train the model, the effect of continuously supplementing the model training data and optimizing the model's accuracy in predicting high-risk areas of future software was achieved.

[0095] In summary, the artificial intelligence-based automatic software test case generation system provided in this application has the following technical effects:

[0096] This application embodiment collects code metadata of the software version under test and obtains associated project management data from the project management system. After analysis and processing by a pre-trained risk prediction model, it obtains risk heatmaps identifying high-risk code modules and functions, as well as dynamic risk weights of software input parameters. Based on the input parameters and dynamic risk weights, it generates a basic test suite and supplements it with complete combination test cases of high-risk parameters. Then, it uses the basic test suite as the initial population to initiate iterative evolution of a search-based software testing algorithm. The fitness function consists of code coverage indicators and dynamic risk weights. The risk prediction model is incrementally trained by combining the test case execution results and newly discovered defect data, thereby accurately generating a risk-oriented software test case set. This allows software testing to focus on covering high-risk areas, improving the accuracy and efficiency of software defect detection. It achieves the technical effect of accurately identifying high-risk links in the software, generating more targeted test cases, and improving software testing efficiency and the accuracy of software quality assessment.

[0097] Example 2, as Figure 2 As shown, based on the same inventive concept as the aforementioned Embodiment 1, this application provides an artificial intelligence-based method for automatically generating software test cases, the method comprising:

[0098] The code metadata of the software version under test is collected, and related project management data is obtained from the project management system. The code metadata and project management data are input into a pre-trained risk prediction model, which outputs a risk heatmap to identify high-risk code modules and functions, and assigns dynamic risk weights to the software's input parameters. Based on the input parameters and the dynamic risk weights, a basic test suite is generated using combined test design rules. The basic test suite is used as the initial population to start a search-based software testing algorithm, wherein the fitness function of the software testing algorithm is composed of the code coverage index and the dynamic risk weights, and a risk-oriented test case set is generated through iterative evolution.

[0099] Furthermore, embodiments of this application also include:

[0100] The code metadata includes code cyclomatic complexity, code change frequency, and lines of code; the project management data includes the functional priority of related requirements, historical defect density, and the experience level of the code contributor.

[0101] Furthermore, the code metadata and project management data are input into a pre-trained risk prediction model, which outputs a risk heatmap to identify high-risk code modules and functions, and assigns dynamic risk weights to the software's input parameters. This embodiment of the application also includes:

[0102] Training samples are extracted from historical data of version control systems and project management systems, where each sample contains code metadata, project management data, and a label indicating the risk probability of the code module. The training samples are trained using a gradient boosting decision tree to generate the risk prediction model. The risk prediction model is then used to analyze the code metadata and project management data, marking code modules and functions with risk probabilities exceeding a preset threshold as high-risk areas, generating the risk heatmap. All input parameters of the software under test are identified, and the correlation between each input parameter and the high-risk areas is analyzed. Based on this correlation, a quantified weight is assigned to each input parameter to obtain the dynamic risk weight.

[0103] Furthermore, embodiments of this application also include:

[0104] The correlation is calculated by the frequency and depth at which parameters are used in functions or code modules in high-risk areas.

[0105] Furthermore, based on the input parameters and the dynamic risk weights, a basic test suite is generated using combined test design rules. This embodiment of the application also includes:

[0106] Analyze the possible value set of all input parameters of the software under test; based on the value set, use a pairwise combination test design method to generate the basic test suite that covers all pairwise combinations of parameters.

[0107] Furthermore, in generating the basic test suite, this embodiment of the application also includes:

[0108] Based on the dynamic risk weights, the top N high-risk parameters with risk weights greater than a preset weight threshold are identified; for the top N high-risk parameters, supplementary test cases covering all possible combinations of parameter values ​​are generated based on pairwise combinations; the supplementary test cases are added to the basic test suite.

[0109] Furthermore, after generating a risk-oriented test case set, the embodiments of this application also include:

[0110] For each test case in the test case set, the interface definition is parsed to extract the input parameter type and return type. Based on the input parameter type and return type, one or more general attribute test templates are matched from the predefined attribute template library. The specific input data of the test case is substituted into the attribute test template to instantiate an executable attribute test assertion. The attribute test assertion is bound to the corresponding test case to form a complete test case containing input data and expected output verification.

[0111] Furthermore, after generating a risk-oriented test case set, the embodiments of this application also include:

[0112] The test case set, the software version under test, and the runtime environment are packaged into multiple independent Docker images. In the continuous deployment platform, by calling the container orchestration tool, instances of the multiple Docker images are started in parallel in an isolated container cluster to execute the test case set concurrently. During execution, the execution results, code coverage data, and system resource consumption indicators of each test case are monitored and collected in real time. The execution results, code coverage data, and system resource consumption indicators of each test case are aggregated into a central analysis platform and a test report is generated.

[0113] Furthermore, after generating the test report, the embodiments of this application also include:

[0114] Extract all newly discovered and verified defects in high-risk areas from the test report; add the defect information and associated code metadata and project management data as new positive samples to the training samples of the risk prediction model; periodically use the updated training samples to incrementally train the risk prediction model to optimize the model's prediction accuracy for high-risk areas in future software versions.

[0115] Through the foregoing detailed description of an AI-based software test case automatic generation system, those skilled in the art can clearly understand the AI-based software test case automatic generation method in this embodiment. As for the method disclosed in Embodiment 2, since it corresponds to the system disclosed in Embodiment 1, it has corresponding execution steps and technical effects. For relevant details, please refer to the system section description.

[0116] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An artificial intelligence-based automatic software test case generation system, characterized in that, include: The project management data acquisition module is used to collect code metadata of the software version under test, and at the same time obtain related project management data from the project management system. The dynamic risk weight allocation module is used to input the code metadata and project management data into the pre-trained risk prediction model, output a risk heatmap to identify high-risk code modules and functions, and allocate dynamic risk weights to the software's input parameters. The basic test suite generation module generates a basic test suite based on the input parameters and the dynamic risk weights, using combined test design rules. The software testing algorithm execution module is used to start a search-based software testing algorithm with the basic test suite as the initial population. The fitness function of the software testing algorithm is composed of the code coverage index and the dynamic risk weight, and generates a risk-oriented test case set through iterative evolution. The code metadata and project management data are input into a pre-trained risk prediction model, which outputs a risk heatmap to identify high-risk code modules and functions, and assigns dynamic risk weights to the software's input parameters, including: The training sample acquisition unit is used to extract training samples from historical data of the version control system and project management system. Each sample contains code metadata, project management data, and a label indicating the risk probability of the code module. A risk prediction model building unit is used to train the training samples using a gradient boosting decision tree to generate the risk prediction model. The risk heatmap generation unit is used to analyze the code metadata and project management data through the risk prediction model, mark code modules and functions with risk probability values ​​higher than a preset threshold as high-risk areas, and generate the risk heatmap. The dynamic risk weight acquisition unit is used to identify all input parameters of the software under test, analyze the correlation between each input parameter and the high-risk area, and assign a quantified weight to each input parameter based on the correlation to obtain the dynamic risk weight. The correlation is calculated by the frequency and depth at which parameters are used in functions or code modules in high-risk areas.

2. The software test case automatic generation system based on artificial intelligence as described in claim 1, characterized in that, The code metadata includes code cyclomatic complexity, code change frequency, and lines of code; the project management data includes the functional priority of related requirements, historical defect density, and the experience level of the code contributor.

3. The software test case automatic generation system based on artificial intelligence as described in claim 1, characterized in that, Based on the input parameters and the dynamic risk weights, a basic test suite is generated using combined test design rules, including: The value set acquisition unit is used to analyze the possible value set of all input parameters of the software under test. The basic test suite generation unit generates the basic test suite that covers all pairwise combinations of parameters based on the set of values ​​and using a pairwise combination test design method.

4. The software test case automatic generation system based on artificial intelligence as described in claim 3, characterized in that, Generating the basic test suite also includes: The high-risk parameter acquisition subunit is used to identify the top N high-risk parameters whose risk weights are greater than a preset weight threshold based on the dynamic risk weights. The supplementary test case generation subunit is used to generate additional supplementary test cases covering all possible combinations of parameter values ​​based on the pairwise combinations of the first N high-risk parameters. The basic test suite supplementary subunit is used to add the supplementary test cases to the basic test suite.

5. The software test case automatic generation system based on artificial intelligence as described in claim 1, characterized in that, After generating a risk-oriented test case set, the following steps are also included: The interface definition parsing unit is used to parse the interface definition and extract the input parameter type and return type for each test case in the test case set. The attribute test template matching unit matches one or more general attribute test templates from a predefined attribute template library based on the input parameter type and return type. The input data substitution unit is used to substitute the specific input data of the test case into the attribute test template and instantiate it into an executable attribute test assertion. The complete test case acquisition unit is used to bind the attribute test assertion with the corresponding test case to form a complete test case containing input data and expected output verification.

6. The software test case automatic generation system based on artificial intelligence as described in claim 1, characterized in that, After generating a risk-oriented test case set, the following steps are also included: The Docker image acquisition unit is used to package the test case set, the software version under test, and the runtime environment into multiple independent Docker images. The test case set execution unit is used to launch instances of the multiple Docker images in parallel in an isolated container cluster by calling container orchestration tools in the continuous deployment platform, so as to execute the test case set concurrently. During the execution process, the execution results, code coverage data and system resource consumption indicators of each test case are monitored and collected in real time. The test report acquisition unit is used to aggregate the execution results, code coverage data, and system resource consumption indicators of each test case to the central analysis platform and generate a test report.

7. The software test case automatic generation system based on artificial intelligence as described in claim 6, characterized in that, After generating the test report, it also includes: The real defect information acquisition subunit is used to extract all newly discovered and verified real defect information in high-risk areas from the test report; The positive sample acquisition subunit is used to add the defect information and associated code metadata and project management data as new positive samples to the training samples of the risk prediction model. The prediction accuracy optimization subunit is used to periodically perform incremental training on the risk prediction model using updated training samples to optimize the model's prediction accuracy for high-risk areas in future software versions.

8. A method for automatically generating software test cases based on artificial intelligence, characterized in that, The method is implemented by an AI-based software test case automatic generation system as described in any one of claims 1-7, and the method includes: Collect code metadata of the software version under test, and simultaneously obtain related project management data from the project management system; The code metadata and project management data are input into a pre-trained risk prediction model, which outputs a risk heatmap to identify high-risk code modules and functions, and assigns dynamic risk weights to the software's input parameters. Based on the input parameters and the dynamic risk weights, a basic test suite is generated using combined test design rules. Using the basic test suite as the initial population, a search-based software testing algorithm is launched, wherein the fitness function of the software testing algorithm is composed of the code coverage metric and the dynamic risk weight, and a risk-oriented test case set is generated through iterative evolution.

Images