Так хоть не запутаешься, что проверил, а что ещё нет… Однако в рамках статьи мы всё-таки рассмотрим негативные тесты отдельно. Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. Наша первая задача – это функциональное тестирование, чтобы убедиться, что API работает правильно. Тесты API проходят быстро, обеспечивают высокую рентабельность инвестиций и упрощают проверку бизнес-логики, безопасности, соответствия и других аспектов приложения. На структуру тела запросов и ответов не накладывается ограничений.
В API это ещё важнее, чем просто в графическом интерфейсе. Поймет ли пользователь, что именно он сделал не так, где именно ошибся? Помните, плохое сообщение об ошибке приведет к тому, что вас будут дергать по пустякам, ручное тестирование api вырывая из контекста. А ещё может показаться, что игнорирование ошибок пользователя — это хорошо. Например, у меня был случай, когда на проекте обновили библиотеку и она стала намного жестче с ошибкам интеграции.
Если требуется обновление объекта, то используется PUT-запрос, который может быть быстрее, если изменения касаются большинства полей объекта. У нас есть коллекция запросов, и мы хотим использовать их на разных окружениях. Допустим, выполнять их локально, на тестовом стенде и на проде. Посмотрим, что предлагает Postman, и как это работает. Сначала отправляем базовый запрос и там, и там, как в документации.
API (Application Programming Interface) — это набор определений, протоколов и инструментов, которые позволяют разработчикам создавать и интегрировать приложения. В сфере тестирования ПО, тестирование API играет важную роль, поскольку оно проверяет правильность работы взаимодействия между разными системами и компонентами приложения. Становится понятно, что важность тестирования API очевидна. Стоит отметить, что и Java, и Python имеют средства работы с http в числе стандартных возможностей, но я неоднократно сталкивался с мнением, что они не слишком удобны.
И у него есть какие-то свои фишечки, ограничения, заголовки опять же. Проверок разработчик не делал, но точно я этого не знаю. Поле базовое, может есть прям во фреймворке какие-то проверки, или в интернете скопипастил… Так что тут стоит убедиться, что email корректный. Мы проверили, что система вернула в ответе «успешно создалась Машенька562», но точно ли она создалась? Может быть, разработчик сделал заглушку и пока метод в разработке, он всегда возвращает ответ в стиле “успешный успех”, ничего при этом не делая.
Смотрим на то, что все поля из требований вернулись, и что в них правильное значение. А то вдруг я сохраняю имя “Оля”, а там всегда сохраняется “Тестовый”… Очень удобно сразу автотесты писать в том же постмане, если отдельного фреймворка нет — идем по ТЗ и каждое поле выверяем. На конкретных примерах https://deveducation.com/ мы остановимся подробнее в следующих разделах. Этим и отличается API от GUI — тут нельзя снять границу из серии “убрать maxlenght”, зато можно и нужно проверить особенности API запросов. Тренер расскажет про эти понятия в привязке к примерам, но вам будет проще, если что-то почитаете заранее.
Система Вызывает Метод Другой Системы
Если лицевую часть приложения просто открывают в браузере и имитируют шаги пользователя, то получить доступ к бэкенду нельзя, так как визуального интерфейса у него нет. Если при регистрации вы указали свои реквизиты, мы подготовим и отправим счет и комплект документов. Если Вы не приложили ваши реквизиты при регистрации, то отправьте их на электронный адрес -testing.ru. Я специально делаю на «полное тестирование метода» одно задание из пяти.
А это нехорошо… Так что смотрим как система реагирует на перестановки. А дальше видим, что изменять только только через соответствующий метод. Ага, то есть если создали через REST, менять можно тоже только через REST, через SOAP нельзя.
Первым заданием курса будет повторить за тренером вызов запроса doRegister в Users через SOAP и REST, в SOAP Ui и Postman-е соответственно. Во время обучения мы уже будем считать, что базовый запрос вы отправить в инструменте можете. Лекция не входит в 5 недель обучения, она сразу доступна в системе дистанционного обучения после оплаты курса. Таким образом, в день старта обучения вам будут доступны лекции 0 и 1.
Темы Курса
Основная сущность в Postman — запрос, позволяющий получить, отправить или удалить данные из API. У нас появится код, с его помощью можно проверять запрос на исполнение. API — это набор правил, с помощью которых программы обмениваются данными друг с другом. RESTful API использует HTTP-методы (GET, POST, PUT, DELETE) для работы с ресурсами и предоставляет данные в формате JSON или XML.
Однотипные и часто повторяющиеся запросы, как правило, относятся к мониторингу сайта, а не к логике совершаемых пользователем действий. Кроме того, скорость запроса также зависит от факторов, таких как скорость сети, загруженность сервера и оптимизация кода API. Поэтому важно проводить тестирование производительности API и выбирать оптимальные методы запросов в каждой конкретной ситуации. Тестирование REST API является важной частью обеспечения качества веб-приложений. С помощью инструментов, таких как Postman, SoapUI и Rest-Assured, вы сможете эффективно проверять работоспособность и безопасность вашего API.
У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования. Чтобы создать запрос, нужно нажать на кнопку New и выбрать пункт Request. Обратите внимание на то, что мы вроде как тестируем API-метод, но после его выполнения лезем в графический интерфейс и проверяем, как там выглядит результат нашего запроса. Раз должны, то будет ошибка в случае неуникальности. А мы решили вынести тестирование негативных сценариев отдельно. Видите, решение тестировать альтернативы отдельно от негативного сразу оказалось не самым удобным — куда лучше просто читать ТЗ и каждый пункт проверять.
Лекцию можно посмотреть в удобное для вас время. Занимается тестированием с 2014 года, начав с фриланса на UTest. В «Лаборатории Качества» начал осваивать автоматизацию тестирования. Работал автоматизатором на крупном государственном проекте.
Оставьте Ваши Данные, Мы С Вами Свяжемся!
В качестве приятного бонуса я приведу небольшую пошаговую инструкцию по воспроизведению запроса в Fiddler. В свою очередь, SOAP API передает все инструкции в подробном письме стандартного вида, используя конверт (единичный HTTP-запрос) лишь как средство доставки. Для лучшего понимания разницы подходов я рекомендую читателю посмотреть следующую инфографику. Потренировавшись самостоятельно писать запросы, можно подробнее разобрать, как работают эти запросы. Чтобы запустить коллекцию тестов, зайдите во вкладку «Коллекции», выберите необходимую коллекцию и в выпадающем списке выберите «Run Collection».
Автора тоже проверили, но только вот в ТЗ он указан капсом, а по факту создается в нижнем регистре. Это уже небольшой баг, скорее всего документации, так как некритично и проще доку обновить. Сделали заметочку / сами исправили доку, если есть доступ. Значит, метод не идемпотентный… Нельзя просто взять пример из ТЗ и отправить не глядя. Это пойдут делать тестировщики, получив от вас новый функционал.
Тут то и выяснилось, что запросы исходные системы присылали “кто во что горазд”. Это постман мне настойчиво подсвечивает красным лишнюю запятую, а если вызов идет из кода и там подсветки нет, то как понять, что пошло не так? Только вот из такого текста разработчик очень долго будет угадывать, что не понравилось системе… Нехорошо, стоит завести баг. Хотя постойте… Я же выполняла не метод CreateUser, а doRegister. Его основная цель — не создать карточку, а зарегистрировать пользователя в системе. Просто при регистрации карточка автоматом создается, поэтому её тоже зацепили проверкой.
- Статус — это трехзначный код, первая цифра показывает, к какой группе он принадлежит.
- Работал автоматизатором на крупном государственном проекте.
- Обратите внимание, что вызываемый метод postRequest определен в моем фреймворке, а не в библиотеке rest-assured.
- У нас появился статус 200 ОК — это значит, что запрос успешно выполнен.
- Чтобы создать ещё один GET-запрос, данные для авторизации и проверку на код ответа 200 нужно продублировать.
Через телеграм-чат, комментарии к домашним заданиям в системе дистанционного обучения. В Postman есть встроенный компонент Collection Runner, с его помощью можно запустить наполненную запросами и тестами коллекцию. Postman автоматически добавил код на JS, который проверяет, что код ответа равен 200.
Уже на этом уровне можно что-то тестировать – например, валидацию данных на стороне сервера. Если веб-клиент в браузере не позволил вам ввести некоторые значения – в Fiddler-е вы сконструируете запрос сами. Такой способ может существенно ускорить проверку большого набора данных для ввода, особенно если изменение значений в браузере занимает длительное время. Достаточно часто по адресу endpoint-а можно догадаться, за что именно отвечает запрос к данному сервису.
Официант передаёт ваш заказ на кухню, там происходит магия, и через некоторое время перед вами появляется готовое блюдо. API работает по такому же принципу — принимает ваш запрос, передаёт информацию системе, обрабатывает её и возвращает ответ. Базовый тест тщательно выверяет каждое поле из “корректного” ответа. Проверяет, как вызов API-метода влияет на отображение в GUI… Поэтому его пропишем текстом, а остальные тесты соберем в табличку. Если в ответе сообщение об ошибке, то внимательно его изучаем.
И конечно, функции можно переиспользовать. То есть одну и ту же функцию можно включать в разные наборы, в разные апи. Получается, что разработчик придумывает, какое у него будет API. Либо делает общее, либо распределяет по функционалу или каким-то своим критериям, и в каждое апи добавляет тот набор функций, который ему необходим. API позволяет упростить процесс создания приложения путем выделения классов и операций, которые необходимы при разработке.
Мы написали в коде false, а не true, потому что у нас есть только созданные проекты, а удалённых нет. Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results.