테스트 설계 기법

테스트 설계 기법의 종류

블랙박스 기법(명세 기반 기법, 경험 기반 기법) - 완성 제품

테스트 대상의 내부구조(코드)를 참조하지 않고 테스트 베이시스 그리고 개발자와 테스터, 사용자들의 경험을 바탕으로 기능적 혹은 비기능적 테스트 케이스를 도출하고 선택하는 방법

 

화이트박스 기법(구조 기반 기법) - 소스 대상

컴포넌트(단위) 또는 소프트웨어(시스템)의 구조(코드)를 중심으로 테스트 케이스를 도출

 

테스트 설계의 근원을 기준

명세 기반 기법, 구조 기반 기법, 경험 기반 기법으로 분류

 

명세 기반 기법 -> 블랙박스 테스트

• 테스트 대상에 관한 공식적/비공식적 모델(명세) 사용
• 모델로부터 테스트 케이스를 체계적으로 도출

 

구조 기반 기법 -> 화이트박스 테스트

• SW 코드나 설계 등 구조를 보여주는 정보로부터 테스트 케이스 도출
• 작성한 테스트 케이스로부터 커버리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 체계적으로 추가할 수 있음

 

경험 기반 기법 -> 탐색적 테스트

• 테스터, 개발자, 사용자 등의 지식 활용
• 발생 가능한 결함과 그 분포 등에 대한 지식 활용
• 문서화 필요

 

명세 기반 기법

• 동등 분할
• 경계값 분석
• 조합 테스팅
• 결정 테이블 테스팅
• 상태전이 테스팅
• 유즈케이스 테스팅

 

동등 분할(Equivalence partitioning)

• 입력/출력값 영역을 유한개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대표값을 선택하여 테스트 케이스를 도출하는 방법
• 동일한 입력에 대해 항상 동일한 결과를 갖도록 클래스 구분
• 적용 방법
  • 주어진 시스템 정보를 분석해 입력/출력 영역을 유사한 특징을 가진 클래스로 분할
  • 분할된 클래스에서 각 클래스를 대표하는 테스트 케이스 도출
  • 모든 Valid equivalence class(유효)가 커버될 때까지 테스트 케이스 생성
  • 모든 Invalid equivalence class 가 커버될 때까지 테스트 케이스 생성

요구사항

테스트 케이스

 

경계값 분석(Boundary value)

• 동등 분할의 경계에서 결함이 발견될 확률이 가장 높기 때문에 결함을 예방하기 위해 경계값까지 포함하여 테스트
• 분할 영역의 최대값과 최소값이 그 영역의 경계값
• 동등 분할과 마찬가지로 모든 테스트 레벨, 테스트 유형에 적용
• 동등 분할의 확장으로 여겨지며 동일한 방식으로 커버리지 보장

 

결정 테이블 테스팅(Decision table)

결정 테이블

• 시스템의 동작을 결정하는 비즈니스 규칙을 정의하는 방법
• 입력 값들이 논리적인 관계(Binary Condition-참과 거짓)을 갖는 경우, 입력 값을 원인/결과로 나누어 기술 -> 테스트 케이스 작성
• 구현이나 명세에 잠재된 오류를 찾는데 효과적으로 이용

 

결정 테이블 특징

• 테이블 분석을 통해 중복, 발생 불가능한 상황, 모순이 생기는 상황을 제외시키고 나머지의 결정(Decision)과 액션(Action) 조합
• 좋은 Test Data 선택을 위해, 경계 값 또는 동등 분할 기법 사용
• 불가능한 Rule을 식별 하는 것은 Test 설계 단계에서 나올 수도, 나오지 않을 수도 있음 -> 시스템 설계에 의존적

 

장점

• 요구사항 등 테스트 베이시스의 문제점을 발견할 수 있는 효과적인 테스트 케이스 생성 가능(테스트 케이스를 작성하면서 결함 발견, 인스펙션 등 리뷰 미팅에 테스트 전문가가 참여한다는 의미)
• 테스트 베이시스의 불완전성과 모호함 식별 가능

단점

• 작성에 노력과 시간이 많이 소요될 수 있음 (특히 테스트를 위해 결정 테이블을 작성해야 하는 경우)
• 복잡한 시스템은 표현하기 어려울 수 있으며, 작성 시 논리적인 실수 가능성 있음 (개발팀 검토 필요)

 

결정 테이블 테스트 설계 기법을 이용해 테스트 케이스를 작성

조건

예상 결과

 

< ATM 로직 > 

사용자가 삽입한 카드가 유효하지 않으면 카드는 반환된다.
유효한 카드인 경우, 사용자는 패스워드를 입력한다.

 

사용자가 잘못된 패스워드를 입력하면 패스워드 재입력을 요구한다.
패스워드 입력 오류가 3회면 ATM은 카드를 보관(회수)한다.

 

사용자가 패스워드를 정상적으로 입력한 후, 원하는 출금액을 입력한다.

 

사용자가 입력한 출금액이 잔고보다 적으면 정상적으로 출금된다.
(입력한 출금액이 잔고보다 많으면 출금액 재입력 화면 출력)

 

시스템의 행동에 영향을 주는 조건을 분석하여 조건과 예상결과로 구분

조건	예상 결과
- 카드 유효 여부 - 패스워드 일치 여부 - 패스워드 불일치 3회 이상 - 잔고 정상	- 카드 반환 - 패스워드 재입력 - 카드 회수 - 출금액 재입력 - 출금

 

조건 4개 = 2^4 = 총 16개의 경우의 수!

 

카드가 유효하지 않다면(N) 다른 조건들(패스워드 일치, 불일치 3회, 잔고)을 다 볼필요는 없음!!

패스워드가 불일치 하든 뭐든 어차피 카드는 반환되기 때문에 불필요 테이블 삭제

패스워드가 불일치라면 잔고 정상 여부를 확인할 필요가 없기 때문에 불필요 테이블 삭제

패스워드가 3회 불일치라면 잔고 정상 여부를 확인할 필요가 없기 때문에 불필요 테이블 삭제

카드가 유효하고 패스워드가 일치하면 3회 불일치 조건을 볼 필요가 없음, 불필요 테이블 삭제

 

완성된 결정 테이블

총 5개의 테스트 케이스 생성 가능!

 

 

 

상태 전이 테스팅(State transition)

• 이벤트, 액션, 상태, 가드, 상태전이 사이의 관계를 검증
• 시스템/SW의 상태 기반 행위가 명세화된 내용과 일치함을 검증
• 상태기반 시스템의 결함은 상태, 상태전이, 가드, 이벤트 결함 등으로 분류
• "구현이 잘못된 경우"와 "명세가 잘못된 경우"의 결함으로 구분
• 모델(명세)상의 결함 발견 가능 -> 인스펙션, 정적 분석으로 결함 발견
  • 초기상태 누락
  • 전이 또는 액션의 누락
  • 가드를 "전이" 대신 상태에 표기
  • 가드의 중복 또는 불일치
• 구현상의 결함 발견 가능 -> 테스트를 통해 결함 발견
  • 여분/누락/훼손 상태(extra/missing/corrupt state)
  • 액션이 틀리거나 누락됨
  • 스니크 패스(sneak paths), 트랩 도어(trap doors)
    • 설계할 때 의도하지 않았으나 발생하여 정상적인 작동에 손상을 주는 경로

 

상태 다이어그램 구성

• 상태(states)
• 전이(transition)
• 이벤트(events)
• 가드(guards)
• 액션(actions)

 

상태 다이어그램 표기법

구성요소	설명	표기법
상태	하나 또는 그 이상의 이벤트를 기다리는 시스템의 독립적인 모드	원으로 표기, 원 안에 상태명 표기
전이	이벤트에 의해 현 상태에서 다른 상태로의 이동 또는 변경	화살표 형태의 선으로 표시하며 상태와 상태를 연결
이벤트	상태의 전이를 유발하는 요인	전이와 같이 표시하며 이벤트 이름을 표시함 (e.g., ev 취소)
가드	상태 전이 조건	이벤트와 함께 표시, '[ ]' 안에 조건이나 값으로 표시 (e.g., ev 금액투입 [투입금액<가격])
액션	상태 전이와 함께 시스템 또는 소프트웨어가 동작하는 행위나 출력	이벤트 뒤에 '/'로 구분 후 표시 (e.g., ev 음료버튼선택 / 잔액 반환())

 

 

음료 자판기 시스템 상태 전이 다이어그램

 

 

상태전이 테스트 케이스 절차

1. 상태-이벤트 테이블 구성
2. 전이 트리 구성
3. 반응(Legal, 또는 Valid(유효)) 테스트 케이스 구성
4. 무반응(Ilegal, 또는 Invalid(비유효)) 테스트 케이스 구성
5. 가드(Guard) 또는 조건 테스트 케이스 구성
6. 테스트 프로시저(Test procedure) 구성

 

1. 상태-이벤트 테이블 구성

 

2. 전이 트리(1-switch)

 

3. 반응(Legal, 또는 Valid(유효)) 테스트 케이스 구성

 

4. 무반응(Ilegal, 또는 Invalid(비유효)) 테스트 케이스 구성

 

5. 가드(Guard) 또는 조건 테스트 케이스 구성

 

6. 테스트 프로시저(Test procedure) 구성

-> 가능한 한 겹치지 않으면서 모든 테스트 케이스를 수행할 수 있도록 구성

 

 

유즈케이스 테스팅(Use case)

• 액터와 액터 사이의 상호작용을 표현 -> 유저에게 결과값 전달
• 시스템(SW)이 유즈케이스로 모델링 되었을 때, 유즈케이스를 활용해 테스트 케이스를 도출하는 테스트 설계 기법
• 유즈케이스를 어떻게 작성하느냐에 따라 유즈케이스의 테스트 용이성이 달라짐 -> 테스팅하기 어려울 수 있음
• 프로세스 흐름을 기술
  • 기본 흐름
  • 대체 흐름

• 각각의 유즈케이스는 자세하게 표현하기 위해 유즈케이스 상세(description)를 가짐
• 시나리오
• 프로세스 흐름 기술
• 유즈케이스를 통해 생성된 테스트 케이스를 통해 시스템이 실제 사용되는 프로세스 흐름에서 결함을 발견하는 데 유용
• 고객이나 유저 그룹을 참여시키는 인수 테스트를 설계할 때 유용
• 통합 테스트 단계에서 컴포넌트 사이의 통합 결함을 찾는데 도움

 

 

이체(모바일 뱅킹) 유즈케이스의 이벤트 흐름과 테스트 시나리오

 

 

이체(모바일 뱅킹) 유즈케이스의 테스트 케이스

 

테스트 순서
- 유즈케이스 상세를 문장별로 분석하여 테스트 케이스 도출 -> 누락을 최소화하고 일정 수준의 보장성을 확보

1. 어떤 흐름을 테스트 할지 고려하여 테스트 시나리오 구성
2. 유즈케이스 상세에서 테스트에 필수적인 상황 선택
3. 유즈케이스 상세 내용을 입력값, 출력값, 상황 처리 등으로 분류하여 테스팅에 관여하는 상황을 선택
4. 각각의 상황에 ID 부여
5. 각각의 상황에 가능한 값을 결정(valid/invalid, upper/lower, true/false, not applicable)

 

컴포넌트(단위) 레벨 유즈케이스 테스팅

- 유즈케이스 각각을 테스팅하는 방법

 

시스템 레벨 유즈케이스 테스팅

- 유즈케이스 상호간의 활동을 테스트

- 상태 관점에서 파악하고 활동의 흐름을 전이로 간주하여 상태 전이 테스팅 기법의 컨셉을 활용

• 활동 기반 커버리지 : 각각의 활동만을 테스팅
• 전이 기반 커버리지 : 활동의 흐름을 테스팅
• 경로 기반 커버리지 : 재귀적인 흐름도 고려한 테스팅
• 활동 기반 ⊂ 전이 기반 ⊂ 경로 기반 -> 포함관계 존재

 

구조 기반 기법

화이트 박스 테스팅 -> 시스템의 구조를 중심으로 테스팅

• SW 코드나 설계 등 구조를 표현하는 정보로부터 테스트 케이스 도출
• 작성한 테스트 케이스들로부터 커버리지를 측정할 수 있으며, 커버리지를 높이기 위해 테스트 케이스를 체계적으로 추가
  • 제어 흐름 테스트, 기본 경로 테스트, x커버리지 테스팅

테스트 레벨과 소프트웨어 구조와의 관계

테스트 레벨	소프트웨어 구조
컴포넌트 레벨	Statements(구문), Decisions(결정) 또는 Branches(분기) 등 코드 구조
통합 레벨	콜 트리(모듈간의 호출 구조 다이어그램) 등
시스템 레벨	메뉴 구조, 비즈니스 프로세스 구조, 웹 페이지 구조 등

 

 

구문 커버리지(statement coverage)

테스트 스위트(테스트 케이스의 집합)에 의해 실행된 구문이 몇 퍼센트(%)인지 측정(가장 약함)

 

결정 커버리지(decision coverage)

실행된 결정 포인트 내의 전체 조건식이 최소한 참이 한 번 그리고 거짓이 한 번씩 선택되었는지 측정하여 퍼센트로 표현

 

조건 커버리지

전체조건식의 결과와 관계없이 각 개별 조건식이 참 한번, 거짓 한번을 모두 갖도록 개별조건식을 조합 (결정 커버리지 보다 강력)

 

결정 커버리지(Decision Coverage) / 분기 커버리지(Branch Coverage)

DPoint = A AND B에 대한 결정 커버리지의 결정 테이블

DPoint	A	B
0	1	0
1	1	1

 

조건 커버리지(Condition Coverage)

DPoint = A AND B에 대한 조건 커버리지의 결정 테이블

DPoint	A	B
0	1	0
0	0	1

 

 

구문 테스팅과 커버리지

• 테스트 스위트에 의해 실행된 구문이 몇 퍼센트(%)인지 측정
  • 존재하는 가능한 경우를 모두 검증 못하는 보장성이 낮은 커버리지
• 구문 테스팅은 구문 커버리지를 늘리기 위해 특정 구문을 테스트하는 테스트 케이스 도출
  • 코드의 모든 구문을 실행할 수 있는 입력값이나 이벤트 등의 테스트 데이터를 제공해주면 달성됨

 

결정 테스팅과 커버리지

결정 커버리지

• 분기 테스팅과 관련
• 테스트 스위트(suite, 묶음)에 의해 실행된 조건문 분기(if문의 참/ 거짓)가 전체 가능한 분기의 몇 퍼센트인지를 측정하고 평가
• 결정 포인트(decision points) 내의 전체조건식이 참과 거짓의 모든 값을 갖게 되어 모든 분기로 흐르게 되면 달성

결정 테스팅

• 결정 커버리지를 늘리기 위해 특정 조건문의 분기를 테스트하는 테스트 케이스를 도출하는 것
• 제어 흐름 테스트

제어 흐름 테스트

• 구조기반 테스트 -> 코드 레벨의 커버리지 개념 필요
• 프로그램 구조 테스트
• 공식적인 화이트 박스 테스트 -> 단위 / 통합 테스트에서 사용
  • 테스트 깊이 레벨에 따라 강도 존재
  • 테스트 케이스를 선택된 흐름에 따라 연속적인 구문의 집합으로 기술
  • 테스트 깊이가 깊을수록 제품의 커버리지는 높아지는 반면 테스트 케이스가 기하급수적으로 많아져 비용, 시간, 리소스 많이 소요됨

 

조건 테스팅과 커버리지

조건 커버리지

• 결정 포인트 내에 있는 개개의 개별 조건식이 참/거짓의 모든 값을 갖게 되면 달성
• 조건 커버리지(강력, 견고한 테스트) > 결정 커버리지

 

조건/결정 커버리지

• 항상 결정과 조건 커버리지를 모두 만족시키는 것보다 강력
• 결정과 조건 커버리지를 최소한 조합으로 달성하는 경우
  • 항상 모든 개별 조건식이 참이고 이에 따른 전체조건식이 참인 경우
  • 모든 개별 조건식이 거짓이면서 이에 따른 전체조건식이 거짓인 경우

 

 

커버리지 레벨(depth level)

• 다중 조건 커버리지(Multiple condition coverage) -> 가장 강력
  ✓ 결정 포인트 내의 개별조건식 결과(참/거짓)에 대한 모든 가능한 논리적인 조합을 적어도 한번 수행
• 변형 조건/결정 커버리지(MC/DC)
  ✓ 결정포인트 내에 다른 개별조건식의 결과와는 독립적으로 해당 개별조건식이 전체조건식의 결과에 영향을 줌
• 조건/결정 커버리지(Condition/decision coverage)
  ✓ 모든 개별조건식이 전체조건식 판단문의 결과값 확정에 관여하는 경우 를 모두 고려함
• 조건 커버리지(Condition coverage)
  ✓ 프로그램 내에 있는 결정 포인트 내의 모든 각 개별 조건식에 대한 모든 가능한 결과(참/거짓)에 대해 적어도 한번 수행

 

다중 조건 커버리지

• 결정 포인트 내에 있는 모든 개별 조건식의 모든 가능한 논리적 인 조합을 고려하여 100% 커버리지를 보장
• 출시 전 모든 결함을 제거해야 하는 제품 테스트에서 주로 사용

 

 

변형 조건/결정 커버리지(Modified Condition/Decision)

• 각 개별조건식이 다른 개별조건식에 영향을 받지 않고 전체조건식의 결과에 독립적으로 영향을 주도록 함
• 조건/결정 커버리지를 향상 시킴, 다중 조건 커버리지 보다는 완화
• 조건 커버리지나 결정 커버리지 보다 강력
  • 프로그램에 있는 모든 결정 포인트 내의 전체조건식은 적어도 한번 모든 가능한 결과값(참, 거짓)을 취한다.
  • 프로그램에 있는 결정 포인트 내의 모든 개별조건식은 적어도 한번 모든 가능한 결과값(참, 거짓)을 취한다.
  • 결정 포인트에 있는 각각의 개별조건식은 다른 개별조건식에 영향을 받 지 않고 그 결정 포인트의 결과값에 독립적으로 영향을 준다.
• 가능한 한 의미 있게 조합의 수를 줄여 테스트 수행

ex)

만약 1행에 A = 1을 고정해두고 B 값을 변경시키면 ? D Point 결과값에 영향을 줌

만약 2행에 B = 1을 고정해두고 A 값을 변경시키면 ? D Point 결과값에 영향을 줌

만약 3행에 A든 B든 하나를 고정하고 다른 값을 변경시키면 ? D Point 결과값에 영향을 줌

(제외되는 경우 ) 만약 D Point = 0 / A = 0 / B = 0 일 때, A든 B든 하나를 고정하고 다른 값을 변경시키면 ? D Point 결과값에 영향 없음

 

테스트 커버리지 종류 및 포함 관계

 

 

경험 기반 기법

경험 기반 테스팅

• 이전에 테스터가 다루었던 유사 어플이나 기술에서의 경험, 직관, 테스터의 기술 능력으로부터 테스트 케이스 추출
• 공식적인 아닌 특별한 테스트 케이스를 찾아내고 실행하는데 유용 -> 공식적인 기법과 같이 사용해야 효과적인
• 경험에 따라 효율성 및 효과성의 정도가 매우 달라짐(일관성 ↓)
• 테스트 케이스를 문서화함
• 에러 추정(Error guessing)
• 탐색적 테스팅(Exploratory Testing) 접근법

탐색적 테스팅 : 기법이 아닌 접근법

• 테스트 케이스 작성 시간을 최소화하고 테스트 엔지니어의 발견적인(heuristic) 지적능력을 최대한 활용하여 테스트 수행
• 에드혹, 게릴라, 직관적 테스팅과 유사한 개념
  • But, 정해진 임무와 목표, 결과물이 존재
• 테스트 설계, 테스트 수행, 테스트 계획, 테스트 기록 및 학습을 동시에 진행
• 테스트를 먼저 작성하지 않고, 테스트 대상 제품을 실행하면서 익숙해지는 동시에 테스트를 설계하고 테스트를 계획한다.
  • 테스트 차터를 기반으로 수행(60~120분 동안 몰입해서 수행)
  • 제한된 시간(time-boxing)내에 테스팅의 목적을 정한 후 몰입하여 최소 한의 설명 가능한 기록(note)을 남기며 테스트 수행하고, 수행 후 요약보고(debriefing)를 하는 것을 강조
• 경험적인 요소를 많이 반영하고 있는 체계화된 테스팅 접근법
• 테스트 케이스 작성(문서화)하는데 들이는 노력을 최소화
• 테스트 설계와 실행 최대화
• 점진적 & 주기적 테스팅
• 공식적 테스팅을 보완하는 측면에서 활용하거나 두가지 접근법을 병행할 것을 권장

탐색적 테스팅 절차

• 제품의 목적 식별
• 기능 식별
• 잠재적으로 불안정한 부분 식별
• 각각의 기능 테스트 및 문제점 기록
• 일관성 검증 테스트 설계 및 기록

탐색적 테스팅의 구성 요소

테스터 차터 -p265

• 제품의 어느 부분을 어떻게 테스트하고 어떤 것을 중점적으로 봐야 할지 등을 기록한 테스트 명령지
• 각 세션에 대해 명확한 임무를 설정

테스터가 수행할 내용

• 정확한 리포팅
• 유연성 있는 일정 관리
• 테스트 방향 정정
• 견고한 테스팅
• 효율적인 요약 보고

테스트 노트

• 테스트 실행과 동시에 계획, 설계, 테스트 케이스 작성 -> 노트화 함
• 테스트 기록 및 발견 특이사항과 실행시간 등 기재 -> 테스트 케이스
• 내용
  • 테스트한 제품에 대한 노트 및 기록
  • 발견한 결함과 장애에 대한 노트 및 기록
  • 어떻게 테스트하였는지를 기술하는 요약된 문서

타임 박싱(60~120분)

• 테스트 집중력을 높이기 위해 테스트 시간을 제한
• 테스트 시간을 제한하면 집중력이 높아지며, 테스트 일정 수립도 쉬움

회고(요약보고 - debriefing)

• 테스트 중 발견했던 결함과 이슈사항에 대해 보고
• 테스터의 경험과 지식을 공유
• 문서화

테스트 케이스 기반 테스팅과 탐색적 테스팅 비교

• 테스트 제품을 파악해 가면서 테스트 실시
• 탐색적 테스트는 테스터의 성향에 많이 의존적임
• 그림 4.22 문서화 정도와 지적 능력의 활용 정도에 따른 비교
  • 테스팅 케이스 기반(연설문-문서화)
  • 탐색적 테스팅(경험-지적 능력)
• 표 4.41 테스트 케이스 기반 테스팅과 탐색적 테스팅의 비교

리스크 기반 테스팅과 연계한 탐색적 테스팅의 활용

• 그림 4.23 리스크 기반 전략에서의 탐색적 테스팅 접근법 활용

 

탐색적 테스팅 효과

• 경험적 테스팅을 체계화 시킬 수 있음
• 테스트케이스 작성 시간을 줄여 좀 더 많은 테스트 가능
• 테스터 또는 테스트 엔지니어의 역량을 강화할 수 있음
• 적은 테스트 인력으로 많은 테스트를 수행할 수 있음
• 명세가 없고 시간 부족인 경우 테스트를 효과적으로 효율적으로 수행할 수 있음

 

탐색적 테스팅 프로세스(절차)

 

 

고급 설계 기법

명세 기반 기법

분류 트리 기법 - p163 그림 4.25

• 소프트웨어 일부 또는 전체를 트리구조로 분석 및 표현하고 이를 바탕으로 테스트케이스를 도출하는 기법
• 분류 트리 장점
  • 시각화해서 테스트케이스 작성에 용이
  • 트리 구조이므로 중복되거나 빠지는 테스트가 없음
  • 복잡한 시스템이나 어플리케이션의 일부 또는 전체를 테스팅
  • 개발 설계를 체크하는 용도로 사용이 가능함
  • 테스트케이스 개수와 트리의 복잡도를 근거로 테스트 비용을 추정하는 것이 가능함

페어와이즈 조합 테스팅

• 페어와이즈 관찰 결과 대부분의 결함이 2개 요소의 상호 작용에 기인하여 나타남
• 페어와이즈는 테스트 하는데 필요한 각 값들이 다른 파라미터의 값과 최소한 한 번씩은 조합을 이루게 된다는 것
• 3개의 파라미터가 각 5, 4, 5 가지 값을 가질 때 100가지에서 만약 테스트를 100가지 경로로 하게되면 10000개의 테스트를 실행해야 함 -> 조합을 최소화 함

 

페어와이즈 조합 테스팅 과정

직교 배열 테스팅

• 6-시그마 기법에 이용되고 있으며 소프트웨어 테스트에 적용하 여 사용하고 있음
• 직교 배열의 원리를 소프트웨어 테스트에 적용하여 조합의 수를 줄임으로써 테스트 케이스의 수를 합리적으로 줄임
• 직교 배열에서 열과 행이 페어와이즈 하다는 것은 직교 배열의 각 행과 열의 조합이 서로 다르다는 것을 의미함
• P167의 그림 4.26

 

 

구조 기반 기법

분할 방법으로 접근한 조건 / 결정 커버리지

분할

• 논리적 테스트 컬럼의 각각을 선택한 커버리지로 생성한 모든 논리적 조합으로 분할하여 테스트 케이스를 작성하는 방식
• 모든 조합을 분할해서 나열하기 때문에 결함원인은 매우 빨리 발견할 수 있지만 테스트 케이스 수가 크게 증가함

포함

• 논리적 테스트 컬럼의 각각을 선택한 커버리지
• 생성한 조합 중에서 단 하나만 선택하여 하나의 논리적 테스트 케이스 로 작성하는 1:1 전환 방식 (테스트 케이스 줄임)

[표 4.46] 결정 테이블

 

 

경험 기반 기법

오류 추정

• 테스터가 테스트 할 시스템에 대하여 완전히 이해한다는 전제로 적용되는 기법
• 취약점 식별 작업에 기반한 테스트
• 테스트 프로세스의 마지막 단계에서 사용
• 일반적인 유용성
  • 테스트에 참고할 명세가 없거나 불충분할 경우, 시간적인 압박이 심한 경우 유용
  • 다른 기법이나 공식적인 테스트를 보완할 때 유용하게 사용
  • 가장 심각한 결함을 찾았다는 확신이 필요한 경우 사용함으로써 테스트 프로세스 및 완성도를 확인하는 기준을 제공

체크리스트

• 테스팅 절차와 테스트 대상 기능 및 시스템 요소 등을 체크리스트로 작성함
• 일반 체크리스트 : 수행해야 할 테스트 목록과 절차를 나열함
• 기능(블랙) 체크리스트
  • 전체 시스템의 최상위 기능 체크
  • 개별적인 컴포넌트 기능
  • 서로 다른 레벨의 기능과 그룹핑
• 시스템 요소 체크리스트
  • 상위레벨 서브-시스템이나 모듈
  • 개인 구문이나 데이터 아이템
  • 서로 다른 레벨의 시스템 요소와 그룹핑

체크 리스트와 테스트 케이스 비교

체크 리스트

• 경험과 노하우의 반영물이어서 테스트를 효율적으로 진행할 수 있음
• 효과성은 없음
• 테스트 베이시스에서 결함을 발견하는데 주로 사용되어서 정적 테스트 기법의 주요 도구 사용

테스트 케이스

• 동적 테스팅의 주요 도구가 됨
• 기법을 적용하여 도출되는 경우가 대부분이고 기법이 보장하는 범위에 서 효과성을 보장해줌

 

어떤 테스트 기법을 사용할지 결정할 때 고려할 사항

• 시스템 유형 및 특징
• 강제적 표준 또는 법적 기준 적용 여부
• 고객 또는 계약상의 요구사항
• 리스크 수준
• 리스크 유형
• 테스트 목표
• 문서(테스트 베이시스)의 존재 유무
• 테스터의 지식 수준
• 시간과 예산
• 테스트 레벨
• 개발 수명 주기
• 유즈케이스, 상태 다이어그램 등 개발 설계 모델 존재 유무
• 발견된 결함 유형 등 이전의 경험

 

테스트 기법을 잘 사용하게 되면

• 테스트 전략을 구체적으로 해석해 적절한 기법을 적용
• 임의로 테스트 케이스를 작성하는 것보다 결함을 발견할 수 있 는 효과적인 테스트 케이스작성 가능(결함 발견율 ⬆️)
• 테스트(케이스)의 높은 재사용성 보장
• 테스트 강도(커버리지)와 품질에 대한 통찰을 제공

 

---

 

📚 참고 문헌 : 개발자도 알아야할 소프트웨어 테스팅 실무

📌 참고 강의 : https://youtube.com/playlist?list=PLUQt-s6e18eOY8rMTw95VsL-jzgLSMuXJ&si=9nltgRpIxSxK9Nhl