Меня зовут Игорь Гросс, я руководитель проектов в Test IT — это такая система управления тестированием. В этом посте я расскажу об одном интересном инструменте тестировщика — Postman — а также о том, как с его помощью решать распространённый тип задач — тестирование API. В результате указана обновленная информация и время, когда были внесены изменения. Дополнительно успешность операции подтверждает ответ 200 от сервера. Попробуем обновить данные пользователя, для этого создаём update_user. Указываем ссылку на API и после отправления смотрим на полученный результат, соответствующий ожидаемому.
- На конкретных примерах мы остановимся подробнее в следующих разделах.
- Мы знаем, что эта форма, скорее всего, хранит данные где-то в базе данных, и мы можем написать множество тестов, чтобы проверить, корректно ли данные сохраняются в базе.
- Это те заголовки, что генерирует сам постман.
- У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования.
- Работал автоматизатором на крупном государственном проекте.
- Поле базовое, может есть прям во фреймворке какие-то проверки, или в интернете скопипастил… Так что тут стоит убедиться, что email корректный.
В целом, PATCH-запросы могут быть быстрее, так как они могут передавать только измененные поля объекта. Раз должны, то будет ошибка в случае неуникальности. А мы решили вынести тестирование негативных сценариев отдельно.
Параметризация Запросов, Переменные Окружения
Этот отзыв никогда не будет общедоступным. Мы будем использовать его, чтобы показывать более качественные вклады всем участникам. Postman предлагает внушительный список, нам нужен GET.
Но и это не представляет проблемы в том случае, если API-тесты интегрированы с тестами GUI. Нужные cookie можно забрать в браузере, открытом с помощью Selenium (driver.manage().getCookieNamed(«sessionId»).getValue()). На структуру тела запросов и ответов не накладывается ограничений. Это может быть как просто набор пар поле/значение (т. н. Form Data, как в примере выше session_token/значение), так и документ в удобном для разработчика формате (JSON, XML или каком-то ином). Более того – многочисленные действия в браузере часто являются причиной ложных «падений» автоматизированных тестов, которым на уровне GUI свойственна «хрупкость».
Потом решили стать модными, молодежными, подключили REST. Обычно это в методе GET делается, прямо в параметры URL зашивается какая-то информация. Например, идентификатор элемента, который мы хотим получить. Если по нему определяется пол, тесты будут одни, если предлагаются подсказки, другие, а если это простая строка — третьи.
Json – Интуитивно Понятное Нечто, Про Которое Тестироващику Лучше Почитать Отдельно
Остается выбрать инструменты, которые будут воспроизводить нужные вам запросы и отслеживать содержимое ответов. Тесты часто содержат подготовительные/вспомогательные действия, многие из которых удобнее выполнить с использованием API. Для расширения ваших возможностей используйте Fiddler или подобные ему инструменты (например, такие). Эти программы перехватывают весь сетевой трафик, позволяя просматривать, редактировать и воспроизводить отдельные запросы. Уже на этом уровне можно что-то тестировать – например, валидацию данных на стороне сервера.
Если вам доступна документация, в которой описываются endpoint-ы сервисов вашего проекта (т. е. адреса, к которым обращаются запросы, относящиеся к API), – изучите ее. Ниже я буду рассматривать вариант, когда подробной документации или соответствующих доступов у вас нет. У нас тестирование api есть коллекция запросов, и мы хотим использовать их на разных окружениях. Допустим, выполнять их локально, на тестовом стенде и на проде. Посмотрим, что предлагает Postman, и как это работает. Чтобы программам общаться между собой, их API нужно построить по единому стандарту.
После того как мы использовали параметры из переменных окружения, повторим запрос, чтобы проверить, что нигде не ошиблись. В ранее созданном запросе выделим в переменные два параметра — URL стенда, к которому мы обращаемся, и токен для авторизации. Создаём две переменные url и token и укажем их значения. На скриншоте ниже их значения скрыты из соображений безопасности. Переходим на вкладку Authorization, указываем данные для идентификации пользователя.
Плюсом метода вложенных условий является возможность вывода нескольких ошибок одновременно. Использование ассоциативного массива и отсутствие принудительных остановок return позволяет полностью проверить ответ и остановить проверки только на определенных https://deveducation.com/ уровнях вложенности. В итоге вместо одной ошибки можно получить три на вкладке Tests. Также этот метод помогает понять, какие параметры зависят друг от друга в ответе, – следовательно, вы лучше понимаете и разбираетесь в API, которое тестируете.
Видите, решение тестировать альтернативы отдельно от негативного сразу оказалось не самым удобным — куда лучше просто читать ТЗ и каждый пункт проверять. Так хоть не запутаешься, что проверил, а что ещё нет… Однако в рамках статьи мы всё-таки рассмотрим негативные тесты отдельно. На этот вопрос нам поможет ответить документация. В документации «Яндекс.Словарь» описаны два метода (getLangs и lookup) и несколько параметров к каждому из методов. Если у нас всего две стороны, или веб-клиент (протестировать можно любыми платформами типа Postman, curl и т.д.), или веб-сервер. Протестировать с третьей стороны можно в среде разработки на localhost с помощью, например, JUnit.
Если веб-клиент в браузере не позволил вам ввести некоторые значения – в Fiddler-е вы сконструируете запрос сами. Такой способ может существенно ускорить проверку большого набора данных для ввода, особенно если изменение значений в браузере занимает длительное время. Надеюсь, что предлагаемый материал будет представлять интерес для всех, кто ранее проводил тестирование через графический интерфейс и еще не имеет опыта работы с http-запросами. Между POST и PUT запросами скорость также зависит от конкретной ситуации. Если требуется создание нового объекта, то используется POST-запрос, который может быть быстрее, если передача данных в теле запроса не занимает много времени.
Вы можете столкнуться с большим количеством однотипных запросов, порождаемых различными системами мониторинга (например, yandex.webvisor). Их можно скрыть, применив негативный фильтр (например, «-yandex» для Chrome), даже если вы не знаете точно, что именно эти запросы делают. Однотипные и часто повторяющиеся запросы, как правило, относятся к мониторингу сайта, а не к логике совершаемых пользователем действий. Между PUT и PATCH запросами скорость зависит от того, как реализована логика сервера.
Появился в моей рабочей жизни новый проект. Веб-приложение небольшое, сроки реализации короткие (2 месяца), сам проект был интересный, и его начало, как в классическом SDLC, радовало меня. Суть проекта состояла в том, что нужно переписать фронтовую часть ПО, используя бэкенд и базу данных заказчика. Итак, начинаю свою историю в стиле сюжетной линии с завязкой, развитием действий, кульминацией развязкой и эпилогом (да, да, «как в фильмах»). И этот рассказ, думаю, должен быть познавательным для тестировщиков, которым необходимо закрыть таску по тестам без доступа к программе.
Между PATCH и DELETE запросами скорость также зависит от логики сервера и конкретной ситуации. Оба запроса могут работать быстро, если используются оптимальные методы обработки данных на сервере. В итоге оба метода свелись к выбору между «читаемостью кода», «легкостью и скоростью реализации автотеста» и «количеству найденных ошибок при одном запуске теста». Если вы хотите быстро писать автотесты, но при этом готовы исправлять ошибки по мере их обнаружения, то используйте метод assert’ов. Если у вас есть время на продумывание структуры проверок, выявление зависимостей параметров в ответе, и вы хотите получить все ошибки сразу – используйте метод вложенных условий.
Postman поддерживает множество типов авторизации, параметры для каждого из них отличаются. Используем авторизацию по API Key, полученному из личного кабинета в Test IT. Прописываем название соответствующего API, в данном случае api/register. Речь пойдёт об архитектуре REST, часто использующейся для взаимодействия сайтов и приложений. При этом активно применяется JSON (JavaScript Object Notation – текстовый формат обмена данными на языке JavaScript). Практиковать составление запросов можно, используя ресурс reqres.in.
Http Методы
Postman предлагает множество готовых сниппетов, которые можно применить для тестирования API. Здесь можно валидировать коды и содержание ответов, парсить и сохранять значения в переменные окружения или глобальные переменные, проверять их соответствие заданным значениям и т.д. Подробнее о написании тестовых скриптов в Postman можно прочитать в документации или статье на Хабре. Основной минус метода assert’ов заключается в том, что автотест сразу прекращает свою дальнейшую работу после обнаружения первой ошибки в проверках.
Работал автоматизатором на крупном государственном проекте. В статье речь будет идти о REST API, так как этот подход является более распространенным из-за своей относительной простоты и удобства для разработчиков. SOAP API преимущественно характерен для больших корпоративных (enterprise) систем. Вы не видите, что внутри у замка, но вы можете использовать инструменты и собственное восприятие, чтобы пощупать замок и узнать, что же у него внутри. А также вы знаете про другие замки и можете применить эту информацию к этому конкретному. Конечно, в этой ситуации сложно исполнить такую работу, не имея самого основного инструмента под рукой.
Одно неуспешное нажатие кнопки может привести к необходимости повторения либо всего теста, либо какой-то его части. Сформировав запрос программно или воспроизведя его с помощью специальных инструментов (об этом чуть позже), мы можем существенно сократить время проверки. Для начала постараемся понять, зачем вообще тестировщику осваивать что-либо на таком уровне.
Допустим, если в ответе придет пять ошибок, то об этих ошибках вы будете узнавать последовательно, по мере исправления предыдущей проверки и повторного запуска автотеста. Достаточно часто по адресу endpoint-а можно догадаться, за что именно отвечает запрос к данному сервису. Если трудно «выловить» нужный запрос в общей массе (а запросов к API тоже может быть немало) – очистите историю запросов перед совершением интересующего вас действия. Довольно быстро вы научитесь видеть нужные запросы и сопоставлять их с действиями в пользовательском интерфейсе. Выберите XHR (XMLHttpRequest) – это интерфейс языка JavaScript, используемый для конструирования запросов, имеющих тело. Обычно именно этот интерфейс используется для обращения к API.
Хороший код отличает структура, оптимальность и читаемость. Мы знаем, что эта форма, скорее всего, хранит данные где-то в базе данных, и мы можем написать множество тестов, чтобы проверить, корректно ли данные сохраняются в базе. Возможно, вам уже доводилось тестировать и находить баги. Мы будем использовать эти инструменты и опыт для будущего тестирования. Если есть API, то первым делом нужно попросить документацию на него.
В нашем случае — чтобы создать пользователя в системе. И важно понимать, а что будет потом с нашими данными? Будут ли они нормально отображаться в интерфейсе? Ведь если нет, то надо ставить ограничение на API-метод. Представляйте, что написание кода – это создание баг-репорта.