Коллекция, окружение и осмысленные assertions · QA Orbit
Перейти к содержимому
QA ORBIT
Новости Инструменты Библиотека Полезные сайты Курсы ИИ и тестирование
Войти
КурсыТренажёры3
Маршруты обучения
КурсыТестирование API: контракт, данные и состояниеУрок 4
Программа курса

Тестирование API: контракт, данные и состояние

0 из 6 уроков пройдено
01HTTP-запрос, ответ и проверяемый контракт≈ 45 мин02Позитивные и негативные проверки данных≈ 50 мин03Авторизация, объектный доступ и состояние≈ 55 мин04Коллекция, окружение и осмысленные assertions≈ 55 мин05Диагностика, повторы и честный результат≈ 50 мин06Итоговый проект: проверка API-контракта≈ 80 мин
Учебные данные. Реальные навыки.
Урок 04 / 6 · 04 / Postman и проверки≈ 55 мин с практикой

Коллекция, окружение и осмысленные assertions

Соберите воспроизводимую цепочку запросов, сохраните ID безопасно и избегайте ложных успехов.

В своём темпе
Что вы сможете после урока
  • Разделять данные окружения и тестовые ожидания.
  • Писать именованные проверки статуса, тела и заголовков.
  • Передавать ID между запросами без использования старого значения.

Коллекция хранит сценарий, окружение выбирает адрес

Скачиваемая Postman-коллекция предназначена только для запущенной локальной лаборатории. Переменная baseUrl указывает http://127.0.0.1:4177; studentToken содержит публичный demo-anna. Перед отправкой проверьте подстановки и порт. Если стенд не запущен, connection refused является препятствием выполнения, а не failed проверкой контракта API. Портал не содержит скрытого удалённого экземпляра этого сервиса.

В реальной работе адреса тестового и production-окружения разделяют явно, а токены не коммитят в общедоступные коллекции. В этом задании токены не секретны, поскольку вся модель синтетическая и локальная. Такая оговорка важна: пример учит передавать значение, но не является архитектурой хранения реальных секретов. У переменных Postman есть области видимости; более узкое значение может перекрыть ожидаемое. Если адрес кажется неправильным, проверьте не только коллекцию, но и выбранное окружение.

Assertion должен обнаруживать смысловое нарушение

Используйте отдельные имена: «201 on create», «author from token», «exact title», «Location matches ID». Падение указывает, какое правило нарушено. Данные JSON сначала разбираются; ошибка разбора сама является сигналом, если контракт обещал JSON. При проверке заголовка учитывайте явно допустимые параметры Content-Type, например charset, вместо точного сравнения со строкой application/json без параметров. Но статус 201 сравнивается точно: общий диапазон 2xx слишком широк для A3.

Полезная отрицательная проверка также называет код ошибки и инвариант. Проверка времени ответа без согласованного порога может быть измерением, но не основанием Passed/Failed по быстродействию. Не добавляйте случайное «меньше 200 мс» ради зелёной галочки: машина ученика и сеть не являются заданной нагрузочной средой. Научитесь проверять описанное, а дополнительные метрики помечать исследовательскими наблюдениями.

Старый ID способен сделать цепочку ложно успешной

Перед Create удалите прошлый taskId. Сохраняйте новый только после выполнения условий успеха; при ошибке создания Read не должен обращаться к вчерашнему объекту и показывать зелёный результат. Наш пример pre-request очищает переменную, а post-response проверяет 201, непустой строковый id и затем записывает его. Если создание не соответствует остальным assertions, весь прогон всё равно должен считаться неуспешным, даже если дальнейший GET прошёл.

Коллекцию можно исполнять по порядку: Reset, Create, Read, Publish, Repeat. Reset является лабораторной подготовкой и не частью продукта. Ручное открытие только Read без Create не воспроизводит сценарий. После прогона сохраните версию коллекции, базовый адрес, фактические результаты и источник данных. Скачиваемый check-lab.mjs даёт альтернативу без интерфейса Postman и проверяет дополнительные отказные сценарии. Он не заменяет ваши объяснения оракула и не оценивает качество реального сервиса.

Post-response для успешного создания

javascriptУчебный пример
pm.test('201 on create', () => pm.response.to.have.status(201));
const data = pm.response.json();
pm.test('author from token', () => pm.expect(data.authorId).to.eql('u-a'));
pm.test('draft state', () => pm.expect(data.state).to.eql('draft'));
pm.test('exact title', () => pm.expect(data.title).to.eql('Коллекция'));
pm.test('Location matches ID', () => pm.expect(pm.response.headers.get('Location')).to.eql('/tasks/' + data.id));
if (pm.response.code === 201 && typeof data.id === 'string' && data.id.length > 0) {
  pm.collectionVariables.set('taskId', data.id);
}

Источники и проверка фактов

Postman — post-response scriptsИменованные тесты и assertions после получения ответа; официальный синтаксис pm.test / pm.expect.Postman — variablesОбласти видимости и подстановка переменных; значения окружения нужно проверять перед запуском.

Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1

Теперь применим это к задачеПопробуйте сами, прежде чем открывать разбор.
Предыдущий урокАвторизация, объектный доступ и состояниеСледующий урокДиагностика, повторы и честный результат
QA ORBIT

Проверяй. Понимай. Расти.

Пространство осмысленного тестирования.
ИсследуйтеНовостиИнструментыБиблиотека
РазвивайтесьКурсыТренажёрыМаршруты обученияИИ и тестирование
Оставайтесь на орбитеО проекте Полезные сайтыГлоссарий
© 2026 QA Orbit. Сделано с вниманием к деталям.
КонфиденциальностьУсловия использования Всегда есть что исследовать