Test case generation method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a test case generation method and device, electronic equipment and a storage medium. The method comprises the steps that a requirement document and a technical document are analyzed according to the user story dimension, a scene set under the user story dimension is obtained, the scene set comprises multiple scene cases, each scene case comprises a set of data description information, the set of data description information is used for describing data details of multiple pieces of data needed by the scene case, and the data details of the multiple pieces of data are stored in the scene set; the data details of the data comprise interfaces corresponding to the data; generating a test data pair corresponding to the scene case according to the interface information of the interfaces corresponding to the data required by the scene case and the data description information included in the scene case; and generating a test case corresponding to the scene case based on the scene case and the test data pair corresponding to the scene case. Through the method, the test case can be automatically generated according to the demand document and the technical document corresponding to the demand document, and the generation efficiency and accuracy of the test case are greatly improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly, to a test case generation method, apparatus, electronic device, and storage medium. Background Art

[0002] In the related art, the writing of test cases usually relies on manual experience, which is not only time-consuming and laborious, but also prone to incomplete test coverage or omission of critical paths due to individual understanding differences. In addition, the test data used in test cases is usually generated by manually writing scripts or using predefined data templates. This way of generating test data is not only inefficient but also difficult to ensure the diversity and representativeness of the data. Therefore, the generation efficiency of test cases in the related art is low and not accurate enough. Summary of the Invention

[0003] In view of this, embodiments of the present application propose a test case generation method, apparatus, electronic device, and storage medium, which can automatically generate test cases according to a requirements document and a technical document corresponding to the requirements document, effectively alleviating the problems such as time-consuming, error-prone, and low efficiency in generating test data used in test cases in the related art.

[0004] In a first aspect, embodiments of the present application provide a test case generation method, which includes: obtaining a requirements document and a technical document corresponding to the requirements document; parsing the requirements document and the technical document according to the user story dimension to obtain a set of scenarios in the user story dimension, where the set of scenarios includes multiple scenario use cases, and each scenario use case includes a set of data description information, and this set of data description information is used to describe the data details of multiple data required by the scenario use case, and the data details of the data include the interfaces corresponding to the data; generating a test data pair corresponding to the scenario use case according to the interface information of the interfaces corresponding to the multiple data required by the scenario use case and the data description information included in the scenario use case; generating a test case corresponding to the scenario use case based on the scenario use case and the test data pair corresponding to the scenario use case.

[0005] Second aspect, an embodiment of the present application provides a test case generation device, and the device includes: a document acquisition module, configured to acquire a requirements document and a technical document corresponding to the requirements document; a document parsing module, configured to parse the requirements document and the technical document in terms of user story dimension to obtain a set of scenarios in the user story dimension, the set of scenarios includes a plurality of scenario use cases, and each scenario use case includes a set of data description information, and this set of data description information is used to describe the data details of a plurality of data required for the scenario use case, and the data details of the data include the interfaces corresponding to the data; a test data generation module, configured to generate a test data pair corresponding to the scenario use case according to the interface information of each of the plurality of data required for the scenario use case and the data description information included in the scenario use case; a test case generation module, configured to generate a test case corresponding to the scenario use case based on the scenario use case and the test data pair corresponding to the scenario use case.

[0006] In an implementable manner, the document parsing module includes a first semantic understanding sub-module, a second semantic understanding sub-module, and a scenario set obtaining sub-module; the first semantic understanding sub-module is configured to perform semantic understanding on the requirements document to obtain the business logic in the user story dimension and a set of initial data information corresponding to the business logic, and this set of initial data information is used to describe the initial data details of a plurality of data required for the business logic; the second semantic understanding sub-module is configured to perform semantic understanding on the technical document to obtain an interface set in the user story dimension; the scenario set obtaining sub-module is configured to obtain a set of scenarios in the user story dimension based on the interface set, the business logic, and a set of initial data information corresponding to the business logic in the user story dimension.

[0007] In an implementable manner, the scenario set obtaining sub-module is further configured to match the initial data details of a plurality of data required for the business logic with the interface information of each interface in the interface set to obtain the interfaces corresponding to each of the plurality of data; generate a plurality of scenario use cases based on the business logic, the initial data information corresponding to the business logic, and the interfaces corresponding to each of the plurality of data in the initial data information by using a preset test design method; the plurality of scenario use cases include normal scenario use cases and abnormal scenario use cases, and the preset test design method includes at least one of an equivalence class partitioning test design method and a boundary value test design method.

[0008] In one implementable manner, the first semantic understanding sub-module is further configured to extract features from the requirement document to obtain requirement document features; perform semantic understanding on the requirement document features to obtain a semantic understanding result of the requirement document; extract business logic and a set of initial data information corresponding to the business logic in the dimension of user stories from the semantic understanding result, where the business logic includes core elements, execution steps, and execution conditions of the business, and the set of initial data information corresponding to the business logic includes initial data details of input data and expected output results respectively.

[0009] In one implementable manner, the second semantic understanding sub-module is further configured to perform semantic understanding on the technical document to obtain a semantic understanding result of the technical document; extract a plurality of interfaces and interface information of each of the interfaces from the semantic understanding result of the technical document; divide the extracted plurality of interfaces according to the dimension of user stories to obtain an interface set in the dimension of user stories.

[0010] In one implementable manner, the interface information of the interface includes at least one of the names, types, formats, and constraint conditions corresponding to the request data and the response data of the interface.

[0011] In a third aspect, an embodiment of the present application provides an electronic device, including a processor and a memory; one or more programs are stored in the memory and configured to be executed by the processor to implement the above method.

[0012] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which program code is stored, and when the program code is run by a processor, the above method is executed.

[0013] In a fifth aspect, an embodiment of the present application provides a computer program product or a computer program, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device obtains the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above method.

[0014] A test case generation method, apparatus, electronic device, and storage medium provided by an embodiment of the present application. The method includes: obtaining a requirements document and a technical document corresponding to the requirements document; parsing the requirements document and the technical document according to the user story dimension to obtain a set of scenarios in the user story dimension, where the set of scenarios includes multiple scenario use cases, and each scenario use case includes a set of data description information, and this set of data description information is used to describe the data details of multiple data required for the scenario use case, and the data details of the data include the interfaces corresponding to the data; generating a test data pair corresponding to the scenario use case according to the interface information of the interfaces corresponding to the multiple data required for the scenario use case and the data description information included in the scenario use case; generating a test case corresponding to the scenario use case based on the scenario use case and the test data pair corresponding to the scenario use case. By adopting the above method, it is possible to automatically extract information from the requirements document and the technical document, and automatically generate high-quality test cases based on this information, reducing the dependence on manual experience and making the preparation stage of test cases more efficient; further, automatically generating test data pairs according to the data description information and interface information parsed according to the user story dimension effectively alleviates the problems of time-consuming, error-prone, and low efficiency in generating test data used in generating test cases in the related art. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the accompanying drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present application. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0016] Figure 1 The flowchart showing a test case generation method provided by an embodiment of the present application; Figure 2 Shows Figure 1 The flowchart of step S120 in Figure 3 The schematic diagram showing a test case generation system provided by an embodiment of the present application; Figure 4 The flowchart showing another test case generation method provided by an embodiment of the present application; Figure 5 The connection block diagram showing a test case generation apparatus proposed by an embodiment of the present application; Figure 6 The structure block diagram showing an electronic device for executing the method of the embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0017] Example embodiments will now be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more complete and comprehensive, and will fully convey the concept of the example embodiments to those skilled in the art.

[0018] In addition, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of the embodiments of this application. However, those skilled in the art will realize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, devices, steps, etc. may be used. In other cases, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of this application.

[0019] The block diagrams shown in the drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0020] The flowcharts shown in the drawings are only illustrative and do not necessarily include all the content and operations / steps, nor do they necessarily have to be executed in the order described. For example, some operations / steps can be decomposed, while some operations / steps can be combined or partially combined, so the actual execution order may change according to the actual situation.

[0021] It should be noted that: "a plurality of" mentioned herein refers to two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after.

[0022] In addition, it should be noted that in the embodiments of this application, the collection, use, processing, and storage of application information are all subject to the user's permission and need to comply with the regulations of the region where it is located.

[0023] A test case generation method provided by this application can be applied to an electronic device, which can be a server, a terminal device, a vehicle, or a combination of one or more of the above.

[0024] In some embodiments, the server may be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms.

[0025] The terminal device may be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart voice interaction device, a smart home appliance, a vehicle-mounted terminal, etc., but is not limited thereto.

[0026] Figure 1 Specifically, a test case generation method of the present application is shown. This method can be applied to an electronic device, and the method includes: Step S110: Obtain a requirements document and a technical document corresponding to the requirements document.

[0027] Among them, the requirements document refers to a description of what the system or product should do from the user's perspective, that is, its functional and non-functional requirements. Specifically, the requirements document details the specific operation processes, rules, and expected results involved in the user story, and describes the data items and their attributes required when performing a specific operation, such as name, type, value range, etc.; among them, the user story refers to starting from the user's perspective, emphasizing "as... I hope... so that...", so as to ensure that the developed product truly meets the user's needs.

[0028] The technical document corresponding to the requirements document focuses on the working principle, architecture design, and implementation method of the system or product. It includes all application program (API) interfaces related to the user story. The interface information of each interface may include the interface path, HTTP method, and specific information of the request parameters and response parameters (such as field name, type, whether it is required, default value, allowed value range, etc.), and may also include possible error codes and their corresponding explanations or exception situations.

[0029] It is worth mentioning that the above requirements document and technical document are created based on their respective standardized templates. Among them, the requirements document can adopt Markdown or a table in a specific format, and each user story has fixed fields, such as title, description, acceptance criteria, etc. The technical document can be provided in the form of an API document to provide clear interface paths, parameter descriptions, and response examples.

[0030] Obtain the requirements document uploaded by the user and the technical document corresponding to the requirements document; it is also possible to obtain the requirements document and the technical document corresponding to the requirements document from a preset database or an associated storage device.

[0031] Among them, the requirement document can be a document including functional requirements in one user story dimension, or a document including functional requirements in multiple user story dimensions. When the requirement document includes functional requirements in multiple user story dimensions, the corresponding technical document of the requirement document includes application program (API) interfaces corresponding to the functional requirements in each user story dimension. Among them, each user story dimension corresponds to a set of specific business scenarios. For example, in the business scenario of login verification, there may be the following user story: "As a registered user, I hope to enter the correct username and password to log in to the website so as to access my account." In an implementable manner of the present application, the requirement document is a document including functional requirements in one user story dimension, and it can be obtained by splitting a document including functional requirements in multiple user story dimensions.

[0032] Step S120: Analyze the requirement document and the technical document according to the user story dimension to obtain a set of scenarios in the user story dimension.

[0033] Among them, the set of scenarios includes multiple scenario use cases, and each scenario use case includes a set of data description information, and this set of data description information is used to describe the data details of multiple data required by the scenario use case. The data details of the data include the interfaces corresponding to the data.

[0034] Among them, the set of scenarios corresponding to the user story dimension means that each user story is further refined into a set of specific and operable scenario use cases, and these scenario use cases detail the behaviors that the system should exhibit when implementing this user story. Each scenario use case includes a set of data description information, and this information clarifies the input data required to execute this scenario and its expected results.

[0035] In an implementable manner, if the requirement document and the corresponding technical document are created according to their respective standardized templates, a parser can be called to extract requirement-related information in the user story dimension from the requirement document, such as the title, description, preconditions, operation steps, acceptance criteria, and data description information required (including data name, type, value range) in the user story dimension; and call a parser to obtain interface information of the interfaces in the user story dimension from the technical document, such as interface path, HTTP method, request parameters (name, type, whether required, default value, value range), response parameters (name, type, example), error codes and their explanations, etc.; generate multiple scenario use cases in the user story dimension based on the requirement-related information and interface information in the same user story dimension.

[0036] Specifically, a preset scenario use case generation model, script, tool, etc. can be used to generate multiple scenario use cases in the user story dimension based on the requirement-related information and interface information under the same user story dimension. Among them, a scenario use case refers to a detailed description of the expected behavior of the system. It can exist in the form of natural language or a document in a specific format (such as a structured data format or program code, etc.), and is used to guide testers or automated testing tools to verify the functions and behaviors of the system or product.

[0037] Taking the registration of an account as an example, the scenario set can include a normal scenario set and an abnormal scenario set. Among them, the normal scenario set is "registration successful", and the abnormal scenario set is "registration failed". The scenario set of successful registration is specifically that both the account and password formats are correct. The scenario set of failed registration includes three cases: (1) the account format is correct and the password format is wrong; (2) the account format is wrong and the password format is wrong; (3) the account format is wrong and the password format is correct. All of these three scenarios will result in failed registration. In this case, the description information of the input data in the normal scenario set is used to indicate the input of the user name and password in the correct format, and the expected result is used to indicate the output of the information indicating successful registration; the description information of the input data of the scenario use case where the account format is correct and the password format is wrong is used to indicate the input of the correct format of the account and the wrong format of the password, and the description information of the expected output result is used to indicate the output of the prompt information indicating that the password format is wrong; the description information of the input data of the scenario use case where the account format is wrong and the password format is wrong is used to indicate the input of the wrong format of the account and the wrong format of the password, and the description information of the expected output result is used to indicate the output of the prompt information indicating that both the account and password formats are wrong; the description information of the input data of the scenario use case where the account format is wrong and the password format is correct is used to indicate the input of the wrong format of the account and the correct format of the password, and the description information of the expected output result is used to indicate the output of the prompt information indicating that the account format is wrong.

[0038] Taking account login as an example, the scenario set can include a normal scenario set and an abnormal scenario set. Among them, the normal scenario set is "login successful", and the abnormal scenario set is "login failed". Among them, the scenario set of successful login is specifically the scenario where both the account and password are correct; the scenario set of failed login can be broken down into three scenario use cases: (1) the account is correct, but the password is incorrect; (2) the account is incorrect, and the password is incorrect; (3) the account is incorrect, but the password is correct. All three scenarios will result in a failed login. In this case, the description information of the input data of the normal scenario set is used to indicate the input of the correct username and password, and the expected result is used to indicate the output of the login successful information; the description information of the input data of the scenario use case where the account is correct but the password is incorrect is used to indicate the input of the correct account and the incorrect password, and the description information of the expected output result is used to indicate the output of the prompt information indicating that the password is incorrect; the description information of the input data of the scenario use case where the account is incorrect and the password is incorrect is used to indicate the input of the incorrect account and the incorrect password, and the description information of the expected output result is used to indicate the output of the prompt information indicating that both the account and password are incorrect; the description information of the input data of the scenario use case where the account is incorrect but the password is correct is used to indicate the input of the incorrect account and the correct password, and the description information of the expected output result is used to indicate the output of the prompt information indicating that the account is incorrect. Exemplarily, if there is an existing account list [a, b, c], then an incorrect account is any other value ∉ [a, b, c]. If there are passwords for each account in the above account list, then when the input account is an account in the account list and the input password is inconsistent with the password corresponding to the input account in the account list, the account is correct but the password is incorrect.

[0039] Step S130: Generate a test data pair corresponding to the scenario use case according to the interface information of each interface corresponding to the multiple data required by the scenario use case and the data description information included in the scenario use case.

[0040] Among them, the test data pair includes a request parameter and an expected response parameter. Specifically, methods such as equivalence class partitioning or boundary value analysis can be used to generate one or more groups of test data pairs for each scenario use case based on the data description information and the interface information of each interface corresponding to the multiple data. Each group of test data pairs includes a request parameter and an expected response parameter.

[0041] Among them, the interface information of the interface includes at least one of the names, types, formats, and constraint conditions corresponding to the request data and response data of the interface.

[0042] Exemplarily, taking the registration of an account as an example, if the data description information corresponding to the normal scenario set "registration successful" includes: account setting rules (composed of 5 to 20 characters, including at least one of letters, numbers, and symbols); password setting rules (composed of 8 to 16 characters, including at least one of letters, numbers, and symbols); the interfaces corresponding to the above data are registration interfaces, and according to the corresponding interface details and data description information of the registration interface, data pairs corresponding to the normal scenario set can be constructed. The request parameters of this data pair include the username "User123!" and the password "User123!@ssw0rd!", and the expected response parameter is "Your account has been successfully created".

[0043] In this case, the data description information corresponding to the use case of the scenario "account format is correct, password format is incorrect" in the abnormal scenario set includes account setting rules (composed of 5 to 20 characters, including at least one of letters, numbers, and symbols); password setting rules (composed of less than 8 characters or more than 16 characters, or composed of any number of strings including characters other than letters, numbers, and symbols). The interfaces corresponding to the above data are registration interfaces, and according to the corresponding interface details and data description information of the registration interface, data pairs corresponding to the normal scenario set can be constructed. The request parameters of this data pair include the username "User123!" and the password "password!123, or User123, etc.", and the expected response parameter is "Your password format is incorrect".

[0044] Step S140: Generate test cases corresponding to the scenario use cases based on the scenario use cases and the test data pairs corresponding to the scenario use cases.

[0045] A test case template can be obtained. The test case template includes necessary elements such as preconditions, input parameters, operation steps, expected results, etc. Fill the scenario use cases and test data pairs into the test case template to obtain test cases corresponding to the scenario use cases.

[0046] Among them, a test case can correspond to a group of test data pairs or multiple groups of test data pairs, which is determined according to actual requirements and specific test design methods and is not specifically limited here.

[0047] By adopting the test case generation method of the present application, it is possible to automatically extract information from the requirement document and the technical document, and automatically generate high-quality test cases based on this information, reducing the dependence on manual experience and making the preparation stage of test cases more efficient. Further, according to the data description information and interface information parsed from the user story dimension, test data pairs are automatically generated, effectively alleviating the problems in the related technology such as time-consuming, error-prone, and low-efficiency in generating test data used in test case generation. In addition, the generated test data pairs include test data pairs under normal scenario use cases and abnormal scenario use cases, achieving higher-quality test coverage.

[0048] In an implementable manner, the above step S120 includes: using natural language processing technology to parse the requirement document and the technical document according to the user story dimension to obtain a set of scenarios under the user story dimension. In this case, please refer to Figure 2 , the above step S120 includes using natural language processing technology to perform the following steps: Step S122: Perform semantic understanding on the requirement document to obtain the business logic under the user story dimension and a set of initial data information corresponding to the business logic. This set of initial data information is used to describe the initial data details of multiple data required for the business logic.

[0049] Among them, the business logic refers to a series of rules and processes that the system follows to complete a specific task, which includes core elements, execution steps, execution conditions, and exception handling. Among them, the core elements include the execution subject (the user or system component that performs the operation, such as "unregistered user"), the achievement goal (the goal that the user hopes to achieve, such as "create a new account"), and the motivation (the reason why the user performs this business, such as "in order to enjoy the services provided by the website"). The execution steps include the steps that the user needs to perform (for example, the user needs to fill in the account number and password) and the system response (for example, the system will generate a feedback result based on the account number and password filled in by the user); the execution conditions include the preconditions (the conditions that are met when performing the operation, such as the user accessing the registration page) and the acceptance conditions (the conditions that are met after performing the business logic, such as returning a registration success result); the exception handling refers to possible exceptions, such as at least one of the password and the account number having an incorrect format.

[0050] Taking the example of registering an account again, the business logic includes determining whether the corresponding setting rules are met after receiving the account number and password entered by the user on the registration page. If both the account number and password meet the corresponding setting rules, the account number and password are saved to the database, and a registration passed notification is sent. If at least one of the account number or password does not meet the corresponding setting rules, a corresponding error prompt is generated.

[0051] A set of initial data information corresponding to the business logic refers to the specific input data required to execute the business logic. Taking the example of registering an account again, the initial data information includes the setting rule information of the account and the setting rule information of the password.

[0052] In an implementable manner, the above step S122 includes: extracting features from the requirement document to obtain requirement document features; performing semantic understanding on the requirement document features to obtain the semantic understanding result of the requirement document; extracting the business logic and a set of initial data information corresponding to the business logic in the user story dimension from the semantic understanding result, where the business logic includes the core elements, execution steps, and execution conditions of the business, and the set of initial data information corresponding to the business logic includes the initial data details of the input data and the expected output result respectively.

[0053] Among them, before extracting features from the requirement document, the requirement document can be preprocessed, such as performing word segmentation, removing stop words, and stemming and lemmatization to obtain the preprocessed requirement document; then, when extracting features from the requirement document, specifically, the word-segmented requirement document can be vectorized and syntactically analyzed to obtain the requirement document features. Then, through semantic understanding of the requirement document features, all important entities mentioned in it can be identified, such as keywords (such as "user", "register", "account") and phrases (such as "create a new account") in the user story, analyze the internal structure of the sentence, determine roles such as actions (predicates), executors (agents), and receivers (patients), find the potential relationships between different entities, and identify the preconditions, operation steps, and acceptance criteria of the user story, as well as determine the goals and motivations of the user story (the above-mentioned content obtained is the semantic understanding result). Finally, based on the semantic understanding result, a business logic is constructed, which includes core elements, execution steps, execution conditions, and exception handling. The initial data information includes the setting rules corresponding to the input data and the expected output data extracted from the requirement document respectively.

[0054] Step S124: Perform semantic understanding on the technical document to obtain an interface set in the user story dimension.

[0055] In an implementable manner, the above step S124 includes: performing semantic understanding on the technical document to obtain the semantic understanding result of the technical document; extracting multiple interfaces and the interface information of each interface from the semantic understanding result of the technical document; dividing the extracted multiple interfaces according to the user story dimension to obtain an interface set in the user story dimension.

[0056] Specifically, by semantically understanding the technical document, the technical document can be decomposed into meaningful units (such as words or phrases), key entities can be identified from the technical document (such as interface paths, parameter names, etc.), and the relationships between words or phrases can be obtained by syntactic analysis, so as to more accurately obtain the input-output relationship of the interface (the content obtained above is the semantic understanding result). Subsequently, according to the semantic understanding result, the interface information of the interfaces included in the technical document can be extracted, where the interface information can include at least one of the interface path, HTTP method, and the names, types, formats, and constraint conditions of the request data and response data respectively. After extracting multiple interfaces, the interfaces corresponding to the same story dimension are divided into the same set to obtain the interface set under the user story dimension.

[0057] Step S126: Obtain a scenario set under the user story dimension based on the interface set under the user story dimension, the business logic, and a set of initial data information corresponding to the business logic.

[0058] The above step S126 may be: matching the initial data details of multiple data required by the business logic with the interface information of each interface in the interface set to obtain the interfaces corresponding to the multiple data respectively; using a preset test design method to generate multiple scenario use cases based on the business logic, the initial data information corresponding to the business logic, and the interfaces corresponding to the multiple data in the initial data information; the multiple scenario use cases include normal scenario use cases and abnormal scenario use cases, and the preset test design method includes at least one of the equivalence class partitioning test design method and the boundary value test design method.

[0059] Among them, when using the equivalence class partitioning test design method, the input data is divided into several equivalence classes, and a representative value is selected from each equivalence class as a test case, which can reduce the number of test cases while ensuring coverage of all possible situations. The boundary value test design method refers to testing the behavior of the input data under boundary conditions, especially when the input is close to the minimum value, maximum value, or other critical points, which helps to discover potential problems and abnormal situations.

[0060] Specifically, matching the data items defined in the business logic with the interface information extracted from the technical document can ensure that each data item can find the corresponding request parameter. Subsequently, if the equivalence class partitioning test design method is used, the valid range and invalid range of each data item can be determined according to the business logic and data format requirements. So as to select one or more representative values from each equivalence class later to construct test data pairs for testing. If the boundary value test design method is used, the boundary conditions of each data item can be determined. So as to select the values near the boundary conditions later to construct test data pairs.

[0061] By adopting the above steps S122 - S126, through semantic understanding of the requirements document, the business logic and initial data information in the user stories are accurately captured, ensuring that each user story is fully understood and transformed into specific business requirements; through semantic understanding of the technical document, detailed API interface information is extracted and divided according to the user story dimension, ensuring that corresponding technical implementations can be found for each user story. Based on the results of semantic understanding, detailed business logic, initial data information, and interface sets are automatically generated, enabling the rapid creation of high-quality test cases and improving test efficiency. It is possible to accurately divide to obtain multiple scenario test cases, so that the divided scenario test cases can cover all execution situations of the business logic.

[0062] As Figure 3 shown, taking the test case generation method of this application being executed by a test data generation system as an example for illustration, where the test data generation system includes 4 subsystems, namely a requirements analysis subsystem, a technical analysis subsystem, a test data generation subsystem, and a test case generation subsystem, for example.

[0063] The goal of the requirements analysis subsystem is to complete requirements parsing to obtain the business logic and a set of initial data information corresponding to the business logic. The requirements analysis subsystem includes a business logic acquisition module.

[0064] Among them, the business logic acquisition module is used to execute the method steps in step S122 of the foregoing method to implement outputting the business logic for each user story dimension.

[0065] The goal of the technical analysis subsystem is to complete technical solution parsing to form interface information, which may include an interface extraction module.

[0066] The interface extraction module is used to execute step S124 in the foregoing method to extract all interfaces under the corresponding user story dimension and output an interface set.

[0067] The test data set generation subsystem includes a test data pair generation module, which is used to obtain scenario test cases according to the business logic. Each scenario test case includes a set of data description information, and this set of data description information is used to describe the data details of multiple data required for the scenario test case, and generate test data pairs corresponding to the scenario test case according to the interface information of the interfaces corresponding to the multiple data required for the scenario test case and the data description information included in the scenario test case.

[0068] The test case generation subsystem includes a use case assembly module, and the use case assembly module is used to generate test cases corresponding to the scenario test cases according to the scenario test cases and the test data pairs corresponding to the scenario test cases.

[0069] Specifically, please refer to Figure 3, taking the example of registering an account on a certain shopping platform based on a certain requirement, logging in to the account, and adding items on the shopping platform to the shopping cart. After obtaining the requirement document and technical document corresponding to the above requirement, by using the step S120 in the foregoing embodiment, the large model is used to parse the requirement document and technical document, and three user story dimensions can be obtained, namely story1: "As a guest user, I hope to register an account on the shopping website"; story2: "As a registered user, I hope to enter the correct username and password to log in to the website for access"; story2: "As a logged-in user, I hope to add the items I want to buy to the shopping cart."

[0070] Among them, the scenario set under the user story dimension of story1 can include a normal scenario set and an abnormal scenario set. Among them, the normal scenario set is "registration successful", and the abnormal scenario set is "registration failed". The specific scenario set of successful registration is that both the account and password formats are correct. The scenario set of failed registration includes three types: (1) the account format is correct and the password format is wrong; (2) the account format is wrong and the password format is wrong; (3) the account format is wrong and the password format is correct. The interface set under the user story dimension of story1 can include multiple interfaces, such as interface 1 and interface 2, etc.

[0071] Furthermore, by adopting the foregoing step S130, it is possible to generate test data pairs corresponding to each of the scenario use cases under the story1 story dimension according to the interface information of the interfaces corresponding to the multiple data required by each of the scenario use cases and the data description information included in the scenario use case. Among them, the above scenario use cases include scenario use cases in normal scenarios and scenario use cases of abnormal scenario 1, abnormal scenario 2, and abnormal scenario 3 respectively.

[0072] After obtaining multiple scenario use cases and the test data pairs corresponding to each scenario use case, by using the foregoing step S140, the test cases corresponding to each scenario use case can be obtained.

[0073] It should be understood that although the steps in the flowcharts involved in the foregoing embodiments are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the foregoing embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same moment, but can be executed at different moments. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least a part of other steps or steps or stages in other steps.

[0074] Please refer toFigure 5 , another embodiment of the present application provides a test case generation device 200, and the test case generation device 200 includes: a document acquisition module 210, configured to acquire a requirements document and a technical document corresponding to the requirements document; a document parsing module 220, configured to parse the requirements document and the technical document according to the user story dimension to obtain a set of scenarios in the user story dimension, where the set of scenarios includes multiple scenario use cases, and each scenario use case includes a set of data description information, and this set of data description information is used to describe the data details of multiple data required by the scenario use case, and the data details of the data include the interfaces corresponding to the data; a test data generation module 230, configured to generate a test data pair corresponding to the scenario use case according to the interface information of the interfaces corresponding to multiple data required by the scenario use case and the data description information included in the scenario use case; a test case generation module 240, configured to generate a test case corresponding to the scenario use case based on the scenario use case and the test data pair corresponding to the scenario use case.

[0075] In an implementable manner, the document parsing module 220 includes a first semantic understanding sub-module, a second semantic understanding sub-module, and a scenario set obtaining sub-module; the first semantic understanding sub-module is configured to perform semantic understanding on the requirements document to obtain a business logic in the user story dimension and a set of initial data information corresponding to the business logic, and this set of initial data information is used to describe the initial data details of multiple data required by the business logic; the second semantic understanding sub-module is configured to perform semantic understanding on the technical document to obtain an interface set in the user story dimension; the scenario set obtaining sub-module is configured to obtain a set of scenarios in the user story dimension based on the interface set, business logic, and a set of initial data information corresponding to the business logic in the user story dimension.

[0076] In an implementable manner, the scenario set obtaining sub-module is further configured to match the initial data details of multiple data required by the business logic with the interface information of each interface in the interface set to obtain the interfaces corresponding to multiple data respectively; generate multiple scenario use cases based on the business logic, the initial data information corresponding to the business logic, and the interfaces corresponding to multiple data in the initial data information by using a preset test design method; the multiple scenario use cases include normal scenario use cases and abnormal scenario use cases, and the preset test design method includes at least one of an equivalence class partitioning test design method and a boundary value test design method.

[0077] In an implementable manner, the first semantic understanding sub-module is further configured to extract features from the requirement document to obtain requirement document features; perform semantic understanding on the requirement document features to obtain a semantic understanding result of the requirement document; and extract business logic and a set of initial data information corresponding to the business logic in the dimension of user stories from the semantic understanding result, where the business logic includes core elements, execution steps, and execution conditions of the business, and the set of initial data information corresponding to the business logic includes initial data details of input data and expected output results respectively.

[0078] In an implementable manner, the second semantic understanding sub-module is further configured to perform semantic understanding on the technical document to obtain a semantic understanding result of the technical document; extract a plurality of interfaces and interface information of each of the interfaces from the semantic understanding result of the technical document; and divide the extracted plurality of interfaces according to the dimension of user stories to obtain an interface set in the dimension of user stories.

[0079] In an implementable manner, the interface information of the interface includes at least one of the name, type, format, and constraint conditions corresponding to the request data and the response data of the interface.

[0080] Each module in the above device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor in the computer device in hardware form or be independent of the processor, or can be stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to the above modules. It should be noted that the device embodiments in this application correspond to the foregoing method embodiments. The specific principles in the device embodiments can refer to the content in the foregoing method embodiments and will not be elaborated here.

[0081] Next, Figure 6 an electronic device provided by this application will be described.

[0082] Please refer to Figure 6 , based on the test case generation method provided in the foregoing embodiments, another electronic device 100 including a processor 102 that can execute the foregoing method is further provided in the embodiments of this application. The electronic device 100 can be a server, a terminal device, or a vehicle, and the terminal device can be a device such as a smart phone, a tablet computer, a computer, or a portable computer.

[0083] The electronic device 100 further includes a memory 104. Among them, a program that can execute the content in the foregoing embodiments is stored in the memory 104, and the processor 102 can execute the program stored in the memory 104.

[0084] Among them, the processor 102 may include one or more cores for processing data and a message matrix unit. The processor 102 connects various parts within the entire electronic device 100 through various interfaces and lines. By running or executing instructions, programs, code sets, or instruction sets stored in the memory 104, and by invoking data stored in the memory 104, it performs various functions of the electronic device 100 and processes data. Optionally, the processor 102 may be implemented in at least one of the following hardware forms: digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 102 may integrate a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem, etc. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing display content; the modem is used to process wireless communication. It can be understood that the above-mentioned modem may not be integrated into the processor 102 and may be implemented separately through a communication chip.

[0085] The memory 104 may include a random access memory (RAM) and may also include a read-only memory. The memory 104 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 104 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for implementing at least one function, instructions for implementing the following various method embodiments, etc. The data storage area may also store data obtained during the use of the electronic device 100 (such as parking location, environmental information, and images).

[0086] The embodiments of the present application also provide a computer-readable storage medium. Program code is stored in the computer-readable medium, and the program code can be called by the processor to execute the methods described in the above method embodiments.

[0087] A computer-readable storage medium may be an electronic memory such as a flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, a hard disk, or a ROM. Optionally, the computer-readable storage medium includes a non-transitory computer-readable storage medium. The computer-readable storage medium has a storage space for program code for performing any of the method steps in the above-described methods. These program codes may be read from or written to one or more computer program products. The program codes may be compressed in a suitable form, for example.

[0088] Embodiments of the present application also provide a computer program product or a computer program. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the methods described in the above various optional implementation manners.

[0089] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A test case generation method, characterized in that, The method includes: Obtaining a requirements document and a technical document corresponding to the requirements document; Parsing the requirements document and the technical document according to the user story dimension to obtain a set of scenarios in the user story dimension. The set of scenarios includes multiple scenario use cases, and each scenario use case includes a set of data description information, which is used to describe the data details of multiple data required by the scenario use case. The data details of the data include the interfaces corresponding to the data; Generating a test data pair corresponding to the scenario use case according to the interface information of the interfaces corresponding to the multiple data required by the scenario use case and the data description information included in the scenario use case; Generating a test case corresponding to the scenario use case based on the scenario use case and the test data pair corresponding to the scenario use case.

2. The method according to claim 1, characterized in that The parsing of the requirements document and the technical document according to the user story dimension to obtain a set of scenarios in the user story dimension includes: Performing semantic understanding on the requirements document to obtain the business logic in the user story dimension and a set of initial data information corresponding to the business logic, where the set of initial data information is used to describe the initial data details of multiple data required by the business logic; Performing semantic understanding on the technical document to obtain a set of interfaces in the user story dimension; Obtaining a set of scenarios in the user story dimension based on the set of interfaces, business logic, and a set of initial data information corresponding to the business logic in the user story dimension.

3. The method according to claim 2, wherein Obtaining a set of scenarios in the user story dimension based on the set of interfaces, business logic, and a set of initial data information corresponding to the business logic in the user story dimension includes: Matching the initial data details of the multiple data required by the business logic with the interface information of each interface in the set of interfaces to obtain the interfaces corresponding to the multiple data respectively; Using a preset test design method to generate multiple scenario use cases based on the business logic, the initial data information corresponding to the business logic, and the interfaces corresponding to the multiple data in the initial data information. The multiple scenario use cases include normal scenario use cases and abnormal scenario use cases, and the preset test design method includes at least one of an equivalent class partitioning test design method and a boundary value test design method.

4. The method according to claim 2, wherein Performing semantic understanding on the requirements document to obtain the business logic in the user story dimension and a set of initial data information corresponding to the business logic includes: Performing feature extraction on the requirements document to obtain requirements document features; Performing semantic understanding on the requirements document features to obtain the semantic understanding result of the requirements document; Extracting the business logic in the user story dimension and a set of initial data information corresponding to the business logic from the semantic understanding result, where the business logic includes the core elements, execution steps, and execution conditions of the business, and the set of initial data information corresponding to the business logic includes the initial data details of the input data and the expected output result respectively.

5. The method according to claim 2, wherein Performing semantic understanding on the technical document to obtain a set of interfaces in the user story dimension includes: Performing semantic understanding on the technical document to obtain the semantic understanding result of the technical document; Extract a plurality of interfaces and interface information of each of the interfaces from the semantic understanding result of the technical document; Divide the extracted plurality of interfaces according to the user story dimension to obtain an interface set under the user story dimension.

6. The method according to claim 1, wherein The interface information of the interface includes at least one of the names, types, formats, and constraint conditions corresponding to the request data and the response data of the interface.

7. A test case generation device, characterized in that, The apparatus includes: A document acquisition module for acquiring a requirements document and a technical document corresponding to the requirements document; A document parsing module for parsing the requirements document and the technical document according to the user story dimension to obtain a scenario set under the user story dimension, where the scenario set includes a plurality of scenario use cases, and each scenario use case includes a set of data description information, and the set of data description information is used to describe the data details of a plurality of data required by the scenario use case, and the data details of the data include the interfaces corresponding to the data; A test data generation module for generating a test data pair corresponding to the scenario use case according to the interface information of the interfaces corresponding to the plurality of data required by the scenario use case and the data description information included in the scenario use case; A test case generation module for generating a test case corresponding to the scenario use case based on the scenario use case and the test data pair corresponding to the scenario use case.

8. An electronic device, characterized in that, Includes: One or more processors; A memory; One or more programs, where the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code, and the program code can be called by a processor to execute the method according to any one of claims 1-6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by a processor, the steps of the method according to any one of claims 1-6 are implemented.

Images