This article has officially entered the practical stage , This article will mainly explain some interface concepts in interface testing , At the same time, I will also briefly introduce the project to be tested , In addition, there is a portal for a series of articles below , It's still being updated , Interested partners can also go to check , Don't talk much , Let's have a look ~
Series articles ：
Series articles 1：【Python automated testing 1】 meet Python The beauty of the
Series articles 2：【Python automated testing 2】Python Installation configuration and PyCharm Basic use
Series articles 3：【Python automated testing 3】 First knowledge of data types and basic syntax
Series articles 4：【Python automated testing 4】 Summary of string knowledge
Series articles 5：【Python automated testing 5】 List and tuple knowledge summary
Series articles 6：【Python automated testing 6】 Dictionary and collective knowledge summary
Series articles 7：【Python automated testing 7】 Data operator knowledge collection
Series articles 8：【Python automated testing 8】 Explanation of process control statement
Series articles 9：【Python automated testing 9】 Function knowledge collection
Series articles 10：【Python automated testing 10】 File basic operation
Series articles 11：【Python automated testing 11】 modular 、 Package and path knowledge collection
Series articles 12：【Python automated testing 12】 Knowledge collection of exception handling mechanism
Series articles 13：【Python automated testing 13】 class 、 object 、 Collection of attribute and method knowledge
Series articles 14：【Python automated testing 14】Python Basic and advanced exercises of automatic test
Series articles 15：【Python automated testing 15】unittest The core concept and function of test framework
Series articles 16：【Python automated testing 16】 Test case data separation
Series articles 17：【Python automated testing 17】openpyxl Secondary packaging and data driven
Series articles 18：【Python automated testing 18】 Configuration file analysis and practical application
Series articles 19：【Python automated testing 19】 Log system logging Explain
Series articles 20：【Python automated testing 20】 Construction of interface automation test framework model
The author once wrote a special explanation on the basic content of the interface and its related concepts , Quite detailed overall , Address reference ： Do you really understand interface testing ？
The project is a Web Management backstage , Have basic information 、 The user action 、 Email management 、 Order management and other modules , In the actual combat of the project , As simple as possible 、 The most efficient way to explain the deepest content , So that everyone can fully understand the project , And how to use the content explained in the actual combat to apply to their own company or private projects .
The project has a detailed interface document , The document includes the corresponding request header 、 Request body 、 Request mode 、 Request parameters 、 Examples of success, feedback, etc , Including all modules in the background , Have corresponding detailed interface information , In the process of practice , I will take screenshots according to the specific situation 、 carding 、 Summary , Only one of the interfaces is shown below as an example 
Obviously, we built the framework for automated testing , Including but not limited to interface automation 、Web automation 、App automation ,UI Automated testing and so on , Some parts will be similar to functional tests , There may also be differences between companies , But generally unchanged , Now let's introduce the process of automated testing ：
""" First step ： Requirements review -- Automated testing is the same as functional testing , The first step requires a requirements review , Be familiar with the requirements during the review , Find requirements defects , This paves the way for demand analysis The second step ： Demand analysis -- The requirement analysis stage is mainly for automated testers to analyze the requirements separately , Disassemble requirements , Understand the requirements in detail , Pave the way for the design of test cases The third step ： Interface document -- After getting familiar with the requirements, you know what you are about to be responsible for , In the interface automation test stage, you need to understand the interface documents , What are the parameters , Request header 、 Request body 、 Request mode 、 Request parameters, etc If the company does not have interface documentation , Usually go to the developer to ask , Let development give a document , If it's still fruitless , You need to get the interface by capturing packets and sort it out into documents Step four ： test plan -- Roughly sort out your personal test plan , Time required for use case design , When to design , When do you expect to pass the test , Whether automation technology is adopted in which link Consider the priority of testing, etc , If you are responsible for the corresponding test , It is also necessary to consider the manpower allocation of tasks Step five ： Plan review -- When you sort out a plan , Also have confirmation discussions with team members , Check whether there are documents in the plan , Is there anything that can be improved , Do the team members have any questions about this Step six ： The test case -- Familiar with requirements and interface documents and have a test plan , Then it comes to the design of test cases , Design test cases for interface automation Step seven ： Use case review -- After the interface test case design is completed, enter the use case review stage , Confirm whether there is any omission in the test case , Whether it is not standardized , Whether it is convenient for automatic reading 、 Use, etc Step eight ： Use case execution -- Write and sort out the code through interface automation test cases , During this period, you can build a test framework or have a framework before that Step nine ： Test report -- When the execution completes the test case , The corresponding test report conclusion can be output , Same business , Including quality 、 Problem distribution , Step 10 ： Integrated deployment -- When the test framework is built and the test cases can be executed smoothly , When the corresponding test report is produced , Consider integrated deployment , Through scheduled tasks , Smoke on a weekly or monthly basis """
The test pyramid is mainly divided into three stages , The bottom line is unit testing / Component testing , That is, code related checks and tests , However, due to the limitation of domestic agile development and testing ability , Therefore, unit tests are not conducted in most company tests , This stage is often completed by self-test of development .
The middle layer of the pyramid is API Aspect test , That is, interface related tests , Interface testing is more professional than unit testing , However, exceptions and problems that cannot be found in manual testing can be found .
The top layer is the test on the user interface , It can also be understood as manual testing , Manual testing can only find some table level problems , However, most requirements can prevent most problems by only passing the surface function test , It's also a very important part , The closer to the upper layer of the test , The closer you can get to the business level , It can also clearly reflect the real needs .
More Than This , The closer to the bottom of the pyramid, the more efficient the test method is 、 Defects are easier to locate 、 Lower testing costs , And the closer you get to the top of the pyramid , The slower the repair efficiency , Costs are higher and defects are less likely to be located , This is why testing requires early intervention .
We know that automated testing can improve work efficiency , Nevertheless , But is it suitable for automation under any circumstances ？ Obviously not , Only if the following conditions are met , The author believes that it is more suitable for automatic testing ：
""" Meet the following conditions , More suitable for automated testing ： 1、 The requirements document , Requirements will not change frequently -- Without changing requirements , The functional modules are relatively stable , After the script is written, it does not need to spend a lot of time on modification and maintenance 2、 Long R & D and test cycle , Frequent regression testing is required 、 Smoke testing -- For example, weekly modules are tested for smoke , Frequent occurrence of an operation activity 3、 Multiple test scenarios need to be run repeatedly on multiple platforms 4、 The test contents of some test items cannot be realized through functional test , Or functional testing is very time-consuming 5、 The development of the tested system is relatively standardized , It can ensure the feasibility of the system """
Some students will continue to do functional tests after interviewing automation test engineers , He's also strange , It means confused ？ Do automated test engineers still need to do functional testing ？
The answer is clearly needed , An automated tester must be familiar with the business before performing automated testing , The best way to get familiar with the business is to do some functional tests or experience tests first , Quickly help automated testers get familiar with the business , To better test .
All right. ~ The above is all the content shared in this article , Have you learned ？ I hope I can help you ！
