Как эффективно использовать скрипты для Postman

Postman — это удобный инструмент для работы с API, однако часто тестировщики используют его неэффективно, вручную изменяя параметры, которые могут меняться автоматически. Разбираемся с автоматизацией в Postman вместе с Романом Масленниковым, руководителем группы тестирования IT Test.

С помощью Postman можно посылать запросы к бэкенду и работать с полученными от него ответами, проверять корректность работы бэкенда, проектировать, создавать и тестировать API. Это популярнейший сервис среди разработчиков и тестировщиков, но при этом многие не знакомы с его полным функционалом. Одни самостоятельно сравнивают структуру ответа от бэка с эталонной или сравнивают данные, пришедшие с бэка, с теми, которые мы ожидаем получить, другие — выбирают нужные данные из ответа от бэка, преобразовывают их и сохраняют в нужное место. Все это умеет делать платформа, но, судя по вопросам в чатах, посвященных автоматизации в Postman, IT-специалисты либо не находят нужной информации в сети, либо не получают ясных ответов.

1. Окружения

Окружения в контексте Postman — это набор динамических переменных, необходимых при тестировании бэкенда. Например, при авторизации пользователь вводит логин и пароль. Если пара логин+пароль валидна, то бэк присылает так называемый токен авторизации, который имеет некоторый срок действия. Мы его сохраняем в каком-либо окружении (глобальном, переменном, итерационном — в зависимости от целей и задач) и используем уже не как некое цифро-буквенное значение, а как переменную {{token}}, а цифро-буквенное значение храним в окружении. По истечении срока действия токена авторизации мы перезапрашиваем его у бэка, заменяем старое цифро-буквенное значение новым, и дальше используем уже новый токен до его истечения.

Ниже будут приведены примеры сохранения токена авторизации в окружениях.

1.1. Globals

Globals — это глобальное окружение, которое нельзя поменять (в отличие от Variables).

Записанный в Globals токен авторизации:

Записываются переменные в Globals таким скриптом на вкладке Tests:

То есть мы достаём токен из тела ответа и записываем в Globals. Подробнее этот вопрос разберём при описании функционала вкладки Tests. Чтобы использовать токен в запросах, нужно прописать его при помощи {{token-first.temp}} — в нашем случае в хедерах в authorization (переменные могут прописываться в URL, например https://{{host}}/api/auth/login; в теле запроса, например {"email" : "{{email}}", "password" : "{{password}}"}, и т.д.). Таким образом мы избавляем себя от необходимости каждый раз прописывать в запросах часто использующиеся значения вручную.

Вот как это выглядит:

1.2. Variables

Variables — это переменные окружения, которых может быть несколько и их можно создавать/удалять/переименовывать/менять в зависимости от ситуации. На скрине ниже показаны записанные в переменное окружение Test массивами коды и названия регионов:

Записываются переменные в Variables таким скриптом на вкладке Tests:

Здесь мы записываем токен авторизации в текущее переменное окружение. Используем токен так же, как и в предыдущем пункте: нужно прописать его при помощи {{token-first.temp}}.

1.3. DataFile (Run Collection -> Run Configuration)

DataFile — это файл (.json, .xlsx и т.д.), где прописаны так называемые итеративные данные (iterationData). Это нужно прежде всего для прогона тестовых ранов, где нам требуются несколько вариантов данных. На примере ниже в json-файле Test.json прописываем три разных пары email+password:

На скрине ниже видно, что у нас количество итераций — 3, то есть все наши тесты будут прогнаны три раза, каждый раз с новой парой email+password:

В теле запроса за получением токена авторизации прописана пара email+password, при каждой новой итерации запуска тестов пара будет меняться и токен авторизации в глобальном либо переменном окружении перезаписываться:

Обращаться к данным из файла можно следующим скриптом:

1.4. Приоритеты обращения к Globals, Variables, DataFile

Если мы пропишем где-то {{token-first.temp}}, то сначала Postman начнёт искать эту переменную в DataFile (если мы его подгрузили), при неудаче — в текущем переменном окружении (Variables), при повторной неудаче — в глобальном окружении (Globals). Поэтому желательно по-разному обозначать переменные в разных окружениях, чтобы избежать путаницы.

2. Вкладка Pre-request Script

Вкладка Pre-request Script, как и вкладка Tests, отвечает за работу скриптов. Здесь мы пишем код на JavaScript, нужный для работы с данными. Можем брать необходимые данные из окружений или из ответов от бэка, можем их трансформировать при помощи скриптов, можем фильтровать, отбирать нужные значения из множества, записывать новые данные в окружения, перезаписывать уже существующие данные и т.д.

Как видно из названия, вкладка Pre-request Script нужна для выполнения скриптов перед запросом, чтобы получить/трансформировать данные из окружений (Globals, Variables, DataFile) либо записать туда нужные данные.

Рассмотрим два примера.

2.1. Запись данных в окружения

Здесь мы хотим, например, записать в переменное окружение два массива данных — categoryCodes (кодовое обозначение категорий продукции) и categoryNames (словесное обозначение категорий продукции). Сделать это нужно для того, чтобы после отправки запроса и получения ответа сравнить данные в респонсе с эталонными данными, которые мы запишем в переменное окружение с помощью вкладки Pre-request Script. Пример скрипта:

Здесь мы создали два массива с четырьмя элементами каждый — categoryCodes и categoryNames — и записали их в текущее переменное окружение (до отправления запроса):

А это пример записи данных в окружение, когда для теста нужно сгенерить рандомные фейковые данные юридического лица (ИНН, КПП и т.д.), записать данные в окружение и использовать их для теста/тестов. Сделать это можно таким образом:

2.2. Трансформация данных из окружений

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

Нам нужна рандомная пара digit+regionname, чтобы в дальнейшем прогонять на ней наши тесты. Делаем это таким скриптом:

То есть достаём из переменного окружения массивы digits и regionnames, выбираем рандомные код и название региона, записываем их в переменное окружение как строковые значения reg и regname (reg строковый, т.к. у нас коды первых девяти регионов начинаются с нуля) и дальше в запросе используем эти reg и regname для необходимых проверок.

Можно придумать ещё возможные варианты использования вкладки Pre-request Script, но приведенных примеров достаточно, чтобы понять функционал этой вкладки.

3. Вкладка Tests

Это основной инструмент работы с автотестами в Postman. Ему мы уделим более пристальное внимание и приведем примеры скриптов.

3.1. Путь до параметра в ответе JSON

Задача: из ответа на запрос к https://{{host}}/api/auth/login нужно получить токен авторизации и прописать его в переменное окружение. Так как JSON может быть с большой вложенностью, то рационально воспользоваться онлайн-jsonpathfinder, например, https://jsonpathfinder.com/ или https://www.site24x7.com/tools/jsonpath-finder-validator.html. Копируем из Postman ответ и вставляем в онлайн-jsonpathfinder. Вот путь до нашего токена авторизации:

Дальше уже упоминавшаяся в первой части статьи схема:

3.2. Проверка значения ответа и времени ответа

Допустим, мы хотим проверить, что на запрос с бэка приходит 200 ОК и вывести время ответа. Сделать это можно при помощи такого скрипта:

Все кейсы в нашем ране, на запрос в которых придёт не 200 ОК, будут в статусе Failed.

3.3. Проверка валидности структуры JSON в ответе

Предположим, нам необходимо сравнить структуру JSON в ответе на запрос и эталонную структуру: проверить, что все параметры на месте, где должны быть строковые значения — действительно строковые, где числовые — числовые и пр. Для начала задаем саму эталонную структуру. Сделать это можно так:

Проверить валидность можно следующим скриптом:

При валидной структуре JSON в ответе мы получим Schema is valid и такие кейсы будут в статусе Passed. При невалидной структуре мы получим сообщение, что именно и где именно неверно, и кейсы будут в статусе Failed.

3.4. Сравнение двух массивов на соответствие

Здесь будет продемонстрирован один из нескольких способов сравнения массивов на соответствие — в зависимости от целей и задач способы могут быть другими. Допустим, у нас есть два массива — AbilitiesArray с параметрами Abilities из ответа на запрос и CheckAbilitiesArray, изначально заданный контрольный массив с эталонными параметрами. Нам нужно, чтобы массивы соответствовали друг другу.

Сначала выбираем все элементы, которые есть в массиве CheckAbilitiesArray, но отсутствуют в AbilitiesArray, и, наоборот, есть в AbilitiesArray, но отсутствуют в CheckAbilitiesArray:

Объединяем filt1 и filt2 и приводим новую сущность к массиву:

Если длина filt3 равна нулю, то массивы идентичны, если нет, пишем в консоль ошибку:

3.5. Сохранение в массив списка параметров из ответа

Допустим, на запрос к условному URL https://{{host}}/api/v1/region/list?fields=FULL приходит JSON со списком регионов вида:

Наша задача вытащить все данные из ответа и записать их в переменное окружение в виде двух массивов: digits (коды регионов, строковые значения) и regionnames (названия регионов, строковые значения). Делаем это таким скриптом:

При помощи скрипта выше мы сначала задаем два пустых массива — digits и regionnames. Затем берём первый регион из списка "Адыгея республика", помещаем имя и код в соответствующий массив; потом второй — "Алтай республика", помещаем в массив; и так по порядку до последнего региона "Ярославская область". Получается уже знакомая нам картина:

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

Больше экспертных материалов о заказной разработке, дизайне и тестировании в Telegram-канале IT Test.