[QA] 🧪 결정 테이블 테스트 (+ 예시 문제)

​결정 테이블 테스트

• 입력 조건의 모든 조합에 대한 시스템의 액션을 고려하여 테스트 케이스를 도출
• 복잡한 논리적 관계를 표현하기 좋음. 누락된 요구사항 검사 시 용이
• 장점 : 테스트 베이시스 문제점을 발견할수 있음. TC를 작성하면서 결함 발견.
• 단점 : 작성에 시간이 많이 소요. 복잡한 시스템은 표현하기 어려움

---

결정 테이블 테스트 방법

연습 문제 : 쇼핑몰에서 의류 구매 시 VIP회원이면 10% 할인 해주고, 결제 방법은 신용카드, 무통장 입금을 이용

 

 

1) 조건, 행동 분석

• 조건 : 신용카드, 무통장, VIP
• 행동 : 주문처리/주문거부, 원가/10%할인

 

2) TC작성

• 조건은 왼쪽 위에, 행동은 왼쪽 아래에 위치하는 테이블 만든다
• 조건의 순서에 따라서 액션이 달라지지 않는다. 오로지 조건의 triggerring에 의해서만 액션이 결정된다.
• 액션은 오로지 조건의 조합에만 영향을 받는다. 다른 입력 조건이나, 시스템의 특정 상태 (모드)가 액션을 결정하지 않는다.

 

3) 조건,행동 기입

• 모든 조건의 조합을 모두 나열하고 그에 해당하는 행동을 기입한다.
  • 첫줄 y 개수 : 2^3 / 2
  • 둘째줄 : 첫줄 / 2
  • 셋재쭐 : 줄째줄 / 2

 

 

4) 중복 무의미 값 삭제

• 중복이거나, 발생 불가능한 상황, 모순이 생기는 상황을 찾아 제외시켜 TC를 줄인다.
  1. 신용카드와 무통장 입금은 동시에 존재 X
  2. 신용카드와 무통장 입금이 모두 존재하지 않으면 VIP조건이 뭐든 동일결과가 발생하므로 중복 묶음

 

5) TC 도출

• 실제 테스트할 물건은 이러한 조건들이 꽤 많기 때문에 실수를 줄이기 위해서라도 조건표는 작성하시는 것을 추천합니다.

---

결정 테이블 테스트 실전 문제 1

 

1) 조건, 행동 분석

 

2) TC작성 (조건 행동 기입)

 

3) 중복 무의미 값 삭제

---

결정 테이블 테스트 실전 문제 2

 

 

[시스템 명 ]

: 체크 카드 시스템

​

[요구 사항]

*입력 정보 : 자동 이체 금액, 계좌 유형, 현재 잔고

*출력 정보 : 최종 잔고, 처리 코드

​

[명세 - 처리 코드]

• D&M : (Debit & Message, 인출 처리 및 메세지 발송)
• D : (Debit, 인출 처리)
• S&M : (Suspend account & Message, 계좌 일시중지 및 메세지 발송)
• M : (Message, 메세지 발송)

 

[계좌 유형]

*인터넷 : 'I', Internet

*창구 : 'C', Counter

 

[거리 처리 정보]

*계좌에 잔고가 충분하거나, 인출 요청 금액이(사전 승인된) 대출 한도 이내면 정상적으로 인출 처리

*인출 요청 금액이 (사전 승인된) 대출 한도를 초과할 경우에는 인출이 되지 않으며, 인터넷 계좌라면 계좌 지급 정지 처리

*인터넷 계좌는 모든 거래에 대해 메세지 발송

*창구 계좌는 잔고가 부족한 경우에만 메세지 발송

 

유사코드 >>>

if 잔고 >= 인출액 || (잔고 < 인출액 && 대출한도 >= abs(잔고 - 인출액)) 
	if 인터넷 계좌 
    	D&M 
    else #창구계좌 
    	if 잔고 < 인출액 
        	D&M 
        else 
        	D 
        endif 
    endif 
else 
	if 인터넷 계좌 
    	S&M 
    else #창구계좌 
    	M 
    endif 
endif

조건 : 인터넷계좌, 잔고 초과, 대출한도 초과
제한: 잔고초과 N일 때 대출한도초과 판별불가능.
액션 : D,D&M,S&M,M
팁&

 

결과 :

조건	인터넷 계좌	Y	Y		Y	N	N		N
	잔고 초과	Y	Y		N	Y	Y		N
	대출한도 초과	Y	N			Y	N
결과	D&M 인출메세지		o		o		o
	D 인출								o
	S&M 계좌정지	o
	M 메세지출력					o

---

결정 테이블 테스트 TIP

• 결정 테이블의 크기(가능한 조합 또는 규칙의 수) = 2^n(식별된 컨디션 수)
• 테스트 컨디션과 테스트 케이스 수는 비례하므로 리스크의 기반한 샘플링이 필요할 수 있음
• 중요한 코어 시스템에 적용, 전체 시스템에 하기에는 너무 많은 경우의 수가 도출 될 수 있음
• 결정 테이블은 "축소(Collapsed)" 될 수 있음
  • "흥미로운" 테스트만 실행하기 위해 지능적으로 테스트 케이스의 수를 감소 시킬 수 있음
  • 결정 테이블을 축소하는 것은 올바르게 구현되었다는 것을 전제하는 것으로 위험할 수 있음!!!
  • 리스크가 낮은 경우에만 테이블을 축소해야 함
• 대부분 조건을 12~13을 MAX로 잡는다
  • 만약 13을 넘으면 해당 시스템을 쪼갠다 (이 부분은 조직에 따라 달라 질 수 있음)
• 때때로 원인-결과 그래프를 추가로 적용할 수 있음
  • 논리적인 표기법을 사용하여 동일한 규칙을 설명하는 그래픽 기법
• 명세의 차이와 실수 발견에 효과적
  • 입력 조합의 복잡한 로직 처리 실수
  • 잘못된 액션의 원인, 올바른 액션 누락, 입력 컨디션(원인)의 누락, 출력 액션(효과)의 누락
• 명세서의 품질이 낮다면 모든 조건(Conditions)과 정확한 처리(Actions)를 찾기 어려울 수 있음. 때문에 결정테이블 테스팅을 명세서를 테스트하는데 주로 적용됨
• 통합, 시스템 그리고 인수 테스트에 주로 적용되며, 비지니스 규칙 테스트에 특히 유용