Model-driven test case design method

Through the model-driven test case design method, the problem of traditional test case design relies on manual labor and low coverage is solved, and automated test case generation and high coverage are realized, which simplifies the design process.

CN119883920APending Publication Date: 2025-04-25SHANGHAI ZEZHONG SOFTWARE TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411987121.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-31
Publication Date
2025-04-25

AI Technical Summary

Technical Problem

Traditional test case design methods rely on manual processing, resulting in low coverage of test cases and difficulty in standardizing use, especially in complex systems.

Method used

Using a model-driven test case design method, by obtaining functional points, requirements input and output fields, requirements manuals and other information, establishing test requirements models and tree models, conducting TCD requirements design, generating UML activity diagrams, performing script design, constraint design and scenario design, and automatically generating test cases.

Benefits of technology

Through the model-driven design method, scenario analysis and test case generation are automated, the coverage and standardization of test cases are improved, and the test case design work is simplified.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119883920A_ABST
    Figure CN119883920A_ABST
Patent Text Reader

Abstract

The invention provides a model-driven test case design method, which belongs to the technical field of testing, and comprises the following steps: S100: obtaining a plurality of demand function points based on a plurality of defined function points; s200, obtaining a plurality of demand input field lists and a plurality of demand output field lists; s300, performing TCD demand design based on the test demand model and the test demand tree model, and obtaining a plurality of UML activity diagrams based on the TCD demand design so as to define required activities; s400, defining a field list and a field list value range of each demand function point in the plurality of UML activity diagrams; s500, displaying the plurality of demand function points in a data combination mode; s600, defining a test item; s700, automatically generating a test case based on the test item; s800, the step S600 and the step S700 are repeated until all the test items are defined; the system test case is designed in a model-driven manner, so that the process of scene analysis and test case generation is automated, and the design work of the test case is simpler, more convenient and quicker.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the field of testing technology, and more specifically, particularly relates to a model-driven test case design method. Background Art

[0002] In today's digital age, the complexity of software systems continues to rise, with numerous functional modules, intertwined business logic, and diverse user interactions, resulting in a large testing workload. Traditional test case design methods mostly rely on manual work, such as boundary value analysis and equivalence class division. Although they are effective in simple systems, they are difficult to use in complex systems. In addition, current test cases often have low test case coverage, making it difficult to use test cases in a standard way. Summary of the invention

[0003] In order to solve the above technical problems, the present invention provides a model-driven test case design method to solve the technical problems in the prior art that traditional test case design methods often rely on manual processing and have low test case coverage.

[0004] The purpose and effect of a model-driven test case design method of the present invention are achieved by the following specific technical means:

[0005] A model-driven test case design method includes the following steps:

[0006] S100: Acquire multiple function points, define the multiple function points, and acquire multiple required function points based on the multiple defined function points, wherein the multiple required function points represent functions that need to be executed;

[0007] S200: Acquire multiple requirement input field lists and multiple requirement output field lists, acquire requirement specifications based on the multiple requirement input field lists, the multiple requirement output field lists and the multiple requirement function points, and perform requirement modeling based on the requirement specifications, thereby acquiring a test requirement model and a test requirement tree model;

[0008] S300: performing TCD requirement design based on the test requirement model and the test requirement tree model, and obtaining multiple UML activity diagrams based on the TCD requirement design, thereby defining required activities;

[0009] S400: defining a field list and a field list value range for each of the required function points in a plurality of the UML activity diagrams;

[0010] S500: Displaying the plurality of required function points in a data combination manner, and performing script design, wherein the script design is to perform CSV binding based on the plurality of UML activity diagrams and the test requirement model, thereby obtaining a plurality of UML activity diagrams bound with CSV;

[0011] S600: performing constraint design, wherein the constraint design is to obtain test data, data constraints and M / S configuration, performing scenario design, wherein the scenario design is to obtain a test scenario, and then defining a test item, wherein the test item includes the test scenario, the data constraints, the test data and the M / S configuration;

[0012] S700: Perform case design, wherein the case design is to automatically generate test cases based on the test items, and export the automatically generated test cases;

[0013] S800: Repeat steps S600 and S700 until all the test items are defined.

[0014] As a further solution of the present invention, a scenario design is performed, wherein the scenario design is to obtain a test scenario, including:

[0015] Scenario design is performed, and automatic parsing is performed based on the UML activity diagrams bound to the multiple CSVs and the test requirement model, so as to find the business path and obtain the multiple test scenarios.

[0016] As a further solution of the present invention, scenario design is performed, and automatic parsing is performed based on the UML activity diagrams bound to the plurality of CSVs and the test requirement model, so as to find the business path and obtain the plurality of test scenarios, including:

[0017] Automatically detect multiple UML activity diagrams bound to CSV to obtain N scenarios, list the N scenarios one by one along the vertical direction, and match the requirement nodes in the test requirement model with the N scenarios respectively, so that the requirement nodes included in the N scenarios are listed in the form of a list, and obtain the test scenario based on the N scenarios and the requirement nodes included in the N scenarios.

[0018] As a further solution of the present invention, constraint design is performed, and the constraint design is to obtain test data, data constraints and M / S configuration, including:

[0019] Perform constraint design, add test data, obtain data constraints based on the test scenario and the test requirement model, and obtain the M / S configuration based on the test scenario and the test requirement model.

[0020] As a further solution of the present invention, TCD requirement design is performed based on the test requirement model and the test requirement tree model, and multiple UML activity diagrams are obtained based on the TCD requirement design. The TCD requirement design includes the following steps:

[0021] S3011: Establishing a UML model, obtaining a plurality of UML activity diagrams based on the plurality of required function points, wherein the plurality of UML activity diagrams represent a plurality of different business processes;

[0022] S3012: Associating the plurality of UML activity diagrams with the plurality of required function points respectively.

[0023] As a further solution of the present invention, a plurality of UML activity diagrams are obtained based on the TCD requirement design, thereby defining the required activities, including:

[0024] When in a cross-system process, multiple groups of swim lanes are obtained, and the multiple groups of swim lanes represent different systems. In the UML activity diagram, the multiple groups of swim lanes represent the systems where the activities are located.

[0025] As a further solution of the present invention, a data dictionary is included, and the data included in the plurality of the required functional points are all stored in the data dictionary, and the test data can be obtained through the data dictionary.

[0026] As a further solution of the present invention, the data dictionary adopts a two-layer structure, and the two layers are data dictionary item 1 and data dictionary item 2. The data dictionary item 1 is located at the upper layer of the data dictionary item 2. Multiple groups of data dictionary items x are connected between the data dictionary item 1 and the data dictionary item 2, and the data dictionary item 2 is connected to multiple groups of data dictionary items y.

[0027] As a further solution of the present invention, automatically generating a test case based on the test item includes:

[0028] The test cases include two types of test cases: "valid" and "invalid".

[0029] Compared with the prior art, the present invention has the following beneficial effects:

[0030] First, obtain multiple function points, define the multiple function points, obtain multiple requirement function points based on the multiple defined function points, obtain multiple requirement input field lists and multiple requirement output field lists, and obtain requirement specifications, perform requirement modeling based on the requirement specifications, thereby obtaining a test requirement model and a test requirement tree model, and then perform TCD requirement design based on the test requirement model and the test requirement tree model, obtain multiple UML activity diagrams, define the required activities, and then define the field list and field list value range of each requirement function point in multiple UML activity diagrams, display multiple requirement function points in a data combination manner, and perform script design. The script design is based on multiple UML activity diagrams and the test requirement model. Bind the rows to CSV to obtain multiple UML activity diagrams of bound CSVs, perform constraint design and scenario design, define test items through constraint design and scenario design, and finally, perform case design, automatically generate test cases based on test items, and export the automatically generated test cases, repeatedly define test items, and repeatedly automatically generate test cases based on test items until all test item definitions are completed. Design system test cases in a model-driven manner to automate the process of scenario analysis and test case generation, making test case design easier and faster. The method of using models to describe system requirements and automatic scenario analysis can greatly improve the coverage of test cases and make the designed test cases more standardized and easy to use. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is a flow chart of steps of a model-driven test case design method of the present invention;

[0032] Figure 2 It is a flow chart of the steps of TCD requirement design in a model-driven test case design method of the present invention;

[0033] Figure 3 It is a schematic diagram of a data dictionary in a model-driven test case design method of the present invention. DETAILED DESCRIPTION

[0034] The following is a further detailed description of the embodiments of the present invention in conjunction with the accompanying drawings and examples. The following examples are used to illustrate the technical solutions of the present invention, but cannot be used to limit the scope of protection of the present invention.

[0035] Embodiment 1:

[0036] As attached Figure 1 , Figure 2 , Figure 3 As shown:

[0037] The present invention provides a model-driven test case design method, comprising the following steps:

[0038] S100: Acquire multiple function points, define the multiple function points, and acquire multiple required function points based on the multiple defined function points, where the multiple required function points represent functions that need to be executed.

[0039] Among them, when defining the function points, it is necessary to clarify their roles and functions in the overall system framework based on the business logic of the system, describe the source of their input data, and clearly define the form of their output results. In this way, each function point is given a clear and accurate definition so that it has a clear execution function. After the definition of multiple function points is completed, they are converted into requirement function points and participate in the generation of subsequent test cases.

[0040] Furthermore, it includes a data dictionary. The data contained in multiple required functional points are all stored in the data dictionary, and test data can be obtained through the data dictionary. The data dictionary reflects the business data requirements of the system. The system business data can be protected by creating a data dictionary, and test data can be generated by binding the data dictionary. When testing business functions, the data dictionary can be used to provide test data to test every business data, achieving a higher coverage. Users can import the data dictionary through excel files, which can more conveniently realize the migration of the data dictionary from the business system to the test platform.

[0041] The data dictionary adopts a two-layer structure, which includes data dictionary item 1 and data dictionary item 2. Data dictionary item 1 is located above data dictionary item 2. Multiple groups of data dictionary items x are connected between data dictionary item 1 and data dictionary item 2, and multiple groups of data dictionary items y are connected between data dictionary item 2.

[0042] like Figure 3 As shown, data dictionary item 2 is provided at the lower layer of data dictionary item 1, and data dictionary item 1 is connected to data dictionary item 2, data dictionary item 11, data dictionary item 12 and data dictionary item 13 are provided between data dictionary item 1 and data dictionary item 2, data dictionary item 21 and data dictionary item 22 are provided at the lower layer of data dictionary item 2, and data dictionary item 21, data dictionary item 22 and data dictionary item 2 are connected.

[0043] S200: Obtain multiple requirement input field lists and multiple requirement output field lists, obtain requirement specifications based on the multiple requirement input field lists, multiple requirement output field lists and multiple requirement function points, perform requirement modeling based on the requirement specifications, and thereby obtain a test requirement model and a test requirement tree model.

[0044] S300: Perform TCD requirement design based on the test requirement model and the test requirement tree model, and obtain multiple UML activity diagrams based on the TCD requirement design to define the required activities.

[0045] S400: Define a field list and a value range of the field list for each requirement function point in multiple UML activity diagrams.

[0046] Among them, TCD requirement design is performed based on the test requirement model and the test requirement tree model, and multiple UML activity diagrams are obtained based on the TCD requirement design. The TCD requirement design includes the following steps:

[0047] S3011: Establish a UML model, obtain multiple UML activity diagrams based on multiple required function points, and multiple UML activity diagrams represent multiple different business processes;

[0048] S3012: Associating multiple UML activity diagrams with multiple requirement function points respectively.

[0049] Furthermore, multiple UML activity diagrams are obtained based on the TCD requirement design to define the required activities, including:

[0050] When in a cross-system process, multiple groups of swimlanes are obtained. The multiple groups of swimlanes represent different systems. In the UML activity diagram, the multiple groups of swimlanes represent the system where the activity is located.

[0051] When in a cross-system process, the process is complex and it is difficult to track the process jumping between various systems; test data is interdependent between systems and difficult to prepare; system connectivity issues lead to inadequate testing of subsequent processes; lengthy processes lead to difficulty in controlling the test cycle; since cross-system testing belongs to business process testing, the system business process can be represented by UML activity diagrams. After obtaining the system business process described by the UML activity diagram, the model-driven approach can be used to generate test cases step by step. Using this method to generate test cases can take advantage of the model to achieve a high path coverage, while greatly reducing the workload of test case design. For the process description of cross-system business, a mechanism needs to be introduced to indicate in which system the current activity is performed. In the UML activity diagram, swimlanes can be used to indicate the system where the activity is located.

[0052] S500: Display multiple demand function points in a data combination manner and perform script design. The script design is based on multiple UML activity diagrams and performs CSV binding with the test requirement model, thereby obtaining multiple UML activity diagrams bound to CSV.

[0053] S600: perform constraint design, which includes obtaining test data, data constraints and M / S configuration, perform scenario design, which includes obtaining test scenarios, and then define test items, which include test scenarios, data constraints, test data and M / S configuration;

[0054] Among them, the scenario design is carried out, and the scenario design is to obtain the test scenario, including:

[0055] Perform scenario design and automatically parse the UML activity diagrams and test requirement models based on multiple CSV bindings to find business paths and obtain multiple test scenarios.

[0056] Further scenario design is performed based on automatic parsing of multiple UML activity diagrams and test requirement models bound to CSVs to find business paths and obtain multiple test scenarios, including:

[0057] Among them, constraint design is performed, which is to obtain test data, data constraints and M / S configuration, including:

[0058] Furthermore, constraint design is performed, test data is added, data constraints are obtained based on the test scenario and test requirement model, and M / S configuration is obtained based on the test scenario and test requirement model.

[0059] Automatically detect multiple UML activity diagrams bound to CSV to obtain N scenarios, list the N scenarios one by one along the vertical direction, and match the requirement nodes in the test requirement model with the N scenarios respectively, so that the requirement nodes contained in the N scenarios are listed in the form of a list, and obtain the test scenarios based on the N scenarios and the requirement nodes contained in the N scenarios.

[0060] S700: Perform case design, where the case design is to automatically generate test cases based on test items, and export the automatically generated test cases.

[0061] Among them, test cases are automatically generated based on test items, including: test cases include two types of test cases, "valid" and "invalid". When a test case in "invalid" performs subsequent execution steps, the relevant execution steps will no longer be executed, and only the test case in "valid" performs subsequent execution steps.

[0062] S800: Repeat steps S600 and S700 until all test items are defined.

[0063] The design principle of this method is the demand management model. In the demand management model, the demand function point defines the system function interaction scenario from the user's perspective, which is a concrete manifestation of the demand; the scenario is a collection of business process fragments that implement the demand function point, and refines the function implementation path; the test case is based on the two, and the execution steps, input data and expected output are written for specific scenarios. The three are closely related and progressive, building a demand realization verification chain.

[0064] For example, in e-commerce shopping, the "user order payment" use case includes product selection, order submission, and payment processing scenarios. Each scenario derives test cases containing different payment methods and order statuses, accurately covering the functional testing requirements of each link in the business process; and when establishing the activity diagram, the graph theory node association method is used to abstract the business process into a graph theory model, with components or functions as nodes and interaction relationships as edges. For example, querying the account information and transaction record nodes associated with functional components in the financial system, and clearly sorting out the business logic, data flow and functional dependencies through association analysis, helps testers grasp the overall picture of system architecture and functional coordination, accurately identify key test nodes and paths, and optimize test strategies, such as focusing on testing the functional integrity and stability of densely associated nodes to prevent functional interaction defects.

[0065] A model-driven test case design method proposed in the first embodiment of the present invention first obtains multiple function points, defines the multiple function points, obtains multiple requirement function points based on the multiple defined function points, obtains multiple requirement input field lists and multiple requirement output field lists, obtains a requirement specification, performs requirement modeling based on the requirement specification, thereby obtaining a test requirement model and a test requirement tree model, then performs TCD requirement design based on the test requirement model and the test requirement tree model, obtains multiple UML activity diagrams, defines the required activities, then defines the field list and field list value range of each requirement function point in the multiple UML activity diagrams, displays the multiple requirement function points in a data combination manner, and performs script design, wherein the script design is based on multiple The UML activity diagram is bound to the test requirement model through CSV to obtain multiple UML activity diagrams bound to CSV, and constraint design and scenario design are performed. Test items are defined through constraint design and scenario design. Finally, case design is performed, test cases are automatically generated based on test items, and the automatically generated test cases are exported. Test items are repeatedly defined, and test cases are automatically generated based on test items until all test item definitions are completed. System test cases are designed in a model-driven manner to automate the process of scenario analysis and test case generation, making the test case design work easier and faster. The method of using models to describe system requirements and automatic scenario analysis can greatly improve the coverage of test cases and make the designed test cases more standardized and easy to use.

[0066] The above embodiments can be implemented in whole or in part by software, hardware (such as circuits), firmware or any other combination. When implemented by software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center by a wireless (such as infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more available media sets. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state hard disk.

[0067] It should be understood that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there may be three relationships. For example, A and / or B can represent the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship, but it may also indicate an "and / or" relationship. Please refer to the context for specific understanding.

[0068] It should be understood that in the embodiments of the present invention, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. 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 invention.

[0069] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A model-driven test case design method, characterized in that: The following steps are included: S100: Acquire multiple function points, define the multiple function points, and acquire multiple required function points based on the multiple defined function points, wherein the multiple required function points represent functions that need to be executed; S200: Acquire multiple requirement input field lists and multiple requirement output field lists, acquire requirement specifications based on the multiple requirement input field lists, the multiple requirement output field lists and the multiple requirement function points, and perform requirement modeling based on the requirement specifications, thereby acquiring a test requirement model and a test requirement tree model; S300: performing TCD requirement design based on the test requirement model and the test requirement tree model, and obtaining multiple UML activity diagrams based on the TCD requirement design, thereby defining required activities; S400: defining a field list and a field list value range for each of the required function points in a plurality of the UML activity diagrams; S500: Displaying the plurality of required function points in a data combination manner, and performing script design, wherein the script design is to perform CSV binding based on the plurality of UML activity diagrams and the test requirement model, thereby obtaining a plurality of UML activity diagrams bound with CSV; S600: performing constraint design, wherein the constraint design is to obtain test data, data constraints and M / S configuration, performing scenario design, wherein the scenario design is to obtain a test scenario, and then defining a test item, wherein the test item includes the test scenario, the data constraints, the test data and the M / S configuration; S700: Perform case design, wherein the case design is to automatically generate test cases based on the test items, and export the automatically generated test cases; S800: Repeat steps S600 and S700 until all the test items are defined.

2. A model-driven test case design method according to claim 1, characterized in that: Perform scenario design, where the scenario design is to obtain a test scenario, including: Scenario design is performed, and automatic parsing is performed based on the UML activity diagrams bound to the multiple CSVs and the test requirement model, so as to find the business path and obtain the multiple test scenarios.

3. A model-driven test case design method according to claim 2, characterized in that: Perform scenario design, automatically parse the UML activity diagrams bound to the multiple CSVs and the test requirement model, thereby finding a business path and obtaining multiple test scenarios, including: Automatically detect multiple UML activity diagrams bound to CSV to obtain N scenarios, list the N scenarios one by one along the vertical direction, and match the requirement nodes in the test requirement model with the N scenarios respectively, so that the requirement nodes included in the N scenarios are listed in the form of a list, and obtain the test scenario based on the N scenarios and the requirement nodes included in the N scenarios.

4. A model-driven test case design method according to claim 1, characterized in that: Perform constraint design, which is to obtain test data, data constraints and M / S configuration, including: Perform constraint design, add test data, obtain data constraints based on the test scenario and the test requirement model, and obtain the M / S configuration based on the test scenario and the test requirement model.

5. A model-driven test case design method according to claim 1, characterized in that: Based on the test requirement model and the test requirement tree model, TCD requirement design is performed, and multiple UML activity diagrams are obtained based on the TCD requirement design. The TCD requirement design includes the following steps: S3011: Establishing a UML model, obtaining a plurality of UML activity diagrams based on the plurality of required function points, wherein the plurality of UML activity diagrams represent a plurality of different business processes; S3012: Associating the plurality of UML activity diagrams with the plurality of required function points respectively.

6. A model-driven test case design method according to claim 5, characterized in that: Based on the TCD requirement design, multiple UML activity diagrams are obtained to define the required activities, including: When in a cross-system process, multiple groups of swim lanes are obtained, and the multiple groups of swim lanes represent different systems. In the UML activity diagram, the multiple groups of swim lanes represent the systems where the activities are located.

7. A model-driven test case design method according to claim 1, characterized in that: A data dictionary is included, and the data contained in the plurality of demand function points are all stored in the data dictionary, and the test data can be obtained through the data dictionary.

8. A model-driven test case design method according to claim 7, characterized in that: The data dictionary adopts a two-layer structure, the two layers are data dictionary item 1 and data dictionary item 2, the data dictionary item 1 is located at the upper layer of the data dictionary item 2, multiple groups of data dictionary items x are connected between the data dictionary item 1 and the data dictionary item 2, and the data dictionary item 2 is connected to multiple groups of data dictionary items y.

9. A model-driven test case design method according to claim 1, characterized in that: Automatically generate test cases based on the test items, including: The test cases include two types of test cases: "valid" and "invalid".