Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- Инструкция по тестированию 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.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement