페어와이즈 조합 테스트로 설정 매트릭스 줄이기
페어와이즈와 t-wise 조합 테스트의 원리부터 제약 모델링, 커버리지 관리, 자동화 파이프라인 적용까지 실무 관점에서 정리합니다.
2026-08-14 · 최초 발행 2025-12-22
모든 조합을 실행할 수 없을 때의 테스트 설계
운영 환경의 옵션, 브라우저, 인증 방식, 플랫폼이 늘어나면 전체 조합을 모두 검증하는 일은 곧 비현실적이 된다. 페어와이즈/조합 테스트는 입력 파라미터의 상호작용을 체계적으로 줄여, 제한된 테스트 케이스로 결함을 찾기 위한 기법이다.
페어와이즈 테스트는 모든 파라미터 쌍(2-wise)의 값 조합이 적어도 한 번은 테스트 집합에 나타나도록 설계한다. 다수의 결함이 두 변수 사이의 상호작용에서 발생한다는 경험적 근거를 바탕으로 한다.
이를 확장한 t-wise 조합 테스트는 t개 파라미터가 만드는 모든 값 조합을 커버한다. t를 높이면 더 복합적인 상호작용을 확인할 수 있지만, 테스트 수와 실행 비용도 함께 증가한다.
커버링 어레이는 주어진 t-wise 조건을 만족하는 최소 크기의 배열을 뜻한다. 직교 배열은 모든 조합이 균등하게 반복되도록 만든 특수한 형태다. 제약이 있거나 파라미터별 값 도메인이 고르지 않은 실무 환경에서는 커버링 어레이가 더 유연하게 쓰인다.
테스트 모델은 파라미터와 제약에서 시작한다
조합 생성기의 품질은 입력 모델의 품질을 넘지 못한다. 먼저 서로 독립적인 파라미터를 식별하고, 각 파라미터의 값 도메인을 분류한다. 대표값과 경계값을 선택하며, 동등 분할과 값 수의 균형화로 불필요한 조합 증가를 막는다.
불가능하거나 의미 없는 조합은 제약으로 정의한다. if-then, mutex, requires 같은 규칙을 사용해 제외 조건을 모델에 넣고, 생성 전 정적 검증과 생성 중 동적 필터링을 함께 적용한다. 제약을 반영하지 않으면 테스트를 낭비하거나 실행 자체가 실패하는 조합이 포함될 수 있다.
조합 생성에는 AllPairs, IPOG/IPOG-D, SA/GA 기반 휴리스틱 등을 활용할 수 있다. 이들은 목표 t-wise 커버리지와 제약을 충족하면서 가능한 작은 테스트 집합을 찾는다. 생성 이후에는 t-wise 커버리지율, 미커버 조합 수, 결함과 조합의 매핑 비율을 추적해 누락 위험과 잔여 리스크를 확인한다.
NIST ACTS, Microsoft PICT, allpairspy 같은 도구를 사용하면 조합 생성부터 테스트 데이터 생성, 실행, 결함 피드백까지 CI 파이프라인으로 연결할 수 있다.
생성과 검증은 피드백 루프로 운영한다
t 값, 제약, 목표 커버리지를 먼저 합의한 뒤 생성·검증·실행의 순서를 반복한다. 실행 과정에서 발견한 실패와 결함은 파라미터 모델 및 제약 규칙으로 되돌려야 한다.
전체 조합과 t-wise 적용 범위
| 방법 | 성능(테스트 수) | 확장성 | 일관성(커버리지) | 안정성(결함 검출률) | 운영 편의 |
|---|---|---|---|---|---|
| 전체 조합(Exhaustive) | 지수적 증가, 매우 큼 | 낮음 | 100% 조합 커버 | 최고, 비용 과다 | 자동화 필수, 실무 비현실 사례 다수 |
| 페어와이즈(2-wise) | 대폭 감소, 수십 수준 | 매우 높음 | 모든 2-튜플 보장 | 다수 상호작용 결함 포착(경험치 60~90%) | 도구 다양, 도입 용이 |
| 3-wise 이상 | 증가, 수십~수백 | 보통 | t-wise 보장 | 복합 상호작용 결함 탐지 강화 | 제약·시간 증가, 선택적 적용 권장 |
전체 조합은 모든 경우를 보장하지만 파라미터가 늘수록 비용이 지수적으로 커진다. 반면 2-wise는 많은 설정 조합을 다뤄야 하는 환경에서 기본 선택지가 될 수 있다. 복합 상호작용 위험이 큰 기능은 3-wise 이상을 선택적으로 적용하는 방식이 적합하다.
설정 매트릭스와 호환성 검증에 적용하는 방식
웹·모바일 환경에서는 OS, 브라우저, 로케일, 네트워크 조건을 조합해 테스트 범위를 줄일 수 있다. Safari=macOS, SSO≠Linux처럼 성립하지 않는 조건을 제약으로 넣으면 무의미한 케이스를 제거할 수 있다.
기능 토글, 라이선스 레벨, 플러그인 호환성을 검증하는 제품 구성에서도 t-wise를 적용할 수 있다. 중요 플로우에는 3-wise를, 주변부에는 2-wise를 적용하는 혼합 전략이 가능하다.
플랫폼과 디바이스 호환성 검증에서는 펌웨어 버전, 칩셋, 드라이버, 주파수 대역의 조합을 다룬다. 환경 매트릭스를 자동 생성한 뒤 HIL/실장 테스트와 연결하는 방식으로 활용할 수 있다.
Python으로 제약을 포함한 Pairwise 조합 만들기
다음 예시는 Python 3.10+와 pip 설치를 가정하며, allpairspy 2.x를 사용한다.
설치 명령은 다음과 같다.
- pip install allpairspy
from allpairspy import AllPairs
# 파라미터와 값 도메인
parameters = [
("OS", ["Windows", "macOS", "Linux"]),
("Browser", ["Chrome", "Firefox", "Safari"]),
("Locale", ["en_US", "ko_KR"]),
("Auth", ["Password", "SSO"]),
]
# 제약 규칙:
# 1) Safari는 macOS에서만 허용
# 2) Linux에서는 SSO 미지원
def is_valid(row):
# row는 아직 완성되지 않은 부분 조합을 포함할 수 있음
values = dict(row)
os_v = values.get("OS")
br_v = values.get("Browser")
auth_v = values.get("Auth")
if br_v == "Safari" and os_v is not None and os_v != "macOS":
return False
if os_v == "Linux" and auth_v == "SSO":
return False
return True
pairs = AllPairs(
parameters=[vals for _, vals in parameters],
filter_func=lambda row: is_valid(list(zip([k for k, _ in parameters][:len(row)], row))),
)
# 생성 결과 출력
headers = [k for k, _ in parameters]
print(headers)
for i, test in enumerate(pairs, start=1):
print(i, dict(zip(headers, test)))
filter_func는 부분 조합을 만드는 단계에서 제약을 확인한다. 이 예시와 같은 방식은 도메인과 제약에 따라 전체 조합 대비 90% 이상 테스트 수를 줄일 수 있다.
줄어드는 테스트 수와 남는 운영 과제
6개 파라미터가 각각 3값으로 균등할 때 전체 조합은 3^6=729건이다. 같은 조건에서 2-wise는 약 9~13건 수준으로 구성할 수 있으며, 98% 내외의 테스트 수 절감 효과를 기대할 수 있다.
보고 사례 기준으로 현장 결함의 다수는 23개 변수의 상호작용에서 발생한다. 2-wise는 6090%의 결함 포착을 목표로 하며, 핵심 경로에 3-wise를 섞으면 탐지력을 더 높일 수 있다. 회귀 주기와 환경 준비·실행 비용도 줄일 수 있고, 자동화 파이프라인과 연결하면 야간 배치로 조합을 다시 생성하고 실행할 수 있다.
다만 t를 높일수록 테스트 폭발 위험과 실행 시간, 인프라 비용이 증가한다. 제약이 지나치게 많으면 커버리지 구멍이 생길 수 있으므로 규칙이 최소충분한지 검토해야 한다. 생성 알고리즘마다 결과 크기와 생성 시간이 다르므로 도구 선택 과정에서도 평가가 필요하다.
테스트 모델은 요구사항, 파라미터, 제약, 커버리지 목표를 함께 기록하는 저장소로 관리하는 편이 좋다. 결함 원인과 조합을 역추적하는 메트릭을 운영하면 모델을 계속 개선할 수 있다.