결정테이블 테스팅(Cause-Effect Graph, Decision Table Testing)

---

정의 및 원리

"조건(Conditions)"과 "처리(Actions)"를 논리적 관계로 표현할 수 있는 모델에 적용
"조건"은 원인에 해당되며 "참", "거짓" 등과 같이 Boolean 연산으로 표현
"처리"는 결과에 해당되며 "참", "거짓" 등과 같이 Boolean 연산으로 표현
Boolean 연산 : ADN, OR NAND, NOR, NOT

 

---

 

예제를 통해 알아보겠습니다.

 

• 시스템 명 : 체크 카드 시스템
• 요구 사항
  • 입력 정보 : 자동 이체 금액, 계좌 유형, 현재 잔고
  • 출력 정보 : 최종 잔고, 처리 코드
• 명세
  • 처리 코드
    • D&M : (Debit & Message, 인출 처리 및 메세지 발송)
    • D : (Debit, 인출 처리)
    • S&M : (Suspend account & Message, 계좌 일시 중지 및 메세지 발송)
    • M : (Message, 메세지 발송)
  • 계좌 유형
    • 인터넷 : 'I', Internet
    • 창구 : 'C', Counter
  • 거리 처리 정보
    • 계좌에 잔고가 충분하거나, 인출 요청 금액이(사전 승인된) 대출 한도 이내면 정상적으로 인출 처리
    • 인출 요청 금액이 (사전 승인된) 대출 한도를 초과할 경우에는 인출이 되지 않으며, 인터넷 계좌라면 계좌 지급 정지 처리
    • 인터넷 계좌는 모든 거래에 대해 메세지 발송
    • 창구 계좌는 잔고가 부족한 경우에만 메세지 발송

 

---

 

절차

 

• TD1 : 기능 셋 식별
  • 체크 카드 시스템

 

• TD2 : 테스트 컨디션 도출
  • 조건(Conditions)
    • TCON1 : C1 인출 금액이 잔고보다 적음 
    • TCON2 : C2 잔고 부족, 대출 한도 내 인출
    • TCON3 : C3 인터넷 계좌 
  • 처리(Actions)
    • TCON4 : A1 정상 인출 처리 
    • TCON5 : A2 계좌 지급 정지
    • TCON6 : A3 메시지 발송 
  • 필자는 테스트 컨디션 도출 시 처리(Action) 먼저 도출 후 그에 대한 조건을 도출하는게 훨씬 더 수월했다

 

• TD3 : 테스트 커버리지 아이템 도출
  • 결정 테이블로 변환하여 테스트 커버리지 아이템을 식별함
  • 결정 테이블 상단은 "조건"의 모든 조합임
    • 조건에 대한 모든 조합이므로 아래는 조건이 3개이므로 2^3= 8가지 경우의 수
  • 결정 테이블 하단은 "조건"의 대한 "처리"를 표현
  • 칼럼이 룰(Rule), 룰이 테스트 커버리지 아이템!
    • 결과는 수동으로 하나하나 따져 가면서 기입 해야 된다.
      • 조건의 수를 반을 나눠서 T/F 기입, 다음 행도 같은 방법으로 기입하면 모든 조건의 조합을 나열 할 수 있다.
      • 실행 불가능한 "조건"의 조합, "결과" 없음

 

•  
• TD4 : 테스트 케이스 도출

테스트 케이스	원인				결과		테스트 커버리지 아이템(룰)
	계좌 유형	대출 한도	현재 잔고	인출 금액	최종 잔고	처리 결과 코드
1	C	100,000	-70,000	150,000	-70,000	M	1
2	I	1,500,000	420,000	2,000,000	420,000	S&M	2
3	C	1,250,000	650,000	800,000	-150,000	D&M	3
4	I	750,000	-500,000	200,000	-700,000	D&M	4
5	C	1,000,000	2,100,000	1,200,000	900,000	D	5
6	I	500,000	250,000	150,000	100,000	D&M	6
7							수행하지 않음
8							수행하지 않음

• TD5 : 테스트 셋 구성
  • TS : Test Case 1, 2, 3, 4, 5, 6

 

• TD6 : 테스트 프로시저 도출
  • TP : TS 과 동일

 

커버리지 = (커버 된 룰 수 / 전체 룰 수) * 100%

 

---

 

결정 테이블의 크기(가능한 조합 또는 규칙의 수)  = 2^n(식별된 컨디션 수)

테스트 컨디션과 테스트 케이스 수는 비례하므로 리스크의 기반한 샘플링이 필요할 수 있음
중요한 코어 시스템에 적용, 전체 시스템에 하기에는 너무 많은 경우의 수가 도출 될 수 있음

결정 테이블은 "축소(Collapsed)" 될 수 있음

"흥미로운" 테스트만 실행하기 위해 지능적으로 테스트 케이스의 수를 감소 시킬 수 있음
결정 테이블을 축소하는 것은 올바르게 구현되었다는 것을 전제하는 것으로 위험할 수 있음!!!
리스크가 낮은 경우에만 테이블을 축소해야 함

 

대부분 조건을 12~13을 MAX로 잡는다

만약 13을 넘으면 해당 시스템을 쪼갠다

(이 부분은 조직에 따라 달라 질 수 있음)

때때로 원인-결과 그래프를 추가로 적용할 수 있음

논리적인 표기법을 사용하여 동일한 규칙을 설명하는 그래픽 기법

명세의 차이와 실수 발견에 효과적

입력 조합의 복잡한 로직 처리 실수
잘못된 액션의 원인, 올바른 액션 누락, 입력 컨디션(원인)의 누락, 출력 액션(효과)의 누락

 

명세서의 품질이 낮다면 모든 조건(Conditions)과 정확한 처리(Actions)를 찾기 어려울 수 있음

때문에 결정테이블 테스팅을 명세서를 테스트하는데 주로 적용됨

 

통합, 시스템 그리고 인수 테스트에 주로 적용되며, 비지니스 규칙 테스트에 특히 유용

 

---