Урок 08.02: Техники тест-дизайна
Цель урока
Освоить основные техники тест-дизайна, которые аналитик использует при подготовке сценариев тестирования: эквивалентное разбиение (Equivalent Partitioning), анализ граничных значений (Boundary Value Analysis), таблица решений (Decision Table), попарное тестирование (Pairwise Testing) и таблица переходов (State-Transition). Научиться защищать систему от «тупиковых статусов» и понимать, почему Pairwise отлавливает 80% багов.
Ключевые понятия
- Тест-дизайн (Test Design) — процесс создания тестовых сценариев на основе требований
- Эквивалентное разбиение — разделение входных данных на классы, внутри которых поведение системы одинаково
- Граничные значения (Boundary Values) — значения на границах классов эквивалентности (самые частые источники багов)
- Decision Table (Таблица решений) — описание бизнес-логики в виде «условия → действия»
- Pairwise Testing (Попарное тестирование) — техника, основанная на эмпирическом факте: большинство багов вызывается взаимодействием двух параметров
- Комбинаторный взрыв (Combinatorial Explosion) — экспоненциальный рост количества тестов при увеличении числа параметров
- Таблица переходов (State-Transition) — тестирование на основе состояний объекта (для объектов со сложной логикой статусов)
- Тупиковый статус (Deadlock State) — состояние, из которого объект не может выйти, хотя бизнес-процесс требует продолжения
1. Зачем аналитику техники тест-дизайна?
1.1. Проблема: «всех комбинаций не перетестировать»
Представьте: форма создания задачи — 6 полей, каждое может принимать 5+ значений.
- 6^5 = 7776 комбинаций
- Если каждый тест — 3 минуты → 388 часов = 48 рабочих дней
Тест-дизайн позволяет сократить количество тестов, сохраняя качество покрытия.
1.2. Что дают техники тест-дизайна аналитику
| Навык | Как помогает |
|---|---|
| Находить баги в требованиях | Если для требования нельзя применить эквивалентное разбиение — требование нечёткое |
| Писать лучшие Acceptance Criteria | Где границы? Какие классы данных? |
| Готовить сценарии для UAT | Уверенность, что заказчик протестирует все значимые сценарии |
| Обсуждать тесты с QA | Общий язык: «Я описал эквивалентные классы для поля email» |
| Замечать пропущенные статусы | State-Transition показывает «дыры» в бизнес-логике |
2. Эквивалентное разбиение (Equivalent Partitioning)
2.1. Идея
Входные данные делятся на классы эквивалентности. Если один тест из класса проходит — все остальные значения из этого класса тоже пройдут.
Пример: Поле «возраст» принимает значения от 0 до 120 лет.
| Класс | Диапазон | Статус | Проверяем одним тестом |
|---|---|---|---|
| Невалидный (слишком мал) | < 0 | ❌ | -1 |
| Валидный | 0 – 120 | ✅ | 25 |
| Невалидный (слишком велик) | > 120 | ❌ | 150 |
Всего 3 теста вместо 121.
2.2. Пример: валидация email
Требование: «email должен содержать @ и домен (username@domain.tld)».
| Класс | Пример | Ожидаемый результат |
|---|---|---|
| Валидный email | user@example.com | ✅ Принят |
| Нет @ | userexample.com | ❌ Ошибка |
| Нет домена после @ | user@ | ❌ Ошибка |
| Спецсимволы в имени | user+tag@example.com | ✅ (зависит от требований) |
| Email с кириллицей | пользователь@пример.рф | ✅ (если поддерживается IDN) |
2.3. Когда применять
- Поля ввода (имя, email, возраст, сумма)
- Выпадающие списки (каждое значение — класс)
- Числовые диапазоны
3. Анализ граничных значений (Boundary Value Analysis)
3.1. Идея
Большинство багов сидит на границах классов эквивалентности. Разработчики часто допускают ошибки типа <= вместо <, путают «включительно» и «исключительно».
Правило: для каждой границы проверяем 3 значения:
- N-1 (перед границей)
- N (на границе)
- N+1 (после границы)
Пример: Поле «количество символов в заголовке» — от 1 до 255.
| Граница | Значения | Ожидаемый результат |
|---|---|---|
| Нижняя (min) | 0 (N-1), 1 (N), 2 (N+1) | 0 — ошибка, 1 — ок, 2 — ок |
| Верхняя (max) | 254 (N-1), 255 (N), 256 (N+1) | 254 — ок, 255 — ок, 256 — ошибка |
Всего 6 тестов (3 нижних + 3 верхних) вместо 256.
3.2. Пример: сумма заказа
Условие: «Скидка 10% при сумме заказа от 1000 до 5000 рублей включительно».
| Значение | Класс | Ожидание |
|---|---|---|
| 999 | Ниже границы | ❌ Без скидки |
| 1000 | Нижняя граница (включительно) | ✅ Скидка 10% |
| 1001 | Сразу после нижней | ✅ Скидка 10% |
| 4999 | Перед верхней | ✅ Скидка 10% |
| 5000 | Верхняя граница (включительно) | ✅ Скидка 10% |
| 5001 | Сразу после верхней | ❌ Без скидки |
3.3. Пример: пароль (8–64 символа, минимум 1 цифра и 1 заглавная)
| Граница | Значение | Ожидание |
|---|---|---|
| Нижняя — 8 символов | 7 символов (N-1) | ❌ Ошибка |
| Нижняя — 8 символов | 8 символов (N) | ✅ Успех |
| Нижняя — 8 символов | 9 символов (N+1) | ✅ Успех |
| Верхняя — 64 символа | 63 символа (N-1) | ✅ Успех |
| Верхняя — 64 символа | 64 символа (N) | ✅ Успех |
| Верхняя — 64 символа | 65 символов (N+1) | ❌ Ошибка |
Важно: Это только длина. Если пароль должен содержать цифру и заглавную букву — это отдельные классы эквивалентности и отдельные тесты.
3.4. Когда применять
- Числовые поля с ограничениями
- Строки с maxLength
- Даты (дедлайн — не раньше сегодня)
- Количество элементов (0, 1, много)
- Пароли, коды, номера (длина)
4. Таблица решений (Decision Table)
4.1. Идея
Бизнес-логика часто описывается как «ЕСЛИ [условия] → ТО [действия]». Decision Table систематизирует все комбинации условий.
4.2. Структура
| Условия | Правило 1 | Правило 2 | Правило 3 | Правило 4 | |
|---|---|---|---|---|---|
| C1 | Пользователь авторизован? | Y | Y | N | N |
| C2 | Задача принадлежит пользователю? | Y | N | — | — |
| C3 | Статус = «In Progress»? | Y | — | — | — |
| A1 | Статус меняется на Done | ✅ | ❌ | ❌ | ❌ |
| A2 | 403 Forbidden | ❌ | ✅ | ❌ | ❌ |
| A3 | 401 Unauthorized | ❌ | ❌ | ✅ | ✅ |
Примечание: «—» (безразличное значение) означает, что условие не влияет на результат. Это сокращает таблицу.
4.3. Пример: скидка на заказ
Условия:
- C1: Сумма > 5000?
- C2: Постоянный клиент (более 3 заказов)?
- C3: Промокод введён?
Действия:
- A1: Скидка 15%
- A2: Скидка 10%
- A3: Скидка 5%
- A4: Скидка 0%
| C1: > 5000? | C2: Постоянный? | C3: Промокод? | Действие | |
|---|---|---|---|---|
| 1 | Y | Y | Y | A1: 15% |
| 2 | Y | Y | N | A1: 15% |
| 3 | Y | N | Y | A2: 10% |
| 4 | Y | N | N | A3: 5% |
| 5 | N | Y | Y | A2: 10% |
| 6 | N | Y | N | A3: 5% |
| 7 | N | N | Y | A3: 5% |
| 8 | N | N | N | A4: 0% |
Всего 8 тестов. Если не использовать Decision Table — можно забыть комбинацию 5 или 7.
4.4. Когда применять
- Сложная бизнес-логика («Если A и (B или не C), то D»)
- Калькуляторы, скоринг, расчёт скидок
- Правила с несколькими независимыми условиями
- Валидация форм с несколькими полями
5. Таблица переходов (State-Transition)
5.1. Идея
Объект (заказ, задача, документ) проходит через состояния. Тестируем все переходы между состояниями. Каждый переход — это тест-кейс.
5.2. Пример: статусы задачи
┌──────────┐
┌──────────│ To Do │◄────┐
│ └────┬─────┘ │
│ │ │
▼ ▼ │
┌────────┐ ┌──────────┐ │
│ Blocked│◄───│ In Progress│─────┘
└────────┘ └────┬─────┘
│
▼
┌──────────┐
│ Testing │
└────┬─────┘
│
┌────▼─────┐
│ Done │
└──────────┘
Таблица переходов:
| Текущий статус | Действие | Следующий статус | Разрешён? |
|---|---|---|---|
| To Do | Начать выполнение | In Progress | ✅ |
| To Do | Заблокировать | Blocked | ✅ |
| To Do | Перевести в Done | ❌ | ❌ |
| In Progress | Завершить | Testing (или Done) | ✅ |
| In Progress | Заблокировать | Blocked | ✅ |
| Blocked | Разблокировать | To Do | ✅ |
| Testing | Принять | Done | ✅ |
| Testing | Отклонить | In Progress | ✅ |
| Done | Изменить | ❌ (done — терминальное) | ❌ |
5.3. Тупиковые статусы (Deadlock States) — что должен проверить аналитик
Тупиковый статус — состояние, из которого объект не может выйти, хотя бизнес-процесс требует продолжения. Это одна из самых опасных ошибок в проектировании статусных моделей.
Пример тупика в Task Manager:
Некорректная статусная модель:
To Do → In Progress → Blocked
│
▼ (нет стрелки обратно!)
?????
Задача перешла в Blocked, но из Blocked нет перехода никуда. Разработчик не предусмотрел «разблокировку». Задача навсегда остаётся в Blocked. Пользователь не может её закрыть, удалить или вернуть в работу. Единственный выход — DBA с запросом UPDATE tasks SET status = 'To Do' WHERE id = 42;
Ещё пример тупика:
Заказ:
Новый → Оплачен → Отгружен
↓
Отменён
Вопрос аналитику: Можно ли отменить заказ после оплаты? А после отгрузки? Если нет стрелки «Отменён → ...», но отмена разрешена на всех этапах — это баг в модели.
Как аналитик защищает систему от тупиков
| Правило | Описание |
|---|---|
| Каждый статус имеет минимум один выход (кроме терминальных) | Из Blocked — в To Do. Из Testing — в Done или In Progress. |
| Терминальные статусы — явно | Done и Cancelled — терминальные, из них нет переходов. Это нормально. |
| Все статусы имеют вход | Если статус есть, но в него нельзя перейти — он мёртвый (dead code). |
| Компенсационные переходы | Для каждого статуса существует «откат»: из In Progress → To Do (вернуть в работу). |
| Статус на схеме ≠ статус в коде | Проверить, что enum в коде соответствует диаграмме состояний. |
Алгоритм проверки статусной модели
1. Выписать все статусы
2. Для каждого статуса:
а. Какие статусы могут в него перейти? (входы)
б. В какие статусы он может перейти? (выходы)
3. Если статус не терминальный и не имеет выходов → DEADLOCK ⚠️
4. Если статус не имеет входов → DEAD STATE (мёртвый статус) ⚠️
5. Если бизнес-правило разрешает переход, но на схеме его нет → MISSING EDGE ⚠️
Таблица самопроверки для аналитика
| Статус | Входы (откуда) | Выходы (куда) | Терминальный? | Проблема |
|---|---|---|---|---|
| To Do | New, Blocked | In Progress, Blocked | ❌ | ✅ Норма |
| In Progress | To Do, Testing | Testing, Blocked, To Do | ❌ | ✅ Норма |
| Testing | In Progress | Done, In Progress | ❌ | ✅ Норма |
| Blocked | To Do, In Progress | To Do | ❌ | ✅ Есть выход |
| Done | Testing | — | ✅ | ✅ Терминальный |
| Cancelled | To Do | — | ✅ | ✅ Терминальный |
| Archived | — | — | ❌ | ⚠️ Нет входов — мёртвый статус! |
| On Hold | In Progress | — | ❌ | ⚠️ Нет выходов — тупик! |
5.4. Когда применять State-Transition
- Объекты со сложным жизненным циклом (заказ, заявка, документ, задача)
- Статусы с разными переходами (не все переходы возможны)
- BPMN-процессы (каждый шаг процесса — переход между состояниями)
- Воркфлоу согласования (заявка: Черновик → На согласовании → Согласовано / Отклонено)
6. Попарное тестирование (Pairwise / All-Pairs)
6.1. Математическая и логическая суть
Pairwise Testing опирается на эмпирическое наблюдение: 80–90% багов вызываются взаимодействием двух параметров. Баги, вызванные одновременным взаимодействием трёх и более параметров, крайне редки (статистически < 5%).
6.2. Феномен комбинаторного взрыва
Полное переборное тестирование (exhaustive testing) невозможно. Количество комбинаций растёт экспоненциально:
| Количество параметров | Вариантов каждого | Всего комбинаций | Время (3 мин/тест) |
|---|---|---|---|
| 3 | 4 | 64 | 3.2 часа |
| 4 | 4 | 256 | 12.8 часов |
| 5 | 4 | 1024 | 2.1 дня |
| 6 | 5 | 15625 | 32.6 дня |
| 7 | 6 | 279936 | 1.6 года |
| 8 | 8 | 16777216 | 95.7 лет |
Как Pairwise решает проблему:
Pairwise тестирует все пары значений, а не все комбинации. Если параметров N, каждый с Vi вариантами, то количество пар:
Количество пар = Σ(i < j) Vi × Vj
Вместо произведения всех вариантов (Π Vi), Pairwise строит минимальный набор тестов, в котором каждая пара значений хотя бы раз встречается вместе.
Эмпирическое правило:
- Полный перебор: 10^6 тестов
- Pairwise: ~ 10^2 тестов
- Покрытие багов: ~ 85–90%
6.3. Почему Pairwise эффективен
Исследования (National Institute of Standards and Technology, 2002):
| Тип дефекта | Процент от всех багов |
|---|---|
| Вызывается 1 параметром | 30–40% |
| Вызывается 2 параметрами | 40–50% |
| Вызывается 3 параметрами | 10–15% |
| Вызывается 4+ параметрами | < 5% |
Вывод: Pairwise покрывает ~80% всех возможных багов (30–50% + 40–50%).
6.4. Пример: форма поиска задач
Форма поиска задач:
- Статус: To Do, In Progress, Done (3 значения)
- Приоритет: Low, Medium, High, Critical (4 значения)
- Исполнитель: Анна, Иван (2 значения)
Полное переборное тестирование: 3 × 4 × 2 = 24 теста.
Pairwise (все пары): 6 тестов.
| Тест | Status | Priority | Assignee |
|---|---|---|---|
| 1 | To Do | Low | Анна |
| 2 | To Do | High | Иван |
| 3 | In Progress | Low | Иван |
| 4 | In Progress | Critical | Анна |
| 5 | Done | Medium | Анна |
| 6 | Done | High | Иван |
Проверка покрытия пар:
| Пара | Комбинации | Покрыто? |
|---|---|---|
| Status × Priority | 3 × 4 = 12 | Да (Low/To Do, High/To Do, Low/In Progress, ...) |
| Status × Assignee | 3 × 2 = 6 | Да (To Do/Анна, To Do/Иван, ...) |
| Priority × Assignee | 4 × 2 = 8 | Да (Low/Анна, High/Иван, Low/Иван, Critical/Анна, ...) |
Каждая пара значений встретилась хотя бы один раз. 24 теста → 6 тестов, покрытие ~80% багов.
6.5. Пример с большим количеством параметров
Форма регистрации:
- Email: валидный, невалидный (2)
- Пароль: валидный, короткий, без цифры, без заглавной (4)
- Имя: валидное, пустое, слишком длинное (3)
- Согласие с правилами: да, нет (2)
- Капча: пройдена, не пройдена (2)
Полный перебор: 2 × 4 × 3 × 2 × 2 = 96 тестов Pairwise: ~15–16 тестов (сокращение в 6 раз)
Пример Pairwise-набора (создан инструментом PICT):
| № | Password | Name | Agreement | Captcha | |
|---|---|---|---|---|---|
| 1 | valid | valid | valid | yes | passed |
| 2 | valid | short | empty | no | passed |
| 3 | valid | no_digit | long | yes | failed |
| 4 | valid | no_upper | valid | no | passed |
| 5 | invalid | valid | empty | no | failed |
| 6 | invalid | short | valid | yes | passed |
| 7 | invalid | no_digit | valid | no | failed |
| 8 | invalid | no_upper | long | yes | passed |
| ... | ... | ... | ... | ... | ... |
6.6. Инструменты для Pairwise
| Инструмент | Описание | Как использовать |
|---|---|---|
| PICT (Microsoft) | Консольная утилита, золотой стандарт | pict model.txt > tests.txt |
| AllPairs | Python-библиотека | allpairs(model) |
| Pairwise Online | Веб-сервисы | pairwise.yuuniworks.com |
| Hexawise | Коммерческий, с аналитикой | Загрузить параметры → получить тесты |
Пример работы с PICT:
Файл model.txt:
Status: To Do, In Progress, Done
Priority: Low, Medium, High, Critical
Assignee: Anna, Ivan
Команда:
pict model.txt > pairwise-tests.txt
Результат:
Status Priority Assignee
To Do Low Anna
To Do High Ivan
In Progress Low Ivan
In Progress Critical Anna
Done Medium Anna
Done High Ivan
6.7. Ограничения Pairwise
| Ограничение | Пояснение | Mitigation |
|---|---|---|
| Не покрывает тройные взаимодействия | Если баг возникает только при комбинации 3+ параметров — Pairwise может не найти | Для критических функций добавить N-wise (N=3) |
| Не учитывает бизнес-логику | Pairwise может сгенерировать комбинацию, которая невозможна бизнес-правилами | Добавить constraints: «Если Status = Done, то Priority не может быть Critical» |
| Не заменяет Boundary Values | Pairwise про комбинации, не про границы | Комбинировать: Pairwise + BVA для критических полей |
| Требует инструмента | Вручную сложно построить оптимальный набор | Использовать PICT или онлайн-сервисы |
6.8. Когда применять Pairwise
| Ситуация | Pairwise? | Почему |
|---|---|---|
| Форма фильтрации (5+ параметров, много значений) | ✅ | Комбинаторный взрыв |
| Тестирование конфигураций (ОС × Браузер × Версия) | ✅ | Классический use case |
| CRUD-операции (стандартные) | ❌ | Достаточно эквивалентного разбиения |
| Критическая функция (оплата, безопасность) | ⚠️ | Pairwise + BVA + E2E |
| 2–3 параметра с небольшим количеством значений | ❌ | Полный перебор всё равно небольшой (8–27 тестов) |
7. Выбор техники тест-дизайна
| Ситуация | Техника | Почему |
|---|---|---|
| Поле ввода с диапазоном (0–255) | Boundary Value | Больше всего багов на границах |
| Много независимых полей в форме | Equivalent Partitioning | Сокращает количество тестов |
| Сложная бизнес-логика (3+ условия) | Decision Table | Систематизация всех комбинаций |
| Объект со статусами | State-Transition | Проверяем все разрешённые переходы |
| Тестирование фильтрации (много параметров) | Pairwise | Сокращаем количество тестов |
| Критическая функция (например, оплата) | Все техники + E2E | Риск высок — нужно максимально покрыть |
| Пароль (длина + состав) | Boundary Value + Classes | Длина — границы, состав — классы |
8. Итоговая памятка: что должен сделать аналитик с каждой User Story
| № | Шаг | Техника | Результат |
|---|---|---|---|
| 1 | Выделить входные данные (поля, параметры) | — | Список полей с типами |
| 2 | Для каждого поля определить классы эквивалентности | EP | Классы валидных/невалидных значений |
| 3 | Для числовых полей определить границы | BVA | Значения N-1, N, N+1 для каждой границы |
| 4 | Если есть бизнес-логика (условия) → Decision Table | DT | Все комбинации условий и действий |
| 5 | Если объект имеет статусы → State-Transition | ST | Все разрешённые/запрещённые переходы |
| 6 | Если много комбинаций полей → Pairwise | PW | Минимальный набор тестов |
| 7 | Проверить, что Acceptance Criteria покрывают все классы | — | Нет непроверенных сценариев |
Вопросы для самопроверки
- Что такое класс эквивалентности? Как он помогает сократить количество тестов?
- Почему граничные значения — самое частое место багов?
- Какие 3 значения нужно тестировать для каждой границы?
- Сколько тестов нужно для проверки поля «пароль 8–64 символа» с помощью BVA?
- Когда применяется Decision Table?
- Чем State-Transition отличается от Decision Table?
- Какая проблема возникает при полном переборном тестировании? Как Pairwise её решает?
- Сколько тестов нужно для 5 полей по 6 значений каждое? А с Pairwise? (примерно)
- Какой процент багов, по статистике, вызывается взаимодействием двух параметров?
- Что такое тупиковый статус (deadlock state)? Как его обнаружить?
- Какие три вопроса нужно задать для каждого статуса в State-Transition?
- В чём ограничение Pairwise? Когда его недостаточно?
Практическое задание
Задание 1. Примените техники тест-дизайна
Кейс: Форма создания задачи в Task Manager.
Поля:
- title: строка, обязательное, 1–255 символов
- description: строка, опционально, до 5000 символов
- status: выпадающий список: To Do, In Progress, Done (только для создания — To Do)
- priority: выпадающий список: Low, Medium, High, Critical
- assignee_id: число, необязательно, должно ссылаться на существующего пользователя
- deadline: дата, необязательно, не может быть в прошлом
Примените:
- Эквивалентное разбиение для поля deadline (дата). Какие классы?
- Boundary Value Analysis для поля title (1–255). Какие 6 тестов?
- Decision Table для логики: если priority=Critical и assignee_id не указан → ошибка «Для Critical задачи нужно назначить исполнителя».
- Pairwise для полей: status (1 значение — To Do, исключаем), priority (4), assignee_id (2: указан / не указан). Сколько тестов нужно?
Задание 2. Постройте таблицу переходов
Для статусов задачи из урока 08.01 (см. State-Transition пример) постройте полную таблицу всех разрешённых и запрещённых переходов. Добавьте два дополнительных правила:
- Из Done нельзя перейти никуда (терминальный статус)
- Из Blocked можно перейти только в To Do (разблокировать)
Задание 3. Найдите тупиковые статусы
Дана статусная модель заказа в интернет-магазине:
Новый → Подтверждён → Оплачен → Отгружен → Доставлен
↓ ↓ ↓
Отменён Отменён Возврат
↓
?????
Вопросы:
- Какие статусы являются терминальными?
- Есть ли тупиковый статус? Какой?
- Какие переходы отсутствуют, но нужны бизнесу?
- Нарисуйте исправленную модель.
Задание 4. Pairwise для фильтрации
Кейс: Фильтр задач на dashboard:
- Status: To Do, In Progress, Testing, Done, Blocked (5)
- Priority: Low, Medium, High, Critical (4)
- Assignee: Я, Другие, Все (3)
- Project: Проект A, Проект B, Все (3)
- Due date: Сегодня, Эта неделя, Этот месяц, Все (4)
- Сколько всего комбинаций? (полный перебор)
- Используя технику Pairwise, оцените, сколько тестов нужно (приблизительно)
- Напишите модель для PICT (синтаксис)
- Какие пары вы считаете самыми критичными для бизнеса?
Задание 5. Анализ
Коллега-тестировщик предлагает протестировать поле title всеми значениями от 0 до 256 (257 тестов). Как вы убедите его сократить до 6 тестов, используя Boundary Value Analysis? Напишите аргументацию (3–4 предложения).
Дополнительные материалы
- Книга: Ли Коупленд — «A Practitioner's Guide to Software Test Design» — полный обзор техник
- Книга: Роман Савин — «Тестирование Дот Ком», главы по тест-дизайну
- Статья: National Institute of Standards and Technology (NIST) — «The Economic Impacts of Inadequate Infrastructure for Software Testing» (2002) — статистика по парным дефектам
- Инструмент: PICT (Microsoft) — Pairwise Testing, консольная утилита
- Инструмент: Pairwise Online — pairwise.yuuniworks.com
- Инструмент: State Transition Viewer — для отладки статусных моделей
- Шпаргалка: «Test Design Techniques Cheat Sheet» — памятка по всем техникам
- Стандарт: ISTQB Syllabus — раздел «Test Design Techniques»
- Видео: «Pairwise Testing Explained» на YouTube — наглядная демонстрация