В функции четыре бинарных параметра, поэтому полный перебор даёт 16 сочетаний. Как применить технику попарного тестирования, чтобы сократить набор проверок, сохранив покрытие взаимодействий двух параметров?
function checkout(browser, os, payment, language) {
if (browser === "Safari" && payment === "PayPal") {
return "fallback";
}
if (os === "macOS" && language === "en") {
return "warning";
}
return "ok";
}
const values = {
browser: ["Chrome", "Safari"],
os: ["Windows", "macOS"],
payment: ["Card", "PayPal"],
language: ["ru", "en"]
};
Нужно составить набор тестов, в котором каждая возможная пара значений любых двух параметров встречается хотя бы один раз. Для четырёх бинарных параметров это позволяет сократить полный перебор из 16 сочетаний до компактного попарного набора, например из 8 тестов, если ограничения между значениями отсутствуют.
Попарное покрытие хорошо ловит дефекты взаимодействия двух факторов, но не гарантирует обнаружение ошибок, возникающих только при одновременном сочетании трёх или четырёх параметров.
Полный перебор комбинаций быстро становится дорогим: при добавлении каждого независимого параметра число сочетаний умножается на количество его значений. При этом многие дефекты конфигурации вызваны взаимодействием небольшого числа факторов, а не всей комбинацией целиком.
Попарное тестирование появилось как компромисс между исчерпывающим перебором и случайной выборкой. Оно систематически покрывает взаимодействия двух параметров, сохраняя приемлемый объём набора.
В примере четыре параметра с двумя значениями дают 2 × 2 × 2 × 2 = 16 комбинаций. Если параметров станет шесть или десять, полный перебор увеличится экспоненциально и может оказаться непрактичным для каждого запуска регрессии.
Неверно просто выбрать несколько случайных строк. Такой набор может не содержать, например, сочетание Safari + PayPal или macOS + en, хотя именно эти взаимодействия влияют на ветвления функции.
Сначала фиксируют параметры и допустимые значения. Затем строят набор строк так, чтобы для каждой пары параметров присутствовали все пары их значений: для browser и payment должны встретиться все сочетания Chrome/Card, Chrome/PayPal, Safari/Card и Safari/PayPal. То же правило применяется к каждой другой паре параметров.
Пример структуры попарного набора:
| № | browser | os | payment | language |
|---|---|---|---|---|
| 1 | Chrome | Windows | Card | ru |
| 2 | Chrome | Windows | PayPal | en |
| 3 | Chrome | macOS | Card | en |
| 4 | Chrome | macOS | PayPal | ru |
| 5 | Safari | Windows | Card | en |
| 6 | Safari | Windows | PayPal | ru |
| 7 | Safari | macOS | Card | ru |
| 8 | Safari | macOS | PayPal | en |
В этом наборе каждая пара значений для каждой пары параметров встречается хотя бы один раз. Поэтому тесты 2 и 6, например, покрывают взаимодействие Safari + PayPal, а тесты 3 и 8 — взаимодействие macOS + en.
На практике набор обычно строит специализированный генератор покрывающих массивов. Перед генерацией нужно описать запрещённые сочетания: например, если конкретная платёжная система недоступна в определённой операционной системе, такую комбинацию нельзя считать обычным тестом.
Попарное покрытие не заменяет другие техники. Отдельно проверяют обязательные бизнес-сценарии, негативные случаи, границы, переходы состояний, производительность, безопасность и комбинации с высоким риском. Если известен дефект именно тройного взаимодействия, для соответствующих параметров повышают силу покрытия до трёхмерного или добавляют целевые тесты вручную.
Главный компромисс таков: набор становится значительно меньше полного, но часть многопараметричных дефектов может остаться незамеченной. Поэтому силу покрытия выбирают по риску, стоимости ошибки и количеству независимых факторов.
В интернет-магазине нужно было проверять сочетания браузера, операционной системы, способа оплаты, языка, валюты и типа доставки. Полный перебор создавал слишком большой набор для каждого изменения интерфейса.
Рассматривались три варианта. Полный перебор давал максимальное комбинаторное покрытие, но был слишком дорогим. Случайная выборка была дешёвой, однако не позволяла доказать, какие взаимодействия проверены. Попарный набор покрывал все пары значений и заметно сокращал объём, но не закрывал редкие тройные взаимодействия.
Выбрали попарный набор как основу регрессии, добавив вручную проверки для рискованных сочетаний: валюты с оплатой, доставки с регионом и сценариев, ранее связанных с дефектами. В результате обычный прогон стал короче, а критичные многопараметричные случаи сохранили отдельное покрытие.
1. Нужно ли включать в попарный набор все возможные значения параметров?
Нет. Сначала значения группируют по ожидаемому поведению с помощью классов эквивалентности. Если несколько браузеров проходят один и тот же кодовый путь и имеют одинаковые риски, их можно представить одной репрезентативной категорией. Но такое объединение допустимо только после анализа требований, платформенных различий и исторических дефектов.
Если значения отличаются бизнес-правилами, ограничениями или реализацией, объединять их нельзя. Иначе формальное попарное покрытие будет достигнуто, но важный реальный сценарий фактически исключится.
2. Достаточно ли попарного покрытия для проверки условия Safari && PayPal?
Да, если пара значений Safari + PayPal присутствует хотя бы в одном тесте и этот тест действительно выполняет функцию с такими входными данными. Попарное покрытие не требует проверять все значения остальных параметров вместе с этой парой.
Однако если результат зависит от третьего фактора, например от языка или валюты, попарного покрытия может быть недостаточно. Тогда нужны тройное покрытие либо целевые тесты для конкретного условия.
3. Что делать, если некоторые сочетания параметров запрещены?
Запрещённые сочетания сначала исключают из модели, иначе генератор может считать недопустимый тест обязательным для покрытия. После этого проверяют попарное покрытие только среди допустимых комбинаций.
Важно отдельно протестировать саму валидацию запрета: систему проверяют не только на корректных строках, но и на попытке передать запрещённое сочетание. Таким образом, модель комбинаций покрывает допустимые сценарии, а негативные проверки подтверждают правильную обработку ограничений.