Также спросил, нет ли у них swagger или чего то подобного. Если есть – супер, можно уже начать ручное тестирование – читаем документацию и пробуем. Не забываем протестировать “разнообразные варианты”. Настал день, когда команда разработки познакомилась с заказчиками. Провели онлайн-встречу, buyer показал свое веб-приложение и как с ним работать, мы задали интересующие нас вопросы и записали встречу на видео.
В API это ещё важнее, чем просто в графическом интерфейсе. Поймет ли пользователь, что именно он сделал не так, где именно ошибся? Помните, плохое сообщение тестирование api об ошибке приведет к тому, что вас будут дергать по пустякам, вырывая из контекста. Читаем, как должно быть, проверяем, как есть на самом деле.
- Запросы Postman хранятся в коллекциях, поэтому нужно не только придумать название и описание запроса, но и создать коллекцию, где он будет храниться.
- В статье речь будет идти о REST API, так как этот подход является более распространенным из-за своей относительной простоты и удобства для разработчиков.
- Подробнее о написании тестовых скриптов в Postman можно прочитать в документации или статье на Хабре.
- В «Лаборатории Качества» начал осваивать автоматизацию тестирования.
- Автора тоже проверили, но только вот в ТЗ он указан капсом, а по факту создается в нижнем регистре.
Работал автоматизатором на крупном государственном проекте. В статье речь будет идти о REST API, так как этот подход является более распространенным из-за своей относительной простоты и удобства для разработчиков. SOAP API преимущественно характерен для больших корпоративных (enterprise) систем. Вы не видите, что внутри у замка, но вы можете использовать инструменты и собственное восприятие, чтобы пощупать замок и узнать, что же у него внутри. А также вы знаете про другие замки и можете применить эту информацию к этому конкретному. Конечно, в этой ситуации сложно исполнить такую работу, не имея самого основного инструмента под рукой.
API (Application Programming Interface) – это набор инструкций и протоколов, которые позволяют программам взаимодействовать между собой. API используются для обмена данными между разными приложениями, веб-сервисами и серверами. По факту это всё то же самое, что в GUI + дополнительные тесты. В интерфейсе нельзя подвигать местами поля или изменить название поля.
Какой Запрос Быстрее?
Допустим, если в ответе придет пять ошибок, то об этих ошибках вы будете узнавать последовательно, по мере исправления предыдущей проверки и повторного запуска автотеста. Достаточно часто по адресу endpoint-а можно догадаться, за что именно отвечает запрос к данному сервису. Если трудно «выловить» нужный запрос в общей массе (а запросов к API тоже может быть немало) – очистите историю запросов перед совершением интересующего вас действия. Довольно быстро вы научитесь видеть нужные запросы и сопоставлять их с действиями в пользовательском интерфейсе. Выберите XHR (XMLHttpRequest) – это интерфейс языка JavaScript, используемый для конструирования запросов, имеющих тело. Обычно именно этот интерфейс используется для обращения к API.
Вы можете столкнуться с большим количеством однотипных запросов, порождаемых различными системами мониторинга (например, yandex.webvisor). Их можно скрыть, применив негативный фильтр (например, «-yandex» для Chrome), даже если вы не знаете точно, что именно эти запросы делают. Однотипные и часто повторяющиеся запросы, как правило, относятся к мониторингу сайта, а не к логике совершаемых пользователем действий. Между PUT и PATCH запросами скорость зависит от того, как реализована логика сервера.
Ведь потом изменится входной запрос и у нас вся интеграция сломается! А это нехорошо… Так что смотрим как https://deveducation.com/ система реагирует на перестановки. Так что прячем hidden-заголовки и проверяем без них в этом пункте.
Этот метод будет имитировать работу assert, так как в JavaScript нет этой встроенной функции или ключевого слова. Для понимания способа реализации этого метода на практике я расскажу о том, как assert работает в других языках программирования. Нельзя недооценивать скорый дедлайн, проблемы сервера с API, проблемы с интернетом и внезапное изменение API. Недостаток опыта тестирования и знаний JavaScript приведет к увеличению времени на написание автотестов. Таким образом, закладывая время на разработку тестов, старайтесь все это учесть для точной оценки сроков и качественного тестирования. Наконец, еще раз хочу напомнить, что тестирование API становится особенно востребованным в свете растущей популярности микросервисной архитектуры.
Ваш Ответ
Между PATCH и DELETE запросами скорость также зависит от логики сервера и конкретной ситуации. Оба запроса могут работать быстро, если используются оптимальные методы обработки данных на сервере. В итоге оба метода свелись к выбору между «читаемостью кода», «легкостью и скоростью реализации автотеста» и «количеству найденных ошибок при одном запуске теста». Если вы хотите быстро писать автотесты, но при этом готовы исправлять ошибки по мере их обнаружения, то используйте метод assert’ов. Если у вас есть время на продумывание структуры проверок, выявление зависимостей параметров в ответе, и вы хотите получить все ошибки сразу – используйте метод вложенных условий.
Хороший код отличает структура, оптимальность и читаемость. Мы знаем, что эта форма, скорее всего, хранит данные где-то в базе данных, и мы можем написать множество тестов, чтобы проверить, корректно ли данные сохраняются в базе. Возможно, вам уже доводилось тестировать и находить баги. Мы будем использовать эти инструменты и опыт для будущего тестирования. Если есть API, то первым делом нужно попросить документацию на него.
В нашем случае — чтобы создать пользователя в системе. И важно понимать, а что будет потом с нашими данными? Будут ли они нормально отображаться в интерфейсе? Ведь если нет, то надо ставить ограничение на API-метод. Представляйте, что написание кода – это создание баг-репорта.
Postman поддерживает множество типов авторизации, параметры для каждого из них отличаются. Используем авторизацию по API Key, полученному из личного кабинета в Test IT. Прописываем название соответствующего API, в данном случае api/register. Речь пойдёт об архитектуре REST, часто использующейся для взаимодействия сайтов и приложений. При этом активно применяется JSON (JavaScript Object Notation – текстовый формат обмена данными на языке JavaScript). Практиковать составление запросов можно, используя ресурс reqres.in.
Конечно, для понимания проще «parsed»/«pretty print», но в том случае, когда вам необходимо скопировать часть запроса, лучше переключиться в режим «source». Кроме того, скорость запроса также зависит от факторов, таких как скорость сети, загруженность сервера и оптимизация кода API. Поэтому важно проводить тестирование производительности API и выбирать оптимальные методы запросов в каждой конкретной ситуации.
Плюсом метода вложенных условий является возможность вывода нескольких ошибок одновременно. Использование ассоциативного массива и отсутствие принудительных остановок return позволяет полностью проверить ответ и остановить проверки только на определенных уровнях вложенности. В итоге вместо одной ошибки можно получить три на вкладке Tests. Также этот метод помогает понять, какие параметры зависят друг от друга в ответе, – следовательно, вы лучше понимаете и разбираетесь в API, которое тестируете.
После того как мы использовали параметры из переменных окружения, повторим запрос, чтобы проверить, что нигде не ошиблись. В ранее созданном запросе выделим в переменные два параметра — URL стенда, к которому мы обращаемся, и токен для авторизации. Создаём две переменные url и token и укажем их значения. На скриншоте ниже их значения скрыты из соображений безопасности. Переходим на вкладку Authorization, указываем данные для идентификации пользователя.
Появился в моей рабочей жизни новый проект. Веб-приложение небольшое, сроки реализации короткие (2 месяца), сам проект был интересный, и его начало, как в классическом SDLC, радовало меня. Суть проекта состояла в том, что нужно переписать фронтовую часть ПО, используя бэкенд и базу данных заказчика. Итак, начинаю свою историю в стиле сюжетной линии с завязкой, развитием действий, кульминацией развязкой и эпилогом (да, да, «как в фильмах»). И этот рассказ, думаю, должен быть познавательным для тестировщиков, которым необходимо закрыть таску по тестам без доступа к программе.
В целом, PATCH-запросы могут быть быстрее, так как они могут передавать только измененные поля объекта. Раз должны, то будет ошибка в случае неуникальности. А мы решили вынести тестирование негативных сценариев отдельно.
Только вот из такого текста разработчик очень долго будет угадывать, что не понравилось системе… Нехорошо, стоит завести баг. Это как раз особенность API, поэтому очень важно её проверить. Бизнес-логика и проверки “а что можно ввести в такое-то поле” одинаковы для GUI и API, а вот переставить поля местами в графическом интерфейсе не получится. На конкретных примерах мы остановимся подробнее в следующих разделах. Этим и отличается API от GUI — тут нельзя снять границу из серии “убрать maxlenght”, зато можно и нужно проверить особенности API запросов. Потому что нет абстрактных методов, которые делают “ничего”, просто отправляются.
Например, у меня был случай, когда на проекте обновили библиотеку и она стала намного жестче с ошибкам интеграции. Тут то и выяснилось, что запросы исходные системы присылали “кто во что горазд”. Обратите внимание на то, что мы вроде как тестируем API-метод, но после его выполнения лезем в графический интерфейс и проверяем, как там выглядит результат нашего запроса.
Оптимальность кода достигается тщательным продумыванием каждой строчки и отсечением всего лишнего; при этом алгоритм должен выполняться за минимальное число шагов. В качестве приятного бонуса я приведу небольшую пошаговую инструкцию по воспроизведению запроса в Fiddler. В свою очередь, SOAP API передает все инструкции в подробном письме стандартного вида, используя конверт (единичный HTTP-запрос) лишь как средство доставки. Для лучшего понимания разницы подходов я рекомендую читателю посмотреть следующую инфографику.
Одно неуспешное нажатие кнопки может привести к необходимости повторения либо всего теста, либо какой-то его части. Сформировав запрос программно или воспроизведя его с помощью специальных инструментов (об этом чуть позже), мы можем существенно сократить время проверки. Для начала постараемся понять, зачем вообще тестировщику осваивать что-либо на таком уровне.