Вводный гайд по тестированию API для новичков

В чем заключается тестирование API
Терминология тестирования веб-сервисов
Что такое HTTP
Что такое REST API
Как писать тест-кейсы
Распространенные проблемы

В чем заключается тестирование API

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

Тестирование API позволяет пользователю тестировать “безголовые” технологии, такие как JMS, базы данных HTTP и веб-сервисы.

Например, бизнес-логика многих современных веб-приложений хранится в API бэкенда. При взаимодействии с фронтендом происходит обращение к этим микросервисам.

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

Что такое “безголовое” тестирование

Большинство “безголовых” тестов состоит в том, чтобы, минуя графический интерфейс, отправить запрос непосредственно в бэкэнд или сервис приложения и получить ответ, валидируя его, чтобы убедиться, что все работает так, как ожидается.

Приведенный выше пример часто называют отношением клиент/сервер. Клиент делает запрос, запрашивая ресурс, и этот запрос отправляется на поиск сервера, который выполнит запрос. Сервер находит нужный ресурс и отправляет ответ клиенту.

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

После того как Agile-разработка стала стандартом в большинстве компаний, способы разработки ПО и автоматизации тестов кардинально изменились.

До Agile большая часть времени, потраченного на автоматизацию QA, приходилась на тесты интерфейса (GUI). Например в Selenium или UFT/QTP.

Но если вы занимались QA-автоматизацией сколько-нибудь долго, то знаете, насколько трудоемки, хрупки и сложны в обслуживании тесты интерфейса.

Написаны целые книги о том, как компании вкладывали большие деньги в создание кастомных функциональных фреймворков автоматизации GUI-тестирования, но со временем разочаровывались в их надежности; доходило до того, что они вообще переставали ими пользоваться, и их фреймворк превращался в систему «для галочки».

Кроме того, GUI-тесты обычно требуют весьма много времени для выполнения. Для некоторых Agile-практик, таких как непрерывные сборки, когда постоянно проверяется новый код, количество времени, необходимое для получения обратной связи от набора регрессионных GUI-тестов, является неприемлемым.

Решение проблемы: тесты API

Частое выполнение API-тестов в рамках процессов DevOps или конвейеров CI/CD позволяет командам разработчиков оптимизировать циклы релиза и сосредоточиться на главных аспектах разработки.

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

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

Одним из преимуществ является быстрая обратная связь.

Быстрая обратная связь API

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

Поймите меня неправильно — тестирование UI по-прежнему очень важно; это единственный тип тестов, который реально проверяет, как пользователь будет работать с готовым приложением. Некоторые дефекты могут быть обнаружены только с помощью GUI-тестов. Но несмотря на свою важность, тесты GUI не должны быть единственными, и не должны быть решающими.

Известные проблемы с GUI-тестами со временем создали QA-автоматизации в целом репутацию ненадежной и дорогой. Сейчас вы, возможно, думаете: но разве автоматизация не является практикой Agile? Следует знать, что автоматизация, на которой сосредоточен Agile — это юнит-тестирование (плюс “низкоуровневое” тестирование API), и в гораздо меньшей меньшей степени тесты GUI.

Пирамида тестирования API

В своей книге Agile: Software Development Using Scrum автор Майк Кон ввел понятие пирамиды автоматизации тестирования:

Это изображение представляет собой противоположность тому, как большинство не-Agile команд проводят автоматизированное тестирование.

Что такое GUI-тест

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

Что такое юнит-тест

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

Что такое API-тест

Средний уровень сервиса — это та самая «сладкая точка», для которой были созданы такие инструменты, как Rest-Assured и Postman.

Тестирование сервисов также известно как интеграционное тестирование. Интеграционное тестирование направлено на проверку того, что множество компонентов продукта может быть интегрировано без проблем. Поскольку API-тесты обходятся без пользовательского интерфейса, они быстрее и надежнее GUI-тестов.

А главное — поскольку API-тесты не зависят от пользовательского интерфейса, их можно создавать на ранних этапах цикла разработки. (Бонус: API-тесты — как я попытаюсь продемонстрировать на примере в этом руководстве — на самом деле гораздо проще создавать, чем GUI-тесты!)

Что такое нагрузочное тестирование API

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

Когда я разговаривал с представителями BlazeMeter, они упомянули, что значительная часть их клиентов использует JMeter для нагрузочных тестов, в которых участвует ровно один пользователь и, возможно, даже одна итерация.

Это дало им идею создать то, что они называют функциональным тестированием API. Идея заключается в том, что вы проводите тестирование производительности с помощью такого сервиса, как BlazeMeter, но перед запуском, например, большого нагрузочного теста на API вы хотите убедиться, что он действительно работает. Поэтому вы сначала проводите функциональные тесты, а затем тесты производительности.

Поэтому API-тесты — большой плюс в процессе тестирования производительности.

Вот пример использования LoadRunner для тестирования веб-сервиса:

Как автоматизировать тестирование API?

Начните с изучения специализированных инструментов, таких как Postman, Insomnia или Swagger. Эти инструменты предоставляют удобные интерфейсы для создания и управления тест-кейсами API. Выбрав инструмент, начните с описания конечных точек API, параметров запросов и ожидаемых ответов.

Затем интегрируйте тестовые сценарии во фреймворк автоматизированного тестирования. Используя такие фреймворки, как Selenium, Robot Framework или JUnit, вы можете планировать и выполнять тесты API автоматически. Такая автоматизация экономит время и обеспечивает выполнение тестов на разных стадиях разработки.

Наконец, не забывайте регулярно обновлять тестовые сценарии, чтобы не отставать от изменений в API.

Как выбрать инструмент для тестирования API

Существует множество инструментов. Много раз я получал вопрос от тестировщиков, могут ли они использовать Selenium для тестирования API.

Ответ — нет. Selenium предназначен только для браузерного тестирования. Какой инструмент использовать для тестирования Rest и Soap веб-сервисов? Полный список замечательных инструментов для тестирования API смотрите в посте 20 Open Source API Testing Tools For REST & SOAP Services.

Как тестировать веб-сервисы

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

Вопросы, которые стоит задать при автоматизации веб-сервиса:

Выдает ли сервис правильные значения?
Соответствует ли поведение сервиса требованиям конечного пользователя?
Как быстро сервис отправляет ответ пользователю?
Может ли сервис справиться с ожидаемой и неожиданной нагрузкой?
Может ли сервис справиться с некорректными значениями и исключениями, вызванными некорректными данными?

Терминология тестирования веб-сервисов

Самым большим препятствием для большинства тестировщиков является терминология веб-сервисов.

Например:

Что такое XML

XML — это язык разметки, с помощью которого вы можете определять собственные теги. XML позволяет обмениваться структурированными данными с многочисленными системами через Интернет.

Что такое WSDL

WSDL — это формат XML, в котором указывается, как получить доступ к веб-службе. (Большинство инструментов тестирования читают WSDL и представляют всю информацию, необходимую для взаимодействия с ним).

Что такое SOAP

SOAP (Simple Object Access Protocol) — это протокол, использующий формат XML для обмена информацией с веб-сервисом.

Что такое SOA

SOA (Service-oriented Architecture) — это архитектура, ориентированная на быстрые изменения в соответствии с требованиями рынка.

Веб-сервисы

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

Что такое REST и Restful API

REST (Representational State of Transfer) — это облегченный вариант разработки веб-сервиса, который использует протокол HTTP, что делает его более простым и дешевым, чем веб-сервис, использующий протокол SOAP.

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

Итак, давайте рассмотрим вызов простого веб-сервиса SOAP на сайте webexerviceX.net.

Как создать тест веб-сервиса SOAP

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

Спецификация W3C по WSDL описывает его следующим образом: «WSDL — это XML-формат для описания сетевых сервисов как набора конечных точек, работающих с сообщениями, содержащими либо ориентированную на документы, либо ориентированную на процедуры информацию«.

В этом примере мы будем использовать WSDL веб-сервиса HolidayWebservice, предоставленный сайтом holidaywebservice.com, который позволит нам легко найти, в каких странах какие праздники отмечаются.

Для этого первого урока тестирования API мы будем использовать онлайн-приложение для вызова нашего веб-сервиса.

Перейдите по адресу https://wsdlbrowser.com/
В WSDL URL введите: http://www.holidaywebservice.com//HolidayService_v2/HolidayService2.asmx?wsdl
В разделе функций выберите GetHolidaysAvailable
В разделе Request, XML измените <countryCode> с Array на Scotland
Нажмите кнопку Call function
Результаты ответа должны вернуть:

Что такое API WSDL Response

Наш веб-сервис HolidayWebservice представляет собой наиболее типичный вид: клиент (в данном случае наш тестовый инструмент) отправляет запрос сервису и ждет. Затем служба обрабатывает запрос и отправляет ответ.

Вы можете спросить: «Как происходит это взаимодействие?»

В основном SOAP — который представляет собой протокол на основе XML, используемый для связи с веб-службой — отправляет информацию на запрос с помощью протокола HTTP. Если мы посмотрим на ответ, который мы получили в нашем тесте, то увидим такие элементы SOAP, как SOAP Envelope, Header и Body.

Как проверить WSDL-ответ

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

Например, вот как это можно сделать с помощью SOAP UI. Хотя видео и старое, оно должно дать вам представление о том, как проверить WSDL-ответ. В терминологии SoapUI это называется утверждением (ассертом).

Элементы сообщений SOAP

XML-сообщение SOAP состоит из трех элементов:

1) SOAP Envelope — SOAP Envelope всегда является верхним элементом сообщения.

2) Header — Header является необязательным и первым дочерним элементом, который появляется после envelope. Заголовки могут содержать различные типы специфической для приложения информации, например, информацию об аутентификации безопасности или управлении сеансами.

3) Body — иногда называемое “полезной нагрузкой” (payload), тело содержит собственно сообщение, в котором отображается информация для получателя сообщения. UFT Results Viewer всегда показывает SOAP XML ответ, который был возвращен из веб-сервиса. Если вы хотите узнать больше, W3C.org содержит подробный документ спецификации Simple Object Access Protocol 1.1

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

Что такое HTTP

HTTP — это коммуникационный протокол, передающий сообщения по сети. HTTP также известен как stateless-протокол (без сохранения состояний), поскольку каждый запрос, который он делает, не зависит от всех предыдущих запросов.

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

Понимание HTTP даст нам хорошую основу для понимания большинства функций инструментов тестирования API. Для следующих нескольких примеров мы будем использовать бесплатный REST-клиент Insomnia. Следуйте простым инструкциям по установке https://insomnia.rest/download/.

Как сделать HTTP-запрос и создать автоматизированный тест

В Insomnia выберите опцию New Request (Новый запрос)
Назовите запрос HTTPDemo и выберите опцию GET
В поле GET введите: https://testguild.com
Нажмите кнопку отправки
Запрос должен вернуть код состояния 200 OK.

Чтобы просмотреть исходные данные, перейдите на вкладку «Timeline».

Что такое HTTP-запросы

Клиентские HTTP-запросы состоят из трех основных частей. К ним относятся:

1) Строка запроса (HTTP Method) — она сообщает серверу, какой тип запроса выполняется. В приведенном выше примере мы сделали запрос GET, но существует множество других методов, которые вы можете использовать в зависимости от типа запроса, который вам нужно сделать. Метод HTTP имеет следующие варианты (первые четыре метода являются наиболее распространенными):

HTTP-методы	Значение
GET	получение данных из указанного источника
POST	отправка новых данных в указанный источник
PUT	обновление информации для указанного источника
DELETE	удаление данных из указанного источника
TRACE	просит прокси объявить о себе
OPTIONS	запрос информации об опциях, доступных на сервере
HEAD	аналогичен запросу GET, но только отправляет информацию о документе
CONNECT	используется, когда клиент должен использовать HTTPS-сервер

2) Header — содержит дополнительную информацию для отправки на сервер, такую как информация о Browser, OS, Accept и Cookie. Различные типы заголовков:

General — необязательный заголовок, содержащий такую информацию, как текущее время.
Request — предоставляет серверу дополнительную информацию о клиенте.
Entity — содержит конкретную информацию об отправляемом документе, например длину и схемы кодировки.

3) Body — содержит данные для использования в методах, которые этого требуют, например в методе PUT. Метод GET, как видно из нашего примера, пуст.

Ответ, возвращенный сервером, также содержит три раздела, как и в случае с HTTP-запросом:

Строка ответа (код состояния)
Информация о заголовке
Тело, содержащее весь текст ответа

Коды состояния HTTP

В нашем примере код состояния был равен 200, что означает, что все в порядке. Код состояния зависит от того, что произошло с исходным запросом.

Коды состояния, которые могут быть возвращены сервером:

1xx — ответы в диапазоне 100-199 означают, что сервер работает над запросом.
2xx — Ответы в диапазоне 200-299 означают, что запрос был успешным.
3xx — Ответы в диапазоне 300-399 означают, что запрос не был выполнен — необходимы дальнейшие действия.
4xx — Ответы в диапазоне 400-499 означают, что запрос был неполным и может потребоваться дополнительная информация.
5xx — Ответы в диапазоне 500-599 означают, что сервер столкнулся с ошибкой.

Как протестировать ошибки при тестировании API

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

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

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

Что такое REST API

REST (Representational State of Transfer) — это облегченный вариант разработки веб-сервисов, использующих протокол HTTP, что делает его более простым и менее накладным, чем веб-сервис, использующий протокол SOAP.

Когда API следует архитектуре REST, он называется REST API. Когда сервис разрабатывается на основе стандарта REST, говорят, что это делает сервис «RESTful». Основные требования к веб-сервису, чтобы считаться RESTful, заключаются в том, что он должен:

Иметь отдельный клиент и сервер
Использовать HTTP
Быть статичным

REST API состоит из набора ресурсов; это называется моделью ресурсов и использует унифицированные идентификаторы ресурсов (URI). Синтаксис URI позволяет задать запрос, который возвращает нужную вам информацию из REST API.

Основными элементами системы REST являются:

Ресурсы — это запрос от клиента о том, что он хочет получить от хоста — например, веб-страницу или запись в базе данных.
Идентификатор ресурса — это URI, который называет ресурс.
Представления — это когда сервер отправляет ответ с ресурсом в готовом формате.

Тестирование REST API

Для нашего примера REST-теста я буду использовать классный Star Wars REST API от swapi.co.

Создайте новый проект в Insomnia,
Назовите его RestDemo и выберите тип GET
В поле GET введите: https://swapi.co/api/people/10 Нажмите Отправить

В панели предварительного просмотра обратите внимание, что вместо представления сайта, которое мы имели в нашем примере HTTP, мы получаем JSON.

Результаты работы с API Star Wars могут показаться вам странными. До сих пор мы работали только с сервисами, возвращающими XML; теперь мы впервые посмотрим, каково это — работать с сервисом, возвращающим JSON.

Может быть, дело во мне, но каждый раз, когда я слышу слово JSON, вместо того чтобы наслаждаться чувством покоя, в моей голове возникает ужасающий образ Джейсона из фильма ужасов «Пятница, 13-е«.

Но на самом деле JSON — это просто еще одна безобидная технологическая аббревиатура, и вскоре вы увидите, что бояться ее не стоит :).

Как писать тест-кейсы для тестирования API

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

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

Подробно опишите конкретные параметры запроса, которые должны быть включены в тест-кейс, а также вызываемый метод API и ожидаемый ответ от API.

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

Что такое JSON?

JSON расшифровывается как JavaScript Object Notation, стандарт был разработан как легкий формат обмена данными. JSON определенно становится все более популярным и теперь заменяет XML в некоторых ситуациях для обмена данными API. На сайте www.json.org описано, как JSON строится на двух структурах:

Коллекция пар имя/значение. В различных языках это реализуется как объект, запись, структура, словарь, хэш-таблица, список с ключами или ассоциативный массив.
Упорядоченный список значений. В большинстве языков реализуется как массив, вектор, список или последовательность».

Итак, мы рассмотрели, как выполнить стандартный GET. Далее давайте рассмотрим, как использовать REST для отправки данных с помощью JSON.

Как валидировать REST API-тест

Как мы уже говорили ранее, существует множество способов проверить REST-ответ. Все зависит от того, какой инструмент тестирования вы используете. Кроме того, выбор инструментов может варьироваться от просто библиотек, используемых в языке программирования, таких как rest-assured для java, до полноценных инструментов тестирования API от специализированных вендоров, таких как Microfocus UFT API.

Например, вот как можно создать тест REST API, используя решение с открытым исходным кодом, такое как SOAP UI.

Вот пример тестирования REST API с помощью Karate с использованием BDD-подхода.

Для более “программного” способа тестирования REST-ful веб-сервисов здесь приведен пример с использованием rest-assured. Rest-assured — это открытая библиотека Java, которую можно использовать для тестирования REST-сервисов на основе HTTP. Она была разработана специально для тестирования.

Наши туториалы:

Распространенные проблемы при тестировании API

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

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

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

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

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

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

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

TestGuild/Joe Collantonio

По теме:

Практикум по тестированию API в Playwright/Java (все части)

REST Assured: большой гайд