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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, при расширении нашего 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 выпиши поля верхнего уровня: Внутри 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
- Добавление нового поля обычно безопасно.
- Удаление обязательного поля ломает клиентов.
- Смена типа поля ломает клиентов.
- Переименование поля ломает клиентов.
- Перенос поля в другое место ломает клиентов, когда клиент жёстко читает путь.
- Вложенный объект часто расширяется безопасно, когда старые поля остаются.

Открыть исходную публикацию