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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

If-Else

If-Else

Специалист 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. Уверены, что подобное может стать удобным и комфортным инструментом в руках любого тестировщика, перед которым поставлена задача провести максимально полное и исчерпывающее независимое тестирование программного обеспечения.

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