Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

От шока до принятия: пять стадий тестирования API

Привет, я Сергей Могилевский, QA Engineer в NIX. Уже пять лет занимаюсь тестированием. Постоянно учусь сам и обучаю других. Сейчас — тимлид на проекте. Решаю самые сложные технические задачи и занимаюсь менеджментом подопечных. Делюсь опытом на внутренних тренингах и конференциях. На NIX MultiConf выступал трижды.

Хочу рассказать о важности тестирования API. Засилье микросервисной архитектуры в современных сервисах вынуждает нас адаптироваться к новым требованиям QA. Неотъемлемый шаг этой адаптации — умение тестировать продукт без использования UI-интерфейса. Это не так сложно, как кажется.

Нас пугает новое и неизвестное. Хотя иногда все оказывается не так страшно. В этой статье я расскажу, почему тестировать API не сложно и как этот скил поможет стать крутым QA.

Когда в команде дело доходит до тестирования API, начинающий QA теряется — даже смотреть в сторону сервера страшно, не то что подбирать к нему запросы. И это волнение оправдано. Тестируя UI, невольно становишься пользователем продукта и видишь такой же графический интерфейс, как и потенциальный клиент. Достаточно ввести в нужное поле браузера текст, и тебе выдаст понятную ошибку. При знакомстве с апишкой может показаться, что она требует другой стратегии тестирования. На деле же тебе понадобится чуть больше технических знаний:

  • понимание клиент-серверной архитектуры;
  • принципы работы протокола HTTP;
  • знание форматов передачи данных JSON и XML.

И, конечно, уверенность в себе.

Зачем тестировать API

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

В монолите бэкенд с фронтендом общается через программный код по единой неизменной схеме. Это как будто играешь с напарником в настольный теннис — ваши роли очевидны. В случае с микросервисами каждый из них — отдельный сервер со своей логикой. Один создает фото, другой обрабатывает их, третий хранит, четвертый передает пользователю. Здесь уже просто отбить мяч недостаточно. Это становится похожим на бейсбол: сначала бьешь по мячу, затем бежишь за ним, чтобы поймать. Так и микросервис может быть одновременно клиентом и сервером по отношению к другим «игрокам».

Допустим, есть сервис, который умеет накладывать фильтры на фото, а другой — хранить файлы. Появляется два варианта их общения:

  1. Сервис с фильтрами идет в хранилище фоток, забирает нужный файл и красит фото в сепию. Здесь сервис фильтров — это клиент, а сервис-хранилище — сервер.
  2. Сервис-хранилище берет одну из своих фоток и несет сервис-фильтру с целью определить, какой именно фильтр наложен на фотку. Сервис-фильтр такой: «Чувак, это же сепия, что непонятного». Так клиент и сервер поменялись местами.

Чтобы микросервисы друг друга понимали, придумали API (Application Programming Interface) — специальный программный интерфейс. Тестирование помогает убедиться, что программа выполняет поставленную перед ней цель и сможет корректно взаимодействовать с другими программами. Проверять и автоматизировать тесты API можно даже с минимальной теоретической базой. Главное — подобрать правильные инструменты.

Шок

Представим QA Васю, которому только что сказали проверить функционал по созданию пользовательских карточек в софте для больниц. В продукте не предусмотрен UI, данные приходят из сторонней системы. То есть сервис заточен под то, чтобы одна программа использовала другую. До этого он всю карьеру проводил исключительно мануальные UI-тесты. У Васи первая стадия на этапе тестирования — шок. Перед ним ни одной знакомой кнопки и полей.

Вася, выдыхай. Вот тебе самый распространенный инструмент для тестирования апишек — Postman. Программа позволяет в понятном для нас виде оформить запрос и передает его серверу на доступном ему языке. В Postman будем вписывать все дальнейшие шаги.

Чтобы запросить информацию у сервера, понадобится протокол HTTP — формат передачи гипертекста в клиент-серверной архитектуре. Типы запросов бывают разные. Иногда клиент хочет что-то попросить или отправить серверу, иногда удалить с него информацию. Так появились методы HTTP-запросов. Самые распространенные: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH. Метод определяет действие относительно сервера.

Итак, выбираем путь, по которому отправим запрос:

То, что хотим сообщить серверу, — тело запроса. Штука опциональная. Ключевая для сервера информация отображается в методе передачи запроса. Возвращаясь к нашему примеру eHealth-программы, в строке «Путь» пишем нужную ссылку, а в теле указываем информацию о медицинской карточке: имя, фамилию, возраст пациента и диагноз.

Заголовок помогает серверу правильно расшифровать сообщение. Иногда он не связан с телом запроса или его вообще нет. Указывая в заголовке Accept, мы даем серверу понять, какие данные готовы принять в ответ. Если устроит любая информация, в заголовке должно быть значение «* / *».

Отправляем...

Отрицание

Postman выдал набор текста, кавычек, запятых и прочие символы. Вася ничего не понимает, злится. Он переживает отрицание — пока мало верит, что из этого получится нечто полезное.

К счастью, у протокола HTTP есть описание не только запросов, но и ответов сервера. 415 — это код состояния. Сервер говорит, что получил данные, которые не умеет читать. Существует множество кодов состояний для разных ситуаций. Ответ 200 ОК — признак успешного запроса. Код 404 известен всем пользователям интернета и значит, что ресурс не найден. Останавливаться на status codes не буду. Их все можно загуглить.

Что же Вася сделал не так? Скорее всего, он не подумал о правильной «упаковке» документа. Для хранения и передачи данных используют JSON и XML — полностью взаимозаменяемые форматы. Трудно передать большой массив информации только через текст. Словами, конечно, это можно было бы сделать, если бы данные не читал компьютер. Он заранее должен знать формат и типы данных, как их найти в системе и работать с ними. Нельзя рассылать XML или JSON всем серверам и думать, что тебя поймут. Формат принимаемых данных разработчики прописывают при создании программы.

Вася погуглил и выяснил, что его сервер умеет общаться на JSON, поэтому вновь по тому же адресу в нужном формате отправляет запрос. Успех! Сервер ответил очередным набором символов, но благодаря Postman их можно перевести.

Подытожим: протокол HTTP определяет формат общения клиента и сервера. Чтобы отправить HTTP-запрос, нужен специальный софт (Postman, а также можно попробовать Insomnia REST Client, HTTPie или другую программу из списка). Клиент, наш Вася, отправляет сообщение и принимает соответствующий ответ. Общение с сервером происходит в одном из форматов — JSON/XML. Полученные данные расшифровывает софт.

Торг

Чтобы автоматизировать API-тест, тебе нужно освоить язык программирования: Python, Java, С# или любой другой понравившийся либо необходимый в проекте. И тут Вася такой: «Автоматизация? Ой, давайте нет? Там же придется написать тонну кода. Я никогда так не мог и не смогу. На тестировании остановимся, ОК?».

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

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

Принятие

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

Секрет в том, что... секрета нет

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

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

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

👍НравитсяПонравилось4
В избранноеВ избранном8
Подписаться на автора
LinkedIn

Похожие статьи



22 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Для автоматизатора тестування API, це навпаки відпочинок, після типових проблем і гальмів UI. А взагалі хорошому тесту має бути все рівно, що там за двигун під капотом, він перевіріє чи довезе машина куди треба.

Да некоторые микросервисы пользуются http для общения. Но это не единственный способ. Есть же ещё Месседж басы, тот же http2(например gRPC), или популярный GraphQL, всякие нотификейшены и события . А как тестировать, когда у микросервисов eventual consistency — тот ещё сок.Так что ещё многое придется изучить)

Ну, при таком подходе много не натестируешь.
Ваши тесты будут похожи на «GET туда-то», «POST туда-то». При наличии больше, чем 200 тестов и аппликухи в инкрементальном цикле разработки — здравствуй, maintenance hell.
Где же DAL, DTO? Где же e2e тесты, базирующиеся на бизнес-логике?
Более того, главная боль микросервисной архитектуры — наличие динамически появляющихся боттлнеков, соответственно, не мешало бы иметь перфоманс и лоад тесты, чтобы отслеживать моменты их появления. Провтыкал — все, поздно, найти опосля будет в разы тяжелее.
Ну и выводы: «не требует подготовки» для UI тестирования — это уже совсем ни в какие ворота. Вы рассуждаете про автоматизацию API — так почему оставляете UI мануальщикам? Selenium / Selenide — не?

автор видимо хотел подкупить литературным стилем нежели содержанием... но не вышло

якийсь жестяк трохи)

А на ДОУ есть пруфридеры или редакторы?)

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

Так, правильно.
Технічні рецензенти у нас теж є, але не всі статті вдається віддавати на рев‘ю. Зрештою, про спірні моменти можна дискутувати в коментарях :)

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

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

Статья очень сжато передает смысл лекции, которую можно найти на ютуб канале NIX. Общий посыл скорее мотивационный, чем технический, тест дизайн туда просто не уместился, т.к. была задача раскрывать самые банальные понятия с самых «низов», а времени было в обрез.

Если будет желание глянуть запись онлайн выступления — она тут youtu.be/qkUCzvP-5mg?t=10098

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

з точки зору тестування немає різниці моноліт, SOA чи мікросервіси. Вам навіть не обовязково про це знати. У вас є ендпойнт і ви працюєте з ним. Для тестування чи UI нічого не змінюється.

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

так я і ніде не писав що знання архітектури не потрібні
Я писав, що тестування API для моноліта та мікросервісів — нічим не відрізняється

З точки зору джунів — цілком можливо. З точки зору інженерів інших рівнів — ні.

Не стоит размениваться несколькими часами свободного времени ради того, чтобы открыть себе путь в автоматизацию чего бы то ни было

Кілька годин? Я хотів би подивитись на цю людину, яка засвоїла автоматизацію за кілька годин)

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

Написати 5 тестів на sign in / sign up форми можна, звісно ж.
Але якщо не йти далі в вивченні мови, то на цьому все й закінчиться.
Тому тяжко це назвати

открыть себе путь в автоматизацию
Чтобы микросервисы друг друга понимали, придумали API (Application Programming Interface) — специальный программный интерфейс.

Wat?

Сам прозрел после этой фразы

Подписаться на комментарии