페어와이즈 테스팅 기본 개념 정리

 

페어와이즈(pairwise) 테스팅

• all-pairs 테스팅, 2-way 조합 테스팅, 2-wise 테스팅으로도 알려짐
• 대부분의 결함이 많아야 두 개 요소의 상호작용(interaction)에 의해 야기된다는 관찰에 기반하고 있는 테스트 케이스 생성 기법
• 페어와이즈 테스트 스위트는 두 요소(한 쌍)의 모든 조합을 커버하도록 생성되며, 그 수가 완전(exhaustive) 테스트 스위트보다 훨씬 작지만 여전히 결함 발견에 효과적임
• 프로세싱이 패러미터간 상호작용과 관련있을 때 페어와이즈 테스팅이 효과적임
• 페어와이즈 테스팅은 제한받지 않는 옵션(즉, 의존성이 없는 서로 독립적인 옵션들)을 테스팅 하는데 주로 사용되며, 그 대표적인 예가 구성 테스팅(Configuration testing)이다.

 

실증적 토대(Empirical Foundation)

• 페어와이즈 테스팅 효과성/효율성의 전제가 되는 “대부분의 결함이 많아야 두 개 요소의 상호작용에 의해 야기된다”를 뒷받침하는 여러 연구가 존재함
• 한 연구에 따르면 평균적으로 67%의 실패가 단일 패러미터에 의해 야기되며, 93%의 실패가 2-way 패러미터 쌍에 의해 야기되고, 98%의 실패가 3-way 패러미터 조합에 의해 야기된다고 함
• 아래 NIST(미국 연방 표준기술국)의 연구를 보면 두 개 이하 패러미터에 의해 야기되는 결함이 의료 기기 소프트웨어와 NASA 분산 DB 시스템에서는 약 90%이며, 브라우저와 서버 시스템에서는 약 70%를 차지함

[다양한 소프트웨어 시스템에서 1~6개의 패러미터 상호작용에 따른 에러 발견율 – 출처: NIST, PRACTICAL COMBINATORIAL TESTING, 2010]

 

 

페어와이즈 테스트 케이스 생성 예

 

예1) 아래와 같이 X, Y, Z의 세 개 입력 데이터를 받아들이는 시스템 S를 테스트 한다고 했을 때

완전 조합(exhaustive combination)의 경우 2³=8건의 테스트 케이스가 아래와 같이 생성됨

 

 

페어와이즈 테스팅을 적용하면 각 패러미터 쌍(X-Y, Y-Z, X-Z)의 모든 조합만 충족시키면 되므로 아래와 같은 4건의 테스트 케이스로 커버할 수 있음

 

예2) 아래 GUI 화면을 테스트 한다고 했을 때

 

완전 조합 테스트 스위트를 생성하는 경우 총 48개의 테스트 케이스가 나올 수 있음(3 ´ 2 ´ 2 ´ 2 ´ 2 = 48)

 

하지만 페어와이즈 테스팅 기준은 아래와 같이 6건의 테스트 케이스로 충족됨

 

예3) 아래와 같은 안드로이드 구성 옵션을 테스트할 때

 

모든 가능한 조합은 3 x 3 x 4 x 3 x 5 x 4 x 4 x 5 x 4 = 172,800

 

페어와이즈 조합은 31개의 테스트 케이스로 축소됨

 

 

페어와이즈 테스팅 지원 툴

페어와이즈 테스트 케이스를 자동 생성해 주는 여러 무료/유료 툴이 존재함 

• ACTS(Automated Combinatorial Testing for Software): 독립형 Java 애플리케이션, 무료 쉐어웨어(2009년 이전에는 FireEye로 불려짐)
• allpairs: Perl 스크립트 기반 커맨드라인 툴, 무료
• AllPairs: Python으로 작성된 실행 소프트웨어, 무료
• Hexawise: 상용(무료 데모 계정)
• jenny: C로 작성된 커맨드라인 툴, 무료
• pairwise: ruby 기반 오픈 소스
• PICT(Pairwise Independent Combinatorial Testing): 커맨드라인 툴, 무료
• rdExpert: 상용
• SmartTest: 상용
• Testcover: 웹 기반 서비스, 상용

 

위에 나열한 것들 외에도 더 많은 페어와이즈 테스팅 지원 툴을 아래 사이트에서 찾을 수 있음

http://www.pairwise.org/tools.asp

 

 

페어와이즈 테스팅 적용 시 고려사항

• 프로그램 입력은 이벤트 또는 데이터일 수 있다. 페어와이즈 기법은 입력이 (데이터와 이벤트의 혼합이 아니라) 오로지 데이터인 경우에 적절하다. 즉, 페어와이즈 기법의 입력은 이벤트가 아닌 변수의 값이다.
• 프로그램 입력 변수가 독립적인 경우 적절하다.  변수 사이에 의존성( dependencies)이 존재하 유효하지 않은 테스트케이스가 생성될 가능성이 높다. 
• 각 프로그램 입력 변수에 대해 의미 있는 동등 클래스(equivalence classes)를 식별할 수 있는 경우 적절하다.
• 프로그램의 변수가 물리적 양을 나타내는지 논리적 양을 나타내는지 여부를 구별하는 것이 유용하다. 물리적 변수(physical variables)는 일반적으로 속도, 고도, 온도 또는 질량과 같은 어떤 측정 단위와 연관 있다. 논리적 변수(logical variables)는 측정 단위와는 거의 연관되지 않으며 대신 전화 번호 또는 직원 식별 번호 같은 열거된 유형(enumerated type)을 가리킨다. 대개 논리적 변수에 대한 동등 클래스를 식별하는 것이 더 쉽다. 따라서 페어와이즈 기법은 프로그램 입력 변수가 물리적이 아니라 논리적인 경우 적절하다.  
• 프로그램 입력 순서(input order)가 중요하지 않은 경우에 적절하다. 페어와이즈 알고리즘에 제시되는 입력 순서의 변화가 그 결과(알고리즘이 선택한 변수 쌍)에 큰 차이를 만들 수 있다.
• 정적(static) 애플리케이션은 계산이 시작되기 전에 모든 입력이 가용하다. 반면 동적(dynamic) 애플리케이션은 프로그램 경로를 결정하는 모든 입력이 계산 시작 시에 가용하지 않을 수 있다(타임 시퀀스로 발생하는 입력에 반응하는 “reactive” 시스템이라고도 함). 페어와이즈 기법은 입력 순서가 중요하기 때문에 동적 애플리케이션에는 적합하지 않다.
• 애플리케이션이 단일 프로세서에서 실행되는지 아니면 다중 프로세서에서 실행되는지 여부도 고려사항이다. 페어와이즈 기법은 여러 프로세서를 가로지르는 적절한 입력 데이터 쌍을 보장할 수 없다. 멀티프로세싱 애플리케이션에서는 경합 조건(race conditions), 실시간 이벤트 기간, 비동기 입력 순서 등이 일반적인 데, 이러한 요구는 페어와이즈 기법에 의해 충족되지 않을 가능성이 높다. 따라서 다중 프로세서 애플리케이션에서는 적합하지 않다.
• 페어와이즈 알고리즘은 테스트케이스의 입력 부분만 생성하므로 페어와이즈 테스트케이스에 대한 예상 출력(expected outputs)을 결정할 수 있는지 여부도 이 기법을 적용하는 데 있어 고려할 사항이다.

 

 

참고자료

Introduction to pairwise testing by Alexandr Romanov 파워포인트 문서 일부,
A Review of Pair-wise Testing by Jimi Sanchez 리뷰 문서 일부,
Pairwise Testing What it is, When to Use and Not to Use with Philip Lew of XBOSoft 영상의 내용 중에서 일부,
Software Testing A Craftsman’s Approach, Paul C. Jorgensen, Fourth Edition, 2014년, 
20장 A Closer Look at All Pairs Testing, 395~406페이지