테스팅 - 블랙박스, 화이트박스

일반적인 소프트웨어 테스트 목적

- 소프트웨어 내에 존재하는 오류 발견

- 소프트웨어 요구사항에 충족하는지 확인

- 소프트웨어 출시 이후 발생할 수 있는 결함을 예방

 

소프트웨어 테스트의 부가적 목적

- 소프트웨어 품질에 대한 자신감 획득과 정보 확인

- 비즈니스 리스크를 감소시킬 수 있도록 정보에 근거한 조언 제공

- 개발 프로세스 점검 및 이유 제공

- 시스템과 소프트웨어가 적절히 동작함을 확인

 

블랙 박스 테스팅 (Black Box Testing)

정의

- 프로그램을 블랙박스로 취급, 내부 구조를 참조하지 않고 주어진 입력에 요구되는 결과가 나오는가를 시험

- 프로그램과 외부와의 인터페이스에 대하여 시험이 이루어짐

- 프로그램의 기능에 초점, 주어진 입력값들의 조합에 의해 요구되는 결과가 나오는가를 점검

- 설계 명세서 또는 요구사항 명세서를 참조하여 이루어짐 -> 명세 기반 테스트

 

장점

- 소스 코드를 이용할 수 없는 경우에도 명세 정보 등을 이용하여 테스트 케이스를 도출 가능

- 블랙 박스 테스트 케이스는 동일 명세 바탕으로 구현된 여러 시스템에 재사용 가능하여 테스트케이스 설계 비용을 줄일 수 있음

- 테스트 케이스를 시스템 개발 초기 단계에서 개발될 수 있음

- 시스템 구현 언어나 개발 알고리즘 등과 같은 구현 기술에 대한 지식이 없어도 사용자 입장에서 시스템을 테스트하는 테스트 케이스 설계가 가능

- 명세를 분석하는 도중에 일관성이나 완전성에 관련된 명세 오류를 검출할 수 있는 기회를 제공 -> 명세서를 점검할 수 있는 계기가 됨

- 기능 누락 오류 검출에 유리

 

테스트 케이스

- 테스트를 실행하기 위해 시험할 케이스를 설정한 것

- 개발 초기 단계(분석, 설계)에 테스트 케이스를 계획해야 한다

- 내용: 테스트할 내용 및 목적, 테스트에 사용할 입력 데이터, 예상되는 출력 데이터 등

블랙박스 테스팅 테스트 케이스 도출 기법	설명
동등 분할 (Equivalance partitioning)	테스트 대상의 입출력 값을 특정 클래스로 분할한 후 각각의 클래스로부터 대표값을 추출하여 테스트 케이스를 생성하고 테스트 데이터의 범주를 식별하는 기법
경계 값 분석 (Boundary value analysys)	동등 분할 기법을 확장, 분할된 클래스의 경계에 대한 값들까지 검사
페어와이즈 조합 (Pairwise combination)	입력 값의 조합의 경우의 수를 줄이기 위해 두 입력 값의 조합을 통해 테스트케이스를 도출하는 기법 모든 경우의 수를 테스트하지 않고 두 개의 요소의 모든 조합을 확인할 수 있도록 테스트 케이스를 생성
상태 전이 (Finite state machine based testing)	상태 전이도를 기반으로 상태 전이 테이블을 도출하고 각각의 전이 시나리오로부터 테스트 케이스를 도출
인과 그래프 (Cause-effect diagram)	입력 데이터 간 관계가 출력에 영향에 미치는 상황을 체계적으로 분석하여 테스트케이스를 도출
결정 테이블 (Decision table)	의사 결정의 여러 조합을 정하는 행위나 결과를 식별함으로써 시스템의 예상되는 행위를 파악하여 테스트 케이스를 도출

---

1. 동등 분할 기법(Equivalance Partitionaing)

- 프로그램의 입력 영역을 몇 개의 동등 클래스(Equivalent class)라 불리는 영역으로 분할하여 각 클래스로부터 하나 이상의 대표값을 선택하여 테스트 케이스로 이용

 

동등의 의미?

- 각 동등 클래스로부터 선정된 입력값에 의하여 오류가 발견되면 클래스에 속한 다른 값들에 의해서도 동일한 오류가 발견

- 만약 각 동등 클래스로부터 선정된 입력값에 의하여 오류가 발견되지 못한다면 클래스에 속한 다른 값들에 의해서도 오류가 발견되지 않아야 함

 

동등 클래스: 시스템에 의해 동일하게 처리되고 같은 출력 결과를 생산하는 입력 조건 또는 입력 데이터 값들의 모임

 

동등 분할 지침

입력 조건이 범위를 기술하는 경우에는 입력 조건을 만족하는 하나의 클래스와 입력 조건을 만족하지 못하는 두 개의 클래스로 분할

- 조건 :: 1 < x < 10 -> {1 < x < 10}, {x <= 1 or x >= 10}

 

입력 조건이 특정 값을 기술하는 경우, 입력 조건을 만족하는 경우와 입력 조건을 만족하지 않는 두개의 클래스로 분할

- 조건 :: x == 1 -> {x == 1}, {x < 1 or x > 1}

 

입력 조건이 어떤 집합의 원소를 기술하는 경우에는 그 집합의 원소들만으로 이루어진 클래스와, 그렇지 못한 클래스로 분할

- 조건 :: {A, B, C, D} -> {A, B, C}, {D, E}

 

입력 조건이 어떤 개체가 존재하는지 여부를 따지는 경우에는 있는 경우와 없는 경우 각각을 하나의 클래스로 나눔

 

ex.

숙련공이 3시간 이하 작업 시 시간당 8만원, 3시간 초과 5시간 이하 시간당  10만원, 5시간 초과 시간당 12만원

비숙련공은 각각에 대해 절반 받음

주급 단위로 계산하고 일주일 간 최대 허용 작업 시간은 40시간

 

E : 숙련공

B : 비기너

K : 예외 인물

each choice 조합 (각 조건마다 한 번씩은 나오도록)
테스트 케이스	입력 조합	입력	예상 출력
1	(E, {0<작업시간<=3})	(E, 2)	16만원
2	(K, {3<작업시간<=5})	(K, 4)	에러 메시지
3	(E, {5<작업시간<=40})	(E, 30)	360만원
4	(E, {작업시간<=0})	(E, -10)	에러 메시지
5	(B, {40<작업시간})	(B, 50)	에러 메시지

All Combinations
테스트 케이스	입력 조합	입력	예상 출력
1	(E, {0<작업시간<=3})	(E, 2)	16만원
2	(E, {3<작업시간<=5})	(E, 4)	40만원
3	(E, {5<작업시간<=40})	(E, 30)	360만원
4	(E, {작업시간<=0})	(E, -10)	에러 메시지
5	(E, {40<작업시간})	(E, 50)	에러 메시지
6	(B, {0<작업시간<=3})	(B, 2)	8만원
7	(B, {3<작업시간<=5})	(B, 4)	20만원
8	(B, {5<작업시간<=40})	(B, 30)	180만원
9	(B, {작업시간<=0})	(B, -10)	에러 메시지
10	(B, {40<작업시간})	(B, 50)	에러 메시지
11	(K, {0<작업시간<=3})	(K, 2)	에러 메시지
12	(K, {3<작업시간<=5})	(K, 4)	에러 메시지
13	(K, {5<작업시간<=40})	(K, 30)	에러 메시지
14	(K, {작업시간<=0})	(K, -10)	에러 메시지
15	(K, {40<작업시간})	(K, 50)	에러 메시지

---

2. 경계 값 분석 (Boundary value analysis)

- 입력 조건이 a부터 b까지라는 값의 범위를 지정하면 a보다 조금 작은 값, a보다 조금 큰 값, b 보다 조금 작은 값, b보다 조금 큰 값을 시험 데이터로 선정

- 입력 조건이 몇 개의 값을 지정하고 있으면 이런 값들의 최소치, 최대치, 최소치 또는 최대치보다 좀 작거나 큰 값들을 시험 데이터로 선정

예시

- 일요일과 월요일의 경계

- 1월과 12월의 새해의 경계

- 30(또는 31)일 월의 경계

- 16비트 정수 값에서 32767과 32768 사이의 경계

- 두자리 연도로 표기하던 기법에서 2000년 1월 1일로 전환할 때

- 한 개의 문자로만 이루어진 문자열과 최대한의 길이를 가지고 있는 문자열의 길이의 경계

- 배열의 인덱스의 최소값과 최대값의 경계

---

3. 페어와이즈 테스트 (Pairwise Test)

- Each Choice(Weak ECP)는 유용한 테스트 케이스가 누락될 수 있음

- All Combinations(Strong ECP)는 너무 많은 테스트 케이스 생성

- 페어와이즈 테스트는 모든 짝들의 조합을 테스트함

 

입력 인자	A	B	C
값(또는 클래스)	A1	B1	C1
	A2	B2	C2
	A3	B3

- All Combinations : 18개의 테스트 케이스 필요 (3*3*2)

- Each choice : 3개 (위에 한줄씩 뽑아다 쓰면 됨)

- Pairwise test : 9개

 

테스트 케이스	A	B	C
1	A1	B1	C1
2	A1	B2	C2
3	A1	B3	C2
4	A2	B1	C2
5	A2	B2	C1
6	A2	B3	C1
7	A3	B1	C2
8	A3	B2	C1
9	A3	B3	C2

A1-B1, A1-B2, A1-B3

A2-B1, A2-B2, A2-B3

A3-B1, A3-B2, A3-B3

A1-C1, A1-C2

A2-C1, A2-C2

B1-C1, B1-C2

B2-C1, B2-C2

이처럼 모든 페어가 등장해야 하는 방식

---

4. 기반 선정(Base Choice) 테스트

- 각 파라미터(factor)에 대해 하나의 베이스 값을 지정

- 각 파라미터의 베이스를 조합하여 베이스 테스트 구성

- 사용자 관점에서 가장 선택될 빈도가 높고 단순하며 일반적으로 정상 작동할 수 있는 것을 선택

입력 인자	A	B	C
값(또는 클래스)	A1	B1	C1
	A2	B2	C2
	A3	B3

여기서 A1, B1, C1을 베이스 값으로 지정 -> 해당 값이 포함되는 테스트케이스 생성

테스트 케이스	A	B	C
1	A1	B1	C1
2	A1	B2	C1
3	A1	B3	C1
4	A2	B1	C1
5	A3	B1	C1
6	A1	B1	C2

기본적으로 하나의 인자만 변경하고 나머지 인자는 베이스로 고정함

---

5. Decision Table

ATM 예시

Decision Table
	1	2	3	4	5	6
1. 카드 유효	y	y	y	y	y	y
2. PIN 일치	y	y	y	y	n	n
3. PIN 3연 실패	y	y	n	n	n	n
4. 잔금 정상	y	n	y	n	y	n
a. 카드 반환
b. PIN 재입력					y	y
c. 카드 회수
d. 금액 재입력				y
e. 정상 출금			y

All Combinations -> 2*4 = 16

첫번째랑 두번째 같은 경우는 애초에 불가능함 => 제거

5, 6번은 겹치니까 하나만 해도 됨

이렇게 제거하다 보면 5개만 남음 (이 개수는 테스트마다 다름)

이런거 도와주는 tool이 당연히 있음

---

화이트박스 테스팅

정의

- 프로그램 내부의 구성을 시험

- 구조(Structural) 또는 코드에 기초한(code-based) 시험

- 모든 가능한 시험 사례는 불가능

- 프로그램 코드에 의도하지 않은 기능이 있는가를 테스트

- 블랙 박스 테스트는 명세에 따라 구현이 올바르게 되어 있는가를 테스트(기능 누락 오류 검출) 그러나 프로그래밍 상 오류 점검은 어려움

 

제어 흐름 그래프(Control Flow Graph)

기본 블록(Basic Block)

- 단일 입구와 단일 출구를 가진 일련의 연속적인 명령어들의 집합

- 기본 블록 내부로부터 제어가 빠져나갈 수 없으며 외부에서 내부로 제어가 들어올 수 없음

- 진입점과 진출점이 하나, 기본 블록의 첫 문장이 실행되면 나머지 기본 문장들도 실행되어야 하는 것을 의미

 

제어 흐름

- 기본 블록 간의 제어 흐름, CFG의 간선

- A->B 간선이 있으면 A가 실행된 후 B가 실행된다는 의미

 

  public class CFG {
      public int cfg(int x) {
          int x, y, i, z;
1:        Scanner scan = new Scanner(System.in);
2:        x = scan.nextInt();
3:        y = scan.nextInt();
4:        if( y < 10 )
5:            i = y + 10;
          else
6:            i = y;
7:        z = 0;
8:        while( i > 0 ) {
9:            z = z + x;
10:            i = i - 1;
          }
11:       if( y < 0 )
12:           z = z + 20;
13:       system.out.println(z);
      }
  }

기본 블록	문장	진입점	진출점
B1	{1, 2, 3, 4}	1	4
B2	{5}	5	5
B3	{6}	6	6
B4	{7}	7	7
B5	{8}	8	8
B6	{9, 10}	9	10
B7	{11}	11	11
B8	{12}	12	12
B9	{13}	13	13

 

CFG

구조 기반 테스트 목표

- 프로그램 상의 모든 경로들을 최소한 한 번은 테스트하는 것

- 엄청난 시간이 소모

 

구조적 커버리지 분석(Structural Coverage Analysis)

- 명세로부터 생성된 테스트를 실행, 코드의 어떤 부분이 실행되고 어떤 부분이 실행되지 않았는지 분석

- 분석 결과 실행이 되지 않은 부분을 실행할 수 있는 테스트를 명세로부터 생성 가능한지 살펴보아야 함

- 만약 코드가 수행하는 기능에 해당되는 부분이 명세에 없다면, 이 코드가 정말 실행할 수 없는 코드인지 아니면 의도하지 않은 기능을 수행하는지를 살펴보아야 함

 

화이트 박스 테스팅 종류

- 블록 커버리지(Block/Statement coverage)

- 분기 커버리지 (Branch/Decision coverage)

- 조건 커버리지 (Condition coverage)

- MC/DC 커버리지(Modified Condition/Decision coverage)

- 다중 조건 커버리지(Multiple Condition coverage)

- 기본 경로 테스트 (Basis Path Test)

---

예시 프로그램

void test(int a, int b, int x)
{
    if( (a > 1) && (b == 0) )
        y = x / a;
    if( (a == 2) && x > 1 )
        x = a * b;
}

 

1. 블록 커버리지(Block/Statement Coverage)

- 테스트하려는 프로그램 내의 모든 블록들을 적어도 한 번 이상 실행하도록 요구하는 테스트케이스 설계 방법

- 가장 기본적인 구조기반/화이트박스 테스트

- 100%의 문장 커버리지: 프로그램 내의 모든 블록들을 적어도 한번씩은 접근

- 커버리지 = 실행된 블록 수 / 전체 블록 수

Block(statement) coverage	TC1	TC2
	a = 3, b = 0, x = 1	a = 2, b = 0, x = 3
S1	o	o
S2	o	o
S3	o	o
S4	x	o
Coverage	3/4	4/4
전체 Coverage	100%

 

2. 분기 커버리지 (Branch/Decision Coverage)

- 각 결정(분기)이 참과 거짓을 적어도 한 번 이상 실행

- 블록 커버리지보다 강한 형태

- 분기 커버리지 = 실행된 분기 / 전체 분기

Branch(decision) coverage	TC1	TC2
	a = 2, b = 0, x = 4	a = 1, b = 1, x = 1
D1	D1T	D1F
D2	D2T	D2F
Coverage	50%	50%
전체 Coverage	100%

 

* JaCoCo

- Java 프로그램의 문장 커버리지와 분기 커버리지를 포함한 코드 커버리지를 측정하여 그 결과를 보고하는 도구

 

3. 조건 커버리지 (Condition Coverage)

- 조건문의 모든 조건식을 만족하는 경우와 만족하지 않는 경우를 테스트

- 조건 커버리지가 더 강하긴 한데, 조건 커버리지를 만족한다고 분기 커버리지를 다 만족하진 않음

Condition coverage	TC1	TC2
	a = 1, b = 0, x = 3	a = 2, b = 1, x = 1
A > 1	F	T
B == 0	T	F
A == 2	F	T
X > 1	T	F
Coverage	50%	50%
전체 Coverage	100%

Branch(Decision) coverage	TC1	TC2
	a = 1, b = 0, x = 3	a = 2, b = 1, x = 1
D1	F	F
D2	T	F
Coverage	50%	50%
전체 Coverage	75%

조건 커버리지가 100%여도 분기 커버리지는 75%

 

4. Multiple Coverage

- 조건이 4개 -> 2^4 .. 16개 다 해보는 거

- 완벽하지만 시간 소모가 큼, 가장 강력하긴 함

 

5. MC/DC (Modified Condition / Decision)

- 테스트 케이스를 줄이고 효율성

- 모든 Decision이 실행되어야 함

- 모든 Condition이 true나 false가 되어야 함

- 각 조건이 개별적으로 결과에 영향을 미쳐야 한다

- 각 조건의 독립적인 영향을 확인해야 한다

(A && B && C)

MC/DC	A	B	C	A	B	C	결과
TC1	T	T	T	v	v	v	T
TC2	T	T	F			v	F
TC3	T	F	T		v		F
TC4 (필요없음)	T	F	F		v	v	F
TC5	F	T	T	v			F
...

TC1, TC2, TC3, TC5만 있으면 됨

---

화이트 박스 시험의 필요성

- 블랙 박스 시험만 가지고는 프로그램의 실행문이 실제로 실행되는지 알 수 없음. 

- 프로그램 내에 불필요한 기능이 있는 경우 이를 찾아낼 수 있음

- 프로그램에 오자(type error)가 있는 경우 이를 찾아낼 수 있음

---

테스팅 프로세스

테스트 계획 -> 테스트 설계 -> 테스트 실행 -> 결과분석 및 평가

 

1. 테스팅 계획

- 테스트 계획은 프로젝트 계획서, 요구사항 명세서를 바탕으로 테스트의 목표를 수립하고, 테스트 대상 및 범위를 선정하는 활동

- 최상위 테스트 계획서(Master Test Plan)는 전체적인 테스트 지침 문서

- 각 테스트 단계 별로(ex. 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트)로 테스트 계획서 작성

 

2. 테스팅 설계

- 테스트에 사용할 특정한 입력값을 테스트 케이스라 부름. 테스트에 필요한 최적의 입력값을 찾아내는 것을 테스트 케이스 설계 또는 간단히 테스트 설계라고 함

- 훌륭한 테스트 설계는 적은 수의 테스트 케이스를 사용하여 오류를 검출할 확률이 높도록 구성

- 테스트 설계서, 테스트 케이스 명세서 작성 확인

 

3. 테스트 실행

- 테스트 계획 단계에서의 계획서와 테스트 설계 단계에서의 테스트 케이스 설계서, 테스트 절차서를 기반으로 구현된 소프트웨어를 구동시켜 테스트를 실시하는 단계

- 실제 테스트를 수행하고 그 결과를 기록한 테스트 상황기록 문서 생성

 

4. 테스트 결과 분석 및 평가

- 테스트 활동의 결과와 얻어진 출력값을 분석하여 테스트 성공 여부에 대하여 평가하고 권고 사항을 작성

- 프로젝트에서 정의한 각각의 테스트 단계에 대한 테스트 보고서 작성 (단위 테스트 보고서, 인수 테스트 보고서)

- 테스트 사건 보고서, 테스트 요약 보고서