# Шаблон тест-кейса с примерами

QA Hub · Версия 1 · 22 октября 2026

Скопируйте пустой шаблон в трекер или систему управления тестами. Один кейс должен проверять одно основное поведение. Ожидаемые результаты должны быть наблюдаемыми, а подготовка — воспроизводимой другим тестировщиком без вопросов автору.

## Пустой шаблон

| Поле | Значение |
| --- | --- |
| ID и название | |
| Требование / критерий приёмки | |
| Риск и приоритет | Объясните влияние на бизнес |
| Среда / сборка | |
| Предусловия | Учётная запись, роль, состояние, зависимости |
| Тестовые данные | Точные значения или воспроизводимый генератор |
| Очистка | Какие записи удалить / какое состояние восстановить |

| Шаг | Действие | Ожидаемый результат |
| --- | --- | --- |
| 1 | | |
| 2 | | |
| 3 | | |

Выполнение: дата · исполнитель · фактический результат · Pass/Fail/Blocked/Not run · доказательства · ссылка на дефект.

## Пример 1 — Отклонить количество выше максимума

**ID:** ORDER-BOUNDARY-02  
**Требование:** В учебном продукте разрешено целое количество от 1 до 10 включительно. Некорректное значение не создаёт заказ и не резервирует товар.  
**Приоритет:** Высокий: ошибка может привести к нежелательному резервированию товара.  
**Среда:** Staging; зафиксировать установленную сборку.  
**Предусловия:** Авторизованный тестовый покупатель, тестовый товар в наличии, нет незавершённого заказа этого запуска. Зафиксировать остаток и число заказов.  
**Данные:** Количество `11`; уникальная метка тестового запуска.  
**Очистка:** Удалить только записи с меткой этого запуска, если они ошибочно появились; восстановить затронутый тестовый остаток.

| Шаг | Действие | Ожидаемый результат |
| --- | --- | --- |
| 1 | Открыть тестовый товар и ввести количество 11 | Введённое значение отображается |
| 2 | Отправить заказ | Валидация объясняет допустимый диапазон; подтверждение заказа не появляется |
| 3 | Проверить список заказов и остаток через разрешённый тестовый интерфейс | Заказ и резерв данного запуска не созданы |

Соседние кейсы: `0`, `1`, `10`, дробное количество, пустое поле. Разделяйте случаи с разным ожидаемым поведением. Диапазон выше — условие примера, а не стандарт для любого магазина.

## Пример 2 — Запретить просмотр чужого заказа

**ID:** ORDER-AUTH-01  
**Требование:** Покупатель видит только свои заказы. В контракте учебного API для авторизованного пользователя без прав указан ответ `403`.  
**Предусловия:** Тестовые покупатели A и B; заказ покупателя B. Обе учётные записи и заказ принадлежат тестовой среде.  
**Данные:** ID заказа B, действующий токен A. Токен не сохранять в доказательствах.  
**Очистка:** Удалить подготовленный заказ разрешённой служебной учётной записью.

| Шаг | Действие | Ожидаемый результат |
| --- | --- | --- |
| 1 | От имени B запросить заказ B | Ответ содержит подготовленный заказ |
| 2 | От имени A запросить тот же ID | Статус 403 согласно контракту примера |
| 3 | Проверить весь ответ с ошибкой | Нет содержимого заказа или личных данных |

Некоторые продукты намеренно возвращают `404`, скрывая существование объекта. В реальном кейсе используйте согласованный контракт своего продукта.

## Проверка перед запуском

- Можно ли воспроизвести предусловия?
- Указаны ли точные действия и данные?
- Проверяется ли бизнес-результат, а не только сообщение?
- Опираются ли статус и текст ошибки на требование?
- Нет ли в доказательствах учётных данных и персональной информации?
- Удаляет ли очистка только данные этого теста?

Продолжить: https://qahub.pro/ru/documentation/test-case