Test case generation method and system based on large language model

Abstract

The present invention relates to the field of software testing technology, and specifically discloses a test case generation method and system based on a large language model, which performs analysis based on the functional requirements and design documents of a test system to obtain a main function coverage scenario; obtains a secondary function coverage scenario based on the external environment conditions of the test system; performs user behavior analysis and sentiment analysis based on user group data of the test system to obtain an auxiliary function coverage scenario; determines the functional test requirements of the test system based on the main function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario; and generates test cases based on the functional test requirements R using a large language model. The method can improve the accuracy and comprehensiveness of test case generation to ensure software quality and stability through more complete testing.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to a test case generation method and system based on a large language model. Background Art

[0002] With the development of Large Language Models (LLMs), LLMs have been performing better and better in natural language processing and understanding. In recent years, LLMs have been increasingly used in software engineering, especially in automated test case generation. Traditional test case generation methods usually rely on manual writing, which is time-consuming and prone to missing important functions and boundary conditions.

[0003] Therefore, it is necessary to provide a test case generation method and system based on a large language model. Summary of the invention

[0004] The purpose of the present invention is to provide a test case generation method and system based on a large language model to solve the following technical problems: improve the accuracy and comprehensiveness of test case generation to ensure software quality and stability through more complete testing.

[0005] The purpose of the present invention can be achieved through the following technical solutions:

[0006] A test case generation method based on a large language model, the method comprising the following steps:

[0007] Obtain functional requirements and design documents for the test system;

[0008] Analyze the functional requirements and design documents to obtain the main functional coverage scenarios; the functional coverage scenarios include the main functional points and boundary conditions of the test system;

[0009] Acquiring external environmental conditions of the test system;

[0010] Based on the external environment conditions, a secondary function coverage scenario is obtained; the secondary function coverage scenario includes network status, database connection, API call, device hardware and server status;

[0011] Acquiring user group data of the test system;

[0012] Performing user behavior analysis and sentiment analysis based on the user group data to obtain auxiliary function coverage scenarios; the auxiliary function coverage scenarios include user input situations under different behaviors and different emotions;

[0013] Based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario, the functional test requirement R of the test system is determined as follows: 1 、r 2 ,……,r n};

[0014] Based on the functional test requirement R, the large language model is used to generate the test case T={t 1 ,t 2 ,……,t n};

[0015] ;

[0016] Among them, P (t j |r i ) indicates that given the functional test requirement r i When the large language model generates test cases t j The probability of score (t j , r i ) is the generated use case t calculated by the large language model j and functional requirements i The matching degree between j represents the jth test case, r i represents the i-th functional test requirement, and j' is the index of other test cases.

[0017] As a further solution of the present invention, determining the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario includes:

[0018] Determining input data for generating test cases based on the primary function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario;

[0019] Acquire input data types related to a test target of the test system;

[0020] A random disturbance is added to the input data based on the input data type to determine a functional test requirement R of the test system.

[0021] As a further solution of the present invention, the adding of random disturbances to the input data based on the input data type to determine the functional test requirement R of the test system includes:

[0022] Based on the input data type, generate a random number through a normal distribution model;

[0023] The random number is added to the input data to determine the functional test requirement R of the test system.

[0024] As a further solution of the present invention, the normal distribution model is:

[0025] ;

[0026] Wherein, P(x) represents the probability density of the generated random number, u represents the mean of the random data corresponding to the input data type, and σ is the standard deviation, which is used to control the fluctuation range of the random number.

[0027] As a further embodiment of the present invention, the standard deviation is determined by the following formula:

[0028] ;

[0029] Among them, σ is the determined standard deviation, σ 0 is the initial standard deviation, α is the adjustment factor, N missed is the number of test cases not covered by historical tests, N total The total number of test cases for historical tests.

[0030] As a further solution of the present invention, determining the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario includes:

[0031] Determining input data for generating test cases based on the primary function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario;

[0032] Acquire a plurality of test scenarios related to a test objective of the test system;

[0033] Determine the generation probability of assigning test cases to each test scenario;

[0034] Based on the input data of the test case and the generation probability, a functional test requirement R of the test system is determined.

[0035] As a further solution of the present invention, determining the generation probability of assigning test cases to each test scenario includes:

[0036] The probability of generating test cases assigned to each test scenario is determined by weighted random selection; wherein the weighted random selection is performed by the following formula:

[0037] ;

[0038] P(scene i) is the probability of generating scene i, Wi is the weight of scene i;

[0039] Among them, the weight Wi is determined by the following formula:

[0040] ;

[0041] in, is the weight of scenario i in historical testing, β is the weight adjustment factor, M failed is the number of test failure scenarios, M total is the total number of test scenarios.

[0042] A test case generation system based on a large language model, the system comprising:

[0043] A first data acquisition module, used to acquire functional requirements and design documents of the test system;

[0044] A first scenario acquisition module is configured to parse the functional requirements and design documents to acquire a main functional coverage scenario, wherein the functional coverage scenario includes the main functional points and boundary conditions of the test system;

[0045] A second data acquisition module, used to acquire external environmental conditions of the test system;

[0046] A second scenario acquisition module is used to acquire a secondary function coverage scenario based on the external environment conditions; the secondary function coverage scenario includes network status, database connection, API call, device hardware and server status;

[0047] A third data acquisition module, used to acquire user group data of the test system;

[0048] A third scenario acquisition module is used to perform user behavior analysis and sentiment analysis based on the user group data to acquire auxiliary function coverage scenarios; the auxiliary function coverage scenarios include user input situations under different behaviors and different emotions;

[0049] A functional test requirement determination module is used to determine the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario. 1 、r 2 ,……,r n};

[0050] The test case generation module is used to generate a test case T={t 1 ,t 2 ,……,t n};

[0051] ;

[0052] Among them, P (t j |r i ) indicates that given the functional test requirement r i When the large language model generates test cases t j The probability of score (t j , r i ) is the generated use case t calculated by the large language model j and functional requirements i The matching degree between j represents the jth test case, r i represents the i-th functional test requirement, and j' is the index of other test cases.

[0053] The beneficial effects of the present invention are as follows: (1) By combining the large language model to automatically identify and generate functional coverage scenarios, it is possible to ensure comprehensive testing of each key function in the software system. Not only can it cover the main functions, but it can also be extended to the testing of secondary functions and auxiliary functions, thereby ensuring the comprehensiveness of the test; (2) By dynamically adjusting the generation weight of each test scenario through historical test data, feedback from failed scenarios, and changes in test requirements, it is possible to effectively avoid test bias in traditional methods, ensure that scenarios with high risks or frequent historical problems are tested first, and thus optimize the allocation of test cases; (3) Based on the natural language processing capabilities of the large language model, the system can automatically generate test cases related to the requirements, reduce the workload of manually writing test cases, and respond to user feedback in real time to optimize and adjust the test cases to ensure consistency between the test and actual requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] The present invention will be further described below in conjunction with the accompanying drawings.

[0055] Figure 1 It is a flow chart of the test case generation method based on the large language model of the present invention. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0057] See also Figure 1 As shown, the present invention is a test case generation method based on a large language model. In some embodiments, Figure 1The process 100 shown may be executed by an electronic device or a processor. The process 100 may include the following operations.

[0058] Step 101, obtaining functional requirements and design documents of the test system.

[0059] Functional requirements refer to the functions and performance requirements that the system needs to complete, which can include the main functions of the system, interface specifications, behavior descriptions, and expected performance standards. Design documents include documents that describe system architecture, module design, data structure, interface definition, etc., which can be used to guide development and testing work.

[0060] In some embodiments, the obtained functional requirement documents and design documents of the test system may be provided by the development team, for example, and may be accessed through a project management tool (such as Jira, Confluence, etc.) or a version control system (such as Git).

[0061] Step 102, performing analysis based on the functional requirements and design documents to obtain main functional coverage scenarios; the functional coverage scenarios include main functional points and boundary conditions of the test system.

[0062] Functional requirement analysis refers to analyzing the system's functions, operating procedures, interfaces and expected behaviors based on the functional requirement document.

[0063] The main function coverage scenarios refer to the core functional points and key operating conditions of the test system, which may include the main operations and boundary conditions that the system should perform.

[0064] In some embodiments, the functional requirements document can be parsed using natural language processing (NLP) technology to extract the main functional points of the system, such as user login, data storage, request processing, etc. Based on the module description in the design document, the core functions of each module and possible boundary conditions (such as input range, exception handling, etc.) can be identified. After that, the parsing results can be organized into main functional scenarios.

[0065] For example, scenario 1: user login function; scenario 2: data processing function; scenario 3: error handling and boundary conditions.

[0066] Step 103: Acquire the external environmental conditions of the test system.

[0067] External environmental conditions refer to external factors that affect system operation, such as network status, database status, server load, etc.

[0068] In some embodiments, the processor may collect a detailed description of the external environment on which the system depends, for example, network conditions (such as bandwidth, latency, packet loss rate, etc.), database connection status (such as number of connections, latency, etc.), API call restrictions (such as rate limits, permission verification, etc.), device hardware configuration and status, and server load and response conditions.

[0069] External environmental conditions can be obtained through monitoring tools or system logs.

[0070] Step 104, based on the external environmental conditions, obtain secondary function coverage scenarios; the secondary function coverage scenarios include network conditions, database connections, API calls, device hardware, and server status.

[0071] Secondary functional coverage scenarios refer to the behavior of the test system under specific external environmental conditions, which can include tests on system stability, reliability, adaptability, etc. For example, the system's response to network fluctuations or database anomalies.

[0072] In some embodiments, the processor can convert the acquired external environment conditions into specific test scenarios. For example, scenario 1: operation under low bandwidth or high latency network conditions; scenario 2: database connection disconnection or timeout; scenario 3: API call failure (such as permission error, rate limit, etc.).

[0073] For each external environmental condition, the primary functional scenario can be expanded by introducing environmental changes to generate secondary functional coverage scenarios.

[0074] Step 105: Acquire user group data of the test system.

[0075] User group data refers to the system's user base, user behavior data, demographic characteristics, etc. User group data can help understand the behavior patterns, needs, and emotional states of system users.

[0076] User group data may include age, gender, geographic location, frequency of use, device type, and other data such as the user's common operating patterns in the system.

[0077] In some embodiments, user behavior data and sentiment analysis results may be collected, for example, through user surveys, user logs, A / B testing, etc.

[0078] Step 106 , performing user behavior analysis and sentiment analysis based on the user group data to obtain auxiliary function coverage scenarios; the auxiliary function coverage scenarios include user input situations under different behaviors and different emotions.

[0079] User behavior analysis refers to analyzing users' operating patterns, such as which functions are frequently used, common operating steps, etc.

[0080] Sentiment analysis refers to analyzing the emotional state of users when using a system. It can be achieved by analyzing unstructured data such as user comments, feedback, and chat records.

[0081] Accessibility coverage scenarios refer to the system's accessibility scenarios under different user behaviors and emotions, including user input, system feedback, etc.

[0082] In some embodiments, the collected user group data can be clustered and classified to determine the typical behavior patterns of different types of users, and sentiment analysis can be performed to identify possible emotional fluctuations of users when using the system (such as pleasure, frustration, anxiety, etc.). Based on the analysis results, corresponding auxiliary function coverage scenarios are generated.

[0083] For example, scenario 1: the user submits incorrect input when feeling anxious; scenario 2: the user performs smooth operations when feeling satisfied.

[0084] Step 107: Based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario, determine the functional test requirement R of the test system = {r 1 、r 2 ,……,r n}.

[0085] Functional test requirement R refers to the set of functional requirements that need to be tested. Each functional test requirement r i Corresponding to a specific function or scenario, it describes the functional requirements that need to be verified under specific conditions.

[0086] In some embodiments, all main functions, secondary functions and auxiliary function scenarios can be summarized to obtain a complete set of functional requirements R.

[0087] In some embodiments, determining the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario may include the following operations.

[0088] S10, determining input data for generating test cases based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario.

[0089] Input data refers to the input information that the test system needs to process in the test case. It can include the input parameters of the test case, input data types, etc.

[0090] In some embodiments, the input data required for each test scenario can be analyzed based on the primary, secondary, and auxiliary function coverage scenarios. For example, for the "primary scenario of user login function", the input data may include username and password. For the "system performance under low bandwidth network" scenario, the input data may include bandwidth limitations, delays, etc. For the "user input behavior under anxiety", the input data may include randomly generated error data or the probability of input errors.

[0091] You can also use natural language processing (NLP) technology to analyze requirement documents and identify the input data required for each functional scenario.

[0092] S11, obtaining input data types related to the test target of the test system.

[0093] Input data type refers to the type of input data involved when the system processes test cases. Input data types can include text, numbers, Boolean values, timestamps, images, etc.

[0094] In some embodiments, the input data in the test requirements can be analyzed to identify the type of each input data, for example, "user name" is a string type, "password" is a string type, "user age" is an integer type, and "bandwidth" is a floating number type.

[0095] The processor can extract the input data type related to each test target according to the test target (such as functional testing, performance testing, etc.). For example, for functional testing, the input data can mainly be field types and user input. For performance testing, the input data can include system load, request rate, etc.

[0096] S12: Add random disturbance to the input data based on the input data type to determine a functional test requirement R of the test system.

[0097] Random perturbations refer to random modifications to input data to test the robustness and fault tolerance of the system to different inputs. Random perturbations can include adding noise, modifying the input value range, changing the order of data, etc.

[0098] In some embodiments, a certain range of random disturbances can be added based on the determined input data type. Specific operations may include: adding or subtracting random numbers to digital input data, changing the precision of numerical values. Randomly deleting, replacing or inserting characters in text data. Reversing Boolean values. The data after adding disturbances still meets the business logic requirements, and the system's response to these disturbance inputs can be tested. For example, for the "user login function", a username and password combination can be randomly generated and tested.

[0099] In some embodiments, adding random disturbances to the input data based on the input data type to determine the functional test requirement R of the test system includes: generating random numbers through a normal distribution model based on the input data type; adding the random numbers to the input data to determine the functional test requirement R of the test system.

[0100] Normal distribution (or Gaussian distribution) is a common probability distribution in mathematics. Data are clustered around the mean, and the probability of data occurrence becomes lower and lower as the distance from the mean increases.

[0101] Random numbers are numerical values ​​generated by random methods such as normal distribution, uniform distribution, etc. They are used to simulate fluctuations or changes in input data to ensure that the test system can handle a variety of possible situations.

[0102] For numeric data, you can add the generated random numbers to the original input data. For example, if the original data is a temperature value of 25°C, and the random perturbation value generated by the normal distribution is +0.3°C, the new input data is 25.3°C.

[0103] For character data, the generated random perturbations can be performed by character replacement or insertion. For example, if the original string is "hello", the generated perturbations can be to change the string to "heLlo" or "hellO".

[0104] In some embodiments, the normal distribution model may be as shown in the following formula (1).

[0105] (1);

[0106] Where P(x) represents the probability density of the generated random numbers, u represents the mean of the random data corresponding to the input data type, and σ is the standard deviation, which is used to control the fluctuation range of the random numbers. Standard deviation σ: is a parameter that describes the degree of data distribution dispersion in the normal distribution. The larger the standard deviation, the wider the fluctuation range of the generated random numbers and the greater the amplitude of data variation. Conversely, the smaller the standard deviation, the smaller the amplitude of data variation.

[0107] In this embodiment, the normal distribution model is used to generate random numbers according to the type of input data. The process includes the following key steps: select the mean and standard deviation, and determine its mean (μ) and standard deviation (σ) according to the type of input data. For example, assuming that the input data is "temperature", its mean may be 20°C and the standard deviation is 2°C. Generate random numbers, use the normal distribution formula, and generate random numbers that conform to the data type through the mean and standard deviation. For example, the random number of temperature may be 22°C, 18°C, etc. (in line with the fluctuation range of the normal distribution). Adjust the fluctuation range, adjust the value of the standard deviation σ according to actual needs, and control the fluctuation range of the generated random numbers. If the fluctuation range needs to be larger, increase σ, and if a smaller fluctuation range is required, reduce σ.

[0108] In some embodiments, the standard deviation is determined by the following formula (2).

[0109] (2);

[0110] Among them, σ is the determined standard deviation, σ 0 is the initial standard deviation, α is the adjustment factor, N missed is the number of test cases not covered by historical tests, N total The total number of test cases for historical tests.

[0111] In this embodiment, the standard deviation σ can be dynamically adjusted according to the historical test coverage to ensure that the fluctuation of the generated random numbers can better reflect the needs of the test scenario, thereby improving the comprehensiveness and accuracy of the test.

[0112] In some embodiments, determining the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario may also include the following operations.

[0113] S20, determining input data for generating a test case based on the primary function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario.

[0114] S21, obtaining a plurality of test scenarios related to the test target of the test system.

[0115] A test scenario is a specific test situation generated during the test process based on the system functional description. A test scenario can include system input, operation process, and expected output, and is designed to verify whether the system works as expected.

[0116] The test objective refers to the specific verification goal that we hope to achieve during the test process, such as verifying the correctness, performance, and reliability of a certain function.

[0117] In some embodiments, the main test objectives of the system can be extracted based on the system requirements analysis. The large language model can automatically identify the key objectives that need to be functionally verified by analyzing the requirements documents, design documents and related user stories.

[0118] In some embodiments, multiple test scenarios related to each test target may be generated. For example, if the test target is to verify the user login function, the corresponding test scenarios may include "enter correct username and password", "enter incorrect username", and "password is empty".

[0119] S22, determining the generation probability of assigning test cases to each test scenario.

[0120] The test case generation probability refers to the probability of each test scenario being selected to generate a test case when generating a test case.

[0121] In some embodiments, a weight may be assigned to each test scenario based on the importance of each test scenario, the priority of the test objectives, the coverage of historical tests, etc. More important scenarios may generally be assigned higher weights, while scenarios of secondary or auxiliary functions may be assigned lower weights.

[0122] In some embodiments, determining the generation probability of assigning a test case to each test scenario may include:

[0123] The probability of generating test cases assigned to each test scenario is determined by weighted random selection, wherein the weighted random selection is performed by the following formula (3).

[0124] (3);

[0125] P(scene i ) is the probability of generating scene i, Wi is the weight of scene i;

[0126] The weight Wi is determined by the following formula (4).

[0127] (4);

[0128] in, is the weight of scenario i in historical testing, β is the weight adjustment factor, M failed is the number of test failure scenarios, M total is the total number of test scenarios.

[0129] S23: Determine a functional test requirement R of the test system based on the input data of the test case and the generation probability.

[0130] In some embodiments, corresponding test cases can be generated according to the generation probability based on the input data and each test scenario, thereby obtaining the functional test requirement R.

[0131] Step 108: Based on the functional test requirement R, a test case T={t 1 ,t 2 ,……,t n}.

[0132] (5);

[0133] Among them, P (t j |r i ) indicates that given the functional test requirement r i When the large language model generates test cases t j The probability of score (t j , r i ) is the generated use case t calculated by the large language model j and functional requirements i The matching degree between j represents the jth test case, r i represents the i-th functional test requirement, and j' is the index of other test cases.

[0134] A large language model refers to a natural language processing model based on deep learning (such as GPT-4, BERT, etc.), which can be used to understand and generate text or other structured data.

[0135] A test case is a specific test case generated based on the test requirements, which includes input data, operation steps, expected output, etc.

[0136] Based on the same inventive concept, the present invention also provides a test case generation system based on a large language model, the system comprising:

[0137] A first data acquisition module, used to acquire functional requirements and design documents of the test system;

[0138] A first scenario acquisition module is configured to parse the functional requirements and design documents to acquire a main functional coverage scenario, wherein the functional coverage scenario includes the main functional points and boundary conditions of the test system;

[0139] A second data acquisition module, used to acquire external environmental conditions of the test system;

[0140] A second scenario acquisition module is used to acquire a secondary function coverage scenario based on the external environment conditions; the secondary function coverage scenario includes network status, database connection, API call, device hardware and server status;

[0141] A third data acquisition module, used to acquire user group data of the test system;

[0142] A third scenario acquisition module is used to perform user behavior analysis and sentiment analysis based on the user group data to acquire auxiliary function coverage scenarios; the auxiliary function coverage scenarios include user input situations under different behaviors and different emotions;

[0143] A functional test requirement determination module is used to determine the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario. 1 、r 2 ,……,r n};

[0144] A test case generation module is used to generate a test case T={t 1 ,t 2 ,……,t n}.

[0145] The working principle of the present invention is as follows: based on the functional requirements and design documents of the test system, the main function coverage scenarios are obtained by parsing; based on the external environment conditions of the test system, the secondary function coverage scenarios are obtained; based on the user group data of the test system, user behavior analysis and sentiment analysis are performed to obtain auxiliary function coverage scenarios; based on the main function coverage scenarios, the secondary function coverage scenarios and the auxiliary function coverage scenarios, the functional test requirements of the test system are determined; based on the functional test requirements R, a large language model is used to generate test cases. By combining the large language model to automatically identify and generate functional coverage scenarios, comprehensive testing of each key function in the software system can be ensured. Not only can it cover the main functions, but it can also be extended to the testing of secondary functions and auxiliary functions, thereby ensuring the comprehensiveness of the test.

[0146] The above is a detailed description of an embodiment of the present invention, but the content is only a preferred embodiment of the present invention and cannot be considered to limit the scope of implementation of the present invention. All equivalent changes and improvements made within the scope of the present invention should still fall within the scope of the patent coverage of the present invention.

Claims

1. A test case generation method based on a large language model, characterized in that: The method comprises the following steps: Obtain functional requirements and design documents for the test system; Based on the functional requirements and design documents, the main functional coverage scenarios are analyzed to obtain the main functional points and boundary conditions of the test system; Acquiring external environmental conditions of the test system; Based on the external environment conditions, a secondary function coverage scenario is obtained; the secondary function coverage scenario includes network status, database connection, API call, device hardware and server status; Acquiring user group data of the test system; Performing user behavior analysis and sentiment analysis based on the user group data to obtain auxiliary function coverage scenarios; the auxiliary function coverage scenarios include user input situations under different behaviors and different emotions; Based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario, the functional test requirement R={r1, r2, ..., r n }; The functional test requirement R refers to a set of functional requirements that need to be tested; Based on the functional test requirement R, the large language model is used to generate the test case T={t1, t2, ..., t n }; ； Among them, P (t j |r i ) indicates that given the functional test requirement r i When the large language model generates test cases t j The probability of score (t j , r i ) is the generated use case t calculated by the large language model j and functional requirements i The matching degree between j represents the jth test case, r i represents the i-th functional test requirement, and j' is the index of other test cases; The determining of the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario includes: Determining input data for generating test cases based on the primary function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario; Acquire input data types related to a test target of the test system; A random disturbance is added to the input data based on the input data type to determine a functional test requirement R of the test system.

2. The test case generation method based on a large language model according to claim 1, characterized in that: The adding random disturbance to the input data based on the input data type to determine the functional test requirement R of the test system includes: Based on the input data type, generate a random number through a normal distribution model; The random number is added to the input data to determine the functional test requirement R of the test system.

3. The test case generation method based on a large language model according to claim 2, characterized in that: The normal distribution model is: ； Wherein, P(x) represents the probability density of the generated random number, u represents the mean of the random data corresponding to the input data type, and σ is the standard deviation, which is used to control the fluctuation range of the random number.

4. The test case generation method based on a large language model according to claim 3, characterized in that: The standard deviation is determined by the following formula: ； Among them, σ is the determined standard deviation, σ0 is the initial standard deviation, α is the adjustment factor, and N missed is the number of test cases not covered by historical tests, N total The total number of test cases for historical tests.

5. The test case generation method based on a large language model according to claim 1, characterized in that: The determining the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario includes: Determining input data for generating test cases based on the primary function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario; Acquire a plurality of test scenarios related to a test objective of the test system; Determine the generation probability of assigning test cases to each test scenario; Based on the input data of the test case and the generation probability, a functional test requirement R of the test system is determined.

6. The test case generation method based on a large language model according to claim 5, characterized in that: The determining of the generation probability of assigning a test case to each test scenario comprises: The probability of generating test cases assigned to each test scenario is determined by weighted random selection; wherein the weighted random selection is performed by the following formula: ； P(scene i ) is the probability of generating scene i, w i is the weight of scene i; Among them, the weight w i Determined by the following formula: ； in, is the weight of scenario i in historical testing, β is the weight adjustment factor, M failed is the number of test failure scenarios, M total is the total number of test scenarios.

7. A test case generation system based on a large language model, characterized in that: The system comprises: A first data acquisition module, used to acquire functional requirements and design documents of the test system; A first scenario acquisition module is configured to parse the functional requirements and design documents to acquire a main functional coverage scenario, wherein the functional coverage scenario includes the main functional points and boundary conditions of the test system; A second data acquisition module, used to acquire external environmental conditions of the test system; A second scenario acquisition module is used to acquire a secondary function coverage scenario based on the external environment conditions; the secondary function coverage scenario includes network status, database connection, API call, device hardware and server status; A third data acquisition module, used to acquire user group data of the test system; A third scenario acquisition module is used to perform user behavior analysis and sentiment analysis based on the user group data to acquire auxiliary function coverage scenarios; the auxiliary function coverage scenarios include user input situations under different behaviors and different emotions; A functional test requirement determination module is used to determine the functional test requirement R={r1, r2, ..., r n }; The functional test requirement R refers to a set of functional requirements that need to be tested; The test case generation module is used to generate a test case T={t1, t2, ..., t n }; ； Among them, P (t j |r i ) indicates that given the functional test requirement r i When the large language model generates test cases t j The probability of score (t j , r i ) is the generated use case t calculated by the large language model j and functional requirements i The matching degree between j represents the jth test case, r i represents the i-th functional test requirement, and j' is the index of other test cases; The determining of the functional test requirement R of the test system based on the primary function coverage scenario, the secondary function coverage scenario and the auxiliary function coverage scenario includes: Determining input data for generating test cases based on the primary function coverage scenario, the secondary function coverage scenario, and the auxiliary function coverage scenario; Acquire input data types related to a test target of the test system; A random disturbance is added to the input data based on the input data type to determine a functional test requirement R of the test system.

Images