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

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