Что такое причинно-следственные графы?

Причинно-следственные графы (Cause-Effect Graphing) — это систематическая техника, которая переводит спецификации на естественном языке в граф булевой логики, который затем преобразуется в таблицу решений. Она связывает неоднозначные требования с точными тест-кейсами.

Зачем использовать причинно-следственные графы?

Таблицы решений мощны, но имеют слабость: при большом числе условий получается 2^N правил, большинство из которых могут быть невозможными или избыточными. Причинно-следственные графы решают эту проблему, моделируя логические связи и ограничения между входами, генерируя только осмысленные комбинации.

Ключевые концепции

  • Причина (Cause): Входное условие или стимул (левая сторона графа)
  • Следствие (Effect): Выход или реакция системы (правая сторона графа)
  • Булевы операторы: AND, OR, NOT — связывают причины со следствиями
  • Ограничения: Правила, определяющие допустимые комбинации причин

Процесс

flowchart LR A[1. Определить причины и следствия] --> B[2. Нарисовать булевы связи] B --> C[3. Добавить ограничения] C --> D[4. Преобразовать в таблицу решений] D --> E[5. Вывести тест-кейсы]

Булевы операторы в графах

Тождество: Если причина C1 истинна, следствие E1 истинно.

C1 ────── E1

NOT (отрицание): Если причина C1 истинна, следствие E1 ложно.

C1 ──~──── E1

AND: Следствие E1 истинно только когда C1 И C2 истинны.

C1 ──┐
     ├─ AND ── E1
C2 ──┘

OR: Следствие E1 истинно когда C1 ИЛИ C2 (или оба) истинны.

C1 ──┐
     ├─ OR ── E1
C2 ──┘

Пример: Система авторизации

Спецификация:

  • Если username валиден И пароль правильный, предоставить доступ
  • Если username валиден И пароль неправильный, показать «неверный пароль»
  • Если username невалиден, показать «пользователь не найден»

Причины:

  • C1: Username валиден
  • C2: Пароль правильный

Следствия:

  • E1: Предоставить доступ
  • E2: Показать «неверный пароль»
  • E3: Показать «пользователь не найден»

Граф:

C1 ──┐
     ├─ AND ── E1 (предоставить доступ)
C2 ──┘

C1 ──┐
     ├─ AND ── E2 (неверный пароль)
~C2 ─┘

~C1 ────────── E3 (пользователь не найден)

Ограничения между причинами

Входные данные в реальном мире часто имеют зависимости. Ограничения моделируют их:

ОграничениеСимволЗначение
ExclusiveEМаксимум одна причина может быть истинной
InclusiveIХотя бы одна причина должна быть истинной
One-and-only-oneOРовно одна причина должна быть истинной
RequiresRЕсли C1 истинна, C2 тоже должна быть истинной
MasksMЕсли C1 истинна, C2 принудительно ложна

Пример: Выбор способа оплаты

  • C1: Выбрана кредитная карта
  • C2: Выбран PayPal
  • C3: Выбран банковский перевод

Ограничение: O (One-and-only-one) — ровно один способ оплаты должен быть выбран.

Это исключает комбинации, где выбрано 0 или 2+ способов, резко сокращая таблицу решений.

Преобразование в таблицу решений

Для примера с авторизацией:

П1П2П3
C1: Username валиденИИЛ
C2: Пароль правильныйИЛ-
Следствия
E1: ДоступX
E2: Неверный парольX
E3: Не найденX

Когда C1 ложна (П3), C2 несущественна (помечена -), потому что система показывает «пользователь не найден» независимо от пароля.

Продвинутые причинно-следственные графы

Сложный пример: Система скидок на заказы

Спецификация:

  • Причина C1: Клиент — VIP-участник
  • Причина C2: Сумма заказа > $100
  • Причина C3: Применён купон
  • Ограничение: C1 и C3 взаимоисключающие (E) — VIP-участники не могут использовать купоны
  • Следствие E1: Скидка 10% (VIP)
  • Следствие E2: Скидка 15% (VIP + заказ > $100)
  • Следствие E3: Скидка по купону
  • Следствие E4: Без скидки

Построение графа:

C1 AND C2 ──── E2 (15% VIP + объём)
C1 AND ~C2 ── E1 (10% только VIP)
~C1 AND C3 ── E3 (скидка по купону)
~C1 AND ~C3 ─ E4 (без скидки)

Ограничение E между C1 и C3

Таблица решений после применения ограничения:

П1П2П3П4
C1: VIPИИЛЛ
C2: Сумма > $100ИЛ--
C3: КупонЛ*Л*ИЛ
Следствия
E2: 15%X
E1: 10%X
E3: КупонX
E4: Без скидкиX

C3 принудительно ложна когда C1 истинна из-за ограничения Exclusive.

Без ограничения было бы 2^3 = 8 правил. С ним — только 4 осмысленных комбинации.

Работа с большими спецификациями

Для сложных систем с множеством причин и следствий:

  1. Декомпозируйте. Разбейте спецификацию на независимые подразделы, каждый со своим графом.
  2. Выстраивайте цепочки. Следствие одного графа может стать причиной в другом.
  3. Нумеруйте систематически. Используйте C1-Cn для причин, E1-En для следствий, согласовано с трассировкой требований.

Типичные ошибки

  1. Пропуск отрицаний. Не забывайте моделировать, что происходит когда причина ложна.
  2. Игнорирование ограничений. Без ограничений вы сгенерируете невозможные тест-кейсы.
  3. Путаница причин и следствий. Причины — это входы, которыми вы управляете; следствия — выходы, которые вы наблюдаете.

Упражнение: Постройте причинно-следственный граф

Сценарий: Система загрузки файлов имеет следующие правила:

  • C1: Размер файла <= 10MB
  • C2: Тип файла допустим (jpg, png, pdf)
  • C3: Пользователь аутентифицирован
  • C4: Квота хранилища не превышена

Правила:

  • Если C3 ложна → E1: «Пожалуйста, войдите в систему»
  • Если C3 И C1 И C2 И C4 → E2: «Загрузка успешна»
  • Если C3 И НЕ C1 → E3: «Файл слишком большой»
  • Если C3 И НЕ C2 → E4: «Тип файла не разрешён»
  • Если C3 И C1 И C2 И НЕ C4 → E5: «Хранилище заполнено»

Ограничение: R (Requires) — C1, C2, C4 требуют C3

Задание: Нарисуйте граф, примените ограничения, постройте таблицу решений и подсчитайте тест-кейсы.

Подсказка

C3 (аутентификация) — входное условие. Когда она ложна, остальные причины не имеют значения. Когда истинна — нужно рассмотреть комбинации C1, C2 и C4, но учитывайте приоритет ошибок.

Решение

Таблица решений (C3 управляет всем):

П1П2П3П4П5
C3: АутентифицированЛИИИИ
C1: Размер OK-ЛИИИ
C2: Тип OK--ЛИИ
C4: Квота OK---ЛИ
Следствия
E1: Войдите в системуX
E3: Файл большойX
E4: Тип не разрешёнX
E5: Хранилище полноX
E2: Загрузка успешнаX

5 тест-кейсов — каскадная валидация означает, что ранние отказы делают последующие причины несущественными.

Советы профессионала

  • Используйте причинно-следственные графы, когда таблицы решений слишком большие. При 6+ условиях полная таблица содержит 64+ правил. Ограничения могут резко сократить это число.
  • Сочетайте с ревью требований. Построение графа часто выявляет двусмысленности, противоречия и пробелы в спецификации — это ценная техника ревью.
  • Документируйте граф. Визуальное представление отлично подходит для коммуникации логики тестирования разработчикам и product owner.
  • Применяйте порядок приоритета ошибок. В реальных системах валидации имеют приоритет (сначала авторизация, затем валидация входных данных, затем бизнес-правила).