Сегодня процесс проверки 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 будет иметь следующую структуру:
Отправка запроса из Postman
При первичной установке Postman пользователю становиться доступной полная коллекция «Postman Echo». Простыми словами – это персонализированный набор всех доступных запросов и ответов, которые объединены логическими цепочками.
Postman Echo специально разработан для проведения несложного тестирования API с заранее выделенными настройками, которые вы ни в коем случае не можете игнорировать.
Чтобы выполнить свой первый простой запрос нужно:
- Перейти во вкладку «Методы».
- Открыть «Запросы GET».
- Нажать кнопку «Отправить».
Ваш первый запрос сформирован и отправлен! Все очень просто и понятно.
Запросы категории POST немного сложны, но тоже понятны и логически структурированы.
В этот раз нужно создавать свой персонализированный запрос. Для этого, нажмите на «+» чтобы открыть новую страницу (вкладку), смените вид запроса с GET на POST и пропишите нужный вам URL для проведения своего теста.
Если желаете просто провести эксперимент, можно воспользоваться специальным REST-порталом, чтобы «поиграться» с ненастоящими данными –https://jsonplaceholder.typicode.com/posts
Теперь наша задача состоит в том, чтобы сформировать тело POST-запроса. Нажимаем на «body» под строкой ввода ссылки будущего запроса и меняем формат с text на JSON.
Полученный код вставляем в редактор:
Жмем на кнопку отправки. Скоро вы должны получить персонализированный ответ с введенным текстом как явное подтверждение успешности выполнения сформированного запроса.
Вы можете сохранить шаблон данного запроса для неоднократного использования в будущем. Можно даже создать определенную коллекцию подобных запросов.
Делается это очень просто:
Тесты
Хорошая особенность Postman состоит в том, что можно самостоятельно совершать автоматические запросы. Вы буквально единожды формируете тест для вашего запроса и каждый раз, когда вам приходит от сервера ответ, программа в автоматическом порядке подбирает нужный функционал согласно данным в ваших кейсах.
Также можно немного поговорить об окружении Postman.
Логично, что у каждого проекта есть свое виртуальное окружение, использующееся для тестирования и прогона создаваемого функционала.
В приложении Postman нет острой необходимости постоянно создавать запросы для каждого подобного окружения. Одновременно поддерживать массу запросов – нелогично, непрактично и в итоге будет масса расхождений.
Приложение Postman дает возможность разрабатывать пользовательское окружение с любыми переменными, которые запросто можно применять при разработке нужных Вам запросов и автоматических тестов.
В итоге
Стать настоящим профессионалом Postman за пару часов невозможно, но вещь эта — очень полезная, особенно если сравнивать ее возможности с распространенной версией Jmeter для составления самых простых автоматических запросов.
Да, в чем-то Jmeter мощнее и производительнее, но взаимодействовать с ним очень тяжело, особенно если вы новичок в данной сфере.
А вот Postman приносит истинное удовольствие при составлении простых запросов на быструю проверку работоспособности API. Уверены, что подобное может стать удобным и комфортным инструментом в руках любого тестировщика, перед которым поставлена задача провести максимально полное и исчерпывающее независимое тестирование программного обеспечения.
Оставить комментарий