Что такое попарное тестирование?

Попарное тестирование (pairwise testing, также all-pairs testing) — техника комбинаторного тест-дизайна, основанная на ключевом наблюдении: большинство дефектов вызвано взаимодействием двух параметров, а не трёх или более одновременно.

Вместо тестирования каждой возможной комбинации (число которых растёт экспоненциально), попарное тестирование гарантирует, что каждая пара значений параметров встретится хотя бы в одном тест-кейсе.

Проблема комбинаторного взрыва

Рассмотрим тестирование веб-приложения на:

  • ОС: Windows, macOS, Linux (3)
  • Браузер: Chrome, Firefox, Safari, Edge (4)
  • Язык: EN, ES, RU (3)
  • Экран: Desktop, Tablet, Mobile (3)

Исчерпывающее тестирование: 3 x 4 x 3 x 3 = 108 комбинаций

Попарное тестирование: примерно 12-15 тест-кейсов — с покрытием каждой пары.

Как работает попарное тестирование

flowchart TD A[Перечислить все параметры и значения] --> B[Сгенерировать все возможные пары] B --> C[Создать тест-кейсы, покрывающие несколько пар каждый] C --> D[Оптимизировать: минимизировать общее число тест-кейсов] D --> E[Результат: компактный тестовый набор]

Для 3 параметров (A, B, C) с 2 значениями каждый (1, 2):

Все пары для покрытия:

  • A-B: (1,1), (1,2), (2,1), (2,2)
  • A-C: (1,1), (1,2), (2,1), (2,2)
  • B-C: (1,1), (1,2), (2,1), (2,2)

Попарный набор всего из 4 тест-кейсов:

ТестABC
1111
2122
3212
4221

Каждая пара встречается хотя бы раз. Исчерпывающее потребовало бы 2^3 = 8 тестов.

Знакомство с PICT

PICT (Pairwise Independent Combinatorial Testing) — бесплатный open-source инструмент Microsoft командной строки для генерации попарных тестовых наборов.

Установка:

# macOS
brew install pict

# Linux (сборка из исходников)
git clone https://github.com/microsoft/pict.git
cd pict && make

# Windows
# Скачать с GitHub releases

Базовое использование:

Создайте файл модели web-test.txt:

OS:       Windows, macOS, Linux
Browser:  Chrome, Firefox, Safari, Edge
Language: EN, ES, RU
Screen:   Desktop, Tablet, Mobile

Запустите PICT:

pict web-test.txt

PICT сгенерирует примерно 12-16 тест-кейсов вместо 108.

Почему попарное тестирование эффективно

Исследование Kuhn, Wallace и Gallo (NIST) показало:

  • 67% дефектов вызываются значением одного параметра
  • 93% вызываются парами значений (2-way взаимодействия)
  • 98% вызываются тройками (3-way)
  • Почти 100% — взаимодействиями 4-way

Попарное тестирование покрывает уровень 93% при малой доле усилий исчерпывающего тестирования.

Продвинутые возможности PICT

Добавление ограничений (Constraints)

Не все комбинации валидны. PICT поддерживает ограничения для исключения невозможных случаев:

OS:       Windows, macOS, Linux, iOS, Android
Browser:  Chrome, Firefox, Safari, Edge

# Ограничения
IF [OS] = "iOS"    THEN [Browser] <> "Edge";
IF [OS] = "iOS"    THEN [Browser] <> "Firefox";
IF [OS] = "Android" THEN [Browser] <> "Safari";
IF [OS] = "Android" THEN [Browser] <> "Edge";
IF [OS] = "Linux"  THEN [Browser] <> "Safari";

PICT никогда не сгенерирует тест-кейс с iOS + Edge или Android + Safari.

Подмодели для покрытия высшего порядка

Иногда определённые группы параметров требуют более сильного покрытия:

OS:       Windows, macOS, Linux
Browser:  Chrome, Firefox, Safari
Language: EN, ES, RU
Theme:    Light, Dark

# По умолчанию: попарное (2-way)
# Но OS-Browser-Language нуждается в 3-way покрытии
{ OS, Browser, Language } @ 3

Посев конкретных комбинаций (Seeding)

Принудительное включение важных комбинаций:

Создайте файл seeds.txt:

OS        Browser  Language  Theme
Windows   Chrome   EN        Light
macOS     Safari   ES        Dark

Запуск с посевом:

pict model.txt /e:seeds.txt

Негативное тестирование с PICT

Добавьте невалидные значения с префиксом ~:

Age:    18, 30, 65, ~-1, ~200
Email:  valid@test.com, ~invalid-email, ~""

PICT гарантирует, что негативные значения появятся в тест-кейсах, но только одно негативное значение на тест-кейс (single fault assumption).

Реальный пример: Матрица тестирования API

Method:      GET, POST, PUT, DELETE
Auth:        Bearer, API-Key, None
ContentType: application/json, multipart/form-data, text/plain
Status:      200, 400, 401, 404, 500

IF [Method] = "GET"  THEN [ContentType] <> "multipart/form-data";
IF [Auth] = "None"   THEN [Status] IN { 401 };
IF [Method] = "DELETE" THEN [ContentType] = "application/json";

Упражнение: Сгенерируйте попарный набор с PICT

Сценарий: Вы тестируете форму обработки платежей:

  • Тип карты: Visa, MasterCard, Amex
  • Валюта: USD, EUR, GBP
  • Диапазон суммы: Маленькая (<$10), Средняя ($10-$100), Большая (>$100)
  • 3D Secure: Включён, Выключен
  • Рекуррентный: Да, Нет

Ограничения:

  • Amex не поддерживает рекуррентные платежи
  • GBP недоступна с 3D Secure Выключен

Задания:

  1. Напишите файл модели PICT
  2. Рассчитайте количество исчерпывающих тестов
  3. Оцените количество попарных тестов
  4. Добавьте ограничения и проверьте результат
Подсказка

Исчерпывающее: 3 x 3 x 3 x 2 x 2 = 108 тестов. PICT сгенерирует примерно 12-18 тестов с ограничениями.

Решение

Файл модели PICT (payment-test.txt):

CardType:  Visa, MasterCard, Amex
Currency:  USD, EUR, GBP
Amount:    Small, Medium, Large
3DSecure:  Enabled, Disabled
Recurring: Yes, No

IF [CardType] = "Amex" THEN [Recurring] = "No";
IF [Currency] = "GBP"  THEN [3DSecure] = "Enabled";

Исчерпывающее: 108 тестов (минус невозможные комбинации)

Попарное с PICT: примерно 12-15 тест-кейсов

Результат: ~12 тестов вместо 108 — сокращение на 89% при покрытии всех пар.

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

  • Начинайте с попарного, увеличивайте порядок при необходимости. 2-way (попарное) обнаруживает ~93% дефектов. Для домена с высоким риском поднимите критические группы параметров до 3-way.
  • Щедро используйте ограничения. Каждая исключённая невозможная комбинация — это избежанный бесполезный тест.
  • Комбинируйте с другими техниками. Используйте попарное для комбинаций параметров, затем примените BVA для выбора конкретных значений внутри каждого параметра.
  • Автоматизируйте pipeline. Интегрируйте PICT в CI: файл модели → генерация PICT → выполнение параметризованных тестов.
  • Храните модели PICT в системе контроля версий. Обращайтесь с файлами моделей как с тестовыми артефактами — ревьюйте, храните рядом с тестами, обновляйте при изменении параметров.