Автоматизация Тестирования Relaxation Api При Помощи Postman И Javascript Лаборатория Качества

Мы проверили, что система вернула в ответе «успешно создалась Машенька562», но точно ли она создалась? Может быть, разработчик сделал заглушку и пока метод в разработке, он всегда возвращает ответ в стиле “успешный успех”, ничего при этом не делая. То есть берём REST-часть и обычную, применяем тест-дизайн, словно это параметр в графическом интерфейсе.

Не забывайте про приоритет тестов для их логически правильного выстраивания. В данном методе тесты слабо зависят друг от друга, т.е. Вы можете сначала проверить, пустое ли тело ответа, затем – какое вернулось значение у параметра «часть речи», а потом – код 200. При первой найденной ошибке метод завершает свою работу и отправляет эту ошибку на вкладку Tests. Постигнув принципы работы API, вы можете использовать эти навыки в автоматизированных тестах.

• Но не стоит паниковать, так как моим выходом оказалось то самое видео со встречи с заказчиком.
• Конечно, в этой ситуации сложно исполнить такую работу, не имея самого основного инструмента под рукой.
• Плюсом метода вложенных условий является возможность вывода нескольких ошибок одновременно.
• К тому же в SOAP всегда есть схема WSDL, где указаны обязательные поля.

Здесь представлены разные Request и ожидаемые результаты (Response). Это и будет тренировочным API с документацией. Под пользователем можно войти в систему — нажимаем “Войти”, вводим емейл из запроса, пароль из запроса, проверяем авторизацию.

Документация, Необходимая Тестировщику Для Обучения

Одним из них является REST — стандарт архитектуры взаимодействия приложений и сайтов, использующий протокол HTTP. Особенность REST в том, что сервер не запоминает состояние пользователя между запросами. Иными словами, идентификация пользователя (авторизационный токен) и все параметры выполнения операции передаются в каждом запросе. Этот подход настолько прост и удобен, что почти вытеснил все другие. Для упрощения работы тестировщики используют дополнительные инструменты.

А дальше видим, что изменять только только через соответствующий метод. Ага, то есть если создали через REST, менять можно тоже только через REST, через SOAP нельзя. Автора тоже проверили, но только вот в ТЗ он указан капсом, а по факту создается в нижнем регистре. Это уже небольшой баг, скорее всего документации, так как некритично и проще доку обновить.

One Thought On “автоматизация Тестирования Rest Api При Помощи Postman И Javascript”

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

Просто при регистрации карточка автоматом создается, поэтому её тоже зацепили проверкой. Тем не менее у разработчика есть основной позитивный сценарий его системы, его он и будет проверять. И тестировщик должен проверить его в первую очередь. Разработчики же должны написать код, используя ваш пример. А они тоже любят копипастить))) И если дать пример, заточенный под постман, то к вам снова придут с вопросом, почему ваш пример не работает, но уже в коде.

Хорошая Структура – Быстрый Анализ Ошибок

Если требуется обновление объекта, то используется PUT-запрос, который может быть быстрее, если изменения касаются большинства полей объекта. В методе assert’ов меньше проблем с читаемостью кода по сравнению с методом вложенных условий. Реализация этого метода проще, так как метод вложенных условий требует тщательного продумывания приоритета проверки в условии if. Например, вы можете проверить, соответствует ли статус ответа ожидаемому (statusCode(expectedStatus)) и содержит ли тело ответа определенный фрагмент текста (body(containsString(«www»))). Команда extract() позволяет получить ответ и использовать его, например, для извлечения определенных значений. Открывается окошко для написания кода на JavaScript.

Помимо всего прочего, коды ответов, как правило, несут полезную информацию и сообщают о логике происходящего. Большинство запросов имеют код ответа «200 OK», сообщающий о том, что операция выполнена успешно. В случае возникновения ошибки коды будут начинаться на 4 (ошибка на стороне клиента) или на 5 (ошибка на стороне сервера). Например, таковы всем известные ошибки 404 («клиент запросил несуществующий ресурс») и 500 («внутренняя ошибка сервера»).

Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results. Использование любого из рассмотренных методов при обнаружении хотя бы одной ошибки позволяет сократить время выполнения автотестов для проверки API.

Выполним запрос на получение данных о созданном пользователе, выбираем GET. К тому же в SOAP всегда есть схема WSDL, где указаны обязательные поля. В ресте же схема WADL необязательна, да и там любят придерживаться принципа минимальных чернил, лишнего не выводить. Ищем «хранителя информации», расспрашиваем, проверяем, как работает на самом деле. Думаем, есть ли проблемы в текущем поведении.

Обсудите со своими разработчиками, как им будет удобнее — чтобы вы сначала потыкали “на слом” и прислали очевидные баги, или вдумчиво проверили всё и прислали результат одним файлом. Ну и плюс всё зависит от времени, если вам позитивные тесты погонять займет полчасика, то проще начать с них. А если там куча сценариев + обязательные автотесты часа на 4, то можно сначала погонять руками, выдать пачку замечаний и сидеть спокойно писать свои тесты. Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А потом мы обсудим каждый пункт — зачем это проверять и как.

Пользователь когда получает ожидаемый результат – страницу с запрашиваемой информацией. Postman использует протокол HTTP для взаимодействия между серверами. Он доступен как в веб-версии, так и в виде настольного приложения с тестирование api графическим интерфейсом. 1 000 символов — ищем верхнюю границу, если она есть. Заодно смотрим, как это выглядит в интерфейсе и корректируем тест. А так — бизнес-логику смотрим один раз, а потом переходим в особенностям API.

Такой баг разработчик может не захотеть исправлять, “пусть присылают по документации”. Ну что же, тогда единственным аргументом будет потом количество обращений в поддержку. Проверок разработчик не делал, но точно я этого не знаю. Поле базовое, может есть прям во фреймворке какие-то проверки, или в интернете скопипастил… Так что тут стоит убедиться, что e-mail https://deveducation.com/ корректный. Хотя постойте… Я же выполняла не метод CreateUser, а doRegister. Его основная цель — не создать карточку, а зарегистрировать пользователя в системе.

Это пойдут делать тестировщики, получив от вас новый функционал. И это же сделает разработчик интеграции / другой пользователь API. Но лично я всё же считаю, что как минимум основной сценарий позитивный проверить надо.

Возможно, у них уже есть что то для такого тестирования (хороший вариант ответа – “пойду спрошу тим/тех лида, может кто то уже делал подобное”). Если есть вопросы к документации, они должны всплыть сейчас. Возможно, есть смысл доработать доку или даже добавить какие-то проверки в новой задаче. Далее можно посмотреть на результаты тестов по каждому запросу, экспортировать результаты по кнопке Export Results либо пролистать их в кратком виде по кнопке Run Summary. В Postman есть встроенный компонент Collection Runner, с его помощью можно запустить наполненную запросами и тестами коллекцию. Postman автоматически добавил код на JS, который проверяет, что код ответа равен 200.

Небольшая часть тестирования посвящена убеждению, что ПО делает то, что должно. Оставшаяся, довольно крупная часть – убеждению, что оно НЕ делает того, что НЕ должно. Когда мы берем часть продукта и не знаем толком, что у него происходит внутри – “внутри ящика”, так сказать – мы используем черноящичное тестирование. Ещё один вариант – попросить программистов в программе сделать возможность вызывать это апи в контексте приложения (какое-то отладочное меню). Если уже нужно писать ручками, то тут варианты разнообразные – от curl/wget в консоли и питона до Postman. При помощи материалов можно начать тестировать программный продукт – даже если нет возможности самостоятельно изучить ПО.

Сделали заметочку / сами исправили доку, если есть доступ. Автор у него всегда будет «SOAP / REST», изменять его можно только через соответствующий-метод. В идеале он берет этот сценарий из примера. Если примеров нет, будет дергать метод наобум, как он считает правильным. Знаете, как с новым девайсом — сначала попробовал сам, если не получилось, пошел читать инструкцию. Чтобы настраивать интеграцию, разработчику той стороны нужен работающий сценарий.

Система пишет «Некоректный  email Имечко 666». Это значит, что она ориентируется не названия полей, передаваемые в тегах, а на их порядковых номер. И это ОЧЕНЬ ПЛОХО, на такое стоит идти ставить баг. Более того, это даже может быть нормально! Например, исходно писался только SOAP-интерфейс, и было правило возвращать все поля, даже пустые.

У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования. Чтобы создать запрос, нужно нажать на кнопку New и выбрать пункт Request. API может быть внутренним, частным — когда программные компоненты связаны между собой и используются внутри системы. А может быть открытым, публичным — в таком случае он позволяет внешним пользователям или другим программам получать информацию, которую можно интегрировать в свои приложения. Postman — это популярный инструмент для тестирования API.

Запросы Postman хранятся в коллекциях, поэтому нужно не только придумать название и описание запроса, но и создать коллекцию, где он будет храниться. Чтобы рассказать, как использовать Postman, напишем несколько тестов на базе реального проекта, используя для этого API системы управления тестированием Test IT. Тестирование REST API является важной частью тестирования веб-приложений и может быть выполнено с использованием различных инструментов, таких как Postman, SoapUI, JMeter и других. Если вы начинающий тестировщик, то знание API может быть полезным для вас, так как API-тестирование может помочь выявлять ошибки и улучшать качество приложения. В соответствующем поле видим ожидаемый результат, указанный в документации и статус 200 ОК. Рассмотрим регистрацию пользователя, поэтому указываем соответствующее название и нажимаем на Save to [Collections name].