🟠 Тестирование API - зачем это надо системному аналитику? 🟠


Системный аналитик встречается с тестированием API (программный интерфейс) в следующих случаях:



✅️ Мобильные приложения

Когда аналитик ставит задачи на разработку мобильных приложений, то, как правило, ему необходимо описать маппинг между тем, что есть на экране - UI (пользовательский интерфейс), и тем, что можно отправить или получить от сервера (Backend) через API.

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

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



✅️ Backend

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

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



✅️ Интеграции

Системы взаимодействуют друг с с другом по API. Это могут быть как подсистемы внутри одного проекта, так и системы других компаний. Пример - проектирование GetDelivery.

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



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

🟢 Зачем системному аналитику инструменты для тестирования API?

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

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

3. Оптимизация Производительности:
Проверка на скорость и надежность работы, особенно, когда в интеграциях идет обмен большим количеством данных. Тестирование помогает понять, какие нефункциональные требования и как поддержать, используя хорошо организованные архитектуру и инфраструктуру проекта.

Какими инструментами на работе пользуетесь вы, делитесь в комментариях? Интересно посмотреть на статистику 🙂

👉✅ Тестирование API: обязательные инструменты к освоению для системного аналитика

🟠 Postman

Возможности:
> Отправка запросов к API - HTTP, GraphQL, WebSocket, gRPC, MQTT, Socket.IO,
> Создание и управление коллекциями запросов под разные проекты.
> Тестирование API с помощью написания тестовых сценариев на JavaScript.
> Возможность имитации сервера (Mock Servers) для тестирования без реального API.
> Поддержка автоматизированного тестирования.
> Есть онлайн и десктоп версии, не обязательно устанавливать.

Преимущества:
+ Удобен для новичков.
+ Используется в большинстве компаний. Поэтому именно его я даю на программах по проектированию Интеграций и REST API.
+ Легко интегрируется с другими инструментами и системами.
+ Отличное сообщество и документация: Обширные руководства и активное сообщество пользователей.
+ Бесплатной версии достаточно для работы на небольших проектах.

Недостатки:
- Высокое потребление ресурсов: Может быть ресурсоемким на некоторых компьютерах.


🟡 SoapUI

Возможности:
> Тестирование REST и SOAP веб-сервисов.
> Возможность создания сложных тестовых сценариев без программирования.
> Автоматизация тестирования.
> Мокирование веб-сервисов для тестирования в изолированной среде.
> Поддержка асинхронного тестирования.
> Расширенные возможности отчетности и аналитики..

Преимущества:
+ Поддержка различных типов API: Включая SOAP и REST.
+ Мощные функции для сложного тестирования. Подходит для разработчиков, которым нужны продвинутые возможности.
+ Детальная отчетность, удобная для анализа результатов.

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


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

Есть ещё два инструмента, которые здесь появятся. Есть идеи? Пишите в комментарии! 😉

🟢 Swagger

Возможности:
> Генерация интерактивной API-документации с использованием OpenAPI спецификации.
> Подходит для проектирования API с нуля, с возможностью визуального редактирования.
> Тестирование API прямо из создаваемой документации.
> Автогенерация API-документации на основе кода приложения благодаря OpenAPI спецификации.
> Поддержка OAuth и других механизмов аутентификации.

Преимущества:
+ Автоматическая документация AP на основе кода.
+ Поддержка OpenAPI Specification, что дает универсальность и стандартизацию для документирования API. OpenAPI сегодня также поддержан и в Postman.
+ Интерактивное тестирование API непосредственно из документации.
+ Сообщество и экосистема предоставляют множество плагинов и инструментов.

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


🟣 insomnia - больше подходит для тестировщиков.

Возможности:
> Тестирование REST, SOAP, gRPC, GraphQL и др
> Загрузка проектов из Swagger.
> Возможность настройки окружений для тестирования (разработка, тестирование, прод и др.).
> Испольование переменных для упрощения и автоматизации тестов.
> Поддерживает автоматизацию тестов.
> Поддержка версионирования и совместной работы.
> Возможность расширения функциональности с помощью плагинов.

Преимущества:
+ Легок в освоении даже для начинающих.
+ Вся необходимая функциональность бесплатна.
+ Удобен для работы с GraphQL.
+ Активное сообщество: Множество руководств и поддержка сообщества.
+ Возможность создавать и прогонять тест-кейсы - полезно для тестировщиков.
+ Возможность поддержки версионности кейсов с подключением их к Git.

Недостатки:
- Может быть менее подходящим для очень сложных тестовых сценариев: В сравнении с такими инструментами как SoapUI, функционал Insomnia может показаться ограниченным.
- Недостаток интеграций по сравнению с Postman: Хотя Insomnia поддерживает плагины, общее количество интеграций и расширений может быть меньше.

Нагрузочное тестирование 🥲

А еще рекомендуют знать про JMeter. Стоит взять на заметку, если вдруг придется столкнуться с анализом нагрузок на систему и надо будет что-то подсказать разработчикам.

Возможности:
> Нагрузочное и стрессовое тестирование.
> Тестирование производительности веб-приложений.
> Поддержка многопоточности и симуляция одновременного доступа множества пользователей.
> Запись и воспроизведение тестовых сценариев.
> Графическое представление результатов тестирования.


Заключение:

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

Из опыта скажу, что в 90% работы я использую Postman.

Для тестирования SOAP API я обращаюсь к SOAP UI.

Для разработки API-документации тоже использую Postman, но и Swagger в этом деле идеальный помощник, просто более сложный.

Insomnia использовали коллеги-тестировщики, а JMeter однажды разработчики 🙂


Выбор определенного инструмента зависит от конкретных требований и целей тестирования.

Зачем быть частью сообщества, если можно и без этого жить? 🧐

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

Если ваша цель — прокачивать себя и выстраивать сильное окружение вокруг, то стоит об этом помнить 😏

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

Они помогают нам раскрыться, посмотреть на мир под другим углом. А ещё это классный шанс увидеть свои точки роста 💫

Я искренне радуюсь, когда подсвечиваю эти «точки» студентам GetAnalyst. Мне нравится говорить о том, как можно достигнуть новых высот, ставить новые цели в карьере, планировать новые проекты. Безумно приятно потом узнавать, что для кого-то общение стало судьбоносным и повлияло на жизнь.

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

Особенно я люблю живые вебинары и воркшопы ❣️Мне важно быть живой, видеть вашу реакцию, получать обратную связь. После таких встреч я настолько заряжаюсь, что уверена — моей энергии хватит, чтобы поддерживать в тепле как минимум один большой мегаполис! Или запустить ракету в космос 🚀

Спасибо Вам, что вы стали частью GetAnalyst. Спасибо всем, кто прошел с нами путь роста в этом году! ❤🦭

🚀 Неделя практики в Swagger 🚀

Последнюю неделю этого года я решила посвятить освоению инструмента документирования API - Swagger, востребованного во многих IT-компаниях для позиции Системного аналитика.

Swagger – это набор инструментов для работы с OpenAPI Specification (OAS). Он помогает разработчикам и системным аналитикам проектировать, документировать и использовать RESTful API сервисы. С его помощью можно легко создавать интерактивную API-документацию.


Swagger включает две основные части, которые я хочу выделить, и которыми я пользуюсь:

🟢 Swagger Editor - с помощью этого инструмента создается в ручном режиме документация. Самое сложное в этом процессе - OpenAPI спецификация, которая по сути является языком разметки или языком программирования для описания документации.

🟢 Swagger API-Documentation - результат того, что вы создали в Swagger Editor - API-документация, с помощью которой можно сразу проверять API.

Также документацию можно собирать автоматически, на основе программного кода. Но в этом случае её редактирование аналитиком невозможно.


Примеры Swagger-документации:

🔗 PetSore - демо-проект Swagger документации, на котором предлагается осваивать инструмент.

🔗 Aviasales B2B API - документация для партнеров известного нам сервиса для бронирования авиабилетов.

🔗API-продавца WB - Статистика - пользователям Wildberries будет полезно посмотреть, что по статистике продаж смотрит бизнес через Wildberries API.


Для того, чтобы научиться создавать аналогичную документацию, необходимо освоить инструмент Swagger Editor и OpenAPI спецификацию.

🟢 Swagger Editor - начало работы 🟢

Я не я, если начну давать вам части кода по OpenAPI и объяснять, без возможности пощупать - попробовать на практике.

Поэтому на сегодня у меня для вас есть задание: зарегистрироваться и сделать первые шаги в Swagger Editor.

1. Регистрируетесь в Swagger.
2. Создаете свой первый тестовый проект.

Всё очень просто! 😃

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

Кто выполнил все шаги и готов идти дальше - ❤️ под публикацию!