Игорь Колосов.ru Личная база знаний

JSON (JavaScript Object Notation) – это текстовый формат для представления структурированных данных, широко используемый в веб-разработке. В тестировании важно понимать, как устроен JSON, и уметь проверять его на корректность, соответствие требованиям и обратную совместимость. Ниже представлена лекция, которая простым языком объясняет основы JSON и его тестирования.

1. Что такое JSON с точки зрения тестирования

JSON хранит данные в виде структуры «ключ – значение». Файл JSON обычно представляет собой объект (набор пар ключ: значение) внутри фигурных скобок { }. Например, простой JSON-объект с информацией о пользователе может выглядеть так:

{
"name": "Иван",
"age": 30,
"isEmployee": true
}

Основные элементы JSON:

  • Ключи (имена полей) – это строки в двойных кавычках. Например: "name": "Иван". В стандартном JSON имена ключей обязательно заключаются в двойные кавычки.

  • Значения – могут быть разных типов:

    • строка (в двойных кавычках),

    • число (целое или с плавающей точкой),

    • логическое значение (true или false),

    • null (специальное значение для отсутствия данных),

    • объект (вложенная структура в { }),

    • массив (список значений в квадратных скобках [ ]).

JSON поддерживает всего шесть типов данных: строки, числа, логические значения, null, массивы и объекты. Ключи и строки пишутся только в двойных кавычках (одинарные кавычки или отсутствие кавычек – ошибка в синтаксисе JSON).

Вложенность: JSON позволяет вкладывать объекты и массивы друг в друга. Например, значение может быть другим объектом или массивом. Это удобно для представления связанных данных. Пример вложенного JSON:

{
"person": {
"name": "Иван",
"contacts": {
"email": "ivan@example.com",
"phone": null
}
}
}

Здесь ключ "person" содержит в качестве значения вложенный объект с именем и контактами.

Примеры корректного и некорректного JSON:

  • Корректный JSON:

    {
    "product": "Телефон",
    "price": 199.99,
    "inStock": true,
    "tags": ["электроника", "смартфон"]
    }

    Все ключи в кавычках, значения допустимых типов, элементы перечислены через запятую.

  • Некорректный JSON (пример ошибок):

    {
    name: "Телефон", // ошибка: ключ без кавычек
    "price": "199.99", // допустимо, но если предполагалось число, то тип неверный
    "inStock": true, // правильно
    "tags": ["электроника", "смартфон",] // ошибка: лишняя запятая после последнего элемента
    }

    В этом некорректном примере отсутствуют кавычки у ключа name и стоит лишняя запятая в конце массива tags. Кроме того, значение "price" заключено в кавычки, поэтому воспринимается как строка, а не число. Такие ошибки приведут к тому, что JSON не пройдёт проверку синтаксиса – парсер выдаст ошибку. Типичные причины некорректности JSON – неэкранированные специальные символы, использование неправильных кавычек (например, одинарных), пропущенные кавычки у ключей или значений, лишние запятые или другие отступления от стандарта.

2. Основы тестирования JSON

Тестирование JSON включает проверку того, что формат данных соответствует ожиданиям. Основные аспекты, на которые обращают внимание тестировщики:

  • Валидация структуры JSON: Первый шаг – убедиться, что JSON синтаксически корректен. То есть, файл/строка JSON открывается и закрывается правильно фигурными или квадратными скобками, все строки имеют кавычки, нет лишних запятых и т.д. Проще говоря, JSON должен успешно парситься (разбираться) без ошибок. Если синтаксис неверный, программа обычно выдаст ошибку вроде «SyntaxError: JSON.parse: unexpected token …». Синтаксическую корректность можно проверить с помощью парсера или онлайн-валидатора.

  • Обязательные и необязательные поля: После проверки синтаксиса нужно убедиться, что в JSON присутствуют все поля, которые обязаны быть по требованиям. Например, если по спецификации ответа API поле "status" должно быть всегда, то его отсутствие считается ошибкой. Обязательные поля должны присутствовать и иметь корректный тип. Необязательные поля могут отсутствовать – это не ошибка, если по требованиям они действительно необязательны. Тестер проверяет наличие обязательных полей и игнорирует отсутствие необязательных, если это допустимо.

  • Типизация значений: Для каждого поля проверяется тип данных. Если ожидается число, в JSON значением не должна быть строка. Например, поле "age" должно быть числовым, и тестер проверит, что значение не заключено в кавычки и представляет число. В примере валидации ниже поле name проверяется как строка, email – как строка формата email, а age – как положительное число.

  • Пустые и null-значения: Тестирование учитывает ситуации, когда поля могут быть пустыми или равны null. Пустая строка ("") и значение null – разные вещи. Null означает отсутствие значения. Нужно понять требования: допускается ли null для поля? Например, если у пользователя может не быть номера телефона, поле "phone" может быть null или просто отсутствовать. Тестер проверяет, что такие поля обрабатываются правильно. Если поле обязательно, пустое значение или null могут считаться ошибкой (в зависимости от контекста).

  • Вложенные структуры: Если JSON содержит объекты внутри объектов или списки, нужно проверить их содержимое. Например, если есть поле "contacts" с вложенными полями "email" и "phone", тестер проверит наличие и корректность этих внутренних полей тоже. Аналогично, в массивах проверяется тип и формат каждого элемента. Вложенные структуры усложняют тестирование, так как необходимо рекурсивно проверить каждое поле на всех уровнях.

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

{
"name": "Maria", // должно быть, тип строка, не пустая
"email": "maria@example.com", // должно быть, тип строка, формат email
"age": 28, // необязательное, но если есть – тип число >= 0
"roles": ["user", "editor"] // необязательное, если есть – массив строк, не пустой
}

Для этого JSON проверяем:

  • Поля name и email обязательны – они присутствуют. name непустая строка, email выглядит как корректный адрес.

  • Поле age необязательное. Здесь оно есть, и значение 28 – число, что корректно (возраст не отрицательный).

  • Поле roles необязательное. Здесь оно есть, значение – массив из строк ["user", "editor"]. Массив не пустой, тип элементов верный.

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

3. Обратная совместимость JSON

Понятие обратной совместимости (backward compatibility) важно, когда JSON используется для взаимодействия разных систем, например, клиента и сервера через API. Обратная совместимость означает, что новые изменения в структуре данных не ломают работу старых клиентов. Иначе говоря, после обновления схемы JSON старые программы, которые этот JSON читают, могут продолжать работать корректно без изменений с их стороны.

Применительно к JSON это означает, что если мы изменяем структуру передаваемых данных, старые потребители (клиентские приложения) не должны «сломаться». Например, добавление нового поля в JSON-объект обычно не нарушает обратную совместимость: старые клиенты, которые не знают про новое поле, просто его проигнорируют и продолжат работать. Такой сценарий считается безопасным.

Однако некоторые изменения критичны для клиентов и могут сломать интеграцию:

  • Удаление обязательного поля: если убрать поле, которое старый клиент считал всегда присутствующим, при чтении JSON он его не найдёт и, скорее всего, выдаст ошибку или начнёт работать неверно. Например, если в ответе сервера раньше всегда было поле "status", и вдруг оно пропало – старый клиент может не понять, что ответ означает, и перестанет корректно работать.

  • Переименование ключа: если поле "price" переименовать в "cost", старые клиенты не найдут ожидаемого поля "price" – это эквивалентно его удалению для них. Переименование без поддержки старого имени ломает совместимость.

  • Изменение типа данных поля: например, поле "id" раньше было числом, а в новой версии стало строкой (например, "id": "123" вместо "id": 123). Старый код, ожидающий число, может не справиться со строкой – возникнет ошибка приведения типа или неправильная логика. Любое изменение типа или формата значений критично (например, поменять формат даты с "2025-12-31" на числовой таймштамп).

  • Изменение структуры: более сложные перестройки JSON – например, раньше список объектов был массивом ["a","b","c"], а стал объектом с ключами { "a": {}, "b": {} }. Такие изменения точно не поймутся старым кодом.

Почему обратная совместимость важна: если не соблюдать ее, обновление сервера или формата данных потребует одновременного обновления всех клиентов. На практике у разных пользователей могут быть разные версии приложений. Если новый формат сразу разорвет совместимость, часть пользователей столкнется с багами или падениями программ. Поэтому хорошие практики разработки API предполагают, что новые версии стараются быть совместимыми со старыми, или же вводится механизм версии (о нём ниже).

Итак, при тестировании JSON в контексте API критичными полями считают те, без которых работа клиента невозможна (обязательные поля, используемые в логике клиента). Их удаление или переименование – запрещённое изменение без повышения версии API. Добавление новых полей, как правило, безопасно, если клиенты их игнорируют. Изменение существующих значений (тип, формат) – опасно. Тестер при анализе изменений в формате всегда задаёт вопрос: «Продолжат ли старые клиенты работать с таким изменением?». Если ответ нет, значит, обратная совместимость нарушается.

4. Как проверять обратную совместимость

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

  • Сравнение версий схемы: Если у вас есть описание старой версии JSON (например, документация или JSON Schema), и новая версия, нужно сравнить их. На уровне manual-тестирования – просмотреть, какие поля добавились, удалились или изменились. Автоматизировано это делают с помощью инструментов сравнения схем. Идея в том, чтобы убедиться: всё, что было обязательным, осталось на месте, типы полей прежние, и никакие старые поля не пропали или не поменяли смысл. Добавленные поля обычно проблем не создают. Если обнаружено удаление/переименование – это сигнал о нарушении совместимости.

  • Контрактное тестирование: В разработке есть понятие контракта API – соглашения о структуре данных между сервером и клиентами. Контракт обычно фиксируется в виде спецификации (например, OpenAPI/Swagger, JSON Schema или просто документ). Для проверки совместимости можно запускать тесты контрактов. Например, старый контракт (структура JSON старой версии) используется для проверки нового сервиса: подаём старый запрос – получаем ответ, проверяем, соответствует ли он старому контракту. Если новые ответы проходят все проверки старого контракта, значит, совместимость сохранилась. Контрактные тесты сообщают, если API ведёт себя не так, как ожидалось по старой спецификации.

  • Автоматические тесты на backward compatibility: Организации иногда пишут набор тестовых сценариев для старой версии API и запускают их против новой версии. Такой регресс-тест гарантирует, что всё, что работало раньше (включая обработку JSON), работает и сейчас. Например, можно взять сохранённые примеры старых JSON-ответов и проверить, что новый парсер/клиент их понимает. Или наоборот – взять новый JSON и прогнать через старую версию парсера (если возможно) чтобы увидеть, нет ли ошибок.

  • Версионирование API: Строго говоря, если изменение настолько большое, что сохранить совместимость невозможно, то вводят новую версию API. Однако, проверка совместимости всё равно важна – она показывает, что в рамках одной версии ничего не сломалось случайно, а если сломалось, то это осознанно и требует новой версии (смотри следующий раздел).

Важно отметить, что тестеру нужно работать в связке с разработчиками и аналитиками: знать, какие поля являются обязательными для клиентов, и какие изменения планируются. Например, если решили переименовать поле, тестер должен обратить внимание, что старые клиенты это не переживут – значит, либо отменить переименование, либо готовить новую версию API.

5. Версионность JSON (версионирование API)

Версионность – это механизм обозначения изменений в формате API. Когда простое сохранение совместимости затруднено, или прошло много изменений, делают новую версию. Версионирование API позволяет вносить улучшения или изменения без нарушения работы существующих интеграций. Новая версия вводится, если изменения могут повлиять на совместимость, то есть старые клиенты сами по себе не смогут работать с новыми данными.

Как указывается версия? Есть несколько типичных подходов к версии API:

  1. В URL: версия включается в путь запроса. Например, запрос к версии 1 может выглядеть так:

    GET /api/v1/users/123

    Здесь v1 – это указание версии 1. Если выпустить несовместимые изменения, их выкатывают по адресу /api/v2/... и старый адрес /api/v1/... продолжает работать для старых клиентов.

  2. В теле JSON: версия передается как поле в самом JSON. Например:

    {
    "version": "1.0",
    "data": {
    "id": 123,
    "name": "Пример"
    }
    }

    Клиент, получая JSON, сначала смотрит на "version" и понимает, как интерпретировать остальные данные. При изменениях можно увеличить номер версии (например, "version": "2.0") и обновлённые клиенты будут знать, как работать с новой структурой.

  3. В заголовках (Headers): версия может передаваться в заголовке HTTP-запроса/ответа, например: API-Version: 1.0. Тогда сам URL и JSON не меняются, но по заголовку обе стороны знают, какую версию данных используют.

  4. В параметрах запроса: иногда версию передают как параметр, например: GET /api/users/123?version=1.0. Это похоже на вариант с URL, только версия не в пути, а в строке запроса.

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

Обычно, если изменение обратно несовместимо (breaking change), то нужна новая версия API. Например, решили удалить важное поле или радикально изменить структуру – правильным решением будет ввести /v2/ или "version": "2.0", а старую версию какое-то время поддерживать, пока пользователи не перейдут на новую. Версионность – своего рода страховка: даже если нужно изменить JSON кардинально, можно это сделать аккуратно, не нарушая сразу работу всех клиентов.

6. Доработка схемы: безопасные изменения и новые версии

При эволюции (доработке) JSON-схемы важно разделять изменения на безопасные (не нарушающие совместимость) и критические (требующие новой версии). Рассмотрим типичные случаи:

Безопасные изменения (не требуют новой версии):

  • Добавление нового поля, которое не было раньше. Старые клиенты просто не будут его использовать. Например, добавить поле "middleName" в JSON пользователя – старое приложение, не ожидающее его, просто проигнорирует лишние данные. Для новых клиентов это поле может нести дополнительную информацию, а старым не мешает.

  • Добавление новых значений в перечисление (enum) или расширение допустимых диапазонов. Например, если поле status раньше принимало значения "NEW" или "DONE", а теперь добавилось "IN_PROGRESS" – старый клиент, возможно, не знает про новое значение. Однако, это безопасно только если старый клиент умеет корректно обработать незнакомое значение (например, отобразить как «неизвестный статус»). Если же неизвестное значение совсем ломает логику, то это не безопасное изменение. В общем случае добавление вариантов допустимо, если клиенты не ожидают строго фиксированный набор.

  • Изменение, не влияющее на контракт: например, поменять местами поля (порядок не важен в JSON-объекте) или изменить формат числа, не меняя типа (скажем, больше знаков после запятой, что по-прежнему число). Эти изменения не должны влиять на парсинг данных.

Критические изменения (требуют новой версии):

  • Удаление или переименование поля. Как упоминалось, убрать поле – значит сломать тех, кто его ждал. Переименование равносильно удалению старого и добавлению нового поля под другим именем – старый клиент потеряет данные. Такие изменения практически всегда требуют поднять версию API или предусмотреть период параллельной поддержки обоих вариантов.

  • Изменение типа поля. Например, было "id": 123 (число), стало "id": "123" (строка). Для старого клиента это ломает работу – нужна новая версия или хотя бы явный сигнал об изменении.

  • Структурные изменения. Если из одного поля делают вложенный объект или наоборот, из объекта – плоский набор полей, старый код это не распознает. Требуется новая версия схемы.

  • Изменение семантики данных. Например, раньше поле "price" было в долларах, а теперь стало в евро без изменения имени. Формально JSON может пройти валидацию структуры, но значение изменило смысл. Клиенты, не знающие об изменении, начнут отображать или рассчитывать неправильно. Такие изменения тоже считаются ломющими контракт – их нельзя просто так внедрить, не договорившись с клиентами (лучше ввести новое поле или явную версию).

При доработках схемы рекомендуется:

  • По возможности не ломать старое: добавлять новые данные, не затрагивая старые.

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

  • Документировать изменения: тестировщик должен иметь новую спецификацию и список отличий.

Например, при расширении нашего JSON пользователя: добавить поле "nickname" безопасно – старые приложения его проигнорируют. Но если решено разделить поле "name" на "firstName" и "lastName", то без новой версии не обойтись, так как старый клиент, ожидавший "name", этого не поймёт. В такой ситуации можно выпустить версию 2.0 API, где отправлять оба новых поля, а какое-то время поддерживать и старое поле (или старую версию эндпоинта).

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

[task_id id=»21281″]

Инструкция по выполнению работы

 

Postman Web. Пошаговая работа

Подготовка

  1. Открой сайт Postman.
  2. Выполни вход.
  3. Перейди в Workspace: Personal Workspace или новый Workspace.

Создание запроса

  1. Нажми New.
  2. Выбери HTTP Request.
  3. В поле Method выбери GET.
  4. В поле URL вставь:
    https://jsonplaceholder.typicode.com/users/1
  5. Нажми Send.

Чтение ответа

  1. Внизу появится блок Response.
  2. Переключись на вкладку Body.
  3. Выбери режим просмотра Pretty.
  4. Убедись, что формат ответа JSON: фигурные скобки { }, поля в кавычках, двоеточия.

Копирование JSON в отчёт

  1. В ответе нажми Copy (иконка копирования).
  2. Вставь в файл api-testing.md в кодовый блок:
...вставить JSON...

Разбор полей и типов

В Response JSON выпиши поля верхнего уровня:

  • id число
  • name строка
  • username строка
  • email строка
  • address объект
  • phone строка
  • website строка
  • company объект

Внутри address и company открой вложенные поля и тоже выпиши.

Моделирование версий JSON

В отчёте создай два примера.

Вариант А. Совместимость сохранена
Пример: добавилось новое поле, старые поля остались.

Вариант Б. Совместимость нарушена
Пример: поле id пропало или стало строкой, либо address превратился в строку.

Каждый вариант вставь отдельным JSON-блоком и подпиши последствия для клиента.

JSON Schema и проверка

  1. Открой любой онлайн JSON Schema генератор/валидатор (разрешается любой).
  2. Вставь исходный JSON.
  3. Получи JSON Schema.
  4. Скопируй схему в отчёт отдельным блоком:
...schema...
  1. Проверь исходный JSON этой схемой.
  2. В отчёте запиши результат: “валидация прошла”, “ошибка в поле …”.

Экспорт запроса (по желанию)

  1. Слева найди запрос.
  2. Переименуй: Users_1_GET.
  3. Сохрани в коллекцию: API Practice.

Hoppscotch.io. Пошаговая работа

Подготовка

  1. Открой сайт Hoppscotch.
  2. Вход допускается, работа возможна и без входа.

Отправка запроса

  1. Вверху слева выбери метод GET.
  2. В поле URL вставь:
    https://jsonplaceholder.typicode.com/users/1
  3. Нажми Send.

Чтение ответа

  1. Внизу откроется блок ответа.
  2. Перейди в Response и режим Body.
  3. Выбери формат отображения JSON (обычно Pretty включается автоматически).
  4. Скопируй JSON из ответа.

Перенос в отчёт

  1. Вставь JSON в api-testing.md в блок:
...JSON...

Разбор структуры

  1. Найди поля верхнего уровня.
  2. Найди вложенные объекты: address, company.
  3. Заполни таблицу полей в отчёте:
  • поле
  • тип
  • роль для клиента
  • обязательность для клиента

Версионность и совместимость

Сделай 2 JSON-примера:

  1. “совместимость сохранена”
  2. “совместимость нарушена”

Для каждого примера добавь 2–4 строки: что случится на фронте или в клиенте.

JSON Schema

  1. Открой онлайн JSON Schema инструмент.
  2. Сгенерируй схему на основе исходного JSON.
  3. Проверь JSON по схеме.
  4. Вставь схему и результат проверки в отчёт.

Шаблон отчёта api-testing.md

Скопируй и заполни:

# Практическая работа: тестирование API и JSON

## 1. API
URL: https://jsonplaceholder.typicode.com/users/1  
Метод: GET

## 2. Исходный JSON
```json
...вставить...

3. Поля и типы

Поле Тип Роль для клиента Обязательность
id number идентификатор обязательное
name string имя обязательное
…дополнить…

4. Контракт API

Клиент ожидает всегда: …
Клиент допускает расширение: …

5. Версии JSON

5.1 Совместимость сохранена

...пример...

Последствия: …

5.2 Совместимость нарушена

...пример...

Последствия: …

6. JSON Schema

...schema...

Результат проверки: …

7. Выводы тестировщика

  • …
  • …

---

## Подсказки по совместимости JSON
- Добавление нового поля обычно безопасно.
- Удаление обязательного поля ломает клиентов.
- Смена типа поля ломает клиентов.
- Переименование поля ломает клиентов.
- Перенос поля в другое место ломает клиентов, когда клиент жёстко читает путь.
- Вложенный объект часто расширяется безопасно, когда старые поля остаются.