Pairwise testing
Тема дорожной карты · QA-инженер
Попарное тестирование (также называемое all-pairs testing) — это комбинаторная техника проектирования тестов, которая генерирует минимальный набор тест-кейсов, необходимых для покрытия каждой возможной пары значений параметров хотя бы один раз, основываясь на исследованиях, показывающих, что большинство программных дефектов вызывается взаимодействием двух факторов, а не более сложными комбинациями. Для конфигурации с 4 параметрами, каждый из которых имеет 3 значения (всего 3⁴ = 81 тест полного комбинирования), попарное тестирование обычно сводит это к 9–12 тест-кейсам с помощью инструментов PICT (Pairwise Independent Combinatorial Testing), AllPairs или плагина pytest pytest-pairwise, при этом обнаруживая подавляющее большинство комбинаторных дефектов. Попарное тестирование особенно ценно для тестирования матриц конфигурации системы (браузер × ОС × разрешение экрана × язык), комбинаций параметров API и перестановок флагов функций, где полное комбинаторное покрытие вычислительно нецелесообразно, но непроверенные парные взаимодействия представляют реальный риск дефектов. QA-инженеры применяют попарное тестирование на этапе проектирования тестов в фазе планирования STLC, генерируя таблицу параметров с PICT (pict input.txt > test_cases.txt) и затем кодируя каждую строку как параметризованный pytest-тест или запись DataProvider в TestNG, вызывающую API-эндпоинт через REST Assured или Postman. Попарное тестирование дополняет разбиение на классы эквивалентности и анализ граничных значений: разбиение на классы эквивалентности сокращает пространство значений, анализ граничных значений выбирает граничные представители, а попарное тестирование обрабатывает измерение взаимодействий — вместе они образуют эффективную стратегию проектирования тестов «чёрного ящика» для сложных пространств параметров.
Как это работает
Pairwise testing применяет систематические техники для решения, что тестировать: equivalence partitioning (делим input на классы с тем же поведением), boundary value analysis (off-by-one баги живут на границах), decision tables (комбинации условий), state transitions (состояния + валидные переходы), pairwise testing (все пары параметров протестированы хотя бы раз). Каждая техника торгует широтой покрытия против количества тестов.
Когда применять
Boundary value analysis — на каждом числовом input; 99% off-by-one багов прячутся на min, max, min-1, max+1. Decision tables — когда бизнес-правила комбинируют условия (цена если (premium и регион=EU и количество>10)). State transitions — для stateful-флоу (lifecycle заказа, состояния аккаунта). Pairwise-инструменты (PICT, allpairs) режут экспоненциальные комбинации до управляемого числа тестов.
Типичные ошибки
Ловушки Pairwise testing: тестируют только happy-path (в production странные input); ad-hoc тест-дизайн без traceability к требованиям (нельзя доказать, что тестировали фичу X); только техники без exploratory testing (люди пропускают неожиданное); экспоненциальный рост числа тестов без pairwise-редукции.