Python. Тестирование API. Структура тестов

Всем привет, меня зовут Александр, в последние 2 года занимаюсь автоматизированным тестирование. Хочу поделиться своим наработанным опытом по созданию API тестов. Для написания автотестов в компании используем selenium webdriver, behave.

Behave — это фрейморк для программирования через поведение системы в python-стиле. Behave использует тесты, написанные на “естественном”, то есть, английском языке.

Selenium webdriver широко используется и думаю в представлении не нуждается, но всегда можно загуглить.

Структура тестов behave очень проста, если feature файлы в которых описываются сценарии и папка steps в которой находятся шаги для выполнения этих сценариев.

Первое на что можно обратить внимание это на структуру feature файлов (в этих файлах находятся сами тесты, которые состоят из различных шагов):

@api @userportal @userportal_api @maps @userportal_maps @userportal_maps_api @requests
Feature: Requests userportal maps

  @get @get_maps_drivers_driverId
  Scenario Outline: Assert GET request maps/drivers/{driverId}
    Given get token
    Then Assert GET request maps drivers/<driver_id> - check <check>
    Examples:
      | driver_id  |    check    |
      |100         |status_code  |
      |[200, 159]  |structure    |
      |random 100  |response     |
      |random: 200 |all          |

  @get_maps_factories_factoryId @get
  Scenario Outline: Assert GET request maps/factories/{factoryId}
    Given get token
    Then Assert GET request maps factories/<factoryId> - check <check>
    Examples:
      | factoryId  |    check    |
      | random: 5  |status_code  |
      | random: 5  |structure    |
      |all         |response     |
      |all         |all          |

В этом примере будет выполнено 8 тестов, по 4 на каждый из описанных сценариев.

Для сокращения количества выполняемых тестов, если запрос по всем 3м проверкам выполняется без ошибок, то эти проверки можно закомментировать и будет выполняться только полная проверка запроса (check -> all). Проверки разбиваются для того, чтобы можно было увидеть какие тесты данного метода автоматизированы и для быстрого поиска проблемы, если тест упал.

При создании теста в первую очередь ориентируюсь на метод запроса и название самого метода. Считаю, что хорошее название API теста должно состоять 1) Из метода запроса 2) короткий путь (без base url). Я реализую следующие проверки на текущем проекте: 1) Статус код 2) Структура ответа 3) Сам ответ 4) Фильтры. Можно расширить еще такими: 5) Время выполнения 6) Уровень доступа и тд. (можете добавить свои варианты)

Параметры для шагов сценариев передаются в example.

Для того, чтобы при выполнении каждого теста не происходила авторизация, мною был создан шаг на получение токена, который вносится в контекст и в каждом из шагов и последующих сценариях к нему есть доступ. При запуске тестов токен получаем при выполнении первого сценария, он же обновляется по истечению жизни токена, в данном примере время жизни токена = 30 минутам.

import time
import requests
from BDDCommon.CommonConfigs.urlconfig import URLCONFIG
from BDDCommon.configs import current_settings, STANDS


token = None
expiration_time = 0


@step('get token')
def get_token(context):
    context.token_auth = get_auth_token()


def get_auth_token():
    global token
    global expiration_time

    current_time = int(time.time())
    # Если нет токена или время жизни токена истекло - получаем новый токен
    if (token is None) or (current_time > expiration_time):
        company = current_settings['company']
        data_login = {
            'username': STANDS[current_settings['stand']]['users']['company_users'][company]['main_logist']['login'],
            'password': STANDS[current_settings['stand']]['users']['company_users'][company]['main_logist']['pwd']}
        url = URLCONFIG['base_url_not_os'] + URLCONFIG['login_token']
        token = requests.post(url, data=data_login)
        assert token.status_code == 200, f'Error auth {token.status_code} - {token.text}'
        token = token.json()
        token = {'authorization': 'Bearer ' + token['resp']['accessToken']}
        expiration_time = current_time + 1800  # допустимый срок действия токена 30 минут

    return token

Сам шаг с проверкой выглядит следующим образом:

@step('Assert GET request maps drivers/{driver_id} - check {check}')
def assert_req_maps_drivers_driver_id(context, driver_id, check):
    # Функция для проверки GET запроса maps/drivers/{driver_id}
    # driver_id может быть числом, "all", "random ЧИСЛО"
    # check может быть: "all" "structure" "response", "status_code"
    ......
    driver_id_list = get_all_drivers(company_id=current_settings['company'])
    # Проходимся по каждому водителю в списке
    for driver_el in driver_id_list:
        # Отправляем запрос
        response = get_req_maps_drivers_by_driver_id(driver_el, context.token_auth)
        url = f"{URLCONFIG['base_url_not_os']}{URLCONFIG['base_api_url']}" \
              f"{URLCONFIG['maps']}{URLCONFIG['drivers']}/{driver_el}"

        # Запускаем проверки, в зависимости от check
        if check == 'status_code' or check == 'all':
            logger.info(f'Check status_code. Method: GET URL: {url}')
            assert response.status_code == 200, \
                f'URL: {url} GET request.status_code Actual: {response.status_code} Expected: 200\n' \
                f'Response: {response.text}'

        if check == 'structure' or check == 'all':
            logger.info(f'Check structure response. Method: GET URL: {url}')
            check_structure_maps_drivers_driverId(response.json()['resp'], driver_el)

        if check == 'response' or check == 'all':
            logger.info(f'Check response. Method: GET URL: {url}')
            check_response_maps_drivers_driverId(response.json()['resp'], driver_el)

        # Вызов ошибки если передали не поддерживающий check
        if check not in ['all', 'response', 'structure', 'status_code']:
            raise Exception(f'not valid param check: {check} in function assert_get_req_maps_drivers_driver_id')

    logger.info(f'assert request maps/drivers/driverId Check: {check} - Completed\n driverIds: {driver_id_list}')

Проверка структуры ответа выглядит следующим образом:

def check_structure_maps_drivers_driverId(resp):
  assert 'vehicleNumber' in resp
  assert type(resp['vehicleNumber']) in [str, NoneType])
.........

Проверяем, что все необходимые поля есть в ответе и что их тип соответствует ожидаемому.

Проверка ответа запроса.

def check_response_maps_drivers_driverId(response, driver_id):
    driver_obj = Driver_obj(driver_id)

    expected_response = {
        'id': driver_obj.id,
        'vehicleNumber': driver_obj.vehicle_number,
        'fullName': driver_obj.name,
        ....
    }
    assert response == expected_response, f'Error response.\nActual response:\n{response}\nExpected: {expected response}'

Это самый трудоемкий процесс, но и самый интересный. В процессе расширяются методы классов, находятся ошибки в коде, происходит развитие в понимании того, как можно улучшить или ускорить свой код.

Подводя итоги, хотелось бы подчеркнуть главное:

1. Для более быстрой работы тестов позаботьтесь о том, чтобы не выполнялась авторизация при запуске каждого теста

2. Запрос отдельно - проверки отдельно

3. Разбиение проверок на разные функции

4. Название теста должно отражать название запроса

Вопросы, критику пишите в комментарии, по возможности буду отвечать.

its my first page article