В этой статье мы узнаем почему намеренные попытки сломать что-то повышают устойчивость ваших приложений. Мы также рассмотрим некоторые распространенные негативные сценарии тестирования и приведем примеры для негативных тестов в 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 может стать руководством по валидации ввода и обработке ошибок. А для тестировщиков это может стать рецептом для написания тестов.
- Форк коллекции. Форк коллекции
Testing Flow for Liteв свою рабочую область. Возможно, потребуется включить публичный профиль, если вы этого еще не сделали. - Создание нового пользователя. Найдите запрос “User create” и обновите значения на закладке Body в нем. Нажмите кнопку Send для создания нового пользователя, а также установите переменную коллекции
userToken, которая может быть использована в последующих вызовах. - Просмотр коллекции. Изучите положительные и отрицательные сценарии тестирования, описанные в оставшихся папках. На вкладке Авторизация обратите внимание на метод авторизации, используемый для каждого запроса. На вкладках Pre-request Script и Tests обратите внимание на код, который выполняется до и после отправки каждого запроса.
- Автоматический запуск коллекции. Эту коллекцию можно также запустить для автоматизации процесса тестирования. Для этого используется 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».