Бизнес-логика и проверки “а что можно ввести в такое-то поле” одинаковы для GUI и API, а вот переставить поля местами в графическом интерфейсе не получится. После того как мы проверили соглашение API, мы можем поразмышлять о том, что тестировать. Независимо от того, думаете ли вы об автоматизации тестирования или ручном тестировании, наши функциональные тест-кейсы имеют одинаковый набор тестовых действий. Они являются частью более широких категорий тестовых сценариев и их можно разделить на три потока тестирования. Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. Становится понятно, что важность тестирования API очевидна.
В ранее созданном запросе выделим в переменные два параметра — URL стенда, к которому мы обращаемся, и токен для авторизации. Назовём наше окружение Test Environment. Создаём две переменные url и token и укажем их значения. На скриншоте ниже их значения скрыты из соображений безопасности. Система пишет «Некоректный e-mail Имечко 666».
Собеседование Qa: Тестирование Api
Слой API любого приложения – один из важнейших программных компонентов системы. Это канал, который соединяет клиента с сервером (или один микросервис с другим), управляет бизнес-процессами и представляет сервисы, которые приносят пользу пользователям. После запуска в Postman стоит создать папку с коллекцией запросов. Для этого нужно во вкладке Collections нажать на New Collection.
Юнит-тестирование имеет дело с небольшими модулями и компонентами и сравнительно проще; тестирование API намного более сложный процесс. Тестирование API направлено на бизнес-логику, передачу данных, безопасность, https://deveducation.com/ и производительность. Тестирование интерфейса проверяет «вид и ощущения» от продукта, вплоть до размещения и удобства кнопок, форм и т.п. Postman предлагает внушительный список, нам нужен GET.
Итак, Какие Аспекты Api Мы Должны Протестировать?
Чтобы рассказать, как использовать Postman, напишем несколько тестов на базе реального проекта, используя для этого API системы управления тестированием Test IT. API может быть внутренним, частным — когда программные компоненты связаны между собой и используются внутри системы. А может быть открытым, публичным — в таком случае он позволяет внешним пользователям или другим программам получать информацию, которую можно интегрировать в свои приложения. Представьте, что вы сидите в ресторане, выбираете блюдо в меню. Официант передаёт ваш заказ на кухню, там происходит магия, и через некоторое время перед вами появляется готовое блюдо. API работает по такому же принципу — принимает ваш запрос, передаёт информацию системе, обрабатывает её и возвращает ответ.
- Тем не менее у разработчика есть основной позитивный сценарий его системы, его он и будет проверять.
- Наша первая задача – это функциональное тестирование, чтобы убедиться, что API работает правильно.
- Чтобы программам общаться между собой, их API нужно построить по единому стандарту.
- Знаете, как с новым девайсом — сначала попробовал сам, если не получилось, пошел читать инструкцию.
Открывается окошко для написания кода на JavaScript. Postman предлагает множество готовых сниппетов, которые можно применить для тестирования API. Здесь можно валидировать коды и содержание ответов, парсить и сохранять значения в переменные окружения или глобальные переменные, проверять их соответствие заданным значениям и т.д.
Запросы Postman хранятся в коллекциях, поэтому нужно не только придумать название и описание запроса, но и создать коллекцию, где он будет храниться. У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования. Чтобы создать запрос, нужно нажать на кнопку New и выбрать пункт Request.
Особенность REST в том, что сервер не запоминает состояние пользователя между запросами. Иными словами, идентификация пользователя (авторизационный токен) и все параметры выполнения операции передаются в каждом запросе. Этот подход настолько прост и удобен, что почти вытеснил все другие. Теперь создадим другое окружение, с другими URL и token, и поменяем их с помощью переключения в выпадающем списке. Протестируем продукт на двух разных окружениях, используя одну коллекцию запросов. Сначала отправляем базовый запрос и там, и там, как в документации.
Если оставить true, тест будет провален. Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results. API (Application Programming Interface) — это набор определений, протоколов и инструментов, которые позволяют разработчикам создавать и интегрировать приложения. В сфере тестирования ПО, тестирование API играет важную роль, поскольку оно проверяет правильность работы взаимодействия между разными системами и компонентами приложения.
Это некий стандарт, дефолтные значения по умолчанию. Тот же Cache-Control, раз вы его не передаете, по факту он вам не нужен, то есть как если бы вы указали “no-cache”. Так что проверки на емейл нужны, особенно — на некорректный.
Этим и отличается API от GUI — тут нельзя снять границу из серии “убрать maxlenght”, зато можно и нужно проверить особенности API запросов. Мы проверили, что система вернула в ответе «успешно создалась Машенька562», но точно ли она создалась? Может быть, разработчик сделал заглушку и пока метод в разработке, он всегда возвращает ответ в стиле “успешный успех”, ничего при этом не делая. Они вполне могут скопипастить пример, отправить его, получить ошибку и прибежать в поддержку ругаться, не читая сообщение об ошибке — у вас плохой пример, он не работает. Самое простое, что можно сделать — дернуть пример из документации, чтобы посмотреть, как метод вообще работает.