Automatic software test case generation system and method based on artificial intelligence

Abstract

The invention provides a software test case automatic generation system and method based on artificial intelligence, and relates to the technical field of software testing, and the system comprises a project management data acquisition module which collects code metadata and project management data; the dynamic risk weight distribution module inputs the two types of data into a risk prediction model, outputs a risk thermodynamic diagram and distributes dynamic risk weights of input parameters; the basic test suite generation module generates a basic test suite according to the input parameters and the dynamic risk weights; and the software test algorithm execution module starts a software test algorithm, and iteratively evolves to generate a test case set. According to the method and the device, the technical problems that an existing software test case generation mode is difficult to effectively integrate software related data to identify a high-risk link, and the generated case is insufficient in coverage of a key area and low in accuracy are solved, accurate identification of the software high-risk link is achieved, the generated test case is more targeted, and the test efficiency is improved. And the software testing efficiency and the software quality evaluation accuracy are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software testing, in particular to a software test case automatic generation system and method based on artificial intelligence. BACKGROUND

[0002] Software test case generation is crucial to software quality assurance and development efficiency improvement, and data processing is a key supporting link. In the prior art, software test case generation relies on manual design or simple rules, and data processing is limited to basic input parameter analysis, without effectively integrating code and project associated data. However, in complex software version testing, the traditional way of data processing is difficult to mine high-risk code module information, resulting in inaccurate coverage of generated test cases, easy omission of high-risk areas, and low data processing efficiency, which cannot meet the needs of software testing for precision and efficiency, and cannot support accurate evaluation and effective control of software quality. SUMMARY

[0003] The present application provides a software test case automatic generation system and method based on artificial intelligence, which solves the technical problems that the existing software test case generation method is 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 precision, and achieves the technical effects of accurately identifying high-risk links of software, generating more targeted test cases, improving software testing efficiency and software quality evaluation accuracy.

[0004] In view of the above problems, on the one hand, the present application provides a software test case automatic generation system based on artificial intelligence, which comprises: a project management data acquisition module for collecting code metadata of a software version to be tested, and simultaneously acquiring associated project management data from a project management system; a dynamic risk weight allocation module for inputting the code metadata and project management data into a pre-trained risk prediction model, outputting a risk heat map for identifying high-risk code modules and functions, and allocating dynamic risk weights for input parameters of the software; a basic test suite generation module for generating a basic test suite based on the input parameters and the dynamic risk weights using combination test design rules; a software test algorithm execution module for taking the basic test suite as an initial population and starting a search-based software test algorithm, wherein the fitness function of the software test algorithm is composed of a code coverage rate index and the dynamic risk weights, and a risk-oriented test case set is generated through iterative evolution.

[0005] In another aspect, the application also provides an artificial intelligence-based software test case automatic generation method, which comprises: collecting code metadata of a software version to be tested, and simultaneously obtaining associated project management data from a project management system; inputting the code metadata and the project management data into a pre-trained risk prediction model, outputting a risk heat map for identifying high-risk code modules and functions, and assigning a dynamic risk weight to an input parameter of the software; based on the input parameter and the dynamic risk weight, generating a basic test suite using a combination test design rule; taking the basic test suite as an initial population, and starting a search-based software test algorithm, wherein an adaptability function of the software test algorithm is jointly constituted by a code coverage rate index and the dynamic risk weight, and a risk-oriented test case set is generated through iterative evolution.

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

[0007] The project management data acquisition module acquires code metadata of a software version to be tested, and calls associated project management data from a project management system to construct a software test basic data set; the dynamic risk weight allocation module inputs the basic data set into a pre-trained gradient boosting decision tree risk prediction model, outputs a risk heat map for identifying high-risk code modules and functions, and combines the use frequency and depth analysis correlation degree of the input parameter in the high-risk area to assign a dynamic risk weight to the input parameter; the basic test suite generation module generates basic test cases covering all parameter two-by-two combinations by using a two-by-two combination test design method according to the possible value set of the input parameter and the dynamic risk weight, additionally generates supplementary test cases with complete value combinations of the first N high-risk parameters with risk weights greater than a preset threshold, and integrates to form a complete basic test suite; the software test algorithm execution module takes the basic test suite as an initial population, starts a search-based software test algorithm, the adaptability function of which is jointly constituted by a code coverage rate index and a dynamic risk weight, and generates a risk-oriented test case set through iterative evolution.

[0008] In summary, the application acquires code metadata of a software version to be tested and associated project management data, processes high-risk code module and function identification and software input parameter dynamic risk weight through a pre-trained risk prediction model, generates a basic test suite, starts a search-based software test algorithm with the basic test suite as an initial population, and iteratively evolves in combination with a code coverage rate and a dynamic risk weight, thereby generating a risk-oriented test case set, and can also improve test case verification logic and realize parallel execution and result analysis, so that software test case generation is more accurate and efficient, and supports accurate evaluation 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, first, when collecting the code metadata of the software version to be tested, those skilled in the art can use version control systems (such as Git, SVN) and static code analysis tools. First, through the command line tool of the version control system, such as the git clone command of Git, the code repository of the software version to be tested is cloned to the local, and then the git log command is used to filter out the code submission records related to the version, and the number of code submissions in the specified time range is counted, so as to obtain the code change frequency; then, a static code analysis tool such as PMD (Programming Mistake Detector) is called, and the code files of the software to be tested are used as input. The tool will automatically traverse the code structure, calculate the cyclomatic complexity of each function and module by analyzing the number of control flow statements such as branches and loops in the code, and at the same time, the total number of lines of each code file is counted, and finally the structured data containing the cyclomatic complexity, code change frequency and code line number is exported, completing the collection of code metadata.

[0019] Next, when obtaining the associated project management data from the project management system, the open API provided by the existing project management system such as Jira and Zen is used. First, find the project corresponding to the software version to be tested in the project management system, and generate an API key with data reading permission through the system background; then, use the curl command of the HTTP request tool, according to the API document format of the project management system, splice the request link containing the API key and the required data types including function priority, historical defect density, code submitter experience level, and send data acquisition request to the system. The project management system will return the corresponding structured data in JSON format after receiving the request, and then through the data parsing script familiar to those skilled in the art, such as the json module of Python, the function priority is extracted from the priority field of the requirement module; the historical defect density is calculated by dividing the number of closed defects in the project by the total number of lines of code of the software to be tested; the code submitter experience level is divided into three levels of basic, skilled and experienced according to the length of time and the number of code submissions of the submitter in the past, and then the project management data is obtained.

[0020] By using the existing popular version control tools, static code analysis tools, project management system APIs and basic data processing tools, the collection of code metadata and associated project management data of the software version to be tested is completed in steps, which achieves the effect of simply and efficiently obtaining two types of core data and providing complete input for the subsequent risk prediction model.

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

[0022] Specifically, first, training samples are extracted from historical data of a version control system and a project management system, each sample containing code metadata, project management data, and a code module risk probability label, and a risk prediction model is trained by gradient boosting decision trees; then, the risk prediction model is used to analyze code metadata and project management data of the software to be tested, code modules and functions with a risk probability exceeding a preset threshold are marked as high-risk areas, and a corresponding risk heat map is generated; finally, all input parameters of the software to be tested are identified, the correlation between the input parameters and the high-risk areas is analyzed, and quantitative weights are allocated to the input parameters based on the correlation, 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 a combinatorial test design rule.

[0024] Specifically, based on the input parameters and the dynamic risk weights, the specific composition and operation of the basic test suite generated using the combinatorial test design rule are as follows: on the one hand, all input parameters of the test software are analyzed to determine the possible value set corresponding to each input parameter; on the other hand, relying on the value set obtained above, a pairwise combinatorial test design method is used to generate a basic test suite that can cover all pairwise combinations of parameters.

[0025] The software test algorithm execution module 40 is configured to use the basic test suite as an initial population to start a search-based software test algorithm, wherein a fitness function of the software test algorithm is composed of a code coverage rate indicator and the dynamic risk weights, and a risk-oriented test case set is generated by iterative evolution.

[0026] Specifically, first, the basic test suite is converted into an initial population recognizable by a genetic algorithm. Each test case in the basic test suite contains a value combination of multiple input parameters, which is disassembled into gene fragments, with each value of an input parameter corresponding to a gene, for example, a test case of an order amount of 100 and a payment method of WeChat payment can be disassembled into a gene sequence of [100, WeChat payment]. With the help of the list structure of Python, the gene sequences of all test cases are integrated into an initial population list, each list element representing an individual, i.e., a test case, so that the genetic algorithm can directly perform subsequent optimization operations on the population.

[0027] Next, a fitness function composed of a code coverage rate indicator and dynamic risk weights is constructed:

[0028] If in small-scale software or simple test scenarios, code coverage indicators can be achieved by manual tracking and statistics: when executing a single test case, the source code of the software under test is synchronized, and the actual executed code lines during the running of the test case are marked line by line, and the non-executed code lines such as comments and empty lines are not involved in marking and statistics, for example, in the source code file, the executed lines are marked with a specific symbol, after the test case is executed, the number of marked executed effective code lines is counted, and then compared with the total number of effective code lines of the software under test, wherein the number of total effective code and executed effective code is obtained, and the comments, empty lines and non-executed code are excluded, and the number of executed effective code lines is divided by the total number of effective code lines, that is, the coverage value in the interval [0, 1] can be obtained.

[0029] If in large-scale software or complex test scenarios, the coverage data of each test case is obtained by using the code coverage tool JaCoCo: execute the test case on the software under test, JaCoCo will automatically track the code execution path, generate a coverage report, and extract the proportion of the number of effective code lines covered by the test case to the total number of code lines of the software under test, and obtain the coverage value in the interval [0, 1].

[0030] Then, the dynamic risk weight score is calculated: the input parameters contained in each test case and the corresponding dynamic risk weight are counted, and the average value of the sum of these weights is obtained, for example, a test case contains two input parameters with weights 0.8 and 0.6, and the average value is 0.7. Finally, the weights of the code coverage indicator and the dynamic risk weight are set to 0.5 respectively, which is convenient for calculation and can balance the influence of the two indicators. The fitness score of each test case is quantified by the formula: fitness score = code coverage value x 0.5 + weight score x 0.5, and the higher the score represents the test case that meets the demand of covering a wide range and strong risk orientation.

[0031] Then, the selection operation of genetic algorithm is performed to select parent individuals. The roulette method well known to those skilled in the art is used to complete it through the DEAP library (open source genetic algorithm tool library) of Python. First, the sum of the fitness scores of all individuals in the initial population is calculated, and then each individual is assigned a selection probability, that is, the individual fitness score / sum, and the probability of the individual being selected is higher. For example, the fitness scores of the three individuals in the initial population are 0.8, 0.6 and 0.5, and the total sum is 1.9, and the corresponding selection probabilities are about 0.42, 0.32 and 0.26. Random numbers are generated by the selRoulette function of the DEAP library, and individuals are selected from the population according to the probability to finally form a parent set with the same size as the original population, which ensures that test cases with high fitness are more likely to enter the subsequent optimization process.

[0032] After that, offspring individuals are generated by crossover operation to combine the advantages of parents. By using single-point crossover method, first, the parent individuals are randomly paired by the random module of DEAP library, for example, the first parent [100, WeChat payment] is paired with the second parent [5000, Alipay payment], and then a crossover point is randomly selected, for example, after the first gene, the gene segments after the crossover point are exchanged, to obtain the first offspring [100, Alipay payment] and the second offspring [5000, WeChat payment]. The crossover operation generates new parameter value combinations by exchanging gene segments, expands the coverage scenarios of test cases, and the cxOnePoint function of DEAP library can directly implement the operation, reducing the development difficulty of the person skilled in the art.

[0033] Subsequently, mutation operation is performed to introduce new mutations, and high-risk parameters are optimized. First, the basic mutation probability is set to 0.05, which is the industry general basic value, to avoid excessive mutation, and then for high-risk parameters with dynamic risk weight greater than the preset weight threshold 0.6, the mutation probability of the corresponding gene segment is increased to 0.2, that is, the high-risk parameter value is adjusted preferentially. For example, the order amount is a high-risk parameter and the weight 0.8 is greater than the preset weight threshold 0.6, and the mutation probability of the gene segment is 0.2; the user ID is a low-risk parameter and the weight is 0.3, and the mutation probability is 0.05. By using the mutUniformInt function of DEAP library, a random number between 0 and 1 is generated for each gene segment, and if it is less than the corresponding mutation probability, a new value is randomly selected from the value set of the parameter to replace the original gene, for example, the order amount 100 is mutated to the order amount -10, so as to increase the diversity of the high-risk parameter value, and it is easier to generate test cases that can detect defects in high-risk areas.

[0034] Finally, a new generation population is obtained after one selection, crossover and mutation, and it is judged whether the iteration termination condition is reached, for example, the iteration is set to 50 times, or the average fitness score of the population changes by less than 0.01 for 5 consecutive generations. If not, repeat the above operation based on the new generation population; if so, select the test cases with the top 80% fitness scores from the final population to form a risk-oriented test case set. The entire iteration process can be controlled by the for loop of Python, and the average fitness of each generation is recorded by using the logging module to monitor the optimization progress in real time, ensuring that the iteration effect can be traced.

[0035] By converting the basic test suite into the initial population of genetic algorithm, constructing the fitness function combining code coverage and dynamic risk weight, performing selection, crossover and mutation operations and iterating optimization, the risk-oriented test case set covering a wide range and focusing on high-risk areas of software can be efficiently generated.

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

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

[0038] Specifically, the code cyclomatic complexity is a technical index for measuring the logical complexity of the code, which is mainly calculated by counting the number of control flow statements such as branches, loops, and conditional judgments in the code. Its role is to provide a basis for the subsequent pre-trained risk prediction model. The more complex the logic of the code module, the higher the probability of logical vulnerabilities or defects. With the help of this index, high-risk logic areas in the code can be preliminarily identified, laying a foundation for subsequent positioning of high-risk code modules.

[0039] The code change frequency refers to the number of times a code module or function is modified and submitted within a certain time range, such as a project iteration period. Its role is to reflect the stability of the code: the more frequently the code is changed, the more likely it is that there are temporary adjustments or functional iterations, and the greater the possibility of introducing new defects. This index can assist the risk prediction model in judging the dynamic risk of the code module and avoiding missing potential problems caused by frequent changes.

[0040] The code line number is an index that counts the number of effective code in a code file or module without comments or blank lines. Its role is to reflect the size of the code module: the more lines of code a module has, the more complex the functionality it contains, and the more potential defects it may have. This index can be used as a reference for the risk prediction model to judge the basic risk of the code module and help preliminarily classify the risk level of code modules of different sizes.

[0041] The functional priority of associated requirements refers to the importance level set by the software requirements corresponding to the code module, such as core function, secondary function, and auxiliary function. Its role 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 user experience. This data can help the risk prediction model to lean towards code modules associated with core functions when judging risks, ensuring that the code corresponding to critical functions receives special attention.

[0042] The historical defect density refers to the ratio of the number of defects found in the code module during past testing or use to the size of the module code (usually based on the number of code lines). Its role is to provide a historical risk reference: a module with a high historical defect density indicates that there may be inherent problems in the design or implementation of the code module, and the probability of new defects occurring is higher. This index can significantly improve the accuracy of the risk prediction model in locating high-risk modules.

[0043] The experience level of the code submitter is evaluated according to the number of past code submissions, the defect rate of the submitted code, the efficiency of solving problems and other dimensions, for example, basic, skilled, experienced, which serves as an indirect basis for judging the quality of the code: the relatively inexperienced submitter may lack in code writing specifications, logical integrity and other aspects, and the submitted code may have a relatively high risk of introducing defects. Combining this data can make the risk prediction model more comprehensive in judging the code risk and avoid ignoring potential risks caused by personnel factors.

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

[0045] a training sample acquisition unit configured to extract training samples from historical data of a version control system and a project management system, wherein each sample contains code metadata, project management data and a label indicating the risk probability of the code module; a risk prediction model construction unit configured to train the training samples using gradient boosting decision trees to generate the risk prediction model; a risk heat map generation unit configured to analyze the code metadata and the project management data by using the risk prediction model, mark code modules and functions with a risk probability value higher than a preset threshold as high-risk areas, and generate the risk heat map; and a dynamic risk weight acquisition unit configured to identify all input parameters of the software to be tested, analyze the correlation degree of each input parameter with the high-risk areas, assign a quantified weight to each input parameter based on the correlation degree, and obtain the dynamic risk weight.

[0046] In the embodiments of the present application, the version control system is a tool for managing software code versions, recording code modification history, including change content, modification time, submitter, supporting team collaborative development and being able to track code change frequency and other information, and common ones are Git, SVN and the like.

[0047] Specifically, in extracting the training samples, the existing version control system Git and project management system Jira can be used to realize data acquisition. First, through the command line tool of Git, the corresponding operation for viewing the code commit history and change statistics information is executed to obtain the code commit record of the historical version of the software under test, from which the historical code metadata of each code module is extracted, including the past code cyclomatic complexity, code change frequency, and code line number. At the same time, through the open API of Jira, the data query interface is called to obtain the historical defect record of the software project, and the defect information associated with each code module is filtered out. Next, the risk probability label of each code module is calculated: the number of defects that occur in the code module in the past multiple iteration cycles is counted, and then divided by the total number of iteration cycles to obtain a risk probability between 0 and 1, for example, if a certain code module has 3 defects in 6 cycles, the risk probability is 0.5. Finally, the historical code metadata, historical project management data, and corresponding risk probability label of each code module are combined to form a training sample set.

[0048] Next, the risk prediction model is constructed and trained, and gradient boosting decision tree is used for training. 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, the mean filling method is used to supplement the defect density mean of the same type of code module; for non-numeric features, such as the experience level of the code committer, the label encoding method is used to map the basic, skilled, and experienced to 1, 2, and 3, respectively.

[0049] Then, the preprocessed training sample set is divided into a training set and a test set according to a 7:3 ratio, the model parameters are set, the learning rate is set to 0.1, the tree depth is set to 3, and the number of iterations is set to 100. These parameters are commonly used industry basic parameters, which are easy to debug and stable in effect. Subsequently, the model training is started, the code metadata including historical code cyclomatic complexity, change frequency, and line number, and the project management data including historical feature priority, historical defect density, and committer experience level are used as input features, and the risk probability label is used as the output target. Through iterative optimization of the model parameters, the error between the predicted risk probability of the model and the actual risk probability label is minimized. After training, the model accuracy is verified using the test set to ensure that the prediction error of the model is less than 10%, and a usable risk prediction model is finally generated. The input of the model is the code metadata and project management data of the code module to be analyzed, and the output is a risk probability value between 0 and 1 for the module.

[0050] Then, the code metadata and project management data of the current version of the software under test are preprocessed in accordance with the training phase described above, including missing value mean filling, non-numeric feature label encoding, and the processed data is input into the risk prediction model trained in the above steps to obtain the risk probability value of each code module and function. The preset threshold is set by referring to the historical test data of existing projects: specifically, the risk probabilities of code modules verified as high risk and actually having defects in the past 3 tests are counted, and the minimum value of these probabilities is taken as the preset threshold, for example, the minimum risk probability of the past high-risk code modules is 0.6, and the threshold is set to 0.6.

[0051] Then, a risk heat map is drawn using a visualization tool, such as the Matplotlib library of Python: taking the module structure of the software as the coordinate axis, the horizontal axis as the function module, and the vertical axis as the sub-function, different colors are used to represent the risk level, for example, red represents the high-risk area with a risk probability ≥ 0.6, yellow represents the medium-risk area with a risk probability of 0.3-0.6, and green represents the low-risk area with a risk probability < 0.3, the code modules and functions with a risk probability higher than the preset threshold are marked in red, and an intuitive risk heat map is generated.

[0052] Finally, when identifying the input parameters of the software under test, the static code analysis tool PMD is used to scan the code files of the software under test by executing the pmdcheck command, parse the interface definition and function parameter list, and extract all input parameters, such as the username and password parameters of the user login module. Then, the association degree of each input parameter with the high-risk area is analyzed, which will be described in detail later, and a quantitative weight is assigned to the input parameter according to the obtained association degree: the higher the association degree, the greater the weight value, and the value of the association degree is taken as the dynamic risk weight of the input parameter. In the calculation of the association degree, the normalization processing is performed to make the association degree itself present a quantitative value of 0-1, and the value reflects the characteristics that the higher the association degree, the greater the value, and finally the dynamic risk weight of each input parameter is obtained.

[0053] By extracting training samples, training a risk prediction model using an algorithm, setting a threshold based on historical data, generating a heat map, and assigning a dynamic weight, the effect of accurately identifying high-risk areas of the software under test and providing risk-oriented basis for generating subsequent test cases is achieved.

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

[0055] The association degree is calculated by the frequency and depth of the parameter being used in the function or code module in the high-risk area.

[0056] Specifically, first, high-risk functions and code modules in the software to be tested are determined, and all function names and code modules belonging to the high-risk regions marked in the risk heat map generated based on the foregoing steps are screened out, i.e., code modules and functions with a risk probability value higher than a preset threshold, to form a list of high-risk code units, locking the analysis range for subsequent correlation degree calculation.

[0057] Next, all input parameters of the software to be tested and the code structure of the high-risk code units are extracted, which can be achieved by using the static code analysis tool PMD. By scanning the source files corresponding to the high-risk code units by using the tool, all input parameters of the software to be tested are parsed and a parameter list is established, and the internal code logic, parameter reference records and function call relationship of the high-risk functions are extracted to form a high-risk code structure analysis report, providing a basis for tracking the use of parameters.

[0058] Subsequently, the use frequency of the input parameters in the high-risk regions is calculated by using the method of text retrieval and statistical counting: taking each input parameter in the parameter list as a retrieval object, the number of times that the parameter is referenced in the high-risk code structure analysis report is retrieved one by one. For example, an input parameter is referenced 2 times, 1 time and 3 times in 3 high-risk functions respectively, and the total number of references is 6. Then, the total number of references is divided by the total number of high-risk functions to obtain the use frequency of the parameter. If there are 5 high-risk functions, the use frequency of the parameter is 6 / 5 = 1.2. The higher the frequency value is, the higher the activity level of the input parameter in the high-risk region is.

[0059] Subsequently, the use depth of the input parameters in the high-risk regions is calculated, which can be achieved by using the method of call chain level tracing. Specifically, the transmission path of the input parameter between high-risk code units is tracked from the entry of the first high-risk function where the input parameter is transmitted, and if the input parameter is used only in the first high-risk function and is not transmitted to other high-risk functions, the use depth is recorded as 1. If the input parameter is transmitted from the first high-risk function to the second high-risk function and is used in the second high-risk function, the use depth is recorded as 2. The maximum transmission level is the use depth of the input parameter. The higher the depth value is, the wider the influence range of the input parameter on the high-risk region is.

[0060] Finally, the obtained usage frequency and usage depth are quantitatively integrated to obtain the correlation degree: the usage frequency and the usage depth are normalized to the interval of 0-1, for example, if the maximum value of the usage frequency is 2, the frequency of a certain parameter is 1.2, which is normalized to 1.2 / 2=0.6; if the maximum value of the usage depth is 3, the depth of a certain parameter is 2, which is normalized to 2 / 3=0.67, and the same weight is allocated to the two, that is, each accounts for 0.5, and 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 input parameter correlation degree of the above example is 0.6*0.5+0.67*0.5=0.635.

[0061] By locking the analysis range by means of the static code analysis tool, calculating the usage frequency and depth by combining text retrieval and call chain tracing, and then obtaining the correlation degree by simple weighting, the effect of accurately quantifying the correlation degree of the input parameters and the high-risk area and providing a reliable basis for subsequent dynamic risk weight allocation of the input parameters is achieved.

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

[0063] A value set acquisition unit is configured to analyze a possible value set of all input parameters of the software to be tested; and a basic test suite generation unit is configured to generate the basic test suite covering all two-by-two combinations of the parameters based on the value set by using a two-by-two combination test design method.

[0064] Specifically, first, the input parameters of the software to be tested are obtained by the static code analysis tool PMD in the foregoing step, and then the possible value set of the input parameters is determined. For each input parameter, the parameter verification logic in the code is checked, for example, a certain input parameter is the order amount which needs to be greater than 0 and less than 100000, and then the reasonable value range is determined, and the edge values such as null values, out-of-range values and special characters are supplemented by referring to the historical test cases and defect records of the project, for example, the value set of a certain input parameter of the payment method is arranged as WeChat payment, Alipay payment, null value, invalid code and the like, and finally a complete possible value set is formed for each input parameter.

[0065] Then, based on the above value set, the two-by-two combination test design tool AllPairs is used to generate the basic test suite. First, arrange each input parameter and its value set in the format of parameter name-value list into table data in the Excel table, and then import the table into the AllPairs tool. The tool will automatically traverse all the combination relationships between the parameters according to the two-by-two combination rule, and generate test cases that do not repeat and cover all two-by-two combinations. For example, if there are order amount and value range 100, 5000, -10, payment method and value range WeChat payment, Alipay payment, for these two input parameters, the test design tool will generate test cases of 100+WeChat payment, 100+Alipay payment, 5000+WeChat payment, 5000+Alipay payment, -10+WeChat payment, -10+Alipay payment, to ensure coverage of all two-by-two combinations between input parameters, and finally form the basic test suite.

[0066] By means of static code analysis tool to determine the input parameters and value set, using two-by-two combination test tool to generate test cases, it achieves the effect of controlling the number of test cases while fully covering the key interaction scenarios of parameters, and provides a reliable basis for subsequent test case optimization.

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

[0068] A high-risk parameter acquisition subunit is configured to identify the top N high-risk parameters with risk weights greater than a preset weight threshold according to the dynamic risk weights. A supplementary test case generation subunit is configured to additionally generate supplementary test cases covering all parameter value combinations on the basis of two-by-two combinations for the top N high-risk parameters. A basic test suite supplementing subunit is configured to supplement the supplementary test cases into the basic test suite.

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

[0070] Next, set a preset weight threshold, which can refer to the weight distribution of high-risk parameters in past tests. For example, if the lowest weight value of high-risk parameters in historical data is 0.6, the preset weight threshold is set to 0.6. Then, sort the input parameters in the Excel table in descending order of risk weight, and then retain the input parameters with weight values greater than 0.6 through the filtering function. Finally, select the top N high-risk parameters from the filtered results. For example, if N=3, these three input parameters are the high-risk parameters that need to be focused on, and the identification of high-risk parameters is thus completed.

[0071] Then, the supplementary test cases are generated for the first N high-risk parameters. Specifically: first, the possible value set of each high-risk parameter is determined, which is the same as the value set obtained by the value set obtaining unit. For example, the values of the three high-risk parameters are order amount, 100, 5000, and -10; payment method, WeChat payment and Alipay payment; and user level, VIP and ordinary user. Then, the value set of the three parameters is fully permuted by using the Cartesian product nested formula of Excel, and a multi-level formula is constructed to enable each value of each parameter to be matched with all values of other parameters one by one, to generate all possible value combinations, such as 100+WeChat payment+VIP, 100+WeChat payment+ordinary user, 5000+Alipay payment+VIP, and the like. These combinations are the supplementary test cases generated on the basis of two-by-two combinations and covering all parameter value combinations.

[0072] Finally, the supplementary test cases are supplemented to the basic test suite obtained by the value set obtaining unit. First, the generated supplementary test cases are arranged according to the format specification of the basic test suite, and fields such as supplementary test case ID, input parameter combination, and test scene description are uniformly included to ensure consistency. Then, the test case management tool TestRail is used to import the existing basic test suite, and then the batch import function of the tool is used to select the file of the supplementary test cases in Excel format and specify the operation option of adding to the existing basic test suite. The tool will automatically merge the supplementary test cases with the original test cases in the basic test suite to form a complete basic test suite containing the supplementary test cases.

[0073] By using Excel to arrange and select high-risk parameters, using a table tool to generate fully combined supplementary test cases, and using a test management tool to merge the suite, the coverage of high-risk parameter testing is strengthened, and the effectiveness of the basic test suite for testing high-risk links of software is improved.

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

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

[0076] Specifically, first, the interface definition is parsed and the input parameter type and the return type are extracted for each test case in the test case set. The software interface corresponding to the test case is found first. If the project has a standardized interface document, such as a Swagger document or a Postman interface collection, the interface details page in the document is directly opened, and the type annotation of each input parameter is checked in the request parameter module, such as the username annotated as a string type and the age annotated as an integer type. The return type of the interface is determined in the response example or the return parameter module, such as returning a JSON object, a Boolean value, or a string. If there is no interface document, the source code file to which the interface belongs can be scanned by a static code analysis tool PMD. The tool automatically identifies the parameter declaration and return value definition of the interface function and outputs the input parameter type and the return type list. Finally, the parameter type and the return type information of each test case are sorted out.

[0077] Then, the general property test template is matched from the predefined property template library based on the extracted input parameter type and the return type. Specifically, the property template library is first built, and the templates are stored in an Excel table or a text file. The table takes the input parameter type combination-return type as the row title, and the corresponding column fills in the general template content. For example, the template corresponding to the string+integer-Boolean value is that the first input parameter (string) should satisfy the non-empty verification, the second input parameter (integer) should be within a reasonable value range, and the return result (Boolean value) should be consistent with the business rule. When performing matching, the parameter type and the return type of a certain test case obtained in the above steps are used to find the completely corresponding row title in the property template library, and the template content of the row is directly obtained. If there are multiple adaptive templates, such as the non-empty verification and format verification templates corresponding to the same type combination, all of them are extracted for standby use.

[0078] Then, the specific input data of the test case is substituted into the property test template to instantiate an executable property test assertion, which can be implemented by using a text replacement method. First, the specific input data of the test case is viewed, for example, the input parameters of a certain test case are username: test001, age: 25, and the return type is a Boolean value. Then, the matched property test template is opened, the placeholders in the template are identified, examples are the first input parameter, the second input parameter, and the return result, and the specific input data is substituted into the placeholders one by one, for example, the first input parameter (string) in the property test template should satisfy the non-empty check is replaced by the input parameter username (string) should satisfy the non-empty check, the specific value is test001, the return result (Boolean) should be consistent with the business rule and the core check logic is retained, the return result (Boolean) should meet the business judgment rule of user login success / failure, and finally the property test assertion directly used for verification is obtained.

[0079] Finally, the property test assertion is bound to the corresponding test case to form a complete test case. If a test case management tool such as TestRail or Zen is used, the target test case is first found in the corresponding tool, the test case editing page is entered, and in the expected result or assertion configuration module, the instantiated property test assertion is entered line by line. If an Excel table is used to manage test cases, a property test assertion column can be added to the above Excel table, and the assertion content corresponding to each test case is filled into the column of the corresponding row to ensure that each test case has a dedicated assertion associated with it, and finally a complete test case containing input data, execution steps, and expected output verification, i.e., property test assertion, is formed.

[0080] By using the interface document and the static analysis tool to extract type information, using a basic table to manage and match templates, generating assertions by text replacement, and binding test cases and property test assertions, the effect of supplementing expected output verification logic for risk-oriented test cases, making test cases more complete, and improving software testing accuracy is achieved.

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

[0082] The Docker image acquisition unit is configured to package the test case set, the to-be-tested software version, and the running environment into a plurality of independent Docker images; the test case set execution unit is configured to, in the continuous deployment platform, start instances of the plurality of Docker images in an isolated container cluster in parallel by calling a container orchestration tool, to concurrently execute the test case set; during execution, the test case set execution unit is configured to monitor and collect the execution result, the code coverage data, and the system resource consumption index of each test case in real time; and the test report acquisition unit is configured to aggregate the execution result, the code coverage data, and the system resource consumption index of each test case to a central analysis platform, and generate a test report.

[0083] In the embodiments of the present application, the Docker image is a lightweight and portable packaging format, which contains an application program including a test case set, to-be-tested software, and a dependent environment required for running, and can ensure consistent running effect of the application program in different environments.

[0084] Specifically, first, a Dockerfile file is created locally through a Docker tool, and a base image is specified in the file, for example, an openjdk:11 image is selected based on a Java project, and a python:3.9 image is selected based on a Python project; then, an installation package of to-be-tested software, a test case set folder, and environment dependent files required for running including a configuration file and a third-party library installation script are copied to a specified directory of the image through a COPY command.

[0085] Then, a RUN command is added to perform environment initialization operations, for example, to install dependent libraries and configure environment variables, so as to ensure that the image can directly run the test after being started. After that, the directory where the Dockerfile is located is entered in the command line, and a Docker build command is executed; according to the module division of the test case set, for example, the test case set is divided into payment test and login test according to function modules, a plurality of independent images are generated, each image corresponds to a test module, which facilitates subsequent parallel execution, and finally, an independent Docker image set containing a test case set, to-be-tested software, and a running environment is obtained.

[0086] Then, the execution of the test case set in the continuous deployment platform can be assisted by the commonly used continuous deployment tool Jenkins and the container orchestration tool Docker Compose. First, a new build task is created in Jenkins, the source code pull address of the task is configured, it is ensured that the packaged Docker image can be obtained, then the execution command is added in the build step of the task, and the Docker Compose tool is called. The number of instances of each Docker image, the network mode and the resource limit are defined in the Docker Compose configuration file, after the execution command is executed, the tool starts all Docker image instances in parallel in an isolated container cluster, and each instance independently runs the test case set of the corresponding module. During the execution process, the test progress is viewed in real time through the console output function of Jenkins, the CPU and memory usage of each container, that is, the system resource consumption index, is monitored by using the stats command of Docker, the code coverage data is collected by using the code coverage tool JaCoCo, and the execution result of each test case, that is, success, failure and failure reason, is recorded by using a text log, so that all key data can be captured in real time.

[0087] Finally, the execution result log, the code coverage report and the system resource consumption statistical data collected during the execution process are integrated by using a Jenkins plug-in or a Python script, the script parses the log file to extract the execution state of the test case, converts the coverage data into an intuitive percentage, and summarizes the average value and the peak value of the resource consumption. Then, the integrated data is generated into an HTML format test report, which includes a test pass rate, a coverage rate reaching a standard, and a resource consumption trend chart, and the test report is uploaded to a central analysis platform. The platform can be built into a simple Web platform by using Nginx, and supports browser access. At the same time, the original data including the execution result details and the coverage raw data are stored in the database of the central analysis platform, which is convenient for subsequent tracing and analysis, and finally a complete test report that can be viewed at any time is formed.

[0088] By packaging the image by using the Docker tool, implementing concurrent test execution by using Jenkins and the Docker Compose, and gathering data to generate a report by relying on the central analysis platform, the concurrent execution of the test case set is efficiently completed, the key indicators in the test process are monitored in real time, the complete test report that can be traced is generated, and the effect of improving the software test efficiency and the result availability is achieved.

[0089] In a possible implementation manner, the software test algorithm execution module 40 further includes:

[0090] The real defect information acquisition subunit is configured to extract all newly discovered and verified real defect information in the high-risk area from the test report; the positive sample acquisition subunit is configured 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; and the prediction accuracy optimization subunit is configured to periodically perform incremental training on the risk prediction model using the updated training samples to optimize the prediction accuracy of the model for the high-risk area in future software versions.

[0091] Specifically, first, real defect information of the high-risk area is extracted from the test report. The test report is presented in an HTM format. The defect statistics module in the test report is opened first, and defect entries related to the high-risk area are found. The test report clearly indicates the code module to which the defect belongs, and corresponds to the risk heat map generated in the foregoing step to determine whether it belongs to the high-risk area. Then, the authenticity of these defects is verified: according to the test case steps recorded in the test report, the test is re-executed in the test environment of the software to be tested, and it is observed whether the same defect can be reproduced. If it is reproduced multiple times, it is determined to be a real defect. Then, the key information of the real defect, including defect description, code module to which the defect belongs, and trigger condition, is sorted into a list, and the defect information extraction step for the high-risk area is completed.

[0092] Then, the defect information and associated data are sorted into new positive samples and supplemented to the training samples: first, the code metadata associated with the defect is obtained, the history of the code module to which the defect belongs is found from the version control system, the code cyclomatic complexity, the recent change frequency, and the number of code lines of the module are counted; then, the associated project management data is retrieved from the project management system, including the functional priority of the defect-related requirement, the historical defect density of the module, and the experience level of the code submitter. Subsequently, the original training sample format, such as the CSV file format, is referred to, which contains code metadata-project management data-risk probability label fields, the sorted defect information and associated data are filled in, and the risk probability label is labeled for the new sample. For real defect information, the label value is set and represents 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 the updated samples. The XGBoost library of Python is selected as the incremental training tool. The original model file is loaded and the updated training sample set is read for incremental training. The training period is set, for example, once a week, which is synchronized with the project iteration period. The incremental training operation is performed: the original model is fine-tuned only using the new samples through the incremental training interface of XGBoost, avoiding retraining of all samples to save time. After training, the reserved test sample set is used to verify the model accuracy, that is, the prediction accuracy of the high-risk area before and after training is compared to ensure that the prediction accuracy of the risk prediction model for the high-risk area of the future software version is optimized.

[0094] By screening and reproducing verification to extract real defects, correlating and calling data, and sorting new samples, and periodically incrementally training the model with commonly used tools, the effect of continuously supplementing model training data and optimizing the prediction accuracy of the model for the high-risk area of future software is achieved.

[0095] In summary, the software test case automatic generation system based on artificial intelligence provided by the embodiments of the present application has the following technical effects:

[0096] The embodiments of the present application collect the code metadata of the software version to be tested, and obtain the associated project management data from the project management system. The pre-trained risk prediction model analyzes and processes to obtain the risk heat map identifying the high-risk code modules and functions and the dynamic risk weight of the software input parameters. The basic test suite is generated based on the input parameters and the dynamic risk weight, and the complete combination test case of the high-risk parameters is supplemented. The search-based software testing algorithm is started to evolve based on the basic test suite as the initial population, wherein the fitness function is composed of the code coverage index and the dynamic risk weight. The risk prediction model is incrementally trained by combining the test case execution result and the newly discovered defect data, thereby accurately generating the software test case set with risk orientation. The software test can focus on covering the high-risk area, improving the accuracy and efficiency of software defect detection, achieving the technical effect of accurately identifying the high-risk link of software, and the generated test case is more targeted, improving the software testing efficiency and the accuracy of software quality evaluation.

[0097] Embodiment two, as shown in Figure 2 The embodiments of the present application provide a software test case automatic generation method based on artificial intelligence, which comprises:

[0098] The code metadata of the to-be-tested software version is collected, and the associated project management data is obtained from a project management system; the code metadata and the project management data are input into a pre-trained risk prediction model, a risk heat map for identifying high-risk code modules and functions is output, and a dynamic risk weight is assigned to an input parameter of the software; based on the input parameter and the dynamic risk weight, a basic test suite is generated by using a combination test design rule; the basic test suite is taken as an initial population, and a search-based software test algorithm is started, wherein an adaptability function of the software test algorithm is composed of a code coverage rate index and the dynamic risk weight, and a risk-oriented test case set is generated by iterative evolution.

[0099] Further, the embodiments of the application further include:

[0100] The code metadata includes code cyclomatic complexity, code change frequency, and code line number; the project management data includes functional priority of associated requirements, historical defect density, and experience level of a code submitter.

[0101] Further, the code metadata and the project management data are input into a pre-trained risk prediction model, a risk heat map for identifying high-risk code modules and functions is output, and a dynamic risk weight is assigned to an input parameter of the software, and the embodiments of the application further include:

[0102] Training samples are extracted from historical data of a version control system and a project management system, wherein each sample contains code metadata, project management data, and a label indicating a risk probability of the code module; the training samples are trained by using a gradient boosting decision tree to generate the risk prediction model; the code metadata and the project management data are analyzed by using the risk prediction model, code modules and functions with a risk probability value higher than a preset threshold are marked as high-risk areas, the risk heat map is generated; all input parameters of the to-be-tested software are identified, the association degree of each input parameter with the high-risk areas is analyzed, a quantitative weight is assigned to each input parameter based on the association degree, and the dynamic risk weight is obtained.

[0103] Further, the embodiments of the application further include:

[0104] The association degree is calculated by the frequency and depth of use of the parameter in the function or code module in the high-risk area.

[0105] Further, based on the input parameter and the dynamic risk weight, a basic test suite is generated by using a combination test design rule, and the embodiments of the application further include:

[0106] analyzing a value set of all input parameters of the software to be tested; based on the value set, generating the basic test suite covering all two-by-two combinations of the parameters by using a two-by-two combination test design method.

[0107] Further, generating the basic test suite, the embodiment of the present application further comprises:

[0108] According to the dynamic risk weight, the first N high-risk parameters with a risk weight greater than a preset weight threshold are identified; on the basis of two-by-two combination, the supplementary test cases covering all value combinations of the parameters are additionally generated for the first N high-risk parameters; and the supplementary test cases are supplemented to the basic test suite.

[0109] Further, after generating the test case set with risk guidance, the embodiment of the present application further comprises:

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

[0111] Further, after generating the test case set with risk guidance, the embodiment of the present application further comprises:

[0112] The test case set, the software version to be tested, and the running environment are packaged into independent multiple Docker images; in the continuous deployment platform, the instances of the multiple Docker images are started in parallel in an isolated container cluster by calling a container orchestration tool, so that the test case set is executed concurrently, and during the execution process, the execution results, the code coverage data, and the system resource consumption indicators of each test case are monitored and collected in real time; the execution results, the code coverage data, and the system resource consumption indicators of each test case are converged to a central analysis platform, and a test report is generated.

[0113] Further, after generating the test report, the embodiment of the present application further comprises:

[0114] All newly discovered and verified defect information in the high-risk area is extracted from the test report; the defect information and the associated code metadata and project management data are added to the training samples of the risk prediction model as new positive samples; and the risk prediction model is incrementally trained using the updated training samples to optimize the prediction accuracy of the model for the high-risk area in future software versions.

[0115] The foregoing detailed description of the application has shown by way of illustration one preferred embodiment of a software test case automatic generation system based on artificial intelligence. Those skilled in the art can clearly understand a software test case automatic generation method based on artificial intelligence in the embodiment. For the method disclosed in Embodiment Two, since it corresponds to the system disclosed in Embodiment One, it has corresponding execution steps and technical effects. For the related parts, refer to the system part description.

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

Claims

1. An artificial intelligence based software test case automatic generation system characterized in that, The application relates to a software testing method based on risk-oriented test suite generation, which comprises the following steps: a project management data acquisition module is used to collect code metadata of a software version to be tested and simultaneously acquire associated project management data from a project management system; a dynamic risk weight allocation module is used to input the code metadata and the project management data into a pre-trained risk prediction model, output a risk heat map for identifying high-risk code modules and functions, and allocate dynamic risk weights to input parameters of the software; a basic test suite generation module is used to generate a basic test suite based on the input parameters and the dynamic risk weights by using a combination test design rule; a software testing algorithm execution module is used to start a search-based software testing algorithm by taking the basic test suite as an initial population, wherein an adaptability function of the software testing algorithm is composed of a code coverage rate index and the dynamic risk weights, and a risk-oriented test case set is generated by iterative evolution.

2. The system for automatic generation of software test cases based on artificial intelligence as claimed in claim 1 wherein, The code metadata comprises code ring complexity, code change frequency and code line number; the project management data comprises functional priority of associated requirements, historical defect density and experience level of a code submitter.

3. The system for automatic generation of software test cases based on artificial intelligence as claimed in claim 1 wherein, The code metadata and the project management data are input into a pre-trained risk prediction model, a risk heat map for identifying high-risk code modules and functions is output, and dynamic risk weights are allocated to input parameters of the software, which comprises the following steps: a training sample acquisition unit is used to extract training samples from historical data of a version control system and a project management system, wherein each sample contains code metadata, project management data and a label indicating a risk probability of the code module; a risk prediction model construction unit is used to train the training samples by using gradient boosting decision trees to generate the risk prediction model; a risk heat map generation unit is used to analyze the code metadata and the project management data by using the risk prediction model, mark code modules and functions with a risk probability value higher than a preset threshold as high-risk areas, and generate the risk heat map; a dynamic risk weight acquisition unit is used to identify all input parameters of the software to be tested, analyze the correlation degree of each input parameter with the high-risk areas, allocate a quantitative weight to each input parameter based on the correlation degree, and obtain the dynamic risk weights.

4. The system as claimed in claim 3, wherein, The correlation degree is calculated by the frequency and depth of use of the parameters in the function or code module of the high-risk areas.

5. The system for automatic generation of software test cases based on artificial intelligence as claimed in claim 1 wherein, The basic test suite is generated based on the input parameters and the dynamic risk weights by using a combination test design rule, which comprises the following steps: a value set acquisition unit is used to analyze possible value sets of all input parameters of the software to be tested; a basic test suite generation unit is used to generate the basic test suite covering all two-by-two combinations of parameters by using a two-by-two combination test design method based on the value sets.

6. The system as claimed in claim 5, wherein, The basic test suite is generated by further comprising the following steps: a high-risk parameter acquisition subunit is used to identify the first N high-risk parameters with risk weights greater than a preset weight threshold based on the dynamic risk weights. The supplementary test case generation subunit is configured to generate, on the basis of two-by-two combination, supplementary test cases covering all parameter value complete combinations for the first N high-risk parameters; The basic test suite supplement subunit is configured to supplement the supplementary test cases to the basic test suite.

7. The system for automatic generation of software test cases based on artificial intelligence as claimed in claim 1 wherein, After the test case set with risk orientation is generated, the following is further included: The interface definition analysis subunit is configured to analyze interface definitions and extract input parameter types and return types for each test case in the test case set; The attribute test template matching subunit is configured to match one or more general attribute test templates from a predefined attribute template library based on the input parameter types and return types; The input data substitution subunit is configured to substitute specific input data of the test case into the attribute test template to instantiate an executable attribute test assertion; The complete test case acquisition subunit is configured to bind the attribute test assertion and the corresponding test case to form a complete test case containing input data and expected output verification.

8. The system for automatic generation of software test cases based on artificial intelligence as claimed in claim 1 wherein, After the test case set with risk orientation is generated, the following is further included: The Docker image acquisition subunit is configured to package the test case set, a software version to be tested, and a running environment into independent Docker images; The test case set execution subunit is configured to start instances of the Docker images in an isolated container cluster in parallel by calling a container orchestration tool in a continuous deployment platform to concurrently execute the test case set, and to monitor and collect execution results, code coverage data, and system resource consumption indicators of each test case in real time during execution; The test report acquisition subunit is configured to aggregate the execution results, code coverage data, and system resource consumption indicators of each test case to a central analysis platform and generate a test report.

9. The system for automatic generation of software test cases based on artificial intelligence as claimed in claim 8 wherein, After the test report is generated, the following is further included: The real defect information acquisition subunit is configured to extract all newly discovered and verified real defect information in high-risk areas from the test report; The positive sample acquisition subunit is configured to add the defect information and associated code metadata and project management data as new positive samples to training samples of the risk prediction model; The prediction accuracy optimization subunit is configured to periodically perform incremental training on the risk prediction model using the updated training samples to optimize the prediction accuracy of the model for high-risk areas in future software versions.

10. An artificial intelligence based software test case automatic generation method, characterized by, The method is implemented by the software test case automatic generation system based on artificial intelligence in any one of claims 1-9, and the method includes: Code metadata of a software version to be tested is collected, and associated project management data is obtained from a project management system; The code metadata and the project management data are input into a pre-trained risk prediction model to output a risk heat map for identifying high-risk code modules and functions, and to assign dynamic risk weights to input parameters of the software; A basic test suite is generated based on the input parameters and the dynamic risk weights and using combination test design rules; A search-based software testing algorithm is started with the basic test suite as initial population, wherein the fitness function of the software testing algorithm is composed of the code coverage indicator and the dynamic risk weight, and a risk-oriented test case set is generated through iterative evolution.

Images