There are many open source tools on the market that can support HTTP interface testing, and the experience is pretty good, but most of the tools are based on desktop clients, and the sharing of test resources is inconvenient and not timely enough. This is for the collaboration of testers. But it is fatal.
Moreover, for test automation, timing execution and scheduling and scientific test case management are also very important. These are currently not available in many open source tools on the market.
We can evolve interface-based data logic verification and data correctness verification, as well as part of business logic verification, into interface test cases, through a unified entrance to control the automatic operation of the interface, and show it in the form of logs or reports .
In this way, the workload of functional testing in this part of the task can be reduced to the greatest extent and the work efficiency can be improved.
Before performing any operation, you need an account for the LuckyFrame test platform. After logging in with the account, enter the "protocol template" page under the UTP module, where we can maintain the template of the HTTP interface protocol. The main steps are as follows:
Step 1: Click <Add Template>, enter the basic information related to the interface, and then save. It should be mentioned that the interface protocol types currently supported by the platform include HTTP and SOCKET, and the encoding format includes UTF-8 and GBK.
In addition: If you need to set a header field for the HTTP request, then in the request header field column, fill in the format of [header field parameter=header field value]. If there are multiple header field parameters, please use [;] to separate them, if Your header field value needs to be encoded in Base64 format, so you can fill in the format of [header field parameter=Base64 (header field value)].
Step 2: In the protocol template list, check the newly added record and click the <template parameter> button to maintain the interface request parameters. The parameter type supports String, JSON object, JSONARR object, File object, number type, Boolean type, just select the parameter type you need.
At this point, you have completed the addition of an http interface protocol template. Next, you can expand the interface test case for this interface.
We maintain the test cases on the "Use Case Management" page under the UTP module.
First, click the <Add Use Case> button, fill in the basic information and save, and a new use case will be added.
Next, we need to maintain the detailed steps of the use case. Check the newly added use case in the use case list, and click the <Edit Step> button to enter the use case step edit page. Remember to select HTTP as the "Type" first, and then enter other information:
• Enter the request address of the http interface in "Package | Location Path"
• "Method|Operation" is a drop-down option, you can choose the interface request method, here we choose HttpClientPost
Note: If the entire request format is JSON, then when you select the request type in your use case, you must select the HttpClientPostJSON type, so that your HTTP template will be automatically formatted into JSON
• Leave "Parameter" blank, and all default parameter values in the agreement template will be used. If you need to modify the default parameter value, fill in this item in the format of "paramname1#value1|paramname2#value2|..."
Note:
1.# is used to separate the parameter name and parameter value. If you want to customize multiple parameters, use | to separate the parameters.
2. If you want to modify the default value of "request header field", the parameter name needs to be filled in in the format of "headmsg(paramname)", for example: headmsg(Access-Token)# parameter value
• "Step Action" is a drop-down option. The optional option is that the automatic association system has an HTTP protocol template, just select the protocol template we need (Note: The drop-down option for V3.0 and above has been changed to the extended field, step action No drop-down options)
• "Expected result" enter the result of the synchronization receipt we expect
The following simple example explains:
The first step: the user logs in, the server returns a JSON string, in which there are parameters with the token of the user login
Step 2: Through a test-driven stub written by yourself, process the JSON string returned by the server, intercept the token value, and assign the variable token (the test result assignment method: $=variable name).
Step 3: Send a new request, assign the token value to the header field of the HTTP protocol template, and complete user authentication.
When you need to add or subtract steps, just click the "+" "-" small icon after the previous step, and "↑" "↓" can move the selected step position.
To our surprise, we can also directly perform the use case <debugging> here, and the validity of the use case can be verified by debugging.
At this point, you already know how to create interface test cases. The next question is how to start interface testing based on your test cases.
