Негативное тестирование API в Postman

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

БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"

Счастливый и несчастливый путь

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

Вот примеры счастливых путей:

  • Пользователь создает новую учетную запись
  • Пользователь входит в систему с новыми учетными данными
  • Пользователь получает информацию о своей учетной записи.

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

Вот примеры несчастливых путей:

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

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

Примечание редакции: о негативном тестировании читайте также в статье “Что такое негативное тестирование?”.

Попытка сломать нерушимый API

В этом прямом эфире вместе с моими коллегами Трентом МакКанном, менеджером по проектированию качества, и Эваном Линдси, ведущим SDET, я попытался сломать Unbreakable API. Этот API был разработан Эваном для того, чтобы продемонстрировать важность проверки вводимых данных и обработки ошибок.

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

Рекомендуемый порядок проведения тестов

Unbreakable API Lite является упрощенной версией Unbreakable API, используемого в видео “How to Break an API”. Вместо управления авторизацией для нескольких ролей, роль admin удаляется, а employee переименовывается в user. В Unbreakable API Lite, создав пользователя и установив возвращаемый токен, вы получите доступ ко всем доступным эндпоинтам.

Сборник Testing Flow for Lite включает примеры положительных и отрицательных сценариев тестирования для API, на которые ссылается Unbreakable API Lite. Для инженеров  Testing Flow for Lite может стать руководством по валидации ввода и обработке ошибок. А для тестировщиков это может стать рецептом для написания тестов.

  1. Форк коллекции. Форк коллекции Testing Flow for Lite в свою рабочую область. Возможно, потребуется включить публичный профиль, если вы этого еще не сделали.
  2. Создание нового пользователя. Найдите запрос “User create”  и обновите значения на закладке Body в нем. Нажмите кнопку Send для создания нового пользователя, а также установите переменную коллекции userToken, которая может быть использована в последующих вызовах.
  3. Просмотр коллекции. Изучите положительные и отрицательные сценарии тестирования, описанные в оставшихся папках. На вкладке Авторизация обратите внимание на метод авторизации, используемый для каждого запроса. На вкладках Pre-request Script и Tests обратите внимание на код, который выполняется до и после отправки каждого запроса.
  4. Автоматический запуск коллекции. Эту коллекцию можно также запустить для автоматизации процесса тестирования. Для этого используется Runner в Postman, Newman из командной строки, или Monitors на серверах Postman. Не забудьте создать нового уникального пользователя по запросу “User create”, прежде чем запускать коллекцию целиком.

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

Примеры в папке Positive в Testing Flow for Lite описывают сценарии счастливого пути:

  • Извлечь все фильмы
  • Создать новый фильм
  • Получить фильм по идентификатору

Для позитивных тестовых случаев вы пишете тест, ожидающий успешный ответ, например, получение 200 OK или аналогичного статуса HTTP-ответа. Если в этих утверждениях есть ошибки, тест должен быть провален. Например, чтобы протестировать конечную точку создания пользователем нового фильма, напишите тест Postman и утверждение следующего вида:

pm.test("Status code is 200", function () {
  pm.response.to.have.status(200);
});

Примеры в папке Negative описывают сценарии несчастливого пути:

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

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

Например, что произойдет, если пользователь создаст новый фильм и отправит недействительный токен авторизации? Мы ожидаем, что сервер вернет 401 Unauthorized или аналогичный код HTTP-ответа. Чтобы протестировать этот случай, отправьте токен, который, как вы знаете, является недействительным, и напишите тест Postman и утверждение следующего вида:

pm.test("Status code is 401", function () {
  pm.response.to.have.status(401);
});

Важность негативного тестирования

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

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

Перевод статьи «Negative testing for more resilient APIs».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *