JMeter notes (Ⅱ) use JMeter for lightweight interface automation testing

Interface testing, although as a part of the version, but also a complete set of systems, functional testing of the interface, performance testing, security testing; At the same time, due to the characteristics of the interface, automation of the interface low-cost high-yield, using some open source tools or some lightweight method, Good test results can be achieved when the cost of test case development is low.

The Open Source Test tool JMeter can assume the task of interface request, result parsing and assertion, and can be used as a means of implementing lightweight interface automation, and can be accepted by teams with low development ability or small size. JMeter can implement basic functions in the protocol layer, including interface access, parameterized constructs, return value assertions, and database access, which is basically sufficient to meet the functionality of a lightweight interface automation framework.

We define one of the following interfaces:

Enter the parameter:

    Searchkeys: My dear you,//user input query data, cannot be empty    pagesize:10,//page size, default entry is 10, front-end incoming    pageindex:1,//pagination PageIndex, page, Front-end incoming    orderby:0,//sorting criteria: 0-Sales, 1-price, passed in by the front end through the radio control to achieve    method:asc//sorting: asc-Ascending, desc-descending, front-end through the radio control implementation

return value:

{

"Data":

[

{

"Commodityid": "03445f1e-ba55-421d-80fa-1777741bb57e",

"CategoryID": 2,

"Commodityname": "Solo sobbing of a double bed",

"Thumb": "Http://img4.imgtn.bdimg.com/it/u=1924829949,2185178641&fm=27&gp=0.jpg",

"Saleprice": 16.0,

"SaleAmount": 13

}

],

"Records": 1,

"Status": true,

"Message": ""

}

Code processing logic: According to paging page and size, from a table in the commodity table directly query to the corresponding data, query results are instantiated as JSON processing returned, corresponding fields are present in the commodity table, corresponding data as follows:

The idea for testing is that, by implementing the business logic, the field of thumb is removed as an assertion field, and the SQL is constructed to query, and if the query to the corresponding data, the interface is returned through. Specifically constructed SQL is as follows:

SELECT    * fromCommodityWHERECommodityid= '03445f1e-ba55-421d-80fa-1777741bb57d' andCategoryID= 2 andCommodityname= 'my dear, you are a big deal .' andSaleprice= 13.0 andSaleAmount=  the

Then we need to do the work, in order to access the interface-get the return value-parse back-construct sql-query-judge the result. The whole process can be realized through jmeter, and it is easier to get started. The following procedures are described:

One. HTTP request:

Add a new thread group under the test Plan and a new HTTP request under the thread group:

After adding an HTTP request, you can set the request as shown, and be aware that if you want to enter a protocol, do not add HTTP or HTTPS to the server name or IP, or you will be directly accessing the http://http://:

In general, the interface needs to authenticate the identity information in the header when it accesses, JMeter provides the function of header information management: Add-config component-http request Header Manager:

Use the result tree to view the interface return value: Add-listener-view result tree, you can clearly see the interface return message:,

Enter the parameter:

Ps:jmeter recorded in the participation of automatic URL encoding processing, it is necessary to do their own URL decoding can be

Return parameters:

In this way, we have completed a basic HTTP request access.

Two. Realization of parameterization

It must be noted that, before we constructed the input via HTTP request, the input to Searchkey was not populated with the previously constructed parameter, but ${key} was used, and in JMeter, the parameter was passed through the ${parameter name}.

In general, we do not necessarily guarantee the stability of the data in the test process or need to construct a number of different parameters to deal with, many times need to consider doing parametric processing, to a certain extent to achieve dynamic construction. The JMeter provides the ability to parameterize by reading local files:

Read parameters in configuration file: Add configuration component under HTTP request-csv DATA SET CONFIG:

After adding the CSV Data configurator, set the parameters as follows:

The call can be called directly using the ${parameter name}.

Three. Using JSON extractor to process json in return values

Typically, most of the interface return values are now serialized to be returned in JSON format. Although it is possible to get the return value using a regular, JMeter provides a more convenient plugin: JSON extractor handles JSON.

Download the plugin jmeter-plugins.org/wiki/jsonpathextractor/, download the extract, the Lib two jar copy to the JMeter Lib directory, lib/ext inside the two jar copy to JMeter lib/ Ext directory, restart JMeter.

Let's take the Commodityid in the following JSON as an example to get the corresponding value:

{    "Data":    [        {            "Commodityid":"03445f1e-ba55-421d-80fa-1777741bb57e",            "CategoryID":2,            "Commodityname":"Double bed solo sobbing",            "Thumb":"http://img4.imgtn.bdimg.com/it/u=1924829949,2185178641&fm=27&gp=0.jpg",            "Saleprice":16.0,            "SaleAmount": -        }    ],    "Records":1,    "Status":true,    "message":""}

Notice that Commodityid is in the JSON array, so the JSON path is data[0]["commodityid", and you need to add the index values in the JSON array. We fill in the JSON Path expreeions $.data[0]. [Commodityid], so we take out the value of Commodityid, and after that we can invoke the value of the fetch by ${commodityid}.

With the same, we can take out all the assertion fields.

According to the previous analysis, we can construct a SQL Access database using the Assertion field, and if all the fields are returned correctly, then the query result should be not empty; In the following format, we can construct the assertion SQL we need:

SELECT     *from    commoditywhere    '${commodityid}'='  ${Commodityname}'== ${saleamount}

Next, we only need to execute the SQL using JMeter and validate the returned results to enable this lightweight interface automation.

Four. Use JDBC to access MySQL:

JMeter provides JDBC plug-ins for database access, but before that, we need to download the MySQL JDBC driver package. In general, the JDBC driver package version needs to match the database version, or it may cause an error due to a driver relationship.

1. Under test Plan Add, import the corresponding JDBC driver package:

2. Add-config component, JDBC Connection configuration

The specific settings are as follows, the Blue border section can be used to directly use the default settings, the red box needs us to fill in manually:

The database connection string at the bottom is filled in as follows:

Databaseurl: Database connection string, use MySQL students to fill in the following format:

Jdbc:mysql://Localhost:2000/autotest?useunicode=true&characterencoding=utf8jdbc:mysql: // Database server Address: Port number/database name, in the test process encountered because of the encoding problem, the query condition in the Chinese string does not take effect causes the assertion result error, so you need to add the encoding method, set the same as the database itself encoding, I use UTF-8 JDBC Driver Class: Fill com.mysql.jdbc.Driver directly username/password: Connect to Database account and password

3. Using JDBC Request for database operations: Add-SAMPLER-JDBC Request

The JDBC operation is simple, we only need to invoke the set JDBC Connection configuration through the parameter name, and then enter the SQL to execute:

Add a look at the results tree and we can see the results of the SQL execution:

Constructed sql:

Results of the query:

Five. Use assertion validation to return results:

JMeter provides a rich assertion feature that can be used to check that the response data is consistent with expectations and can be used as a result check for interface Automation tests. For a single request, if passed, the assertion result will only print the name of a row of requests, and if it fails, there will be a reason for the failure (different types of assertions, different results) in addition to the requested name, or help us to locate the contents of the wrong return value. Additionally, a sampler can add multiple assertions, add assertions based on your inspection needs, and when all assertions are passed under sampler, the request succeeds.

So for this use case, we can simplify the problem: Since the query results returned by the database query to the data even if the test passed, then the return value of the JDBC request is bound to have our parameters, then we can directly use the Basic Text tool to verify the assertion, The returned result contains one or several assertion fields, so you can assert that the test passed:

Add-assert-response assertions, which include key parameters in the response text:

Then if the returned result is correct, the assertion test passes with only one returned data in the result tree:

If a result error is returned, the assertion test fails, and the reason for a new row in the result tree is:

We construct a wrong scenario, return the SaleAmount (sales) in the Return field to Saleprice (price), then our query result is empty, the returned assertion result will be unsuccessful, because the return value does not include the incoming Commodityid:

The assertion failed because there was no match to the corresponding Commodityid data.

At this point, we use JMeter to complete a lightweight interface Automation test use case construction, the construction of good use cases can be used in subsequent versions of regression testing.