Test case generation method and system based on demand document analysis

Abstract

The invention provides a test case generation method and system based on demand document analysis, and the method comprises the steps: obtaining a demand document, inputting the demand document into a pre-trained recognition model, and outputting the relation between entities in the demand document by the recognition model; constructing a first UML class diagram based on the relationship between the entities, wherein the first UML class diagram comprises a connection line corresponding to the node of each entity and the relationship between the entities; obtaining a second UML class diagram constructed by the technician through the demand document, and comparing the first UML class diagram with the second UML class diagram; determining whether there is a difference between the first UML class diagram and the second UML class diagram; if so, reporting the difference node and the difference relation obtained by comparison; and if the first UML class diagram does not exist, analyzing the first UML class diagram or the second UML class diagram into a corresponding test case.

Description

Technical Field

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

[0002] In the complex and delicate process of software development, the writing of test cases plays a pivotal role and its importance cannot be ignored. As the cornerstone of software quality assurance, test cases not only provide a clear guide for the testing team, but also are the key to ensuring the correct implementation of software functions, stable performance and good user experience.

[0003] First of all, test cases are the core driving force of testing work. During the software development cycle, testers carefully design test cases covering various functions and scenarios based on detailed requirements documents and design specifications. These use cases describe the test steps, input data, and expected output results in detail, providing testers with clear test paths and verification criteria. By executing these use cases, the testing team can systematically check all aspects of the software to ensure that its behavior under different conditions and scenarios is as expected, thereby effectively reducing defects and vulnerabilities in the software.

[0004] Secondly, the writing of test cases helps improve the efficiency and accuracy of testing work. By pre-defining the test steps and expected results, testers can focus more on executing the test without having to frequently refer to the requirements document or design specifications during the testing process. This not only saves time, but also reduces testing errors caused by misunderstandings or omissions. At the same time, the repeatability and verifiability of test cases make the testing work more objective and reliable, helping the testing team to accurately evaluate the stability and reliability of the software.

[0005] However, traditional test cases mainly rely on manual writing, which is inefficient and prone to omissions and errors. Summary of the invention

[0006] In view of this, an embodiment of the present invention provides a test case generation method and system based on requirement document parsing to eliminate or improve one or more defects existing in the prior art.

[0007] One aspect of the present invention provides a test case generation method based on requirement document parsing, the method comprising the steps of:

[0008] Obtaining a requirement document, inputting the requirement document into a pre-trained recognition model, and the recognition model outputting entities and relationships between entities in the requirement document;

[0009] Building a first UML class diagram based on the entities and the relationships between the entities, wherein the first UML class diagram includes a node corresponding to each entity and a connection line between the entities;

[0010] Obtain a second UML class diagram constructed by the technician from the requirement document, and compare the first UML class diagram and the second UML class diagram;

[0011] Determine whether there is a difference between the first UML class diagram and the second UML class diagram; if so, report the difference nodes and difference relationships obtained by comparison; if not, parse the first UML class diagram or the second UML class diagram into a corresponding test case.

[0012] By adopting the above scheme, on the one hand, this scheme can extract entities in the requirement document and the relationship between entities in the requirement document through the pre-trained recognition model, and construct it into a first UML class diagram, and then compare the first UML class diagram with the second UML class diagram constructed by the technician according to the requirement document. Since both may have errors, this scheme compares the two with each other. On the one hand, it can improve the accuracy of test case writing, and on the other hand, it can improve the efficiency of test case writing through the recognition model.

[0013] In some embodiments of the present invention, in the steps of obtaining a requirement document, inputting the requirement document into a pre-trained recognition model, and the recognition model outputting entities in the requirement document and relationships between entities, the requirement document is encoded to obtain an encoded document, and the encoded document is input into a pre-trained recognition model, and the recognition model outputs corresponding codes of the identified entities and corresponding codes of relationships between entities.

[0014] In some embodiments of the present invention, in the step of constructing the first UML class diagram based on the relationships between entities, each entity is used as a node in the first UML class diagram, and the nodes in the first UML class diagram are connected based on the relationships between entities.

[0015] In some embodiments of the present invention, in the step of connecting the nodes in the first UML class diagram based on the relationship between entities, different annotations are set on the connection line for each relationship between entities, and corresponding annotations are set for the nodes with existing relationships in the first UML class diagram.

[0016] In some implementations of the present invention, the step of comparing the first UML class diagram and the second UML class diagram includes:

[0017] Establishing a correspondence between the root nodes in the first UML class diagram and the second UML class diagram, and establishing a correspondence between the nodes in the first UML class diagram and the second UML class diagram that are connected to the root node, hop by hop, starting from the root node;

[0018] Compare all nodes and connections between nodes having corresponding relationships in the first UML class diagram and the second UML class diagram.

[0019] In some implementations of the present invention, the step of establishing a correspondence between the root nodes in the first UML class diagram and the second UML class diagram further includes:

[0020] The nodes in the first UML class diagram and the second UML class diagram are traversed, and reverse tracing is performed based on the directionality of the connection between the nodes to determine the root nodes in the first UML class diagram and the second UML class diagram.

[0021] In some embodiments of the present invention, in the step of reporting the difference nodes and difference relationships obtained by comparison if they exist, the difference nodes and difference relationships obtained by comparison are marked in the first UML class diagram and the second UML class diagram, and the marked first UML class diagram and the second UML class diagram are reported to the control end.

[0022] In some implementations of the present invention, if any, the step of reporting the difference nodes and difference relationships obtained by comparison further includes receiving a third UML class diagram fed back by the control end, and parsing the third UML class diagram into a corresponding test case.

[0023] In some embodiments of the present invention, in the step of parsing the third UML class diagram into a corresponding test case or parsing the first UML class diagram or the second UML class diagram into a corresponding test case: the first UML class diagram, the second UML class diagram or the third UML class diagram is parsed into a corresponding code format document, and a corresponding test case is generated based on the code format document.

[0024] The second aspect of the present invention also provides a test case generation system based on requirement document parsing, the system comprising a computer device, the computer device comprising a processor and a memory, the memory storing computer instructions, the processor being used to execute the computer instructions stored in the memory, and when the computer instructions are executed by the processor, the system implements the steps implemented by the method described above.

[0025] The third aspect of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps implemented by the aforementioned test case generation method based on requirement document parsing.

[0026] Additional advantages, purposes, and features of the present invention will be described in part in the following description, and will become apparent to those skilled in the art after studying the following, or may be learned from the practice of the present invention. The purposes and other advantages of the present invention can be specifically pointed out and obtained in the specification and the accompanying drawings.

[0027] Those skilled in the art will appreciate that the objectives and advantages that can be achieved with the present invention are not limited to the above specific description, and the above and other objectives that can be achieved by the present invention will be more clearly understood from the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The drawings described herein are used to provide a further understanding of the present invention, constitute a part of this application, and do not constitute a limitation of the present invention.

[0029] Figure 1 A schematic diagram of an implementation method of a test case generation method based on requirement document parsing of this solution;

[0030] Figure 2 This is a schematic diagram of the overall architecture of this solution;

[0031] Figure 3 This is a schematic diagram for reverse verification of this scheme. DETAILED DESCRIPTION

[0032] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments and the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0033] It should also be noted that, in order to avoid obscuring the present invention due to unnecessary details, only structures and / or processing steps closely related to the solutions according to the present invention are shown in the accompanying drawings, while other details that are not closely related to the present invention are omitted.

[0034] In the field of software testing in the existing technology, traditional test cases are mainly written manually, which is inefficient and prone to omissions and errors. Although some solutions for intelligently generating test cases have emerged, such as those based on rule templates and machine learning, they all have certain defects.

[0035] 1. Manual editing

[0036] 1. Inefficiency: Testers need to understand the requirement documents word by word and write test cases, which consumes a lot of time and manpower costs, especially in large software projects.

[0037] 2. Accuracy is difficult to guarantee: Manual operations are prone to negligence and there may be deviations in the understanding of requirements, resulting in test cases that cannot fully cover software functions or incorrect test scenarios.

[0038] 3. Lack of consistency: The style and quality of test cases written by different testers may vary, which is not conducive to subsequent maintenance and management.

[0039] (II) Common Problems of Intelligent Solutions

[0040] 1. Unable to cope with complex demands: Common intelligent solutions do not fully understand complex business needs, and the training results of neural networks are usually not explainable, making it difficult to verify the results.

[0041] 2. Heavy reliance on data: Common intelligent solutions rely heavily on data and need to continuously collect data to ensure accuracy. In many cases, automation cannot be achieved.

[0042] 3. Unexplainable: The test cases generated by common intelligent solutions are not explainable.

[0043] 4. Lack of objective evaluation criteria: Common intelligent solutions for generating test cases usually do not have objective evaluation criteria.

[0044] 5. Insensitive to time series changes: Common intelligent solutions are not sensitive enough to time series and cannot analyze and retain the status of different historical periods.

[0045] The purpose of the present invention is: on the one hand, to solve the problems of low efficiency, low accuracy, and uneven quality among different people in manual writing; on the other hand, to solve the problems of intelligent solutions, especially in terms of explainability, objective evaluation standards, and feedback on temporal changes.

[0046] like Figure 1 and 2 As shown, the present invention proposes a test case generation method based on requirement document parsing, the steps of the method comprising:

[0047] Step S100, obtaining a requirement document, inputting the requirement document into a pre-trained recognition model, and the recognition model outputting entities and relationships between entities in the requirement document;

[0048] In some embodiments of the present invention, the recognition model is a pre-trained convolutional neural network model.

[0049] In some embodiments of the present invention, the step of obtaining a requirement document and inputting the requirement document into a pre-trained recognition model includes preprocessing the requirement document. The preprocessing step may be to segment the requirement document and delete meaningless words therein. The meaningless words may be prepositions or participles, etc.

[0050] In the specific implementation process, the requirements document is pre-built by the staff. The requirements document is the core document in the software development project. It elaborates on the various requirements that the software product or service should meet and provides a clear work guide for the development team. This document not only describes the functional requirements of the software, such as the functional characteristics, business processes, user interface design, etc. expected by users, but also covers non-functional requirements, such as performance, security, availability, compatibility and operation and maintenance requirements. When writing the requirements document, you must first clarify the background and goals of the project and outline the problems that the software is designed to solve and its expected effects. Then, list all functional requirements in detail, including user roles, operation scenarios, input and output requirements, etc., to ensure that each requirement is specific and measurable. At the same time, for non-functional requirements such as response time, system capacity, data security, etc., clear indicators and thresholds should also be set. In addition, the requirements document should also include a preliminary design or prototype of the user interface and interface definitions with other systems. For easy tracking and management, each requirement should be assigned a unique identifier and indicate its priority, source and possible change history. The writing of the requirements document should be clear and accurate, and avoid using vague or ambiguous language. It is not only the basis for the development team's work, but also an important reference for testing, acceptance and post-maintenance. Through regular review and update, it ensures that the document is consistent with the actual progress of the project and effectively guides the smooth progress of the project.

[0051] During the specific implementation process, this solution deeply analyzes the correspondence between various elements and relationships in the UML class diagram and the natural language expressions in the requirement document, and establishes a comprehensive semantic mapping rule library.

[0052] For entities, define the mapping rules from nouns or noun phrases in the requirements document to UML classes. For example, when the requirements document mentions concepts such as "user", "order", and "product", they correspond to the "User" class, "Order" class, and "Product" class in the UML class diagram, respectively, and clarify their naming specifications and mapping methods for attribute definitions.

[0053] For relationships, detailed mapping rules are formulated for different types of relationships (such as generalization, aggregation, composition, dependency, etc.). For example, for a "generalization" relationship, when "a class A is a subclass of another class B" or similar expressions appear in the requirements document, the mapping to the UML class diagram is the relationship that class A inherits from class B. It is clear how to identify this expression and accurately convert it into the corresponding UML code structure.

[0054] Step S200, constructing a first UML class diagram based on entities and relationships between entities, wherein the first UML class diagram includes nodes corresponding to each entity and lines between the entities;

[0055] Step S300, obtaining a second UML class diagram constructed by a technician from a requirement document, and comparing the first UML class diagram with the second UML class diagram;

[0056] In some implementations of the present invention, in the step of comparing the first UML class diagram with the second UML class diagram, the corresponding nodes in the first UML class diagram and the second UML class diagram are compared one by one.

[0057] Step S400, determining whether there is a difference between the first UML class diagram and the second UML class diagram; if so, reporting the difference nodes and difference relationships obtained by comparison; if not, parsing the first UML class diagram or the second UML class diagram into corresponding test cases.

[0058] As the core component of the Unified Modeling Language (UML), the UML class diagram is an indispensable tool in the object-oriented software design and development process. It graphically displays the classes and interfaces in the system and the various relationships between them, such as inheritance, implementation, association, aggregation and combination.

[0059] In UML class diagrams, a class is usually represented by a rectangle that contains the class name, properties, and methods. The class name is at the top of the rectangle, and the properties (i.e., class member variables) and methods (i.e., class member functions) are listed in the middle and bottom of the rectangle, respectively. Interfaces are represented by a rectangle with a "< <interface>>" tag, which contains only method declarations and no attribute definitions.

[0060] The class diagram not only shows the internal structure of the class, but more importantly, reveals the interactions and relationships between classes. For example, inheritance relationships are represented by solid lines with hollow arrows, with the arrows pointing to the parent class or interface; association relationships are represented by solid lines, sometimes with arrows to indicate navigation; aggregation and composition relationships are represented by hollow and solid diamonds with solid lines, with arrows pointing to partial classes.

[0061] UML class diagrams are widely used in the software development process. They can help developers better understand the structure of the system, clarify the responsibilities of classes and their dependencies, and thus guide the implementation and maintenance of the code. At the same time, class diagrams are also an important part of software documentation, which can provide strong support for subsequent testing, deployment and upgrades. Therefore, mastering the skills of drawing and interpreting UML class diagrams is of great significance to improving the efficiency and quality of software development.

[0062] In a specific implementation process, the control end receives the difference nodes and difference relationships obtained by comparison, and constructs a third UML class diagram based on the difference nodes and difference relationships.

[0063] In a specific implementation process, if there is no difference between the first UML class diagram or the second UML class diagram, either one of them is parsed to obtain a test case.

[0064] In the specific implementation process, this solution uses UML class diagrams to describe the business model. Through the attributes of the class diagram and the relationship between classes, the business model can be clearly understood. This solution uses PlantUML for explanation. PlantUML is a UML class diagram tool that supports a comprehensive code syntax and ecology.

[0065] By adopting the above scheme, on the one hand, this scheme can extract entities in the requirement document and the relationship between entities in the requirement document through the pre-trained recognition model, and construct it into a first UML class diagram, and then compare the first UML class diagram with the second UML class diagram constructed by the technician according to the requirement document. Since both may have errors, this scheme compares the two with each other. On the one hand, it can improve the accuracy of test case writing, and on the other hand, it can improve the efficiency of test case writing through the recognition model.

[0066] In the specific implementation process, Figure 2 The steps are shown below;

[0067] 1. The business should write the requirement document in the standard and agreed format. For example, nouns must use the nouns in the "unified language" (the unified language formed in the previous event storm). For example, the system, module, operation transaction, etc. must be clearly described.

[0068] 2. Business, technology, and testing conduct event storming based on the requirement document (a way to capture requirements in the domain-driven design concept, and other forms such as use case diagrams can also be used). It is a communication method that emphasizes the joint establishment of business models by business and technology, similar to brainstorming. Through multiple iterations of communication, consensus is reached and business models and unified language are formed.

[0069] The business model is a simple diagram that is understandable to the business, similar to the UML class diagram.

[0070] Unified language means reaching a consensus on the business language during the iterative communication process. For example, in the credit system, the front-end uses customers as credit users, and credit user is a name we have agreed upon.

[0071] 3. Based on the business model and unified language, the technology is in charge to draw a specific UML class diagram to form a real model. If the corresponding business model already exists, compare whether there are any differences and make modifications. The business model is persistent, not temporary. After each iteration of requirements, the model is supplemented. Later, regression verification can be performed based on the model.

[0072] 4. Parse the UML class diagram to generate the code format document corresponding to the business model. This article uses PlantUML as a tool for UML class diagram. Code syntax support has been provided for PlantUML, which can directly realize the conversion between class diagram and syntax code.

[0073] 5. Based on the code format document, test cases are automatically output through fixed templates or machine learning, which will be described in detail below.

[0074] 6. Train entity recognition models and relationship recognition models. The models can be used to parse requirement documents and output entities and relationships between entities.

[0075] 7. Based on the relationship between entities, we can convert it into a class diagram code format document by setting a fixed conversion template. To generate test cases based on the code format document, see step 5. The code document generated by the requirement document can be compared with the generated code document to achieve reverse verification of the class diagram.

[0076] In some embodiments of the present invention, in the steps of obtaining a requirement document, inputting the requirement document into a pre-trained recognition model, and the recognition model outputting entities in the requirement document and relationships between entities, the requirement document is encoded to obtain an encoded document, and the encoded document is input into a pre-trained recognition model, and the recognition model outputs corresponding codes of the identified entities and corresponding codes of relationships between entities.

[0077] In the specific implementation process, in the step of encoding the demand document, the encoding method used can be ASCII encoding, ANSI encoding, Unicode encoding or UTF-8 encoding, etc.;

[0078] ASCII encoding uses 7-bit or 8-bit binary numbers to represent 128 or 256 possible characters. Standard ASCII code, also called basic ASCII code, uses 7-bit binary numbers (the remaining 1 bit is 0) to represent all uppercase and lowercase letters, numbers 0 to 9, punctuation marks, and special control characters used in American English;

[0079] ANSI encoding supports character sets of multiple languages, but different ANSI encoding standards may be incompatible. Commonly used ANSI encodings include GB2312, GBK, and GB18030, which are used to support the storage and display of Chinese characters;

[0080] Unicode encoding uses a fixed length (usually 2 bytes or 4 bytes) to represent each character, thus avoiding compatibility issues between different encoding standards. Unicode encoding provides a rich character set, including text, punctuation marks, and special symbols in various languages. There are two commonly used representations of Unicode encoding: UCS-2 (using 2 bytes) and UCS-4 (using 4 bytes). Among them, UCS-2 can represent 65535 characters, while UCS-4 can represent more characters;

[0081] UTF-8 encoding uses 1 to 4 bytes to represent a character, and the specific length depends on the Unicode code point of the character. UTF-8 encoding has backward compatibility, that is, ASCII code remains unchanged in UTF-8 encoding, so old ASCII text can be easily processed. UTF-8 encoding is widely used in fields such as the Internet and e-mail because it can effectively represent characters in multiple languages ​​and has a small storage space requirement.

[0082] The processing of the recognition model is as follows:

[0083] (1) Collection and organization of requirements documents: Collect historical requirements-related documents, including but not limited to functional requirements specifications, user stories, business process descriptions and other relevant business knowledge documents, to ensure that most business scenarios and functional requirements are covered. The collected documents need to be processed initially, such as removing parts with confusing formats, incomplete content, and irrelevant business parts.

[0084] (2) Word Segmentation: Based on a unified language, construct a trie or hash table, and start scanning the text character by character from the beginning of the text. When a character is scanned, look up in the constructed data structure to see if there is an entity name starting with that character. If a complete entity name is found, segment it out as a word. For example, if "customer Zhang San" appears in the text and there is an entity "customer" in the entity relationship table, then "customer" is segmented out as a word. For the remaining text part that is not recognized as an entity name, use a general word segmentation tool for word segmentation. For example, for Chinese text, the jieba word segmentation tool can be used to reasonably segment common words and phrases.

[0085] (3) BIO Tagging

[0086] B (Begin) Tagging Rule: When a word segmentation result exactly matches an entity in the entity relationship table and it is the first occurrence of that entity in the text, it is tagged as "B - entity type". For example, if the word segmentation result is "customer" and it appears for the first time in the text, and the entity type of "customer" in the entity relationship table is "customer type", then it is tagged as "B - customer type".

[0087] I (Inside) Tagging Rule: When a word segmentation result exactly matches an entity in the entity relationship table and it comes after a word that has been tagged as "B - entity type", it is tagged as "I - entity type". For example, for the text "customer Zhang San and customer Li Si", "customer" is tagged as "B - customer type", and if "Zhang San" and "Li Si" are recognized as specific instances of the customer type entity in the entity relationship table, then "Zhang San" and "Li Si" are tagged as "I - customer type".

[0088] O (Outside) Tagging Rule: For word segmentation results that do not match any entity in the entity relationship table, they are tagged as "O". For example, words such as "in", "October 2024", "26th" are tagged as "O".

[0089] (4) Data Partitioning

[0090] Partition the labeled requirement document data into a training set, a validation set, and a test set. The training set is used for model training and parameter learning. The validation set is used to adjust the hyperparameters of the model and evaluate the model's performance during training. The test set is used to finally evaluate the generalization ability and effect of the model on unseen data.

[0091] Stratified sampling is usually used to divide data to ensure that the entity types and relationship distributions in each data set are relatively balanced. For example, first divide the data into several levels according to different business areas or functional modules, and then extract a certain proportion of data from each level as training sets, validation sets, and test sets. The specific division ratio can be adjusted according to the scale of the data and the actual situation. The common ratio is 70% (training set), 15% (validation set), and 15% (test set).

[0092] (5) Model training phase

[0093] Methods based on deep learning have achieved good results in entity recognition tasks. Models such as long short-term memory network (LSTM), gated recurrent unit (GRU), convolutional neural network (CNN) or Transformer architecture can be selected for entity recognition training. These models can effectively process sequence data, learn contextual information and semantic features in text, and accurately identify the boundaries and types of entities.

[0094] In the entity recognition model, entities and corresponding text representing the relationship can be identified.

[0095] In UML class diagrams, the following relationships are common:

[0096] Generalization, Realization, Association, Aggregation, Composition, Dependency. Therefore, we need to use the relationship text to determine what kind of relationship it belongs to.

[0097] In some embodiments of the present invention, in the step of constructing the first UML class diagram based on the relationships between entities, each entity is used as a node in the first UML class diagram, and the nodes in the first UML class diagram are connected based on the relationships between entities.

[0098] In some embodiments of the present invention, in the step of connecting the nodes in the first UML class diagram based on the relationship between entities, different annotations are set on the connection line for each relationship between entities, and corresponding annotations are set for the nodes with existing relationships in the first UML class diagram.

[0099] In some implementations of the present invention, the step of comparing the first UML class diagram and the second UML class diagram includes:

[0100] Establishing a correspondence between the root nodes in the first UML class diagram and the second UML class diagram, and establishing a correspondence between the nodes in the first UML class diagram and the second UML class diagram that are connected to the root node, hop by hop, starting from the root node;

[0101] Compare all nodes and connections between nodes having corresponding relationships in the first UML class diagram and the second UML class diagram.

[0102] In the specific implementation process, the correspondence between the root nodes in the two UML class diagrams is first determined, and based on the correspondence between the nodes connected to the root nodes, that is, the correspondence between the nodes with a one-hop distance, the correspondence between the nodes connected to the nodes with a one-hop distance is determined, that is, the correspondence between the nodes with a two-hop distance. According to the above scheme, the correspondence between the nodes connected to the root nodes in the first UML class diagram and the second UML class diagram is constructed hop by hop.

[0103] By adopting the above scheme, the present scheme determines the corresponding relationship between nodes in the above manner, so as to facilitate comparison.

[0104] In some implementations of the present invention, the step of establishing a correspondence between the root nodes in the first UML class diagram and the second UML class diagram further includes:

[0105] The nodes in the first UML class diagram and the second UML class diagram are traversed, and reverse tracing is performed based on the directionality of the connection between the nodes to determine the root nodes in the first UML class diagram and the second UML class diagram.

[0106] Using the above solution, since the UML class diagram has a root node, which is the starting node of the diagram, this solution accurately determines the position of the root node through the above method.

[0107] In some embodiments of the present invention, in the step of reporting the difference nodes and difference relationships obtained by comparison if they exist, the difference nodes and difference relationships obtained by comparison are marked in the first UML class diagram and the second UML class diagram, and the marked first UML class diagram and the second UML class diagram are reported to the control end.

[0108] In some implementations of the present invention, if any, the step of reporting the difference nodes and difference relationships obtained by comparison further includes receiving a third UML class diagram fed back by the control end, and parsing the third UML class diagram into a corresponding test case.

[0109] In some embodiments of the present invention, in the step of parsing the third UML class diagram into a corresponding test case or parsing the first UML class diagram or the second UML class diagram into a corresponding test case: the first UML class diagram, the second UML class diagram or the third UML class diagram is parsed into a corresponding code format document, and a corresponding test case is generated based on the code format document.

[0110] In the specific implementation process, the requirement document is parsed, and the known entities and relationships can be converted into UML code format through fixed mapping relationships.

[0111] The beneficial effects of this program include:

[0112] 1. Improve efficiency and accuracy

[0113] Compared with manually writing test cases, the present invention can automatically generate test cases, greatly improving the efficiency of test case generation and saving a lot of time and labor costs, especially in large-scale software projects.

[0114] Through analysis based on models and requirement documents, errors caused by human understanding deviations are reduced, the accuracy of test cases is improved, software functions can be covered more comprehensively, and the risk of missing important test scenarios is reduced.

[0115] (II) Enhance the ability to handle complex requirements

[0116] In view of the problem that existing intelligent solutions have difficulty understanding complex business requirements, the present invention introduces methods such as business models and event storming, which can better analyze and model complex businesses, thereby generating test cases more accurately and adapting to various complex software system requirements.

[0117] Ability to identify and handle multiple relationship types (such as generalization, aggregation, composition, etc.), have a deeper understanding of the structure and relationships of the software system, and provide a basis for generating comprehensive and targeted test cases.

[0118] 3. Improving explainability and verifiability

[0119] Different from the unexplainable training results of neural networks, the test case generation process of the present invention has clear steps and logic. From requirement document parsing, UML class diagram analysis to test case generation, each link can be explained and traced, which is convenient for developers and testers to understand and verify.

[0120] like Figure 3 As shown, by reverse verifying the UML class diagram, errors and inconsistencies in the generation process can be discovered and corrected in a timely manner, further improving the quality and reliability of the test cases.

[0121] 4. Considering time series changes and objective evaluation criteria

[0122] Paying attention to changes in time series can analyze and preserve the status of software systems in different historical periods, providing strong support for software evolution and maintenance, which is an aspect that existing intelligent solutions often overlook.

[0123] A relatively objective evaluation standard has been established. By evaluating indicators such as test case coverage and accuracy, as well as verifying and analyzing each link in the generation process, the quality and effectiveness of test cases can be evaluated more scientifically.

[0124] (V) Overall technical process and method system

[0125] It includes a complete series of technical processes and method systems, including the writing specifications of requirement documents, the implementation process of event storms, the drawing and analysis of UML class diagrams, the analysis of requirement documents based on unified language and BIO annotations, the generation algorithm of test cases, and the reverse verification mechanism. Protecting this overall technical framework can ensure that others cannot easily copy the core ideas and implementation methods of the entire invention, and ensure the uniqueness and innovation of the invention in the field of software testing.

[0126] (VI) Key technology algorithms and models

[0127] Such as UML class diagram parsing algorithm, feature extraction and relationship recognition algorithm based on BIO annotation, template and data mining algorithm for test case generation, difference detection algorithm for reverse verification, and other key technical algorithms and models. These are the core technical components to realize the functions of the present invention. Protecting them can prevent others from directly using or imitating these key technologies, thereby maintaining the technical advantages and commercial value of the present invention.

[0128] (VII) Specific data structure and format definition

[0129] These include the definition and format of the unified language in the requirements document, the standardized format of the UML class diagram, and the data structure and code format involved in the parsing and generation process. These specific data structures and format definitions are important factors in ensuring that the entire invention system can operate and interact effectively, and their protection can ensure the uniqueness and standardization of the invention in terms of data processing and information transmission.

[0130] 8. Software Tools and System Implementation

[0131] If the present invention involves the development of specific software tools or systems, such as requirement document parsing tools, UML class diagram processing tools, test case generation systems, etc., protecting the implementation codes, user interface designs, functional module architectures, etc. of these software tools and systems can prevent others from copying or imitating the software implementation of the present invention, thereby ensuring the exclusivity and competitiveness of the present invention in practical applications.

[0132] An embodiment of the present invention also provides a test case generation system based on requirement document parsing, the system comprising a computer device, the computer device comprising a processor and a memory, the memory storing computer instructions, the processor being used to execute the computer instructions stored in the memory, and when the computer instructions are executed by the processor, the system implements the steps implemented by the method described above.

[0133] The embodiment of the present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps implemented by the test case generation method based on requirement document parsing are implemented. The computer-readable storage medium can be a tangible storage medium, such as a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a floppy disk, a hard disk, a removable storage disk, a CD-ROM, or any other form of storage medium known in the technical field.

[0134] It should be understood by those skilled in the art that the exemplary components, systems and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software or a combination of the two. Whether it is performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present invention are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link via a data signal carried in a carrier.

[0135] It should be clear that the present invention is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0136] In the present invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with features of other embodiments or replace features of other embodiments.

[0137] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.< / interface>

Claims

1. A test case generation method based on requirement document parsing, characterized in that: The steps of the method include: Obtaining a requirement document, inputting the requirement document into a pre-trained recognition model, and the recognition model outputting entities and relationships between entities in the requirement document; Building a first UML class diagram based on the entities and the relationships between the entities, wherein the first UML class diagram includes a node corresponding to each entity and a connection line between the entities; Obtain a second UML class diagram constructed by the technician from the requirement document, and compare the first UML class diagram and the second UML class diagram; Determine whether there is a difference between the first UML class diagram and the second UML class diagram; if so, report the difference nodes and difference relationships obtained by comparison; if not, parse the first UML class diagram or the second UML class diagram into a corresponding test case.

2. The test case generation method based on requirement document parsing according to claim 1 is characterized in that: In the steps of obtaining a requirement document, inputting the requirement document into a pre-trained recognition model, and the recognition model outputting entities in the requirement document and relationships between entities, the requirement document is encoded to obtain an encoded document, and the encoded document is input into a pre-trained recognition model, and the recognition model outputs corresponding codes of the recognized entities and corresponding codes of relationships between entities.

3. The test case generation method based on requirement document parsing according to claim 1 is characterized in that: In the step of constructing the first UML class diagram based on the relationships between entities, each entity is used as a node in the first UML class diagram, and the nodes in the first UML class diagram are connected based on the relationships between entities.

4. The test case generation method based on requirement document parsing according to claim 3 is characterized in that: In the step of connecting the nodes in the first UML class diagram based on the relationship between entities, different annotations are set on the connection lines for each relationship between entities, and corresponding annotations are set for the nodes with relationships in the first UML class diagram.

5. The test case generation method based on requirement document parsing according to any one of claims 1 to 4, characterized in that: The step of comparing the first UML class diagram and the second UML class diagram comprises: Establishing a correspondence between the root nodes in the first UML class diagram and the second UML class diagram, and establishing a correspondence between the nodes in the first UML class diagram and the second UML class diagram that are connected to the root node, hop by hop, starting from the root node; Compare all nodes and connections between nodes having corresponding relationships in the first UML class diagram and the second UML class diagram.

6. The test case generation method based on requirement document parsing according to claim 5 is characterized in that: The step of establishing a corresponding relationship between the root nodes in the first UML class diagram and the second UML class diagram further includes: The nodes in the first UML class diagram and the second UML class diagram are traversed, and reverse tracing is performed based on the directionality of the connection between the nodes to determine the root nodes in the first UML class diagram and the second UML class diagram.

7. The test case generation method based on requirement document parsing according to claim 1 or 6, characterized in that: In the step of reporting the difference nodes and difference relationships obtained by comparison if they exist, the difference nodes and difference relationships obtained by comparison are marked in the first UML class diagram and the second UML class diagram, and the marked first UML class diagram and the second UML class diagram are reported.

8. The test case generation method based on requirement document parsing according to claim 1 is characterized in that: If so, the step of reporting the difference nodes and difference relationships obtained by comparison further includes receiving a third UML class diagram fed back by the control end, and parsing the third UML class diagram into a corresponding test case.

9. The test case generation method based on requirement document parsing according to claim 8 is characterized in that: In the step of parsing the third UML class diagram into a corresponding test case or parsing the first UML class diagram or the second UML class diagram into a corresponding test case: the first UML class diagram, the second UML class diagram or the third UML class diagram is parsed into a corresponding code format document, and a corresponding test case is generated based on the code format document.

10. A test case generation system based on requirement document parsing, characterized in that: The system includes a computer device, which includes a processor and a memory. The memory stores computer instructions. The processor is used to execute the computer instructions stored in the memory. When the computer instructions are executed by the processor, the system implements the steps implemented by the method as described in any one of claims 1 to 9.

Images