1 Introduction
In the last article, Hongge introduced the interface use case design, so in this chapter, Hongge will introduce the interface test tool while it is hot. Then the friends or children's shoes can use the interface test tool to execute the test cases according to the designed test cases to manually test the interface. There are only a few manual testing tools, and it is very simple to use. Hongge will not repeat them here. Those who are interested can take a look at the introduction of interface testing tools by Hongge in Python interface automation. Here, Hongge is simple Mention, just pass by.
2. Common tools for manual interface testing
Below are some of the main commonly used interface testing tools listed by Hongge, commonly used postman and jmeter. Hongge also recommends using jmeter. The middle two are rarely used. Use fiddler's words. That means that the interface test is prepared, and no interface test document has been formed. It also requires the interface tester to capture packets to view the interface address and the parameters for sending the request. So this Hong Ge is not very recommended.
Postman (Chrome plug-in)
HttpRequest (Firefox plug-in)
Fiddler (capable of capturing packets and sending requests)
Semi-automatic: Jmeter (incomplete statistics on results)
3. Design of the automation framework
Here is a summary of a framework. Later, as we learn more and then enrich, refine, and refine it little by little, Hongge will slowly implement this framework little by little. This is a layered architecture, which is actually similar to the MVC in Java.
3.1 Display layer: test report
In the display layer, the general leaders here cannot see or like to see it, so this part mainly shows the test report. Generally, this part is for the leader or the relevant person in charge of the test. It can visually show the test results. Pass and fail It is clear at a glance how many interfaces passed, how many passed, and how many failed. This test report is mainly explained in conjunction with testng. There is a module in front to explain this test framework, if you don't know, you can go and see. Portal
3.2 Control layer: logic verification
This part of the control layer is mainly about what requests are inside, and what parameters these requests have, and then after sending the request, verify that the returned result is consistent with our expected result.
3.3 Persistence layer: test case storage (data driven)
This part is mainly used to store the test cases we designed for data-driven testing.
4. Summary
Well, this article is mainly a brief theoretical introduction to boring, I hope you like it. Here is a brief introduction to the automation framework. We will refine it step by step, implement and perfect it step by step around this framework.