[2011 실라버스 - Chapter.4] 테스트 설계와 구현 프로세스에 대해서 알아보자

※ "개발자도 알아야 할 소프트웨어 테스팅 실무"를 기반으로 요약 ※ 

 

Part 4. 테스트 설계 기법

4.1 테스트 설계 및 구현 프로세스

< 테스트 케이스 포함내용 >

1. ID(식별번호) 
- 테스트 케이스를 식별하기 위한 번호 
- 구분 식별자와 인련번호로 구성됨
2. 사전조건 
- 테스트가 수행되기 위해 연결되어야 하는 조건에 대한 정보 
- 구동환경, 테스트 데이터에 대한 정의 등
3. 테스트 수행절차 
- 구체적인 테스트 수행 단계 - 7단계 이내 제안
4. 기대결과 
- 테스트 실행 후 의도한 대로 동작하였는지를 판단하는 근거 
- 실행 사후조건이 필요한 경우에는 기대결과에 포함되거나 별도로 기술함
5. 구분 
- 테스트 케이스를 분류하여 편리하게 구별하기 위해 사용
6. 추적성  
- 해당 테스트 설계의 바탕이 된 요구사항 및 적용된 기법 등 기록
7. 중요도  
- 시간적 제약이 있을 경우 테스트 대상을 선택하기 위한 기준. 시간이 부족할 경우에 테스트 하지 않을 것만 표시할 수도 있음
8. 합격/불합격 : 테스트 케이스를 수행할 결과에 대한 최종 확인 
- Pass : 의도대로 동작하였음 
- Fail : 의도대로 동작하지 않았음 
- Not Tested : 테스트가 수행되지 않았음 
- Blocked : 서전 조건이 충족하지 않아 테스트가 수행 될 수 없었음. 올바른 동작여부 판단불가
9. 비고 : 해당 테스트 케이스가 확인하고자 하는 의도 등 관련 내용 기술 
- 테스트 프로시저 : 효율적인 테스트를 위한 테스트 케이스의 실행 순서 
- 테스트 케이스를 작성할 때, 테스트 수행절차를 얼마나 상세하게 작성하는 것이 적절한지 결정해 주어야 한다. 테스트 케이스를 실행할 테스터의 스킬, 능력, 해당 시스템에 대한 이해 등을 고려하여 테스트 케이스의 섬세함 정도를 조정해야 한다.  
- 테스트 케이스의 목적은 요구되는 보장성을 갖는 최소한의 테스트 케이스로 가능한 많은 결함을 발견하는 것이다.

 

소프트웨어가 사전에 정의된 요구사항을 기반으로 구현되었는지 여부에 따라 결함이 발생하는 경우는 4가지로 구분되며, 각각의 경우에 결함을 발견하기 위해 수행해야 하는 테스트는 아래와 같다.

 

1. 요구사항에 명시되어 있는데 구현되지 않은 경우

- 요구사항을 기반으로 테스트 케이스를 만들어서 실행해야 한다.

2. 요구사항대로 구현되었는데, 때에 따라 정상동작 하지 않는 경우

- 요구사항을 기반으로 테스트 케이스를 만들어서 실행하고 추가적인 테스트 케이스를 수행한다.

3. 요구사항에 명시되어 있지 않은데 구현되어 있는 경우

- 요구사항 기반의 테스트로는 해당 결함을 발견하기 어려우므로 비공식적인 테스트를 추가적으로 실행하여야 한다.

- 이 경우, 해당 결함을 제거하기 위해서는 구현된 부분을 반영하여 요구사항을 변경하거나 해당 부분을 제거해야 한다.

4. 요구사항에는 명시되어 있지 않지만 구현은 되어 있는 부분에서 정상동작 하지 않는 경우

- 요구사항 기반의 테스트로는 해당 결함을 발견하기 어려우므로 비공식적인 테스트를 추가적으로 실행하여야 한다.

- 3의 경우보다 기대결과를 알기 어려우므로 요구사항을 기반으로 비공식적인 테스트를 보다 체계적이고 강도 높게 설계하고 실행해야 한다.

 

4.2 테스트 설계 기법의 종류

1. 명세 기반 기법의 일반적인 특징
- 해결할 문제를 명세하기 위해 공식적이거나 비공식적인 모델을 사용한다.
- 이러한 모델에서 테스트 케이스를 시스템적으로 도출하는 것이 가능하다.
- 커버리지를 측정할 수 있으나 그 의미가 구조 기반 기법의 커버리지에 비해 제한적이다.

2. 구조 기반 기법의 일반적인 특징
- 코드와 개발 설계 등의 소프트웨어 구현 정보를 기반으로 테스트 케이스를 도출한다.
- 수행된 테스트 케이스를 바탕으로 테스트 커버리지를 측정할 수 있으며, 커버리지를 높이기 위해 추가로 테스트 케이스를 시스템적으로 도출할 수 있다.

3. 경험 기반 기법의 일반적인 특징
- 테스트 관련 인력의 지식이나 경험에서 테스트 케이스를 도출한다.
- 테스터 , 개발자 , 사용자의 소프트웨어 대한 지식
- 소프트웨어에서 자주 발생하는 결함이나 결함의 분포와 관련 있는 지식

 

4.3 기본 설계 기법

4.3.1 명세 기반 기법

- 명세 기반 기법은 명세를 바탕으로 테스트 케이스를 도출하는 것을 의미하며 , 해당 테스트 케이스를 수행해서 중대한 결함이 없음을 보장하는 것이다.

 

명세 기반 기법 적용 시 고려하여야 할 사항

- 시스템이 상태 다이어그램, 유즈케이스 등의 모델로 표현되어 있지 않을 경우, 명세 기반 기법을 적용하기 위해서는 테스트 전문가가 요구사항 분석서와 설계서를 먼저 작성한 후 테스트 케이스를 작성하는 것을 고려해야 한다.

- 조기 테스트 설계에 활용한다. 동작하는 소프트웨어가 없어도 명세만 있다면 명세 기반 기법으로 테스트 케이스를 도출할 수 있다. 이는 개발 초기에 테스팅이 진행될 수 있다는 것을 의마하며 테스트 케이스를 생성하는 과정에서 개발자/분석가/아키텍트가 발견하기 어려운 결함을 효과적으로 발견할 수 있다.

4.3.1.1 동등 분할

- 입력값/출력값 영역을 유한 개의 상호 독립적인 집합으로 나누어 수학적인 등가 집합을 만든 후, 각 등가 집합의 원소 중 대푯값 하나를 선택하여 테스트 케이스를 작성하는 것이 동등분할이다.
1. 동등 분할은 명세에 있는 입/출력값 등을 활용하기 때문에 명세기반 테스트 기법으로 분류하고 있지만 구조 기반 기법과 경험 기반 기법에서 입/출력 데이터가 필요한 경우에도 해당 기법을 사용할 수 있다.
2. 동등 분할은 모든 테스트 레벨에서 사용이 가능하다.
3. 동등 분할은 모든 테스트 유형에서 적용이 가능하다.

4.3.1.2 경계값 분석

- 경계값 분석은 동등 분할의 경계 부분에 해당되는 입력값에서 결함이 발견될 확률이 경험적으로 높기 때문에

결함을 방지하기 위해 경계값까지 포함하여 테스트하는 기법이다.

- 해당 분할영역의 최대값과 최소값은 그 영역의 경계값이 된다.
- 동등분할 과 동일한 테스트 프로세스이며, 경계값에서 유효 경계값과 비유효 경계값을 추가하여 테스트하는 방법이다.

 

- 동등분할과 경계값 분석의 한계점
1. 일련의 동작에 대한 조합을 테스트하기에는 적합하지 않다.
2. 입력 범위를 동등 분할하여 제한하더라도 입력값 조합의 수가 테스트 가능한 수를 넘어서는 경우가 많다.
3. 입력 조합이 상호간에 독립적이라는 가정에서만 적합한 기법이다.
4. 출력이 입력조건이나 변수들 사이의 관계에 따라 달라지는 경우, 입력 조건을 동등 분할하는 것이 매우 어려울 수 있다.

4.3.1.3 결정 테이블 테스팅

결정 테이블은 논리적인 조건이나 상황을 구현하는 시스템에서 요구사항을 도출하거나 내부 시스템 설계를 문서화하는 매우 유용한 도구이다. 이것은 시스템이 구현해야 할 비즈니스 규칙을 문서화하는데 사용된다.

 

- 결정 테이블 테스팅의 장/단점 비교

장점	단점
논리적으로 의존적인 가능한 모든 조건들의 조합을 생성함  요구사항 등 테스트 베이시스 문제점을 드러내게 하는 효과적 테스트 케이스 생성 가능  - 테스트 베이시스의 불완전성과 모호함 발견 가능  - 테스트 케이스를 만들면서 결함을 발견하는 것이 가능함	작성에 많은 노력과 시간이 소요 될 수 있음(특히 테스트를 위해 결정테이블을 만들어야 할 경우 작성 후 개발측의 검토가 필요함)  복잡한 시스템은 표현하기 어려울 수 있으며, 작성 시 논리적 실수 가능성 있음

4.3.1.4 상태 전이 테스팅

시스템은 현재 상황과 이전의 이력을 반영하는 상태 및 그 변화에 따라 다르게 동작할 수 있다.

시스템의 이러한 측면을 상태 전이 다이어그램으로 표현할 수 있다.

상태 전이 테스팅을 통해 다음과 같은 방식으로 테스틀 설계하는 것이 가능하다.

 

- 전형적인 상태의 순서를 커버하는 방식

- 모든 상태를 커버하는 방식

- 모든 상태 전이를 실행하는 방식

- 특정한 상태 전이 순서를 발견하는 방식

- 불가능한 상태 전이를 테스트하는 방식

구성요소	설명	표기법
상태	하나 또는 그 이상의 이벤트를 기다리는 시스템의 모드	원으로 표기, 원안에 상태명 표시
전이	이벤트에 의해 한가지 상태에서 다른 상태로의 변경	화살표 형태의 링크로 표시하며 상태와 상태를 연결함
이벤트	상태의 전이를 유발하는 원인	화살표에 이름과 값으로 표시
가드	이벤트가 발생하는 조건	이벤트 오른편의 [ ] 안에 조건이나 값으로 표시
액션	상태의 전이에 따라서 유발되는 동작	화살표에 이름과 값으로 표시

상태 다이어그램으로 시스템을 설계하는 과정에서 도출할 수 있는 결함을 아래와 같이 모델상의 결함과 구현상의 결함으로 분류할 수 있다.

 

- 모델상의 결함

1. 초기상태 누락

2. 전이 또는 액션의 누락

3. 가드를 "전이" 대신 상태에 표기함

4. 가드의 중복 또는 불일치

 

- 구현상의 결함

1. 여분/누락/훼손 상태

2. 액션이 틀리거나 누락됨

3. 스니크 패스, 트랩 도어

 

- 상태전이 테스팅 절차

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

2. 전이 트리 구성

3. 반응 테스트 케이스 구성 (유효)

4. 무반응 테스트 케이스 구성 (비유효)

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

6. 테스트 프로시저 구성

4.3.1.5 유즈케이스 테스팅

유즈케이스나 비즈니스 시나리오를 기반으로 테스트를 명세화할 수 있다.

유즈케이스는 시스템이 실제 사용되는 방식에 기반하여 "프로세스 흐름"을 기술한다.

유즈케이스 테스팅은 통합테스트 단계에서 서로 다른 컴포넌트 사이의 상호작용과 간섭으로 발생하는 통합 결함을 찾는데 도움이 된다.

 

컴포넌트 레벨 유즈케이스 테스팅

유즈케이스 상세를 문장별로 분석하여 테스트 케이스를 도출하는 것을 아래의 절차에 따라 진행하면,

누락을 최소화하고 일정수준의 보장성을 확보할 수 있다.

 

1. 어떤 흐름을 테스트 할지 고려하여 테스트 시나리오 구성

2. 유즈케이스 상세에서 테스트에 필수적인 상황 선택

3. 유즈케이스 상세 내용을 입력값 , 출력값 , 상황 처리 등으로 분류하여 테스팅에 관여하는 상황을 선택

4. 각각의 상황에 ID 부여

5. 각각의 상황에 가능한 값을 결정

 

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

유즈케이스 간의 상호작용과 활동을 테스트하는 시스템 테스팅 레벨의 유즈케이스 테스팅에서는 활동 다이어그램에 표현된 유즈케이스 활동을 상태의 관점에서 파악하고 활동의 흐름을 전이로 간주하여 상태 전이 테스팅 기법의 컨셉을 활용할 수 있다.

 

유즈케이스 테스팅은 절차에 따라 한다고 해서 누락되는 것 없이 기대되는 테스트의 보장성을 확보하면서 테스트 케이스를 도출할 수 있는 것은 아니다. UML 에서는 유즈케이스 이벤트의 흐름을 어떻게 구조화시켜 조직하고 작성해야 하는지를 제시하지 않아 근간이 되는 유즈케이스로 표현된 것 자체가 정확하지 않고 일관성이 낮을 수 있다. 결국 유즈케이스가 얼마나 쉽고 정확하고 체계적으로 작성되어 있느냐에 따라 테스트 케이스의 완성도와 정확도가 달라지며 보장성 확보에 영향을 줄 수 있다.

4.3.2 구조 기반 기법

시스템 또는 소프트웨어의 구조가 테스트 스위트에 의해 테스트된 정보를 커버리지 라 하며, 특정 구조의 종류에 대해 커버된 백분율로 표시된다.

 

- 각 커버리지의 특징

1. 구문 커버리지는 테스트 스위트에 의해 실행된 구문이 몇 퍼센트인지 측정하는 것으로 다른 커버리지에 비해 가장 약하다.

2. 결정 커버리지는 테스트 스위트에 의해 실행된 결정 포인트 내의 전체조건식이 최소한 참이 한 번 그리고 거짓이 한 번씩 선택되었는지 측정하여 퍼센트로 표현하는 것이다. 개별조건식의 개수와 관계없이 테스트 케이스 최소 개수는 2개로 도출되며, 조건/결정 커버리지에 비해 약하다.

DPoint = A AND B

DPoint	A	B
0	1	0
1	1	1

3. 조건 커버리지는 전체조건식의 결과와 관계없이 각 개별조건식이 참 한번, 거짓 한번을 모두 갖도록 개별조건식을 조합하는 것으로 결정 커버리지보다 강력한 형태의 커비리지이다.

DPoint = A AND B

DPoint	A	B
0	1	0
0	0	1

4. 조건/결정 커버리지는 전체조건식의 결과가 참 한번, 거짓 한번을 갖도록 각 개별조건식을 조합하는데 이 때 각 조건식도 참과 거짓을 한번씩 모두 갖도록 조합하는 것으로 결정 커버리지와 조건 커버리지를 포함하는 커버리지이다.

DPoint = A AND B

DPoint	A	B
0	0	0
1	1	1

5. 변경 조건/결정 커버리지, 즉 MC/DC 는 각 개별조건식이 다른 개별조건식에 무관하게 전체조건식의 결과에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 것으로 결정 커버리지, 조건/결정 커버리지보다 강력하다.

DPoint = A AND B

DPoint	A	B
0	1	0
0	0	1
1	1	1

 

6. 다중 조건 커버리지는 결정 포인트 내에 있는 모든 개별조건식의 모든 가능한 논리적인 조합을 고려하여 100% 커버리지를 보장한다.

DPoint = A AND B

DPoint	A	B
1	1	1
0	1	0
0	0	1
0	0	0

4.3.2.1 구문 테스팅과 커버리지

구문 커버리지는 적은 개수의 테스트 데이터로 쉽게 달성할 수 있지만 코드 상에 존재하는 가능한 경우를 모두 검증하지 못하는 보장성이 낮은 커버리지이다.

4.3.2.2 결정 테스팅과 커버리지

결정 커버리지는 결정 포인트 내의 전체조건식이 참과 거짓의 모든 값을 갖게 되어 모든 분기로 흐르게 되면 달성된다.
결정 커버리지는 구문 커버리지보다 강력하여 100% 결정 커버리지를 달성할 경우, 100% 구문 커버리지를 달성함을 보장한다. 그러나 반대의 경우는 성립하지 않는다.

4.3.2.3 (다중)조건 테스팅과 커버리지

조건 커버리지는 결정 포인트 내에 있는 개개의 개별조건식이 참과 거짓의 모든 값을 갖게 되면 달성된다.

 

- 다중 조건 커버리지

결정 포인트 내에 있는 모든 개별조건식의 모든 가능한 논리적인 조합을 고려한 강력한 커버리지를 의미한다. 

그러나 모든 개별조건식의 모든 조합의 경우를 고려한 방법이므로 테스트 케이스 양이 매우 방대해지므로 출시 전에 반드시 100% 결함을 제거해야 하는 제품 테스트에 사용한다.

4.3.2.4 변형된 조건 /결정 커버리지 (MC/DC)

변형된 조건/결정 커버리지는 각 개별조건식이 다른 개별조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 함으로써 조건/결정 커버리지를 향상시킨 것으로 결정 커버리지, 조건 커버리지보다 강력하다.

- 변형된 조건/결정 커버리지의 결정 테이블을 만들기 위해 접근하는 방법

1. 프로그램에 있는 모든 결정 포인트 내의 전체조건식은 적어도 한 번 모든 가능한 결과값(참,거짓)을 취한다.
2. 프로그램에 있는 결정 포인트 내의 모든 개별조건식은 적어도 한번 모든 가능한 결과값(참,거짓)을 취한다.
3. 결정 포인트에 있는 각각의 개별조건식은 다른 개별조건식에 영향을 받지 않고 그 결정 포인트의 결과값에 독립적으로 영향을 준다.
DPoint = A AND B 에 대한 MC/DC 결정 테이블

전체조건식	개별조건식A	개별조건식B	설명
1	1	1	A가 B에 독립적,B가 A에 독립적으로 전체조건식에 영향을 미친다. 개별조건식 A와 B중에 어느 한개의 값을 0으로 변경하면 전체조건식이 0으로 변경되기 때문에 A,B 모두 전체조건식에 독립적으로 영향을 준다.
0	1	0	B가 A에 독립적으로 전체조건식에 영향을 미친다. B를 1로 변경하면 전체조건식이 1로 변경되기 때문에 전체조건식에 독립적으로 영향을 주는 것이다.
0	0	1	A가 B에 독립적으로 전체조건식에 영향을 미친다. A를 1로 변경하면 전체조건식이 1로 변경되기 때문에 전체조건식에 독립적으로 영향을 주는 것이다.
0	0	0	개별조건식 A와 B중 어느 한개의 값을 1로 변경하더라도 그 결과인 전체조건식은 0으로 변화가 없기 때문에 독립적으로 영향을 미치지 못한다. 그러므로 MC/DC 커버리지에서는 제외된다.

 

커버리지 포함 관계

 

4.3.3 경험 기반 기법

4.3.3.1 탐색적 테스팅 접근법

※ 탐색적 테스팅의 개념

탐색적 테스팅은 테스트 설계,테스트 수행, 테스트 계획, 테스트 기록 및 학습을 동시에 진행하는 휴리스틱한 테스팅 접근법이다. 여러 형태의 탐색적 테스팅이 존재할 수 있지만 60~120분 동안에 몰입해서 수행할 수 있는 정도의 테스트 목적을 담고 있는 테스트 차터를 기반으로 수행하는 것이 일반적이다.

 

탐색적 테스팅은 테스트 케이스 기반의 공식적 테스팅과 반대되는 개념의 "테스팅 접근법"이다. 테스트 설계기법의 한 가지로 보려는 시각도 있는데 이는 잘못된 것이다. 공식적 테스팅이 문서화된 테스트 케이스를 기반으로 수행하는 것임에 반해, 탐색적 테스팅은 테스트 케이스를 문서화하는데 소요되는 시간을 최소화 하여 테스트를 "실행" 하는 것에 집중한다.

 

탐색적 테스팅을 깊이 있게 알지 못하는 경우 탐색적 테스팅을 단순한 경험적 테스팅이나 애드훅 테스팅과 혼돈할 수 있는데 실제적으로는 완전히 다르다. 다양한 차이점이 존재하는데 가장 두드러진 차이점은 탐색적 테스팅이 차터 기반으로 제한된 시간 내에 몰입해서 테스팅을 수행하고, 설명 가능한 기록을 남기고 요약보고 미팅을 갖는다는 것이다.

 

- 탐색적 테스팅 아래와 같은 내용을 포함한다.

1. 제품 탐색

2. 테스트 설계

3. 테스트 실행

4. 직관

5. 검토 가능한 결과물

 

- 탐색적 테스팅에서 제안하는 테스트 절차

1. 제품의 목적 식별

2. 기능 식별

3. 잠재적으로 불안정한 부분 식별

4. 각각의 기능 테스트 및 문제점 기록

5. 일관성 검증 테스트 설계 및 기록

 

※  탐색적 테스팅의 구성요소

- 테스트 차터와 시간 제한

탐색적 테스팅에서 테스트 차터는 무엇을 어떻게 테스트해야 하고, 무슨 문제를 살펴야 하는지를 제안한 내용이다. 즉, 각 세션에 대해 명확한 임무를 설정해 놓은 것을 말한다.

 

테스트 차터를 정할 때에는 먼저 수행할 각 세션당 시간을 정해놓는다. 테스터는 정해진 시간 내에 테스트 차터를 수행해야 하며, 몰입하여 테스트 하는 것을 원칙으로 한다.

테스터가 제한된 시간 안에 수행해야 할 것은 다음과 같다.

 

1. 정확한 리포팅

2. 유연성 있는 일정관리

3. 테스트 방향 정정

4. 견고한 테스팅

5. 효율적인 요약 보고

 

테스트 차터를 효율적/효과적으로 만들기 위해서는 제품 리스크에 기반하여 만들어야 한다.

즉, 리스크 분석 결과, 제품의 리스크가 높은 기능에는 테스트 차터를 많이 생성하고 리스크가 낮은 기능에는 테스트 차터를 적게 생성하여 테스트를 수행하는 것이다.

 

탐색적 테스트 기법

 

- 테스트 노트와 요약보고

탐색적 테스팅에서는 문서를 최소화해야 한다고 주장하지만, 테스트 산출물이 전혀 없는 것은 아니다.

테스트 엔지니어는 테스트 실행과 동시에 머릿속으로 계획, 설계하고 테스트 케이스를 작성하며, 이러한 사고활동을 간단하게 노트에 기록한다.

이렇게 작성된 테스트 노트는 테스트 케이스의 역할을 대체함과 동시에, 검토 가능한 결과물로써 활용된다.

탐색적 테스팅의 한 세션이 종료된 후에는 팀원끼리 요약보고하는 시간을 갖는다.

요약보고 중에는 테스트 중 발견했던 결함과 이슈사항에 대해 보고하고, 어떤 식으로 테스트를 수행했는지에 관한 경험을 팀원 모두가 공유한다.

 

- 테스트 노트에 포함되어야 할 내용

1. 테스트한 제품에 대한 노트 및 기록

2. 발견한 결함과 장애에 대한 노트 및 기록

3. 어떻게 테스트 하였는지를 기술하는 요약된 문서

 

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

테스트 케이스 기반 테스팅과 탐색적 테스팅의 가장 큰 차이점은, 테스트 케이스 기반 테스팅은 모든 테스트 케이스의 작성을 마친 후 그것을 절차적으로 실행하지만, 탐색적 테스팅은 테스트 대상을 파악해 가며 동시에 테스트를 설계하고 실행하는 것이다.

문서화와 지적능력 사분면

 

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

테스트 케이스 기반 테스팅	탐색적 테스팅
테스트가 먼저 설계되고 기록된다. 나중에 다른 테스터가 이를 수행한다.	테스트가 설계됨과 동시에 수행된다. 테스트가 반드시 기록되어야 하는 것은 아니다.
테스트의 실행을 관리하는 것이다.	테스트 설계를 향상 시키는 것이다.
테스트 실행을 시작하기 전에 테스트 케이스를 작성한다.	프로젝트 기간 내내 테스트 계획/설계와 실행을 반복한다.
테스트 문서 작성,검토에 많은 에너지를 소비함으로써 테스트의 효율성이 감소하는 경우가 있다.	테스트 문서 작성, 검토에 대한 필요성을 최소화하여 보다 많고 복잡한 테스트에 상대적으로 많은 노력 투자가 가능하다.
테스터 간의 차이를 제거하려는 노력	테스터 간의 차이를 십분 활용하려는 노력
테스터가 아닐 수 있는 테스트 설계자가 테스트를 설계한다.	테스트 설계자일 수 있는 테스터가 테스트를 설계한다.
완벽하게 한번에 테스팅을 수행한다.	점진적이고 주기적으로 테스팅을 수행한다.

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

테스트 전략 수립 시 제품의 리스크가 가장 높은 곳에 탐색적 테스팅을 추가, 그 다음 높은 곳에는 선택적 탐색적 테스팅을 추가하였다.

 

이와 같이 탐색적 테스팅은 공식적인 테스팅과 함께 사용됨으로써, 다양한 종류의 결함을 발견할 수 있다.

리스크가 가장 높은 곳에는 테스팅 경험이 풍부하고 능력 있는 테스트 엔지니어가 탐색적 테스팅을 수행해야 하고 반대로 리스크가 가장 낮은 곳에는 경험과 능력이 상대적으로 부족한 테스트 엔지니어가 수행해야 한다.

 

- 탐색적 테스팅을 성공적으로 수행하게 되면 다음과 같은 효과를 가져올 수 있다.

1. 경험적 테스팅을 체계화 시킬 수 있다.

2. 테스트 케이스를 작성하는 시간을 줄여 보다 많은 테스트를 실행할 수 있다.

3. 테스터 또는 테스트 엔지니어의 역량을 월등히 향상시킬 수 있다.

4. 적은 테스트 인력으로 많은 테스트를 수행할 수 있다.

5. 명세가 거의 없고 시간이 부족한 경우 테스트를 효과적/효율적으로 수행할 수 있다.

 

4.4 고급 설계 기법

4.4.1 명세 기반 기법

4.4.1.1. 분류 트리 기법

- 분류 트리 기법의 장점
1. 테스트 아이디어를 트리 구조로 시각화 하여 테스트 케이스를 설계하므로 의도한대로 테스트 케이스를 도출할 수 있다.
2. 시각적으로 보면서 트리 구조 끝단의 조합을 통해 테스트 케이스를 작성하므로 일부분만 테스트를 진행한다거나 중복된 테스트 수행을 피할 수 있다.
3. 복잡한 시스템 혹은 어플리케이션의 일부 또는 전체를 테스팅하는데 적합하다.
4. 개발 설계를 체크하는 용도로 사용이 가능하여 , 조기 테스트 설계에 활용할 수 있다.
5. 테스트 케이스 개수와 트리의 복잡도를 근거로 테스트 비용을 추정하는 것이 가능하다.

4.4.1.2 페어와이즈 조합 테스팅

페어와이즈 조합 테스팅은 커버해야 할 기능적 범위에 비해 상대적으로 적은량의 테스트 세트를 구성하여 소프트웨어의 결함을 찾고 테스트에 대한 자신감을 얻을 수 있는 방법이다.
<페어와이즈 조합 방법>
1. 재생 , 볼륨 , 이퀄라이저 기능을 순차적으로 조합. 2x2x2 = 8가지

페어와이즈 조합

2. 두 가지 요소의 개별조합만을 고려한다.

재생,볼륨의 개별조합을 고려

개별 조합

3. 나머지 요소를 중복되지 않게 조합

중복 제거

처음 8개 보다 50%가 줄은 페어와이즈 조합을 볼 수 있다.

 

4.4.2. 구조 기반 기법

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

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

- 포함 : 논리적 테스트 컬럼의 각각을 선택한 커버리지로 생성한 조합 중에서 단 하나만 선택하여 하나의 논리적 테스트 케이스로 작성하는 1:1 전환 방식이다. 따라서 하나의 테스트 케이스에서 개별조건식은 다른 결정 포인트의 결과값과 독립적ㄱ으로 확인할 수 없으므로 결함의 원인을 즉각적으로 판단하기 어렵지만 어느 정도 커버리지를 만족하면서 테스트 케이스 수를 줄일 수 있는 방법이다.

4.4.3 경험 기반 기법

4.4.3.1. 오류추정

- 오류 추정 기법을 통해 언급된 경험기반 테스팅 기법의 일반적인 유용성을 정리해 보면 다음과 같다.
1. 스펙이 거의 없거나 불충분할 경우, 시간적인 압박이 극심한 경우 유용하다.
2. 다른 기법이나 공식적인 테스트를 보완ㄴ할 때 유용하게 사용할 수 있다.
3. 가장 심각한 결함을 찾았다고 확신할 수 있도록 지원함으로써 테스트 프로세스를 점검하는 기준을 제공할 수 있다.

4.4.3.2. 체크리스트

- 체크리스트 분류
1. 일반 체크리스트 : 수행해야 할 테스트 목록과 절차를 나열함
2. 기능 체크리스트
- 전체 시스템의 최상위 기능 체크
- 개별적인 컴포넌트 기능
- 서로 다른 레벨의 기능과 그룹핑
3. 시스템 요소 체크리스트
- 상위 레벨 서브-시스템 이나 모듈
- 개별 구문이나 데이터 아이템
- 서로 다른 레벨의 시스템 요소와 그룹핑

4.5 테스트 기법의 선택

- 어떤 테스트 기법을 사용할지 결정하는데 고려해야 할 사항
1. 시스템의 유형
2. 강제적인 표준 또는 법적 기준의 존재 여부
3. 고객 또는 계약상의 요구 사항
4. 리스크 수준
5. 리스크 유형
6. 테스트 목표
7. 문서의 존재 유무
8. 테스터의 지식 수준
9. 시간과 예산
10. 테스트 레벨
11. 개발 생명 주기
12. 유즈케이스 , 상태 다이어그램 등 모델 존재 유무
13. 발견된 결함 유형에 대한 이전의 경험

4.6 소프트웨어 특성에 따른 테스팅

- 특성 테스팅으로 테스트 케이스를 도출하는 방법은 아래와 같다.
1. 각 품질 특성을 평가항목으로 보고 테스트 대상 제품에 대해 평가항목의 비율을 선정한다.
2. 각 품질 특성별로 경험과 제품의 특성을 고려하여 테스트 케이스를 도출한다.

- 기능성에 해당하는 품질 부특성
1. 적합성 : 사용자의 요구 기능을 제공하는 능력
2. 정확성 : 올바른 또는 정확한 결과를 제공하는 능력
3. 상호운영성 : 다른 시스템과의 상호 작동 능력
4. 보안성 : 정보 및 데이터를 보호하는 능력
5. 준수성 : 기능성 관련 표준,규정,관례 등을 따르는 능력

- 신뢰성에 해당하는 품질 부특성
1. 성숙성 : 사용자의 오류를 피하는 능력
2. 오류 허용성 : 내재된 결함으로부터 성능을 유지하는 능력
3. 회복성 : 장애발생시 기능 및 데이터를 복구하는 능력
4. 준수성 : 신뢰성 관련 표준,규정,관례 등을 따르는 능력

- 사용성에 해당하는 품질 부특성
1. 이해성 : 운용 방법이나 조건 등을 쉽게 파악하게 하는 능력
2. 학습성 : 소프트웨어 운용법을 배울 수 있게 하는 능력
3. 운용성 : 소프트웨어를 운영하고 제어할 수 있게 하는 능력
4. 친밀성 : 사용자에게 호감을 갖게 하는 능력
5. 준수성 : 사용성 관련 표준, 규정, 관례 등을 따르는 능력

 

- 효율성에 해당하는 품질 부특성

1. 시간반응성 : 기능 수행시 적절한 응답시간, 처리시간, 처리율을 제공하는 능력

2. 자원효율성 : 기능 수행시 적절한 자원을 사용하는 능력

3. 준수성 : 효율성 관련 표준,규정,관례 등을 따르는 능력

 

- 유지보수성에 해당하는 품질 부특성

1. 분석성 : 장애 원인을 진단할 수 있게 하는 능력

2. 변경성 : 변경 사항을 쉽게 구현할 수 있게 하는 능력

3. 안정성 : 변경에 따른 예상 밖의 결과를 최소화 하는 능력

4. 시험성 : 변경된 결과를 검증할 수 있게 하는 능력

5. 준수성 : 유지보수성 관련 표준,규정,관례 등을 따르는 능력

 

- 이식성에 해당하는 품질 부특성

1. 적응성 : 최소한의 조치만으로 이식될 수 있는 능력

2. 설치성 : 지정된 환경으로 설치될 수 있는 소프트웨어 능력

3. 대체성 : 공동 운영 환경에서 다른 소프트웨어를 대체할 수 있는 능력

4. 공존성 : 동일 환경에서 다른 소프트웨어를 대체할 수 있는 능력

5. 준수성 : 이식성 관련 표준,규정,관례 등을 따르는 능력

 

참조

- 도서 : 개발자도 알아야 할 소프트웨어 테스팅 실무

 

ISTQB

요약 : iso 표준, 국제 표준 iso, 국내 표준, 표준, istqb, kstqb, 웹 qa, 모바일 qa, 앱 qa, test web