ISTQB 실라버스 4장 요약

1. 테스트 기법 개요

- 블랙박스, 화이트박스, 경험 기반 테스트 기법을 구별할 수 있다

2. 블랙박스 테스트 기법

- 동등 분할을 사용해 테스트 케이스를 도출할 수 있다

- 경계값 분석을 사용해 테스트 케이스를 도출할 수 있다

- 결정 테이블 테스팅을 사용해 테스트 케이스를 도출할 수 있다

- 상태 전이 테스팅을 사용해 테스트 케이스를 도출할 수 있다

3. 화이트박스 테스트 기법

- 구문 테스팅을 설명할 수 있다

- 분기 테스팅을 설명할 수 있다

- 화이트박스 테스팅의 가치를 설명할 수 있다

4. 경험 기반 테스트 기법

- 오류 추정을 설명할 수 있다

- 탐색적 테스팅을 설명할 수 있다

- 체크리스트 기반 테스팅을 설명할 수 있다

 

 

1) 동등 분할 커버리지 (테스트 케이스가 실행한 분할 수) / (식별한 총 분할 수) × 100%

2) 경계값 분석 커버리지

[2-value BVA] (테스트 케이스가 실행한 경계값 수) / (식별한 경계값 총 수) × 100%

[3-value BVA] (테스트 케이스가 실행한 경계값 및 이웃 값 수) / (식별한 경계값 및 이웃 값 총 수) × 100%

3) 결정 테이블 커버리지 (실제로 실행된 열 수) / (실행 가능한 열의 총 수) × 100%

4) 상태 전이 테스팅 커버리지

- 모든 상태(All State) (확인한 상태 수) / (상태 총 수) × 100%

- 유효 전이(Valid Transitions, 0-스위치) (실제로 실행된 유효 전이 수) / (총 유효 전이 수) × 100%

- 모든 전이(All Transitions) (실행한 유효 및 비유효 전이 수) / (총 유효 및 비유효 전이 수) × 100%

5) 화이트박스 테스트 커버리지

- 구문(Statement) 커버리지 (테스트 케이스가 실행한 구문 수) / (전체 실행 가능한 구문 수) × 100%

- 분기(Branch) 커버리지 (테스트 케이스가 실행한 분기 수) / (전체 분기 수) × 100%

1. 테스트 기법 개요

• 테스트 기법의 목적
  • 테스트 분석(무엇을 테스트할지)과 테스트 설계(어떻게 테스트할지) 작업 지원
  • 체계적인 방식으로 적은 수의 충분한 테스트 케이스 개발
  • 테스트 컨디션 정의, 커버리지 항목 및 테스트 데이터 식별 도움
• 테스트 기법 분류
  • 블랙박스 테스트 기법 (명세 기반 기법)
    • 내부 구조 참조 없이 명시된 동작에 대한 분석 기반
    • 소프트웨어 구현 방식에 의존하지 않음
    • 구현이 바뀌더라도 필요한 동작이 동일하면 테스트 케이스 유효
    • 동등 분할, 경계값 분석, 결정 테이블 테스팅, 상태 전이 테스팅
  • 화이트박스 테스트 기법 (구조 기반 기법)
    • 내부 구조와 처리에 대한 분석 기반
    • 소프트웨어 설계 방식에 의존
    • 설계나 구현이 끝난 후에 테스트 케이스 생성
  • 경험 기반 테스트 기법
    • 테스터의 지식과 경험을 활용
    • 테스터의 능력에 따라 효과성 달라짐
    • 블랙박스 및 화이트박스 테스트 기법을 보완

2. 블랙박스 테스트 기법

2-1. 동등 분할

: 테스트 대상이 동일한 방식으로 처리될 것으로 예상되는 데이터를 분할 단위로 나누는 기법

• 각 분할 내의 특정 값을 테스트하는 테스트 케이스가 결함을 식별할 수 있다면, 같은 분할의 다른 값도 결함을 식별할 수 있다고 가정한다.
• 따라서 각 분할에 대해 하나의 테스트만 수행하면 충분하다.
• 테스트 대상이 단순하다면 동등 분할을 적용하기가 쉬울 수 있지만, 실제로는 테스트 대상이 다양한 값을 어떻게 처리하는 . 지이해하기 어려울 때가 많다. 그렇기 때문에 분할 식별은 신중하게 해야한다.
• 적용대상
  • 동등 분할은 입력, 출력, 형상 항목, 내부 값, 시간 관련 값, 인터페이스 매개변수 등 테스트 대상과 관련된 모든 데이터 요소에 대해 식별할 수 있다.
• 특징
  • 분할은 연속적이거나 비연속적일 수 있으며, 정렬되어있거나, 유한 또는 무한일 수 있다.
  • 분할은 서로 겹치지 않아야하며, 값이 없는 공집합일 수는 없다.
• 유효/ 비유효 분할
  • 유효 분할: 테스트 대상이 처리해야 하는 값 또는 명세에 정의된 값을 포함
  • 비유효 분할: 테스트 대상이 무시하거나 거부해야 하는 값, 또는 명세에 정의되지 않은 값을 포함
• 커버리지
  • 각 분할을 최소 한번씩 다루는 테스트 케이스로 100% 커버리지를 달성
  • 커버리지 측정: 테스트 케이스로 실행한 분할 수 / 식별한 총 분할 수 x 100%
• 이치 초이스 커버리지
  • 분할 집합이 다수인 경우, 가장 간단한 커버리지 기준을 말함.
  • 모든 분할 집합의 각 분할을 최소 한 번 실행하는 것을 요구함.
  • 분할의 조합을 고려하지 않음.
• 동등 분할 테스팅 예제
  • 테스트 대상: 사용자가 입력하는 나이에 따라 다른 메시지를 출력하는 간단한 애플리케이션을 가정
    • 0 ~ 12: "어린이"
    • 13 ~ 19: "청소년"
    • 20 ~ 59: "성인"
    • 60 이상: "노인"
    • 유효하지 않은 값: "유효하지 않은 입력"
  • 동등 분할: 이 애플리케이션에서는 입력 값의 범위에 따라 다음과 같은 동등 분할을 정의할 수 있음.
    • 유효 분할
      • 0 ~ 12: 어린이
      • 13 ~ 19: 청소년
      • 20 ~ 59: 성인
      • 60 이상: 노인
    • 비유효 분할
      • 음수 값 (예: -1)
      • 비숫자 값 (예: "abc")

2-2. 경계값 분석

: 동등 분할의 경계값을 중심으로 하는 테스트 기법

• 경계값 분석은 정렬된 분할에서만 사용할 수 있음.
• 분할의 최솟값과 최댓값이 경계값이 된다.
• 같은 분할에 속하는 두 값 사이의 모든 값도 해당 분할에 속해야 한다.
• 경계값 분석의 주요 결함
  • 경계가 의도한 위치보다 위나 아래에 잘못 배치된 경우
  • 경계가 누락된 경우
• 유형
  • 두 개 선택 경계값 분석(2-value BVA)
    • 각 경계값에 대해 두 개의 커버리지 항목을 도출
    • 경계값과 인접 분할에 속한 가장 가까운 값이 커버리지 항목(각 경계의 최솟값과 최댓값)
    • 100% 커버리지 달성: 모든 경계값과 인접 값을 테스트
    • 커버리지 계산: 실행한 경계값 수 / 식별한 경계값 총 수 x 100%
  • 세 개 선택 경계값 분석(3-value BVA)
    • 각 경계값에 대해 세 개의 커버리지 항목을 도출
    • 경계값과 이웃한 양쪽의 값 모두가 커버리지 항목(직전값, 경계값, 바로 직후 값)
    • 100% 커버리지 달성: 모든 경계값과 이웃 값을 테스트
    • 커버리지 계산: 실행한 경계값 및 이웃 값 수 / 식별한 경계값 및 이웃 값 총 수 x 100%
• 경계값 분석 예제
  • 테스트 대상: 사용자가 입력하는 점수에 따라 성적을 부여하는 애플리케이션을 가정하며, 점수에 따라 다음과 같은 성적을 부여함.
    • 0 ~ 59: "F"
    • 60 ~ 69: "D"
    • 70 ~ 79: "C"
    • 80 ~ 89: "B"
    • 90 ~ 100: "A"
  • 경계값: 이 애플리케이션에서는 각 성적 구간의 경계값을 다음과 같이 정의할 수 있음.
    • 0, 59, 60, 69, 70, 79, 80, 89, 90, 100
  • 2-value BVA를 기준으로 테스트 데이터 분류
    1. 0, 59
    2. 60, 69
    3. 70, 79
    4. 80, 89
    5. 90, 100
  • 3-value BVA를 기준으로 테스트 데이터 분류
    1. -1, 0, 1
    2. 58, 59, 60
    3. 59, 60, 61
    4. 68, 69, 70
    5. 78, 79, 80
    6. 79, 80, 81
    7. 88, 89, 90
    8. 89, 90, 91
    9. 99, 100, 101

2-3. 결정 테이블 테스팅

: 여러 조건의 조합에 따라 달라지는 결과를 정확하게 구현했는지 확인하는 테스트 기법

• 복잡한 비즈니스 로직을 테스트하는 데 효과적임
• 결정 테이블 구성
  • 조건: 조건과 시스템의 동작 결과를 정의
  • 행: 조건 및 결과 동작
  • 열: 하나의 결정 규칙을 나타내며, 고유한 조건 조합과 그에 따른 동작을 정의
• 표기법 
  • 조건
    • "T" (True): 조건이 충족됨
    • "F" (False): 조건이 충족되지 않음
    • "-" (Dash): 결과에 영향이 없음
    • "N/A": 실행 불가능한 조건
  • 결과 동작 
    • "X": 동작이 발생해야 함
    • 공백: 동작이 발생하지 않아야 함
• 유형
  • 제한-입력 결정 테이블: 모든 조건과 동작 결과값을 부울값으로 표시
  • 확장-입력 결정 테이블: 조건 및 동작 결과값이 복수의 값을 가질 수 있음(예: 숫자 범위, 동등 분할, 불연속 값)
• 커버리지
  • 커버리지 항목은 실형 사능한 조건 조합을 가진 열
  • 100% 커버리지 달성: 모든 열을 테스트
  • 커버리지 측정: 실행된 열의 수 / 실행 가능한 열의 총 수 x 100%
• 강점
  • 모든 조건 조합을 체계적으로 식별
  • 누락되거나 모순된 요구사항 식별
  • 조건이 많을 경우, 규칙의 수가 기하급수적으로 늘어날 수 있음
  • 결정 테이블을 최소화하거나 리스크 기반 접근법을 사용할 수 있음

2-4. 상태 전이 테스팅

: 시스템의 가능한 상태와 유효한 상태 전이를 모델링하여 시스템 동작을 테스트하는 기법

• 전이는 특정 이벤트에 의해 발생하며, 가드 조건과 동작이 포함될 수 있다.
• 상태 전이 다이어그램
  • 시스템의 상태와 상태 간의 전이를 그래픽으로 표현
  • 전이는 "이벤트 [가드 조건] / 동작" 형식으로 표시
• 상태 테이블
  • 상태 전이 다이어그램의 다른 표현 방식
  • 행은 상태, 열은 이벤트를 나타냄
  • 각 셀은 전이를 나타내며, 목표 상태와 가드 조건, 결과 동작을 포함
• 테스트 케이스
  • 일련의 이벤트와 그에 따른 상태 변화 및 동작을 포함
  • 하나의 테스트 케이스는 여러 상태 전이를 포함할 수 있음
• 커버리지 측정 기준
  • 모든 상태 커버리지(All State Coverage)
    • 커버리지 항목: 상태
    • 100% 달성 조건: 모든 상태를 테스트
    • 커버리지 측정: (확인한 상태 수 / 상태 총 수) x 100%
  • 유효 전이 커버리지(Valid Transitions Coverage, 0-스위치 커버리지)
    • 커버리지 항목: 유효 전이
    • 100% 달성 조건: 모든 유효 전이를 테스트
    • 커버리지 측정: (실행된 유효 전이 수 / 총 유효 전이 수) x 100%
    • 가장 널리 사용되는 커버리지 조건임.
      • 유효 전이 커버리지 100%를 달성하면, 모든 상태 커버리지도 달성됨
  • 모든 전이 커버리지(All Transitions Coverage)
    • 커버리지 항목: 모든 전이(유효 및 비유효)
    • 100% 달성 조건: 모든 유효 전이를 실행하고, 비유효 전이도 시도
    • 커버리지 측정: (실행한 유효 및 비유효 전이 수 / 총 유효 및 비유효 전이 수) x 100%
    • 모든 전이 커버리지를 100% 달성하면, 모든 상태 커버리지와 유효 전이 커버리지도 보장됨

3. 화이트박스 테스트 기법

: 소프트웨어 내부 구조와 처리를 기반으로 하는 테스트 기법으로, 주로 코드의 논리적 흐름을 검증

• 널리 사용하는 두가지를 다룰 예정
  • 구문 테스팅
  • 분기 테스팅

3-1. 구문 테스팅과 구문 커버리지

• 구문 테스팅
  • 실행 가능한 모든 코드 구문을 테스트하는 기법
  • 목적: 코드 구문을 실행하는 테스트 케이스를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것
• 구문 커버리지
  • 테스트 스위트에 의해 이행되는 실행문의 백분율
    • 테스트 스위트: 테스트 대상 컴포넌트나 시스템에 사용되는 여러 테스트 케이스의 집합. 
  • 100% 구문 커버리지: 모든 구문은 적어도 한 번은 실행했다는 것을 의미하지만, 모든 결함을 식별할 수 있다는 것을 보장하지는 않음.
  • 커버리지 계산: (테스트 케이스가 실행한 구문 수 / 전체 실행 가능한 구문 수) x 100%

3-2. 분기 테스팅과 분기 커버리지

• 분기 테스팅
  • 제어 흐름 그래프의 모든 분기를 테스트하는 기법
  • 분기: 제어 흐름 그래프에서 두 노드 간 제어의 이동으로 테스트 대상에서 소스 코드 구문의 실행 가능 순서를 보여줌.
  • 목적: 코드의 분기를 실행하는 테스트 케이스를 설계해서 허용할 수 있는 수준의 커버리지를 달성하는 것.
• 분기 커버리지
  • 100% 분기 커버리지: 모든 분기(무조건 및 조건 분기)를 실행했다는 것을 의미
  • 분기 커버리지는 구문 커버리지를 포함. 즉, 100% 분기 커버리지를 달성하는 테스트 케이스 집합은 100% 구문 커버리지도 달성하지만, 그 반대의 경우는 성립하지 않음.
  • 모든 결함을 식별할 수 있는 것은 아님.
  • 커버리지 계산: (테스트 케이스가 실행한 분기 수 / 전체 분기 수) x 100%

3-3. 화이트박스 테스팅의 가치

• 장점
  • 전체 소프트웨어 구현을 고려하여, 명세가 불완전한 경우에도 결함을 쉽게 감지할 수 있음
• 단점
  • 소프트웨어가 요구사항을 구현하지 않는 경우, 그 누락을 식별하지 못할 수도 있음
• 적용
  • 정적테스팅에도 사용할 수 있으며, 슈도 코드나 제어 흐름 그래프 등의 논리 검토에 적합
  • 커버리지 측정:
    • 블랙박스 테스팅만으로는 실제 코드 커버리지 측정을 얻을 수 없으며,
    • 화이트박스 커버리지 측적은 객관적인 커버리지 값을 제공

4. 경험 기반 테스트 기법

4-1. 오류 추정

: 테스터 지식을 기반으로 오류, 결함, 장애 발생을 예측하는 기법

• 테스터의 지식에 포함되는 요소
  • 애플리케이션의 과거 동작
  • 개발자가 범하기 쉬운 오류 유형
  • 유사 애플리케이션에서 발생한 장애 유형
• 오류, 결함, 장애와 관련된 요소
  • 입력: 올바른 입력을 인식하지 못함, 매개변수 오류 또는 누락
  • 출력: 잘못된 형식, 잘못된 결과
  • 논리: 사례 누락, 잘못된 연산자
  • 계산: 잘못된 피연산자, 잘못된 계산
  • 인터페이스: 매개변수 불일치, 호환되지 않는 유형
  • 데이터: 잘못된 초기화, 잘못된 유형
• 결함 공격
  • 오류 추정을 체계적으로 구현한 접근법
  • 테스터가 예상 가능한 오류, 결함, 장애 목록을 작성하거나 획득하여 
  • 오류와 관련된 결함을 식별하고 노출하거나 장애를 유발하는 테스트를 설계
  • 이러한 목록은 다음을 기반으로 작성할 수 있음
    • 결함
    • 결함 및 장애 데이터
    • 소프트웨어에 문제가 생기는 원인에 관한 일반적인 지식

4-2. 탐색적 테스팅

: 테스터가 테스트 대사에 대해 학습하면서 테스트의 설계, 실행, 평가를 동시에 수행하는 기법

• 이 기법은 테스트 대상에 대한 이해를 깊게 하고, 테스트되지 않은 영역을 탐색하는 데 사용됨
• 세션 기반 테스팅: 탐색적 테스팅을 체계적으로 수행하기 위해 사용
  • 테스트 차터: 테스터는 정의된 테스트 목적을 갖춘 차터(charter)를 사용하여 테스트를 수행
  • 테스트 세션: 정해진 시간 동안 집중적으로 테스트를 수행하며, 세션 종료 후 결과를 보고하고 이해관계자와 논의
  • 테스트 목적: 상위 수준의 테스트 조건으로 취급되며, 커버리지 항목을 세션 중에 식별 및 실행됨
  • 기록: 테스터는 수행 절차와 발견 내용을 기록하기 위해 테스트 세션 시트를 사용할 수 있음
• 다음과 같은 상황에서 유용함
  • 명세가 부족하거나 부적합할 경우
  • 테스트에 시간적 압박이 심할 경우
  • 공식 테스트 기법을 보완할 경우
• 탐색적 테스팅은 테스터가 품부한 경험과 도메인 지식을 가지고 있으며, 높은 수준의 분석 기술, 호기심, 창의성을 갖춘 경우 더욱 효과적이다.

4-3. 체크리스트 기반 테스팅

: 테스터가 체크리스트를 활용해 테스트 컨디션을 확인하는 테스트를 설계, 구현, 실행하는 기법

• 체크리스트는 경험, 사용자에게 중요한 사항, 또는 소프트웨어 실패 원인과 방법에 대한 이해를 바탕으로 작성될 수 있음.
• 체크리스트 기반 테스팅의 특징
  • 자동으로 점검할 수 있는 항목, 시작/ 종료 조건에 더 적합한 항목, 너무 일반적인 항목은 체크리스트에 포함해서는 안됨
  • 체크리스트 항목은 질문 형식으로 표현되며, 각 항목은 개별적이고 직접적으로 확인할 수 있어야 함
  • 요구사항, 그래픽 인터페이스 속성, 품질 특성 또는 기타 유형의 테스트 컨디션이 포함될 수 있음
  • 체크리스트는 기능 및 비기능 테스트를 포함한 다양한 테스트 유형을 지원하기 위해 작성될 수 있음
• 유지 및 업데이터
  • 시간이 지남에 따라 개발자가 같은 오류를 반복하지 않게 되므로, 일부 체크리스크 항목의 효과가 떨어질 수 있음
  • 새로 발견된 심각도가 높은 결함으로 인해 새로운 항목을 추가해야 할 수도 있음
  • 체크리스트는 결함 분석을 기반으로 정기적으로 업데이트 해야하지만, 너무 길어지지 않도록 주의해야 함
• 유용성
  • 구체적인 테스트 케이스가 없는 경우, 체크리스트 기반 테스팅은 테스트를 위한 지침과 일정 수준의 일관성을 제공할 수 있음
  • 체크리스트가 상위 수준으로 작성된 경우, 실제 테스트는 조금씩 달라질 수 있으며 결과적으로 커버리지는 높아지지만 재현 가능성은 떨어질 수 있음

5. 협업 기반 테스트 접근법

5-1. 협업 기반 사용자 스토리 작성

• 사용자 스토리는 시스템이나 소프트웨어의 사용자 또는 구매자에게 가치를 제공하는 기능을 나타냄
• 3C 구성 요소
  • 카드(Card): 사용자 스토리를 설명하는 매체(예: 인덱스 카드, 전자 게시판 항목)
  • 대화(Conversation): 소프트웨어 사용 방법에 대한 설명
  • 확인(Confirmation): 인수 조건
• 형식: [역할]로서 [목표]를 달성해 [역할이 얻게 될 비즈니스 가치]를 얻기를 원한다.  + 이후 인수 조건이 뒤따름
• 협업 방법: 브레인스토밍, 마인드 매핑 등을 사용하여 비즈니스, 개발, 테스팅의 세 가지 관전을 고려해 공유된 비전을 얻음
• 좋은 사용자 스토리의 특성
  • 독립적 (Independent), 협상 가능 (Negotiable), 가치 있음 (Valuable), 추정 가능 (Estimable), 작음 (Small), 테스트 가능 (Testable)
• 주의사항
  • 사용자 스토리가 명확하지 않거나 중요한 내용을 반영하지 않는다면, 이해관계자가 테스트 방법을 모르거나 도움이 필요할 수 있음.

5-2. 인수 조건

: 사용자 스토리 구현 결과를 이해관계자가 승인하기 위해 충족되어야 하는 조건

• 결정 방법
  • 인수 조건은 보통 3C 중 대화를 통해 결정됨
• 사용 목적
  • 사용자 스토리 범위 정의
  • 이해관계자 간 합의 도출
  • 긍정과 부정 시나리오 설명
  • 사용자 스토리 인수 테스팅의 베이시스 제공
  • 정확한 계획 및 추정
• 작성 방법: 다양한 사용자 스토리의 인수 조건 작성법이 있으며, 가장 일반적인 두가지 방법은 아래와 같음
  • 시나리오 기반: 행위 주도 개발에서 사용하는 Given / When / Then 형식
  • 규칙 기반: 베리피케이션이 필요한 목록 또는 표로 표현된 입력-출력 매핑

5-3. 인수 테스트 주도 개발(ATTD)

: 인수 테스트 주도 개발은 테스트 우선 접근법으로, 테스트 케이스는 사용자 스토리 구현 전에 작성됨.

• 참여자: 고객, 개발자, 테스터 등 다양한 관점을 가진 팀원들이 테스트 케이스를 만듦
• 과정
  • 명세 워크숍
    • 팀원들이 사용자 스토리와 인수 조건을 분석하고 토론하여 작성
    • 사용자 스토리의 불완전성, 모호성, 결함을 해결
  • 테스트 케이스 작성
    • 팀 전체가 수행하거나 테스터가 개별적으로 수행할 수 있음
    • 테스트 케이스는 인수 조건을 기반으로 하며, 소프트웨어의 작동 방식에 대한 예제로 볼 수 있음
  • 테스트 설계
    • 긍정 / 유효 테스트 케이스: 예외나 오류 조건 없이 올바른 동작을 확인
    • 비유효 / 부정 테스트 케이스: 예외나 오류 조건을 포함
    • 비기능 품질 특성 테스트: 성능 효율성, 사용성 등을 다룸
  • 특징
    • 테스트 케이스는 이해관계자가 이해할 수 있는 방식으로 표현되어야 함.
    • 필요한 전제 조건, 입력값, 사후 조건 등을 포함하여 자연어 문장으로 작설ㅇ
    • 테스트 케이스는 사용자 스토리의 모든 특성을 다루며, 스토리를 벗어나지 않아야 함
    • 두 개 이상의 테스트 케이스가 같은 특성을 설명해서는 안됨.
  • 자동화
    • 테스트 자동화 프레임워크가 지원하는 형식으로 작성하면, 개발자는 필요한 코드를 작성하여 테스트 케이스를 자동화할 수 있음. 
    • 인수 테스트는 실행 가능한 요구사항이 됨.