Что такое тестирование по use case?
Тестирование по use case выводит тест-кейсы из документов use case — структурированных описаний того, как акторы взаимодействуют с системой для достижения целей. Каждый use case содержит основной сценарий успеха и альтернативные потоки, предоставляя естественные тестовые сценарии.
Анатомия use case
| Элемент | Описание | Пример |
|---|---|---|
| Название | Краткий описательный заголовок | «Оформить заказ» |
| Актор | Кто инициирует взаимодействие | Клиент, Администратор |
| Предусловие | Что должно быть истинным перед началом | Пользователь авторизован, корзина не пуста |
| Основной поток | Пошаговый happy path | 1. Выбрать доставку… 2. Ввести оплату… |
| Альтернативные потоки | Отклонения от основного потока | 2a. Оплата отклонена → показать ошибку |
| Постусловие | Что истинно после успеха | Заказ создан, email отправлен |
Пример: Use Case «Оформить заказ»
Актор: Зарегистрированный клиент Предусловие: Клиент авторизован, корзина содержит 1+ товаров
Основной поток:
- Система отображает сводку корзины с товарами и итогом
- Клиент выбирает способ доставки
- Система рассчитывает стоимость доставки и обновляет итог
- Клиент вводит платёжную информацию
- Система проверяет данные оплаты
- Клиент подтверждает заказ
- Система обрабатывает платёж
- Система создаёт заказ и отправляет email подтверждения
- Система отображает страницу подтверждения заказа
Альтернативные потоки:
- 2a. Только один способ доставки → система автоматически выбирает его
- 4a. Клиент выбирает сохранённый способ оплаты → переход к шагу 6
- 5a. Валидация оплаты не прошла → система показывает ошибку, возврат к шагу 4
- 7a. Обработка платежа не удалась → система показывает ошибку, предлагает повторить
- 7b. Таймаут оплаты → система показывает сообщение о таймауте, заказ не создан
- 8a. Сервис email недоступен → заказ создан, email поставлен в очередь
Вывод тест-кейсов
Правило: Создать минимум один тест-кейс на каждый поток (основной + каждый альтернативный).
| TC | Поток | Описание |
|---|---|---|
| TC1 | Основной | Happy path, все шаги 1-9 успешны |
| TC2 | 2a | Авто-выбор доставки |
| TC3 | 4a | Сохранённый платёж, переход к подтверждению |
| TC4 | 5a | Невалидная оплата → ошибка → повтор |
| TC5 | 7a | Платёж не прошёл → предложить повтор |
| TC6 | 7b | Таймаут оплаты → заказ не создан |
| TC7 | 8a | Email не доступен → заказ создан, email в очереди |
7 тест-кейсов из 1 use case.
Поиск пропущенного покрытия
Use case часто выявляют пробелы тестирования. Задавайте вопросы:
- Что если корзина опустеет между шагами 1 и 6?
- Что если цена изменится во время оформления?
- Как насчёт прав доступа актора?
- Что происходит после постусловия?
Продвинутое тестирование по use case
Комбинирование потоков
Реальные сценарии часто комбинируют несколько альтернативных потоков последовательно:
| TC | Комбинированные потоки | Сценарий |
|---|---|---|
| TC8 | 5a → Основной | Невалидная оплата, повтор с правильными данными → успех |
| TC9 | 7a → 4a | Платёж не прошёл, использовать сохранённый метод → успех |
| TC10 | 5a → 5a → 7a | Два невалидных ввода, затем валидный, но карта отклонена |
Тестирование use case для API
Сопоставьте use case с последовательностями API-вызовов:
Шаг 1: GET /cart → 200 (сводка корзины)
Шаг 2: PUT /cart/shipping → 200 (выбор доставки)
Шаг 3: GET /cart/total → 200 (пересчитанный итог)
Шаг 4: POST /orders/payment-intent → 200 (инфо об оплате)
Шаг 5: POST /orders/validate → 200 или 400 (валидация)
Шаг 6: POST /orders/confirm → 201 (заказ создан)
Критерии покрытия
Покрытие потоков (минимум): Каждый поток выполнен хотя бы раз. Покрытие шагов: Каждый шаг каждого потока выполнен хотя бы раз. Вариация данных: Тот же поток с разными валидными/невалидными данными (комбинируя с EP/BVA).
Упражнение: Выведите тест-кейсы из use case
Use Case: Сброс пароля
Актор: Зарегистрированный пользователь Предусловие: У пользователя есть аккаунт с подтверждённым email
Основной поток:
- Пользователь нажимает «Забыл пароль»
- Система показывает форму ввода email
- Пользователь вводит зарегистрированный email
- Система отправляет ссылку сброса на email
- Пользователь кликает по ссылке в течение 24 часов
- Система показывает форму нового пароля
- Пользователь вводит новый пароль (по политике: 8+ символов, 1 заглавная, 1 цифра)
- Система проверяет и сохраняет новый пароль
- Система подтверждает смену пароля и отправляет уведомление
Альтернативные потоки:
- 3a. Email не зарегистрирован → «Если аккаунт существует, письмо отправлено» (безопасность)
- 5a. Ссылка истекла (>24 ч) → «Ссылка истекла»
- 5b. Ссылка уже использована → «Ссылка уже использована»
- 7a. Пароль не соответствует политике → конкретная ошибка
- 7b. Новый пароль совпадает со старым → «Выберите другой пароль»
Задание: Выведите тест-кейсы для всех потоков. Добавьте 2 дополнительных сценария исключений.
Подсказка
Подумайте: что если пользователь запросит несколько ссылок сброса? Что если аккаунт заблокирован? Как насчёт SQL injection в поле email?
Решение
Тест-кейсы из документированных потоков: 8 тест-кейсов
Дополнительные сценарии исключений:
| TC | Сценарий | Ожидаемый результат |
|---|---|---|
| TC9 | Несколько запросов сброса → работает только последняя ссылка | Предыдущие ссылки недействительны |
| TC10 | Деактивированный аккаунт → запрос сброса | Общее сообщение (не раскрывать статус) |
| TC11 | XSS в поле email | Input очищен, нет выполнения |
| TC12 | Запросить сброс, сменить пароль обычным способом, кликнуть ссылку | Ссылка должна быть недействительной |
Итого: 12 тест-кейсов.
Советы профессионала
- Каждый альтернативный поток — тест-кейс. Не пропускайте их — альтернативные потоки скрывают большинство дефектов.
- Проверяйте предусловия. Что происходит, если предусловие НЕ выполнено? Это ещё один тестовый сценарий.
- Думайте о постусловиях. Проверяйте не только успех действия, но и все побочные эффекты (отправка писем, обновление БД, создание логов).
- Use case хорошо сочетаются с исследовательским тестированием. Документированные потоки направляют структурированное тестирование; затем исследуйте за пределами документированных путей.
- Нумеруйте потоки последовательно. «5a» означает «альтернатива на шаге 5, вариант a» — это упрощает трассировку при создании тест-кейсов.