Outline
I did test these years, interviewed a lot of children's shoes. Most people I asked what is the interface to the test, will be talking about: I jmeter / postman send out a request for you, look at the response result, even if 200 passed. If you are not 200 down, there are problems thrown development. Finally the report, which is the interface to test it!
Then I would ask what type of interface? Interface design scene how? Interface design how the use case? Interface response code What? Front-end and back-end how to interact with the interface? The third question is often asked when the students began scratching their heads, brains downtime.
Therefore: add some interface test theoretical knowledge is necessary Oh!
What is the interface?
Generally speaking, there are two interfaces, one is the internal procedure interfaces, one is the system external interfaces. Broadly speaking, the protocol between the client and the background service; communication between the plug-in interface; the interface between the modules; and then a small class provides methods; can be understood as an interface.
System external interface:
If access to resources on our website or from the server or information, the website will certainly not share the database to you, It will provide you with a written way to get the data, we can get the data by reference to the interface it provides.
Internal procedure interfaces:
It is between the method and the method, the interaction between the module and the module, but also internal procedures thrown interface. For example, a web project, have a login, add, modify, delete, etc., then these modules will be interactive, it will throw an interface system for internal calls.
The composition of the interface
A complete interface should contain the following:
1. Interfaces
2. Call the url
3. The request method (get \ post)
4. The request parameters, parameter types, Request Parameter
5. Return Parameter Description
The interface should be at least the address request, the request method, the request parameters (the parameters and the parameters), the first part of the interface there is a request header. header is the server to the HTTP protocol to pass data HTML browser before sending the string, the general store cookie, token and other information.
header and the parameters are different. header general store are some of the check information such as cookie, which is to verify that the request has permission request to the server. If it has permission to request that the server, then the request address is sent to the server along with the parameters together, the server then returns a reference to the address and the parameters. In other words, the server is to accept the header information to determine whether the request has permission request, after the judge has authority, will accept the request and the address parameters.
Common Interface Type
1, webService Interface
It uses soap and http protocol transmission, the request packet and return messages are xml format, we can be invoked through the tool at the time of testing. You can use the tools SoapUI, jmeter.
2, http-api interfaces
It uses the http protocol, to distinguish a path through a method call, the request packets are in the form of key-value, the packets are generally returns json string, or the like with a get and post, which is the request for the two most common ways. You can use the tools postman, jmeter and so on.
3, dubbo Interface
Rpc transfer protocol it uses, is generally used in micro-service
Front-end and back-end
front end
Let's use the web page, open the Web site, are the front-end. Including the structure of Web pages, Web performance and visual appearance of interactive Web-level implementation;
rear end
When we operate on the page, these business logic, function, such as add, modify, delete these functions are implemented by the backend. More of a back-end database to handle interaction with the corresponding business logic. To consider is how to implement the functions, access, stability and performance data platform.
Front and rear ends interact through the interface. Front page to realize the function, access to data by calling the backend interface, the data is displayed in front of the user.
Interface Test Definitions
1, the interface test is a test method for testing an interface between the system components
2, which is used to detect the interaction between the external system and between the system and the various subsystems within the system
3, the focus is switched to check the data, and the logical mutual dependencies between systems
4, through respective interface test is the parameter information of the participation in the case where different test to determine whether or interface conforming to meet the appropriate functionality, safety requirements.
Interface testing significance
1, system complexity continues to rise , a sharp increase in the cost of traditional test methods and test efficiency dropped significantly, so do interface testing.
2, the test is relatively easy to implement the interface. And the interface automation UI Automation also relatively stable. Reduce manual regression testing time and labor costs, shorten the test cycle, support rapid iteration.
3, the front and rear ends of many systems are separate , so the security level, depends only on the front end has to be limiting system can not meet the security requirements (distal easily bypassed), the rear end also needs to be verified, in which it is necessary to verify the level of the interface from the case. Are the front and rear end of the transmission, log and print information encrypted transmission also need to verify, particularly in relation to the user's private information, such as money, identity information.
Value Interface testing
1, identify problems earlier
Testing should be involved in the earlier development of the project, because the sooner the discovery bug, the lower the cost of repair. However, functional tests have to wait until test system provides an interface to test the system. The interface test can test the system before the function interface developed. The system interface is the basis of the upper functions, interfaces can test earlier and more cost-effective to find and solve problems. However, in the actual development process, and developers do not have enough time to write unit tests, and they are often lost confidence in the code I have written it, do not want to spend time on writing unit tests. This time the role of interface testing will become more important.
2, shorten product development cycles
For the product development cycle, if all the test work has focused on functional testing stage. The question test and repair cycle will be longer. Because the test can intervene earlier in the product development, therefore, can effectively control the number of functions bug stage; thus effectively shorten the product development cycle.
3, found more underlying problems
Some of the underlying logic of the system is not easy UI function tests triggered, then the logic can be problematic. Interface test makes it easier and more comprehensive to test the underlying logic of these.
4, check the server's exception handling capabilities
Usually called weak verification front-end verification, because it can be easily circumvented, if only this time standing on the level of functional testing, it is difficult to find some security problems. Not to function as an inlet interface test will be very easy to verify that these anomalies.
Common request
GET and POST requests
If you get a request, then enter directly in the browser, you can, as long as the request to be able to directly inside the browser, all get request, if the request is sent to the post, then we have to use tools.
The difference between GET and POST requests
1, GET using a URL or Cookie mass participation. The POST data in the BODY.
2, there will be restrictions on the length of the URL of the GET, POST data can be very large.
3, POST than GET security, because the data is not visible on the address bar.
4, generally get request for acquiring the data, a request for transmitting data POST
common problem:
(1) passing parameters Misuse program exceptions;
(2) the type of overflow, resulting in inconsistent data reading and writing;
(3) because the subject did not verify permissions, other users can access sensitive information;
(4) state Misuse logic be confusion;
(5) check logic imperfect, can be exploited obtain improper interests
Interface design test scenarios
1. Interface Specification document checks
2. Check connector Front
3. The interface logic check function implemented
4. Check Request parameter legality
The request check parameter attributes
6. Check the exception process request parameters
7. Check response structural member
8 to check the correctness of the response data
9. abnormalities response
10. The image inspection response
11. Check the compatibility of older versions of
12. The role of authority checking business logic
13. Operational parameters dependency checking logic
Interface testing process
-
In fact, the process interface testing and functional testing process is similar, the main target of which is dependent on the requirements specification, therefore, is involved in the initial needs assessment process.
-
After identifying needs, will be developed according to the needs of interface design, it will give the interface definition. In the development and design process, the test can give some suggestions for the design, improve testability, and for the needs of design, specify testing program.
-
After development is complete interface definition, need to design test cases based on requirements documents and maps and interface definitions. The main test case design considerations from business scene, function, and abnormal test aspects.
-
After completion of the test case design, test case for review. Testers can intervene early stages of the development of the interface FBI.
-
At the end of the project, the need for a summary of each project.
Interface response status codes
Details http request status code
Use ASP.NET/PHP/JSP or javascript will be used in different states of http, some common status code: 200 - the server successfully returned the page 404 - the requested page does not exist 503 - Service unavailable.
1xx (provisional response) shows a state in a provisional response and require the requestor to continue with the operations of the code
-
100 (continued) requestor should continue with the request. The server returns this code indicates a first part of the request has been received and is waiting for the rest.
-
101 (Switching protocols) The requestor has switched protocol requires the server, the server is acknowledging that handover.
2xx (Successful) expressed successfully processed the request status code
-
200 (success) server has successfully processed the request. Typically, this means that the server provided the requested page.
-
201 (Created) request was successful and the server created a new resource.
-
202 (accepted) server has accepted the request, but not yet processed.
-
203 (Non-authoritative information) The server successfully processed the request, but is returning information that may be from another source.
-
204 (no content) server successfully processed the request, but is not returning any content.
-
205 (Reset content) server successfully processed the request, but not returning any content.
-
206 (part of) the server successfully processed a partial GET request.
3xx (Redirection) indicates to fulfill the request, further action is required. Typically, these status codes for redirection
-
300 (choice) for the request, the server may perform various operations. The server may operate a requestor (user agent) selected in accordance with, or provide a list of actions for the requester to select.
-
301 (Moved Permanently) permanently requested page has been moved to a new location. When the server returns this response (response to a GET or HEAD request), it automatically forwards the requestor to the new location.
-
302 (Temporary Mobile) respond to requests from the web server is currently a different location, but the requestor should continue to use the original location for future requests.
-
303 (See other location) requestor to retrieve the response should separate GET request to a different location, the server returns this code.
-
304 (Not Modified) since the last request, the requested page has not been modified. When the server returns this response, it does not return to the page content.
-
305 (use proxy) The requestor can only access the requested page using a proxy. If the server returns this response, it said requester use the agent.
-
307 (temporary redirect) server response to a request from a web page different from the current position, but the requestor should continue to use the original location for future requests.
4xx (Request error) These status codes indicate that the request may be wrong, the processing server hampered
-
400 (Bad Request) server did not understand the syntax of the request.
-
401 (Unauthorized) The request requires authentication. For pages that require login, the server might return this response.
-
403 (Forbidden) server rejects the request.
-
404 (not found) server can not find the request.
-
405 (Method disabled) method specified in the request is disabled.
-
406 (not accepted) can not use the content characteristics requested in response to the requested page.
-
407 (Proxy Authentication Required) This status code 401 (not authorized), but specifies that the requestor should be authorized to use the proxy.
-
When a timeout occurs waiting for the request 408 (Request Timeout) server.
-
Conflict 409 (conflict) occurs when the server to complete the request. The server must include information about the conflict in the response.
-
410 (Deleted) If the requested resource has been permanently removed, the server returns this response.
-
411 (length) of the server does not accept the request without a valid Content-Length header field.
-
412 (Precondition Failed) where the server is not a prerequisite for the requestor in the request is satisfied.
-
413 (Request entity too large) server can not process the request because it is too large for the server to handle.
-
414 (Request URI is too long) URI (typically a URL) request is too long, the server can not handle.
-
415 (Unsupported Media Type) request in a format not supported requested page.
-
416 (Requested range not satisfiable) if the page can not provide the requested range, the server returns this status code.
-
417 (expected value) server can not meet "desired" request header field requirements.
5xx (Server Error) These status codes indicate internal server error occurred while trying to process the request. These errors could be wrong server itself
-
500 (Internal Server Error) The server encountered an error and can not fulfill the request.
-
501 (Not implemented) server does not have to complete the request. For example, the server might not return this code request identification method.
-
502 (Bad gateway) as a gateway or proxy server received an invalid response from the upstream server.
-
503 (Service Unavailable) server is currently unavailable (because it is overloaded or down for maintenance). Typically, this is a temporary state.
-
504 (Gateway Timeout) as a gateway or a proxy server, but the request is not received from the upstream server.
-
505 (HTTP Version not supported) server does not support HTTP protocol version used in the request.
-
511 Network Authentication Required (requires network authentication)
Interface case design
There usually is an interface input output when the input is the most common to the Senate, sometimes no output. Call the relevant interface, the interface performs the associated processing logic.
Example design of the interface with the testing, and input from the main interface processing two considerations:
1) for the input, it can be designed in accordance with the parameter type;
2) for interface processing, can be designed in accordance with the embodiment of the logic;
3) For output, the results of analysis and design
Design for input
For the interface, the input is to the Senate. Common parameter types are:
(1) numeric (int, long, float, double, etc.)
(2) Type String
(3) an array or linked list
(4) Structure
Possible problems and risks
-
Incoming non-specific type of program quit unexpectedly
-
Long characters are not processed, resulting in storage, display abnormal
-
Visible to other users sensitive character set
-
Array or list type
-
Parameter type is an array or linked list, use cases may be considered
For example, a batch job submission interfaces, design parameters to consider use cases:
-
Normal values: 1-5 outer permission range: 6 authority;
-
Boundary value: 1-35 boundary value, maximum and minimum allowed request;
-
Special values: 0;
-
ID lawful and unlawful;
-
Duplicate ID or the like.
-
Possible problems and risks:
-
0 item when the program exits abnormally;
-
Duplicate not lead to unexpected results like heavy item during processing.
For logic design
Interface logic requires some processing, then the logical design can be analyzed from the perspective of the following use cases:
(1) numerical limitation, restriction points, the level of restrictions like. For example: Q currency exchange activities require integration> 50 before participation
(2) state restrictions: login status, etc. For example: synchronize user information required to log in account.
(3) restricted access: the administrator and so on.
Constraints often encountered in testing the function test, the interface is more important test. Its significance lies in: when the user performs an operation, the front end of the operation may have been limiting constraint, so the user can not directly trigger request the interface. But in fact, if there are other means: for example, through technical means to directly call interface, the interface whether or not the limit for these conditions is particularly important.
Such as common examples: To 5Q currency exchange needs 200 points, but my lack of integration, so the exchange can not click on the button is grayed state. But I can bypass the front-end interface to a direct call to exchange? Of course, expectations are not convertible. So this integral value limit will need to be tested for the interface, and is very important.
For output design
In fact, output is designed for analysis of results returned interface:
Output
Interface processing may be only one correct result, but the error abnormal return a result there are many cases a lot of value. If you know there are many returns a result, you can use the results for different design cases. We may not be able to fully cover all the error codes, but based on the return code returned interfaces can be designed more defined use cases.
Frequently asked questions and risks
(1) Error handling is less than the distal end, the distal end resulting in abnormal;
(2) improper error handling, causing the user to see the obscure error code;
(3) improper error, causing the user does not know what went wrong, how to solve.
Interface design for overtime
Under normal circumstances, the interface is returned, so if the interface does not return it? That process is also time-out after the test part of the interface needs to be considered. If the timeout is not handled properly, may cause the following problems:
(1) time-out processing is not performed, the entire process results in obstruction
(2) received after the timeout return to the interface, resulting in confusion occurs logic
Interface design for waste
Obsolete agreement refers to the definition before, but because of the demand for change or for other reasons, temporarily do. Although these interfaces are no longer used, but it is possible to code and did not delete. If you call these interfaces using technology, possible risks. Therefore, in consideration of the new version compatible with older versions of the same time, you should also do the checking of waste-related interfaces, to avoid the risk.
Common problems and risks: constraints, whether the shortage, causing the user can obtain benefits through special means.
Interface design for rationality
Whether a reasonable definition of the interface can be analyzed from the following aspects:
(1) Interface fields are redundant;
(2) the interface are redundant;
(3) whether the interface is returned to the caller expect to receive information;
(4) whether the definition of the interface to meet the needs of all calls;
(5) interface definition calls are convenient.