Учебное пособие по тестированию REST API: примеры ручных тестовых случаев.

Что такое тестирование REST API?

Тестирование REST API Тестирование REST API — это метод автоматизированного тестирования веб-приложений с открытым исходным кодом, используемый для тестирования RESTful API. Цель тестирования REST API — зафиксировать ответы REST API путем отправки различных HTTP/S-запросов, чтобы проверить, корректно ли работает REST API. Тестирование REST API выполняется с помощью методов GET, POST, PUT и DELETE.

ОТДЫХ означает передачу представительского государства. Это архитектурный стиль и подход к общению, используемый при разработке Web-сервисыREST стал логичным выбором для создания API, поскольку позволяет пользователям эффективно подключаться к облачным сервисам и взаимодействовать с ними.

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

Например, Google Веб-сайт может иметь API для поиска, переводов и календарей. В общем, API выглядят примерно так, как в примере ниже, с именем сервера, путями и параметрами.

http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv

Но зачем вообще вкладывать усилия по тестированию на этом уровне?

Почему тестирование REST API важно

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

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

Стабильность — третья причина. Макеты постоянно меняются, но опубликованный REST-интерфейс сохраняет свою актуальность.tracОжидается, что он останется стабильным. Тесты, написанные с учетом этого фактора, подтверждают это.tracчтобы выдерживать изменения в дизайне, они защищают те части продукта, которые затем используются другими командами для дальнейшей разработки.

Типы методов API

в основном 4 вида Тестирование API Методы: GET, POST, DELETE и PUT.

• ПОЛУЧИТЬ– Метод GET используется для выполненияtracПолучайте информацию с указанного сервера, используя указанный URI. При использовании GET-запроса должна отправляться только следующая информация:tracданные t и не должны оказывать никакого другого влияния на данные.
• POST– Запрос POST используется для создания нового объекта. Его также можно использовать для отправки данных на сервер, например, информации о клиентах, загрузки файлов и т. д. с использованием HTML-форм.
• ПОЛОЖИЛ– Создайте новую сущность или обновите существующую.
• УДАЛИТЬ– Удаляет все текущие представления целевого ресурса, заданные URI.

Как протестировать REST API

Для тестирования REST API необходимо, чтобы приложение взаимодействовало с тестовым примером API. Для тестирования API вам потребуется две вещи:

• Инструмент тестирования/фреймворк для управления API
• Написание собственного кода для тестирования примера REST API.

Тестирование REST API можно проводить с помощью таких инструментов, как:

• Расширенный клиент отдыха
• Postman-Остальный клиент
• Керл в Linux

Здесь мы будем использовать Advanced Rest Client. Ниже описаны шаги для установки Advanced Rest Client.

Как получить расширенный REST-клиент?

• Перейдите на Google ChromeИнтернет-магазин 's
• Найдите «Advanced Rest Client» или перейдите напрямую. здесь и установите расширение
• Выберите значок «Расширенный клиент Rest» в разделе приложений Chrome — chrome://apps/.

Информация о товаре в интернет-магазине отображается следующим образом.

После завершения установки выполните следующие действия для проверки работоспособности. API RESTful.

Шаги по тестированию REST API

Здесь мы используем расширение REST-клиента в браузере Chrome. Для наглядности мы используем фиктивный API для тестирования:

http://ip.jsontest.com/

Шаг 1) Откройте расширенный клиент REST.

Запустите приложение Advanced REST client (ARC) после его успешной установки.

Шаг 2) Введите URL API для тестирования

Введите пример REST API URL для тестирования в URL текстовое окно.

Шаг 3) Выберите метод HTTP.

Выберите метод для типа HTTP-метода при тестировании API, например POST.

Шаг 4) Предоставьте набор заголовков

Укажите набор заголовков в текстовом поле «Заголовки». Нажмите «Вставить набор заголовков».

Шаг 5) Подтвердите набор заголовков

Далее нажмите «ИСПОЛЬЗОВАТЬ ЭТОТ НАБОР».

Шаг 6) Предоставьте необходимое содержимое тела

1. Теперь переключитесь на вкладку «Тело».
2. Установите требуемый тип содержимого тела и вид редактора, например, тип содержимого тела: application/json.
3. Вид редактора: необработанный ввод.
4. В поле «Полезная нагрузка» передайте тело запроса демонстрационного API для тестирования в виде пар ключ-значение, например, {"key1":"value1"","key2":"value2"}. Если это POST-запрос, то необходимо передать тело или параметры. Мы передадим их в указанной полезной нагрузке.

{"property" : ["Sites"], "report_type" : ["ALL"]}

⚠️ Предупреждение: Content-Type имеет значение application/json, а полезная нагрузка недопустима. JSON Возвращает ошибку 400 Bad Request.

Шаг 7) Отправьте данные, чтобы начать тест.

1. Нажмите кнопку отправки.
2. Вы можете нажать кнопку «ДЕТАЛИ», чтобы увидеть заголовки ответов.

Вот подробности ответа:

Полученный результат все равно необходимо оценивать в сравнении с ожидаемым.

Проверка результатов

В основном, при тестировании веб-API нам необходимо проверять код ответа, сообщение ответа и тело ответа.

Коды ответов делятся на пять групп:

Ниже приведены коды ответов, с которыми вы можете столкнуться.

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

Необходимо протестировать REST API.

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

• Счастливый путь: Отправьте корректный запрос на каждую конечную точку и подтвердите код состояния, схему и значение каждого поля.
• Отрицательные случаи: Отправьте некорректный JSON, неподдерживаемый метод и отсутствующий идентификатор ресурса, и ожидайте коды ошибок 400, 405 и 404 вместо 500.
• Граничные значения: Если поле принимает от 1 до 200 символов, проверьте значения 0, 1, 200 и 201. Правила проверки нарушаются на границах допустимых значений.
• Специальные символы: Чтобы выявить ошибки кодировки, пропускайте через каждое поле буквы с диакритическими знаками, эмодзи, кавычки и многобайтовый текст.
• В лице tract-проверки: Сравните полученный ответ с опубликованной спецификацией OpenAPI или Swagger, чтобы выявлять недокументированные изменения на ранней стадии.
• Последовательность действий: Вызывайте конечные точки в реалистичной последовательности, например, POST, затем GET, затем DELETE, поскольку состояние сохраняется между вызовами.
• Спокойствие и эффективность работы: Регистрируйте время отклика при каждом запуске и отмечайте любые конечные точки, которые выходят за пределы порогового значения, согласованного с командой.

Инструмент тестирования REST API

Разные инструменты подходят для разных этапов тестирования.

Смотрите подборку Инструменты тестирования API.

Большинство реальных конечных точек отказываются отвечать, пока запрос не подтвердит, кто его отправил.

Аутентификация и проверки безопасности REST API

Публичные демонстрационные конечные точки позволяют отвечать кому угодно, но рабочий REST API работает через систему аутентификации, и ошибка авторизации гораздо опаснее, чем неправильное значение поля. Сначала определите механизм: статический ключ API, учетные данные HTTP Basic, токен носителя OAuth 2.0 или подписанный JSON Web Token.

После успешного выполнения аутентифицированного запроса тщательно проанализируйте возможные сценарии сбоя:

1. Нет учетных данных: Удалите заголовок Authorization. Ожидайте ошибку 401 Unauthorized и отсутствие данных записи в теле сообщения.
2. Некорректные учетные данные: Поврежден один символ токена. Ожидайте снова ошибку 401 с сообщением, которое не объясняет причину.
3. Учетные данные устарели: Повторное использование токена после истечения срока его действия. Подтвердите, что он отклонен, а не принят, — это распространенная ошибка, связанная с расхождением во времени.
4. Неверный уровень привилегий: Необходимо выполнить аутентификацию как пользователь с низкими привилегиями и обратиться к конечной точке, доступной только администратору. Ожидается ошибка 403 Forbidden, а не 200.
5. Запись другого пользователя: Измените идентификатор таким образом, чтобы пользователь A запрашивал данные пользователя B. В этом случае успех является серьезным недостатком в системе контроля доступа.

Наконец, убедитесь, что каждый вызов передается по HTTPS и что неудачные ответы не приводят к утечке стека. tracбаннеры версий или es, а также быстрые повторы, вызывающие ошибку 429 Too Many Requests.

Тестирование REST API также сопряжено с трудностями, которых нет при тестировании интерфейсов.

Проблемы тестирования API

К числу интересных проблем, с которыми сталкиваются тестировщики при тестировании REST API, относятся:

1. Для того чтобы убедиться, что тестовая среда изменяет параметры вызовов API таким образом, чтобы проверить функциональность и выявить ошибки, она включает в себя исследование граничных условий и назначение общих параметров.
2. Создание интересных комбинаций значений параметров для вызовов с двумя и более параметрами.
3. Определение содержимого, для которого должны выполняться вызовы API. Это может включать в себя настройку внешних условий среды (периферийные устройства, файлы и т. д.), а также внутренне хранящиеся данные, влияющие на API.
4. Упорядочение вызовов API в соответствии с порядком выполнения функции.
5. Чтобы API выдавал полезные результаты из последовательных вызовов.

Часто задаваемые вопросы (FAQ)