[ISTQB] 제4장 테스트 기법 (1)

 

 

4.1 테스트 기법의 종류

 

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

​

분류

1. 블랙박스

2. 화이트박스

3. 경험 기반

​

1. 블랙박스 테스트 기법

- 기능 및 비기능 테스팅 모두에 적용 가능

- 내부 구조를 고려하지 않고, 입력과 출력에 집중

​

<특징>

- sw요구사항, 명세서, 유스케이스와 같은 테스트 베이시스로부터 테스트 컨디션/케이스/데이터를 도출

- 테스트 케이스는 요구사항과 요구사항 구현 결과물 간 차이와 편차를 식별하는 데 사용

- 커버리지는 테스트 베이시스에서 테스트된 항목과 적용한 기법을 기반으로 측정

 

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

- 테스트 대상의 내부 구조와 처리에 집중

 

<특징>

- 소프트웨어 구조와 관련된 기타 정보를 포함한 테스트 베이시스로부터 테스트 컨디션/케이스/데이터를 도출

- 커버리지는 선택한 구조 내에서 테스트한 항목과 테스트 베이시스에 적용된 기법을 기준으로 측정

​

​

3. 경험 기반 테스트 기법

- 경험을 활용하여 테스트를 설계, 구현, 실행함

- 블랙박스 및 화이트박스 테스트 기법과 결합해서 사용하는 경우가 많다

 

<특징>

- 이해관계자의 지식과 경험과 같은 테스트 베이시스로부터 테스트 컨디션/케이스/데이터를 도출

 

​

💡 테스트 컨디션

​ㄴ 테스트할 대상의 기능, 품질속성, 트랜잭션 등 테스트 설계에 필요한 대상 또는 조건을 의미 = 조건/상황 = 테스트베이스 ~.. 측면

 

💡 테스트 케이스의 내용이 상세할 수록

(장점)

ㄴ 테스트케이스 작성에 오랜 시간이 소요

ㄴ 테스트 실행 결과의 일관성이 유지됨 (누가 test하든 같은 결과가 나옴)

(단점)

ㄴ 살충제 패러독스에 걸리기 쉬움 (동일한 경로를 계속 실행하여 제한적일 수 있음)

ㄴ 테스트케이스의 업데이트, 유지보수가 어려움

ㄴ 효과적으로 결함을 발견할 수 없음 (살충제 패러독스/결과의 일관성 유지)

ㄴ 테스터가 지적능력을 활용하기 어려움 (상세하게 되어 있어서)

​

💡 CMMI

​ㄴ 개발 조직의 성숙도를 심사하는 모델

 

💡 요구사항 문서가 없는 경우, 기대결과를 대신할 수 있는 소스

ㄴ 테스터의 상식

ㄴ 개발팀이나 테스트 팀의 배경 지식과 경험

ㄴ 경쟁사 제품의 작동 결과

​

💡 테스트 설계 절차

ㄴ 테스트 조건을 식별/설계 -> 테스트케이스 명세화 -> 테스트 프로시저를 명세화

ㄴ 테스트 프로시저 : TC를 효율적으로 실행하기 위해 실행이 용이한 순서로 배치

​

💡 테스트케이스 명세에 '기대결과'가 정의돼 있지 않다면, 유사하지만 실제로는 틀린 결과가 올바른 것으로 판정 받을 수 있음

​

💡 네거티브 테스트

ㄴ 정상동작하지 않음을 보여주는 testing

​

💡 테스트 하네스

ㄴ 테스트 대상이 실행되는 환경을 시뮬레이션한다.

 

💡 테스트 드라이버

ㄴ 시스템 모듈을 호출하는 기능, 상향식(bottom-up) 테스트에서 사용

 

💡 테스트 스텁

ㄴ 시스템 모듈에 의해 호출되는 기능, 하향식(top-down) 테스트에서 사용

​

💡 테스트 용이성이 높은 요구사항은?

ㄴ 테스트 설계 및 실행이 가장 명확 -> 예) 홈페이지 접속시 응답 시간은 1초 이하여야 한다.

​

💡 블랙박스 테스트 (명세 기반)

ㄴ 종류 : 동등(등가) 분할, 경계값 분석, 상태 전이 테스트, 결정 테이블 테스팅, 유즈케이스 테스트

ㄴ 개발 초기 단계의 명세서 리뷰에 사용

ㄴ 주로 상위레벨 테스팅에 적용 (모든 레벨에서 적용 가능)

​

💡 화이트박스 테스트 (구조 기반)

ㄴ 종류 : 제어 흐름 테스팅, 구문 테스팅, 결정 테스팅

ㄴ 입력 값을 선택하는 기법과 같이 사용할 수도 있다.

ㄴ 상위레벨 테스팅에 적용될 수 있다. (모든 레벨에서 적용 가능)

​

---

4.2 블랙박스 테스트 기법

- 세부 내용 참고

명세기반 테스트 기법

 

4.1.2 동등 분할

동등 분할은, 특정 파티션의 모든 변수는 동일한 방식으로 처리된다는 가정으로 데이터를 분할한다.

​

유효한 값과 비유효한 값 모두에 대해 동등분할을 구성할 수 있다.

유효값이란, 컴포넌트나 시스템에 입력되는 값이다.

유효한 값을 포함하는 동등한 파티션을 “유효 동등 분할"이라고 한다.

비유효값이란 컴포넌트나 시스템이 거부하는 값이다.

유효하지 않은 값을 포함하는 동등한 파티션을 “비유효 동등 분할"이라고 한다.

​

모든 값은 동등 분할에 포함되어야 하며, 하나의 값은 하나의 동등 분할에만 속해야 한다.

​

비유효 동등 분할을 테스트 케이스로 만들 때는 장애가 마스크(가려지는 것)되는 것을 방지하기 위해 개별적으로 테스트해야 하며, 다른 비유효 동등 분할과 조합하지 않아야 한다.

​​

4.2.2 경계값 분석

경계값 분석은, 동등 분할의 확장 형태이지만 각 파티션이 순서화되어 있고, 숫자 또는 연속 데이터로 구성된 경우에만 적용할 수 있다.

​

분할의 최소값과 최대값은 해당 분할의 경계값이 된다.

​

예를들어, 특정 필드가 정수값만 입력으로 받아들이고 유효범위가 1~5일때 > 3개의 동등 분할이 존재한다.

유효 동등 분할의 경계값은 1, 5이다.

비유효 분할의 경계값은 6, 0이다.

비유효와 유효 사이의 경계에 대해서는 테스트 값 0,1과 5,6을 선택한다.

​

이 기법은 경계당 세 개의 경계값을 식별하는 것도 있다. 이 경우에는 0,1,2와 4,5,6을 선택하면 된다.

 

특징

- 동등 분할의 경계에서 동작이 잘못될 확률이 중간의 값에서 잘못될 확률에 비해 높다.

- 경계값 분석은 모든 테스트 레벨에 적용할 수 있다.

- 일반적으로 숫자의 범위와 연관된 요구사항을 테스트하는 데 적용된다.

 

4.2.3 결정 테이블 테스팅

결정 테이블은, 시스템이 구현해야 하는 복잡한 비즈니스 규칙을 기록하기에 좋은 방법이다.

​

특징

- 시스템의 조건(입력)과 예상 동작(출력)을 식별한다.

- 조건과 기대결과의 값은 참/거짓 , 빨간색/녹색/파란색 등과 같은 비연속 값으로 표기할 수도 있고, 숫자나 숫자 범위로 표기하는 경우도 있다.

- 최소 커버리지 기준은 테이블의 결정 규칙당 최소 한 개의 테스트 케이스를 작성하는 것이다. 일반적으로 모든 조건 조합을 포함한다.

- 조건 조합에 영향을 받는 모든 상황에 적용 가능하며, 모든 테스트 레벨에 적용할 수 있다.

​

장점

- 중요한 모든 조건 조합을 식별하는 데 도움이 된다.

- 요구사항의 누락된 부분을 찾는 데 도움이 된다.

​

4.2.4 상태 전이 테스팅

시스템은 현재 조건이나 기존 이력(상태)에 따라 이벤트에 대해 다르게 반응할 수 있다.

​

특징

- 상태 전이 다이어그램은 sw의 가능한 상태 뿐만 아니라 상태 간에 어떻게 진입하고 빠져나오는지에 대한 전이 방법을 보여준다.

- 전이는 이벤트에 의해 시작된다.

- 하나의 이벤트에 의해 두 개 이상의 다른 전이가 발생할 수 있다.

- 상태 전이 다이어그램은 일반적으로 유효한 전이만 보여주며, 비유효 전이는 표시하지 않는다.

- 상태 전이 테스팅이느 메뉴 기반 애플리케이션에 사용한다. (임베디드 업계에서 사용)

- 구체적인 상태를 포함한 비즈니스 시나리오를 모델링하거나 화면 탐색을 테스팅하는데 적합하다.

- 상태의 개념은 추상적이다. (코드 몇 줄 또는 전체 비즈니스 프로세스)

​

4.2.5 유스케이스 테스팅

sw항목 간의 상호작용을 설계하는 특정 방법이다.

​

유스케이스

- sw기능에 대한 요구사항을 통합한다.

- 액터와 대상 간의 관계이다.

- 액터와 협력하여 수행할 수 있는 동작들을 명시한다.

- 상호작용과 활동으로 설명하기도 하고, 사전조건, 사후조건 및 자연어로 설명할 수 있다.

- 상호작용으로 대상의 상태가 변경될 수 있다.

- 상호작용은 워크플로우, 활동 다이어그램, 비즈니스 프로세스 모델로 시각화할 수 있다.

- 예외 동작 및 오류 처리를 포함한 기본 동작의 가능한 변형이 포함된다.

​

 

​

💡 동등 분할을 적용 가능한 테스트 유형 : 모든 유형에서 가능 (기능/비기능 테스트, 구조적 테스트, 확인/리그레션 테스트)

​

💡 결정 테이블 테스팅의 특징

ㄴ 가능한 모든 조건들의 조합을 도출

ㄴ 테스트 베이시스의 불완전성과 모호함을 지적

ㄴ TC를 만들면서 요구사항의 모호함과 결함을 발견하는 것이 가능

ㄴ 많은 노력과 시간이 소요된다. (개발 측의 검토와 합의도 필요함)

​

💡 상태 전이 테스팅의 절차

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

2) 전이 트리 구성

3) 유효/비유효 테스트 케이스 구성

4) 가드 또는 조건 테스트케이스 구성

5) 테스트 프로시저 또는 스크립트 구성

​

💡 0-스위치 커버리지 : 상태를 1번 전이하는 것 (edge 하나): 중간 상태 없이 한 상태에서 다른 상태로 전이

💡 1-스위치 커버리지 : 상태를 2번 전이하는 것 (edge를 두개 지나는 경로): 하나의 중간 상태를 거처 한 상태에서 다른 상태로 전이 , ex) S3 to S1 to S2

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

​

💡 상태 전이 테스팅

ㄴ 상태 다이어그램이 있어야 적용할 수 있다.

ㄴ 구동하는 소프트웨어 또는 시스템이 없어도 적용할 수 있다.

ㄴ 무반응 테스트케이스도 도출할 수 있다.

ㄴ 다이어그램에 요구사항을 '정확하게 표현 해야만' TC를 누락없이 도출할 수 있다.

 

💡 유즈케이스 테스팅

UML에서는 유즈케이스 이벤트의 작성법을 정의하지 않아 유즈케이스 표현 자체가 정확하지 않고 일관성이 낮을 수 있다. -> 누락없이 목표로 하는 테스트의 보장성을 확보 x

 

 

 

 

---

Reference

https://m.blog.naver.com/PostList.naver?blogId=jing_new_&tab=1