Test case generation method and device, equipment and medium

By converting natural language testing requirements into finite state machine model diagrams and generating test cases, the problem of manually building test models in the existing technology is solved, and the automation of test case generation is realized, and the efficiency of test design is improved.

CN119537191APending Publication Date: 2025-02-28ZHUZHOU CSR TIMES ELECTRIC CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202310966469.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-08-02
Publication Date
2025-02-28

AI Technical Summary

Technical Problem

Test scenarios or test models used to generate test cases in the prior art need to be built manually, consuming human resources, and cannot automatically generate test cases based on natural language requirements.

Method used

By obtaining the test requirements of the target software, converting them into the first format requirements of formal natural language descriptions, using keywords and identifiers to convert them into a finite state machine model diagram, determining the generation path and generating test cases, and automating the entire process from natural language requirements to test cases.

Benefits of technology

It greatly improves the efficiency of test design, saves a lot of manpower and material resources, and realizes the automation of test case generation.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119537191A_ABST
    Figure CN119537191A_ABST
Patent Text Reader

Abstract

The invention belongs to the technical field of software testing, and particularly relates to a test case generation method and device, equipment and a medium. The method comprises the steps of obtaining a test requirement of target software; converting the test requirement into a first format requirement described by a formalized natural language, wherein the first format requirement comprises a plurality of keywords and identifiers; converting the first format demand into a finite-state machine model diagram according to a keyword and an identifier, wherein the finite-state machine model diagram comprises a plurality of conversions and states; determining a generation path of each test case according to the finite-state machine model diagram; and generating a test case of the target software according to the generation path. Compared with the prior art, automation of the whole process from the natural language format requirement to the test case is achieved, the test design efficiency is greatly improved, and a large amount of manpower and material resources are saved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The invention belongs to the technical field of software testing, and specifically relates to a test case generation method, device, equipment and medium. Background Art

[0002] Software testing is an important means to ensure software quality. During the software testing process, testers need to write test cases based on software requirements, which takes a lot of time and human resources, and the quality of test cases cannot be effectively guaranteed.

[0003] In order to ensure the quality of testing and improve testing efficiency, the industry has carried out research on automatic test case generation technology, among which the model-based testing method MBT is the mainstream technical route. The main advantage of this technology is that it can accurately and model the software. By analyzing the state, logic, and algorithm of the modeled requirements, the efficiency and quality of automatic generation of test cases are high.

[0004] MBT (Model based testing), model-based testing belongs to a testing method in the field of software testing. It automatically generates test cases and test codes by establishing test scenarios or test models (hereinafter referred to as test models). It is an emerging technology for software testing. Compared with traditional testing technologies, MBT is more intuitive and easier to understand. It can automatically generate test data and has high test coverage. The logical path of the test case can be easily displayed, which is convenient for checking requirements and codes, and saves a lot of repetitive code writing work. The code of the test case is generated by the test model. However, the test scenario or test model used to generate test cases in the prior art MTB needs to be manually built, which consumes human resources and cannot automatically generate test cases based on natural language requirements. Summary of the invention

[0005] In response to the above technical problems, the present invention proposes a method, device, equipment and medium for generating test cases. The present application obtains the test requirements of the target software; converts the test requirements into a first format requirement described by a formalized natural language, wherein the first format requirement includes multiple keywords and identifiers; converts the first format requirement into a finite state machine model diagram according to the keywords and identifiers, wherein the finite state machine model diagram includes multiple transitions and states; determines the generation path of each test case according to the finite state machine model diagram; and generates the test case of the target software according to the generation path. Compared with the prior art, the whole process from natural language format requirements to test cases is automated, the test design efficiency is greatly improved, and a lot of manpower and material resources are saved.

[0006] In order to solve the above technical problems, the technical solution adopted by the present invention includes five aspects.

[0007] In a first aspect, a method for generating a test case is provided, comprising: obtaining a test requirement of a target software; converting the test requirement into a first format requirement described by a formalized natural language, wherein the first format requirement includes a plurality of keywords and identifiers; converting the first format requirement into a finite state machine model diagram according to the keywords and identifiers, wherein the finite state machine model diagram includes a plurality of transitions and states; determining a generation path for each test case according to the finite state machine model diagram; and generating a test case for the target software according to the generation path.

[0008] In some embodiments, the converting of the first format requirement into a finite state machine model diagram according to keywords and identifiers includes: splitting the first format requirement according to keywords and identifiers to obtain multiple second format requirements described by a mixture of formal natural language and finite state machines; and converting each of the second format requirements into the finite state machine model diagram according to keywords and identifiers.

[0009] In some embodiments, the splitting of the first format requirement according to keywords and identifiers to obtain multiple second format requirements described by a mixture of formal natural language and finite state machine includes: splitting the first format requirement into multiple sub-requirements described by formal natural language according to keywords and identifiers; creating a finite state machine and an initial state in each of the sub-requirements to obtain second format requirements described by a mixture of formal natural language and finite state machine.

[0010] In some embodiments, the converting each second format requirement into the finite state machine model diagram according to keywords and identifiers includes: splitting each second format requirement into steps according to keywords and identifiers to obtain multiple first format steps described by formal natural language; converting each first format step into a second format step described by a mixture of finite state machine and formal natural language according to keywords and identifiers, wherein the second format step includes: a first format conversion and a first state, the first state is a corresponding state of the first format conversion, which is described by a finite state machine, the first format conversion is also connected to a source state, the source state is the initial state or the first state of other second format steps, and the first format conversion is described by formal natural language; decomposing each first format conversion into multiple second format conversions described by a finite state machine according to keywords and identifiers, and determining the second state corresponding to each second format conversion; connecting each second format conversion to the second state, and at the same time connecting each second format conversion to the source state corresponding to the second format step to obtain the finite state machine model diagram.

[0011] In some embodiments, decomposing each first format conversion into multiple second format conversions described by a finite state machine according to keywords and identifiers, and determining a second state corresponding to each second format conversion, includes: converting each first format conversion into a logic tree according to keywords and identifiers; creating multiple second format conversions described by a finite state machine according to preset rules and the logic tree; and determining the second state corresponding to each second format conversion according to the preset rules.

[0012] In some embodiments, converting each of the first formats into a logic tree based on keywords and identifiers includes: creating a root node of the logic tree; creating multiple levels of child nodes on the root node based on keywords and identifiers; determining a node type of each of the child nodes based on the keywords or the identifiers to obtain the logic tree.

[0013] In some embodiments, creating a plurality of second format conversions according to a preset rule and the logic tree includes: determining the number of second format conversions created at the child nodes and the content of each second format conversion according to the node type of each child node.

[0014] In some embodiments, determining the second state corresponding to each second format conversion according to the preset rule includes: solving step by step from the child node where the second format conversion is located to the root node according to the content of each second format conversion, and finally obtaining the expected result of each second format conversion at the root node; determining the corresponding second state of the second format conversion according to the expected result.

[0015] In the second aspect, the present application provides a test case generation device, including: a first acquisition module, used to acquire the test requirements of the target software; a first execution module, used to convert the test requirements into a first format requirement described by a formalized natural language, wherein the first format requirement includes multiple keywords and identifiers; a second execution module, used to convert the first format requirement into a finite state machine model diagram according to the keywords and identifiers, wherein the finite state machine model diagram includes multiple transitions and states; a third execution module, used to determine a generation path for each test case according to the finite state machine model diagram; and a fourth execution module, used to generate a test case for the target software according to the generation path.

[0016] In a third aspect, the present application proposes an electronic device, comprising: a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the method described in the first aspect is performed.

[0017] In a fourth aspect, the present application proposes a storage medium, which stores a computer program that can be executed by one or more processors, and the computer program can be used to implement the method described in the first aspect.

[0018] In a fifth aspect, the present application provides a test case generation system, comprising: a requirement description module, used to describe the acquired requirements in a formalized natural language to obtain a first format requirement. A language analysis module, used to convert the first format requirement into a finite state machine model diagram. A test model description module, used to view and edit the finite state machine model diagram. A test analysis module, used to traverse the finite state machine and generate a test path. A test case module, used to generate a test case based on the test path, and to view the test path and the test case.

[0019] Beneficial effects created by the present invention: The present application obtains the test requirements of the target software; converts the test requirements into a first format requirement described by a formalized natural language, wherein the first format requirement includes multiple keywords and identifiers; converts the first format requirement into a finite state machine model diagram according to the keywords and identifiers, wherein the finite state machine model diagram includes multiple transitions and states; determines the generation path of each test case according to the finite state machine model diagram; and generates the test case of the target software according to the generation path. Compared with the prior art, the whole process from natural language format requirements to test cases is automated, the test design efficiency is greatly improved, and a lot of manpower and material resources are saved. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The scope of the present disclosure may be better understood by reading the following detailed description of exemplary embodiments in conjunction with the accompanying drawings. The drawings included are:

[0021] Figure 1 An overall flow chart of a method for generating a test case provided in an embodiment of the present application;

[0022] Figure 2 An overall flow chart of a postman algorithm provided in an embodiment of the present application;

[0023] Figure 3 A structural block diagram of a test case generation device provided in an embodiment of the present application;

[0024] Figure 4 A structural block diagram of a test case generation system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0026] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0027] If similar descriptions of "first\second\third" appear in the application documents, the following instructions will be added. In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0029] Embodiment 1:

[0030] In the prior art MTB, the test scenarios or test models used to generate test cases need to be built manually, which consumes human resources and cannot automatically generate test cases based on natural language requirements.

[0031] In view of the problems existing in the prior art, such as Figure 1 As shown, the present application provides a method for generating a test case, and the method is applied to an electronic device, and the electronic device can be a server, a mobile terminal, a computer, a cloud platform, etc. The function implemented by the device data processing provided in the embodiment of the present application can be implemented by calling a program code by a processor of the electronic device, wherein the program code can be stored in a computer storage medium, and the method for generating a test case includes:

[0032] Step S1: Obtain the test requirements of the target software.

[0033] Step S2: converting the test requirement into a first format requirement described in a formalized natural language, wherein the first format requirement includes a plurality of keywords and identifiers.

[0034] Generally, test requirements are proposed by humans, but the test requirements proposed by humans cannot be directly identified to obtain the final test cases. Therefore, in this application, the test requirements need to be converted into first-format requirements described by formal natural language first, and the test requirements are marked, structured, and standardized by formal natural language, and finally the first-format requirements are obtained. There are many keywords and identifiers in the first-format requirements described by formal natural language. In the subsequent methods, the requirements can be identified by using these keywords and identifiers. The definitions of identifiers and keywords are set as follows:

[0035] Identifier: Identifiers are mainly used to mark identifiers with specific meanings in software requirement descriptions. Identifiers include the following:

[0036] <>: Control identifier. The content marked with this symbol is used to identify requirement architecture keywords and logical keywords in the form of <keyword>.

[0037] 【】: Data identifier. The content marked by this symbol represents a variable, signal or parameter in the form of [xx variable name].

[0038] [], [), (], () are interval parameters. This symbol identifies a parameter or a parameter interval. For example, [3,5) indicates that the parameter range is 3 to 5 (including 3 but not including 5).

[0039] Keywords are used to define specific functions, and include structural keywords and logical keywords.

[0040] Structural keywords: Control keywords are mainly used to implement the structural organization of software requirements. Control keywords are marked with <> and include:

[0041] <Requirement>: This keyword is used to mark the starting point of a requirement. The text following this keyword is a complete requirement.

[0042] <Function>: This keyword is used to mark a function in a requirement.

[0043] <Step>: This keyword is used to mark a process state of a software function, including the combination of conditions for entering the process state and the entry process, as well as the result / state of the software after entering the step.

[0044] <Condition>: This keyword is used to mark the conditions required for the software to perform a certain action, produce a result, or reach a "state".

[0045] <Result>: This keyword is used to mark the action or result performed by the software in a certain step.

[0046] <Source>: This keyword forms a pair with the <Jump> keyword and is used to indicate that the current step jumps from another step.

[0047] <Jump>: This keyword forms a pair with the <Source> keyword, which is used to indicate that you can jump to the corresponding step after the current step is executed.

[0048] Logical keywords include:

[0049] <all>: This keyword indicates that after all <conditions> meet the requirements (valid / invalid), the result will take effect.

[0050] <Any>: This keyword indicates that if any of the subsequent <conditions> meets the requirements (valid or not), the result will take effect.

[0051] <Valid>: Indicates that the condition is valid.

[0052] <Invalid>: Indicates that the condition is invalid.

[0053] <AND><AND>: The two conditions before and after the keyword meet the requirements at the same time (valid / invalid), and the combination of conditions is valid.

[0054] <or>: If either of the two conditions before or after the keyword meets the requirement (valid / invalid), the combined condition is valid.

[0055] <greater than><>>: If the signal / variable / parameter before the keyword is <>> the parameter after the keyword, the combination condition takes effect. When > is used, the keyword does not need an identifier.

[0056] <greater than or equal to><≥>: The signal / variable / parameter before the keyword <≥> the parameter after the keyword, then the combined condition takes effect. When ≥ is used, the keyword does not need an identifier.

[0057] <less than><<>: the signal / variable / parameter in front of the keyword is <<> the parameter behind the keyword, then the combined condition takes effect. When < is used, the keyword does not need an identifier.

[0058] <Less than or equal to><≤>: The signal / variable / parameter before the keyword <≤> the parameter after the keyword, then the combined condition takes effect. When ≤ is used, the keyword does not need an identifier.

[0059] <equals><=>: if the signal / variable / parameter before the keyword is <=> the parameter after the keyword, the combined condition takes effect. When using =, the keyword does not need an identifier.

[0060] <time>: This keyword is followed by a time parameter, such as 3s, 20 minutes, or 2 hours. This means that the combined condition takes effect only after the condition / signal preceding the keyword continues to meet the time requirement.

[0061] Formula keywords: +, -, *, / , (), =.

[0062] Step S3: converting the first format requirement into a finite state machine model diagram according to keywords and identifiers, wherein the finite state machine model diagram includes a plurality of transitions and states.

[0063] In some embodiments, step S3 "converting the first format requirement into a finite state machine model diagram according to the keyword and the identifier" includes:

[0064] Step S31: splitting the first format requirement according to keywords and identifiers to obtain a plurality of second format requirements described by a mixture of formal natural language and finite state machine;

[0065] In some embodiments, step S31 "splitting the first format requirement according to keywords and identifiers to obtain multiple second format requirements described by a mixture of formal natural language and finite state machine" includes:

[0066] Step S311: splitting the first format requirement into multiple sub-requirements described in a formalized natural language according to keywords and identifiers;

[0067] Identify the control identifier and structure keywords. Each FNL after the <requirement> and <function> keywords is treated as an independent FNL requirement and is recorded as FNL. i , that is, sub-requirements. Formal Natural Language (hereinafter referred to as FNL: Formal Natural Language), Finite State Machine (FSM: Finite-state machine)

[0068] Step S312: Create a finite state machine and an initial state in each of the sub-requirements to obtain a second format requirement described by a mixture of formal natural language and finite state machine.

[0069] Select a separate FNL format Required FNL i , create an FSM and an initial state, respectively denoted as FSM i and S i0 . Among them, FSM i is the finite state machine mentioned above, S i0 is the initial state.

[0070] Step S32: convert each of the second format requirements into the finite state machine model diagram according to the keyword and the identifier.

[0071] In some embodiments, step S32 of "converting each of the second format requirements into the finite state machine model diagram according to the keyword and the identifier" includes:

[0072] Step S321: split each of the second format requirements into steps according to keywords and identifiers to obtain multiple first format steps described in a formalized natural language.

[0073] Identify the <step> keyword in FNLi, and each FNL after the <step> keyword is treated as an independent FNL format step, recorded as FNL ik .

[0074] Step S322: Convert each of the first format steps into a second format step described by a mixture of a finite state machine and a formal natural language according to keywords and identifiers, wherein the second format step includes: a first format conversion and a first state, the first state being a corresponding state of the first format conversion and being described by a finite state machine, the first format conversion being further connected to a source state, the source state being the initial state or the first state of other second format steps, and the first format conversion being described by a formal natural language.

[0075] Identifying FNL ik In the <result> keyword, all the contents marked by the <result> keyword are merged into one FNL format content, recorded as FNL is , the rest is recorded as FNL it . Create a transformation T ik , i.e. the first conversion, and FNL it As T ik content; create a state S ik , i.e. the first state, and FNL is As S ik content; ik and S ik Connect, S ik As T ik The corresponding status.

[0076] Step S323: Decompose each of the first format conversions into a plurality of second format conversions described by a finite state machine according to the keyword and the identifier, and determine a second state corresponding to each of the second format conversions.

[0077] Step S324: Connect each of the second format conversions to the second state, and simultaneously connect each of the second format conversions to the source state corresponding to the second format step, to obtain the finite state machine model diagram.

[0078] If T ikis the first transformation created, then connect T ik and S i0 , S i0 As T ik The source state; if T ik Not the first transformation created, recognize FNL ik The <source> keyword in the ik Connect with the state in the source step and use the state of the source step as the source state; if T ik is not the first transformation created, and FNL ik If the <source> keyword is not included, T ik With the last created state S i(k -1) Connect and change the previous state S i(k-1) As T ik The source status.

[0079] In some embodiments, step S232 "decomposing each first format conversion into a plurality of second format conversions described by a finite state machine according to the keyword and the identifier, and determining a second state corresponding to each second format conversion" includes:

[0080] Step S3231: convert each of the first formats into a logic tree according to keywords and identifiers.

[0081] Extract the converted content fnl of each first format conversion i , corresponding to the first state s id and source status ic , and find the first state s id The mutually exclusive state Identify fnl i Keywords in the text file and perform semantic analysis to convert the natural language format fnl i Convert to a logical tree.

[0082] In some embodiments, step S3231 "converting each of the first formats into a logic tree according to the keyword and the identifier" includes:

[0083] Step S32311: Create the root node of the logical tree.

[0084] The beginning of a logical tree requires a root node, so we first create a root node result.

[0085] Step S32312: Create multiple levels of child nodes on the root node according to keywords and identifiers.

[0086] Step S32313: Determine the node type of each of the child nodes according to the keyword or the identifier to obtain the logic tree.

[0087] Identify fnl i The <condition> keyword in the result is a leaf node named leaf. a If the node contains the keywords <all> + <valid>, the node is defined as an 'and' type node; if the node contains the keywords <any> + <valid>, the node is defined as an 'or' type node.

[0088] Traverse all leaf nodes on the logical tree and extract the content of each leaf node in turn. If the content contains one of the keywords <and> and <and>, create a child node for the content before and after the keyword respectively as a new leaf node and name it leaf. b node, and the leaf b The node is defined as an 'and' node; if the content contains the < or > keyword, a child node is created for the content before and after the keyword as a leaf node. a The direct leaf node is named leaf b node, and the leaf b Nodes are defined as 'OR' nodes.

[0089] Traverse all leaf nodes under the logical tree and extract the content of each leaf node in turn. If the content contains one of the keywords in the <time> keyword, create a child node for the content before and after the keyword respectively as a new leaf node and name it leaf. c node, and the leaf c Nodes are defined as 'time' nodes.

[0090] Retraverse all leaf nodes under the logical tree and extract the content of each leaf node in turn. If the content contains any of the keywords <greater than>, <>>, <greater than or equal to>, <≥>, <less than>, <<>, <less than or equal to>, <≤>, <equal to>, and <=>, create a child node for the content before and after the keyword respectively as a new leaf node and name it leaf. d node, and the leaf d The nodes are defined as nodes of the corresponding type (<greater than> and <>> are defined as 'greater than' type, <greater than or equal to> and <≥> are defined as 'greater than or equal to' type, <less than> and <<> are defined as 'less than' type, <less than or equal to> and <≤> are defined as 'less than or equal to' type, <equal to> and <=> are defined as 'equal to' type).

[0091] Retraverse all leaf nodes under the logical tree and extract the content of each leaf node in turn. If the content contains the keyword <invalid>, create a leaf node with the content before the keyword <invalid> as a new leaf node and name it leaf. f node, and put leaf f Defined as a 'non' type node.

[0092] Retraverse all leaf nodes under the logical tree and extract the content of each leaf node in turn. If the content contains the [] identifier, create a leaf node with the content in the identifier as a new leaf node and name it leaf. f , and leaf f The node is defined as a 'variable' type node. If the content contains a number, a new leaf node is created with the number and named leaf. g node, and the leaf g The node is defined as a 'parameter' type node.

[0093] In this application, the above rules are used to gradually identify and decompose the first format conversion content, and the node type of each level of child nodes and the final leaf node are obtained. In order to facilitate the understanding of the above content, the node problem in the above content is explained again. In this application, the child node that does not generate a new node is called a leaf node, and when a branch or extension is generated on a leaf node, then the node is just an ordinary child node, no longer a leaf node, and is not within the next traversal range.

[0094] For example, if a leaf node generated by a conditional keyword does not contain the time keyword, and the AND keyword, but only contains numbers, then this leaf node is considered a leaf node when traversing the parameter or variable level. However, if the leaf node contains the time keyword, then after the time-level traversal, the node is just a child node and will not be traversed again in subsequent traversals.

[0095] Step S3232: Create multiple second format conversions described by finite state machines according to preset rules and the logic tree.

[0096] In some embodiments, step S3232 “creating a plurality of second format conversions described by a finite state machine according to a preset rule and the logic tree” includes:

[0097] Step S32321: Determine the number of second format conversions created at the child node and the content of each second format conversion according to the node type of each child node.

[0098] The following describes in detail how to determine the number and content of conversions created for different types of child nodes.

[0099] For 'and' type nodes, create n+1 conversions, where n is the number of direct child nodes of the node. For the first conversion, all child node values ​​are valid, and the expected result is expected to be valid. For other conversions, selecting one child node at a time is invalid, and the other child nodes are valid, and the expected result is expected to be invalid.

[0100] For 'or' type nodes, create n+1 conversions, where n is the number of direct child nodes of the node. For the first conversion, all child node values ​​are invalid, and the expected result is invalid. For other conversions, select one child node to be valid, and the other child nodes are invalid, and the expected result is valid.

[0101] For a 'greater than' type node, create three conversions. In the first conversion, the value of node 1 = the value of node 2 + precision, and expect is valid. In the second conversion, the value of node 1 = the value of node 2, and expect is invalid. In the third conversion, the value of node 1 = the value of node 2 - precision, and expect is invalid.

[0102] For a 'greater than or equal to' type node, create three conversions. In the first conversion, the value of node 1 = the value of node 2 + precision, and expect is valid. In the second conversion, the value of node 1 = the value of node 2, and expect is valid. In the third conversion, the value of node 1 = the value of node 2 - precision, and expect is invalid.

[0103] For a 'less than' type node, create three conversions. In the first conversion, the value of node 1 = the value of node 2 + precision, and expect is invalid. In the second conversion, the value of node 1 = the value of node 2, and expect is invalid. In the third conversion, the value of node 1 = the value of node 2 - precision, and expect is valid.

[0104] For a 'less than or equal to' type node, create three conversions. In the first conversion, the value of node 1 = the value of node 2 + precision, and expect is invalid. In the second conversion, the value of node 1 = the value of node 2, and expect is valid. In the third conversion, the value of node 1 = the value of node 2 - precision, and expect is valid.

[0105] For the 'equal' type node, three conversions are created. In the first conversion, the value of node 1 = the value of node 2 + precision, and expect is invalid. In the second conversion, the value of node 1 = the value of node 2, and expect is valid. In the third conversion, the value of node 1 = the value of node 2 - precision, and expect is invalid.

[0106] For a 'time' type node, create three conversions. In the first conversion, the value of node 1 = the value of node 2 + precision, and expect is valid. In the second conversion, the value of node 1 = the value of node 2, and expect is invalid. In the third conversion, the value of node 1 = the value of node 2 - precision, and expect is invalid.

[0107] In determining the content of the conversion, variables are obtained from the child node to the leaf node until a 'variable' type node is obtained, and the values ​​of all variables are used as input events for the new conversion, that is, the content of each new conversion.

[0108] Step S3233: Determine the second state corresponding to each second format conversion according to the preset rule.

[0109] In some embodiments, step S3233 "determine the second state corresponding to each second format conversion according to the preset rule" includes:

[0110] Step S32331: solving step by step from the child node where the second format conversion is located to the root node according to the content of each second format conversion, and finally obtaining the expected result of each second format conversion at the root node.

[0111] Step S32332: Determine the second state of the corresponding second format conversion according to the expected result.

[0112] After determining the content of each new conversion, you also need to determine the state corresponding to each conversion, that is, the second state. First determine the expected result of each second format conversion when it is created, and then solve it in the direction of the root node. When encountering a 'non' node, the expectation is negated until the root node is solved, and the final expected result is assigned to the Result of the root node. If the Result is invalid, the mutually exclusive state of the first format conversion is selected. As the target state of the new transition, otherwise select the first state s id As the state of the second format conversion, it is the second state.

[0113] Through steps S31 to S32332, the first format requirement described by the mixed formal natural language and the finite state machine is converted into a finite state machine model diagram, namely, a test model diagram, thereby realizing the automatic creation of the test model.

[0114] Step S4: Determine the generation path of each test case according to the finite state machine model diagram.

[0115] After obtaining the test model graph, a traversal algorithm is used to generate a test case for each path. The traversal algorithm principles are as follows:

[0116] 1) State coverage: Every state in the FSM must be covered once.

[0117] 2) Transition Coverage: Every transition in the FSM must be covered exactly once.

[0118] 3) Transition / state coverage criteria: Each transition / state pair in the FSM diagram must be covered once. A transition / state pair refers to a combination of a transition and the only exit state of the transition.

[0119] Step S5: Generate test cases for the target software according to the generation path.

[0120] There are many methods for generating test cases for FSM, such as W algorithm, D algorithm, UIO algorithm, and postman algorithm. Figure 2 As shown, the present invention is only illustrated by the postman algorithm:

[0121] Step S51: From the initial state S i0 Start the traversal.

[0122] Step S52: Obtain the current state S in sequence in The i-th transition and the exit state S of the transition oi .

[0123] Step S53: Determine the exit status S oi Is there an export conversion? If yes, jump to step S54; if no, jump to step S56;

[0124] Step S54: Exit state S oi Whether it appears repeatedly in this traversal path, if yes, jump to step S55, jump, if not, jump to step S56;

[0125] Step S55: take the exit state as the current state and jump to step S52;

[0126] Step S56: Set the initial state S i0 and exit status S oi Generate a test case for the path between them;

[0127] Step S57: Whether the coverage criteria have been met, if yes, jump to step S58, if not, jump to step S51.

[0128] Step S58: End.

[0129] This application solves the problem that test cases are mainly formed by manually writing test cases, or manually building models and then generating test cases based on model analysis, which requires human resources and cannot automatically generate test cases based on natural language requirements. It realizes the automation of the entire process from natural language format requirements to test cases, and greatly improves the efficiency of test design. At the same time, by integrating natural language, finite state and logic tree, it can test and analyze the scenarios of design state transition relationships, timing relationships and logical relationships, and automatically generate test cases, solving the problem that the test case generation algorithms in the prior art cannot perform comprehensive test analysis when facing complex application scenarios containing multiple relationships such as state transition relationships, timing relationships and logical relationships, making the test case generation method more applicable.

[0130] Embodiment 2:

[0131] Based on the foregoing embodiments, the embodiments of the present application provide a test case generation state, and the modules included in the device, as well as the units included in each module, can be implemented by a processor in a computer device; of course, they can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU, Central Processing Unit), a microprocessor (MPU, Microprocessor Unit), a digital signal processor (DSP, Digital Signal Processing) or a field programmable gate array (FPGA, Field Programmable Gate Array), etc.

[0132] like Figure 3 As shown, a test case generation device includes: a first acquisition module 1, a first execution module 2, a second execution module 3, a third execution module 4 and a fourth execution module 5.

[0133] The first acquisition module 1 is used to obtain the test requirements of the target software. The first execution module 2 is used to convert the test requirements into a first format requirement described by a formal natural language, wherein the first format requirement includes a plurality of keywords and identifiers. The second execution module 3 is used to convert the first format requirement into a finite state machine model diagram according to the keywords and identifiers, wherein the finite state machine model diagram includes a plurality of transitions and states. The third execution module 4 is used to determine the generation path of each test case according to the finite state machine model diagram. The fourth execution module 5 is used to generate the test case of the target software according to the generation path.

[0134] In some embodiments, the second execution module 3 includes: a fifth execution module and a sixth execution module.

[0135] The fifth execution module is used to split the first format requirement according to the keywords and identifiers to obtain multiple second format requirements described by a mixture of formal natural language and finite state machine. The sixth execution module is used to convert each of the second format requirements into the finite state machine model diagram according to the keywords and identifiers.

[0136] In some embodiments, the fifth execution module includes: a seventh execution module and an eighth execution module.

[0137] The seventh execution module is used to split the first format requirement into multiple sub-requirements described by formal natural language according to keywords and identifiers. The eighth execution module is used to create a finite state machine and an initial state in each of the sub-requirements to obtain a second format requirement described by a mixture of formal natural language and finite state machine.

[0138] In some embodiments, the sixth execution module includes: a ninth execution module, a tenth execution module, an eleventh execution module, and a twelfth execution module.

[0139] The ninth execution module is used to split the steps of each second format requirement according to the keywords and identifiers to obtain a plurality of first format steps described by a formalized natural language. The tenth execution module is used to convert each first format step into a second format step described by a mixture of a finite state machine and a formalized natural language according to the keywords and identifiers. The eleventh execution module is used to decompose each first format conversion into a plurality of second format conversions described by a finite state machine according to the keywords and identifiers, and determine the second state corresponding to each second format conversion. The twelfth execution module is used to connect each second format conversion with the second state, and at the same time connect each second format conversion with the source state corresponding to the second format step to obtain the finite state machine model diagram.

[0140] In some embodiments, the eleventh execution module includes: a thirteenth execution module, a fourteenth execution module and a first determination module.

[0141] The thirteenth execution module is used to convert each of the first format conversions into a logic tree according to the keyword and the identifier. The fourteenth execution module is used to create a plurality of second format conversions described by a finite state machine according to a preset rule and the logic tree. The first determination module is used to determine the second state corresponding to each of the second format conversions according to the preset rule.

[0142] In some embodiments, the thirteenth execution module includes: a fifteenth execution module, a sixteenth execution module, and a seventeenth execution module.

[0143] The fifteenth execution module is used to create a root node of the logic tree. The sixteenth execution module is used to create multiple levels of child nodes on the root node according to the keyword and the identifier. The seventeenth execution module is used to determine the node type of each child node according to the keyword or the identifier to obtain the logic tree.

[0144] In some embodiments, the fourteenth execution module includes: a seventeenth execution module.

[0145] The seventeenth execution module is used to determine the number of second format conversions created at the child nodes and the content of each second format conversion according to the node type of each child node.

[0146] In some embodiments, the first determination module includes: an eighteenth execution module and a second determination module.

[0147] The eighteenth execution module is used to solve the second format conversion from the sub-node where the second format conversion is located to the root node step by step according to the content of each second format conversion, and finally obtain the expected result of each second format conversion at the root node. The second determination module is used to determine the second state of the corresponding second format conversion according to the expected result.

[0148] Each module in the above-mentioned test case generation device can be implemented in whole or in part by software, hardware and a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the device in the form of hardware, or can be stored in the memory in the processing device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0149] Embodiment 3:

[0150] The third aspect provides an electronic device, including a storage device and a processor, wherein the storage device stores a computer program, and the processor implements the steps of a test case generation method when executing the computer program.

[0151] Embodiment 4:

[0152] A fourth aspect provides a storage medium, which stores a computer program that can be executed by one or more processors, and the computer program can be used to implement the steps of any test case generation method in the first aspect.

[0153] Embodiment 5:

[0154] Fifthly, Figure 4As shown, the present application provides a test case generation system, including: a requirement description module 100, a language analysis module 200, a test model description module, a test analysis module 400 and a test case module 500.

[0155] The requirement description module 100 is used to describe the acquired requirements in a formalized natural language to obtain the first format requirements. The language analysis module 200 is used to convert the first format requirements into a finite state machine model diagram. The test model description module is used to view and edit the finite state machine model diagram. The test analysis module 400 is used to traverse the finite state machine and generate a test path. The test case module 500 is used to generate a test case according to the test path, and view the test path and the test case.

[0156] In some embodiments, the language analysis module 200 includes: a structure analysis module, a hybrid description requirement model and a semantic analysis module.

[0157] The structural analysis module is mainly used to analyze FNL, decompose the FNL format requirements into a structure, and form a FSM+FNL mixed description requirement format. The mixed description module is used to view and edit the generated FSM+FNL mixed description requirements. The semantic analysis module is used to analyze the FSM+FNL mixed description requirements, analyze the FNL format requirements under each transition and state of the FSM, convert them into FSM paths, and form a test model in FSM format.

[0158] Those of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory, etc. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0159] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The above-mentioned sequence numbers of the embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments.

[0160] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0161] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0162] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0163] In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0164] A person of ordinary skill in the art can understand that: all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM, Read Only Memory), disks or optical disks, etc. Various media that can store program codes.

[0165] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can essentially or in other words, the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for a controller to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0166] The above is only an implementation method of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A method for generating a test case, characterized in that: include: Obtain the test requirements of the target software; Converting the test requirement into a first format requirement described in a formal natural language, wherein the first format requirement includes a plurality of keywords and identifiers; Converting the first format requirement into a finite state machine model diagram according to the keyword and the identifier, wherein the finite state machine model diagram includes a plurality of transitions and states; Determine a generation path for each test case according to the finite state machine model diagram; Generate test cases for the target software according to the generation path.

2. The method for generating a test case according to claim 1, characterized in that: The converting the first format requirement into a finite state machine model diagram according to the keyword and the identifier includes: Splitting the first format requirement according to keywords and identifiers to obtain a plurality of second format requirements described by a mixture of formal natural language and finite state machine; Each of the second format requirements is converted into the finite state machine model graph according to the keyword and the identifier.

3. The method for generating a test case according to claim 2, characterized in that: The first format requirement is split according to the keyword and the identifier to obtain a plurality of second format requirements described by a mixture of formal natural language and finite state machine, including: Splitting the first format requirement into a plurality of sub-requirements described in a formal natural language according to keywords and identifiers; A finite state machine and an initial state are created in each of the sub-requirements, and a second format requirement described by a mixture of formal natural language and finite state machine is obtained.

4. The method for generating a test case according to claim 2, characterized in that: The step of converting each of the second format requirements into the finite state machine model diagram according to the keyword and the identifier includes: Splitting each of the second format requirements into steps according to the keywords and the identifiers to obtain a plurality of first format steps described in a formalized natural language; Convert each of the first format steps into a second format step described by a finite state machine and a formal natural language according to the keyword and the identifier, wherein the second format step includes: a first format conversion and a first state, the first state is a corresponding state of the first format conversion, and is described by a finite state machine, the first format conversion is also connected to a source state, the source state is the initial state or the first state of other second format steps, and the first format conversion is described by a formal natural language; Decomposing each of the first format conversions into a plurality of second format conversions described by a finite state machine according to the keyword and the identifier, and determining a second state corresponding to each of the second format conversions; Each of the second format conversions is connected to the second state, and each of the second format conversions is connected to the source state corresponding to the second format step, to obtain the finite state machine model diagram.

5. The method for generating a test case according to claim 4, characterized in that: The step of decomposing each first format conversion into a plurality of second format conversions described by a finite state machine according to the keyword and the identifier, and determining a second state corresponding to each second format conversion, comprises: converting each of the first formats into a logic tree according to the keywords and the identifiers; Creating a plurality of second format conversions described by a finite state machine according to preset rules and the logic tree; The second state corresponding to each second format conversion is determined according to the preset rule.

6. The method for generating a test case according to claim 5, characterized in that: The step of converting each of the first formats into a logic tree according to the keywords and the identifiers includes: Create the root node of the logical tree; Creating multiple levels of child nodes on the root node according to keywords and identifiers; The node type of each of the child nodes is determined according to the keyword or the identifier to obtain the logic tree.

7. The method for generating a test case according to claim 6, characterized in that: The step of creating a plurality of second format conversions according to the preset rules and the logic tree includes: The number of second format conversions created at the child node and the content of each second format conversion are determined according to the node type of each child node.

8. The method for generating a test case according to claim 7, characterized in that: The determining, according to the preset rule, the second state corresponding to each second format conversion includes: Solve the problem step by step from the child node where the second format conversion is located to the root node according to the content of each second format conversion, and finally obtain the expected result of each second format conversion at the root node; A second state of the corresponding second format conversion is determined according to the expected result.

9. A test case generation device, characterized in that: include: A first acquisition module is used to acquire the test requirements of the target software; A first execution module, configured to convert the test requirement into a first format requirement described in a formal natural language, wherein the first format requirement includes a plurality of keywords and identifiers; A second execution module, configured to convert the first format requirement into a finite state machine model diagram according to the keyword and the identifier, wherein the finite state machine model diagram includes a plurality of transitions and states; A third execution module, used to determine a generation path for each test case according to the finite state machine model diagram; A fourth execution module is used to generate a test case for the target software according to the generation path.

10. An electronic device, characterized in that: include: A memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the method according to any one of claims 1 to 8 is performed.

11. A storage medium, characterized in that: The computer program stored in the storage medium can be executed by one or more processors, and the computer program can be used to implement the method according to any one of claims 1 to 8.

12. A test case generation system, characterized in that: include: A requirement description module is used to describe the acquired requirements in a formalized natural language to obtain the first format requirements; A language analysis module, used for converting the first format requirement into a finite state machine model diagram; A test model description module, used for viewing and editing the finite state machine model diagram; A test analysis module, used to traverse the finite state machine and generate a test path; The test case module is used to generate a test case according to the test path, and to view the test path and the test case.