'SW_이론'에 해당되는 글 7건

정의 및 원리

테스트 아이템의 실행 절차를 표현한 업무 흐름도 등의 모델 사용
정상(기본) 흐름과 비정상(대체) 흐름 테스트

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

• 시스템 명 : 현금 인출 기능
• 요구 사항
  • ATM(자동 현금 지급기)를 통해 현금 인출 기능
  • 현금 인출 조건 : 정상 계좌, 정상 카드, 정상 비밀번호, 정상 동작 ATM
  • 정상 인출 처리 : 거래 금액은 계좌에서 차감 되고, 거래 명세서 출력, ATM 화면 초기화(다음 거래자를 위한 준비)
• 기본 시나리오
  • 계좌에서 정상적으로 현금을 인출함
• 대체 시나리오
  • ATM 은행 카드 인식 불가
  • 사용자가 비밀번호를 3회 이상 틀리게 입력
  • ATM의 보유 현금이 인출 금액 보다 적음
  • 사용자 계좌 잔고가 인출 금액 보다 적음
  • 사용자 출금 단위가 아닌 금액 입력

절차

• TD1 : 기능 셋 식별
  • 현금 인출 기능
  • 흐름 - 이벤트 다이어그램

• 각 구성 항목 식별
  • U1 (사용자) 카드 삽입
  • S1.1 (ATM) 카드 정상 인식
  • S1.2 (ATM) 카드 인식 불가 
  • U2 (사용자) 비밀번호 입력 
  • S2.1 (ATM) 비밀번호 정상 
  • S2.2 (ATM) 비밀번호 비정상(<3회) 
  • S2.3 (ATM) 비밀번호 비정상(=3회) 
  • S3 (ATM) 카드 회수 
  • U3.1 (사용자) 인출 선택
  • U3.2 (사용자) 입금 또는 이체 선택
  • S10 (ATM) 입금 또는 이체 화면으로 이동
  • U4 (사용자) 계좌 선택
  • S4.1 (ATM) 정상 계좌 확인
  • S4.3 (ATM) 비정상 계좌
  • U5 (사용자) 인출 금액 입력
  • S5.1 (ATM) 인출 가능 금액
  • S5.2 (ATM) 비유효 인출 금액(인출 단위 외 금액)
  • S5.3 (ATM) 보유 현금 부족
  • S5.4 (ATM) 인출 불가 금액(고가 지폐만 있음)
  • S5.5 (ATM) 일일 인출 금액 초과
  • S5.6 (ATM) 계좌잔고 초과 금액
  • S6 (ATM) 현금 지급
  • S7 (ATM) 계좌 잔고 업데이트
  • S8 (ATM) 거래명세서 출력
  • S9 (ATM) 카드 반환
  • U6 (사용자) 카드 제거

• TD2 : 테스트 컨디션 도출
  • TCOND1 : 정상 출금 시나리오 ( U1, S1.1, U2, S2.1, U3.1, U4, S4.1, U5, S5.1, S6, S7, S8, S9, U6 )
  • TCOND2 : 사용자 카드를 ATM이 인식하지 못하는 시나리오 ( U1, S1.1, S9 )
  • TCOND3 : 사용자가 비밀번호를 잘못 입력한 시나리오 (<3회) ( U1, S1.1, U2, S2.2 )
  • TCOND4 : 사용자가 입력한 인출금액이 ATM 보유 현금보다 많은 시나리오 ( U1, S1.1, U2, S2.1, U3.1, U4, S4.1, U5, S5.3 )
  • TCOND5 : 사용자가 입력한 인출금액이 계좌 잔고보다 많은 시나리오 ( U1, S1.1, U2, S2.1, U3.1, U4, S4.1, U5, S5.6 )
  • TCOND6 : 사용자가 입력한 인출금액이 ATM 출금 단위가 아닌 시나리오 ( U1, S1.1, U2, S2.1, U3.1, U4, S4.1, U5, S5.2 )
  • TCOND7 : 사용자가 비밀번호를 잘못 입력한 시나리오(=3회) ( U1, S1.1, U2, S2.2, U2, S2.2, U2, S2.3, S3 )
  • TCOND8 : 사용자가 입력한 인출금액이 인출 불가능한 시나리오( 5만원권 지폐만 있는데, 2만원 인출할 경우) ( U1, S1.1, U2, S2.1, U3.1, U4, S4.1, U5, S5.4 )
  • TCOND9 : 사용자가 입력한 인출금액이 일일 인출 상한 액을 초과한 시나리오 ( U1, S1.1, U2, S2.1, U3.1, U4, S4.1, U5, S5.5 )
  • TCOND10 : 사용자가 입금 또는 이체 기능을 선택한 시나리오 ( U1, S1.1, U2, S2.1, U3.2, S10 )
  • TCOND11 : 사용자가 거래가 불가한 비정상 계좌를 선택한 시나리오 ( U1, S1.1, U2, S2.1, U3.1, U4, S4.2 )

• TD3 : 테스트 커버리지 아이템 도출
  
  • TCOVER1 : 정상 출금 시나리오 ( TCOND1 )
  • TCOVER2 : 사용자 카드를 ATM이 인식하지 못하는 시나리오 ( TCOND2 )
  • TCOVER3 : 사용자가 비밀번호를 잘못 입력한 시나리오 (<3회) ( TCOND3 )
  • TCOVER4 : 사용자가 입력한 인출금액이 ATM 보휴 현금보다 많은 시나리오 ( TCOND4 )
  • TCOVER5 : 사용자가 입력한 인출금액이 계좌 잔고보다 많은 시나리오 ( TCOND5 )
  • TCOVER6 : 사용자가 입력한 인출금액이 ATM 출금 단위가 아닌 시나리오 ( TCOND6 )
  • TCOVER7 : 사용자가 비밀번호를 잘못 입력한 시나리오 (=3회) ( TCOND7 )
  • TCOVER8 : 사용자가 입력한 인출금액이 인출 불가능한 시나리오(5만원권 지폐만 있는데, 2만원 인출할 경우) ( TCOND8 )
  • TCOVER9 : 사용자가 입력한 인출금액이 일일 인출 상한 액을 초과한 시나리오 ( TCOND9 )
  • TCOVER10 : 사용자가 입금 또는 이체 기능을 선택한 시나리오 ( TCOND10 )
  • TCOVER11 : 사용자가 거래가 불가한 비정상 계좌를 선택한 시나리오 ( TCOND11 )

• TD4 : 테스트 케이스 도출

• TD5 : 테스트 셋 구성
  • TS1 : 기본 흐름 테스트 : Test Case 1
  • TS2 : 대체 흐름 테스트 : Test case 2, 3, 4, 5, 6 ,7 8, 9, 10, 11

• TD6 : 테스트 프로시저 도출
  • TP1 : 기본 흐름 테스트 : TS1 과 동일
  • TP2 : 기본 흐름 테스트 : TS2 과 동일

커버리지 = (커버된 시나리오 수 / 전체 시나리오 수) * 100%

시나리오 테스팅은 모든 테스트 레벨에 적용 가능

주로 인수 테스팅과 시스템 테스팅에 적용

시나리오 테스팅은 다른 기법과 병행하여 적용 가능

[실무]기본 흐름을 잡고 대체 흐름은 경험에 기반하여 작성

일반적인 결함

프로세스와 시스템 간의 통합 문제
서로 다른 액터의 사용성 이슈
요구 사항 불일치와 결함
통합 및 상호 운용성 결함

정의 및 원리

"조건(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 : 테스트 케이스 도출

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

정의 및 원리

테스트 아이템의 상태 모델 사용
상태 간의 전이, 이벤트 등을 테스트
유효(Valid) 테스트 케이스, 비 유효(Invalid)테스트 케이스

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

• 시스템 명 : 시각/날짜 설정 가능
• 요구 사항
  • 상태 전이 다이어그램

절차

• TD1: 기능 셋 식별
  • 시각/날짜 설정 기능

• TD2: Valid 테스트 컨디션 도출
  • 상태전이 다이어그램의 전이(Transition)을 테스트 컨디션으로 식별함 
    • TCOND1 : S1 to S2
    • TCOND2 : S1 to S3
    • TCOND3 : S3 to S1 
    • TCOND4 : S2 to S1
    • TCOND5 : S2 to S4
    • TCOND6 : S4 to S2 
  • 상태-이벤트 테이블 작성

• TD2: Invalid 테스트 컨디션 도출
  • 상태-이벤트 테이블에서 Invalid 케이스를 테스트 컨디션으로 식별함
    • TCOND7 : S3 to S3 CM 
    • TCOND8 : S4 to S4 CM
    • TCOND9 : S3 to S3 R
    • TCOND10 : S4 to S4 R 
    • TCOND11 : S1 to S1 TS
    • TCOND12 : S2 to S2 TS 
    • TCOND13 : S4 to S4 TS
    • TCOND14 : S1 to S1 DS
    • TCOND15 : S2 to S2 DS
    • TCOND16 : S3 to S3 DS 

• TD3: 테스트 커버리지 아이템 도출(테스트 컨디션과 테스트 커버리지 아이템이 동일함)
  • 테스트 컨디션과 테스트 커버리지 아이템이 동일함
  • 0-swich
    • 유효한(Valid) 테스트 커버리지 아이템 도출 
      • TCOVER1 : S1 to S2 , 날짜표시 D 
      • TCOVER2 : S1 to S3 , 시간변경 AT
      • TCOVER3 : S3 to S1 , 시간표시 T
      • TCOVER4 : S2 to S1 , 시간표시 T
      • TCOVER5 : S2 to S4 , 날짜변경 AD
      • TCOVER6 : S4 to S2 , 날짜표시 D
      • TCOVER7 : S3 to S3 , 모드변경 CM 
    • 비 유효한(Invalid) 테스트 커버리지 아이템 도출
      • TCOVER8 : S4 to S4 , 모드변경 CM 
      • TCOVER9 : S3 to S3 , 초기화 R
      • TCOVER10 : S4 to S4 , 초기화 R
      • TCOVER11 : S1 to S1 , 시간설정 TS
      • TCOVER12 : S2 to S2 , 시간설정 TS
      • TCOVER13 : S4 to S4 , 시간설정 TS
      • TCOVER14 : S1 to S1 , 날짜설정 DS
      • TCOVER15 : S2 to S2 , 날짜설정 DS
      • TCOVER16 : S3 to S3 , 날짜설정 DS 

• TD4 : 테스트 케이스 도출
  • Valid 테스트 커버리지 아이템을 모두 커버 하기 위한 테스트 케이스

• Invalid 테스트 커버리지 아이템을 모두 커버 하기 위한 테스트 케이스

• TD5: 테스트 셋 구성(목적에 따라 구분)
  • TS1 : Valid 전이 테스트 - Test Case 1, 2, 3, 4, 5, 6
  • TS2 : Invalid 전이 테스트 - Test Case 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 

• TD6 : 테스트 프로시저 도출
  • TP1 : Valid 전이 테스트 - TS1과 동일
  • TP2 : Invalid 전이 테스트 - TS2와 동일

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

상태 전이 커버리지(Chow's)

Chow의 커버리지 = 중간 상태의 수

0-스위치
중간 상태 없이 한 상태에서 다른 상태로 전이

1-스위치
하나의 중간 상태를 거처 한 상태에서 다른 상태로 전이
ex) S3 to S1 to S2

N-스위치
N개의 중간 상태를 거처 한 상태에서 다른 상태로 전이

[일반적인 결함 ]

잘못 정의된 상태
정의된 상태/컨디션 간의 유효하지 않은 전이
정의된 전이에 대한 유효하지 않은 액션
Dead Status / Black Holes
유효하지 않은 상태(도달 불가능한)

성공적인 상태 전이 테스팅의 실행은 상태 다이어그램 작성 시 시스템의 상태를 성공적으로 식별하는 것에 의존함

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

그 중 몇 가지만 소개합니다.

1. PICT

Microsoft 제공(현재는 오픈소스)

테스트 버전 : 3.3

사용방법

설치 후
실행을 테스트 데이터가 있는 폴더로 하는게 정신 건강에 좋음

실행 및 옵션

Usage: pict model [options]
Options:
 /o:N    - Order of combinations (default: 2)
 /d:C    - Separator for values  (default: ,)
 /a:C    - Separator for aliases (default: |)
 /n:C    - Negative value prefix (default: ~)
 /e:file - File with seeding rows
 /r[:N]  - Randomize generation, N - seed
 /c      - Case-sensitive model evaluation
 /s      - Show model statistics

한글 이슈
파일명이 한글이면 읽을 수 없음

2. ACTS

테스트 버전 : 3.0

NIST에서 제공
가장 압축률이 좋음
가장 효율적인 테스트 세트 생성(효과적X)
대부분의 도구는 최소한의 테스트 세트 생성에 완벽하지 않음
해당 PC에 Java 설치가 되어 있어야함

사용방법
Java -jar 파일명

아래 Create a New System 버튼 누른다

기본적으로 한글은 지원하지 않음
파라미터 이름만 한글로 넣으면 안됨

파라미터를 입력 하고 "Add To Table" 버튼을 눌러 "Saved Parameters" 리스트에 등록 시킨 후 "Modify System" 버튼을 눌러 최종 등록!

상단 "Build Current System" 버튼을 눌러 옵션을 선택 후 "Build" 버튼 클릭

조합 결과 화면

자세한 설명은 홈페이지에서 확인

https://csrc.nist.gov/projects/automated-combinatorial-testing-for-software

정의 및 원리

입력 값을 조합해 테스트 케이스 작성
다른 기법을 이용해 테스트 데이터(입력 값)을 선정한 후 활용 가능(예, 동등 분할, 경계 값 분석)

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

• 시스템 명 : 항공 여행 안내 시스템
• 요구 사항
  • 목적지 = 파리, 런던, 시드니
  • 좌석 등급 = 퍼스트 클래스, 비지니스 클래스, 이코노미 클래스
  • 좌석 위치 = 통로, 창가 

절차

• TD1 : 기능 셋 식별
  • 항공 여행 안내 시스템

• TD2 : 테스트 컨디션 도출
  • TCOND1 : 목적지 - 파리
  • TCOND2 : 목적지 - 런던
  • TCOND3 : 목적지 - 시드니
  • TCOND4 : 좌석등급 - 퍼스트 클래스
  • TCOND5 : 좌석등급 - 비즈니스 클래스
  • TCOND6 : 좌석등급 - 이코노미 클래스
  • TCOND7 : 좌석위치 - 통로
  • TCOND8 : 좌석위치 - 창가  

•  TD3 : 테스트 커버리지 아이템 도출(All Combination)
  • All Combinations Testing
    • 입력 값의 모든 조합을 모두 테스트

•  TD4 : 테스트 케이스 도출(All Combination)
  • 모든 테스트 커버리지 아이템을 포함하도록 테스트 케이스 생성
  • 커버리지 아이템 = 테스트 케이스

• TD5 : 테스트 셋 구성(All Combination)
  • 목적에 따라 구분 
    • TS1 : 통로 쪽 좌석 테스트 - 1, 3, 5, 7, 9, 11, 13, 15, 17
    • TS2 : 창자 쪽 좌석 테스트 - 2, 4, 6, 8, 10, 12, 14, 16, 18

• TD6 : 테스트 프로시저 도출(All Combination)
  • TP1 : 통로 쪽 좌석 테스트 - TS1과 동일
  • TP2 : 통로 쪽 좌석 테스트 - TS2과 동일

커버리지 = (커버된 입력 값 조합 수 / 전체 입력 값 조합 수) * 100%

• TD3 : 테스트 커버리지 아이템 도출(Pairwise)
  • Pairwise Testing
    • 두 입력 값의 유일한 조합이 테스트 커버리지 아이템

• TD4 : 테스트 케이스 도출(Pairwise)
  • 모든 테스트 커버리지 아이템을 포함하도록 테스트 케이스 생성

• TD5 : 테스트 셋 구성(Pairwise)
  • TS : 1, 2, 3, 4, 5, 6, 7, 8, 9

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

커버리지 = (커버 된 입력 쌍 조합 수 / 전체 입력 쌍 조합 수) * 100%

• TD3 : 테스트 커버리지 아이템 도출(Each Choice)
  • Each Choice Testing
    • 입력 값을 최소 한번 이상 테스트

• TD4 : 테스트 케이스 도출(Each Choice)
  • 모든 테스트 커버리지 아이템을 포함하도록 테스트 케이스 생성

• TD5 : 테스트 셋 구성(Each Choice)
  • TS : Test Case 1, 2, 3

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

커버리지 = (커버 된 입력 값 수 / 전체 입력 값 수) * 100%

• TD3 : 테스트 커버리지 아이템 도출(Base Choice) 
  • Base Choice Testing (빈도수가 가장 높거나 초기 값으로 정의된 입력 조합)
    • 기본 입력 값으로만 테스트

• TD4 : 테스트 케이스 도출(Base Choice)
  • 모든 테스트 커버리지 아이템을 포함하도록 테스트 케이스 생성

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

• TD6 : 테스트 프로시저 도출(Base Choice)
  • TP : TS와 동일

커버리지 = (커버 된 기본 입력 값 수 / 전체 기본 입력 값 수) * 100%

[조합 테스팅 적용 ]

기능 테스팅 : 옵션의 조합을 선택할 수 있는 메뉴 기반의 어플리케이션 테스트

구성 테스팅 : 서로 다른 하드웨어 및 소프트웨어 구성

호환성 테스팅 : 모든 어플리케이션의 조합이 아닌 공존할 수 있는 어플리케이션의 조합 확인

설치성 테스팅  :설치 옵션 조합 확인

정의 및 원리

테스트 아이템의 입력 또는 출력이 여러 영역으로 구분되는 경우에 적용
입력 또는 출력 조건의 경계를 기준으로 데이터를 선택해 테스트하는 기법

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

• 시스템명 : 교과목 학점 평가 시스템
• 요구사항
  • 시험점수(75%) + 과제점수(25%) = 총점 = 학점 계산(A, B, C, D)
  • 점수(시험, 과제) 별 범위를 벗어나는 점수를 입력하면 "경고 메세지" 출력
  • "정수"만 모든 입력 가능

절차

• TD1 : 기능 셋 식별
  • 교과목 학점 평가 시스템

• TD2 : 테스트 컨디션 도출(파티션 식별)
  • 유효한 입력 파티션(Input Valid Partition)
    • EP1 : 0 <= 시험 점수 <=75
    • EP1 : 0 <= 시험 점수 <= 75
    • EP2 : 0 <= 과제 점수 <= 25
  • 비 유효한 입력 파티션(Input Invalid Partition)
    • EP3 :   시험 점수 > 75
    • EP4 :   시험 점수 < 0 
    • EP5 :   과제 점수 > 25
    • EP6 :   과제 점수 < 0
    • EP3 : 75 < 시험 점수 <= 32767(16bit)
    • EP4 : -32768 <= 시험 점수 < 0
    • EP5 : 25 < 과제 점수 <= 32767
    • EP6 : -32768 <= 과제 점수 < 0
    • EP7 : 시험 점수 = 실수 값(소수점 포함)
    • EP8 : 시험 점수 = 영문자
    • EP9 : 시험 점수 = 특수 문자
    • EP10 : 과제 점수 = 실수 값(소수점 포함)
    • EP11 : 과제 점수 = 영문자
    • EP12 : 과제 점수 = 특수 문자
  • 유효한 입력 파티션(Input Valid Partition) 
    • EP13 : 70 <= 총 점 <= 100, 'A'
    • EP14 : 50 <= 총 점 < 70, 'B'
    • EP15 : 30 <= 총 점 < 50, 'C'
    • EP16 : 0 <= 총 점 < 30, 'D'
    • EP17 : 총 점 > 100, '경고 메시지' 출력
    • EP18 : 총 점 < 0, '경고 메시지' 출력
    • EP17 : 100 < 총 점 <= 32767, '경고 메세지' 출력
    • EP18 : -32768 <= 총 점 < 0, '경고 메세지' 출력

• TD2 : 테스트 컨디션 도출
• TD3 : 테스트 커버리지 아이템 도출

• TD4 : 테스트 케이스 도출

•  TD5 : 테스트 셋 구성
  • TS1 : 수작업 테스트("경고 메세지"가 출력 되는 케이스는 수작업 테스트)
    • 1, 2, 3, 4, 5, 6, 7, 12, 13, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50
  • TS2 : 자동 테스트
    • 2, 3, 4, 5, 8, 9, 10, 11, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29

• TD6 : 테스트 프로시저 도출
  • TP1 : 수작업 테스트 - TS1과 동일
  • TP2 : 자동 테스트 - TS2와 동일

커버리지 = (커버 된 경계 값 수 / 전체 경계 값 수) * 100%

2-Value(테스트 커버리지 아이템)

경계는 파티션의 최대 및 최소 값으로 설정
비 유효한 파티션의 "다른 경계값' 또는 '끝 값'을 종종 고려하지 못할 수 있음

3-Value(테스트 커버리지 아이템)

경계값은 파티션을 고려해야 함
정확한 경계값은 명세에 따라 달라짐
잘못 설정된 경계값을 발견하기 위하여 경계의 양 쪽 값을 모두 선택

[기술적 관점]

시험 점수와 과제 점수는 정수
정수의 경계값을 고려해야 함(비트에 따라)
정수라면 일반적으로 MinInt +-X와 MaxInt +-X 로 테스트 설계

경계값은 선언된 변수의 유형을 고려
X 값은 선언된 변수 유형의 가장 작은 수를 사용

UI 또는 하드웨어 입력 장치 고려

입력 필드와 같은 UI에 따라 입력 가능한 경계 값을 고려해야 함
소프트웨어가 경계값에 따라 가능한 대처 방법도 고려해야 함

경계를 잘못 구현한 결함 발견에 유용
예를 들어, 시험 점수가 65점을 이상을 65점 초과로 구현

일반적인 실수는 명세를 잘못 이해하거나 연산자를 잘못 사용하는 경우임

경계값 분석은 결함 발견에 가장 효과적인 기법으로 널리 사용됨

모든 테스트 레벨에 적용 가능

경계값 분석은 일반적으로 동등 분할을 표현
하지만 특정한 클래스는 경계가 없을 수 있음(예를 들어 파랑, 빨강, 녹색과 같은 색상)

경계값 분석은 동등 분할 테스팅 보다 훨씬 더 효과적이기 때문에 가능한 경계값 분석을 적용!

정의 및 원리

테스트 아이템의 입력 또는 출력이 여러 영역(Partition)으로 구분되는 경우에 적용
동일한 영역 내에서는 어떠한 값을 선택해도 항상 같은 결과를 기대할 수 있다는 것을 전제로함(테스팅이 가정 하에 실행됨)
실무에서는 잘 활용되지 않는다(테스트 강도가 약함)

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

• 시스템명 : 교과목 학점 평가 시스템

• 요구사항

  • 시험점수(75%) + 과제 점수(25%) = 총점으로 학점 계산(A, B, C, D)

  • 시험 점수 입력 : 0 ~ 75점

  • 과제 점수 입력 : 0 ~ 25 점

  • "정수"만 입력 가능

  • 범위를 벗어나거나 잘못된 입력은 "경고 메시지"출력

절차

• TD1 : 기능 셋 식별 

  • 교과목 학점 평가 시스템 

• TD2 : 테스트 컨디션 도출
  • 유효한 입력 파티션 (Input Valid Partition) 
    • TCOND1 : 0 <= 시험 점수 <=75 
    • TCOND2 : 0 <= 과제 점수 <=25 
  • 비 유효한 입력 파티션(Input Invalid Partition) 
    • TCOND3 : 시험 점수 < 0 
    • TCOND4 : 시험 점수 > 75
    • TCOND5 : 과제 점수 < 0 
    • TCOND6 : 과제 점수 > 25 
  • 비 유효한 입력 파티션 (Input Invalid Partition)
    • TCOND7 : 시험 점수 = 실수 값(소수점 포함) 
    • TCOND8 : 시험 점수 = 영문자
    • TCOND9 : 시험 점수 = 특수 문자
    • TCOND10 : 과제 점수 = 실수 값(소수점 포함)
    • TCOND11 : 과제 점수 = 영문자
    • TCOND12 : 과제 점수 = 특수 문자 
  • 유효한 입력 파티션(Input Valid Partition)
    • TCOND13 : 70 <= 총 점 <= 100, 'A'
    • TCOND14 : 50 <= 총 점 < 70, 'B'
    • TCOND15 : 30 <= 총 점 < 50, 'C'
    • TCOND16 : 0 <= 총 점 < 30, 'D'
    • TCOND17 : 총 점 > 100, '경고 메세지' 출력
    • TCOND18 : 총 점 < 0, '경고 메세지' 출력
    • TCOND19 : 총 점 = 정수 이외의 값, '경고 메세지'출력
  • 비 유효한 입력 파티션 (Input Invalid Partition)
    • TCOND20 : 결과 = 'E'
    • TCOND21 : 결과 = 'A'
    • TCOND22 : 결과 = "null"

• TD3 : 테스트 커버리지 아이템 도출 
  • 테스트 커버리지 아이템 = 식별 된 파티션 = 테스트 컨디션

• TD4 : 테스트 케이스 도출
  • Option A : One to One (테스트 케이스 = 하나의 테스트 커버리지 아이템 커버)

• TD4 : 테스트 케이스 도출
  • Option A : Minimized (테스트 케이스 = 여러 테스트 커버리지 아이템을 동시에 커버)

• TD5 : 테스트 셋 구성(경고 메세지가 출력 되는 케이스는 수작업 테스트)
  • Option A : One to One
    • TS1 : 수작업 테스트 - Test Case 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 17, 18, 19, 20, 21
    • TS2 : 자동 테스트 - Test Case 1, 4, 13, 14, 15, 16
  • Option B : Minimized
    • TS3 : 수작업 테스트 - Test Case 5, 6, 7, 8, 9, 10, 11, 12
    • TS4 : 자동 테스트 - Test Case 1, 2, 3, 4

• TD6 : 테스트 프로시저 도출
  • Option A : One to One
    • TP1 : 수작업 테스트 - TS1과 동일
    • TP2 : 자동 테스트 - TS2와 동일
  • Option B : Minimized
    • TP3 : 수작업 테스트 - TS3과 동일
    • TP4 : 자동 테스트 - TS4와 동일

커버리지 = (커버 된 파티션 / 전체 파티션) * 100%

테스트 컨디션은 4가지 방법으로 생성

INVALID는 경험이나, 개발자에게 따로 문의

[기술적 관점]

시험 점수와 과제 점수는 정수 - 컴퓨터 메모리에서 어떻게 다뤄지는가?
선언된 변수의 처리는 CPU와 언어에 따라 다름

시험 점수와 과제 점수가 정수라면 추가 파티션 도출 가능
예를 들어 16비트 정수라면 아래와 같은 범위를 확인 할 수있음

동등 분할은 특정 결함 유형을 대상으로 하지 않음

테스트 대상에 대하여 기대 결과와 다른 결과를 테스트 케이스가 커버할 수 있도록 설계하는 것이 결함 발견에 도움이 됨
파티션을 동일한 특성의 클래스로 제대로 분할하지 않은 경우에 주의해야 함

동등 분할은 유효하지 않은 파티션에 대한 아이디어 도출을 강제함 > 테스트 대상이 잘못된 입력을 제대로 처리하지 못하는 결함 발견에 도움이 됨

일반적으로 입력 값과 그에 따라 변환되는 출력 값으로 기능적 결함을 발견

모든 테스트 유형과 테스트 레벨에 적용 가능

동일한 방식으로 처리될 것으로 기대하나 상호 작용하지 않는 데이터 세트에 적합

경계값 분석과 함께 사용될 때 가장 강력한 기법