4.3. Basis Specification, Black Box

Equivalence Partitioning (동등분할테스트)

S/W나 시스템의 엽력값은 입력의 결과로 나타날 결과 값이 동일한 경우 하나의 class로 묶어 사용함. 이러한 class 내의 입력값은 내부적으로 같은 방식으로 처리된다고 가정함.

해당 클래스는  유효한 입력 데이터 (Allow data, incorrect data, denied data)의 모두를 가질수 있음.

테스트는 모든 레벨에 적용이 가능 하며, 특정 커버리지를 달성하기 위해서도 사용할 수 있음.
강한 동등 분할 테스트의 경우에는 모든 경우의 수를 고려하여 테스트를 진행 함
약한 동등 분할 테스트의 경우에는 대표할 수 있는 (범위안에 포함이 되는) 하나 이상의 특정 데이터를 포함 하여 테스트를 진행 함

예) 리X지2 레볼X션에서 엘프 종족, 1차 전직 (Lv.30 > 에쁜이), 2차 전직 (Lv.150 > 존예), 3차 전직 (Lv.250 > 쯔위 >_<)

## 레벨별 카테고리로 분류
전직 하기전: 1<= 현렙 <30
1차 전직: 30 <= 현렙 <150
2차 전직: 150 <= 현랩 <250
3차 전직: 250 <= 현렙 <320

## 카테고리 별 대표값 선택 후 TC
Lv.15: 전직 퀘를 받으면 안된다.
Lv.35: 1차 전직 퀘를 받을 수 있어야 한다. (만일 전직을 안했다면)
Lv.200: 2차 전직 퀘를 받을 수 있어야 한다. (만일 전직을 안했다면)
Lv.280: 3차 전직 퀘를 받을 수 있어야 한다. (만일 전직을 안했다면)

만일 이중에서 퀘스트 뿐만 아니라 특정 이벤트 (Lv 별로 반드시 거쳐야 하는) 조합을 적용 하여 테스트케이스를 작성 하려 하면 다음의 경우를 고민 하면 됨
약한 동등 분할 테스트 기법
@> 각 레벨별 특정 이벤트를 1:1 매칭하여 작성
강한 동등 분할 테스트 기법
@> 모든 레벨에서 특정 이벤트를 n:1 매칭하여 작성 (이러면 TC 가 조오오옹나 많아지는 상황...)

Boundary Value Analysis (경계값 분석 테스트)

경험적으로 동등 분할의 경계 부근에서 입력되는 값들에서 결함이 발견되는 확률이 경험적으로 높기 때문에 해당 결함의 발지를 위해서 경계값까지 포함 하는 테스트 기법.
해당 분할 영역의 최소/최대 값을 그 영역의 경계값이 됨. (유효범위 내에 들어가는 것은 "유효경계값", 유효범위 밖의 값들은 "비유효경계값". << 이것들이 모두 포함 되어야 함.

경계값 분석은 모든 테스트 레벨에서 사용 가능 함.

예) 솔까 쉬워서 Pass...

Decision Table Test (결정 테이블 테스트)

논리적인 조건이나 상황을 구현하는 시스템 요구사항을 도출 하거나 내부시스템 디자인을 문서화 하는데 편한 방법임.

결정테이블을 작성 할 때 명세서를 분석하고, 컨디션과 시스템의 조건을 식별함. 입력조건과 동작은 주로 "true", "false" 로 표현함.
동작을 유발시키는 조건 이나 상황 (or trigger), 그리고 예상 결과 까지 포함 함. 테이블의 각 컬럼은 비즈니스 규칙과 대응관계를 가지게 되고, 이것은 유일한 조건의 조합을 정의 하고 이 조합을 통해 비즈니스 규칙과 연관된 동작을 수행 하게 됨.

실무에서 사용 하는 경우 일반적인 커버리지는 각 테이블 컬럼당 적어도 하나의 TC를 생성 해야 함. 이렇게 되는 일반적으로 가능한 모든 동작을 유발시키는 조건의 조합을 커버함.

예) mWallet true&false TC

mWallet case	Test Case ID
	1	2	3	4
Test Condition
Install the mwallet apk	False	True	True	True
Eligible between SIM and mwallet apps		False	True	True
Expectation Result
Need to SIM	True
Expired the SIM		True

ID	Category	Pre-condition	Procedure	Expectation Result	Actual Result	Tractability	Priority	Notes
TC-01	Eligible	휴대폰에 금융용 유심이 없다.	Start the twallet	유효성 확인 후 "insert usim" 메시지가 나와야 함		ref. for BRD	major	유심관련 eligible check
TC-02	Eligible	휴대폰에 금융용 유심이 있다.	Start the twallet	유효성 확인 후 "incorrect usim" 메시지가 나와야 함		ref.for BRD	major	유심관련 eligible check

State Transition Test (상태 전이 테스트)

시스템이 현재 상황과 이전의 이력의 상태에서 변화에 대한 추이를 살펴 보면서 이러한 부분을 상태전이 다이어그램으로 표현, 변화 되는 부분을 파악함.
만들어진 다이어그램을 테이블로 전환 하면서 상태과 이벤트와의 관계를 확인, 개연성 추적, 요구사항과 다른 전이 상태등을 확인 할 수 있음.

일반적으로 임베디드 시스템에서 많이 사용됨

예) 음료자판기의 상태 전이 (Suresoft 블로그 참고)

상태A: 대기
이벤트1: 금액투입 [투입금액 >= 가격]  --->> 음료선택 상태 C
이벤트2: 금액투입 [투입금액 < 가격] --->> 금액투입 상태 B

상태B: 금액투입
이벤트1: 금액투입 [투입금액 >= 가격] ---> 음료선택 상태 C
이벤트2: 금액투입 [투입금액 < 가격] --->> 금액 투입 상태 B (더넣어요~)
이벤트3: 취소 [투입금액반환] --->> 대기 상태 A

상태C: 음료선택
이벤트4: 음료버튼선택 [캔방출,잔액반환,잔량수정] --->> 대기 상태 A
이벤트5: 취소선택 [투입금액반환, 라이트리셋] --->> 대기 상태 A

Use Case Test (유즈케이스 테스트)

Use case는 일반적으로 Actor와 Actor 사이의 상호관계를 표현하고 해당 작용을 통해서 고객에게 결과 값을 알려줌. Use case는 원칙적인 레벨(비즈니스나, 비 기술적 레벨)이나 시스템 레벨등에서 구현이 가능함.

일반적으로 전제 조건과 후속 조건, 그리고 결과등 전체 시나리오가 Use case 안에 녹아 들어가게 되고 주로 실 사용에 적용되는 '프로세스의 흐흠'을 설명함 이는 이후 UAT (User Acceptance Test) 나 BRT (Business Randiness Test) 를 진행 할때 유용함.

예) 대부분의 Test case는 Use case 를 바탕으로 만들어 진다고 할 정도로 일반적으로 사업자 요구 사항과 함께 TC 설계의 중용한 basis 가 됨