Всем привет! Я старший преподаватель направления функционального тестирования в «ЛАНИТ Экспертиза». К нам в штат приходят люди из разных профессий и с разным уровнем знаний. Поэтому в компании организованы курсы обучения практикам тестирования, которые уже стали базовыми. Одной из них является тестирование с помощью API запросов, или, как его еще называют, тестирование API. И сегодня для тех, кто этим занимается, я постараюсь доступным языком рассказать, как использовать этот формат для описания тестовых данных, подключаемых к прогонам коллекций в Postman.

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

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

Поиски решений приводят интересующихся к возможности подключать к прогонам коллекций тестовые данные из внешних файлов. Postman позволяет делать это в форматах CSV и JSON.

Как я уже говорил ранее, мы используем CSV-файлы для подгрузки тестовых данных в автопрогонах коллекций запросов. Однако этот формат не очень удобен в визуальном представлении. Конечно, если у нас с вами буквально пара строк итераций и несколько переменных, то проблем не возникнет. А если их сотни и больше, то отслеживание соответствия значений каким-то переменным может стать не самой простой задачей, требующей большой внимательности.

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

Формирование содержимого файла

Правила синтаксиса все те же, без каких-либо нюансов. Каждая пара «ключ-значение» в таком JSON'е должна восприниматься как имя переменной и ее значение. Так же, как и во всех уже известных вам примерах работы с переменными, вы можете назвать все переменные, как вам заблагорассудится. Просто если ее имя будет совпадать в той или иной степени с именем ключа из отправляемого в запросе тела, то будет легче сориентироваться в том, какие данные и куда подключаются.

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

Вы можете использовать любой удобный вам редактор текста. Я использую для этого NotePad ++.

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

Подключение этого JSON'а в Postman ничем не отличается от подключения CSV-файла. Конечно же, для отправки такого простого объекта в единичном экземпляре внешний файл не нужен. Можно и руками сделать. Поэтому предлагаю обратить внимание, как правильно сформировать  набор данных для нескольких итераций прогона. Давайте дополним этот вариант JSON'а ещё двумя комбинациями с невалидными вариациями данных.

Поскольку у нас будет больше одного объекта, значит, первое, что мы должны сделать по правилам синтаксиса JSON, ― это заключить контент нашего файла в квадратные скобки. 

Затем перечислить наши объекты внутри этих скобок. Используя квадратные скобки, мы создаём массив объектов. В итоге получим вот такой JSON:

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

Нюансы

1. Первый нюанс, о котором надо знать.

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

Дело в том, что некоторые языки программирования могут равно посчитать и двойные, и одинарные кавычки признаком того, что значение является строкой. Например, на скриншоте ниже вы увидите переменную body, в которой хранится набор данных, очень похожий на JSON. Однако так в языке Python  описываются такие массивы данных, как словари. Это сходство меня самого поначалу удивило. Мой JSON, по меркам online-валидаторов, вроде правильный, а в Postman не мог подгрузиться.

Как вы уже поняли, в нашем случае это не работает. Даже при простом подключении такого файла Postman выдаст ошибку.

2. Вторым нюансом является следующее. 

Как значения из JSON'а воспринимаются Postman при подключении и прогоне.

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

Однако если начать прогон, то все три наших теста пройдут неуспешно. В итоге мы увидим, что почему-то, несмотря на правильное оформление JSON'а, сам Postman в прогоне куда-то утащил наши кавычки. 

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

Один будет успешным, а два других ― проваленными. Все, как мы и планировали.

Работает как часы. Вроде все классно, понятно и наглядно. Но вот незадача - мы использовали JSON для описания значений только для одного из запросов в цепочке, а в CSV у нас были описаны переменные для целой группы разных запросов.

Здесь все работает точно так же. Мы просто дополняем имеющиеся в JSON'е объекты нужными нам парами ключ-значение. Ниже в каждом объекте вы увидите дополнение ключами title и queue, нужные для создания тикета-на-задачу в нашей учебной системе Help Desk.

И все будет работать, как и в CSV-файлах. Postman сам разберет, к каким запросам какие переменные использовать.

Чтобы повысить читаемость JSON-файла, можно разделить группы ключей и значений пустыми строками. Файл не потеряет своей работоспособности. А если хочется, чтобы назначение групп пар ключ-значение было сходу понятно всем читающим, можно в том же формате внести комментарий. Например, comment «Получение токена рабочей сессии» или comment «Создание тикета».

Проблем с добавлением таких элементов не должно возникнуть. Ведь если в теле запроса нет ключа, к которому эта переменная подключена, то и ошибки в отправляемом теле запроса не будет, потому что в запросах «переменная» comment использоваться не будет.

Также у вас могут возникнуть вопросы: «А что, если в теле отправляемого запроса у нас есть для каких-то ключей в качестве значения вложенный объект? Для этих вложенных пар ключ-значение как-то нужно изменять структуру JSON'а с данными?»

Например, есть простой JSON, описывающий пользователя:

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

Ответ прост. Поскольку Postman, анализируя наш JSON с тестовыми данными, смотрит только на то, какие ключи этого файла соответствуют именам переменных, обозначенных в каждом конкретном запросе, строгое следование структуре какого-то тела запроса в нем ― не важно. Главное, чтобы имя ключа в JSON с тестовыми данными четко совпадало с именем переменной, например, в теле запроса или в URL запроса. Говоря проще, никаких вложенностей в файле JSON  с тестовыми  данными не требуется.

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