Introduction to server interface testing
What is the server?
Generally speaking, the server refers to everything behind providing data services for the Internet functions used by users in APP or PC. Taking the product link of the Tmall Elf smart speaker series as an example, the server is the link after the gateway (including the gateway).
What is an interface?
Officially, it is a shared boundary for information exchange between two independent components in a computer system. In layman's terms, it is the most common information exchange method used by the server to provide data services to the outside world. The server that provides data services is an organization that can be large or small. It mostly does more than one thing. It has done so many things. The ultimate goal is to be used by APP or other callers, so the server sent several representatives. , for example, API 1 is responsible for providing user information, API 2 is responsible for providing device information, API 3 is responsible for providing played audio information, and so on. Colleagues, the server stipulates that the connector passwords for communicating with API 1 are param1, param2..., and the connector passwords for communicating with API 2 are param3, param4..., and params are interface parameters, which are used to tell the server what services you want, specifically What are the requirements. The interface generally consists of three parts: protocol, address and parameters.
What is interface testing?
Generally speaking, interface testing refers to functional testing of a given interface to determine whether the interface return value is correct when different parameters are entered. The picture below is the classic testing pyramid model.
In this model, the proportion will be higher as you go down, which means that in a product test, unit testing has the highest proportion, followed by interface testing, UI automation testing, and the manual testing part at the top. The server interface test is in the middle, connecting the previous and the following, which shows its importance.
现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036
Why do we need to do interface testing?
Generally, interface testing is done for the following reasons:
- Interface is the most commonly used information exchange method for servers to provide external data services. Most of the content of the interface is data. Through data comparison, we can infer the logic of the system. Testing the interface is actually testing the logic.
- Interface testing is relatively easy to automate and implement continuous integration, and is relatively stable compared to UI automation. It can reduce the labor cost and time of manual regression testing, shorten the testing cycle, and support the rapid release requirements of the backend.
How to do interface testing?
As mentioned earlier, the interface consists of these components: interface address, request protocol, request parameters and expected results. The general steps for testing the interface are: send request -> parse results -> verify results.
To put it simply, interface testing is to refer to the interface document, call the interface, and see whether the result returned is consistent with the document description; in addition, test the interface's handling of abnormal logic such as illegal parameters or boundary values.
In depth, the focus of interface testing is:
1. Whether the data logic of the interface is correct. We need to fully understand the function of the interface, what kind of data logic is inside, what information or resources it exchanges with the upstream and downstream, and not simply stay in the parameter call and the superficial data returned by the program. In layman's terms, you need to know what this interface is used for, where it is used, what will happen every time it is called, and then check whether the changes have occurred.
2. The interface’s handling mechanism for exception parameters and fault tolerance of upstream and downstream services. As shown in the figure below, the interface A under test depends on the upstream service A, so it is very important whether the interface under test is fault-tolerant when service A is abnormal, otherwise the service may hang or crash. In addition, as the service provider interface B, it should be fully compatible with different usage scenarios or the use of different versions of callers. It cannot be used by other service users except E to meet the needs of service E. In general, the principle is "the upstream is unreliable, and the downstream must be compatible."
Introduction to interface test automation
What is interface test automation?
Interface test automation, simply put, means scripting functional test cases and then executing the script to generate a visual test report.
Why do we need to automate interface testing?
No matter what kind of testing method, it is to verify functions and find bugs. So why do we need to automate interface testing? In one sentence, it is to save labor costs. Specifically, it includes the following points:
- Reduce your own workload and free testing from boring and repetitive manual testing;
- Assist manual testing to complete tasks that are difficult or impossible to simulate;
- Improve work efficiency, such as automated compilation, packaging, deployment, continuous integration and even continuous delivery of test environments.
- Help locate problems. For example, if a problem is found at the interface layer, you can locate the log error or error code line through the added traceID.
- Discover bugs as early as possible and automatically notify testers. Once a problem is discovered, testers are notified immediately, quickly and efficiently.
Specifications for interface test automation
Here, combined with some of my usual experience in interface testing, I have summarized some specifications for interface testing automation, and you are welcome to add to them.
- Document preparation
Sharpening the knife does not waste time cutting wood, and preparing detailed interface-related documents can help the subsequent interface automation testing work to be carried out efficiently. Relevant documents include but are not limited to the following:
1. "Requirements Document" clearly defines: the business scenario behind the interface, that is, what the interface is used for, where it is used, what happens each time it is called, etc.;
2. "Interface Document" clearly defines: interface name, each input parameter value, each return value, and other related information;
3. "UI Interaction Diagram" clearly defines: the data to be displayed on each single page; the interaction between pages, etc.;
4. "Data Table Design Document" clearly defines: table field rules, table N-to-N relationships (one-to-one, one-to-many, many-to-many), etc.;
Be sure to confirm with relevant demand parties that the information in the document is reliable and up-to-date. Only by relying on reliable documents can you design correct and detailed interface use cases and get the most correct results.
- Clarify the functions required for interface test automation
1. Verification (assertion)
Test assertions are test passing conditions in automated testing, used to determine whether the test case meets expectations. Therefore, supporting return value verification is a necessary function.
2. Data isolation
Data isolation means that specific request interfaces, parameters, verification and other data are isolated from the code, which facilitates maintenance. Once the interface use cases need to be adjusted or new interface use cases need to be added, the location can be found quickly. Another benefit of isolation is reusability. The framework can be promoted to other teams. Users can use the same code and only need to fill in their own use cases as required to test.
3. Data transfer
After data isolation and maintainability are achieved, data transfer is another more important requirement. During interface testing, we will first implement single interface decoupling, and then combine multiple interfaces according to business scenarios. Data transfer is a necessary condition for combining multiple interfaces, which allows parameters to be passed down between interface use cases. For example, we query the device information of the current Tmall Genie speaker through the device information query interface. This interface will return a UUID. Next, we need to query the user information bound to the current device through the user information query interface. At this time, the The request data of the two interfaces needs to be extracted from the return in the first interface use case.
4. Function function
Actual business scenario testing will require the support of various auxiliary functions, such as randomly generated timestamps, request IDs, random mobile phone numbers or location information, etc. At this time, we need code that can support the execution when identifying the corresponding keywords. Fill in the corresponding function function.
5. Configurable
The current test environments include but are not limited to daily, pre-release 1, pre-release 2, online, etc. Therefore, the use cases can not only be executed in one environment, but also require the same interface. The use cases can be used in daily, pre-release, online, etc. Can be executed in any environment. Therefore, the framework needs to be configurable and easy to switch. Different configuration files can be called to execute in different environments. 6. Log The log contains key information such as the specific execution interface, request method, request parameters, return value, verification interface, request time, time consumption, etc. The advantage of the log is that it can quickly locate problems with new use cases. Fill in where there is a problem. Secondly, it is convenient to provide data to the development feedback when a bug is discovered. The development can quickly locate the problem from the trigger time, parameters and other information.
7. Visual reporting
After the use case is executed, it is time to show the results to the team. A visual report can facilitate team members to understand the number of successes, number of failures and other data for each automated interface use case execution.
8. Sustainable integration
For interfaces that already have test cases and have been tested, we hope to form regression use cases. Before the next version iteration or launch, a regression test will be conducted through the existing use cases to ensure that newly launched functions do not affect existing functions. Therefore, this requires interface automation testing to be continuously integrated rather than one-time.
- Interface test automation framework selection
Combining our needs for the interface test automation framework and the characteristics of many testing tools currently on the market, it is summarized in the following table:
Here is a brief list:
1、fiddler
fiddler is an HTTP protocol debugging proxy tool that is used for both web and mobile testing. It also supports interface testing. It can record and inspect all http communications between your computer and the Internet, set breakpoints, and view all data "in and out" of Fiddler (referring to cookies, html, js, css and other files).
2、postman
It is a plug-in developed by Google and installed on the Chrome browser. It can support different interface test requests, manage test suites and automate operations. The weakness is that the automated assertion function is not powerful and cannot be used for continuous integration testing with Jenkins and code management libraries.
3、wireshak
This is a packet capture tool that supports TCP, UDP, HTTP and other protocols. If you do low-level network data testing, you generally need to use it, but when used for interface testing, it is a bit unfriendly. Because the data is refreshed too quickly, it is difficult to locate the interface corresponding to each operation.
4、soupUI
soapUI is an open source testing tool that checks, calls, and implements function/load/compliance testing of Web Services through soap/http. This tool can be used as a stand-alone testing software or integrated into Eclipse, maven2.X, Netbeans and intellij using plug-ins. Organize one or more test suites (TestSuite) into projects. Each test suite contains one or more test cases (TestCase). Each test case contains one or more test steps, including sending requests, receiving responses, and analyzing results. , change the test execution process, etc. This tool can support interface automation testing and interface performance testing, and also supports continuous integration testing with Jenkins.
5. Java code for interface testing
Why use code for automated interface testing? Some tool functions have limitations. Many companies need some specific functions that are not supported by the tools, so they have to use code to develop them. Generally, Java is used for automated testing, mainly using the httpclient.jar package, and then using unit testing tools such as JUnit or TestNG to develop test cases, and then create a job on Jenkins or our aone for continuous integration testing.
6. Python code for interface testing
Like Java, when using Python for interface testing, you can use Requests, a powerful third-party library, which can easily create interface automation use cases. The unit testing framework under Python generally uses unittest. To generate a test report, generally choose HTMLTestRunner.py. Similarly, you can use Jenkins to do continuous integration testing.
Interface test automation practice
TestNG vs. JUnit
- comprehensive comparison
In my daily testing work, the most automated testing tool I use is Java code for interface testing. Here I will first introduce my comparison of the unit testing tools TestNG and Junit. First use a table to summarize their characteristics comparison.
The similarities between TestNG and JUnit are as follows:
1. They all have annotations, that is, they all use annotations, and most of the annotations are the same;
2. Unit testing can be performed;
3. They are all tools for Java testing;
The differences between TestNG and JUnit are as follows:
1. TestNG supports more annotations, such as @ExpectedExceptions, @DataProvider, etc.;
2. JUnit 4 requires the @BeforeClass and @AfterClass methods to be declared static, which restricts the variables used in the method to be static. The method modified by @BeforeClass in TestNG can be exactly the same as an ordinary function;
3. JUnit can only be run using IDE. TestNG can be run in: command line, ant and IDE;
4. JUnit 4 is very dependent, and there is a strict sequence between test cases. If the previous test fails, all subsequent dependency tests will fail. TestNG leverages @Test's dependsOnMethods attribute to handle test dependencies. If a method depends on a method that fails, it will be skipped instead of marked as failed.
5. For testing n different parameter combinations, JUnit 4 needs to write n test cases. The tasks completed by each test case are basically the same, only the parameters of the method have changed. TestNG's parameterized testing only requires one test case, and then add the required parameters to the TestNG xml configuration file or use the @DataProvider method to inject different parameters. The advantage of this is that the parameters are separated from the test code, and non-programmers can also modify the parameters without recompiling the test code.
6. The test results of JUnit 4 are reflected in the Green/Red bar. In addition to the Green/Red bar, the TestNG results also have the Console window and the test-output folder. The test results are described in more detail, making it easier to locate errors.
Finally, I would like to thank everyone who has read my article carefully. Looking at the increase in fans and attention, there is always some courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly!
Software Testing Interview Document
We must study to find a high-paying job. The following interview questions are the latest interview materials from first-tier Internet companies such as Alibaba, Tencent, Byte, etc., and some Byte bosses have given authoritative answers. After finishing this set I believe everyone can find a satisfactory job based on the interview information.
