Тест-кейс – это не просто таблица с шагами. Это рабочий документ, по которому тестировщик воспроизводит ситуацию, проверяет поведение системы и фиксирует результат. Примеры тест-кейса помогают понять, как именно выглядит хороший тест: какие поля заполнять, какой уровень детализации нужен и как не превратить документ в бесполезную формальность.
В этой статье собраны образцы тест-кейсов в разных форматах – от функционального тестирования и UI до API, регрессии и нагрузки. Каждый пример показывает структуру, логику заполнения и способ адаптации под реальную задачу.
Что войдет в подборку: примеры тест-кейса по форматам
Ниже представлены образцы тест-кейсов, разбитые по основным форматам и сценариям тестирования:
- Функциональные тест-кейсы
- 1. Авторизация пользователя с корректными данными
- 2. Авторизация с неверным паролем
- 3. Регистрация нового аккаунта
- 4. Восстановление пароля через email
- Тест-кейсы для UI и форм
- 5. Валидация обязательных полей формы
- 6. Проверка отображения ошибок при некорректном вводе
- 7. Поведение кнопки при отправке формы
- API тест-кейсы
- 8. GET-запрос на получение списка пользователей
- 9. POST-запрос на создание нового ресурса
- 10. Обработка запроса с невалидным токеном
- Регрессионные тест-кейсы
- 11. Проверка корзины после обновления модуля оплаты
- 12. Работа поиска после изменения структуры базы данных
- Граничные и негативные тест-кейсы
- 13. Поле с максимально допустимым количеством символов
- 14. Загрузка файла недопустимого формата
- 15. Отправка пустого запроса к API
- Нагрузочные тест-кейсы
- 16. Одновременная авторизация 500 пользователей
- 17. Пакетная загрузка файлов в хранилище
- Тест-кейсы для мобильных приложений
- 18. Работа приложения при потере соединения
- 19. Корректное отображение на разных размерах экрана
- Тест-кейсы для интеграций
- 20. Передача данных между CRM и почтовым сервисом
- 21. Синхронизация заказа с системой складского учета
Примеры тест-кейса разных видов и форматов: основной FAQ
Что такое тест-кейс? Тест-кейс – это структурированное описание проверки: что тестируется, при каких условиях, какие шаги выполняет тестировщик и какой результат считается правильным. Это не баг-репорт и не чеклист – это самостоятельный документ, воспроизводимый любым участником команды.
Основные форматы тест-кейсов:
- Функциональные – проверяют, работает ли функция так, как описано в требованиях.
- UI/UX – проверяют внешний вид, поведение элементов интерфейса, валидацию форм.
- API – проверяют запросы и ответы на уровне программного интерфейса, без UI.
- Регрессионные – проверяют, что после изменений старая функциональность не сломалась.
- Граничные и негативные – проверяют поведение системы на крайних и недопустимых значениях.
- Нагрузочные – проверяют устойчивость системы под высоким трафиком или объемом данных.
- Мобильные – проверяют поведение приложения в условиях мобильного устройства.
- Интеграционные – проверяют корректность передачи данных между разными системами.
Где применяются: в командах разработки, QA-отделах, при сдаче продукта заказчику, при регрессионном тестировании перед релизом, при аудите качества.
Обязательные поля тест-кейса: идентификатор (ID), название, предусловия, шаги, ожидаемый результат, фактический результат, статус. Остальные поля – приоритет, тип, автор, дата – добавляются по потребности команды.
Функциональные тест-кейсы
Функциональные тест-кейсы – самый распространенный тип в повседневной работе QA. Они проверяют, выполняет ли система то, что от нее ожидается по требованиям или спецификации. Именно с таких примеров тест-кейса чаще всего начинают знакомство с форматом.
📌 Авторизация пользователя с корректными данными
- Сценарий: позитивный – пользователь вводит правильные логин и пароль
- Область: веб-приложение, страница входа
- Задача: убедиться, что система пропускает пользователя с верными учетными данными
Пример:
ID: TC-AUTH-001
Название: Успешная авторизация с корректными данными
Приоритет: Высокий
Тип: Функциональный, позитивный
Предусловия: Пользователь зарегистрирован в системе. Учетная запись активна. Страница входа доступна.
Тестовые данные: Логин: test_user@example.ru | Пароль: Test@12345
Шаги:
- Открыть браузер и перейти на страницу входа: https://app.example.ru/login
- В поле "Email" ввести: test_user@example.ru
- В поле "Пароль" ввести: Test@12345
- Нажать кнопку "Войти"
Ожидаемый результат:
Система перенаправляет пользователя на главную страницу личного кабинета. В шапке отображается имя пользователя. Сессия активна.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован] Автор: [имя тестировщика] Дата: [дата выполнения]
- Почему подходит: Это базовый позитивный кейс. Он всегда должен быть первым в наборе тестов авторизации – без него нельзя оценивать негативные сценарии.
- Что важно не испортить: Тестовые данные должны быть реальными учетными записями тестовой среды, а не выдуманными. Иначе кейс нельзя воспроизвести.
- Термин "предусловия": Условия, которые должны быть выполнены до начала теста. Без них кейс может дать ложный результат.
📌 Авторизация с неверным паролем
- Сценарий: негативный – пользователь вводит правильный логин, но ошибочный пароль
- Область: страница входа
- Задача: проверить, что система корректно обрабатывает ошибочные данные и не пропускает пользователя
Пример:
ID: TC-AUTH-002
Название: Отказ в авторизации при неверном пароле
Приоритет: Высокий
Тип: Функциональный, негативный
Предусловия: Пользователь зарегистрирован. Страница входа открыта.
Тестовые данные: Логин: test_user@example.ru | Пароль: WrongPass999
Шаги:
- Перейти на страницу входа: https://app.example.ru/login
- Ввести корректный email: test_user@example.ru
- Ввести неверный пароль: WrongPass999
- Нажать кнопку "Войти"
Ожидаемый результат:
Система не выполняет вход. На странице отображается сообщение об ошибке: "Неверный логин или пароль". Пользователь остается на странице авторизации. Поле пароля очищается.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Негативный сценарий авторизации критичен для безопасности. Без него нельзя считать авторизацию протестированной.
- Что важно проверить дополнительно: Сколько попыток допускает система до блокировки. Это отдельный кейс, но он вытекает из этого.
📌 Регистрация нового аккаунта
- Сценарий: позитивный – новый пользователь заполняет форму регистрации
- Область: страница регистрации
- Задача: проверить полный цикл создания учетной записи
Пример:
ID: TC-REG-001
Название: Успешная регистрация нового пользователя
Приоритет: Высокий
Тип: Функциональный, позитивный
Предусловия: Email не зарегистрирован в системе. Почтовый ящик доступен для проверки.
Тестовые данные: Имя: Тест Пользователь | Email: newuser_test@example.ru | Пароль: Secure@2024
Шаги:
- Перейти на страницу регистрации: https://app.example.ru/register
- Заполнить поле "Имя": Тест Пользователь
- Заполнить поле "Email": newuser_test@example.ru
- Заполнить поле "Пароль": Secure@2024
- Повторить пароль в поле "Подтверждение пароля"
- Нажать кнопку "Зарегистрироваться"
- Открыть почтовый ящик и найти письмо с подтверждением
- Перейти по ссылке подтверждения из письма
Ожидаемый результат:
Учетная запись создана. Пользователь получает письмо с подтверждением. После перехода по ссылке аккаунт активирован. Пользователь перенаправляется в личный кабинет.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Этот кейс покрывает полный пользовательский путь, включая подтверждение по email – критический шаг, который часто ломается отдельно от самой формы.
- Что важно не испортить: Шаг с подтверждением email нельзя пропускать, даже если он кажется очевидным. Именно здесь часто обнаруживаются баги.
📌 Восстановление пароля через email
- Сценарий: пользователь забыл пароль и запрашивает сброс
- Область: страница "Забыли пароль?"
- Задача: проверить корректность всего цикла сброса пароля
Пример:
ID: TC-AUTH-003
Название: Восстановление пароля через email
Приоритет: Высокий
Тип: Функциональный, позитивный
Предусловия: Учетная запись с указанным email существует. Доступ к почтовому ящику есть.
Тестовые данные: Email: test_user@example.ru | Новый пароль: NewPass@2024
Шаги:
- Перейти на страницу входа: https://app.example.ru/login
- Нажать ссылку "Забыли пароль?"
- Ввести email: test_user@example.ru
- Нажать кнопку "Отправить инструкции"
- Открыть почтовый ящик, найти письмо со ссылкой для сброса
- Перейти по ссылке
- Ввести новый пароль: NewPass@2024
- Подтвердить новый пароль
- Нажать "Сохранить"
- Авторизоваться с новым паролем
Ожидаемый результат:
Письмо приходит в течение 2 минут. Ссылка ведет на форму смены пароля. После смены старый пароль не работает. Новый пароль обеспечивает успешный вход.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Восстановление пароля – один из самых уязвимых сценариев с точки зрения безопасности и пользовательского опыта. Его тестируют отдельно, а не в составе авторизации.
- Что важно проверить дополнительно: Срок действия ссылки сброса. Это отдельный граничный кейс.
Тест-кейсы для UI и форм
UI-тестирование проверяет, как интерфейс ведет себя с реальными пользователями: корректно ли отображаются элементы, правильно ли работает валидация, понятны ли сообщения об ошибках. Эти примеры тест-кейса особенно важны для продуктов с формами ввода – интернет-магазинов, сервисов, личных кабинетов.
📌 Валидация обязательных полей формы
- Сценарий: пользователь пытается отправить форму, не заполнив обязательные поля
- Область: форма оформления заказа
- Задача: убедиться, что система блокирует отправку и показывает подсказки
Пример:
ID: TC-UI-001
Название: Блокировка отправки при незаполненных обязательных полях
Приоритет: Высокий
Тип: UI, негативный
Предусловия: Форма оформления заказа открыта. Пользователь не заполнил ни одного поля.
Шаги:
- Открыть страницу оформления заказа
- Не заполнять ни одно поле
- Нажать кнопку "Оформить заказ"
Ожидаемый результат:
Форма не отправляется. Все обязательные поля (Имя, Телефон, Адрес) подсвечиваются красным. Под каждым полем отображается подсказка: "Поле обязательно для заполнения". Фокус переходит на первое незаполненное поле.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Этот кейс проверяет сразу несколько аспектов: блокировку отправки, визуальную индикацию ошибок и UX-поведение формы.
- Термин "валидация": Проверка данных, введенных пользователем, на соответствие требованиям – формат, длина, обязательность поля.
📌 Проверка отображения ошибок при некорректном вводе
- Сценарий: пользователь вводит данные в неверном формате
- Область: поле "Телефон" в форме обратного звонка
- Задача: проверить, что система показывает понятное сообщение об ошибке формата
Пример:
ID: TC-UI-002
Название: Сообщение об ошибке при вводе телефона в неверном формате
Приоритет: Средний
Тип: UI, негативный
Предусловия: Форма обратного звонка открыта.
Тестовые данные: Телефон: abc123
Шаги:
- Открыть форму обратного звонка
- В поле "Телефон" ввести: abc123
- Нажать кнопку "Перезвоните мне"
Ожидаемый результат:
Форма не отправляется. Поле "Телефон" подсвечивается. Отображается сообщение: "Введите номер телефона в формате +7 900 000 00-00".
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Форматные ошибки – частый источник проблем при интеграции данных. Проверка подсказки важна для пользовательского опыта.
📌 Поведение кнопки при отправке формы
- Сценарий: пользователь заполнил форму и нажал кнопку отправки
- Область: форма подписки на рассылку
- Задача: проверить состояние кнопки во время и после отправки
Пример:
ID: TC-UI-003
Название: Блокировка кнопки отправки во время обработки запроса
Приоритет: Средний
Тип: UI, позитивный
Предусловия: Форма подписки открыта. Email не зарегистрирован ранее.
Тестовые данные: Email: subscriber_test@example.ru
Шаги:
- Ввести email в поле формы подписки: subscriber_test@example.ru
- Нажать кнопку "Подписаться"
- Наблюдать за состоянием кнопки во время отправки запроса
- Дождаться ответа системы
Ожидаемый результат:
Во время обработки запроса кнопка принимает состояние "загрузка" (неактивна, отображается индикатор). После успешной отправки появляется сообщение: "Вы подписались на рассылку". Повторное нажение кнопки до завершения запроса невозможно.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Двойная отправка формы – распространенный баг, который приводит к дублированию данных. Этот кейс закрывает именно эту проблему.
API тест-кейсы
API-тестирование проверяет программный интерфейс приложения напрямую, без участия UI. Такие тест-кейсы используют в командах, где разработка ведется через API-first подход, или когда нужно изолированно проверить логику сервера. Шаблон тест-кейса для API немного отличается: здесь важны метод запроса, endpoint, заголовки и тело запроса.
📌 GET-запрос на получение списка пользователей
- Сценарий: авторизованный клиент запрашивает список пользователей
- Метод: GET
- Задача: проверить корректность ответа и структуры данных
Пример:
ID: TC-API-001
Название: GET /users – получение списка пользователей
Приоритет: Высокий
Тип: API, позитивный
Предусловия: В системе существует не менее 1 пользователя. Токен авторизации действителен.
Метод: GET
Endpoint: https://api.example.ru/v1/users
Заголовки: Authorization: Bearer {valid_token} | Content-Type: application/json
Шаги:
- Отправить GET-запрос на endpoint /v1/users с валидным токеном
- Получить ответ
- Проверить HTTP-статус ответа
- Проверить структуру тела ответа
- Убедиться, что список содержит ожидаемые поля для каждого пользователя
Ожидаемый результат:
HTTP-статус: 200 OK
Тело ответа: JSON-массив объектов. Каждый объект содержит поля: id (integer), name (string), email (string), created_at (datetime). Список не пустой при наличии пользователей в системе.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Базовый GET-кейс закрывает самый частый сценарий – чтение данных. Без него нельзя двигаться к проверке записи и удаления.
- Термин "endpoint": Адрес конкретного ресурса в API, к которому отправляется запрос.
- Термин "Bearer-токен": Способ передачи авторизационного ключа в заголовке запроса.
📌 POST-запрос на создание нового ресурса
- Сценарий: клиент создает новую запись через API
- Метод: POST
- Задача: проверить, что ресурс создается корректно и возвращается правильный ответ
Пример:
ID: TC-API-002
Название: POST /products – создание нового товара
Приоритет: Высокий
Тип: API, позитивный
Предусловия: Токен авторизации с правами администратора действителен.
Метод: POST
Endpoint: https://api.example.ru/v1/products
Заголовки: Authorization: Bearer {admin_token} | Content-Type: application/json
Тело запроса:
{
"name": "Тестовый товар",
"price": 1500,
"category_id": 3,
"in_stock": true
}
Шаги:
- Отправить POST-запрос на /v1/products с указанным телом
- Получить ответ
- Проверить HTTP-статус
- Проверить, что в ответе возвращен объект созданного товара с присвоенным ID
- Выполнить GET-запрос по возвращенному ID и убедиться, что товар существует
Ожидаемый результат:
HTTP-статус: 201 Created
Тело ответа содержит объект с полями: id (новый уникальный), name: "Тестовый товар", price: 1500, in_stock: true. GET-запрос по ID подтверждает существование записи.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: POST-кейс проверяет не только создание записи, но и идемпотентность – шаг 5 с проверкой через GET исключает ситуацию, когда API возвращает 201, но данные не сохраняются.
- Термин "201 Created": HTTP-статус, означающий успешное создание ресурса.
📌 Обработка запроса с невалидным токеном
- Сценарий: клиент отправляет запрос с истекшим или недействительным токеном
- Метод: GET
- Задача: проверить, что система корректно отклоняет неавторизованные запросы
Пример:
ID: TC-API-003
Название: Отклонение запроса с невалидным токеном авторизации
Приоритет: Высокий
Тип: API, негативный, безопасность
Предусловия: Доступ к API есть. Используется заведомо недействительный токен.
Метод: GET
Endpoint: https://api.example.ru/v1/users
Заголовки: Authorization: Bearer invalid_token_12345 | Content-Type: application/json
Шаги:
- Отправить GET-запрос на /v1/users с невалидным токеном
- Получить ответ
- Проверить HTTP-статус
- Проверить тело ответа на наличие сообщения об ошибке
Ожидаемый результат:
HTTP-статус: 401 Unauthorized
Тело ответа: JSON с полем error: "Unauthorized" или "Invalid token". Данные пользователей не возвращаются.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Проверка безопасности API – обязательная часть любого набора тестов. Если система возвращает данные при невалидном токене, это критический баг.
- Термин "401 Unauthorized": HTTP-статус, означающий отсутствие или недействительность авторизации.
Регрессионные тест-кейсы
Регрессионные тесты запускают после изменений в коде – обновлений, патчей, рефакторинга. Их задача – убедиться, что новая версия не сломала то, что работало раньше. Готовые шаблоны таких тест-кейсов обычно хранят в тест-плане и переиспользуют от релиза к релизу.
📌 Проверка корзины после обновления модуля оплаты
- Сценарий: в системе обновлен модуль обработки платежей, нужно убедиться, что корзина работает корректно
- Область: интернет-магазин, корзина и оформление заказа
- Задача: убедиться, что изменения в платежном модуле не затронули логику корзины
Пример:
ID: TC-REG-001
Название: Регрессия: корзина после обновления платежного модуля v2.3
Приоритет: Критический
Тип: Регрессионный
Связанные изменения: Обновление платежного модуля до версии 2.3
Предусловия: Пользователь авторизован. В каталоге есть товары в наличии.
Шаги:
- Открыть каталог товаров
- Добавить товар "Тестовый товар A" в корзину
- Добавить товар "Тестовый товар B" в корзину
- Перейти в корзину
- Проверить отображение товаров, количества и итоговой суммы
- Изменить количество "Тестового товара A" с 1 до 2
- Проверить пересчет суммы
- Удалить "Тестовый товар B"
- Перейти к оформлению заказа
- Выбрать способ оплаты "Банковская карта"
- Ввести тестовые данные карты и подтвердить заказ
Ожидаемый результат:
Товары корректно отображаются в корзине. Сумма пересчитывается при изменении количества. Удаление работает без ошибок. Оформление заказа проходит успешно. Статус заказа в личном кабинете: "Оплачен".
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован] Версия системы при последнем успешном прогоне: v2.2
- Почему подходит: Регрессионный кейс всегда привязан к конкретному изменению. Поле "Связанные изменения" помогает понять, что именно проверяется и почему кейс включен в прогон.
- Что важно не испортить: В регрессионных кейсах нельзя менять шаги без контроля версий. Если шаги изменились, нужно зафиксировать причину.
📌 Работа поиска после изменения структуры базы данных
- Сценарий: в БД добавлены новые поля, нужно убедиться, что поиск по старым полям не сломан
- Область: строка поиска по сайту
- Задача: проверить, что поиск по названию и артикулу работает корректно после миграции
Пример:
ID: TC-REG-002
Название: Регрессия: поиск по сайту после миграции БД
Приоритет: Высокий
Тип: Регрессионный
Связанные изменения: Миграция БД – добавление полей в таблицу products
Предусловия: В каталоге присутствует не менее 10 товаров с разными названиями и артикулами.
Шаги:
- Перейти на главную страницу сайта
- Ввести в строку поиска название существующего товара (например, "Ноутбук")
- Нажать Enter или кнопку поиска
- Проверить список результатов
- Очистить строку поиска
- Ввести артикул существующего товара (например, "NB-2024-001")
- Проверить список результатов
- Ввести несуществующий запрос "zzznonsense"
- Проверить поведение при пустом результате
Ожидаемый результат:
По названию: выводятся все товары, содержащие слово "Ноутбук". По артикулу: выводится конкретный товар. По несуществующему запросу: отображается сообщение "По вашему запросу ничего не найдено". Время ответа не превышает 2 секунды.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Поиск – одна из самых уязвимых функций при изменении структуры БД. Этот кейс покрывает три сценария сразу: позитивный по названию, позитивный по артикулу и негативный.
Граничные и негативные тест-кейсы
Граничные тесты проверяют поведение системы на крайних допустимых и недопустимых значениях. Негативные – проверяют, что система корректно реагирует на неправильные данные, не падает и не ведет себя непредсказуемо. Без таких примеров тест-кейса невозможно полноценно закрыть тему надежности продукта.
📌 Поле с максимально допустимым количеством символов
- Сценарий: пользователь вводит строго максимальное число символов в текстовое поле
- Область: поле "Комментарий к заказу"
- Задача: проверить граничное значение – ровно 500 символов
Пример:
ID: TC-BOUND-001
Название: Ввод максимально допустимого количества символов в поле "Комментарий"
Приоритет: Средний
Тип: Граничный, позитивный
Предусловия: Форма оформления заказа открыта. По документации максимум для поля "Комментарий" – 500 символов.
Тестовые данные: Строка ровно из 500 символов (например, повторяющийся текст "А" × 500)
Шаги:
- Открыть форму оформления заказа
- В поле "Комментарий" вставить строку из ровно 500 символов
- Убедиться, что вся строка принята полем (счетчик символов показывает 500/500)
- Заполнить остальные обязательные поля формы
- Нажать "Оформить заказ"
Ожидаемый результат:
Все 500 символов приняты. Форма отправляется успешно. В подтверждении заказа комментарий отображается полностью без обрезки.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Граничное значение "ровно максимум" – классический тест. Именно здесь чаще всего обнаруживаются ошибки типа "off-by-one" (граница сдвинута на один символ).
- Термин "off-by-one": Ошибка, при которой граница проверки сдвинута на единицу – например, допускается 499 вместо 500 или 501 вместо 500.
📌 Загрузка файла недопустимого формата
- Сценарий: пользователь пытается загрузить файл в формате, который система не принимает
- Область: форма загрузки документов в личном кабинете
- Задача: убедиться, что система отклоняет недопустимый формат с понятным сообщением
Пример:
ID: TC-NEG-001
Название: Отклонение файла недопустимого формата при загрузке
Приоритет: Высокий
Тип: Негативный
Предусловия: Пользователь авторизован. Допустимые форматы: PDF, JPG, PNG. Подготовлен файл в формате .exe
Тестовые данные: Файл: test_file.exe, размер: 50 КБ
Шаги:
- Перейти в раздел "Мои документы" в личном кабинете
- Нажать кнопку "Загрузить документ"
- В диалоге выбора файла выбрать test_file.exe
- Нажать "Открыть"
Ожидаемый результат:
Файл не загружается. Отображается сообщение: "Недопустимый формат файла. Разрешены: PDF, JPG, PNG". Кнопка загрузки остается доступной для повторной попытки.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Проверка типов файлов важна и для безопасности (исполняемые файлы), и для корректности обработки данных. Кейс закрывает оба аспекта.
📌 Отправка пустого запроса к API
- Сценарий: клиент отправляет POST-запрос с пустым телом
- Метод: POST
- Задача: проверить, что API корректно обрабатывает отсутствие обязательных данных
Пример:
ID: TC-NEG-002
Название: POST /orders – отправка запроса с пустым телом
Приоритет: Высокий
Тип: API, негативный
Предусловия: Токен авторизации действителен.
Метод: POST
Endpoint: https://api.example.ru/v1/orders
Заголовки: Authorization: Bearer {valid_token} | Content-Type: application/json
Тело запроса: {} (пустой объект)
Шаги:
- Отправить POST-запрос на /v1/orders с пустым телом {}
- Получить ответ
- Проверить HTTP-статус
- Проверить тело ответа
Ожидаемый результат:
HTTP-статус: 422 Unprocessable Entity или 400 Bad Request
Тело ответа содержит перечень обязательных полей, которые отсутствуют. Запись в БД не создается.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Пустой запрос – один из первых тестов при проверке API. Если сервер не возвращает понятную ошибку, это затруднит интеграцию для разработчиков.
- Термин "422 Unprocessable Entity": HTTP-статус, означающий, что запрос синтаксически корректен, но содержит семантические ошибки – например, отсутствие обязательных полей.
Нагрузочные тест-кейсы
Нагрузочное тестирование проверяет, как система ведет себя при высоком количестве одновременных запросов или большом объеме данных. Такие тест-кейсы отличаются от функциональных: здесь важны метрики – время ответа, количество ошибок, потребление ресурсов. Их запускают перед крупными релизами, сезонными пиками и масштабированием.
📌 Одновременная авторизация 500 пользователей
- Сценарий: 500 пользователей одновременно пытаются войти в систему
- Инструмент: Apache JMeter или аналог
- Задача: проверить стабильность сервиса авторизации при пиковой нагрузке
Пример:
ID: TC-LOAD-001
Название: Нагрузочный тест: одновременная авторизация 500 пользователей
Приоритет: Высокий
Тип: Нагрузочный
Предусловия: В тестовой среде созданы 500 учетных записей. Нагрузочный инструмент настроен. Мониторинг сервера активен.
Параметры нагрузки: Виртуальных пользователей: 500 | Период нарастания: 60 секунд | Длительность теста: 5 минут
Шаги:
- Настроить сценарий в инструменте нагрузочного тестирования: POST /login с уникальными учетными данными для каждого из 500 пользователей
- Запустить тест с нарастанием нагрузки: 0 → 500 пользователей за 60 секунд
- Удерживать нагрузку 5 минут
- Зафиксировать метрики: среднее время ответа, 95-й перцентиль, количество ошибок, потребление CPU и RAM
- Остановить тест
- Проверить логи сервера на наличие критических ошибок
Ожидаемый результат:
Среднее время ответа: не более 2 секунд. Процент ошибок: не более 1%. Сервис не падает и не зависает. Потребление CPU: не выше 80%. После теста система возвращается в нормальное состояние без перезапуска.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Авторизация – самая нагруженная точка при пиковом трафике. Этот кейс имитирует реальный сценарий – например, начало рабочего дня или открытие продаж.
- Термин "95-й перцентиль": Время ответа, которое не превышают 95% запросов. Используется вместо среднего, чтобы не скрывать пиковые задержки.
📌 Пакетная загрузка файлов в хранилище
- Сценарий: система получает 1000 файлов за короткий промежуток времени
- Область: сервис загрузки документов
- Задача: проверить, что очередь обрабатывается без потерь и зависаний
Пример:
ID: TC-LOAD-002
Название: Нагрузочный тест: пакетная загрузка 1000 файлов
Приоритет: Средний
Тип: Нагрузочный
Предусловия: Подготовлены 1000 тестовых файлов в формате PDF, размером до 1 МБ каждый. Сервис хранилища запущен. Мониторинг активен.
Параметры: 1000 параллельных POST-запросов к endpoint загрузки файлов в течение 2 минут
Шаги:
- Запустить сценарий с 1000 параллельными запросами загрузки файлов
- Отслеживать прогресс обработки очереди
- После завершения теста проверить количество успешно загруженных файлов
- Проверить, нет ли дублей или потерянных файлов
- Проверить логи на наличие ошибок таймаута или отказов
Ожидаемый результат:
Все 1000 файлов успешно загружены. Процент ошибок: 0%. Время обработки всей очереди: не более 3 минут. Дублей нет. Потерянных файлов нет.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Пакетная загрузка выявляет проблемы с очередями, блокировками и дедупликацией – то, что не видно при единичных запросах.
Тест-кейсы для мобильных приложений
Мобильное тестирование учитывает специфику устройств: нестабильное соединение, разные размеры экранов, фоновый режим, прерывания вызовами. Эти условия нельзя проверить стандартными веб-тестами – нужны отдельные образцы тест-кейсов с мобильной спецификой.
📌 Работа приложения при потере соединения
- Сценарий: пользователь теряет интернет-соединение во время активной сессии
- Платформа: Android / iOS
- Задача: проверить, как приложение реагирует на обрыв связи и восстанавливается после ее возврата
Пример:
ID: TC-MOB-001
Название: Поведение приложения при потере интернет-соединения
Приоритет: Высокий
Тип: Мобильный, негативный
Устройство: Смартфон с Android 13 / iOS 17
Предусловия: Приложение установлено и запущено. Пользователь авторизован. Соединение Wi-Fi активно.
Шаги:
- Открыть приложение и перейти на главный экран
- Отключить Wi-Fi и мобильные данные на устройстве
- Попытаться выполнить действие, требующее сети (например, обновить ленту)
- Зафиксировать поведение приложения
- Включить Wi-Fi обратно
- Попытаться повторить то же действие
Ожидаемый результат:
При потере соединения: отображается баннер или экран "Нет подключения к интернету". Приложение не падает. Ранее загруженные данные остаются видимы (если предусмотрен офлайн-режим). После восстановления соединения: баннер исчезает, данные обновляются автоматически без перезапуска приложения.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Нестабильное соединение – одна из самых частых причин негативного пользовательского опыта в мобильных приложениях. Этот кейс проверяет сразу обрыв и восстановление.
📌 Корректное отображение на разных размерах экрана
- Сценарий: приложение открывают на устройствах с разными диагоналями и разрешениями
- Платформа: Android
- Задача: убедиться, что интерфейс не ломается и ключевые элементы остаются доступными
Пример:
ID: TC-MOB-002
Название: Адаптивность интерфейса на разных размерах экрана
Приоритет: Средний
Тип: Мобильный, UI
Устройства для проверки: Смартфон 5″ (360×800), смартфон 6.5″ (1080×2400), планшет 10″ (1200×1920)
Предусловия: Приложение установлено на всех устройствах или используется эмулятор.
Шаги:
- Открыть приложение на устройстве 5″
- Проверить главный экран: видимость заголовка, кнопок навигации, контента
- Открыть экран детали товара и проверить отображение изображения, описания, кнопки "Купить"
- Повторить шаги 1–3 на устройстве 6.5″
- Повторить шаги 1–3 на планшете 10″
- Зафиксировать отклонения в отображении
Ожидаемый результат:
На всех устройствах: кнопки навигации видимы и кликабельны, текст не обрезан и не перекрывается, изображения масштабируются пропорционально, кнопка "Купить" доступна без горизонтальной прокрутки.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Адаптивность – обязательная проверка перед релизом мобильного приложения. Проблемы с отображением на конкретных диагоналях часто не видны при разработке на одном устройстве.
Тест-кейсы для интеграций
Интеграционные тесты проверяют, как данные передаются между двумя и более системами. Это могут быть CRM и почтовые сервисы, интернет-магазин и складская система, платежный шлюз и бухгалтерия. Ошибки в интеграциях часто не видны при тестировании каждой системы по отдельности.
📌 Передача данных между CRM и почтовым сервисом
- Сценарий: новый лид, добавленный в CRM, автоматически получает приветственное письмо
- Системы: CRM (условно "Система А") + почтовый сервис (условно "Сервис Б")
- Задача: убедиться, что данные лида корректно передаются и письмо отправляется
Пример:
ID: TC-INT-001
Название: Интеграция CRM → почтовый сервис: отправка приветственного письма новому лиду
Приоритет: Высокий
Тип: Интеграционный
Предусловия: Интеграция между CRM и почтовым сервисом настроена и активна. Триггер: создание нового лида. Тестовый почтовый ящик доступен.
Тестовые данные: Имя: Тест Лид | Email: test_lead@example.ru | Источник: сайт
Шаги:
- Открыть CRM и создать нового лида с указанными тестовыми данными
- Сохранить запись
- Подождать до 5 минут (время срабатывания триггера)
- Открыть почтовый ящик test_lead@example.ru
- Найти приветственное письмо
- Проверить содержимое письма: обращение по имени, корректность ссылок, отсутствие технических артефактов
Ожидаемый результат:
Письмо приходит в течение 5 минут. В обращении указано имя "Тест Лид". Ссылки в письме рабочие. Письмо не попадает в спам. В CRM в карточке лида зафиксирован статус "Письмо отправлено".
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Этот кейс проверяет не только факт отправки, но и корректность данных в письме и обратную запись статуса в CRM – три точки, в каждой из которых может быть ошибка.
📌 Синхронизация заказа с системой складского учета
- Сценарий: оформленный заказ в интернет-магазине должен автоматически уменьшить остатки на складе
- Системы: интернет-магазин + система складского учета
- Задача: убедиться, что остатки обновляются корректно и без задержек
Пример:
ID: TC-INT-002
Название: Синхронизация остатков: заказ в магазине → списание на складе
Приоритет: Критический
Тип: Интеграционный
Предусловия: Интеграция магазина и складской системы активна. Тестовый товар "Артикул TEST-001" присутствует в обеих системах. Остаток на складе: 10 единиц.
Тестовые данные: Товар: TEST-001 | Количество в заказе: 3
Шаги:
- Зафиксировать остаток товара TEST-001 в складской системе: 10 единиц
- Оформить заказ на 3 единицы товара TEST-001 в интернет-магазине
- Подтвердить заказ (перевести в статус "Оплачен")
- Подождать до 2 минут (время синхронизации)
- Открыть складскую систему и проверить остаток товара TEST-001
Ожидаемый результат:
Остаток товара TEST-001 в складской системе: 7 единиц (10 − 3). Синхронизация выполнена в течение 2 минут. В истории движения товара зафиксирована операция списания с указанием номера заказа.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
- Почему подходит: Ошибки синхронизации остатков – один из самых дорогих багов в e-commerce. Этот кейс проверяет и корректность числа, и наличие трейла в истории операций.
- Термин "трейл": Журнал операций, позволяющий отследить, кто, когда и что изменил.
Как написать тест-кейс: правила и этапы сборки с примерами
Примеры выше показывают рабочую логику разных форматов. Теперь разберем, как собрать собственный тест-кейс с нуля – не копируя содержание чужого, а используя ту же структуру под свою задачу.
Базовая схема сборки тест-кейса:
- 1. Определить, что именно тестируется (функция, интерфейс, API, интеграция)
- 2. Сформулировать цель теста одним предложением
- 3. Описать предусловия – что должно быть выполнено до старта
- 4. Подготовить тестовые данные (конкретные значения, не абстракции)
- 5. Записать шаги в строгой последовательности, каждый – отдельным действием
- 6. Сформулировать ожидаемый результат по каждому критическому шагу или итоговый
- 7. Оставить поля для фактического результата и статуса – они заполняются при выполнении
| Блок | Зачем нужен | Что сюда подставляется | Пример заполнения |
| ID | Уникальная идентификация кейса для ссылок и отчетов | Код по принятой нумерации команды | TC-AUTH-001 |
| Название | Быстрое понимание, что проверяется | Краткое описание: действие + объект + результат | Успешная авторизация с корректными данными |
| Приоритет | Определить порядок выполнения и критичность | Критический / Высокий / Средний / Низкий | Высокий |
| Тип | Классифицировать кейс для фильтрации и отчетности | Функциональный, UI, API, регрессионный, нагрузочный и т.д. | Функциональный, позитивный |
| Предусловия | Обеспечить воспроизводимость теста | Состояние системы, данные, доступы, которые нужны до старта | Пользователь зарегистрирован. Аккаунт активен. |
| Тестовые данные | Устранить неоднозначность в шагах | Конкретные значения: логины, пароли, файлы, числа | Email: user_test@example.ru | Пароль: Test@12345 |
| Шаги | Дать точную воспроизводимую последовательность действий | Глаголы в повелительном наклонении, по одному действию на шаг | 1. Открыть страницу входа. 2. Ввести email. 3. Ввести пароль. 4. Нажать "Войти". |
| Ожидаемый результат | Определить критерий успеха теста | Конкретное наблюдаемое состояние системы после выполнения шагов | Система перенаправляет на главную. В шапке отображается имя пользователя. |
| Фактический результат | Зафиксировать, что произошло в реальности | Описание реального поведения системы при выполнении | [заполняется при выполнении] |
| Статус | Зафиксировать итог выполнения | Пройден / Не пройден / Заблокирован / Пропущен | Пройден |
Пошаговая сборка на одном кейсе
Сценарий: нужно написать тест-кейс для проверки формы обратной связи на сайте – пользователь заполняет имя, email и сообщение, нажимает "Отправить".
Шаг 1. Определяем, что тестируем: форма обратной связи – функция отправки сообщения.
Шаг 2. Формулируем цель: убедиться, что сообщение успешно отправляется при корректном заполнении всех полей.
Шаг 3. Предусловия: страница с формой открыта, сервер принимает запросы, тестовый почтовый ящик администратора доступен.
Шаг 4. Тестовые данные: Имя: Тест Иванов | Email: feedback_test@example.ru | Сообщение: "Тестовое сообщение для проверки формы".
Шаг 5. Шаги: открыть форму → заполнить "Имя" → заполнить "Email" → заполнить "Сообщение" → нажать "Отправить" → проверить уведомление на странице → проверить почту администратора.
Шаг 6. Ожидаемый результат: на странице появляется сообщение "Ваше сообщение отправлено". На почту администратора приходит письмо с данными из формы. Форма очищается после отправки.
Готовая собранная версия:
ID: TC-FORM-001
Название: Успешная отправка формы обратной связи при корректном заполнении
Приоритет: Высокий
Тип: Функциональный, позитивный
Предусловия: Страница с формой обратной связи открыта. Сервер обрабатывает запросы. Доступ к почте администратора есть.
Тестовые данные: Имя: Тест Иванов | Email: feedback_test@example.ru | Сообщение: "Тестовое сообщение для проверки формы"
Шаги:
- Открыть страницу с формой обратной связи
- Ввести имя: Тест Иванов
- Ввести email: feedback_test@example.ru
- Ввести сообщение: "Тестовое сообщение для проверки формы"
- Нажать кнопку "Отправить"
- Проверить уведомление на странице
- Открыть почту администратора и найти входящее письмо
Ожидаемый результат:
На странице отображается: "Ваше сообщение отправлено. Мы свяжемся с вами в ближайшее время". Форма очищается. Письмо приходит на почту администратора с темой "Новое сообщение с сайта" и содержит имя, email и текст сообщения из формы.
Фактический результат: [заполняется при выполнении] Статус: [Пройден / Не пройден / Заблокирован]
Границы применимости и типичные ошибки
- Когда схема работает: для любого типа тест-кейсов – функциональных, UI, API, мобильных, интеграционных. Структура универсальна, меняется только содержание блоков.
- Где ломается: в нагрузочных тестах блок "Шаги" заменяется на параметры нагрузки и метрики – стандартная последовательность действий здесь не работает.
- Что нельзя выкидывать: предусловия и тестовые данные. Без них кейс невоспроизводим – другой тестировщик не сможет его выполнить корректно.
- Что можно менять: набор дополнительных полей (автор, дата, ссылка на баг), порядок некоторых полей по стандарту команды, уровень детализации шагов.
- Что нельзя переносить бездумно: тестовые данные из чужого примера. Логины, пароли, артикулы и email-адреса должны соответствовать вашей тестовой среде.
- Типичная ошибка 1: писать ожидаемый результат как "все работает корректно" – это не результат, это пожелание. Результат должен быть конкретным и наблюдаемым.
- Типичная ошибка 2: объединять несколько действий в один шаг. Каждый шаг – одно действие. Иначе при провале теста непонятно, на каком именно шаге сломалось.
- Типичная ошибка 3: пропускать фактический результат и статус, считая их необязательными. Без них кейс не может использоваться в отчетности.
Практические приемы написания тест-кейсов: сводная таблица
| Прием | В чем помогает | Как применять |
| Один шаг – одно действие | Упрощает локализацию дефекта | Разбивать составные действия: "открыть, ввести, нажать" – три отдельных шага |
| Конкретный ожидаемый результат | Делает тест объективным | Писать наблюдаемое состояние: "отображается сообщение X", "статус меняется на Y" |
| Реальные тестовые данные | Обеспечивает воспроизводимость | Указывать конкретные значения, а не "введите любой email" |
| Проверка граничных значений | Выявляет ошибки на краях диапазона | Тестировать: минус 1, ровно граница, плюс 1 от допустимого значения |
| Парный позитивный и негативный кейс | Закрывает оба сценария для каждой функции | К каждому позитивному кейсу писать хотя бы один негативный |
| Предусловия отдельно от шагов | Разделяет подготовку и само тестирование | В предусловиях – состояние среды, в шагах – действия тестировщика |
| Привязка к требованиям | Позволяет отследить покрытие | Добавлять поле "Связанное требование" со ссылкой на спецификацию |
6 практических приемов для работы с тест-кейсами:
- Используйте рыбы данных в тестовых значениях. Никогда не указывайте реальные логины, пароли или данные клиентов – только тестовые аккаунты и нейтральные значения.
- Группируйте кейсы по функциональным блокам. Авторизация, корзина, оплата – отдельные группы. Это упрощает запуск регрессии по конкретному модулю.
- Пишите ожидаемый результат до выполнения теста. Если писать его после – есть риск подогнать результат под то, что произошло.
- Фиксируйте версию системы при каждом прогоне. Это критично для регрессионных кейсов: без версии непонятно, когда именно что-то сломалось.
- Не дублируйте шаги из предусловий в шагах теста. Предусловие – это состояние до теста, шаги – действия во время теста. Смешивание делает кейс громоздким.
- Обновляйте кейсы при изменении требований. Устаревший тест-кейс опаснее отсутствующего: он создает иллюзию покрытия там, где его нет.
Хороший шаблон тест-кейса – это не бюрократия, а инструмент воспроизводимости. Чем точнее описан кейс, тем меньше вопросов возникает при его выполнении и тем надежнее результаты тестирования. Примеры тест-кейсов из этой подборки можно использовать как основу: берите структуру, подставляйте свои данные, адаптируйте под свою систему и среду.
Главное, что отличает рабочий тест-кейс от формального – конкретность на каждом уровне: конкретные данные, конкретные шаги, конкретный ожидаемый результат. Именно это превращает документ из отчетной бумаги в реальный инструмент контроля качества.
