Тестирование API
Тестирование API простыми словами: что такое API и что проверяет тестировщик
API (программный интерфейс приложения) – это правила, по которым одна программа обращается к другой: какие запросы можно отправить, какие данные передать и что вернётся в ответ. Тестировщик API отправляет эти запросы напрямую, без экрана приложения, обычно в Postman, и сверяет статус-код, тело ответа и текст ошибок с документацией. Так проверяется серверная часть, до которой проверки через интерфейс не добираются.
- Контракт
- API описывает, как к программе можно обращаться
- Раньше экрана
- API часто готов, пока интерфейс ещё в разработке
- Бесплатно
- урок с заданиями в моём базовом курсе
Что такое API простыми словами
API (application programming interface, программный интерфейс приложения) – это способ взаимодействия одной системы с другой. Пример: оплата на сайте авиакомпании или интернет-магазина проходит через API платёжной системы. Сайт отправляет ей запрос и получает ответ, прошёл ли платёж.
API часто называют контрактом. Между программами заранее договариваются, как к каждой из них можно обращаться, и для тестировщика этот договор служит требованиями: по нему видно, что должен принять сервер и что он обязан вернуть.
API бывает локальным и удалённым. Через локальный общаются компоненты одной программы, например приложение на телефоне с камерой или телефонной книгой. Удалённый связывает разные системы по сети, и когда говорят о тестировании API, обычно имеют в виду его: веб-сервисы на SOAP или REST, реже GraphQL, gRPC и WebSocket. Сайт-агрегатор авиабилетов через такие API собирает рейсы разных авиакомпаний на одной странице.
Как устроен вызов API
Вызов API состоит из трёх частей: операции, которую нужно выполнить, входных данных и выходных данных, которые программа возвращает после обработки. В веб-сервисах операция соответствует HTTP-методу (GET получает информацию с сервера, POST отправляет её на сервер). Входным данным соответствует запрос, выходным – ответ с телом, статус-кодом или сообщением об ошибке.
Под каждую функцию разработчик пишет свой метод API: регистрацию, изменение профиля, поиск, удаление. Методов бывает очень много, и каждый тестируется отдельно.
Я выделяю четыре способа вызвать API, из них три прямых и один косвенный.
Программа вызывает свою же функцию
Это локальный API, через который общаются компоненты одной системы. Логику здесь закладывает разработчик, и тестировщик такие вызовы обычно не проверяет.
Одна система вызывает метод другой
Самый частый случай в работе тестировщика API. Сайт-агрегатор туристических путёвок обращается к платёжной системе, и проверяется как раз интерфейс между ними.
Человек вызывает метод сам
Например, когда в систему нужно залить много тестовых данных. Вместо того чтобы долго вводить их через интерфейс, тестировщик отправляет POST-запрос в Postman, и данные сразу попадают в нужные поля.
Интерфейс вызывает API за пользователя
Это косвенный вызов. Пользователь заполняет отчёт, нажимает кнопку, и что происходит дальше, его не интересует. Под капотом кнопка отправляет запрос, чаще всего POST, к тому же API.
Зачем тестировать API, если есть интерфейс
Экран показывает только то, что пропускает клиент, то есть браузер или мобильное приложение. Пример из моего урока о Postman: в поле логина нельзя ввести больше символов, чем разрешено, но ограничение часто задано атрибутом maxlength в HTML. Его можно стереть в инструментах разработчика браузера и отправить на сервер слишком длинный логин. Поэтому та же проверка нужна и на сервере, а иногда и в базе данных, и тестировщик убеждается, что она срабатывает на каждом уровне.
Через интерфейс до многих ошибок сервера не добраться. Экран не даст отправить пустое обязательное поле или число вместо строки, а запрос из Postman уйдёт с любыми данными. Так же в обход интерфейса действует злоумышленник, поэтому проверки на сервере должны совпадать с проверками на экране.
Типичный пример из интернет-магазина: при оформлении заказа приложение отправляет запрос, где рядом с товаром передаётся его цена. Тестировщик повторяет запрос в Postman с ценой 1 рубль и проверяет, что сервер берёт цену из своего каталога или отклоняет запрос. Если заказ создан за рубль, это критический дефект, и через экран его не найти.
API нередко готов раньше графического интерфейса, и тестировать его можно, пока фронтенд-разработчик ещё занят экраном, вместо того чтобы ждать сборку.
В программе ISTQB Foundation Level API назван среди типичных объектов интеграционного тестирования. Глоссарий ISTQB определяет тестирование API как проверку, при которой команды отправляются тестируемой программе напрямую через её программные интерфейсы.
Что проверяет тестировщик API
Работа строится так же, как с любой другой функцией. Сначала изучают требования, то есть документацию API: методы, обязательные и необязательные параметры, примеры запросов и ответов. Если документации нет, начинают с разговора с разработчиком и просят у него примеры. Затем по требованиям с помощью техник тест-дизайна пишут проверки и проходят их в Postman или SoapUI.
Тесты для API делят по глубине так же, как остальные. Смоук – это один корректный запрос на метод. Тест критического пути охватывает все корректные запросы, а расширенный тест проверяет некорректные. Дальше идут проверки, характерные именно для веб-сервисов.
Результат запроса стоит увидеть и в самой системе. В уроке о SoapUI и Postman я регистрирую пользователя запросом, нахожу его в списке пользователей и вхожу под его паролем, и только после этого считаю проверку пройденной.
Обязательные и необязательные параметры
Без обязательного параметра сервер должен вернуть ошибку. Без необязательного запрос проходит, если так написано в требованиях.
Пустые и недопустимые значения
Пустые строки, лишние параметры, которых нет в документации, слишком длинные строки и числа.
Другой тип данных
Число вместо строки, строка вместо числа, true вместо текста. Если у параметра в документации числовой тип, а пришли буквы, сервер обязан отказать.
Дубли и порядок
Один и тот же атрибут несколько раз в запросе и нарушенный порядок атрибутов там, где он задан.
Синтаксис и код в данных
Запрос с ошибкой в JSON или XML и комментарии внутри них. Сервер должен вернуть понятную ошибку и не исполнять присланное как код.
Ответ
Статус-код, тело ответа и текст ошибки сверяют с документацией и со схемой, если она есть. Расхождение – это дефект, и к баг-репорту прикладывают JSON запроса и ответа.
Пример: проверки одного метода
Ниже проверки из моего урока о Swagger и Postman. Учебный API Petstore ищет питомцев по статусу: GET-запрос к адресу /pet/findByStatus с параметром status, который по документации обязателен и принимает значения available, pending и sold.
status=available
Ожидаемый результат: 200 OK, в теле только питомцы со статусом available. Тело сверяют с примером ответа в документации.
Несуществующий статус
По документации сервер должен вернуть 400. В уроке пришёл 200 OK, и это дефект: стороннему приложению, которое подключится к API, будет трудно понять, что пошло не так.
Число или true вместо строки
В строке запроса это тоже просто текст, которого нет среди available, pending и sold, поэтому ожидается та же ошибка 400. Ответ 200 тоже заводят дефектом.
Без параметра status
Параметр обязательный, значит, нужна ошибка с понятным сообщением. Если сервер молча ничего не вернул, это дефект.
POST /pet без тела
Создание питомца без тела запроса вернуло 415 Unsupported Media Type. Это правильное поведение, ведь обязательное тело не передано.
POST /pet с телом из примера
Питомец создан, в ответе новый идентификатор. Сервер ответил 200, хотя для создания принято возвращать 201 Created. Я отношу это к предложениям по улучшению: дефектом такой ответ не считается, но команде о нём стоит сказать.
Видеоурок, шпаргалка и задания
Я объясняю API простыми словами в отдельном восьмиминутном ролике на YouTube, а инструменты показываю в 18-м уроке курса "Тестировщик с нуля" о Postman и SoapUI. В бесплатном базовом курсе по тестированию тема идёт уроком "Что такое API простыми словами?", и после теории в нём есть задания.
Шпаргалка по API собирает на одной странице REST, SOAP и признаки, по которым в проекте выбирают протокол. В тренажёре запросы уходят на настоящий сервер учебной песочницы, и под каждую задачу нужно подобрать метод, адрес и тело запроса.
Курсы по теме
Вопросы и ответы
Что такое API простыми словами?
Это способ, которым одна программа обращается к другой: правила о том, какие запросы можно отправить, какие данные передать и что вернётся в ответ. Через API сайт интернет-магазина проводит оплату в платёжной системе, а приложение на телефоне получает данные с сервера.
Что делает тестировщик API?
Изучает документацию API, пишет по ней позитивные и негативные проверки и отправляет запросы напрямую, без интерфейса, обычно в Postman. Статус-код, тело ответа и текст ошибок он сверяет с документацией, а расхождения оформляет баг-репортами с приложенным запросом и ответом.
Чем тестирование API отличается от тестирования через интерфейс?
Через интерфейс проверяют то, что видит пользователь, и экран сам не даёт отправить многие неверные данные. При тестировании API запросы уходят на сервер напрямую, поэтому видно, как сервер обрабатывает любые данные, включая те, что экран не пропустил бы. Обычно проверяют и то и другое, потому что поведение должно совпадать.
Какие бывают API?
По месту работы API делят на локальные, через которые общаются компоненты одной программы, и удалённые, которые связывают разные системы по сети. Среди удалённых чаще всего встречаются REST и SOAP, есть также GraphQL, gRPC и WebSocket. На собеседовании полезно назвать оба деления: ответ из одних SOAP и REST выглядит неполным.
Нужно ли уметь программировать, чтобы тестировать API?
Для ручного тестирования API не нужно. Запросы собираются в Postman мышкой, а простые проверки статус-кода и тела ответа берутся из готовых заготовок. Код понадобится позже, когда дело дойдёт до цепочек запросов и автотестов.
Какими инструментами тестируют API?
Для REST чаще всего используют Postman, для SOAP – SoapUI, которому достаточно ссылки на WSDL, чтобы подтянуть все методы сервиса. Документацию и пробные запросы даёт Swagger, а запросы, которые отправляет сам сайт, видны во вкладке Network инструментов разработчика браузера.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.