Previous articles Overview and process sorting of interface automation test In, we introduce the process of interface automation test.

In our work, when a project determines to conduct interface automation test, we generally face two situations:

1. The company has been doing automated testing and has become one of them

In this case, what we need to do is to quickly understand the ready-made automated testing framework, look at the project code, understand the team's business logic and code style, and quickly integrate into it.

2. The company didn't do it before. You need to build it 0-1.

At this time, we need to plan the whole automated testing framework according to the specific situation of the project and our own skills.

1, Automatic test framework planning idea

1. Select language

• python

• java

Choose which you are good at and recommend python

2. Programming tool selection

• pycharm

• vscode

Choose which you are good at

3. Test frame selection

• Unittest -- Python's own test framework

• Pytest -- unittest upgrade, recommended

• httprunner

• rf framework --- keywords

4. Report visualization scheme selection

• htmltestrunner

• beautifulreport

• allure

5. Continuous integration scheme

• jenkins

6. Warehouse server selection

• github - servers abroad

• gitlab

• gitee

7. Selection of test management tools

• ZenTao

• jira

There are generally two ways to build the 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 suggestion: if it is the learning stage, choose the code based mode. Through planning the project step by step and writing the code, you can better understand the implementation principle of interface automation, and then learn some tools more easily.

I choose Python+pycharm+pytest+allure+gitlab+jira here

After planning the scheme, we can create our project code project (it can be parallel to writing test cases, and the format of test cases needs to be agreed in advance to facilitate subsequent code design).

2, Construction ideas of project code engineering

Principles of design framework:

• Encapsulating base class methods

  Some common methods can be encapsulated, such as sending a request, adding, deleting, modifying, and querying.

• High cohesion and low coupling

  Each module completes its own functions independently as far as possible without relying on the code outside the module.

  The complexity of the interface between modules shall be as low as possible. For example, the calls between methods within a class shall be reduced as much as possible, otherwise the change of one method will affect the other method calling it.

• Script separation

  Business code and test data should be separated from each other and called flexibly. Similar concept First understand PO mode and simply practice it in Selenium PO design pattern in. There should be no specific data or configuration in the code. Instead, call the corresponding data file.

3, A relatively complete project code engineering structure:

- common  #Package file, public module, storing some general methods
    - baseapi.py
        - class BaseApi()#Base class
            - Method 1: send request
            - Method 2: add
            - Method 3: delete
            - Method 4: Change
            - Method 5: check
- libs  #Package file to store business layer code
    - login.py #Login module
        - class Login(BaseApi) #Inherit BaseApi in base class
            - Method 1: send login request
            - Method 2: Send a logout request
    - logout.py #Logout module
        - class Logout(BaseApi)
- configs  #Package file, storage configuration
    - config.py
        - HOST='xxx'#Used to switch the test environment
        - url='xxx'
- datas #Folder to store data / test cases
    - xxx.xls
    - xxx.yaml
- testCase #Package file to store the test case code. Pay attention to the 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 #Folders, output files
    - logs #Store 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 to store description documents
    - Code specification.doc
    - Requirements document.doc

Frame construction:

4, Ideas for subsequent code writing:

The coding idea after the framework is written is generally

1. Base class encapsulation, which puts some common methods such as sending request, adding, deleting, modifying and querying into our base class.

2. Write the interface code of the business layer

3. When writing test case code, write any method you find missing in the process, and think about whether this method should be placed in specific business, base class or tools. This process is a process of continuous code optimization. Until our use case code is written.

• For example, if you need to read the yaml file in the process of writing test case code, add a get in tools_ yml_ Data method

• For another example, if the two business modules need to be associated and the object returned by method A needs to be used by method B, optimize method A and give the return value.

• For another example, if some key nodes need screenshots, supplement the screenshot method.

  

  Scan code to focus on official account "automated testing workshop"

  Become stronger together