CN116719735A

CN116719735A - Test case generation method and device

Info

Publication number: CN116719735A
Application number: CN202310735402.5A
Authority: CN
Inventors: 孙鲜艳; 崔月强
Original assignee: Tianjin Huishang Gongda Technology Co ltd
Current assignee: Tianjin Huishang Gongda Technology Co ltd
Priority date: 2023-06-20
Filing date: 2023-06-20
Publication date: 2023-09-08

Abstract

The application provides a test case generation method and a device, wherein the method comprises the steps of acquiring requirement description information comprising at least one execution step of a software test, and extracting at least one execution step from the requirement description information. And determining a base component according to the operation type of the execution step, wherein the operation type and the base component have a preset corresponding relation. And then acquiring target data based on target parameters input by the base component, wherein the target parameters are at least one parameter preset by the base component. And finally, generating a test case for software testing according to the basic component, the target parameters and the target data. Therefore, based on the basic components, parameters of the basic components and data are used for generating the test cases, if a certain part of the test cases needs to be modified, or input data needs to be modified, only the corresponding basic components need to be modified, modification of other basic components is not involved, and the modification range is small, so that the test case generation efficiency is improved.

Description

Test case generation method and device

Technical Field

The present application relates to the field of software technologies, and in particular, to a method and apparatus for generating test cases.

Background

Software testing is the process of determining a certain software system, the purpose of which is to verify whether the software system meets the needs of a user. Software testing includes manual testing and automated testing. Automated testing is a test process that converts human-driven test behavior into machine execution, and requires the use of test cases. A test case refers to a description of a test task performed on a particular software product, which is a set of test inputs, execution conditions, and expected results that are tailored for a particular goal.

The tester needs to be skilled in a programming language to write test cases for a certain functional module. Therefore, the process of writing test cases has high requirements on the coding capability of testers, and is not applicable to most testers. When a certain part of the test case changes or the input data changes due to system adjustment, a tester is required to adjust the test case by updating the relevant code so as to adapt the test case to the relevant change. These all result in inefficiency in test case generation.

Disclosure of Invention

The application provides a test case generation method and device, which are used for solving the problem of low test case generation efficiency.

In a first aspect, the present application provides a test case generating method, including:

acquiring requirement description information, wherein the requirement description information comprises at least one execution step of a software test;

extracting at least one execution step from the demand description information;

determining an operation type of the execution step, and determining a basic component required by the execution step according to the operation type, wherein the operation type and the basic component have a preset corresponding relation;

acquiring target data based on target parameters input by the base component, wherein the target parameters are at least one parameter preset by the base component;

and generating a test case for software testing according to the basic component, the target parameters and the target data.

In one implementation manner, if data transfer is required between different base components, the base components are further preset with connection parameters, where the connection parameters are used for characterizing a data transfer relationship between the base components, and the generating a test case for software testing according to the base components, the target parameters and the target data includes:

Assigning the target data to the target parameters to generate the basic component for completing configuration;

and splicing the basic components according to the connection parameters and a preset sequence to obtain the test case, wherein the preset sequence is the sequence determined according to the sequence of the execution steps in the requirement description information.

In one implementation, the extracting at least one execution step from the requirement description information includes:

if the requirement description information comprises a text, performing word segmentation on the text, and performing semantic analysis on a word segmentation result to obtain an execution step keyword;

and determining at least one execution step of the requirement description information according to the execution step keywords.

In one implementation, the operation types include at least any one of data acquisition, interface invocation, and code writing.

In one implementation, if the operation type includes data acquisition, the base component required by the executing step includes a database component, if the operation type includes interface call, the base component required by the executing step includes a protocol component, and if the operation type includes code writing, the base component required by the executing step includes a code component;

Acquiring target data based on target parameters input by the base component, including:

if the base component comprises a database component, acquiring target data of target parameters input in a first input box corresponding to the database component;

if the basic component comprises a protocol component, acquiring target data of target parameters input in a second input box corresponding to the protocol component;

and if the basic component comprises a code component, acquiring target data of target parameters input in a third input box corresponding to the code component, wherein the first input box, the second input box and the third input box are input boxes on a test case generation interface displayed on a display, and the first input box, the second input box and the third input box are used for receiving the target data of the corresponding basic component input by a tester in the test case generation interface.

In one implementation, the target data is data corresponding to an SQL statement.

In one implementation, the obtaining the target data based on the target parameters input by the base component includes: acquiring a target data list based on target parameters input by the basic component, wherein the target data list comprises a plurality of target data of the target parameters;

The generating test cases according to the base component, the target parameters and the target data includes: and generating a plurality of test cases according to the basic component, the target parameters and the target data list.

In a second aspect, the present application provides a test case generating device, including:

the system comprises a demand description information acquisition module, a software test module and a software test module, wherein the demand description information acquisition module is used for acquiring demand description information, and the demand description information comprises at least one execution step of the software test;

a step extracting module, configured to extract at least one executing step from the requirement description information;

the basic component determining module is used for determining the operation type of the executing step and determining a basic component required by the executing step according to the operation type, wherein the operation type and the basic component have a preset corresponding relation;

the target data acquisition module is used for acquiring target data based on target parameters input by the base component, wherein the target parameters are at least one parameter preset by the base component;

and the test case generation module is used for generating a test case for software testing according to the basic component, the target parameters and the target data.

As can be seen from the above technical solutions, the present application provides a method and an apparatus for generating a test case, where the method may obtain requirement description information including at least one execution step of a software test, and then extract at least one execution step from the requirement description information. And determining the operation type of the execution step and determining a basic component required by the execution step according to the operation type, wherein the operation type and the basic component have a preset corresponding relation. And then acquiring target data based on target parameters input by the base component, wherein the target parameters are at least one parameter preset by the base component. And finally, generating a test case for software testing according to the basic component, the target parameters and the target data. Therefore, based on the basic components, parameters of the basic components and data are used for generating the test cases, if a certain part of the test cases needs to be modified, or input data needs to be modified, only the corresponding basic components need to be modified, modification of other basic components is not involved, and the modification range is small, so that the test case generation efficiency is improved.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic flow chart of a test case generation method in an embodiment of the application;

FIG. 2 is a connection block diagram of a part of functional modules of a test case generating device according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a visual operation interface of a user-case head configuration in an embodiment of the present application;

FIG. 4 is a schematic diagram of a visual operation interface of a protocol component configuration according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a visual operation interface for database component configuration in an embodiment of the present application;

FIG. 6 is a diagram of a visual operation interface of a code component configuration according to an embodiment of the present application;

FIG. 7 is a flowchart of another test case generating method according to an embodiment of the present application;

FIG. 8 is a schematic diagram illustrating an implementation of a protocol module according to an embodiment of the present application;

FIG. 9 is a schematic diagram illustrating the implementation of a database component in accordance with an embodiment of the present application;

FIG. 10 is a diagram illustrating an implementation of a code component according to an embodiment of the present application;

FIG. 11 is a schematic diagram of a visual operation interface of an automated test platform homepage in an embodiment of the present application;

FIG. 12 is a schematic diagram of a visual operation interface of another embodiment of the present application;

FIG. 13 is a schematic diagram of a first database component configuration according to an embodiment of the present application;

FIG. 14 is a schematic diagram of a first protocol component configuration according to an embodiment of the present application;

FIG. 15 is a diagram illustrating a second database component configuration according to an embodiment of the present application;

FIG. 16 is a diagram illustrating a second protocol component configuration according to an embodiment of the present application;

FIG. 17 is a diagram illustrating a third protocol component configuration according to an embodiment of the present application;

fig. 18 is a schematic diagram of a fourth protocol component configuration according to an embodiment of the application.

Detailed Description

Reference will now be made in detail to the embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The embodiments described in the examples below do not represent all embodiments consistent with the application. Merely as examples of apparatus and methods consistent with some aspects of the application as set forth in the claims.

The automated test procedure for a software system may include the steps of:

the test requirement is analyzed, the test requirement is a test target, namely, the function point of the automatic test, the degree of the automatic test of the software can be judged through the test requirement analysis, and the test coverage rate can be improved through the analysis of the test requirement. The automatic test can prioritize the realization of the forward test cases and then realize the reverse test cases, wherein the reverse test cases can be screened out through analysis. Therefore, the work of determining the test coverage rate, the automatic test granularity, screening test cases and the like are all important points for analyzing the test requirements.

Before the automatic test, a test plan needs to be formulated, and a test object, a test purpose, a test item content, a test method and the like are defined. And the resources such as hardware, data and the like required by the test are reasonably distributed. The test schedule may be monitored using a management tool after the test plan is formulated.

When designing the test case, the real use environment of the software is considered, for example, for performance test and security test, the real environment needs to be simulated by the design scene to ensure that the test is real and effective.

Setting up a test environment, and writing a script for automatic test, wherein the script needs to record page controls and add objects. The construction of the test environment comprises the deployment of a tested system, the calling of test hardware, the installation and the setting of a test tool, the arrangement of a network environment and the like.

And writing and executing the test script, and after the common test framework is determined, entering a script writing stage, and writing the automatic test script according to the automatic test plan and the test cases. The test script is written to require the testers to master basic programming, and the skates need to communicate with the developers so as to know the internal structure of the software and design and write effective test script. After the test script is written, repeated test is needed to be carried out on the test script, so that the correctness of the test script is ensured.

The test case related in the embodiment of the application refers to the description of a specific software product for testing tasks, and the test scheme, method, technology and strategy are embodied. The content of the method comprises a test target, a test environment, input data, a test step, an expected result, a test script and the like, and finally a document is formed. A test case can be simply considered a set of test inputs, execution conditions, and expected results tailored for a particular goal to verify that a particular software requirement is met. Test cases may include test cases of Application Programming Interfaces (APIs) and test cases of User Interfaces (UIs). The embodiment of the application mainly relates to a method and a device for generating test cases of an API (application program interface), namely the finally generated test cases are used for automatically testing the APIs of application programs.

Analyzing the test results and recording the test problems, wherein the step is to analyze the automatic test results so as to discover the defects in the software as soon as possible. The test Bug is tracked and the software Bug found by the test can be recorded in the defect management tool for periodic tracking processing.

The automatic test framework of the software system can adopt frames such as Java+maven+testing and protocol Runner, but the test cases are generated based on the automatic test framework, so that the requirements on the coding capacity of testers are high, and the testers need to master a certain programming language to write the test cases of a certain functional module. When a certain part of the test case occurs or the input data changes due to system adjustment, a tester is required to adjust the test case by updating the relevant code so as to adapt the test case to the relevant change. These all result in inefficiency in test case generation.

In view of the above problems, some embodiments of the present application provide a test case generating method, which is used for automatically generating test cases, so as to improve test case generating efficiency. In order to facilitate understanding of the technical solutions in some embodiments of the present application, the following details of each step are described with reference to some specific embodiments and the accompanying drawings. Fig. 1 is a flowchart of a test case generating method according to some embodiments of the present application. FIG. 2 is a block diagram illustrating connection between functional modules of a test case generating device according to some embodiments of the present application. The test case generating apparatus of fig. 2 is an apparatus for executing the test case generating method shown in fig. 1.

The test case generating device may be a computer, having a processor 11 and having a memory 12. The processor 11 is connected to other hardware via a signal line, and controls the other hardware.

As functional requirement elements, the processor 11 includes a program information input interface 111, a requirement description information acquisition module 112, a step extraction module 113, a base component determination module 114, a target data acquisition module 115, and a test case generation module 116. The functions of the program information input section module 111, the requirement description information acquisition module 112, the step extraction module 113, the base component determination module 114, the target data acquisition module 115, and the test case generation module 116 are implemented by software.

The processor 11 is a device that executes a test case creation program. The test case generation program is a program that realizes the functions of the program information input interface 111, the requirement description information acquisition module 112, the step extraction module 113, the base component determination module 114, the target data acquisition module 115, and the test case generation module 116. The processor 11 may be a CPU (Central Processing Unit ).

The memory 12 is a device that stores a test case creation program. The memory 12 may be RAM (Random Access Memory ), flash memory, or a combination thereof. The memory 12 also stores therein a program of the test object software and specification information of the test object software. The test object software may be any kind of software, in this embodiment embedded software.

The test case creation program is read from the memory 12 by the processor 11 and executed by the processor 11. The memory 12 stores not only a test case generating program but also an OS (Operating System). The processor 11 executes the test case generating program while executing the OS. In addition, a part or all of the test case generating program may be incorporated into the OS.

The data, information, signal values, and variable values utilized by, processed by, or output from the case under test generation program are stored in the memory 12 or a register or cache memory within the processor 11.

The test case generation program is the following program: the computer is caused to execute the processes performed by the program information input interface 111, the requirement description information acquisition module 112, the step extraction module 113, the base component determination module 114, the target data acquisition module 115, and the test case generation module 116 as a program information input process, a requirement description information acquisition process, a step extraction process, a base component determination process, a target data acquisition process, and a test case generation process, respectively. The test case generating program may be provided by being recorded in a computer-readable medium, may be provided by being stored in a recording medium, may be provided as a program product, and may be recorded in the memory 12, for example.

The test case generating device may be configured by 1 computer or by a plurality of computers. In the case where the test case generating apparatus is constituted by a plurality of computers, the functions of the program information input interface 111, the requirement description information acquiring module 112, the step extracting module 113, the base component determining module 114, the target data acquiring module 115, and the test case generating module 116 may be implemented in a distributed manner among the computers.

Based on the test case generating device provided in fig. 2, the test case generating method provided in some embodiments of the present application includes the steps shown in fig. 1:

step S100, obtaining requirement description information, wherein the requirement description information comprises at least one execution step of a software test;

step S200, extracting at least one execution step from the requirement description information;

the requirement description information may be stored in a product requirement document, which may be a PRD (Product Requirement Document) document, and the PRD document is a test document written by a tester according to a preset standard. According to the embodiment of the application, the preset PRD document templates can be provided, and when a tester needs to write a test case, the system controls the preset terminal according to the data acquisition operation of the tester, and a plurality of preset PRD document templates are displayed. And selecting a preset PRD document to be used by a tester according to the requirement, and inputting corresponding content into the preset PRD document template according to the content of the preset PRD document template. According to the data input operation of the tester, the system generates data corresponding to the data input operation in a preset PRD document template to obtain a PRD document for generating the test case, namely, generates the requirement description information for generating the test case. In addition, the requirement description information comprises at least one execution step of the software test.

For example, the requirement description information included in the PRD document of the login operation of a certain software application may be: the user name is input in the user name column, the password is input in the password column, and then the user clicks the confirm button to finish the software login. In this example, the execution steps may be extracted from the demand description information: the user name is entered, the password is entered, and the ok button is clicked. It should be noted that this example indicates a simple example of the requirement description information, which is recorded in other forms in the PRD document. The requirement description information of the PRD document record may be written functional logic data, field description data or business scenario data, for example.

In order to facilitate the operation of a tester, a visual operation interface can be provided on a display of a device for generating test cases (hereinafter referred to as a test device), and the tester can interact with the test device by using the visual operation interface. For example, a tester can perform operations such as test case management, selection of a database to be called, and the like through a visual operation interface provided by the test equipment. The tester can also input the requirement description information based on the visual operation interface.

If the requirement description information comprises a text, word segmentation processing can be performed on the text comprising the requirement description information, and semantic analysis is performed on a word segmentation processing result to obtain an execution step keyword. And then determining at least one execution step of the requirement description information according to the execution step keywords. For example, the text included in the requirement description information is "input user name in user name field, input password in password field, then click on ok button to complete software login", and the word segmentation information obtained after word segmentation of the text is "in user, name field, input, user, name, in password field, input, password, then click, ok, button, complete, software, login". Then, carrying out semantic analysis on the word segmentation information to obtain an execution step keyword of input, user name, input password, click and confirm button, and then determining the execution step of the requirement description information as the input of user name, input password and click confirm button according to the obtained execution step keyword.

Step S300, determining an operation type of the executing step and determining a basic component required by the executing step according to the operation type, wherein the operation type and the basic component have a preset corresponding relation;

The operation type at least comprises any one of data acquisition, interface calling and code writing.

The operation type and the basic component have a preset corresponding relation means that: if the operation type comprises data acquisition, the required basic component corresponding to the execution step comprises a database component; if the operation type comprises interface call, the required basic component corresponding to the execution step comprises an http protocol component; if the operation type includes code writing, the required base component corresponding to the execution step includes a code component.

The determining of the operation type of the execution step may be: the type of operation of the execution step corresponds to the type of operation that needs to be performed in using the application software, or the result that needs to be obtained in the application software according to the execution step. I.e. the type of operation of the execution step is determined based on the type of action of the execution step or the results that the execution step may obtain.

For example, the operation of inputting the user name needs to complete the result of retrieving data from the database, and specifically, the user information corresponding to the user name needs to be retrieved from the database. Thus, the type of operation of entering the user name is data acquisition, and the base component required for this operation is a database component. The operation of inputting the password needs to complete the result of data calling from the database, and particularly needs to call the user information corresponding to the user password from the database. Thus, the type of operation of entering a password is data acquisition, and the basic component required for this operation is a database component. Clicking the ok button needs to complete the page skip operation, specifically needs to skip from the login interface to the main page of the application software, and this process needs to call the access interface of the main page of the application software. Thus, the operation type of clicking the ok button is an interface call, and the basic component required for this operation is an http protocol component.

It should be noted that the operation type includes any one of data acquisition, interface calling and code writing, which means that one piece of requirement description information includes at least one execution step, if the number of the execution steps included is multiple, the multiple execution steps may be the same operation type, and the multiple execution steps may also be different operation types. Correspondingly, the needed basic components corresponding to the needed description information can only comprise one of a database component, a protocol component and a code component, can also comprise two of the database component, the protocol component and the code component, and can also comprise three basic components of the database component, the protocol component and the code component.

Different basic components correspond to different test script fragments, and the different test script fragments can be assembled by splicing the different basic components, so that the automatic test cases for realizing different business scenes are formed. The database component is used for extracting the needed numerical values from different databases and performing splicing or checking. The code component is used for acquiring the value based on a self-defined method and completing the splicing or the value verification with other components. The protocol component is used for completing the request of the protocol request type interface and checking the numerical result, and the protocol component can adopt different transmission protocols to realize the interface request and checking the numerical result, for example, HTTP (Hyper Text Transfer Protocol, hypertext transmission protocol) can be adopted.

Step S400, acquiring target data based on target parameters input by the base component, wherein the target parameters are at least one parameter preset by the base component;

the target parameters are basic parameters of the base component, for example, the target parameters of the database component at least comprise parameters of a target database, an SQL (Structured Query Language )) number, an SQL description, an SQL statement, and the like. The tester may enter or select target data in a parameter field of the database component on the visual operation interface. For example, for a target database, different databases can be selected according to requirements, and the selected database is the target data of the target database, which is the target parameter. The target parameters of the protocol assembly at least comprise parameters such as interface numbers, interface descriptions, request modes, interface protocols, data sources and the like. The tester can also input or select target data in the parameter column of the protocol component on the visual operation interface. For example, for a target parameter, such as an interface protocol, a different interface protocol may be selected, where the selected interface protocol is the target data of the target parameter, such as the interface protocol.

The test device may associate various SQLs with corresponding change languages in advance, and may set an input dialog box as an input interface of an SQL sentence on the visual operation interface. In this way, the tester can input the target data of the target parameters based on the SQL statement. And after the test equipment detects that the input dialog box has data input, acquiring target data based on SQL sentence corresponding data input by the input dialog box as target parameters. It should be noted that SQL is a database query and programming language used to access data and query, update, and manage relational database systems. The structured query language is a high-level, non-procedural programming language that allows testers to work on high-level data structures. The method does not require users to specify a data storage method or require testers to know a specific data storage mode, so that different database systems with completely different substructures can use the same structured query language as an interface for data input and management. The structured query language statement can be nested, which gives it great flexibility and powerful functionality.

Based on SQL, a tester can use simple SQL sentences, directly input target data of target parameters of a test case to be generated in a visual operation interface by the aid of test equipment, without requiring the tester to master complex language changing or specific machine language, and the technical difficulty of writing the test case is reduced.

Since the contents of the test cases include test targets, test environments, input data, test steps, expected results, test scripts, etc. Therefore, parameters such as test environments, case types and the like of the test cases need to be configured in addition to the generation of the test cases based on the base components. In some embodiments, besides inputting target data for target parameters of different base components, a case head configuration may be set, and different base components and case heads may be spliced to form a complete test case.

In some embodiments, if the operation type includes data acquisition, the base component required by the executing step includes a database component, if the operation type includes interface call, the base component required by the executing step includes a protocol component, and if the operation type includes code writing, the base component required by the executing step includes a code component; thus, obtaining target data based on target parameters entered by the base component may include:

If the base component comprises a database component, acquiring target data of target parameters input in a first input box corresponding to the database component; if the basic component comprises a protocol component, acquiring target data of target parameters input in a second input box corresponding to the protocol component; and if the basic component comprises a code component, acquiring target data of target parameters input in a third input box corresponding to the code component, wherein the first input box, the second input box and the third input box are input boxes on a test case generation interface displayed on a display, and the first input box, the second input box and the third input box are used for receiving the target data of the corresponding basic component input by a tester in the test case generation interface.

It can be seen that, in the embodiment of the present application, different input boxes are set for different base components, the database component corresponds to the first input box, the protocol component corresponds to the second input box, the code component corresponds to the third input box, and a tester can select different base components according to actual test requirements, and input target data in the input boxes corresponding to different base components. For example, if one test case needs to use one database component and two protocol components, one first input box and two second input boxes need to be called, after the tester inputs target data in one first input box and two second input boxes, one database component and two protocol components are generated, and the one database component and the two protocol components are spliced to generate the test case. If one test case needs to be used for two database components and one protocol component, two first input boxes and one second input box are required to be called, a tester generates two database components and one protocol component after inputting target data in the two first input boxes and the one second input box respectively, and the two database components and the one protocol component are spliced to generate the test case.

Fig. 3, 4, 5, and 6 illustrate, respectively, a visual operation interface diagram of a use case header configuration, a visual operation interface diagram of a protocol component configuration, a visual operation interface diagram of a database component configuration, and a visual operation interface diagram of a code component configuration, which illustrate specific forms of a first input box, a second input box, and a third input box, respectively.

In fig. 3, the parameter information (i.e., target parameters) of the use case header configuration includes target parameters including: use case names, applications, environments, master modules, sub-modules, use case types, newly added step interfaces (for newly added protocol components), newly added step SQL (for newly added database components), interface numbers, and the like. The use case name characterizes the brief description of the current service use case, and the use case test point, such as a user mall order, can be highlighted. The application is a drop down option, with two classifications being selectable interface automation and UI automation. The environment of the environment feature case execution comprises a UAT (User Acceptance Test ) environment and a pre-upper line environment, the test case can be executed in different deployment environments, and a tester can write the mark case according to different environments.

The main module is used for grouping the sign cases of the main module and is used for different systems and different modules, so that the follow-up cases can be conveniently used for performing granularity division. Test planning and test task formulation. The sub-module characterizes the sub-division group under the parent class, refining the classification. The use case types include multiple interfaces and single interfaces. The newly added step interface is used for newly adding a default use case step component, and defaults to an HTTP use case component. Newly added stepql: clicking the dynamic additional database use case component, displaying relevant parameter configuration content on the page, inputting a box, and inputting and writing SQL script. The interface number characterizes the numeric number in the request address URL (Uniform Resource Locator, same resource locator).

In fig. 4, the target parameters of the protocol component configuration include: interface description, request encryption, request mode, interface protocol, request data, interface path, latency, whether to associate, association parameters, association substitutions, assertion conditions, execution results, return results, etc. The interface describes what tasks are being done to characterize the current request. The request encryption drop down may be optionally unencrypted or encrypted. The request mode characterizes the HTTP request mode, i.e. the client-to-server request message mode, such as post, get. The post request mode submits data to a specified resource for processing requests (e.g., submitting forms or uploading files). The data is contained in the request body and the post request may result in the creation of new resources and/or modification of existing resources. The get request may request specified page information and return the entity body.

The interface protocol drop down may be HTTP or HTTPs. The requested data characterizes a data format that defaults to json format. The interface path characterizes the URL path address. The waiting time characterizes the intermediate waiting time between the interface and the execution of the interface, and if the data volume returned by the interface is large, the waiting time needs to be configured, so that the problem that the returned parameter value information cannot be acquired due to the process of returning the data time is avoided. Whether the association characterizes whether the interfaces are associated or not is used for association configuration among the basic components, and if yes, the basic component connection control program is required to perform corresponding processing.

The associated parameters represent the returned data of the current interface to get the parameters, and the component connection control program can pre-store the parameters needing to be associated. The associated replacement characterizes that parameters returned by other interfaces (base components) are replaced to the current request as an input parameter, and parameter values returned by other base components replace corresponding parameter values in the data of the current request, so that connection and data transfer between the two base components are realized. The assertion condition characterizes a judgment condition for judging whether the interface returns data correctly. The execution result characterizes the current component execution result as failed or passed. The return result characterizes the data returned by the current component execution.

In fig. 5, the target parameters of the database component configuration include: target database, SQL numbers, SQL descriptions, SQL statements, etc. The target database characterizes the environment in which the connection data is selected and the database information, for example, the test environment and the database information can be SQLSerer (business database), sr-Postgress (big database), hsgd_statistics_ uat (data statistics database), and the like. The SQL number is used to mark the coded information of SQL. SQL descriptions are used to describe specific service points for SQL completion. The SQL statement is an SQL statement that implements a specific database operation, such as a select, update, delete, insert, etc.

In fig. 6, the target parameters of the code component configuration include: code number, code description, latency, java code, move up, move down, delete, etc. The code encodes a sequence number for editing the Java steps (steps of the base component implementation). The code description is used to describe business functions or acquisition data functions of a Java code implementation. The waiting time is used for setting the waiting result return time, and if the code return value information is too large, the waiting time is required to be set, so that the completion of the return data of the server is ensured. Java code is a Java coding method that implements specific business functions or obtains data functions. The move up means to move the current step (i.e., the current base component) forward, the move down means to move the current step backward, and the delete means to delete the current step.

And S500, generating a test case for software testing according to the basic component, the target parameters and the target data. In the embodiment of the application, a test case for software testing is generated according to the basic component, the target parameter and the target data, and specifically can be: and after the target data input by the tester are assigned to the target parameters, generating at least one basic component with specific parameter data according to the relation of the target parameters in the basic components. If the current test case only needs to use one basic component, the test case is directly generated according to the basic component, and the generated test case is actually a test script, that is, the test case has only one section of test script.

If the current test case needs to use a plurality of base components and data transfer is not needed among the plurality of base components, the plurality of base components can be simply spliced, namely test script fragments corresponding to the plurality of base components are simply spliced, and the data transfer among the test script fragments is not needed to be considered. It should be noted that in this case, it is still necessary to splice the base components in a preset order determined in accordance with the order of execution steps in the requirement description information. For example, the requirement description information is "input user name in user name field, input password in password field, then click on ok button to complete software login", the order of execution steps is "input user name, input password, click on ok button", and thus the order of base components determined in order of execution steps is "first database component, second database component, protocol component". When different base components are spliced, the different base components are required to be spliced according to the sequence, and in terms of script implementation, the splicing is performed according to the sequence of the test script fragments of the first database component, the test script fragments of the second database component and the test script fragments of the protocol component.

If data transfer is required between different base components, the base components are further preset with connection parameters, where the connection parameters are used to characterize a data transfer relationship between the base components, and as shown in fig. 7, a test case for software testing is generated according to the base components, the target parameters and the target data, and the method includes:

step S301, assigning the target data to the target parameters to generate the base component with the configuration completed;

and step S302, splicing the basic components according to the connection parameters and a preset sequence to obtain the test case, wherein the preset sequence is the sequence determined according to the sequence of the execution steps in the requirement description information.

If the data transfer is not needed between different base components, the base components do not have data transfer relation, that is, the base components are independent, and the different base components are simply stacked when being assembled. If data transfer is required between different base components, there is a data transfer relationship between the base components, that is, the base components do not exist independently, and the base components are not simply stacked when assembled, but the transfer relationship of data between the base components needs to be considered. And specifically, transmitting certain target data to be transmitted in a certain basic component to one or more basic components, so that the one or more basic components execute corresponding test scripts by using the target data to obtain an execution result.

For example, the requirement description information is "input user name in user name field, input password in password field, then click on ok button to complete software login", the order of execution steps is "input user name, input password, click on ok button", and thus the order of base components determined in order of execution steps is "first database component, second database component, protocol component". When the first database component, the second database component and the protocol component are spliced, the target data, namely the user name in the first database component, is required to be transmitted to the protocol component, and the target data, namely the user password in the second database component, is required to be transmitted to the protocol component, so that when the test script of the first database component, the test script of the second database component and the test script of the protocol component are spliced, the test scripts of the three are not overlapped in sequence. The user name called by the first database component is transferred to the protocol component, and the user password called by the second database is transferred to the protocol component, so that the protocol component can execute the user login operation by using the user name and the user password, and the purpose of assembling the completed test case is achieved.

In practical application, the implementation process of the protocol component is as shown in fig. 8:

the method comprises the steps of firstly judging the type of a component by executing a doRequest method in a caseRun method, and if the type of the component is judged to be a protocol component, preparing data by performing work before request through HTTPRequest. Data parameters are encrypted before the background request of the service, so that the data is encrypted by an encryption method. The tester then makes a package call using the PostDataTools method to request parameters in the use case configuration (target data for target parameters entered by the tester in the base component input box). The HTTP pre-request job also includes get, post type request encapsulation call processing.

The post and get methods in PostDataTools are then performed, requesting data in the business background (business background refers to the actual business system code), and placing the data returned by the HTTP request business background into the postResult variable. Because the data returned by the service background is encrypted, the returned data is also required to be decrypted by using a decipher in the PostDataTools method, and the returned data is changed into a plaintext json data format after the decryption is successful.

And then, a replace method in PostDataTools is called to judge whether the current step has a parameter connection mode (namely whether data transfer is needed between base components), and if the current step does not have the parameter connection mode (namely, the current base component does not need to carry out data transfer with other base components), the assertion is carried out. Specifically, the method (including) is called to carry out verification of returned data, and the obtained expected parameter values set by the user are compared. If the current step has a parameter connection mode, the parameters required by the connection mode are extracted from json by analyzing the returned json data through the JsonObject tool class. And then, the returned json extraction parameters are put into global variables in the form of keys and values by an autoincoreHashMap method. And finally, putting the executed result into an object ApiTaskResult so that the executed result is returned to a foreground web page, and displaying the executed result to a tester through the web page.

If a plurality of database components exist in one test case assembly, the steps can be circularly executed, and the current database component puts the AutoIncreHashMap of the last database component into a global variable for replacement by a replace method before executing the steps.

In practical application, the execution process of the database component is as shown in fig. 9:

firstly, judging the type of the component by executing the doRequest method in the caseRun method, and if the type of the component is judged to be the database component, performing the database connection preparation work. Wherein the preparation work comprises: and if the connection mode exists, replacing the SQL parameters by a replay method to ensure the integrity and the accuracy of the SQL statement. The service database connection information is configured into an automatic test mutual database, and is associated through the service modules, when the foreground generates a use case, the selected service modules are transmitted to an automatic test background, and the automatic test background can find the database connection information according to the selected service modules. For example, database information is assembled through DBUtil three-way plug-in units, and keywords such as select, insert, update, delete and the like in SQL sentences are judged, so that a data processing method in DBUtil is executed.

If the data updating is required to be executed according to the keywords in the SQL statement, executing an update method in the DBUtil to update the data in the database. If the data search is required to be executed according to the keywords in the SQL statement, executing the map method in the DBUtil, inquiring the service database data, and transferring the reference to the key information of the inquired data.

The return data is then formatted into json string format by the tojson string method in the json plug-in. And the json string format data is put into a result variable, and the result variable transmits the data downwards. And judging whether a connection mode exists in the current step through a replace variable. If the current step does not have a parameter connection pattern (i.e., the current base component does not need to communicate data with other base components), then an assertion is made. Specifically, the method (including) is called to carry out verification of returned data, and the obtained expected parameter values set by the user are compared. If the current step has a parameter connection mode, the parameters required by the connection mode are extracted from json by analyzing the returned json data through the JsonObject tool class. And then, the returned json extraction parameters are put into global variables in the form of keys and values by an autoincoreHashMap method. And finally, putting the executed result into an object ApiTaskResult so that the executed result is returned to a foreground web page, and displaying the executed result to a tester through the web page.

In practical application, the execution process of the code component is as shown in fig. 10:

firstly, judging the type of a component by executing a doRequest method in a caseRun method, and if the type of the component is judged to be a database code component, performing preparation work before a database connection request, wherein the preparation work comprises performing replacement of parameters of a replacement method if a connection mode exists in a code.

After the complete code is obtained, the runCode method in the dealWithJavaShell method is executed. This is because Java code is compiled through Java commands to run after it has passed. After compiling, a temporary class file is generated, and code is executed by running the command java+ class file.

And (3) serializing the returned result after the code is executed into json format data through Json.toJsonString, then putting the json character string format data into a result variable, and then transmitting the data downwards by the result variable. And judging whether a connection mode exists in the current step through a replace variable. If the current step does not have a parameter connection pattern (i.e., the current base component does not need to communicate data with other base components), then an assertion is made. Specifically, the method (including) is called to carry out verification of returned data, and the obtained expected parameter values set by the user are compared. If the current step has a parameter connection mode, the parameters required by the connection mode are extracted from json by analyzing the returned json data through the JsonObject tool class. And then, the returned json extraction parameters are put into global variables in the form of keys and values by an autoincoreHashMap method. And finally, putting the executed result into an object ApiTaskResult so that the executed result is returned to a foreground web page, and displaying the executed result to a tester through the web page.

It can be seen that in the embodiment of the present application, a plurality of different base components may be preconfigured, and a corresponding relationship is established between the base components and the operation types, where in reality, the base components encapsulate different test script fragments and then are presented in the form of components. When the test case is generated, different basic components are called according to different operation steps, namely different test script fragments are called, and then the basic components are spliced according to the logic relation corresponding to the operation steps, namely the test scripts corresponding to the basic components are spliced.

The basic components suitable for the current test application can be obtained by modifying the target parameters and the target data of the basic components, and the required test cases are obtained after the modified basic components are spliced, so that the generation efficiency of the test cases is improved. In addition, in the embodiment of the application, the test case generation process is performed by utilizing the visual operation interface, and a tester can automatically generate the test case only by inputting the requirement description information, selecting the target parameters and inputting the target data on the visual operation interface. Therefore, a tester does not need to master a specific programming language, and can operate to generate required test cases, so that the test experience of the tester is improved.

Based on the connection frame diagram shown in fig. 2, the test case generation process of the present application is as follows: the requirement description information acquisition module 111 acquires requirement description information including at least one execution step of the software test from the program information input interface 112, and transmits the acquired requirement description information to the step extraction module 113. The step extraction module 113 extracts at least one execution step from the requirement description information and then transmits the extracted execution step to the base component determination module 114. The base component determination module 114 determines the type of operation to perform the step and then determines the base component required to currently perform the step based on the correspondence between the type of operation and the base component. The target data acquisition module 115 acquires target data based on target parameters input by the base component. The base component determination module 114 then sends the base component determined to be needed to the test case generation module 116, while the target data acquisition module 115 sends the information of the target parameters and the target data to the test case generation module 116. Finally, the test case generation module 116 generates a test case for software testing according to the required basic components, the target parameters and the target data.

In some embodiments, a target data list based on target parameters entered by the base component may be obtained, wherein the target data list includes a plurality of the target data for the target parameters; the generating test cases according to the base component, the target parameters and the target data includes: and generating a plurality of test cases according to the basic component, the target parameters and the target data list. Therefore, a plurality of different test cases can be generated at the same time, and the test case generation efficiency is further improved. After the test cases are generated, the tester can select the generated test cases and execute the generated test cases on the test equipment.

Based on the test case generation method in the above embodiment, the test case generation on the visual operation interface may be the following process, and the following examples are login and request examples completed by the protocol component and the database component in combination with the test case.

In the visual operation interface diagram shown in fig. 11, a tester may first log in to the automated test platform and then select API use case management under use case management. Then click the new use case button, the page jumps from the visual operation interface shown in fig. 11 to the visual operation interface shown in fig. 12 in response to the button instruction input by the tester. The visual operation interface shown in fig. 12 includes a case header configuration area and a new step area, where the case header configuration area is used to set basic information of a test case. The new step area comprises a new interface button, a new SQL button and a new script button, which correspond to a new protocol component, a new database component and a new code component respectively.

First, a database component (first database component) is newly added, and the database component is used for obtaining information such as user name, user password and the like required by user login. And selecting a target database as a UAT environment SQLServer master database in a setting area of the database component, describing the user operation to be completed in the step as deleting the user leave record, inputting an actual database operation code in an SQL sentence input dialog box, configuring a connection parameter as a CUSTOMER_ID, and storing the connection parameter CUSTOMER_ID for the use of the subsequent step component. The newly added first database component configuration is shown in fig. 13.

A new protocol component (first protocol component) is then added, the first protocol component being used to simulate a user logging into the system. In the setting area of the first protocol component, the interface number 10 is selected, the interface is described as partner login, encryption is required to be selected for request encryption, get is selected for request mode, HTTP is selected for interface protocol, and target data of target parameters such as data source, request data, interface path, waiting time and the like are required to be filled. The step is that the user logs in, after the user logs in, the user information needs to be acquired, and then the acquired user information is prestored for the following testing step (basic component). Thus, in the protocol component, whether the "association" is configured as "yes", the parameters that require the pre-stored processing are "token" and "CUSTOMER_ID". The assertion condition after this step is executed is to include the text "king XX", where king XX corresponds to interface number 10. After the verification result is processed by the system, if the processing result contains the content in the assertion condition, the step is operated correctly (marked as pass); if the processing result does not contain content in the predicate condition, the step operates as an error (labeled as fial). The configuration of the newly added first protocol component is shown in fig. 14.

After the simulation user logs in the system, the simulation user asks for the fact that the request time is the dynamic time (one day after the current time), so that in order to acquire the dynamic parameter value information (the dynamic time), a database component (a second database component) needs to be newly added. Presetting a dynamic parameter for data preprocessing in the next request step. The second database component configuration is shown in fig. 15. The second database component needs to return the processing result as the time of day after the current time.

When the simulation user asks for a false, a protocol component (a second protocol component) needs to be added again, and in the visual operation interface shown in fig. 16, the ask for a false interface needs to be called for parameter replacement, so that the ask for a false is simulated. And setting a connection mode as a replacement parameter at the association configuration place, setting a parameter name as StartTime, performing parameter replacement processing at the request data, and exchanging the parameter value with a dynamic time parameter value pre-stored in the database component in the last step. The protocol component returns a processing result example "{" leave type ":1, "startTime": "2023-02-28 10:29:03"," leaveTime ":1, "leaveReason": "interface automated test leave" }.

After the user request is simulated, the user cancellation request operation can be simulated, for example, cancellation is performed on the request result, a protocol component (a third protocol component) needs to be newly added, and the third protocol component is utilized. In the protocol component, the sequence number value cancelled at this time needs to be acquired first. The configuration of the third protocol component is shown in fig. 17.

Then, a protocol component (a fourth protocol component) is added, and the fourth protocol component is used for calling the request query interface to obtain the serial number value of the current leave. The connection mode is configured to be yes (whether the association is configured to be yes), the association parameter is leave (leave identifier), and the program acquires the leave of the current leave from the returned numerical value and performs pre-storing. And after the unique identification parameter of the request is obtained, calling a cancel leave interface to replace the parameter, and finally finishing cancel leave operation. The configuration of the fourth protocol component is shown in fig. 18.

In this example, the executing step of the leave-out service is to obtain the user name, log in by the user, determine the leave-out time, and determine the leave-out time, where the corresponding base components are spliced in the order of the first database component, the first protocol component, the second database component, and the second protocol component. The data acquired by the first database component is the user name (i.e., the CUSTOMER_ID) and this parameter is set to the connection parameter (i.e., the parameter passed down). The data transferred between the first database component and the first protocol component is a user name, and the login interface is called by the user name in the first protocol component to complete the login of the leave system. The data acquired by the second database component is the leave-out time, and the parameter is set as the connection parameter. The first database component transmits the user name to the second protocol component, the second database component transmits the leave time to the second protocol component, the second protocol component finishes the leave operation processing by utilizing the user name and the leave time, and records the leave information (the leave information is provided with a unique identification parameter, namely leave code).

The executing step of canceling the leave-out service is to acquire the unique identifier of the leave-out request, cancel the leave-out request, the corresponding splicing sequence of the basic components is a third protocol component and a fourth protocol component, and the set association parameter is leave code. The third protocol component uses the unique identification parameter acquisition interface to acquire the unique identification parameter of the leave request, prestores the unique identification parameter and transmits the unique identification parameter to the fourth protocol component. And the fourth protocol component calls the cancellation request interface according to the unique identification parameter to perform parameter replacement, and the cancellation leave service is completed.

According to the embodiment of the application, the basic components required by the current service are determined according to the operation types corresponding to the execution steps included in different services, the tester can input the target data of the target parameters included in the basic components by utilizing the visual operation interface, and then the configured basic components are spliced according to the sequence of the execution steps to automatically generate the test cases, so that the tester does not need to program, the tester can generate the test cases conveniently, and the test case generation efficiency can be improved.

The above-provided detailed description is merely a few examples under the general inventive concept and does not limit the scope of the present application. Any other embodiments which are extended according to the solution of the application without inventive effort fall within the scope of protection of the application for a person skilled in the art.

Claims

1. A test case generation method, comprising:

extracting at least one execution step from the demand description information;

2. The test case generating method according to claim 1, wherein if data transfer is required between different base components, the base components are further preset with connection parameters, the connection parameters are used for characterizing a data transfer relationship between the base components, and the generating the test case for software testing according to the base components, the target parameters and the target data includes:

3. The test case generating method according to claim 1, wherein the extracting at least one execution step from the requirement description information includes:

4. The test case generating method according to claim 1, wherein the operation type includes at least any one of data acquisition, interface call, and code writing.

5. The test case generating method according to claim 4, wherein, if the operation type includes data acquisition, the base component required by the executing step includes a database component, if the operation type includes interface call, the base component required by the executing step includes a protocol component, and if the operation type includes code writing, the base component required by the executing step includes a code component;

6. The test case generation method of claim 5, wherein the target data is data corresponding to an SQL statement.

7. The test case generating method according to claim 1, wherein the acquiring the target data based on the target parameters input by the base component includes: acquiring a target data list based on target parameters input by the basic component, wherein the target data list comprises a plurality of target data of the target parameters;

8. A test case generating apparatus, comprising:

9. The test case generating device according to claim 8, wherein if data transfer is required between different base components, the base components are further preset with connection parameters, the connection parameters are used for characterizing a connection data transfer relationship between the base components, and the generating the test case according to the base components, the target parameters and the target data includes:

10. The test case generating device according to claim 8, wherein the extracting at least one execution step from the requirement description information includes: