Postman combat summary
Introduction
The content of this actual combat mainly includes the following points:
l Background introduction
l Postman use, focusing on automation implementation, basic use will not be introduced
l Visual Newman Introduction
l Framework features
l Pitfalls in actual combat
background
With the rapid development of domestic software technology, more and more manual tests are gradually replaced by automation, such as UI test, interface test, unit test, etc. Very mature, greatly improving product delivery efficiency and delivery quality.
Under the general trend of the IT industry, the product group is facing the following four challenges:
1. The old interface at the bottom of dubbo+cloudt2.X needs to be upgraded urgently;
2. The product basically implements two-week iterations, and the regression test cannot cover all modules, and occasionally the related impact is not considered carefully, resulting in leaked bugs;
3. Insufficient test resources, after leaking bugs, affect product quality;
4. I have tried to use python, doclever, eolinker, postman, etc. to do interface tests, but the results are not very satisfactory.
In this context, through research, combined with the experience of using postman in the product group, and the lack of automation ability of testers, postman is well packaged, low learning cost, and can quickly produce automated scripts, and establishes the use of Postman+newman as interface automation testing plan.
If you don’t want to experience the feeling of not being able to find information, no one answering questions, and giving up after a few days of self-study, you can follow me to discuss together.
Recommend a software testing technology exchange group for everyone: 1079636098 Group friends receive free benefits
Postman
Json use case
The automated test case in Json**** format actually saves an array, and the elements of the array are all objects, and an object corresponds to a test case, as shown in the figure below;
The use case includes the use case name ( caseName ), use case description ( description ), expected call result ( expectation ), automated business type ( requestType ), input parameter ( queryData ), expected result ( checkData )****, result verification field ( checkKey ); you can flexibly set your own use case parameters according to the needs of the automation framework .
There are several ways to access use case data in Postman****. In order to facilitate later viewing, use cases in the following format are specially prepared:
{
"url":"requestUrl",
"params":"params"
"body":0,
"script":{
"consoleInfo":"helloWorld"
}
}1. The interface address can only access the outermost properties of the use case object, using **{ {variableName}}**
2. Params **, the usage and rules are the same as the address**
3. Body **, the method of use and rules are the same as the address**
4. Pre-request-Script& Tests ** (hereinafter referred to as pre-script and post-script), data points to the use case object, and if you want to get the attribute of the object, you can get it by ****data.** attribute name, As shown below:
environment variable
Postman**** supports environment variables, in which some variables of different environments can be set, such as domain name, login account password, etc.
Environment variables can also be used in scripts, as follows:
1. The interface address, params and body are used in the same way as the use case attribute, { {variableName}} . If there is a variable conflict, the attribute in the use case will be used first. For example, url= www.baidu.com is set in the environment variable . There is also a url= www.google.com attribute in the outermost attribute of the use case object , so **** www.google.com is preferred
2. The use of environment variables in the pre- and post-scripts will be different, and the method encapsulated by postman can be used **,** The specific usage is as follows:
global variable
Postman supports setting global variables. As the name suggests, global variables can be used in any environment, which limits it to only setting some public variables. The interface address, the use of global variables in params and body are the same as environment variables, so I won’t go into details here; the usage methods in pre / post scripts are generally the same as environment variables, except that the method names encapsulated by postman**** are different :
** Get global variables: ** pm.globals.get("variable_key");
**Set global variables:** pm.globals.set("variable_key", "variable_value");
**Empty environment variables:** pm.globals.unset("variable_key");
In this automation practice, the blogger extracted public methods as global variables, such as obtaining timestamps, comparing data, processing cookies , querying data dictionaries, etc. The following figure shows the method of obtaining timestamps, getTime is the method name, and the right side is the method body:
The use of public methods in global variables is different from variables and requires special handling; if you want to use the method of obtaining timestamps in scripts, you need to use the eval() method reference, just like import in java ;
Notice:
1. When using eval to refer to a method, you do not need to add **() after the method name , but you need to add ()**** when calling the method;**
2. The method can also be set in the environment variable, but it is generally not used in this way, and the usage method is similar to the global variable, eval(environment.functionName) ;
3. Other methods can be called in the method, the usage is the same as 1 and 2 .
screenplay
The pre-script is executed before the interface is called, and generally pre-processes the interface parameters, such as assigning values to the input parameters; the post-script is executed after the interface is called, and generally verifies the interface response result. Environment variables, global variables, and json external data access have been mentioned above, so I won’t go into details here.
These two parts are the parts that postman supports script writing. Bloggers are used to writing in JavaScript language; and postman lists some commonly used methods, so I won’t introduce them one by one here. I mainly introduce a few postman that are not listed, but in the following Useful points during scripting:
1. postman.setNextRequest()****: Jump
There are multiple interfaces in collection****, and a use case will involve the calls of multiple interfaces. If no jump statement is added, the next interface will be executed by default when the automation is running, and the execution flow of the use case is difficult to control. If you add a jump After the statement, the jump will be flexible, and it will be more convenient to end the execution process;
End the execution of the current use case: postman.setNextRequest(null) ;
Jump to execute another interface: postman.setNextRequest(" interface name ") ;
2. return **: return **
The Tests script can be regarded as the method body of a method. The return in the above figure means that the method returns, and no subsequent scripts will be executed.
3. responseCode **: interface call status**
Generally, you only need to use the code (interface response code), using method: responseCode.code , the entire responseCode content is as follows:
{
"name": "OK",
"detail": "Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.",
"code": 200,
"standardName": "OK"
}
4. responseBody **: response result **
It should be noted here that the value of responseBody is a response result of string type. If the interface returns an object, the responseBody needs to be converted (JSON.parse(responseBody))
5. request **: the current call interface information, the content is as follows: **
6. tests["response assertion output content"] = true: response assertion, any script must have a response assertion
A judgment statement can be used after the equal sign. If it is true, the assertion passes; if it is false, the assertion fails. For example, if it is judged that tests["the interface call is successful, and the status code is 200"] = responseCode.code == 200, it is judged whether the interface call is successful.
automated test
Using postman , a single collection can be used locally for automated testing, and the collection runner window can execute automated scripts.
1. environment**** can choose to execute environment variables;
2. Iterations sets the number of use cases to be executed. If the number of use cases set is less than the number of use cases in the json external file, only the set number of use cases will be executed; if the number of set use cases is more than the number of use cases in the json external file, then all the use cases will be executed. , the last use case will be executed repeatedly until the set Iterations**** times are executed.
3. Delay**** sets the execution interval;
4. Data can choose an external json use case. Note here that if there is a problem with the json**** data format in the file, an error will be reported.
The result of the operation is as follows:
Newman
Newman is a nodejs library launched by Postman. Directly speaking, it is a plug-in that Postman's json file can execute on the command line. Newman can easily run and test the collection, and use it to construct interface automation testing and continuous integration.
The installation of Newman will not be repeated here. There are many installation tutorials on the Internet.
Because newman needs to use the bat command to run, the amount of automated scripts is large, and the command form is not conducive to management; in order to solve this problem, the newman visual page is specially developed, which can select environment variables and global variables, select scripts in batches, automatically generate bat commands and execute them , improve efficiency and reduce difficulty of use. The visualization page is as shown below
Newman executes scripts, and each set of scripts will generate reports in three formats (xml, json, and html), which are poorly readable. In order to solve this problem, the following research was carried out:
1. During the discovery process, it was found that the json file was large and the reading efficiency was low;
2. By querying the data, determine the js script that generates the report from the newman installation file (path: C:\Users\account\AppData\Roaming\npm\node_modules\newman\lib\reporters\json), reduce the size of the json report, Keep only what's useful
3. Generate automated reports in excel format
4. Email sending, the processed report is automatically sent to the stakeholders in the form of email through the nodejs script.
frame features
Stored by business module
This actual combat is mainly aimed at web api, and the automatic smoke test of the interface splits the collection from the business dimension, not only testing the abnormal situation of a single interface, but also supporting the cooperation test between related interfaces;
data driven model
1. All automation use cases are extracted to external json files;
2. In the same collection, the same interface does not exist;
3. In any interface, there is only one variable stored in the use case for input or output parameters. After the subsequent interface maintenance, only the use case needs to be updated, and the script does not need to be modified; if the input or output parameters need to be processed, then in the pre-script For processing; see the figure below for an example, only one variable value is passed in the body;
4. The expected results are stored in the use case, and the same set of scripts is applicable to different business scenarios.
public method refinement
In order to reduce redundant scripts in automation scripts and improve script writing efficiency, public methods are specially extracted into global variables, which not only reduces code complexity, improves script writing efficiency, but also reduces the difficulty of getting started with this set of automation frameworks; public methods The usage method has been described in the postman introduction, so I won't go into details here.
Multi-environment execution
On the basis of multiple environments, the primary key of the basic data is different; facing more and more automated scripts, the workload of maintenance continues to increase.
In order to reduce this part of the work, through research, establish the data dictionary mode:
1. Maintain the data dictionary in the environment into environment variables
2. For the part that needs to use the primary key of the basic data in the automation use case, add variable identification
3. Write a public method to identify the variable and match it in the data dictionary and replace it with the matching result.
Advantages: There is only one set of scripts and use cases, applicable to any environment, further reducing maintenance costs
Disadvantage: The readability of the use case is reduced, and the data cannot be seen intuitively
Pit in actual combat
1. If the variable used in the body needs to be an object or an array, the object or array needs to be converted into a string through JSON.stringify(), and then assigned to the variable to successfully call the interface;
Json external use case format, the body parameter should be passed to the bodyInfo property:
Pre-script processing:
Called in Body:
2. When defining a variable in a pre- or post-script, if no identifier is written, the defined variable can be used when other interfaces are executed, but its life cycle is limited to the completion of this use case.
Variables defined in query 1:
Output the content of test in query 2:
Output results after the Collection runner runs
3. Jumping between interfaces is not supported in the pre-script: postman.setNextRequest();
4. Collection can add pre-scripts, post-scripts and variable definitions; pre-scripts and post-scripts are executed once without calling an interface;
Finally, I would like to thank everyone who has read my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, you can take it away if you need it:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey, and I hope it can help you! Partners can click the small card below to receive