Методы тестирования веб-API, которые должен знать каждый: чек-листы для начинающих

Тестирование веб-API нужно, чтобы обеспечить надёжность взаимодействий и обработки данных в приложениях. Ошибки в API могут вызвать сбои и уязвимости, поэтому проверка аутентификации, авторизации и шифрования критична. Качественно протестированные API улучшают пользовательский опыт и снижают затраты на дальнейшую поддержку продукта.

Михаил Абрамов, технический писатель платформы МТС Exolve, подготовил для начинающих специалистов чек-листы с основными правилами и процедурами тестирования.

Разделение тестирования: фронтенд vs бэкенд

Тестирование в разработке ПО обычно делится на фронтенд- и бэкенд-тестирование, каждое из которых фокусируется на разных аспектах приложения.

Фронтенд-тестирование

• что тестируется: пользовательский интерфейс и взаимодействие пользователя с приложением. Включает в себя элементы дизайна, вёрстку, функциональность и клиентскую бизнес-логику

• задачи: контроль отображения интерфейса на разных устройствах и браузерах, удобства использования, отклика на действия пользователей, правильности выполнения клиентских скриптов и запросов к API

• инструменты и подходы: часто используются инструменты автоматизации фронтенда (например, Selenium, Cypress), а также ручное тестирование для оценки юзабилити

Бэкенд-тестирование

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

• задачи: проверка правильности работы серверных скриптов, обработки данных, безопасности, производительности сервера, корректной работы API

• инструменты и подходы: используются инструменты для автоматизации бэкенд-тестирования (например, Postman, JUnit, Mockito) и интеграционное тестирование

Специфика тестирования API

Тестирование API прокладывает мост между бэкендом и фронтендом и занимает ключевую позицию в создании общей функциональности и надёжности приложения.

• основное направление: тестирование обычно сосредоточено на бэкенде, поскольку API — это интерфейс, который позволяет внешним системам взаимодействовать с бэкендом приложения

• задачи: проверка функциональности, безопасности, производительности API, правильности ответов на различные запросы и обработку ошибок

• связь с фронтендом: хотя API относится к бэкенду, его тестирование также важно для фронтенда, поскольку клиентская часть приложения часто взаимодействует с интерфейсом для получения или отправки данных. Поэтому важно убедиться, что фронтенд корректно обрабатывает данные, полученные от API

Типы тестирования

Ручное тестирование

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

Когда используется:

• для тестирования новых функций, пользовательских сценариев, которые сложно автоматизировать, и юзабилити-тестирования (проверки удобства интерфейса)

• для исследовательского тестирования, где нужны понимание и интуиция человека

Преимущества:

• гибкость и способность адаптироваться к непредвиденным изменениям и условиям

• точность в оценке пользовательского опыта и визуальных аспектов интерфейса

• лучшее выявление и диагностика сложных ошибок, которые могут быть упущены автоматизированными инструментами

Автоматизированное тестирование

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

Когда используется:

• для повторяющихся тестов, таких как регрессионное тестирование, где одни и те же проверки нужно выполнять регулярно

• для проверки производительности и нагрузочного тестирования, где требуются быстрые и масштабируемые решения

Преимущества:

• экономит время и усилия, особенно при необходимости частого повторения тестов

• уменьшает вероятность ошибок, связанных с человеческим фактором

• позволяет проводить более широкий охват проверки, включая нагрузочное и тестирование производительности

• интеграция с процессами CI/CD для быстрой обратной связи и улучшения процессов разработки

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

Автоматизированное тестирование в современной разработке

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

Работу с автоматизированными тестами можно сравнить с использованием хорошо отлаженного инструмента: после первоначальной настройки команда может эффективно и быстро реагировать на изменения и новые требования. Этот подход особенно ценен в рамках Agile- и DevOps-практик, где быстрота итераций и непрерывная интеграция важны для гладкой и непрерывной доставки качественного продукта.

Вызовы и затраты на автоматизацию

На создание надёжной структуры автоматизации тоже нужны ресурсы и инвестиции. Например, нужно уделить внимание поиску квалифицированных специалистов и настройке процессов, а это может занять немало времени.

Роль ручного тестирования

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

Баланс между ручным и автоматизированным тестированием

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

Позитивные и негативные тесты

Позитивные и негативные тесты составляют основу проверки программного обеспечения. Позитивные подтверждают, что функции работают корректно. Негативные проверяют устойчивость системы к неверным входным данным. Давайте разберёмся в этих фундаментальных концепциях тестирования и в их значении для разработки ПО.

Позитивные тесты

Позитивное тестирование (Positive Testing) направлено на проверку ожидаемой работы API при получении валидных входных данных. Основная цель — убедиться, что интерфейс правильно функционирует в стандартных условиях использования.

Что проверяем?

1. Валидные запросы: тестирование с корректными параметрами запроса, чтобы убедиться, что API возвращает правильный ответ.

2. Ожидаемые результаты: проверка на соответствие выходных данных API его документации и техническим требованиям.

3. Коды состояния: отслеживание того, что для валидных запросов возвращаются соответствующие HTTP статус-коды (например, 200 OK для успешных запросов).

4. Проверка функциональности: убеждение в том, что все заявленные функции API работают должным образом.

Пример

Чтобы провести позитивное тестирование API, можно воспользоваться Postman и сервисом JSONPlaceholder.

1. Запустите программу Postman на вашем компьютере.

2. В интерфейсе Postman нажмите на кнопку для создания нового запроса.

3. В интерфейсе для создания запроса выберите метод GET из выпадающего списка доступных HTTP-методов.

4. В адресную строку запроса введите UR: https://jsonplaceholder.typicode.com/posts.

5. Нажмите кнопку Send для отправки запроса на сервер.

6. Убедитесь, что в ответе от сервера статус кода состояния HTTP равен 200 OK, что означает успешное выполнение запроса.

7. Просмотрите тело ответа (payload), чтобы удостовериться, что необходимые данные были корректно возвращены в ответе.

Негативные тесты

Негативное тестирование (Negative Testing) фокусируется на том, как API реагирует на неверные, некорректные или необычные входные данные. Это помогает выявить уязвимости и устойчивость к ошибкам.

Что проверяем?

1. Невалидные запросы: отправка неправильных, некорректно сформированных или невалидных данных, чтобы проверить, верно ли API обрабатывает такие ситуации.

2. Обработка ошибок: проверка того, что API возвращает правильные сообщения об ошибках и соответствующие HTTP статус-коды. Например, 400 Bad Request для неверных запросов.

3. Устойчивость: тестирование способности API справляться с нестандартными и крайними сценариями без сбоев или непредсказуемого поведения.

4. Безопасность: негативные тесты могут выявить уязвимости в безопасности, такие как обработка SQL-инъекций или других видов атак.

Пример

Чтобы провести негативный тест, можно воспользоваться Postman и JSONPlaceholder.

1. Запустите программу Postman на вашем компьютере.

2. В интерфейсе Postman создайте новый запрос, выбрав метод POST.

3. В адресной строке запроса введите URL: https://jsonplaceholder.typicode.com/posts.

4. Перейдите в раздел Body запроса.

5. Выберите опцию raw и в выпадающем списке форматов выберите JSON.

6. В тело запроса введите некорректный JSON, например, просто текст «Невалидный JSON».

7. Нажмите кнопку Send для отправки запроса на сервер.

8. Обратите внимание на ответ сервера. Проверьте, какой статус-код возвращается:

   а) Ожидается, что сервер вернёт код ошибки 400 Bad Request из-за некорректного JSON.
   b) Обратите внимание: если сервер возвращает код 500 Internal Server Error, это может указывать на особенности обработки запросов сервером JSONPlaceholder.

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

Тестирование API на производительность

Если пойти дальше в автоматизации, то можно протестировать производительность. Оцените время ответа API и его эффективность при больших нагрузках. В этом поможет библиотека Locust — с её помощью можно создавать нагрузочные тесты.

Устанавливаем библиотеку и начинаем проверку производительности:

1. Создаём файл с тестовым скриптом, например performance_test.py, и добавляем следующий код:

from locust import HttpUser, task, between

class MyUser(HttpUser):
    wait_time = between(1, 3) # Интервал между запросами (в секундах)
    @task
    def perform_api_request(self):
        # Определите запрос к вашему API:
        with self.client.get('/your/api/endpoint', catch_response = True) as response:
            # Проверьте код состояния HTTP:
            if response.status_code != 200:
                response.failure("API request failed with status code {}".format(response.status_code))

2. Заменяем «/your/api/endpoint» на реальный путь к API, который вы хотите тестировать.

3. Запускаем тест с помощью команды:

locust -f performance_test.py

Открываем браузер и переходим по адресу http://localhost:8089. Здесь можно настроить параметры теста и запустить его:

Этот код создаёт пользователя, который выполняет GET-запрос к API в цикле с интервалом между запросами. Если код состояния HTTP не равен 200, это считается ошибкой. Во вкладке Failures вы найдёте отчёт об ошибках.

Убедитесь, что вы правильно настроили количество пользователей и длительность теста.

Тестирование сценариев

Посмотрите пример:

import requests
#URL вашего API
api_url = 'https://example.com/api/'

# Сценарий 1: отправка GET-запроса к ресурсу

def test_get_resource():
    response = requests.get(api_url + 'resource/1')
   
    # Проверка кода состояния HTTP
    assert response.status_code == 200
   
    # Дополнительные проверки данных, если необходимо
    data = response.json()
    assert 'id' in data
    assert 'name' in data

# Сценарий 2: отправка POST-запроса для создания ресурса

def test_create_resource():
    new_resource = {
        'name': 'New Resource',
        'description' : 'Description of the new resource'
    }

    response = requests.post(api_url + 'resource/', json = new_resource)
   
    # Проверка кода состояния HTTP
    assert response.status_code == 201 # 201 Created
   
    # Дополнительные проверки данных, если необходимо
    created_resource = response.json()
    assert 'id' in created_resource
    assert created_resource['name'] == new_resource['name']

# Вызываем сценарии тестирования
test_get_resource()
test_create_resource()

# Дополнительные сценарии могут быть добавлены по аналогии

Этот пример включает два сценария тестирования:

1. test_get_resource(): отправляет GET-запрос к ресурсу и проверяет код состояния HTTP, а также структуру данных в ответе.

2. test_create_resource(): отправляет POST-запрос для создания нового ресурса и проверяет код состояния HTTP, данные о созданном ресурсе в ответе.

Создайте дополнительные сценарии тестирования в аналогичном стиле, чтобы выяснить функциональность API. При выполнении проверок убедитесь, что API доступен и работает корректно.

Заключение

Без тестирования API не выйдет получить стабильный и безопасный продукт. Особенно если его нужно внедрять в крупные компании. В МТС Exolve мы предоставляем всестороннюю поддержку для эффективного тестирования — от полных возможностей тестирования до обширной документации по SMS API и активной помощи на нашем форуме.