Проблема выбора техники
Вы изучили более 20 техник тест-дизайна. Задача теперь не «какие техники существуют?», а «какую использовать сейчас?»
Неверный выбор тратит усилия впустую. EP на протоколе с состояниями пропустит баги переходов. State transition testing на движке расчётов пропустит граничные дефекты.
Фреймворк принятия решений
Шаг 1: Какой тип фичи вы тестируете?
| Тип фичи | Лучшие техники |
|---|---|
| Валидация ввода (формы) | EP + BVA |
| Бизнес-правила с условиями | Таблицы решений |
| Рабочие процессы, протоколы, сессии | Тестирование переходов состояний |
| Конфигурация/совместимость | Попарное тестирование |
| Расчёты, формулы | Доменный анализ + BVA |
| API с множеством параметров | Комбинаторное тестирование |
| Критические алгоритмы | MC/DC + покрытие путей |
| Сложные пользовательские сценарии | Use case testing + state transitions |
Шаг 2: Какая информация доступна?
| Доступная информация | Применимые техники |
|---|---|
| Только требования/спецификации | Black-box: EP, BVA, таблицы решений, переходы состояний |
| Доступен исходный код | White-box: покрытие операторов/решений, путей, MC/DC |
| Без документации | На основе опыта: предугадывание ошибок, исследовательское тестирование |
| Существует формальная модель | Тестирование на основе моделей |
Шаг 3: Каков уровень риска?
| Уровень риска | Рекомендуемый подход |
|---|---|
| Safety-critical | MC/DC + доменный анализ + мутационное тестирование |
| Финансовый/регуляторный | Таблицы решений + BVA + комбинаторное |
| Ключевая бизнес-логика | EP + BVA + переходы состояний + покрытие путей |
| Стандартные фичи | EP + BVA + предугадывание ошибок |
| Низкий риск/косметика | Предугадывание ошибок + чек-листы |
Сопоставление техник по категориям
Тестирование ввода данных
- Начать с EP — определить классы
- Применить BVA — границы классов
- Добавить доменный анализ — если входы взаимодействуют
- Использовать предугадывание ошибок — типичные ошибки ввода
Тестирование бизнес-логики
- Начать с таблиц решений — все комбинации условий
- Добавить переходы состояний — если поведение зависит от предыдущего состояния
- Применить cause-effect graphing — при сложных зависимостях
- Использовать комбинаторное — при множестве параметров
Структурное тестирование (White-Box)
- Покрытие операторов — базовый минимум
- Покрытие решений — обе ветви
- MC/DC — для safety-critical
- Покрытие путей — критические алгоритмы
- Мутационное тестирование — валидация эффективности тестов
Примеры из практики
Пример 1: Форма входа
- Поле логина: EP + BVA
- Поле пароля: EP + BVA
- Кнопка входа: Переходы состояний (блокировка после 3 неудач)
- Общее: Предугадывание ошибок (SQL injection, XSS, пустые поля)
Пример 2: Калькулятор страховки
- Расчёт премии: Таблицы решений
- Диапазоны ввода: BVA + Доменный анализ
- Комбинации скидок: Попарное тестирование
Пример 3: Оформление заказа
- Состояния корзины: Переходы состояний
- Способы оплаты: Попарное тестирование
- Правила доставки: Таблицы решений
- End-to-end поток: Use case testing
Упражнение: Выбор техник
Задача 1
Для каждой фичи выберите основную и дополнительную техники:
- Движок расчёта налогов с разными ставками по шкалам дохода
- Музыкальный плеер с play, pause, skip, shuffle, repeat
- Функция поиска с опциональными фильтрами
- Система управления лифтами в 20-этажном здании
- Индикатор надёжности пароля
Решение
Налоги: Основная: Таблицы решений; Дополнительная: BVA + Доменный анализ + Покрытие путей
Плеер: Основная: Переходы состояний; Дополнительная: Попарное (shuffle/repeat) + Предугадывание ошибок
Поиск: Основная: EP; Дополнительная: Попарное (фильтры) + BVA (даты) + Предугадывание ошибок
Лифты: Основная: Переходы состояний; Дополнительная: MBT + Комбинаторное
Надёжность пароля: Основная: EP (категории); Дополнительная: BVA + Таблицы решений + Предугадывание ошибок
Задача 2
Создайте стратегию тестирования для системы бронирования отелей.
Решение
| Подфича | Основная техника | Дополнительная | Обоснование |
|---|---|---|---|
| Поиск по датам | BVA | EP | Чёткие границы дат |
| Количество гостей | BVA + EP | Предугадывание | Границы (min 1, max на номер) |
| Динамические цены | Таблицы решений | Доменный анализ | Сложные правила по сезону |
| Жизненный цикл брони | Переходы состояний | Use case testing | Состояния: ожидание, подтверждена, отменена |
| Обработка платежей | Переходы состояний | Предугадывание | Состояния платежа + edge cases |
| Конфигурация | Попарное | Чек-листы | Комбинации браузер/устройство |
Анти-паттерны выбора техник
Использование только одной техники. Команды, применяющие только EP, пропускают баги состояний.
Пропуск техник на основе опыта. Формальные техники не покрывают всё.
Избыточная инженерия для фич с низким риском. MC/DC для лендинга — трата ресурсов.
Полное игнорирование white-box техник. Данные структурного покрытия выявляют пробелы.
Ключевые выводы
- Ни одна техника не достаточна сама по себе — эффективное тестирование требует комбинации
- Сопоставляйте технику с типом фичи: зависит от состояния → переходы, правила → таблицы решений, ввод → EP+BVA
- Уровень риска определяет строгость
- Доступная информация ограничивает выбор
- Всегда дополняйте формальные техники предугадыванием ошибок и исследовательским тестированием
- Выработайте привычку выбора — для каждой фичи осознанно спрашивайте «какая техника подходит лучше?»