CN112306861A - Unittest and Jenkins tool-based interface automatic testing system and method - Google Patents

Abstract

The invention relates to the field of interface automatic test systems, in particular to an interface automatic test system and a method based on Unittest and Jenkins tools, which simplify project codes through data driving, improve reusability of use cases, reduce later maintenance cost of test scripts, widen test coverage scenes by introducing a database module for database verification, design the problem that data is stored in object attributes to solve the dependency of upper and lower interface data, read data in the test cases through an openpyxl module, realize test data parameterization through a regular and configuration file, realize data driving through an ddt module, initiate HTTP requests through a requests module to finally generate HTML-based test reports, and finally deploy the HTML-based test reports into the Jenkins tools to form a continuous integrated interface automatic test system with high integrity and high universality.

Description

Unittest and Jenkins tool-based interface automatic testing system and method

Technical Field

The invention relates to the field of interface automatic test systems, in particular to an interface automatic test system and method based on Unittest and Jenkins tools.

Background

The interface test is a means for testing the system interface function by simulating the application scene of the upper application or the system upper calling interface mainly by means of a unit test technology. Essentially, the interface test is used to verify the correctness of each method that constitutes the software. The interface test inherits the concept of 'test preposition', the service logic of the software product can be tested earlier through the interface test, the problems existing in the project can be found in advance and solved, and the quality of the product can be better ensured.

Today, most companies are mainly designed to test manually, and for a long-term stable or logically complex project, the manual testing is only needed to waste a lot of manpower, and the long-term repeated labor is inevitably careless to cause human careless omission. At present, some companies realize the importance of the automated interface test and start to build an own automated phone interface test system, but the test system is not flexible and complete enough, for example, parameterized data driving is not achieved, only interface test is carried out, a background database is not checked, the frame design is not concise, and a test suite still needs to be manually executed.

unittest: the unittest is a Python-self unit test framework, can organize and execute test cases, and provides rich assertion methods for judging whether the test cases pass or not and finally generating test results.

Jenkins tool: the Jenkins tool is a continuous integration tool for monitoring continuous and repeated work and aims to provide an open and easy-to-use software platform so that continuous integration of software becomes possible.

openpyxl module the openpyxl module is a Python library that reads and writes excel files.

ddt Module, also called Data-Driven Design, where ddt module exists as a decorator in Python to achieve parameterization of the Data.

Disclosure of Invention

Technical problem to be solved

Aiming at the defects of the prior art, the invention provides an interface automatic test system and method based on Unittest and Jenkins tools, which are complete in automatic test system and can be continuously integrated.

(II) technical scheme

In order to achieve the purpose, the invention provides the following technical scheme: the utility model provides an automatic test system of interface based on unitest and Jenkins instrument, its characterized in that, includes unit test frame, openpyxl module and Jenkins instrument, unit test frame includes the TestCommon layer, and the TestCommon layer includes test case module, database module, parameterization module, request module and log module, the test case module links to each other with openpyxl module, and re module, ddt module and Jenkins instrument are connected gradually to the output of openpyxl module.

The improvement of the invention is that the database module is connected with a pymysql module for self-checking the database.

The invention has the improvement that the invention also comprises a TestData module, and the TestData layer is connected with the parameterization module.

The invention further provides an automatic interface testing method based on Unittest and Jenkins tools, which comprises the following steps:

step 1, writing test data into a file in a form of a use case;

step 2, encapsulating a public method, namely reading data, reading a configuration file, initiating a request, inquiring a database, parameterizing and operating a log file;

step 3, compiling a configuration file, and writing the commonly used parameter configuration into the configuration file;

step 4, compiling a test case, and compiling the test case of the TestCase class under the unit test module;

step 5, compiling a test suite;

step 6, newly building a project in a Jenkins tool, and deploying an interface automation project package;

and 7, executing a construction program by the Jenkins tool to generate a test result.

The improvement of the invention is that the step 1 comprises the following steps:

step 1, opening a worksheet in a workbook;

step 2, reading the worksheet data by rows, and converting the read data objects into lists;

step 3, traversing the first element of the list in the step 2,

adding the traversed value into a new list;

step 4, traversing the remaining elements of the list in the step 2, adding the traversed values into a new list, and aggregating the list in the step 2 through an aggregation function to obtain an aggregation object;

step 5, transmitting the aggregation object into the written data class to generate an instance object for storing test data, wherein the aggregation object is composed of various primitive progenitors after being converted into a list, and two elements in the primitive progenitors are divided into attributes and values which serve as the instance object;

and 6, storing and returning the instance object in the step 5 through the list, and acquiring the attribute value through the object when the test case is executed.

The improvement of the invention is that the writing of the configuration file in the step 3 specifically comprises: the device comprises a unit test module, an ddt module, a test data reading module and a parameterization module.

The improvement of the invention is that the parameterization step in the step 3 is specifically as follows:

step 1, test data are transmitted;

step 2, obtaining data to be replaced in the test data through query of a regular expression;

step 3, acquiring fields to be replaced through grouping in the regular expression;

step 4, reading data in the configuration file through the field in the step 3;

step 5, replacing the test data to be replaced in the step 2 with the data read in the step 4;

and 6, returning the test data.

The improvement of the invention is that the test in the step 7 comprises the following specific steps:

step 1, reading data in a test data file and configuring;

step 2, generating final test data through a parameterized function;

step 3, creating a request object, initiating an http request to a server through the request object, and receiving a request result;

step 4, requesting an actual result and an expected result through the assertion check interface;

step 5, checking the actual result and the expected result of the database through assertion;

and 6, generating a test result according to the result verification of the step 4 and the step 5, writing the test result back to the test data file, and outputting a corresponding test log.

(III) advantageous effects

Compared with the prior art, the invention provides a system and a method for an interface automatic test system based on Unittest and Jenkins tools, and the system and the method have the following beneficial effects:

the automatic interface test system based on the Unittest and Jenkins tools simplifies project codes through data driving, improves reusability of use cases, reduces maintenance cost of test scripts in later periods, simultaneously widens test coverage scenes by introducing a database module for database verification, designs data storage in object attributes, solves the problem of upper and lower interface data dependence, and is an automatic test system with high integrity and high universality.

Drawings

FIG. 1 is a block diagram of the overall system of the present invention;

FIG. 2 is a flow chart of the integrated interface automated testing system of the present invention;

FIG. 3 is a flow chart of reading test data according to the present invention;

FIG. 4 is a flow chart of the present invention for executing test cases;

FIG. 5 is a flow chart of parameterization in accordance with the present invention;

FIG. 6 is a flow chart of database querying according to the present invention;

FIG. 7 is a flow chart of the upper and lower interface parameter transmission of the present invention;

FIG. 8 is a flowchart of reading a configuration file according to the present invention;

FIG. 9 is a flow chart of an interface request initiation of the present invention;

FIG. 10 is a flow chart of the operational test suite of the present invention;

FIG. 11 is a Jenkins tool deployment project flow diagram.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Referring to fig. 4, the interface automation test system based on unitest and Jenkins tools of the present invention is characterized by comprising a unit frame, an openpyxl module and Jenkins tools, wherein the unit frame comprises a TestCommon layer, the TestCommon layer comprises a test case module, a database module, a parameterization module, a request module and a log module, the test case module is connected with the openpyxl module, and an output end of the openpyxl module is sequentially connected with a re module, an ddt module and the Jenkins tools.

And a test data module. And packaging the test data class, introducing a third-party module openpyxl, and reading and writing the excel file. In the past, data are read according to cells, and the method has problems that a data file needs to be added or subtracted in a row, and codes for reading data in a script need to be modified. Here, we can read data by rows and convert the read data objects into list types by using the rows method under the openpyxl module. The data objects read from each row are aggregated with the data objects read from the first row by an aggregation function starting from the second row. In python, all objects are classified into objects, a class is created in advance to enable the aggregation object to be entered into the parameters, and then the meta-ancestors obtained by the aggregation function are divided into attributes and values stored as the objects through a setr function. The method has the advantages that the method for reading the data does not need to maintain and modify any data file structure at the later stage, and the read use case data is instantiated, so that scripts can be written conveniently, and the efficiency is improved.

In this embodiment, the database module is connected to a pymysql module for performing self-check on the database.

And a database module. After some interfaces are tested, the database is changed, and the correctness of the returned values of the interfaces is not only required to be checked, but also the database needs to be further checked, so that the rigor of the test work is improved. And packaging a database operation class, importing a pymysql module, and connecting the access parameters mainly including host, port, username, password and database to the database by using a connect method. It should be noted here that after the database is connected, a cursor needs to be created by using a cursor method to perform operations such as querying the database.

And a parameterization module. The parametric data is mainly divided into two types, static parameters and dynamic parameters. Static parameters are parameters written into the configuration file, such as login account and password of the login function. The dynamic parameters are dynamically generated, such as the return value of the previous interface as the parameter of the next interface. It is necessary to design in conjunction with the TestData layer that the parameters are not written to death in the data sheet, but are presented in the form of keywords. To facilitate regular expression matching, special signs may be added at the beginning and end of the keywords, such as "{ phone:" @ phone @ ". To solve the problem of upper and lower interface parameter dependence, a class is created in the module to store data. If a certain value in the previous interface is needed to be used, a function setattr can be stored as the attribute and the value of the class, and the later interface is obtained through the class attribute when needing to be used. And (3) importing a re module, wherein a search method in the module can perform matching of the regular expression, and after matching, replacing data by a sub method, for example, replacing the data by static parameters read from a configuration file or dynamic attribute values stored in a class.

And a request module. And packaging the http request class, wherein when an interface request is initiated, the main parameters comprise an interface address, test data, a request method and a request header. When an interface test is performed, a plurality of interfaces are called to send out a plurality of requests, and some common data such as cookies are required to be kept in the requests sometimes. The session object of the requests library can help us keep certain parameters across requests.

And a log module. By introducing the logging module, a log collector and a log output channel are generated, and the log output channel can be bound in a fixed log format.

In this embodiment, the system further includes a TestData module, and the TestData layer is connected to the parameterization module.

The TestData layer prepares test data, mainly addresses of interfaces, request modes, and designs different test data according to different scenes of different interfaces. When the data of the test case is written in the excel table, because the database needs to be checked at necessary places when the test case is executed, the column of sql query needs to be added in the test data. The same logic function can write the test data in the same form, and different logic functions can be used for writing another form.

The TestConf layer is used to store common configuration data such as the address of the database, the user name, and the password. Static parameters in the test data can be stored, and then the static parameters are read from the configuration file for replacement through a regular expression function packaged by a parameterization module when the TestCase is executed, so that the parameterization data is realized.

The TestCase layer, i.e. the test case layer, is the core in the interface test and is the process for specifically realizing the interface test. The created test case class needs to be inherited to a TestCase class in the unittest module, each method in the TestCase class is a test case, and it needs to be noted that each test case method must start with a test. The data driving can be achieved by passing through a decorator @ ddt module before testing the case types and passing through the decorator @ data and unpacking into the case method before the case method. The main flow of the interface test is to import data for test, initiate an interface request to obtain a return value, verify a test result by assertion, write the result into a test data file and output a log.

The TestSuite layer is used for loading test cases, executing the test cases and generating test reports. And importing a unittest library, creating a test suite, and creating a TestLoader object to load a test case. The test cases are loaded in several ways, 1. the test cases are loaded; 2. loading all use cases under the module; 3. all test cases under the package are loaded. And then introducing a third-party module HTMLTestRunner, and generating an HTML-based test report in a specified path after the test case is executed.

A project is newly built in the Jenkins tool, the whole project of the interface test can be placed in a workplace path, and corresponding version management systems such as SVN and GIT can also be added in source code management. Most importantly, the "Execute Windows batch command" is selected in the add build step, and the "python XXX. py", XXX. py code test suite module name is entered in the command box. Therefore, as long as the test case is constructed by clicking, the test case can be automatically executed, a test result is generated, and a complete automatic test system is formed.

Referring to the attached figure 2, the invention further provides an interface automatic testing method based on a Unittest and Jenkins tool, which comprises the following steps:

step 1, writing test data into a file in a form of a use case, wherein the test data are generally excel files;

step 2, encapsulating a public method, namely reading data, reading a configuration file, initiating a request, inquiring a database, parameterizing and operating a log file;

step 3, compiling a configuration file, and writing the commonly used parameter configuration into the configuration file;

step 4, compiling a test case, and compiling the test case of the TestCase class under the unit test module;

step 5, compiling a test suite, which is equivalent to a master control file of the whole project, operating the selected test cases, and flexibly selecting the cases to be operated by aggregating a case loading method;

step 6, newly building a project in a Jenkins tool, deploying an interface automation project package, deploying the interface automation project package, supporting a plurality of plug-in functions in the Jenkins tool, and being capable of being flexibly applied, such as operating the project at regular time, sending mails after construction and the like;

and 7, executing a construction program by the Jenkins tool to generate a test result.

Referring to fig. 3, in this embodiment, the specific steps of step 1 are as follows:

step 1, opening a worksheet in a workbook;

step 2, reading the worksheet data by rows, and converting the read data objects into lists;

step 3, traversing the first element of the list in the step 2, and adding the traversed value into a new list;

step 4, traversing the remaining elements of the list in the step 2, adding the traversed values into a new list, and aggregating the list in the step 2 through an aggregation function to obtain an aggregation object;

step 5, transmitting the aggregation object into the written data class to generate an instance object for storing test data, wherein the aggregation object is composed of various primitive progenitors after being converted into a list, two elements in the primitive progenitors are divided into attributes and values which serve as the instance object, and the attribute values comprise the test data, expected results and the like;

and 6, storing and returning the instance object in the step 5 through the list, and acquiring the attribute value through the object when the test case is executed.

In this embodiment, the writing of the configuration file in step 3 specifically includes: the method and the function in the modules need to be used when the test case is executed, so that the test framework can be better perfected and simplified.

Referring to fig. 5, the parameterization process of the invention is as follows:

and 1, starting.

And 2, transmitting test data.

And 3, acquiring data to be replaced in the test data through query of the regular expression.

And 4, acquiring the fields to be replaced through the grouping in the regular expression.

And 5, reading the data in the configuration file through the field in the step 4.

And 6, replacing the test data to be replaced in the step 3 with the data read in the step 5.

And 7, returning the test data.

And 8, ending.

Referring to fig. 4, in this embodiment, the specific steps of the test in step 7 are as follows:

step 1, reading data in a test data file and configuring;

step 2, generating final test data through a parameterized function;

step 3, creating a request object, initiating an http request to a server through the request object, and receiving a request result;

step 4, requesting an actual result and an expected result through the assertion check interface;

step 5, checking the actual result and the expected result of the database through assertion;

and 6, generating a test result according to the result verification of the step 4 and the step 5, writing the test result back to the test data file, and outputting a corresponding test log.

Referring to fig. 6, the database query flow chart of the present invention is briefly as follows:

and 1, starting.

And 2, inputting a server address.

And step 3, inputting the port number.

And 4, inputting a user name.

And 5, inputting a password.

And 6, inputting a database name.

And 7, connecting the database.

And 8, creating a cursor object.

And 9, querying the database through the cursor object.

And step 10, ending.

Referring to fig. 7, the up/down interface of the present invention refers to a flow chart. The brief flow is as follows:

and 1, starting.

And 2, creating a storage data class.

And 3, storing a certain value of the previous interface as a class attribute value.

And 4, acquiring a value of the next interface through the class attribute.

Step 5, the method of fig. 5 replaces the test data with the value of step 4.

And 6, ending.

Referring to FIG. 8, a flow chart for reading a configuration file according to the present invention is shown. The brief flow is as follows:

and 1, starting.

And 2, importing a configuration file module.

And 3, creating a configuration file object.

And step 4, reading the environment configuration file.

Step 5, judging whether the read environment is a test environment, if so, turning to step 6; if not, go to step 7.

And 6, reading the test environment configuration file.

And 7, reading the user environment configuration file.

And 8, reading the corresponding field.

And 9, acquiring configuration file data.

And step 10, ending.

Referring to fig. 9, an interface request initiation flow diagram of the present invention is shown. The brief flow is as follows:

and 1, starting.

And 2, selecting a request mode.

And 3, transmitting the address of the request.

And 4, transmitting parameters of the request.

And 5, initiating a request.

And 6, receiving the return value of the request.

And 7, ending.

Referring to fig. 10, a flow chart of the operational test suite of the present invention. The brief flow is as follows:

and 1, starting.

Step 2, creating a test suite

And 3, loading the test case.

And 4, running the test suite.

And (6) ending.

Referring to FIG. 11, a Jenkins tool deployment project flow diagram of the present invention is shown. The brief flow is as follows:

and 1, starting.

And 2, opening a Jenkins tool.

And step 3, newly building a project.

And 4, configuring a source code address.

And 5, setting a timing task, and automatically executing the script at the set time.

And 6, selecting 'executing batch processing command' in the building step. The file name of the test suite is input in the input box.

And 7, storing.

And 8, ending.

Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that changes, modifications, substitutions and alterations can be made in these embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.

Claims (8)

1. The utility model provides an automatic test system of interface based on unitest and Jenkins instrument, its characterized in that, includes unit test frame, openpyxl module and Jenkins instrument, unit test frame includes the TestCommon layer, and the TestCommon layer includes test case module, database module, parameterization module, request module and log module, the test case module links to each other with openpyxl module, and re module, ddt module and Jenkins instrument are connected gradually to the output of openpyxl module.

2. The Unittest and Jenkins tool-based interface automation test system as claimed in claim 1, wherein the database module is connected with a pymysql module for self-checking the database.

3. The interface automation test system based on the Unittest and Jenkins tools as claimed in claim 1, further comprising a TestData module, wherein the TestData layer is connected with the parameterization module.

4. An automatic interface testing method based on Unittest and Jenkins tools is characterized by comprising the following steps:

step 1, writing test data into a file in a form of a use case;

step 2, encapsulating a public method, namely reading data, reading a configuration file, initiating a request, inquiring a database, parameterizing and operating a log file;

step 3, compiling a configuration file, and writing the commonly used parameter configuration into the configuration file;

step 4, compiling a test case, and compiling the test case of the TestCase class under the unit test module;

step 5, compiling a test suite;

step 6, newly building a project in a Jenkins tool, and deploying an interface automation project package;

and 7, executing a construction program by the Jenkins tool to generate a test result.

5. The automatic interface testing method based on the Unittest and Jenkins tools according to claim 1, wherein the specific steps of the step 1 are as follows:

step 1, opening a worksheet in a workbook;

step 2, reading the worksheet data by rows, and converting the read data objects into lists;

step 3, traversing the first element of the list in the step 2, and adding the traversed value into a new list;

step 4, traversing the remaining elements of the list in the step 2, adding the traversed values into a new list, and aggregating the list in the step 2 through an aggregation function to obtain an aggregation object;

step 5, transmitting the aggregation object into the written data class to generate an instance object for storing test data, wherein the aggregation object is composed of various primitive progenitors after being converted into a list, and two elements in the primitive progenitors are used as attributes and values of the instance object;

and 6, storing and returning the instance object in the step 5 through the list, and acquiring the attribute value through the object when the test case is executed.

6. The automatic interface testing method based on the Unittest and Jenkins tools according to claim 1, wherein the compiling configuration file in the step 3 specifically comprises: the device comprises a unit test module, an ddt module, a test data reading module and a parameterization module.

7. The automatic interface testing method based on the Unittest and Jenkins tools according to claim 6, wherein the parameterization step in the step 3 is as follows:

step 1, test data are transmitted;

step 2, obtaining data to be replaced in the test data through query of a regular expression;

step 3, acquiring fields to be replaced through grouping in the regular expression;

step 4, reading data in the configuration file through the field in the step 3;

step 5, replacing the test data to be replaced in the step 2 with the data read in the step 4;

and 6, returning the test data.

8. The automatic interface testing method based on the Unittest and Jenkins tools according to claim 1, wherein the testing in the step 7 comprises the following specific steps:

step 1, reading data in a test data file and configuring;

step 2, generating final test data through a parameterized function;

step 3, creating a request object, initiating an http request to a server through the request object, and receiving a request result;

step 4, requesting an actual result and an expected result through the assertion check interface;

step 5, checking the actual result and the expected result of the database through assertion;

and 6, generating a test result according to the result verification of the step 4 and the step 5, writing the test result back to the test data file, and outputting a corresponding test log.

Images