1. Why do we need interface documents?
Interface testing without interface documentation is a fool's errand. The previous interface testing focused on protocols and fiddler simulated interface requests. It is estimated that most of them still don't know how to start testing. The editor here specially takes out the interface document as a reference for interface testing (it is estimated that many test partners have never seen the interface document).
For example: front-end development and back-end development verbally discuss: "Return 0 if successful, return 1 if failed." The result was finally developed, and the test MM found that the backend returned 1 if successful and 0 if failed. So the two developers began to fight, and neither one admitted that he was wrong. No one is willing to bow their heads and admit their mistakes, because the words are empty and empty, and what was discussed at the beginning will be forgotten in two days. In order to avoid wrangling over such trivial matters and wasting unnecessary time, interface documents were created.
The writing is clearly written in black and white, and the test is also useful for reference.
2. SMS interface requirements
All functional development is inseparable from requirements documents, and all testing is also inseparable from requirements documents. Let’s first look at the requirements of this SMS interface, as follows:
Working method
· The two parties exchange data through HTTP, and the third party can send submission content or respond to request content in a simple "name=value" method. That is, exchanged through HTTP's GET/POST method.
· In addition, both parties need to ensure the integrity and security of data transmission. Every time a request is sent, there is a response (the response return format is plain text). Security verification currently uses username and password.
Character encoding
·The data received by the server can be GBK encoded characters, and the default received data is GBK encoded.
· The request response content is GBK encoded.
Response format
: The response is the value returned after each request is submitted to the server.
The response value format is a plain text status code, for example, 0 is returned after successful transmission.
3. Send SMS interface document
Function: Send SMS
HTTP request method: GET/POST
request URL http://host:8080/sms/mt.jsp?cpName=user account&cpPwd=user password&phones=number&msg=content request
parameters:
Return results:
Parameter name Type Description
Return description String If the transmission is successful, 0 will be returned. If the transmission is unsuccessful, "ERROR&& corresponding error message" will be returned.
Request example
GET http://host:8080/sms/mt.jsp?cpName=user account&cpPwd=user password&phones=number&msg=content
(Note: Generally, this kind of interface for submitting parameters uses the post method. Although get can also be submitted, it is more stupid. If you encounter a developer who uses the get method to submit data, you can slap him.)
4. Sending SMS interface documents in batches
Function: Send SMS in batches
HTTP request method: POST
request URL
http://221.122.112.136:8080/sms/batchmt.jsp?pack=packet content
request parameters
Request example:
POST http://host:8080/sms/batchmt.jsp
request data
{ 'cpid':'Your username', 'cppwd':'Your password', 'items':[ { 'content':'111【Software Testing Tribe】', 'phone':'123123212312', ' extend':'123123', 'spnumber':'11111' }, { 'content':'222【Software Testing Tribe】', 'phone':'12312312312', 'extend':'123123', 'spnumber': '11111' } ] }
5. Interface standard documents
6. Test method
Input parameter test: Test the input parameters, which can also be said to be a test assuming the incorrect number of interface parameters, to ensure that the interface handles any type of input accordingly: the input parameters are legal, and the input parameters are
illegal
.
The input parameter is empty.
The input parameter is null.
The input parameter is too long.
(Mainly refer to the interface test document)
function test
(Mainly refer to the requirements document)
Exception testing
(Simulating various possible abnormal scenarios)
The interface testing method has been discussed in the first article, so I won’t go into details here. It is recommended to refer to the video below.
After practicing 30 practical projects of interface automation testing in 7 days, 28K people joined the byte testing position. [Automated testing/interface testing/software testing/performance testing/Jmeter]
Finally, I would like to thank everyone who reads my article carefully. Reciprocity is always necessary. Although it is not a very valuable thing, if you can use it, you can take it directly:
This information 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. I hope it can also help you!