ПРАКТИЧЕСКИЙ ТРЕНАЖЁР

Тест-кейсы.

Правило → данные → шаг → ожидание

0 проверок— лучший результат

Проходите без регистрации: работа автоматически сохраняется в этом браузере. Гостевой черновик останется здесь после входа; в аккаунте используется отдельное сохранение.

Войти для синхронизации

УЧЕБНЫЙ КЕЙССредний

Файл: границы размера и приоритет отказов

Учебный OrbitFiles: POST /api/files создаёт один файл после успешной проверки.

Требования

R1Без сессии возвращается 401; viewer получает 403. Проверка доступа идёт раньше проверки файла.
R2Editor может загрузить .pdf и .zip размером от 1 до 8388608 байт включительно; успех — 201 и один новый файл.
R3Пустой файл, превышение размера или другое расширение у editor дают 422.
R4Любой отказ не создаёт файл и не меняет уже существующие файлы.

Наблюдаемые факты

Формат Данных: {"role":"editor|viewer|anonymous","name":"имя.расширение","size":целое_число_байт}. Выберите одно значение role, а не строку со всеми вариантами.
Данные описывают подготовленный файл; бинарный файл прикладывать не нужно.
Внешний сервис хранения исправен, сети хватает. Каждый кейс независим.

Что нужно сделать

В поле Данные каждого кейса укажите один JSON-объект по формату сценария. Это описание фикстуры, запросы здесь не выполняются.
Каждому кейсу дайте уникальный ID, конкретный заголовок, ID требования и технику.
Опишите подготовку, действие и проверку результата. Для КАЖДОГО шага заполните ожидаемый результат; у запроса укажите один точный HTTP-статус.
Проверьте и ответ, и сохранённые данные. Не превращайте отрицательную проверку в успешный сценарий.
Покройте оба разрешённых расширения, нулевой/минимальный/максимальный/сверхмаксимальный размер, запрещённый тип и обе роли отказа.
Проверьте гостя и viewer также с плохим файлом, чтобы проверить порядок отказов.

Подсказки и цель практики

Вы потренируете

Таблица решений
Границы в байтах
Приоритет доступа над валидацией

Если застряли

8 МиБ — 8388608 байт, не 8000000.
Отказ по доступу не должен смениться на 422 из-за плохого файла.

Повторить теорию по теме

ВАША РАБОТА

Спроектируйте набор проверок

Восстанавливаем работу…

Открываем вашу рабочую тетрадь…

Файл: границы размера и приоритет отказов

Учебный OrbitFiles: POST /api/files создаёт один файл после успешной проверки.

Требования

R1Без сессии возвращается 401; viewer получает 403. Проверка доступа идёт раньше проверки файла.
R2Editor может загрузить .pdf и .zip размером от 1 до 8388608 байт включительно; успех — 201 и один новый файл.
R3Пустой файл, превышение размера или другое расширение у editor дают 422.
R4Любой отказ не создаёт файл и не меняет уже существующие файлы.

Наблюдаемые факты

Формат Данных: {"role":"editor|viewer|anonymous","name":"имя.расширение","size":целое_число_байт}. Выберите одно значение role, а не строку со всеми вариантами.
Данные описывают подготовленный файл; бинарный файл прикладывать не нужно.
Внешний сервис хранения исправен, сети хватает. Каждый кейс независим.

Что нужно сделать

В поле Данные каждого кейса укажите один JSON-объект по формату сценария. Это описание фикстуры, запросы здесь не выполняются.
Каждому кейсу дайте уникальный ID, конкретный заголовок, ID требования и технику.
Опишите подготовку, действие и проверку результата. Для КАЖДОГО шага заполните ожидаемый результат; у запроса укажите один точный HTTP-статус.
Проверьте и ответ, и сохранённые данные. Не превращайте отрицательную проверку в успешный сценарий.
Покройте оба разрешённых расширения, нулевой/минимальный/максимальный/сверхмаксимальный размер, запрещённый тип и обе роли отказа.
Проверьте гостя и viewer также с плохим файлом, чтобы проверить порядок отказов.

Подсказки и цель практики

Вы потренируете

Таблица решений
Границы в байтах
Приоритет доступа над валидацией

Если застряли

8 МиБ — 8388608 байт, не 8000000.
Отказ по доступу не должен смениться на 422 из-за плохого файла.

Повторить теорию по теме