Рейтинг: 4.0/5. на основе 2 оценок.
Пожалуйста, подождите...

Сегодня процесс проверки REST API является наиболее актуальной и обсуждаемой темой в среде интеграционного тестирования. Далее в нашей статье мы детализировано разберем программные возможности утилиты Postman, которая как раз и используется в качестве основного компонента для проведения тестов REST API, детально изучим парочку методов написания подобных тестов на базе реального проекта (взятого конечно из сети – Яндекс. Словарь).

Процесс планирования тестирования

Перед тем как начинать писать программный код, следует ответить на некоторые вопросы: «какие методы в первую очередь буду тестироваться», «как именно будет проходить процесс тестов», «какие неурядицы и трудности у нас могут возникнуть».

Разберем каждый нюанс детально.

Какие методы будут тестироваться в первую очередь?

Отвечая на этот вопрос, в первую очередь стоит обратиться к документации проекта. В данном случае в «Яндекс. Словарь» описано всего 2 метода (lookup и getLangs) и парочку параметров к каждому из них.

Как именно будет проходить процесс тестов?

В первую очередь, перед тем как выбрать наиболее подходящую для нас технику выполнения проверок, нужно внимательно проанализировать имеющиеся параметры для каждого метода API. Исходные данные параметров на практике бывают разными, это может банальное число, объект из списка значений или другие виды данных.

Для использования каждого из подобных параметров нужно применять свой оригинальный подход: к примеру, при условии что параметр – это простое число с допустимым значением (максимальным), что случиться при отправке запроса в виде простого числа, существенно превышающего данное значение? Если наше API функционирует верно, то в предоставленном нами ответе можно будет обнаружить критическую ошибку с данными значением; полное отсутствие ошибки будет красноречиво свидетельствовать о том, что API работает неверно.

Для создания группы тестов исходных параметров можно применять различные техники тест-дизайна (к примеру, группы эквивалентности, допустимые значения и методики парных тестов).

Какие неурядицы и трудности у нас могут возникнуть?

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

То есть, выделяя время на создание и проверку тестов, нужно учитывать максимальное число возможных ситуаций, которые могут возникнуть на этапе разработки программного обеспечения.

Оптимизированная структура

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

Приемлемый код отличается продуманной структурой, хорошей читаемостью и оптимальностью.

Чтобы код всегда был читаемым, нужно применять несколько действенных практик:

  • Всегда старайтесь следовать отступам в блоках функций, заданных условий и циклов;
  • Присваивайте переменным лаконичные и понятные имена;
  • Не стоит создавать массу логических выражений внутри условной конструкции;
  • Применяйте обыкновенные функции, без использования встроенных условий языков программирования.

Чтобы ваш код всегда был легко читаем и понятен, нужно весьма тщательно прорабатывать его структуру и наполненность. Все указанные вами алгоритмы должны выполнять максимально число шагов, без допущения каких-либо системных ошибок.

Для того чтобы достичь полной оптимальность и максимальной структурности программного кода при написании тестов для проверки API, стоит отдельно поговорить о двух методах – вложений и asserts.

Метод вложенных условий

Значение данного метода заключается в следующем: каждая проверка, которая должна проводиться, должна быть детально описана во вложенном условии if else. Метод хорош тем, что если какая-то часть программы Postman не хочет работать и проверять функционирование вашего API, то остальные структуры тоже не будут проходить заданную проверку.

Специалист QA максимально экономит свое время для проверки методов API, и сразу же может понять, в чем именно возникла причина и как с нею бороться.

Яркий пример составления очень плохого кода:

Пример плохого кода

Пример плохого кода

Но чтобы данный метод работал идеально, тестировщик самостоятельно должен расставить нужные приоритеты своими тестами, уяснить для себя их последовательность выполнения, а также логически продумать, что может еще сломаться в будущем и при каких условиях.

Яркий пример: большой приоритет будет присвоен коду статуса.

Если хотелось увидеть код 200, а «прибыло» что-то явно другое, уже можно не продолжать – банально выводим статус об ошибке «входящий код не 200».

Затем стоит проверить есть ли какой либо ответ: если его нет – также выводим явную ошибку.

Баг в данной ситуации состоит в следующем: тестировщики создают ассоциативный массив со значением false, а подключенные логические проверки приобретают условие if.

На практике реализация данного метода выглядит подобным образом:

Метод вложенных условий

Метод вложенных условий

Метод Asserts

Данный подход будет максимально реалистично имитировать функционирование группы assert, ведь в JavaScript нет подобной встроенной функции или определенного ключевика. Чтобы максимально полно понять данный метод, стоит разобраться, как действует assert в других языках программирования.

Как известно, Assert – это специализированный метод вызова программной ошибки, полное прекращение работы программы: в некоторых случаях может передаваться какой либо пользовательский текст. В сфере программирования, assert применяться по заданному алгоритму – если возникла техническая ошибка, нужно вызвать нужное исключение с детализированным описанием ее.

Автоматический тест проверки API с использованием метода assert будет иметь следующую структуру:

Метод Asserts

Метод Asserts

Отправка запроса из Postman

При первичной инсталляции Postman, пользователю становиться доступной полная коллекция «Postman Echo». Простыми словами – это персонализированный набор всех доступных запросов и ответов, которые объединены логическими цепочками.

Postman Echo специально разработан для проведения несложного тестирования API с заранее выделенными настройками, которые вы ни в коем случае не можете игнорировать.

Чтобы выполнить свой первый простой запрос нужно:

  • Перейти во вкладку «Методы»;
  • Открыть «Запросы GET»;
  • Нажать кнопку «Отправить».

Ваш первый запрос сформирован и отправлен! Все даже очень просто и понятно.

Запрос

Запрос

Запросы категории POST немного сложны, но тоже понятны и логически структурированы.

В этот раз нужно создавать свой персонализированный запрос. Для этого, нажмите на «+» чтобы открыть новую страницу (вкладку), смените вид запроса с GET на POST и пропишите нужный вам URL для проведения своего теста.

Если желаете просто провести эксперимент, можно воспользоваться специальным REST-порталом, чтобы «поигратся» с ненастоящими данными  –https://jsonplaceholder.typicode.com/posts

Теперь наша задача состоит в том, чтобы сформировать тело POST-запроса. Жмем мышкой на «body» под строкой ввода ссылки будущего запроса, меняет формат с text на JSON.

Полученный код вставляем в редактор:

Тело POST-запроса

Тело POST-запроса

Жмем на кнопку «отправки». Скоро вы должны получить персонализированный ответ с введенным текстом, как явное подтверждение успешности выполнения сформированного запроса.

Вы можете сохранить шаблон данного запроса для неоднократного использования в будущем. Можно даже создать определенную коллекцию подобных запросов.

Делается это очень просто:

Коллекция запросов

Коллекция запросов

Тесты

Хорошая особенность Postman состоит в том, что можно самостоятельно совершать автоматические запросы. Вы буквально единожды формируете тест для вашего запроса, и каждый раз, когда вам приходит от сервера ответ, программа в автоматическом порядке подбирает нужный функционал согласно данным в ваших кейсах.

Также можно немного поговорить об окружении Postman.

Логично, что у каждого проекта есть свое виртуальное окружение, использующееся для тестирования и прогона создаваемого функционала.

В приложении Postman нет острой необходимости постоянно создавать запросы для каждого подобного окружения. Одновременно поддерживать массу запросов – не логично, не практично, и будет масса расхождений.

Приложение Postman дает возможность разрабатывать пользовательское окружение с любыми переменными, которые запросто можно применять при разработке нужных вам запросов и автоматических тестов.

В итоге

Стать настоящим профессионалом Postman за пару часов невозможно, но штука это очень полезная, особенно если сравнивать ее возможности с распространенной версией Jmeter для составления самых простых автоматических запросов.

Да, в чем-то Jmeter мощнее и производительнее, но взаимодействовать с ним очень тяжело, особенно если ты простой новичок в сфере.

А вот Postman – истинное удовольствие при составлении простых запросов на быструю проверку работоспособности API. Уверенны, что подобная «штука» может стать удобным и комфортным инструментом в руках любого тестировщика, перед которым поставлена задача провести максимально полное и исчерпывающееся тестирование проекта.

Оставить комментарий