[ISTQB CFTL 2018]4. 테스트 기법

Q) 체크리스트 기반 테스팅(Checklist-based Testing)이란?

A. 과거 장애에 대한 테스터의 지식이나 장애 모드에 대한 일반적 지식에 기반해 테스트를 도출하는 기법

B. 내부 구조는 참조하지 않고 컴포넌트나 시스템의 기능 및 비기능 명세를 분석해 테스트 케이스를 도출하고 선택하는 절차

C. 숙련된 테스터가 제품 검증을 위한 일련의 규칙이나 기준, 또는 참고/확인/기억해야 하는 상위수준 아이템 목록을 사용하는 경험 기반 기법 (정답)

D. 테스터가 자신의 지식, 테스트 항목의 탐구, 이전 테스트 결과를 기반으로 한 테스트를 적극적으로 설계하고 실행하는 테스팅 접근법

Q) 다음 중 탐색적 테스팅을 가장 잘 설명한 것은?

A. 테스트 대상의 배경에 대한 심층적인 조사를 통해 테스트 케이스로 확인된 잠재적인 약점을 식별하는 테스트 방법

B. 테스터가 테스트를 수행할 때 테스트 설계를 적극적으로 제어하고 새롭고 더 나은 테스트 설계를 위해 테스트하는 동안 얻은 정보를 사용하는 비공식적인 테스트 설계 기법 (정답)

C. 테스트 활동이 테스트 분석 및 설계의 중단되지 않는 세션으로 계획되는 테스트 설계 접근법으로, 체크리스트 기반 테스팅과 함께 사용되는 경우가 많음

D. 테스터의 경험과 지식, 직관에 기반한 테스팅

4.1 테스트 기법의 종류

FL-4.1.1 (K2) 블랙박스 테스트 기법, 화이트박스 테스트 기법, 경험 기반 테스트 기법의 특성과 공통점 및 차이점을 설명할 수 있다.

Q) 다음 중 블랙-박스 테스트 기법으로 분류할 수 있는 것은?

A. 아키텍처 분석에 기반한 기법들

B. 기술적 설계에 따라 테스트 대상의 동작을 확인하는 기법들

C. 소프트웨어의 예상 사용법에 기반한 기법들

D. 공식 요구사항에 기반한 기법들 (정답)

Q) 다음 중 테스트 기법과 그 설명을 올바르게 연결한 것은?

1. 테스트 대상의 선택된 구조에 기반하여 커버리지 측정

2. 테스트 대상 내부의 절차 확인

3. 일어날 가능성이 있는 결함과 그 분포를 기반으로 테스트

4. 요구사항과의 차이를 확인

5. 사용자 스토리를 테스트 베이시스로 사용

블랙박스 - 블랙박스 테스트 기법

화이트박스 - 화이트박스 테스트 기법

경험 - 경험 기반 테스트 기법

A. 블랙박스 – 4, 5 화이트박스 – 1, 2 경험 – 3 (정답)

B. 블랙박스 – 3 화이트박스 – 1, 2 경험 – 4, 5

C. 블랙박스 – 4 화이트박스 – 1, 2 경험 – 3, 5

D. 블랙박스 – 1, 3, 5 화이트박스 – 2 경험 – 4

이번 장은 테스트 기법을 설명한다. 테스트 기법의 목적은 테스트 컨디션, 테스트 케이스, 테스트 데이터 식별을 지원하는 것이다.

4.1.1 테스트 기법 선택

테스트 기법의 선택은 다음과 같은 여러 요소를 기반으로 이루어진다.

• 컴포넌트나 시스템의 유형
• 컴포넌트나 시스템의 복잡도
• 규제 기준
• 고객 또는 계약 요구사항
• 리스크 수준
• 리스크 유형
• 테스트 목적
• 사용 가능한 문서
• 테스터의 지식과 역량
• 사용 가능한 도구
• 시간과 예산
• 소프트웨어 개발 수명주기 모델
• 예상되는 소프트웨어 사용 목적 
• 테스트 대상 컴포넌트 또는 시스템에 테스트 기법을 사용한 과거 경험
• 컴포넌트나 시스템에서 예상되는 결함 유형

일부 기법은 특정 상황과 테스트 레벨에 더 적합한 반면, 모든 테스트 레벨에 적합한 기법도 있다. 테스트 케이스를 작성할 때 테스터는 일반적으로 테스트 노력 대비 가장 좋은 결과를 얻기 위해 다양한 테스트 기법을 조합해서 사용한다.

테스트 분석, 테스트 설계, 테스트 구현 활동에서 테스트 기법의 사용은 매우 비공식적인 형식(거의 또는 전혀 문서화하지 않음)부터 매우 공식적인 형식까지 다양할 수 있다. 적절한 수준의 공식성은 테스트 및 개발 프로세스의 성숙도, 시간적인 제한, 안전 또는 규정 요구사항, 관련된 사람들의 지식과 역량, 준수해야 하는 소프트웨어 개발 수명주기 모델을 포함하는 테스팅의 정황에 따라 결정된다.

4.1.2 테스트 기법의 종류와 특성

이 실러버스에서는 테스트 기법을 블랙박스, 화이트박스, 경험 기반으로 분류한다.
블랙박스 테스트 기법(행위 기법 또는 행위 기반 기법이라고도 함)은 적절한 테스트 베이시스(예: 공식 요구사항 문서, 명세서, 유스케이스, 사용자 스토리 또는 비즈니스 프로세스)에 대한 분석을 기반으로 한다. 이 기법은 기능 테스팅과 비기능 테스팅 모두에 적용할 수 있다. 블랙박스 기법은 테스트 대상의 내부 구조를 고려하지 않고, 입력과 출력에 집중한다.
화이트박스 테스트 기법(구조 기법 또는 구조 기반 기법이라고도 함)은 아키텍처, 세부 설계, 내부 구조, 테스트 대상의 코드에 대한 분석을 기반으로 한다. 블랙박스 기법과는 달리, 화이트박스 기법은 테스트 대상의 내부 구조와 처리에 집중한다.
경험 기반 테스트 기법은 개발자, 테스터, 사용자의 경험을 활용하여 테스트를 설계, 구현, 실행한다. 이 기법은 블랙박스 및 화이트박스 테스트 기법과 결합해서 사용하는 경우가 많다.

블랙박스 테스트 기법의 일반적인 특징은 다음과 같다:

• 테스트 컨디션, 테스트 케이스, 테스트 데이터는 소프트웨어 요구사항, 명세서, 유스케이스, 사용자 스토리와 같은 테스트 베이시스로부터 도출한다.
• 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용한다.
• 커버리지는 테스트 베이시스에서 테스트된 항목과 테스트 베이시스에 적용한 기법을 기반으로 측정한다.

화이트박스 테스트 기법의 일반적인 특성은 다음과 같다:

• 테스트 컨디션, 테스트 케이스, 테스트 데이터는 코드, 소프트웨어 아키텍처, 상세 설계 또는 소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 도출한다.
• 커버리지는 대상 구조(예: 코드나 인터페이스)에서 테스트한 항목을 기준으로 측정한다.
• 명세서는 테스트 케이스의 기대 결과 판별을 위한 추가 정보로 사용되는 경우가 많다.

경험 기반 테스트 기법의 일반적인 특징은 다음과 같다:

• 테스트 컨디션, 테스트 케이스, 테스트 데이터는 테스터, 개발자, 사용자, 기타 이해관계자의 지식과 경험과 같은 테스트 베이시스로부터 도출한다.

지식과 경험은 소프트웨어의 예상 동작과 사용 환경, 발생 가능성이 있는 결함과 분포 등을 포함한다.

4.2 블랙박스 테스트 기법

FL-4.2.1 (K3) 주어진 요구사항에 동등 분할을 적용해서 테스트 케이스를 도출할 수 있다.

Q) 직원의 보너스를 계산하는 소프트웨어가 있다. 보너스는 음수(negative)는 될 수 없지만 0은 될 수 있다. 보너스는 근무 기간에 따라 산정한다. 
산정 기준은 근무 연한에 따라 2년 이하, 2년 초과 ~ 5년 미만, 5년 이상 ~ 10년 미만, 10년 이상으로 구분돼 있다. 
보너스를 계산하기 위해 모든 유효 동등 파티션(valid equivalence partitions)을 커버하는 최소 테스트 케이스 수는 몇 개 인가?

A. 3

B. 5

C. 2

D. 4 (정답)

Q) 다음은 비디오 애플리케이션의 요구사항이다:

이 애플리케이션은 다음과 같은 화면 사이즈에 따라 비디오를 재생한다:

1. 640x480

2. 1280x720

3. 1600x1200

4. 1920x1080

다음 중 이 요구사항을 테스트하기 위해 동등분할 테스트 기법을 적용해 도출한 테스트 케이스 목록은 무엇인가?

A. 애플리케이션이 1920x1080의 화면 사이즈로 비디오를 재생할 수 있는지 확인한다 (테스트 케이스 1개).

B. 애플리케이션이 640x480과 1920x1080의 화면 사이즈로 비디오를 재생할 수 있는지 확인한다 (테스트 케이스 2개).

C. 애플리케이션이 요구사항에 있는 각각의 화면 사이즈로 비디오를 재생할 수 있는지 확인한다 (테스트 케이스 4개). (정답)

D. 애플리케이션이 요구사항에 있는 화면 사이즈 중 하나로 비디오를 재생할 수 있는지 확인한다 (테스트 케이스 1개).

Q) 사용자의 건강 유지를 위해 매일의 걸음 수를 측정해 피드백을 제공하는 피트니스 앱이 있다.

걸음 수에 따른 피드백 메시지는 다음과 같다:

1000 이하 - 카우치 포테이토(Couch Potato)!

1000 초과 ~ 2000 이하 - 게으름뱅이(Lazy Bones)!

2000 초과 ~ 4000 이하 - 거의 도달(Getting There)!

4000 초과 ~ 6000 이하 - 괜찮아요(Not Bad)!

6000 초과 - 잘하고 있어요(Way to Go)!

다음 중 동등 분할 커버리지가 가장 높은 테스트 입력값의 묶음은?

A. 0, 1000, 2000, 3000, 4000

B. 1000, 2001, 4000, 4001, 6000

C. 123, 2345, 3456, 4567, 5678

D. 666, 999, 2222, 5555, 6666 (정답)

Q) 식물용 일별 일조량 기록기(daily radiation recorder for plants)는 식물이 태양에 노출된 시간의 합에 따라 일조량 점수(3시간 미만, 3시간 이상 6시간 미만, 6시간 이상)와 평균 태양열 강도(아주 낮음, 낮음, 중간, 높음)를 산출한다.

다음과 같은 테스트 케이스가 있다:

         노출시간 열강도      점수

T1      1.5         아주 낮음  10

T2      7.0         중간         60

T3      0.5         아주 낮음  10

유효한 동등 분할 입력값을 모두 커버하기 위해 추가해야 하는 최소의 테스트 케이스는 몇 개인가?

A. 1

B. 2 (정답)

C. 3

D. 4

FL-4.2.2 (K3) 주어진 요구사항에 경계값 분석을 적용해서 테스트 케이스를 도출할 수 있다.

Q) 속도 제어 및 알림 시스템이 다음과 같이 동작한다:

- 50 km/h 이하로 주행 시 아무 것도 하지 않음

- 50 km/h 초과, 55 km/h 이하로 주행 시 경고를 보냄

- 55 km/h 초과, 60 km/h 이하로 주행 시 벌금이 부과됨

- 60 km/h 초과로 주행 시 운전 면허가 중지됨

다음 중 2-포인트 경계값(two-point boundary value) 분석으로 테스트 데이터 식별 시 가장 적절한 값(km/h)은?

A. 0, 49, 50, 54, 59, 60

B. 50, 55, 60

C. 49, 50, 54, 55, 60, 62

D. 50, 51, 55, 56, 60, 61 (정답)

Q) 스마트 홈 앱은 이전 주의 집안 평균 기온을 측정하고 이를 기반으로 환경 친화적인 관점에서 거주자에게 피드백을 제공한다.

다양한 기온 범위에 대한 피드백은 다음과 같다:

~10°C - 매우 추움

11°C ~ 15°C - 서늘함

16°C ~ 19°C - 쾌적함

20°C ~ 22°C - 따뜻함

22°C ~ - 너무 더움

2-포인트 경계값 분석(two-point BVA)을 이용할 때, 경계값 분석 커버리지가 가장 큰 테스트 입력값의 집합은?

A. 0°C, 11°C, 20°C, 22°C, 23°C

B. 9°C, 15°C, 19°C, 23°C, 100°C

C. 10°C, 16°C, 19°C, 22°C, 23°C (정답)

D. 14°C, 15°C, 18°C, 19°C, 21°C, 22°C

FL-4.2.3 (K3) 주어진 요구사항에 결정 테이블 테스팅을 적용해서 테스트 케이스를 도출할 수 있다.

Q) 1년 이상 근무한 직원들에게 합의한 개별 성과목표 달성에 따라 보너스를 지급하는 회사가 있다.

보너스 지급 논리를 테스트하기 위해 다음과 같은 결정 테이블을 설계했다:

위의 테스트 케이스 중 실제 일어날 수 없는 경우로 결정 테이블에서 삭제해도 되는 것은?

A. T1, T2

B. T3, T4

C. T7, T8

D. T5, T6 (정답)

Q) 속도위반 벌금 시스템에 대한 결정 테이블 테스팅을 수행하고 있다. 규칙 1, 4를 테스트하는 2개의 테스트 케이스를 아래와 같이 작성했다:

추가 테스트 케이스가 아래와 같다면:

규칙 1, 4에 대해 이미 작성한 테스트 케이스와 합쳐 100% 결정 테이블 테스팅 커버리지를 달성하는 추가 테스트 케이스 2개는 무엇인가?

A. DT1, DT2

B. DT2, DT3

C. DT2, DT4 (정답)

D. DT3, DT4

FL-4.2.4 (K3) 주어진 요구사항에 상태 전이 테스팅을 적용해서 테스트 케이스를 도출할 수 있다.

Q) 아래에 주어진 상태 전이 다이어그램과 테스트 케이스에 대한 설명 중 옳은 것은?

 

A. 위 테스트 케이스는 상태 전이 다이어그램의 유효 및 비유효 전이를 모두 커버하는 데 사용할 수 있다.

B. 위 테스트 케이스는 상태 전이 다이어그램의 모든 가능한 유효 전이를 표현하고 있다. (정답)

C. 위 테스트 케이스는 상태 전이 다이어그램의 유효 전이 중 몇 가지만 표현하고 있다.

D. 위 테스트 케이스는 상태 전이 다이어그램의 전이를 일어날 순서대로 표현하고 있다.

Q) 다음은 배터리 충전 소프트웨어의 상태 전이 모델이다:

다음 중 이 상태 모델의 가장 높은 전이 커버리지를 제공하는 전이 순서는?

A. 방전→ 대기 → 방전 → 대기 → 미세전류 충전 → 충전 → 높음 → 충전 → 낮음

B. 대기 → 미세전류 충전 → 대기 → 방전 → 대기 → 미세전류 충전 → 충전 → 낮음 → 충전

C. 높음 → 충전 → 낮음 → 충전 → 미세전류 충전 → 대기 → 미세전류 충전 → 대기 → 미세전류 충전 → 충전

D. 대기 → 미세전류 충전 → 충전 → 높음 → 충전 → 미세전류 충전 → 대기 → 방전 → 대기 (정답)

FL-4.2.5 (K2) 유스케이스에서 테스트 케이스를 도출하는 방법을 설명할 수 있다.

Q) 다음 중 유스케이스에서 테스트 케이스를 도출하는 방법을 가장 잘 설명한 것은?

A. 테스트 케이스는 관련자들(actors)과 협력해 테스트 중인 시스템이 수행하는 명시된 기본, 예외 및 에러 동작의 실행을 위해 생성한다. (정답)

B. 테스트 케이스는 유스케이스에 들어 있는 컴포넌트를 식별하고 이런 컴포넌트들의 상호작용을 수행하는 통합 테스트를 생성함으로써 도출한다.

C. 테스트 케이스는 사용자 인터페이스가 사용하기 쉽게 하기 위해 시스템과 관련자들(actors) 간의 상호작용을 분석하여 생성한다.

D. 테스트 케이스는 유스케이스의 비즈니스 프로세스 흐름에서 각각의 결정 포인트를 수행하고 이런 흐름의 100% 결정 커버리지를 달성하기 위해 도출한다.

4.2.1 동등 분할 (Equivalence Partitioning)

동등 분할은 특정 파티션(partitions)의 모든 변수는 동일한 방식으로 처리된다는 가정으로 파티션에 데이터를 분할한다. 유효한 값과 비유효한 값 모두에 대해 동등 분할을 구성할 수 있다.

• 유효값(valid values)이란 컴포넌트나 시스템에 입력되는 값이다. 유효한 값을 포함하는 동등한 파티션을 “유효 동등 분할”이라고 한다.
• 비유효값(invalid values)이란 컴포넌트나 시스템이 거부하는 값이다. 유효하지 않은 값을 포함하는 동등한 파티션을 “비유효 동등 분할”이라고 한다. 
• 분할은 입력값, 출력값, 내부값, 시간관련값(예: 이벤트 전 또는 후), 인터페이스 매개변수(예: 통합 테스팅에서 테스트하는 통합 컴포넌트)를 포함하여 테스트 대상과 관련된 모든 데이터 요소에 대해 식별할 수 있다.
• 필요한 경우 모든 파티션은 하위 파티션으로(subpartitions) 나눌 수 있다.
• 모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야 한다.
• 비유효 동등 분할을 테스트 케이스로 만들 때는 장애가 마스크(masked) 즉, 가려지는 것을 방지하기 위해 개별적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야 한다. 동시에 여러 장애가 발생할 때 겉으로 드러나는 하나의 장애 때문에 나머지가 인식되지 않아 장애가 가려지는 경우가 발생한다. 

동등 분할 기법으로 100% 커버리지를 달성하기 위해서는 식별한 모든 분할(비유효 분할 포함)의 각 분할에서 최소 한 개의 값을 사용해 테스트 케이스를 작성해야 한다. 동등 분할 커버리지는 일반적으로 백분율로 표기하며, 최소한 한 개의 값으로 테스트한 동등 분할 수를 식별한 모든 동등 분할의 수로 나눠서 계산한다. 동등 분할은 모든 테스트 레벨에 적용할 수 있다.

4.2.2 경계값 분석 (Boundary Value Analysis)

경계값 분석(BVA)은 동등 분할의 확장 형태이지만 각 파티션이 순서화되어 있고, 숫자 또는 연속 데이터로 구성된 경우에만 적용할 수 있다. 분할의 최소값과 최대값(또는 첫 번째값과 마지막값)은 해당 분할의 경계값이 된다.

예를 들어, 특정 입력 필드가 한 자리 정수값만 입력으로 받아들이고 정수가 아닌 값의 입력은 막기 위해 입력 방법을 키패드(keypad)로 제한한다고 가정해보자. 유효 범위는 1 이상 5 이하이다. 따라서 3개의 동등 분할이 존재한다: 비유효(너무 낮음); 유효; 비유효(너무 높음). 유효 동등 분할의 경계값은 1과 5이다. 비유효(너무 높음) 분할의 경계값은 6과 9이다. 비유효(너무 낮음) 분할은 변수가 하나뿐인 파티션으로 유일한 값 0이 경계값이 된다.

위의 예제에서는 각 경계에 대해 두 개의 값을 식별했다. 비유효(너무 낮음)와 유효 사이의 경계에 대해서는 테스트 값 0, 1을, 유효와 비유효(너무 높음) 사이의 경계에 대해서는 테스트 값 5, 6을 선택했다. 이 기법의 여러 유형 중에는 경계당 세 개의 경계값을 식별하는 것도 있다: 경계 직전 값, 경계에 해당하는 값, 경계 직후의 값. 경계값을 세 개 선택하는 경우로 앞에 주어진 예제를 살펴보면, 낮은 쪽 경계에 해당하는 테스트 값은 0, 1, 2가 되고 높은 쪽 경계에 해당하는 테스트 값은 4, 5, 6이 된다.

동등 분할의 경계에서 동작이 잘못될 확률이 동등 분할 중간의 값에서 잘못될 확률에 비해 높다. 명시된 경계값과 구현한 경계값 모두 의도했던 값보다 높거나 낮게 설정되거나, 모두 생략하거나 의도하지 않았던 경계값이 추가되었을 수 있다는 사실을 기억하는 것이 중요하다. 경계값 분석과 테스팅을 통해 소프트웨어가 경계값이 원래 속한 분할의 동작이 아닌 다른 분할의 동작을 수행하는 것과 같은 종류의 결함 대부분을 식별할 수 있다.

경계값 분석은 모든 테스트 레벨에 적용할 수 있다. 이 기법은 일반적으로 숫자의 범위(날짜, 시간 포함)와 연관된 요구사항을 테스트하는 데 적용된다. 경계값 분석 커버리지는 보통 백분율로 표기하며, 테스트한 경계값의 수를 식별한 모든 경계값의 수로 나눠서 계산한다.

4.2.3 결정 테이블 테스팅 (Decision Table Testing)

조합 테스트(Combinatorial test) 기법은 다양한 조건 조합이 서로 다른 결과를 도출한다고 명시하는 시스템 요구사항의 구현을 테스팅하는 데 유용하다. 이러한 테스팅에 대한 한 가지 접근법이 결정 테이블 테스팅이다.
결정 테이블은 시스템이 구현해야 하는 복잡한 비즈니스 규칙을 기록하기에 좋은 방법이다. 결정 테이블을 작성할 때 테스터는 시스템의 조건(주로 입력)과 예상 동작(주로 출력)을 식별한다. 이것들은 테이블의 행(rows)을 형성하며 일반적으로 조건은 위쪽에, 기대 결과는 아래쪽에 둔다. 각 열(column)은 하나의 결정 규칙으로 특정 조건의 고유한 조합과 연관된 기대 결과로 정의한다. 조건과 기대 결과의 값은 일반적으로 참 또는 거짓으로 표기하거나, 빨간색, 녹색, 파란색 등과 같은 비연속 값으로 표기하지만 숫자나 숫자 범위로 표기하는 경우도 있다. 이러한 여러 가지 유형의 조건과 기대 결과를 하나의 결정 테이블에 표기하는 경우도 있다.

결정 테이블의 일반적인 표기법은 다음과 같다.
조건:

• Y, 조건이 참이라는 것을 의미 (T 또는 1 로 표기할 수 있음)
• N, 조건이 거짓이라는 것을 의미 (F 또는 0 으로도 표기할 수 있음) 
• —, 조건의 값이 중요하지 않다는 것을 의미 (N/A 로 표기할 수 있음) 

기대 결과:

• X, 행동이 일어난다는 것을 의미 (Y, T, 1 로 표기할 수 있음) 
• 공백(blank), 행동이 일어나지 않음을 의미 (—, N, F, 0 으로 표기할 수 있음) 

전체 결정 테이블은 모든 조건 조합을 다루기에 충분한 행 수를 가지게 된다. 불가능한 조건 조합이 포함된 행, 가능은 하지만 실행할 수 없는 조건 조합이 포함된 행, 결과에 영향을 주지 않는 조건 조합을 테스트하는 행을 삭제하여 테이블을 축소할 수 있다.
결정 테이블 테스팅에서 일반적인 최소 커버리지 기준은 테이블의 결정 규칙당 최소 한 개의 테스트 케이스를 작성하는 것이다. 이것은 일반적으로 모든 조건 조합을 포함한다. 커버리지는 일반적으로 백분율로 표기하며, 최소 한 개의 테스트 케이스로 테스트한 결정 규칙의 수를 식별한 모든 결정 규칙의 수로 나눠서 계산한다.
결정 테이블 테스팅의 장점은 중요한 모든 조건 조합을 식별하는 데 도움이 된다는 것이다. 그 중에는 결정 테이블을 사용하지 않았으면 간과했을 수 있는 조합도 있을 수 있다. 또한, 요구사항의 누락된 부분을 찾는 데 도움이 된다. 이는 소프트웨어의 동작이 조건 조합에 영향을 받는 모든 상황에 적용 가능하며, 모든 테스트 레벨에 적용할 수 있다.

4.2.4 상태 전이 테스팅 (State Transition Testing)

컴포넌트나 시스템은 현재 조건이나 기존 이력(예를 들어, 시스템이 초기화되고 난 후 발생한 이벤트)에 따라 이벤트에 대해 다르게 반응할 수 있다. 기존 이력은 상태라는 개념을 활용해서 요약할 수 있다. 상태 전이 다이어그램은 소프트웨어의 가능한 상태뿐만 아니라 소프트웨어가 상태 간에 어떻게 진입하고 빠져나오는지에 대한 전이 방법을 보여준다. 전이는 이벤트에 의해 시작된다 (예를 들어, 사용자가 입력 필드에 값을 입력). 이 이벤트는 전이라는 결과를 가져온다. 만약 하나의 이벤트에 의해 동일한 상태로부터 두 개 이상의 다른 전이가 발생한다면, 해당 이벤트는 가드 조건(guard condition)을 가지게 된다. 상태 변화로 소프트웨어가 특정 행동을 할 수도 있다 (예: 연산 결과 또는 오류 메시지 출력).
상태 전이 테이블은 상태 간의 모든 유효 전이와 잠재적인 비유효 전이뿐만 아니라, 유효 전이와 관련된 이벤트, 가드 조건, 결과 조치를 보여준다. 상태 전이 다이어그램은 일반적으로 유효한 전이만 보여주며, 비유효 전이는 표시하지 않는다.

테스트는 상태의 일반적인 순서를 커버하거나, 모든 상태를 실행하거나 모든 상태 전이를 실행하거나 특정한 상태 전이 순서를 실행하거나 또는 불가능한 상태 전이를 테스트하도록 설계할 수 있다.
상태 전이 테스팅은 메뉴 기반 애플리케이션에 사용하며, 임베디드 소프트웨어 업계에서 널리 사용하고 있다. 이 기법은 또한 구체적인 상태를 포함한 비즈니스 시나리오를 모델링하거나 화면 탐색을 테스팅하는 데 적합하다. 상태의 개념은 추상적이다. 이는 코드 몇 줄 또는 전체 비즈니스 프로세스를 나타낼 수도 있다.
커버리지는 일반적으로 백분율로 표기하며, 식별한 상태나 전이 중 테스트된 수를 식별한 모든 상태나 전이의 수로 나눠서 계산한다.

4.2.5 유스케이스 테스팅 (Use Case Testing)

유스케이스에서 테스트를 도출할 수 있다. 유스케이스는 소프트웨어 기능에 대한 요구사항을 통합하고 소프트웨어 항목 간의 상호작용을 설계하는 특정 방법이다. 유스케이스는 액터(actor, 즉 사용자, 외부 하드웨어, 기타 컴포넌트나 시스템)와 대상(유스케이스를 적용하는 컴포넌트나 시스템) 간의 관계이다.
각 유스케이스는 대상(subject)이 하나 이상의 액터와 협력하여 수행할 수 있는 동작들을 명시하고 있다. 유스케이스를 상호작용과 활동으로 설명하기도 하고, 적절한 경우 사전조건, 사후조건 및 자연어로 설명할 수도 있다. 액터와 대상 간의 상호작용으로 대상의 상태가 변경될 수 있다. 상호작용은 워크플로우, 활동 다이어그램, 비즈니스 프로세스 모델로 시각화할 수 있다.
유스케이스에는 예외 동작 및 오류 처리(시스템 응답과 프로그래밍, 애플리케이션 및 통신 오류로부터의 복구, 예를 들어, 오류 메시지 발생)를 포함한 기본 동작의 가능한 변형이 포함된다. 테스트는 정의한 동작(기본, 예외 또는 대안, 오류 처리)을 실행하도록 설계된다. 커버리지는 일반적으로 백분율로 표기하며, 테스트한 유스케이스 동작 수를 모든 유스케이스 동작 수로 나눠서 계산한다.

4.3 화이트박스 테스트 기법

FL-4.3.1 (K2) 구문 커버리지를 설명할 수 있다.

Q) 다음 중 구문 커버리지를 가장 잘 설명하고 있는 것은?

A. 실행한 테스트 케이스의 백분율을 계산하고 측정하는 데 사용하는 메트릭이다.

B. 소스코드에서 실행한 구문의 백분율을 계산하고 측정하는 데 사용하는 메트릭이다. (정답)

C. 성공한 테스트 케이스로 수행한 구문의 수를 계산하고 측정하는 데 사용하는 메트릭이다.

D. 모든 구문이 커버되었는지 참/거짓으로 판별하는 메트릭이다.

Q 27. 다음 구문 커버리지에 대한 설명 중 맞는 것은?

A. 구문 커버리지는 테스트로 수행한 소스 코드의 라인 수(주석 제외)를 측정한 것이다.

B. 구문 커버리지는 테스트로 수행한 소스 코드에서 실행 가능한 구문의 비율을 측정한 것이다. (정답)

C. 구문 커버리지는 테스트로 수행한 소스 코드 라인의 비율을 측정한 것이다.

D. 구문 커버리지는 테스트로 수행한 소스코드에서 실행 가능한 구문 수를 측정한 것이다.

FL-4.3.2 (K2) 결정 커버리지를 설명할 수 있다.

Q) 다음은 결정 커버리지에 대한 설명이다:

“ 코드에 하나의 ‘if’ 문만 있고 다른 루프나 CASE 문이 없는 경우, 하나의 테스트 케이스 수행 시 50%의 결정 커버리지를 달성할 수 있다.”

다음 설명 중 옳은 것은?

A. 위 문장은 옳다. 하나의 테스트 케이스로 100% 구문 커버리지를 달성할 수 있으므로 결정 커버리지는 50%이다.

B. 위 문장은 옳다. 하나의 테스트 케이스는 if 문의 참 또는 거짓 중 하나의 결과가 나올 것이다. (정답)

C. 위 문장은 틀렸다. 이 경우 하나의 테스트 케이스는 결정 커버리지 25%만 보장한다.

D. 위 문장은 틀렸다. 지나치게 광범위한 설명으로, 테스트하는 소프트웨어에 따라 참일 수도 있고 거짓일 수도 있다.

Q) 다음 중 결정 커버리지에 대한 설명으로 맞는 것은?

A. 결정 커버리지는 소스코드 내 가능한 경로 중 테스트로 실행한 비율을 측정한 것이다.

B. 결정 커버리지는 컴포넌트 내 비즈니스 흐름 중 테스트로 실행한 비율을 측정한 것이다.

C. 결정 커버리지는 코드 내 ‘if’ 문 중 참과 거짓 결과를 모두 실행한 비율을 측정한 것이다.

D. 결정 커버리지는 소스코드 내 결정문 결과 중 테스트로 실행한 비율을 측정한 것이다. (정답)

FL-4.3.3 (K2) 구문 및 결정 커버리지의 가치를 설명할 수 있다.

Q) 다음 중 구문 커버리지와 결정 커버리지의 관계를 올바르게 설명한 것 두 가지는?

A. 결정 커버리지가 구문 커버리지보다 더 강력하다. (정답)

B. 구문 커버리지가 결정 커버리지보다 더 강력하다.

C. 구문 커버리지가 100%면 결정 커버리지도 100%다.

D. 결정 커버리지가 100%면 구문 커버리지도 100%다. (정답)

E. 결정 커버리지는 절대 100%가 될 수 없다.

화이트박스 테스팅은 테스트 대상의 내부 구조를 기반으로 한다. 화이트박스 테스트 기법은 모든 테스트 레벨에서 적용할 수 있지만, 이 절에서 언급하고 있는 두 가지 코드 관련 기법은 단위 테스트 레벨에서 가장 일반적으로 사용된다. 안전 최우선, 임무 최우선, 높은 무결성 환경에서 더 높은 커버리지 달성을 위해 적용하는 고급 기법들도 있지만, 여기서는 다루지 않는다.

4.3.1 구문 테스팅과 커버리지 (Statement Testing and Coverage)

구문 테스팅은 코드의 실행 가능한 구문을 실행한다. 커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행한 구문의 수를 테스트 대상의 모든 실행 가능한 구문의 수로 나눠서 계산한다.

4.3.2 결정 테스팅과 커버리지 (Decision Testing and Coverage)

결정 테스팅은 코드에 존재하는 결정문을 실행하고 결정문의 결과에 따라 실행되는 코드를 테스트한다. 이것을 달성하기 위해 테스트 케이스는 결정문에서 시작되는 제어 흐름을 따라 실행된다 (예를 들어, IF문에서 결과가 참인 경우와 거짓인 경우; CASE문에서 기본 결과를 포함한 가능한 모든 결과를 필요로 하는 테스트 케이스).
커버리지는 일반적으로 백분율로 표기하며, 테스트로 실행된 결정문 결과의 수를 테스트 대상의 가능한 모든 결정문 결과의 수로 나눠서 계산한다.

4.3.3 구문 및 결정 테스팅의 가치

100% 구문 커버리지를 달성하면 코드에 존재하는 모든 실행 가능한 구문을 최소한 한 번씩은 테스트했다는 것을 의미하지만, 모든 결정 로직을 테스트했다는 것을 보장하지는 않는다. 이 실러버스에서 다루고 있는 두 가지 화이트박스 기법 중 구문 테스팅은 결정 테스팅보다 커버리지가 낮다.
100% 결정 커버리지를 달성하면 명확한 거짓 구문이 명시되지 않은 경우(예를 들어, IF문에 else문이 없는 경우)에도 결과가 참인 경우와 거짓인 경우를 포함한 모든 결정 결과가 실행되었다는 것을 의미한다. 구문 커버리지는 다른 테스트에 의해 실행되지 않은 코드의 결함을 찾는 데 도움이 된다. 결정 커버리지는 다른 테스트가 참과 거짓 결과 모두를 테스트하지 않은 코드의 결함을 찾는 데 도움이 된다. 100% 결정 커버리지는 100% 구문 커버리지를 보장하지만, 반대의 경우는 성립하지 않는다.

4.4 경험 기반 테스트 기법

FL-4.4.1 (K2) 오류 추정을 설명할 수 있다.

Q 29. 다음 중 오류 추정의 기본 개념을 가장 잘 설명한 것은?

A. 오류 추정을 위해서는 테스터가 테스트 대상의 사용자라고 가정하고 사용자가 테스트 대상과 상호작용하면서 할 수 있는 실수를 추정하는 것이다.

B. 오류 추정은 테스터의 개발 경험과 개발할 때 했던 실수를 활용하는 것이다.

C. 오류 추정은 테스터의 지식과 과거에 발견했던 결함에 대한 경험, 개발자들이 흔히 범하는 실수를 활용하는 것이다. (정답)

D. 오류 추정은 개발자들이 할 수 있는 실수를 식별하기 위해 테스터가 개발 작업을 빠르게 따라하는 것이다.

FL-4.4.2 (K2) 탐색적 테스팅을 설명할 수 있다.

Q) 다음 중 탐색적 테스팅을 사용하기에 적합한 상황이 아닌 것은?

A. 시간의 압박이 있으며, 요구사항이 완벽하지 못하거나 사용할 수 없다.

B. 시스템을 점진적으로 개발하고 테스트한다.

C. 신입이거나 경험이 없는 테스터만 있다. (정답)

D. 애플리케이션의 주요 부분을 고객 환경에서만 테스트할 수 있다.

FL-4.4.3 (K2) 체크리스트 기반 테스팅을 설명할 수 있다.

경험 기반 테스트 기법을 적용할 경우 테스트 케이스는 테스터의 기술 역량과 직관 그리고 유사한 애플리케이션과 기술에 대한 경험을 기반으로 도출한다. 이 기법은 체계적인 다른 기법으로는 쉽게 찾아내기 어려운 테스트를 식별하는 데 도움이 된다. 테스터의 접근 방식과 경험에 따라 이 기법으로 달성하는 커버리지와 효과성은 매우 다양하게 나타날 수 있다. 이 기법을 사용할 경우 커버리지를 평가하기 어려울 수 있으며 측정이 불가능할 수도 있다.

이번 절에서는 일반적으로 많이 적용되는 경험 기반 기법을 설명하고 있다.

4.4.1 오류 추정 (Error Guessing)

오류 추정은 다음을 포함한 테스터의 지식을 기반으로 실수, 결함 및 장애 발생을 예측하는 데 적용하는 기술이다:

• 애플리케이션의 과거 동작
• 개발자가 하는 실수 유형
• 다른 애플리케이션에서 발생한 장애

오류 추정 기법에 대한 체계적인 접근법은 발생 가능한 실수, 결함, 장애 목록을 작성하고 이런 장애와 그것의 원인이 되는 결함을 노출하는 테스트를 설계하는 것이다. 이러한 실수, 결함, 장애 목록은 경험, 결함 및 장애 데이터 또는 소프트웨어가 실패한 이유에 대한 일반적인 지식을 기반으로 작성할 수 있다.

4.4.2 탐색적 테스팅 (Exploratory Testing)

탐색적 테스팅에서는 비공식(사전에 정의되지 않은) 테스트를 테스트 실행 중에 동적으로 설계, 실행, 기록하고 평가한다. 테스트 결과는 컴포넌트나 시스템에 대해 더 많이 학습하고, 더 많은 테스트가 필요한 영역에 대한 테스트를 작성하는 데 활용된다.
탐색적 테스팅은 때로 세션 기반 테스팅을 사용하여 활동을 구성한다. 세션 기반 테스팅에서는 탐색적 테스팅을 정해진 시한(time-box)동안 수행하며, 테스터는 테스트 목적이 포함된 테스트 차터(test charter)를 활용해 테스팅 방향을 설정한다. 테스터는 테스트 세션 시트에 수행 단계와 발견 사항을 기록한다.
탐색적 테스팅은 명세가 충분하지 않거나 적은 경우 또는 테스팅에 상당한 시간적 압박이 있을 때 가장 유용하다. 또한, 탐색적 테스팅은 다른 보다 공식적인 테스팅 기법을 보완하는 데도 유용하다.
탐색적 테스팅은 반응적 테스트 전략과 밀접하게 관련되어 있다. 탐색적 테스팅은 다른 블랙박스, 화이트박스, 경험 기반 기법과 통합하여 사용할 수도 있다.

4.4.3 체크리스트 기반 테스팅 (Checklist-based Testing)

체크리스트 기반 테스팅에서는 체크리스트에 기록된 테스트 컨디션을 커버하기 위해 테스터가 테스트를 설계, 구현, 실행한다. 테스터는 분석의 일환으로 새로운 체크리스트를 작성하거나 기존 체크리스트를 확장할 수 있지만, 기존 체크리스트를 수정하지 않고 그대로 사용하는 경우도 있다. 체크리스트는 경험, 사용자에게 무엇이 중요한지에 대한 지식 또는 소프트웨어가 실패하는 이유와 방법에 대한 이해를 기반으로 작성할 수 있다.

체크리스트는 기능 및 비기능 테스팅을 포함한 다양한 테스트 유형을 지원하기 위해 작성할 수 있다. 구체적인 테스트 케이스가 없는 경우, 체크리스트 기반 테스팅은 대략적인 지침과 일관성을 제공할 수 있다. 이런 체크리스트는 상위 수준으로 작성되기 때문에 실제 테스팅에서 어느 정도의 가변성이 있기 마련이며, 따라서 커버리지는 늘어날 수 있지만 재현 가능성은 줄어들 수 있다.