Here is the interface testing white black white papers records, get to the the
1. Interface? Roughly divided into two
(1) internal system interfaces words (I understand ha ha) to pay attention to the need to log in first
(2) External system interface to obtain information from the server through the interface to obtain
http api webservice interface and the interface to the difference (see http webservice and interfaces articles)
webservice interface to external, from the perspective of the test, take the soap protocol transmission via http request packet and return messages are xml format, we have the tools to make calls through the test, the test
Http protocol is to go through a path to distinguish between method calls, the request packets are key-value in the form of return message usually json string, there are other methods to get and post, which is the most commonly used two ways request
(3) a front end and a rear end
The front end of the main page and to realize a simple check, the rear end of the logic function to achieve
(4) Interface Test procedure
First, the needs assessment, familiar with the business and demand
Second, the development to provide interface documentation
Third, writing test cases Interface
Fourth, cases assessment
Fifth, Timothy test start test
Sixth, submit test reports
(5) interface testing dependent interface documentation
Interface document comprising at least: 1, 2 interface specification, call url 3, request method (get \ post) 4, request parameters, parameter types, the request parameter description 5, return parameter description (role similar requirements document)
(6) test http Interface
get request interface which can be directly spliced parameter
url? param = value & param2 = value This is the simplest one, in front of a question mark is a request url, followed by the parameter name and value of the request to connect the plurality of parameters &
There is also a json string into the reference is, at this time the need to use tools such as the postman Request Interface
(7) http status code
After each issue a http request, there will be a response, http itself will have a status code to indicate whether the request is successful, a common status codes are the following:
2 at the beginning of 1200 have expressed this request is successful, the most common is 200, on behalf of the request is ok, the server also returned.
2,300 3 represents the beginning of the redirect, the most common is 302, this request is redirected to another place,
400 represents 3,400 requests sent by the client has a syntax error, page 401 representatives visited without authorization, 403 did not have permission to access this page, not on behalf of this page 404
4,500 behalf of the server 5 at the beginning is abnormal, the abnormal internal server 500 delegates, 504 represents the server side timeout, return no result
(8) test tool webservice interface to soapui
How webservice interface to test it, he does not need you to go on the message, and will address a webservice, wsdl file or directly into the soapui, you can see all the interfaces inside the webservice, there are messages, direct fill arguments, returns the result to see it
(9) Interface test case design
By verification, the parameters of its interface documentation, incoming normal, if you can return the correct results
Interface Safety: 1, bypass the validation, for example, to buy a commodity, its price is $ 300, then I submit an order, I put the price of this commodity into three yuan, there is no back-end verification. Genghen point, I put the money into a -3, is not my balance but also increase? 2, bypassing the identity of the authorized product information such as modifying the interface, it must get the seller to modify, then I pass an ordinary user can not modify success, I pass one of the other sellers can not be modified successfully 3, parameters are encrypted, For example, I landed interfaces, user names and passwords are not encrypted, if not encrypted, then someone intercepting your request, you will be able to obtain information, and encryption rules are easy to crack. The complexity of the check 4, password security rules, the password
Abnormal verification: abnormal, that is, I do not enter parameters in accordance with the requirements of your interface documentation to verify the interface check on abnormal situations. For example, do not fill the required parameters, enter the integer type of the incoming string type, length is 10, 11 pass, in short, is how come you say, how come I do not, in fact, also three, will pass non-essential passed, the parameter type, the parameter length
According to the business logic design, then, is based on their own business systems to design use cases that each company's business is not the same, you have to specifically look at their company's business, but in fact this is also functional test design use cases is the same. For example, take the bbs, the demand bbs is this: 1, Login failed five times, and then have to wait another 15 minutes to log 2, requires newly registered users can post messages through the internship 3, delete posts deducted points and many more
