How to build an interface automation testing framework?

Why do it （ automation ） The interface test ？

　　1、 Due to the increasing complexity of various systems , As a result, the cost of traditional test methods increases and the test efficiency decreases significantly , Interface testing is relative to UI The test is more stable , And it is relatively easy to realize automatic continuous integration , It can reduce the time cost of manual regression testing , Shorten the test cycle .

　　2、 Interface testing can be involved in project development earlier , Generally, as long as the interface is defined , You can write code . and A functional test It can only be carried out after the system provides a measurable interface .

　　3、 be relative to UI test （ Some test environments are troublesome ） Come on , Interface testing can cover the underlying code logic more simply and comprehensively , To discover some hidden bug.

　　4、 In terms of security , The front and back frames of most systems are now separated , Only relying on the front end for restriction can no longer meet the security requirements of the system , Need back-end synchronization for control , Therefore, the test also needs to be verified from the interface level .

　　5. More and more teams begin to receive DevOps The high degree of synergy advocated , Research and development 、 test 、 Integrated thinking of operation and maintenance and delivery , Put forward higher requirements for test efficiency .

　　 Interface testing principle

　　 Simulate the client to send a request to the server , After receiving, the server processes and returns a reply to the client , The process of the client receiving the reply again .

　　 Test range

　　· Business function （ Including normal 、 Whether the exception scenario is implemented ）

　　·  Business rules （ Is the coverage comprehensive ）

　　·  Parameter validation （ The border 、 Whether the business rules meet the requirements ）

　　·  Abnormal scenario （ Repeated submission 、 Concurrent commit 、 Business interruption 、 Multi machine environment 、 big data Quantity test ）

　　·  Performance testing （ response time 、 throughput 、 Concurrency number 、 Resource requirements ）

　　·  Security testing （ Authority verification 、SQL Injection, etc. ）

　　 One 、 Automated testing framework Planning ideas

　　1. Choice language

　　· python

　　· java

　　 Choose which one you are good at , recommend python

　　2. Programming tool selection

　　· pycharm

　　· vscode

　　 Choose which one you are good at ？

　　3. Test framework selection

　　· unittest ---python Built in test framework

　　· pytest ---unittest Upgraded version , recommend

　　· httprunner

　　· rf frame --- keyword

　　4. Report visual scheme selection

　　· htmltestrunner

　　· beautifulreport

　　· allure

　　5. Continuous integration solution

　　· jenkins

　　6. Warehouse server selection

　　· github --- Server is abroad

　　· gitlab

　　· gitee

　　7. Selection of test management tools

　　·  ZenTao

　　· jira

　　 There are generally two ways to build an interface automation test framework ：

　　1. Tool based

　　 for example ：Postman+Newman+Jenkins+Git/svn Jmeter+Ant+Jenkins+Git/svn

　　2. Code based

　　 for example ：Python+Requests+Pytest+Allure

　　 Personal advice ： If it's a learning stage , Choose a code based pattern , Through their own step-by-step planning of the project 、 Write code , Can better understand the implementation principle of interface automation , It will be easier to learn some tools later .

　　 What I choose here is ： Python+pycharm+pytest+allure+gitlab+jira

　　 After planning the scheme, we can create our project code project （ Can be written with The test case parallel , The format of test cases needs to be agreed in advance , Facilitate subsequent code design ）.

　　 Two 、 Project code engineering construction ideas

　　 Principles of designing the framework ：

　　·  Encapsulate base class methods

　　 For some more general methods , Can be encapsulated , Like send a request 、 increase 、 Delete 、 Change 、 check .

　　·  High cohesion and low coupling

　　 Each module can complete its own functions as independently as possible , It doesn't depend on the code outside the module .

　　 The complexity of the interface between modules shall be as low as possible , For example, minimize calls between methods within a class , Otherwise, a change in one method will affect another method that calls it .

　　·  Script separation

　　 Business code 、 The test data should be separated from each other 、 Flexible call . The idea is similar to a first acquaintance PO Mode and in Selenium In simple practice PO Design patterns . There should be no specific data in the code 、 To configure . Instead, call the corresponding data file .

　　 3、 ... and 、 A relatively perfect project code engineering structure ：

　　- common # Package file , Common module , Store some general methods

　　 - baseapi.py

　　 - class BaseApi()# Base class

　　 - Method 1： Send a request

　　 - Method 2： increase

　　 - Method 3： Delete

　　 - Method 4： Change

　　 - Method 5： check

　　- libs # Package file , Store business layer code

　　 - login.py # Login module

　　 - class Login(BaseApi) # Inherit from the base class BaseApi

　　 - Method 1： Send login request

　　 - Method 2： Send a logout request

　　 - logout.py # Log out of the module

　　 - class Logout(BaseApi)

　　- configs # Package file , Storage configuration

　　 - config.py

　　 - HOST='xxx'# Used to switch the test environment

　　 - url='xxx'

　　- datas # Folder , Storing data / The test case

　　 - xxx.xls

　　 - xxx.yaml

　　- testCase # Package file , Store test case code , Note compliance pytest Naming specification

　　 - test_login.py

　　 - class Test_login

　　 - Method 1：test_login01

　　 - Method 2：test_login02

　　 - test_logout.py

　　 - - class Test_logout

　　 - Method 1：test_logout01

　　 - Method 2：test_logout02

　　- outFiles # Folder , The output file

　　 - logs # Deposit log file

　　 - report # Storage Report

　　 - screenShot # Save screenshots

　　- tools # Package file , Tool class

　　 - handle_data.py

　　 - handle_excel.py

　　 - handle_path.py

　　 - handle_yaml.py

　　- docs # Folder , Store description documents

　　 - Code specification .doc

　　 - The requirements document .doc

　　 Frame building ：

　　 Four 、 Follow up code writing ideas ：

　　 The coding idea after the framework is written , Generally speaking

　　1. Base class encapsulation , Put some common methods, such as sending requests 、 increase 、 Delete 、 Change 、 Check and put it in our base class .

　　2. Write the interface code of the business layer .

　　3. Write test case code , If you find something missing in the process, write what method , Think about whether this method should be placed in a specific business or a base class or tools Inside , This process is a process of continuous code optimization . Until our use case code is written .

　　 such as , In the process of writing test case code, you need to read yaml file , It's just tools Add one inside. get_yml_data Methods

　　 Another example , Two business modules need to be associated , need A Method returns an object to B Method use , Then optimize A Method , Give the return value .

　　 Another example is , Some key nodes need screenshots , Then go to the method of supplementing the screenshot .