First of all, what is an interface?
Generally speaking, there are two types of interfaces, one is the internal interface of the program, and the other is the external interface of the system.
The external interface of the system: For example, if you want to obtain resources or information from other websites or servers, others will definitely not share the database with you. They can only provide you with a method written by them to obtain the data. , you can use the methods he wrote by citing the interface he provides, so as to achieve the purpose of data sharing. For example, the apps and URLs we use are all called through the interface when processing data.
The interface within the program: the interaction between methods, the interaction between modules, the interfaces thrown inside the program, such as the bbs system, there are login modules, posting modules, etc., then you If you want to post, you must log in first, and if you want to post, you must log in. Then these two modules must interact, and it will throw out an interface for the internal system to call.
1. Common interfaces:
1. WebService interface: It is transmitted through soap protocol through http. The request message and return message are both in xml format. When we test, we use tools to call and test. Tools that can be used include SoapUI, jmeter, loadrunner, etc.;
2. http api interface: It adopts the http protocol and distinguishes the calling method by path. The request messages are in the form of key-value. The return messages are generally json strings. There are methods such as get and post, which are also the most commonly used. Two request methods. Tools that can be used include postman, RESTClient, jmeter, loadrunner, etc.;
2. Front-end and back-end:
Before talkinginterface testing, let us first understand these two concepts, front-end and back-end.
What is the front-end? For the web side, the web pages we use and the websites we open are all front-ends. These are written in HTML and CSS; for the app side, it is what we use app, developed on android or object-C (developing apps on ios), its function is to display the page, let us see the beautiful page, and do some simple verification, such as non-empty verification, we are When operating on the page, these business logic and functions, such as shopping and posting on Weibo, are implemented by the backend. The backend controls the deduction of your balance when you shop and the account to which you post on Weibo. Next, how do the front end and back end interact? It is through the interface.
What I said before may not be easy for you to understand. You just need to remember: the front end is responsible for looking beautiful, and the back end is responsible for making money to support the family.
From the comparison of the two pictures above, we can see that the same parts in the two testing activities includefunctional testing, boundary analysis testing and performance testing, other parts require special testing due to their different characteristics or concerns, and will not be discussed here. Next, we will analyze the same content in the above three parts:
1. Basic function test:
Since it is testing basic business functions, this part is the one with the highest degree of overlap between the two tests. Development students usually mainly refer to this part of the content.
2. Boundary analysis test:
On the basis of basic functional testing, the boundary conditions of input and output are considered. This part of the content will also have repeated parts (such as the boundaries of business rules). However, the input and output of the front end often provide fixed values for users to choose (such as drop-down boxes). In this case, the boundary range of the test is very limited, but there is no such limitation in interface testing. Relatively speaking, The interface can cover a wider range, and similarly, the probability of problems with the interface is also higher.
3. Performance test:
This is easier to distinguish. Although both require performance testing, the focus is indeed very different. App-side performance mainly focuses on mobile phone-related features, such as mobile phone CPU, memory, traffic, fps, etc. The interface performance mainly focuses on interface response time, concurrency, server resource usage, etc. The strategies and methods of the two tests are very different, so this part needs to be tested separately. In theory, this is also a different part.
Summary:
1. The activities of interface testing and app testing have some repetitive content, mainly focusing on business function testing. In addition, the tests for each characteristic are different, and targeted tests need to be conducted separately to ensure the quality of the entire product.
2. Interface testing can focus on server logic verification, while UI testing can focus on page display logic and interface front-end and server integration verification.
3. What is interface testing:
Interface testing is a type of testing that tests the interfaces between system components. Interface testing is mainly used to detect interaction points between external systems and systems and between internal subsystems. The focus of testing is to check the exchange of data, transmission and control management processes, as well as the mutual logical dependencies between systems, etc.
OK, the above is what Baidu Encyclopedia says, and the following is what I say.
In fact, I think interface testing is very simple, simpler than ordinary functional testing (I will say this first, I may delete O(∩_∩)O in the future!). Nowadays, many companies require interface testing experience when looking for a job. Many people have also asked me (just two or three people) what interface testing is. With the attitude of pretending to understand even if you don’t understand, I would say: the so-called interface testing is to test the corresponding input and output information under different situations. To determine whether the interface meets or meets the corresponding functional and security requirements.
Why do I say that interface testing is simpler than functional testing? Because functional testing inputs values from the page and then transfers the value to the backend by clicking buttons or links. Moreover, functional testing also tests UI, front-end interaction and other functions, but interface testing There is no page. It uses the calling address and request parameters in the interface specification document to splice the message, then sends the request and checks the return result, so it only needs to measure the incoming and outgoing parameters, which is relatively simple.
4. Interface composition
What parts does the interface consist of?
First, the interface document should contain the following content:
1. Interface description
2. Calling url
3. Request method (get\post)
4 , request parameters, parameter type, request parameter description
5. Return parameter description
It can be seen from the interface document that the interface should at least consist of a request address, a request method, and request parameters (input parameters and outgoing parameters). Some interfaces have request headers.
Header: It is a string sent by the server before transmitting HTML data to the browser using the HTTP protocol. A blank line is required between the header and the HTML file. Generally, information such as cookies and tokens are stored.
Some students asked me what is the relationship between header and input? Aren't they all parameters sent to the server?
OK, first of all, they are indeed parameters sent to the server, but they are different. The parameters stored in the header generally store some verification information, such as cookies, which are used to verify whether the request has permission requests. server, if there is one, it can request the server
5. Why interface testing is needed:
As we all know, the interface is actually used by the front-end page or APP to interact with the back-end, so many people will ask, I have already tested the functional test, why do I need to test the interface? OK, before answering this question, let me give you an example:
For example, when testing the user registration function, the user name is stipulated to be 6 to 18 characters, including letters (case-sensitive), numbers, and underscores. First of all, username rules will definitely be tested during functional testing, such as entering 20 characters, entering special characters, etc., but these may only be verified on the front end, and may not be verified on the back end. If someone circumvents it by capturing packets, What should I do if it passes front-end verification and is sent directly to the back-end? Just imagine, if the username and password are not verified on the back-end, and someone bypasses the front-end verification, can't the username and password be entered casually? If you are logging in, you may be able to log in at will through SQL injection and other means, and you can even obtain administrator rights. Isn't this scary?
Therefore, the necessity of interface testing is reflected:
①. You can find many bugs that cannot be found by operating on the page.
② Check the system’s exception handling capabilities
③. Check the security and stability of the system
④. The front-end can be changed at will. Once the interface is tested, the back-end does not need to be changed.
6. How to test the interface test:
Before conducting interface testing, you also need to understand:
1), GET and POST requests:
If it is a get request, just enter it directly in the browser. As long as it can be requested directly in the browser, it is Get request, if it is a post request, it will not work, you have to use a tool to send it.
The difference between GET request and POST request:
1. GET uses URL or Cookie to pass parameters. And POST puts the data in BODY.
2. The GET URL will have a length limit, so the POST data can be very large.
3. POST is safer than GET because the data is not visible on the address bar.
4. Generally, get requests are used to obtain data, and post requests are used to send data.
In fact, of the above points, only the last one is more reliable. The first point is that post requests can also put data into the URL. In fact, there is no length limit for get requests. Post requests It seems that the parameters are implicit, which is a little safer, but that is only for novice users. Even if you post a request, you can capture the parameters by capturing the packet. So just mention the above during the interview.
2), http status code
After each http request is issued, there will be a response. HTTP itself will have a status code to indicate whether the request is successful. Common status codes are as follows:
1. Anything starting with 200 or 2 means that the request was sent successfully. The most common one is 200, which means that the request is ok and the server has returned it.
2. 300 3 means redirection. The most common one is 302, which redirects the request to another place.
3. 400 400 means redirection. The request sent by the client has a syntax error. 401 means that the accessed page is not authorized, 403 means that there is no permission to access this page, and 404 means that there is no such page
4. 500 5 means that the server has an exception. 500 represents an internal server exception, 504 represents a server timeout and no result was returned
Next, let’s talk about how to test the interface test:
1). Common interface use case design
①. Passability verification: First of all, you must ensure that the interface function is easy to use, that is, a normal passability test. According to the parameters on the interface document, if the parameters are passed in normally, the correct result can be returned.
②. Parameter combination: Now there is an interface for operating products. There is a field type. When 1 is passed, it means modifying the product. One of the product id, product name, and price must be passed, type. When passing 2, the product is deleted, and the product ID is required. In this case, the parameter combination must be tested. When passing type 1, can the modification be successful if only the product name is passed? Can it be modified successfully when the id, name, and price are all passed? Unable to modify successfully.
③. Interface security:
1. Bypass verification. For example, if I purchase a product and its price is 300 yuan, then when I submit the order, I will If the price is changed to 3 yuan, is there any verification on the backend? To be more ruthless, if I change the price to -3, will my balance still increase?
2. Bypass identity authorization. For example, if you modify the product information interface, you must be a seller to modify it. So if I upload it to an ordinary user, can the modification be successful? If I upload it to another seller, can it be successful? Cannot be modified successfully
3. Whether the parameters are encrypted, for example, the interface I log in to, the user name and password are encrypted. If they are not encrypted, others can intercept your request and obtain your information, whether the encryption rules are easy to crack.
4. Password security rules, password complexity verification
④. Exception verification:
The so-called exception verification means that I do not enter parameters according to the requirements in your interface document to verify the interface's verification of abnormal situations. For example, if you don’t fill in the required parameters, enter the integer type, pass in the string type, and the length is 10, pass in 11. In short, you tell me how to do it, and I won’t do it. In fact, there are only these three types, which must be passed. Optionally passed, parameter type, input parameter length.
2) Design use cases based on business logic
If you design based on business logic, you are designing use cases based on the business of your own system. Each company's business is different. You have to look specifically at your company's business. In fact, this is the same as functional test design use cases.
For example, take bbs, the requirements of bbs are as follows:
1. If you fail to log in 5 times, you need to wait 15 minutes before logging in again< /span> Like this, you have to list these test points, and then create test points corresponding to the data test. 4.... ... 3. Points will be deducted for deleting posts
2. Newly registered users must have passed the internship period before they can post
7. What tools to use to measure
There are many tools for interface testing, such as postman, RESTClient, jmeter, loadrunner, SoapUI, etc. The testing tools I recommend most are postman and jmeter. Next, I will briefly introduce how to use these two tools for interface testing. Other tools will not be discussed this time. No introduction.
1) Postman is an interface testing plug-in from Google. It is simple to use, supports use case management, supports get, post, file upload, response verification, variable management, environment parameter management and other functions. It can be run in batches and supports use case export. Import.
jmeter is a free and open source tool written in 100% pure Java. It is mainly used for performance testing. Compared with loadrunner, it takes up less memory, is free and open source, lightweight and convenient, and does not require installation. It is increasingly popular among the public. .
8. Interface testing and continuous integration
For interface testing, continuous integration automation is the core content. Only by maintaining automation can we achieve low cost and high profits. At present, we have implemented interface automation, which is mainly used in the regression phase. In the future, we need to strengthen the degree of automation, including but not limited to the following:
a) In terms of process: Strengthen the coverage of interface abnormal scenarios in the regression phase, and gradually extend to the system testing and smoke testing phases, and finally achieve full-process automation.
b) Result display: richer result display, trend analysis, quality statistics and analysis, etc.
c) Problem location: Error messages and logs are more accurate, making it easier to reproduce and locate problems.
d) Result verification: Strengthen automated verification capabilities, such as database information verification.
e) Code coverage: Constantly try to move from the current black box to the white box to improve code coverage.
f) Performance requirements: Improve the performance testing system and monitor whether the interface performance indicators are normal through automated means.
9. Interface test quality assessment standards
a) Whether the coverage of business functions is complete
b) Whether the coverage of business rules is complete
c) Whether parameter verification meets the requirements (boundaries, business rules)
d) Whether the coverage of interface exception scenarios is complete
e) Whether the interface coverage meets the requirements?
f) Does the code coverage meet the requirements?
g) Whether the performance indicators meet the requirements
h) Whether the safety indicators meet the requirements
Thank you to everyone who reads my article carefully. There is always a courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly:
These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends, and this warehouse also accompanies Thousands of test engineers have gone through the most difficult journey, and I hope it can help you!Friends in need can click on the small card below to receive it
