Одним из них является REST — стандарт архитектуры взаимодействия приложений и сайтов, использующий протокол HTTP. Особенность REST в том, что сервер не запоминает состояние пользователя между запросами. Иными словами, идентификация пользователя (авторизационный токен) и все параметры выполнения операции передаются в каждом запросе. Этот подход настолько прост и удобен, что почти вытеснил все другие. Для упрощения работы тестировщики используют дополнительные инструменты.
Если требуется обновление объекта, то используется PUT-запрос, который может быть быстрее, если изменения касаются большинства полей объекта. В методе assert’ов меньше проблем с читаемостью кода по сравнению с методом вложенных условий. Реализация этого метода проще, так как метод вложенных условий требует тщательного продумывания приоритета проверки в условии if. Например, вы можете проверить, соответствует ли статус ответа ожидаемому (statusCode(expectedStatus)) и содержит ли тело ответа определенный фрагмент текста (body(containsString(«www»))). Команда extract() позволяет получить ответ и использовать его, например, для извлечения определенных значений. Открывается окошко для написания кода на JavaScript.
Не забывайте про приоритет тестов для их логически правильного выстраивания. В данном методе тесты слабо зависят друг от друга, т.е. Вы можете сначала проверить, пустое ли тело ответа, затем – какое вернулось значение у параметра тестирование api «часть речи», а потом – код 200. При первой найденной ошибке метод завершает свою работу и отправляет эту ошибку на вкладку Tests. Постигнув принципы работы API, вы можете использовать эти навыки в автоматизированных тестах.
Что Тестируем В Ответе
Это пойдут делать тестировщики, получив от вас новый функционал. И это же сделает разработчик интеграции / другой пользователь API. Но лично я всё же считаю, что как минимум основной сценарий позитивный проверить надо.
- Тут ничего сложного нет и зависит только от Ваших возможностей и того, что есть в компании.
- Если у вас в системе два интерфейса — SOAP и REST, нужно проверить оба.
- Для понимания способа реализации этого метода на практике я расскажу о том, как assert работает в других языках программирования.
- Посмотрим, что предлагает Postman, и как это работает.
И тут опять или писать около примера, что “$randomInt — переменная Postman, она тут для того-то”, или всё же примеры оставить в покое. Они вполне могут скопипастить пример, отправить его, получить ошибку и прибежать в поддержку ругаться, не читая сообщение об ошибке — у вас плохой пример, он не работает. Занимается тестированием с 2014 года, начав с фриланса на UTest. В «Лаборатории Качества» начал осваивать автоматизацию тестирования.
Немного О Rest Api И Soap Api
Запросы Postman хранятся в коллекциях, поэтому нужно не только придумать название и описание запроса, но и создать коллекцию, где он будет храниться. Чтобы рассказать, как использовать Postman, напишем несколько тестов на базе реального проекта, используя для этого API системы управления тестированием Test IT. Тестирование REST API является важной частью тестирования веб-приложений и может быть выполнено с использованием различных инструментов, таких как Postman, SoapUI, JMeter и других. Если вы начинающий тестировщик, то знание API может быть полезным для вас, так как API-тестирование может помочь выявлять ошибки и улучшать качество приложения. В соответствующем поле видим ожидаемый результат, указанный в документации и статус 200 ОК. Рассмотрим регистрацию пользователя, поэтому указываем соответствующее название и нажимаем на Save to [Collections name].
Сделали заметочку / сами исправили доку, если есть доступ. Автор у него всегда будет «SOAP / REST», изменять его можно только через соответствующий-метод. В идеале он берет этот сценарий из примера. Если примеров нет, будет дергать метод наобум, как он считает правильным. Знаете, как с новым девайсом — сначала попробовал сам, если не получилось, пошел читать инструкцию. Чтобы настраивать интеграцию, разработчику той стороны нужен работающий сценарий.
Небольшая часть тестирования посвящена убеждению, что ПО делает то, что должно. Оставшаяся, довольно крупная часть – убеждению, что оно НЕ делает того, что НЕ должно. Когда мы берем часть продукта и не знаем толком, что у него происходит внутри – “внутри ящика”, так сказать – мы используем черноящичное тестирование. Ещё один вариант – попросить программистов в программе сделать возможность вызывать это апи в контексте приложения (какое-то отладочное меню). Если уже нужно писать ручками, то тут варианты разнообразные – от curl/wget в консоли и питона до Postman. При помощи материалов можно начать тестировать программный продукт – даже если нет возможности самостоятельно изучить ПО.
Официант передаёт ваш заказ на кухню, там происходит магия, и через некоторое время перед вами появляется готовое блюдо. API работает по такому же принципу — принимает ваш запрос, передаёт информацию системе, обрабатывает её и возвращает ответ. API — это Application Programming Interface, или программный интерфейс приложения, с помощью которого одна программа может взаимодействовать с другой. API позволяет слать информацию напрямую из одной программы в другую, минуя интерфейс взаимодействия с пользователем. RESTful API использует HTTP-методы (GET, POST, PUT, DELETE) для работы с ресурсами и предоставляет данные в формате JSON или XML.
А дальше видим, что изменять только только через соответствующий метод. Ага, то есть если создали через REST, менять можно тоже только через REST, через SOAP нельзя. Автора тоже проверили, но только вот в ТЗ он указан капсом, а по факту создается в нижнем регистре. Это уже небольшой баг, скорее всего документации, так как некритично и проще доку обновить.
После митинга наша команда получила все необходимые документации, инструкций, руководства пользователя и исходники программы. Создали звонок с командой разработки, познакомились друг с другом. Проект-менеджер показал цели проекта, архитектурное решение, план работ, примерные даты окончания этапов и ответственных сотрудников за области разработки. Но нам нужно проверить, что запрос отрабатывает при самом банальном позитивном тесте. Приходит позитивный ответ – происходят соответствующие изменения, если они должны происходить, и не происходят, если мы просто интересуемся. Представьте, что вы сидите в ресторане, выбираете блюдо в меню.
Такой баг разработчик может не захотеть исправлять, “пусть присылают по документации”. Ну что же, тогда единственным аргументом будет потом количество обращений в поддержку. Проверок разработчик не делал, но точно я этого не знаю. Поле базовое, может есть прям во фреймворке какие-то проверки, или в интернете скопипастил… Так что тут стоит убедиться, что e mail корректный. Хотя постойте… Я же выполняла не метод CreateUser, а doRegister. Его основная цель — не создать карточку, а зарегистрировать пользователя в системе.
Система пишет «Некоректный email Имечко 666». Это значит, что она ориентируется не названия полей, передаваемые в тегах, а на их порядковых номер. И это ОЧЕНЬ ПЛОХО, на такое стоит идти ставить баг. Более того, это даже может быть нормально! Например, исходно писался только SOAP-интерфейс, и было правило возвращать все поля, даже пустые.
Мы проверили, что система вернула в ответе «успешно создалась Машенька562», но точно ли она создалась? Может быть, разработчик сделал заглушку и пока метод в разработке, он всегда возвращает ответ в стиле “успешный успех”, ничего при этом не делая. То есть берём REST-часть и обычную, применяем тест-дизайн, словно это параметр в графическом интерфейсе.
Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results. Использование любого из рассмотренных методов при обнаружении хотя бы одной ошибки позволяет сократить время выполнения автотестов для проверки API.
Но не стоит паниковать, так как моим выходом оказалось то самое видео со встречи с заказчиком. После вопроса от менеджера проекта сразу появляется задача «Составить тесты к ПО». И, к тому же, эта таска должна быть выполнена уже вчера. После всех манипуляций взялась за разработку «скелета» стратегии тестирования и плана демонстрации.
У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования. Чтобы создать запрос, нужно нажать на кнопку New и выбрать пункт Request. API может быть внутренним, частным — когда программные компоненты связаны между собой и используются внутри системы. А может быть открытым, публичным — в таком случае он позволяет внешним пользователям или другим программам получать информацию, которую можно интегрировать в свои приложения. Postman — это популярный инструмент для тестирования API.
Возможно, у них уже есть что то для такого тестирования (хороший вариант ответа – “пойду спрошу тим/тех лида, может кто то уже делал подобное”). Если есть вопросы к документации, они должны всплыть сейчас. Возможно, есть смысл доработать доку или даже добавить какие-то проверки в новой задаче. Далее можно посмотреть на результаты тестов по каждому запросу, экспортировать результаты по кнопке Export Results либо пролистать их в кратком виде по кнопке Run Summary. В Postman есть встроенный компонент Collection Runner, с его помощью можно запустить наполненную запросами и тестами коллекцию. Postman автоматически добавил код на JS, который проверяет, что код ответа равен 200.
Пользователь когда получает ожидаемый результат – страницу с запрашиваемой информацией. Postman использует протокол HTTP для взаимодействия между серверами. Он доступен как в веб-версии, так и в виде настольного приложения с графическим интерфейсом. 1 000 символов — ищем верхнюю границу, если она есть. Заодно смотрим, как это выглядит в интерфейсе и корректируем тест. А так — бизнес-логику смотрим один раз, а потом переходим в особенностям API.
Помимо всего прочего, коды ответов, как правило, несут полезную информацию и сообщают о логике происходящего. Большинство запросов имеют код ответа «200 OK», сообщающий о том, что операция выполнена успешно. В случае возникновения ошибки коды будут начинаться на four https://deveducation.com/ (ошибка на стороне клиента) или на 5 (ошибка на стороне сервера). Например, таковы всем известные ошибки 404 («клиент запросил несуществующий ресурс») и 500 («внутренняя ошибка сервера»).
Просто при регистрации карточка автоматом создается, поэтому её тоже зацепили проверкой. Тем не менее у разработчика есть основной позитивный сценарий его системы, его он и будет проверять. И тестировщик должен проверить его в первую очередь. Разработчики же должны написать код, используя ваш пример. А они тоже любят копипастить))) И если дать пример, заточенный под постман, то к вам снова придут с вопросом, почему ваш пример не работает, но уже в коде.
