можно ли проводить api тестирование без запуска кода
👨🔧️ Немного про API: от тестового покрытия до QAAPI
Понимание тестового покрытия дает понимание качества продукта, автотесты значительно ускоряют процесс и зачастую делают его более точным, тестирование без доступа к коду показывает возможности продукта с пользовательской стороны. Разберем основные понятия от простого к сложному, ведь хороший инженер QA – постоянно развивающийся инженер QA.
По понятиям
API для QA: что тестируем и как?
API бывает внутренним, когда все компоненты связаны и используются внутри системы, и бывают публичными, когда можно полученную информацию интегрировать с другими приложениями. Чтобы программы корректно работали друг с другом, их API должны соответствовать одному стандарту. Например, существует стандарт архитектуры взаимодействия приложений и сайтов REST.
К сожалению не всегда очевидно, что покрыто тестированием, а что нет. В большой команде проводится много тестов на разных языках, а инженеры QA обладают разной степенью подготовки – может возникнуть вопрос о пересечении тестов между собой.
Выделим две важных задачи:
В основе тестирования всегда лежит бизнес-логика программного продукта, а тестирование API – это интеграционное тестирование, в ходе которого можно отловить ошибки взаимодействия между системами.
API для QA: тест фичи без доступа к коду
Многие особенности приложения невозможно проверить без доступа к коду, особенно если вы только начали обучение или недавно записались на курсы тестировщика. А как тестировать задачи, результат которых нужно ждать от нескольких часов до нескольких дней?
Логично, что удобнее всего подменить константы в программе, но не всякий код позволит так с собой обращаться. Поэтому в результате многочисленных проб и ошибок на простора было создано QAAPI – возможность точечного вмешательства в работу продукта в нужном моменте. Это набор вызываемых и возвращающих ответ методов, которые можно вызвать из браузера. Притом вызывать их можно один из другого.
В каждом проекте свое API и, соответственно, у QAAPI должны быть свои умения, которые и дату назад отмотают, и тестового пользователя зарегистрируют с определенными параметрами, и данные подгрузят, и сервис активируют, и весь нужный пул методов содержат.
Любое QAAPI стоит на трех китах:
Концепция QAAPI проста и в то же время максимально эффективна. Она дает массу преимуществ, подготавливая данные для автоматического тестирования и обеспечивая получение информации о состоянии фичи.
Например, нам нужно проверить, чтобы через 45 секунд после регистрации у нового пользователя появлялось окно с партнерским предложением. Есть метод SetHelloBalTime и URL, принимающий в качестве параметра количество секунд с момента регистрации, когда нужно будет показать пользователю (по его ID) нужное окно.
Выглядело бы это примерно так:
Такой запрос возвращает ответ
Сам класс метода будет таким:
API-помощники в тестировании
Для автоматизации труда инженера QA существует множество различных решений. Рассмотрим два популярных программных продукта, упрощающих работу с QAAPI:
По сути, Swagger представляет из себя документацию, которая генерируется по вашему сервису. Она содержит:
Swagger работает по принципу генерации и при этом неважно, какой фреймворк вы используете.
Есть коды ответов и они также все задокументированы.
Приложение умеет составлять и отправлять запросы, добавлять контрольные точки, параметризовать запросы, создавать разные окружения одним и тем же запросам.
Плюс Postman – графический интерфейс и встроенный компонент Collection Runner, с помощью которого можно запустить наполненную запросами и тестами коллекцию.
Автоматизация тестирования – один из лучших способов проверки качества ПО в текущей версии. И чем чаще и качественнее по уровню проходит обучение инженер QA, тем более современные и мощные инструменты появляются в его арсенале. Образование тестировщика напрямую влияет на его заработок, поэтому важно выбирать максимально качественные обучающие ресурсы. Если вы не новичок в профессии, стоит прокачать английский, а потом перейти к какому-нибудь новому языку программирования. Наиболее эффективным для создания автоматизированных тестов считается Java.
Если вы только начинаете карьерный путь, стоит обратить внимание на факультет тестирования ПО онлайн-академии GeekBrains. Помимо теоретических знаний, здесь вы сможете получить и практические навыки по реализации топовых вариантов автотестов, а также фидбек от опытных наставников и помощь в трудоустройстве.
Стратегия тестирования REST API: что именно вам нужно тестировать?
Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом. Если он сломается, это подвергнет риску не только одно приложение, но и целую цепочку бизнес-процессов, построенных вокруг него.
Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).
Пирамида тестов
Когда у нас уже есть прочный фундамент из модульных тестов, охватывающих отдельные функции, тесты API обеспечивают более высокую надежность. Они проверяют интерфейс, более близкий к пользователю, но не имеют недостатков тестов пользовательского интерфейса.
Стратегия тестирования API
Основными задачами функционального тестирования API являются:
гарантировать, что реализация API работает в соответствии со спецификацией требований (которая позже становится нашей документацией по API).
предотвратить регрессий между написанным кодом(merge) и релизом.
эндпоинты правильно именованы;
ресурсы и их типы правильно отражают объектную модель;
нет отсутствующей или дублирующей функциональности;
отношения между ресурсами правильно отражаются в API.
Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).
Итак, какие аспекты API мы должны протестировать?
После того как мы проверили соглашение API, мы можем поразмышлять о том, что тестировать. Независимо от того, думаете ли вы об автоматизации тестирования или ручном тестировании, наши функциональные тест-кейсы имеют одинаковый набор тестовых действий. Они являются частью более широких категорий тестовых сценариев и их можно разделить на три потока тестирования.
Этапы тестирования API
Каждый тест состоит из тестовых шагов. Это отдельные атомарные действия, которые тест должен выполнять в каждом потоке тестирования API. Для каждого запроса API тест должен будет выполнить следующие действия:
Проверьте корректность кода состояния HTTP. Например, создание ресурса должно возвращать 201 CREATED, а запрещенные запросы должны возвращать 403 FORBIDDEN и т. Д.
Проверьте полезную нагрузку ответа. Проверьте правильность тела JSON, имен, типов и значений полей ответа, в том числе в ответах на ошибочные запросы.
Проверьте заголовки ответа. Заголовки HTTP-сервера влияют как на безопасность, так и на производительность.
Проверьте правильность состояния приложения. Это необязательно и применяется в основном к ручному тестированию или когда пользовательский интерфейс или другой интерфейс можно легко проверить.
Проверьте базовую работоспособность. Если операция была завершена успешно, но заняла неоправданно много времени, тест не пройден.
Категории тестовых сценариев
Наши тест-кейсы делятся на следующие общие группы тестовых сценариев:
Основные позитивные тесты (прохождение успешного сценария по умолчанию)
Расширенное позитивное тестирование с дополнительными параметрами
Негативное тестирование с валидными входными данными
Негативное тестирование с недопустимыми входными данными
Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи)
Тестирование успешного сценария по умолчанию проверяет базовую функциональность и критерии приемки API. Позже мы расширим положительные тесты, чтобы включить дополнительные параметры и дополнительные функции.
Тестовые потоки
Давайте разделим и обозначим три вида потоков тестирования, которые составляют наш план тестирования:
Мы выполняем запросы через API и проверяем действия через пользовательский интерфейс веб-приложения и наоборот. Цель этих потоков проверки целостности состоит в том, чтобы гарантировать, что, хотя на ресурсы влияют различные механизмы, система по-прежнему поддерживает ожидаемую целостность и согласованный поток данных.
Пример API и тестовая матрица
Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов).
Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API:
Можно ли проводить api тестирование без запуска кода
Что пишут в блогах
В этом видео Крутов рассказал про инструменты Moon и Moon Cloud. Обсудили новые фичи: поддержка Selenium 4, Playwright, Cypress.
29-30 октября в Москве пройдет международная конференция по тестированию SQA Days!
Продолжу хвастаться статусом книги.
Онлайн-тренинги
Конференции
Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Дейв Вестервельд (DaveWesterveld)
Оригинал статьи
Перевод: Ольга Алифанова
Начиная тестировать API, я не знал о них ничего. За последние несколько лет я многое узнал, и теперь совершенно спокойно использую и тестирую API, но так было не всегда. Когда я начинал, было сложно даже определить, что же делать. Все еще помню, через какую боль я прошел.
На первом курсе университета у нас был профессор математики по кличке «Эйнштейн» – частично из-за его прически, а частично потому, что он делал математику такой же сложной, как теорию относительности. Он начинал решать задачу на доске, а затем говорил «следовательно, очевидно, что» и выводил решение. Мы сидели с озадаченными лицами. Очевидное для него было неочевидно нам, студентам. Нам нужно было знать промежуточные шаги, которые он проскочил, чтобы разобраться, что произошло.
Это частая история. Когда вы узнаете больше, стартовая боль кривой обучения проходит, и становится сложнее и сложнее объяснять что-то тем, кто только начал. Вы начинаете предполагать и делать логические скачки, очевидные для вас, но смущающие новичков в предмете. Продолжая развивать свои знания об API, я хочу записать ряд своих мыслей о тестировании API, пока не стало слишком поздно объяснять это начинающим.
Итак, после этого долгого вступления, вот моя попытка упрощенного руководства для начала API-тестирования.
Выясните конечные точки
Для меня это одна из самых сложных вещей в тестировании API. Как узнать, что там вообще тестировать? Что это API умеет? Если вы работаете с хорошо документированным публичным API, то выяснить это нетрудно, но по моему опыту, большая часть тестирования API проводится на внутренних API, поддерживающих различные части вашего приложения. Как правило, такие API плохо задокументированы (если документация вообще есть). Как же это выяснить?
Конечно, любая имеющаяся внутренняя документация вам поможет, поэтому всегда начинайте с нее, если она есть. И не забудьте, что она может лежать в самых неожиданных местах. К примеру, иногда вам могут помочь комментарии в коде или даже подписи в методе. Документацию можно также найти в сторис или требованиях, которые укажут вам нужное направление.
Еще один отличный источник информации – это люди. В компании есть люди, которые создавали, проектировали, тестировали и/или использовали ваш API? Найдите их и поговорите с ними – они могут быть бесценным источником информации.
И, наконец, можно посмотреть на сетевые вызовы в консоли разработчика, чтобы выявить доступные конечные точки API. Зачастую вызовы API отправляются через сеть, и, разглядывая их через инструменты разработчика, можно многое узнать об их работе.
Все эти источники информации дадут вам неполные и неточные сведения. Наверняка будет то, что вы просто не понимаете, и (особенно поначалу) все будет непонятным и туманным. Но если вы не сдаетесь и продолжаете задавать вопросы и получать обратную связь, то в один прекрасный день осознаете, что вы все поняли и разбираетесь, как API работает.
Авторизацияибезопасность
Авторизация. Аутентификация. Безопасность. Что это и как это работает? С моей точки зрения, процессы авторизации сложны для понимания. Безопасность, конечно, очень важна для работы API, но она может серьезно усложнить его использование. Эта статья сильно разрастется, если я углублюсь в этот вопрос, но хочу все же дать несколько подсказок.
Для начала разберитесь, как вам могут помочь ваши инструменты. Приложения вроде Postman сильно упрощают вопросы авторизации и аутентификации. Они также могут дать вам представление о безопасности вашего API. Покопайтесь в функциональности используемого инструмента, посмотрите, что он предлагает.
Другой момент – когда вас все это раздражает, считайте это полезным опытом. Задавайте вопросы коллегам (и Гуглу). Попытайтесь разобраться, как работает OAuth. Вникните в процесс авторизации. Лично мне изучение авторизации сильно помогло понять работу API и HTTP-протоколов, и это был отличный способ узнать больше о тестировании API.
И напоследок про безопасность – множество вопросов «безопасности» не связано напрямую с техническим тестированием безопасности. Проверка, что разные типы пользователей могут получать только ту информацию, на которую у них есть права, и что все пути отдают правильную информацию – это тоже формы тестирования безопасности. Не забывайте смотреть на ваше API в совокупности.
Учитесь делать, делая
Очень привлекательно потратить много времени на изучение чего-то вроде API-тестирования. Нам кажется, что нам надо знать, что мы делаем, до того, как мы приступим к делу, но я убежден, что лучший способ обучения – практический. Просто попробуйте сделать API-вызовы. Разберитесь, какова конечная точка, и попробуйте ее вызвать. Начните с самого небольшого известного вам участка и используйте его. Пробуя что-то сделать, застревая, разбираясь с этим, вы узнаете то, что вам надо знать про ваш рабочий API. Вы также узнаете, о чем вы не знаете, и что нуждается в изучении, и найдете ресурсы, которые помогут вам разобраться именно с этим вопросом.
Разберитесь с базовой терминологией
У меня есть словарик терминов. Это набор терминов, которые мне пришлось выучить. Возможно, он вам пригодится, но мне кажется важным также выяснить, какие из ваших рабочих терминов вам непонятны, и прояснить этот вопрос. Важно также слушать, какие термины употребляют коллеги, и убедиться, что они вам понятны. Зачастую разные команды и компании используют одинаковые и похожие термины, имея в виду разные вещи. Обращайте внимание на слова, постройте свой словарь. Это упростит задавание вопросов и понимание происходящего.
Что дальше?
Итак, что же делать дальше?
Большой гайд по тестированию с Postman для начинающих
Содержание
В этом большом гайде мы разберем тестирование API с помощью Postman. Он покроет большинство сценариев использования этой программы в вашей повседневной работе.
Давным-давно Postman стартовал как расширение для Google Chrome. Сейчас это полноценное нативное приложение, доступное на Windows, Linux и MacOS.
Что такое API?
API — сокращение от Application Programming Interface (программный интерфейс приложения). API — набор правил, протоколов и инструментов для взаимодействия между приложениями. Говоря простым языком, API — интерфейс, который определяет, как одна программа должна взаимодействовать с другой программой. Как правило, представляет собой набор функций, которые могут быть вызваны другой программой.
Что такое Postman?
Postman — приложение для работы с API. Это популярный API клиент, который позволяет разрабатывать, тестировать и документировать API.
Как тестировщики, с помощью Postman мы можем отсылать HTTP/s запросы к сервисам и получать от них ответы. С помощью такого подхода можно протестировать бэкенд сервисы и убедиться, что они корректно работают.
Зачем использовать Postman?
Сегодня Postman — супер-популярный инструмент. Им пользуются более 8 миллионов разработчиков и тестировщиков. И вот почему:
Установка Postman
Установка подробно описана в отдельном гайде. Найти его можно здесь (! на английском)
После того, как Postman установлен, можно переходить к тестированию API.
Postman отличный инструмент для тестирования API для тех, кто не хочет или не может писать тесты вручную (в IDE на языке программирования, используемом для разработки приложения).
Особенности Postman
Ниже мы перечислим только некоторые из особенностей Postman:
Больше информации о Postman можно найти на официальном сайте: https://www.getpostman.com/
Цена: Бесплатно или 21 доллар за пользователя в месяц.
Postman — freemium-интсрумент. Но бесплатной версии более, чем достаточно, чтобы проводить базовое тестирование API.
Как пользоваться Postman
Для начала, давайте подробно рассмотрим интерфейс. Мы сознательно будем рассматривать английскую версию (и рекомендуем использовать именно ее):
Основные сущности Postman: запросы, коллекции и окружения
Перед тем, как приступить непосредственно к тестированию, давайте рассмотрим основные сущности, которыми оперирует Postman:
1. Запросы (Requests)
Запрос представляет собой комбинацию URL, хедеров и Body (тела запроса). Postman позволяет сохранять запросы и использовать их в будущем там, где вам нужно.
Чтобы создать новый запрос, нажмите New — Request
Как мы писали выше, Postman позволяет делать запросы к API. С помощью API-запроса можно получать и отправлять данные какому-либо бэкенд-сервису.
Для каждого API-запроса нужно выбрать HTTP-method.
Что такое HTTP?
HTTP — сокращение от HyperText Transfer Protocol (протокол передачи гипертекста). Протокол используется для общения клиента и сервера. Клиентом, к примеру, может быть браузер (в нашей статье в качестве клиента используется Postman).
После отправки клиентом HTTP-запроса, сервер возвращает ответ. Ответ сервера содержит метаданные о статусе и запрашиваемый контент.
Наиболее распространенные типы HTTP-запросов:
Далее в статье мы рассмотрим, как создавать и отправлять запросы разных типов с помощью Postman.
2. Коллекции (Collections)
Коллекции представляют собой группы запросов. Вы можете думать о коллекциях как о папках, в которых лежат запросы.
Как создать коллекцию в Postman:
Нажмите New — Collection
Введите имя (Name) и описание (Description) коллекции, после этого нажмите кнопку Create:
Коллекция может содержать любое число запросов. Запустить выполнение коллекции можно двумя способами:
Далее мы рассмотрим оба этих способа.
3. Окружение (Environments)
Окружения в Postman позволяют запускать запросы и коллекции, используя разные наборы данных. Например, мы можем создавать разные окружения в Postman для Dev, QA и Production серверов. В каждом из окружений будут свои собственные настройки: например, URL, auth token-ы и пароли, API-ключи и т.п. Окружения представляют собой наборы пар «ключ-значение».
Чтобы создать новое окружение (Environment), нажмите New — Environment
Мы рассмотрим работу с окружениями далее в статье.
Тестирование GET-запросов
Повторимся, GET-запросы используются для получения данных с сервера. GET-запросы не меняют состояние данных на сервере (не добавляют, не удаляют и не изменяют данные).
Для обучения мы будем использовать простой открытый API: http://dummy.restapiexample.com/api/v1/employees
Давайте отправим GET-запрос с помощью Postman:
Мы рекомендуем завести аккаунт и использовать его для входа (чтобы сохранять запросы, коллекции и окружения для использования в будущем).
Шаг 1: Открываем новую вкладку, чтобы создать запрос (нажимаем на «+»):
Шаг 2: Создаем GET-запрос:
После выполнения запроса вы должны будете увидеть данные от сервера во вкладке Body.
На скриншоте ниже вы видите код ответа сервера (Status: 200 OK), время выполнения запроса (Time: 1700ms) и размер ответа (Size: 1.62 KB)
По наведению на Time и Size появляется всплывающее окно с подробной информацией.
Время ответа сервера (Response Time)
Размер ответа (Response Size)
Куки (Cookies): Здесь можно увидеть информацию о куках, возвращаемых сервером
Хедеры ответа от сервера (Response headers)
Тестирование POST-запросов
POST-запросы используются для отправки новых данных на сервер. Давайте попробуем с помощью POST-запроса добавить нового пользователя. Для этого мы отправим информацию о новом пользователе в теле POST-запроса.
После этого наживаем кнопку SEND и отправляем POST-запрос.
Примечание: для проверки корректности вашего json можно использовать Jsonformatter
Точно так же, как и POST, отправляются PUT, PATCH и DELETE запросы.
Примечание: во время тестирования, для каждого запроса проверяйте возвращаемый результат, код ответа сервера и время ответа сервера. И не забывайте про негативные тесты!
Параметризация запросов
Параметризация — одна из самых полезных особенностей Postman.
Часто необходимо выполнить один и тот же запрос на разных наборах данных. С помощью параметризации, можно использовать переменные при выполнении запросов.
В Postman, параметры создаются с помощью двойных скобок: <
Например, наш base URL — https://testengineer.ru и мы сохраняем это значение в переменной с именем base_url. В этом случае, мы можем обратиться к этой переменной из запроса, написав <
Шаг 1: Меняем тип HTTP-запроса на GET и вводим URL:
Шаг 2: Меняем URL на параметр <
Шаг 3: Теперь нам нужно создать переменную окружения, чтобы использовать ее в качестве параметра. Для этого нажимаем на кнопку с глазом и кликаем на Edit (редактировать), чтобы создать глобальную переменную и затем использовать ее в коллекциях.
Шаг 4: В окне создания переменной задаем имя (именем будет url) и значение (значением будет https://jsonplaceholder.typicode.com). После этого нажимаем Save (Сохранить)
Шаг 5: Возвращаемся к GET-запросу и нажимаем Send (отправить)
Если все сделано правильно, значение переменной, которую мы создали, будет подставлено вместо ее имени и запрос выполнится успешно.
Создание тестов в Postman
Тесты в Postman позволяют убедиться, что API работает так, как этого от него ожидают.
Давайте начнем с написания простого теста.
Шаг 1: Возвращаемся к GET-запросу, который мы создали ранее и переключаемся во вкладку Tests (Тесты). В секции сниппетов нажимаем на сниппет «Status code: Code is 200». В окне теста появится скрипт. Этот скрипт будет проверять, что запрос возвращает код ответа 200.
Шаг 2: Нажмите кнопку Send (Отправить). В нижней части окна вы увидите результат выполнения теста (в нашем случае он выполнился успешно).
Шаг 3: Давайте добавим еще один тест. В этот тесте мы будем сравнивать полученный результат с ожидаемым. Чтобы это сделать, выбираем сниппет с названием «Response body:JSON value check». Давайте проверим, что пользователь с именем Leanne Graham имеет userid 1.
Шаг 4: Заменим название теста на что-то более понятное: вместо «Your test name» напишем «Check if Leanne Graham has the userid 1». Также заменим jsonData.value на jsonData[0].name (т.к. jsonData представляет собой массив, а массивы начинаются с 0):
Код теста будет выглядеть следующим образом:
Шаг 5: Нажимаем Send (Отправить)
Запуск коллекций с помощью Collection Runner
Давайте запустим коллекцию с помощью Collection Runner.
Шаг 1: Нажимаем на кнопку «Runner» (находится рядом с кнопкой Import)
Шаг 2: Должна будет открыться следующая страница:
Разберем основные элементы:
2 — Resent Runs: Все предыдущие запуски
3 — Environment: Окружение. Если вы хотите запустить коллекцию в конкретном окружении, вы можете выбрать его в этом поле.
4 — Iterations: Количество итераций
5 — Delay: Задержка. Указывается в миллисекундах. Выполнение тестов без задержки может вызвать ошибки, поэтому всегда указывайте небольшую задержку.
7 — Start Run: Кнопка для запуска коллекции
Шаг 3: В этом окне добавим коллекцию для запуска. Выбираем нашу коллекцию тестов, устанавливаем параметр Iterations в 2, delay в 2500ms и нажимаем кнопку запуска.
Шаг 4: После выполнения откроется отчет. В нашей коллекции были GET и POST запросы, но тесты мы добавляли только для GET-запроса. Поэтому в отчете рядом с POST-запросом показывается текст «This request doesn’t have any tests.» (для этого запроса нет тестов)
Запуск коллекций с помощью Newman
Для того, чтобы запустить коллекции с помощью Newman, делаем следующее:
Шаг 1: Устанавливаем node.js. Сделать это можно по ссылке
Шаг 3: После установки newman заходим в Postman. В списке коллекции находим нашу коллекцию, нажимаем на три точки и выбираем Export (Экспортировать)
Шаг 4: В появившемся окне выбираем «Export Collection as Collection 2.1 (Recommended)» и нажимаем Export.
Шаг 5: Выбираем папку, в которую экспортировать коллекцию и нажимаем Save. Рекомендуем создать отдельную папку для Postman-тестов. После нажатия на Save, коллекция будет экспортирована в выбранную папку.
Шаг 6: Для корректного запуска нам понадобится экспортировать и окружение. Для этого нажимаем на кнопку с глазом и выбираем опцию Download as JSON. Выбираем папку, в которую экспортировать окружение и нажимаем Save. Рекомендуем экспортировать окружение в ту же папку, в которую была экспортирована коллекция.
Шаг 7: Теперь, когда мы экспортировали коллекцию и окружения в папку, возвращаемся в командную строку и меняем директорию на ту, где находятся коллекция и окружение.
Шаг 8: Запускаем коллекцию с помощью команды:
После выполнения коллекции, появятся результаты выполнения тестов.
Заключение
В этом гайде по Postman мы постарались разобрать базовые темы. Мы надеемся, вы научились создавать и отправлять просты запросы, проверять ответы сервера, создавать простые тесты. Узнали, как выполнять коллекций с помощью Collection Runner и Newman. В следующих статьях мы разберем продвинутые возможности Postman.