Инструкция по тестированию API для бэкэнд разработчиков

Подготовка и установка Postman

Для работы с postman необходимо установить postman локально (https://www.postman.com/)
Предварительно необходимо установить Node.js(https://nodejs.org/ru/) и менеджер пакетов ноды NPM который устанавливается вместе с нодой.
Так же в комплекте с postman идет cli утилита newman которая позволяет локально удобно прогонять все тесты. Для установки newman
печатаем в консоли npm install -g newman .
Создаем в корне проекта фолдер postman для коллекции и env переменных внутри. Пример фолдера можно посмотреть в проекте dbo/dbo-api.
Открываем и экспортим коллекцию в постман вместе с env файлом.
При добавлении теста для существующего запроса в коллекцию или прочем изменении коллекции импортим измененную коллекцию в папку postman.
И запускаем тесты. Запускать тесты можно в десктоп версии по одному либо все вместе в консоли или postman runner.
Чтобы запустить все реквесты в консоли нужно выполнить newman run "DBO API part 1 backup.postman_collection.json" -e "DBO-API STAGE.postman_environment.json" (имена коллекции
и environment файла могут отличаться).

Правила написания хороших тестов и тестирования нашего API

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

Основными задачами в функциональном тестировании API являются:

Убедиться, что реализация работает правильно, как и ожидалось - никаких ошибок!
Убедиться, что реализация работает так, как указано в соответствии со спецификацией требований (которая позже становится нашей документацией API).
Предотвратить регрессию между слиянием и выпуском кода.

Тестовые действия API
Каждый тест состоит из тестовых действий. Это отдельные действия, которые необходимо выполнить тесту в каждом потоке тестирования API. Для каждого запроса API тест должен выполнить следующие действия:

1. Проверьте правильный код статуса HTTP. Например, создание ресурса должно возвращать 201 CREATED, а незапущенные запросы должны возвращать 403 FORBIDDEN и т. Д.

2. Проверьте ответную нагрузку. Проверьте правильное тело JSON и правильные имена полей, типы и значения - в том числе в ответах об ошибках.

3. Проверьте заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.

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

5. Проверьте основные показатели работоспособности. Если операция была успешно завершена, но заняла неоправданно много времени, тест не пройден.

Категории тестовых сценариев

Наши тестовые примеры подразделяются на следующие общие группы сценариев тестирования :

Основные позитивное тесты (positive tests)
Расширенное позитивное тестирование с дополнительными параметрами
Негативное тестирование с правильным вводом (negative tests)
Негативное тестирование с неверным вводом
Разрушительное испытание
Тесты безопасности, авторизации и разрешений (которые выходят за рамки этого поста)
Позитивные тесты проверяют базовую функциональность и критерии приемлемости API.
Позже мы расширим позитивное тесты, чтобы включить дополнительные параметры и дополнительную функциональность.
Следующая группа тестов - это негативное тестирование, где мы ожидаем, что приложение будет корректно обрабатывать проблемные сценарии как с допустимым пользовательским вводом (например, при попытке добавить существующее имя пользователя), так и с недопустимым пользовательским вводом (при попытке добавить имя пользователя, которое является нулевым).
Деструктивное тестирование - это более глубокая форма негативного тестирования, когда мы намеренно пытаемся сломать API, чтобы проверить его надежность (например, отправка огромного тела полезной нагрузки в попытке переполнить систему).



Виды тестовых сценариев:


1.	Основные позитивные тесты

Выполнить вызов API с допустимыми обязательными параметрами.
Проверить код состояния:
1. Все запросы должны возвращать код состояния HTTP 2XX.
2. Возвращаемый код состояния соответствует спецификации:
- 200 OK для запросов GET
- 201 для запросов POST или PUT, создающих новый ресурс
- 200, 202 или 204 для операции DELETE и т. Д. на
3. Проверить полезную нагрузку:
    1. Ответ является правильно сформированным объектом JSON.
    2. Структура ответа соответствует модели данных (проверка схемы: имена полей и типы полей соответствуют ожидаемым, включая вложенные объекты; значения полей соответствуют ожидаемым; ненулевые поля не равны нулю, и т.д.)

4. Проверить заголовки:
Убедитесь, что заголовки HTTP соответствуют ожидаемым, включая тип контента, соединение, управление кэшем, срок действия, время
доступа, контроль доступа, происхождение, keep-alive, HSTS и другие стандартные поля заголовков - согласно спецификации.
Убедитесь, что информация НЕ пропускается через заголовки (например, заголовок X-Powered-By не отправляется пользователю).

5. Минимальные требования к производительности: Ответ получен своевременно (в пределах разумного ожидаемого времени) - как определено в плане тестирования.

Позитивные тесты и необязательные параметры	:

Выполнить вызов API с допустимыми обязательными параметрами и допустимыми необязательными параметрами.
Выполнить те же тесты, что и в # 1, на этот раз, включая необязательные параметры конечной точки (например, фильтр, сортировка, ограничение, пропуск и т. Д.)

Кроме того, проверьте следующие параметры:
- фильтр: убедитесь, что ответ фильтруется по указанному значению.
- сортировать: указать поле для сортировки, проверить параметры возрастания и убывания. Убедитесь, что ответ отсортирован в соответствии с выбранным полем и направлением сортировки.
- пропустить: убедиться, что указанное количество результатов от начала набора данных пропущено
- предел: убедиться, что размер набора данных ограничен указанным пределом.
- limit + skip: тестовая нумерация страниц.

Проверьте комбинации всех необязательных полей (поля + sort + limit + skip) и проверьте ожидаемый ответ.



2.	Отрицательное тестирование
Выполните вызовы API с допустимым вводом, который пытается недопустимые операции. т.е.:
- Попытка создать ресурс с именем, которое уже существует (например, пользовательская конфигурация с тем же именем).
- Попытка удалить ресурс, который не существует (например, пользовательская конфигурация без такого идентификатора).
- Попытка обновить ресурс с недопустимыми действительными данными (например, переименование конфигурации в существующее имя).
- Попытка недопустимой операции (например, удаление конфигурации пользователя без разрешения).
И так далее.

Проверить код состояния:
    1. Убедитесь, что отправляется ошибочный код состояния HTTP (НЕ 2XX).
    2. Убедитесь, что код состояния HTTP соответствует регистру ошибки, как определено в спецификации.

Проверить пэйлоад:
    1. Убедитесь, что получен ответ об ошибке.
    2. Убедитесь, что формат ошибки соответствует спецификации. например, error является допустимым объектом JSON или простой строкой (как определено в спецификации)
    3. Убедитесь, что имеется четкое, описательное поле сообщения об ошибке / описания
    4. Убедитесь, что описание ошибки является правильным для этого случая ошибки и в соответствии со спецификацией

Проверить заголовки: Как в п.1
Минимальные требования к производительности: Ответ получен своевременно (в пределах разумного ожидаемого времени) - как определено в плане тестирования.


Исходя из расписанного выше плана тестирования хорошей практикой является создание для каждого эндпоинта двух запросов и соотственно двух тестов(позитивного и негативного)
в которых исчерпывающе проверяется работа API.