itmo_conspects

Лекция 5. Таблицы решений и комбинации условий

Основная проблема создания тест-кейсов заключается в том, что при большом числе параметров полный перебор комбинаций становится невозможным из-за экспоненциального роста. Например, пусть в магазине есть три параметра: статус VIP-клиента, сумма заказа и промокод - суммарно они уже создают сложные комбинации. Если параметров становится больше, число тестов быстро выходит из-под контроля, поэтому нужны методы сокращения без потери важных проверок

Таблица решений, один из способов записи правил, состоит из 4 компонентов:

• Условия, например, “статус клиента”, “сумма заказа не менее 10000 рублей”, “наличие промокода”
• Значения условий, например, “базовый” и “премиум”, “да” и “нет”
• Действия, например, “скидка 10%”, “скидка 5%” или “отсутствие скидки”
• Правила, то есть столбцы, которые связывают условия с действиями

Правила задаются требованиями, например:

VIP-клиент получает скидку 10% при заказе от 10000 рублей
В остальных случаях действующий промокод предоставляет скидку 5%
Скидки не суммируются: применяется максимальная

В этом примере выделяются ключевые условия: статус клиента, сумма заказа и промокод

При сопоставлении условий, их значений и действий получаем такую таблицу:

Условие \ Правило	R1	R2	R3	R4	R5	R6	R7	R8
VIP-клиент	✅	✅	✅	✅	❌	❌	❌	❌
Сумма заказа не менее 10000	✅	✅	❌	❌	✅	✅	❌	❌
Действующий промокод	✅	❌	✅	❌	✅	❌	✅	❌
Действия
Скидка 10%	☑️	☑️
Скидка 5%			☑️		☑️		☑️
Без скидки				☑️		☑️		☑️

Классы эквивалентности помогают сократить количество тестов. Например, сумма заказа делится на диапазоны “менее 0”, “от 0 до 9999” и “не менее 10000”, но на логику влияют только два последних, поэтому условие упрощается до используется бинарное сравнение “не менее 10000” и “менее 10000” вместо точного значения суммы

При трех бинарных условиях полная таблица содержит 8 правил, но при увеличении параметров число комбинаций растет экспоненциально, например, 4 параметра по 3 значения дают 81 тест. По этой причине применяются способы сокращения:

• Удаление лишних условий, если они не влияют на результат

  Условия, которые не влияют на логику (например, имя клиента), перечислять не нужно

• Учет доминирующих условий, когда один параметр делает остальные нерелевантными, например, если пользователь не авторизован, то остальные условия не важны для результата

  Если условие не влияет на решение, то его обозначают длинным тире ➖ или “Не важно”

• Исключение невозможных комбинаций

  Если одно условие неприменимо к ситуации с уже установленными другими условиями, то его обозначают как N/A (от Not Available) или “Неприменимо”

Например, если два столбца с одинаковым результатом “VIP-клиенту с заказом на сумму не менее 10000 дают скидку 10%” можно объединить в одну, так как промокод не влияет на действие. Таким же образом исключаются комбинации условий, которые противоречат друг другу (например, “новый клиент” и “пользователь, который был в системе больше года”). Такие комбинации исключаются из позитивных тестов, но могут стать негативными тестами для проверки обработки ошибок, поэтому важно документировать невозможность сценария

Если одинаковые условия приводят к разным результатам, то решение выбирают исходя из выбранной политики:

• Первое подходящее правило (First Applicable)
• Правило с максимальным приоритетом (Highest Priority)
• Выполняются все применимые действия (All Applicable)
• Выбирается лучший или наиболее выгодный результат (Best Result)
• Такой конфликт обрабатывается отдельным правилом (Explicit Conflict)

Таблица решений дополнительно выявляет в требованиях:

• Пропуски, когда комбинация есть, а действие не указано
• Противоречия, когда для одной комбинации заданы несовместимые действия
• Избыточность, когда несколько пунктов требований сводятся к одному правилу

• Недостижимые условия, когда сценарий логически невозможен

  Такое полезно для тестирования API, где в теле запроса можно указать любое значение, в отличие от UI, где выбор может быть заблокирован

После объединения таблица из примера выше сокращается до трех правил (здесь применяется первое подходящее правило):

Условие \ Правило	R1	R2	R3
VIP-клиент	✅	➖	➖
Сумма заказа не менее 10000	✅	➖	➖
Действующий промокод	➖	✅	❌
Действия
Скидка 10%	☑️
Скидка 5%		☑️
Без скидки			☑️

Правило “VIP-клиенту с заказом на сумму не менее 10000 дают скидку 10%” превращается в готовый тестовый сценарий, где предусловие - это “VIP-клиент с заказом 12000”, действие - это “оплатить без применения промокода”, а ожидаемый результат - это “получение скидки 10% к итоговой сумме”

Здесь дополнительные тесты могут проверять граничные значения, в этом примере можно проверить заказы на сумму 9999 и на сумму 10000

Обычно нет надобности отдельно тестировать невлияющее условие (в этом примере проверять те же условия, но с действующим промокодом), но такое решение зависит от критичности логики и риска проявления дефекта в этой части логики

---

Дополнительные параметры, такие как браузеры, ОС, языки и устройства, усложняют тесты. Например, для 4 параметров “браузер”, “ОС”, “язык” и “роль” по 3 значения полный перебор займет $3^4 = 81$ тест

Полный перебор непрактичен, поэтому используются подходы попарной проверки и проверки всех комбинаций из $T$ параметров

• Попарная проверка (Pairwise или 2-way) покрывает все пары значений параметров, а не все комбинации, например, “Chrome и Windows”, “Chrome и русский язык”. В таком случае получится всего 9 тестов, которые проверяют все пары параметров:

  Тест №	Браузер	ОС	Язык	Роль
  1	Chrome	Windows	Русский	Гость
  2	Chrome	macOS	Английский	Пользователь
  3	Chrome	Linux	Немецкий	Администратор
  4	Firefox	Windows	Английский	Администратор
  5	Firefox	macOS	Немецкий	Гость
  6	Firefox	Linux	Русский	Пользователь
  7	Safari	Windows	Немецкий	Пользователь
  8	Safari	macOS	Русский	Администратор
  9	Safari	Linux	Английский	Гость

  Риск при такой проверке возникает в том, что возможны пропущенные дефекты в редкой комбинации, например “Safari, macOS, немецкий язык и роль администратора”, но предполагается, что основные сценарии учтены

• Проверка всех комбинаций из $T$ параметров (T-way) увеличивает покрытие, но также и число тестов

  При $T = 3$ тесты имеют вид “Chrome, Windows и русский язык”

  Количество тестов при попарной проверке и проверке всех комбинаций из $T$ параметров зависит от числа параметров и значений, которые они принимают. Точной формулы нет, но есть оценка снизу: $N_{\min} = \prod_{j = 1}^T V^{\max}_j$ - произведение $T$ наибольших чисел в порядке убывания (чаще всего эта оценка не совпадает с минимальным числом нужных тестов из-за несовместимости некоторых значений параметров или из-за большего числа параметров)

  В текущем примере для $T = 3$ $N_{\min} = 3 \cdot 3 \cdot 3 = 27$ тестов, для $T = 4$ - $N_{\min} = 3^4 = 81$ (то есть полный перебор)

Выбор параметра $T$ зависит от критичности функции, стоимости выполнения теста, сложности взаимодействия, истории дефектов и требований к покрытию

---

Подытожим:

• Таблицы решений фокусируются на бизнес-правилах, то есть на том, “что делает система”, и требуют детальных требований

  На практике таблицы решений обычно оформляют в программах для работы с таблицами (Excel или Google Sheets)

• Методы попарной проверки и проверки всех комбинаций из $T$ параметров фокусируются на конфигурациях, то есть на том, как система работает в разных условиях

  Попарная проверка не моделирует последовательность действий, поэтому проверяются только независимые конфигурации, а каждый тест должен быть автономным

Алгоритм работы для построения таблицы решений и попарных проверок выглядит так:

• Проанализировать требования и выделить условия и действия
• Построить таблицу решений с учётом приоритетов
• Найти пробелы и противоречия в требованиях
• Упростить таблицу, удалив лишние условия
• Сгенерировать тест-кейсы
• Дополнить набор тестами попарной проверки для конфигураций

Этот сайт имеет открытый исходный код! Вы можете улучшить эту страницу или этот репозиторий!