Black box testing

 

 

Black box, White box의 기준 : 코드의 내부를 아느냐 모르느냐

 

-Black box :

박스 안의 내용을 모른다,

코드가 어떻게 구현되는지 모르는 상황에서 테스트,

코드는 모르지만 명세는 가지고 있다,

소프트웨어의 명세에 기반하여 테스트하는 방법,

명세에 기술된 동작들은 다 커버하도록 테스트해야 한다,

코드는 모르고 명세만 보고 테스트하기 때문에 명세에 드러나있지 않은 구현상세 내용으로 인한 버그가 있을 때 찾지 못한다. = 명세와 관련한 오류는 찾을 수 있지만 명세와 관련 없는 오류는 찾을 수 없다.

 

-White box :

명세는 없지만 코드를 들여다 볼 수 있다,

코드에 기반하여 테스트 케이스를 설계하여 테스트.

코드에 구현된 것은 다 커버가 되도록 테스트해야 한다,

코드를 가지고 있음에도 불구하고 테스트 하지 못하는 경로가 있을 수 있고 그 오류는 찾을 수 없다.

 

두 방법은 서로 상호보완적이다.

 

 

-Black-box Testing

코드에 어떤 내용이 들어있는지 모른다.

명세 내용에 따라 int 아무거나 하나 설정해서 테스트 케이스를 진행한다.

ex) 123을 넣어서 잘 동작하는지 확인

 

1. 장점 :

1) 도메인에 집중한다.

2) 코드가 필요없다. => 테스트케이스 설계를 일찍 할 수 있다.

3) 논리적 오류를 잡는데 더 유리하다.

4) 테스트 대상의 크기에 상관없이 적용 가능하다.

 

 

2. 명세에서 테스트 케이스 만드는 과정

주어진 기능적인 명세에서

1) 독립적이고 테스트 가능한 특징들을 찾아낸다.

2) 테스트 가능한 각 특징들과 관련된 입력들을 찾아낸다.

3) 입력들의 조합을 가지고 테스트 케이스 명세를 만든다.

4) 테스트 케이스 명세에 부합하는 실제 구체적인 테스트 케이스들을 만든다.

 

예시1 : Usecase diagram 명세

독립적이고 테스트 가능한 특징 = 사용자 ID, 패스워드, 재입력 패스워드

 

 

특징들(사용자 ID, 패스워드, 재입력 패스워드)과 관련된 입력 = 정상 input, 비정상 input, 예외 input / 정상 패스워드, 비정상 패스워드, 예외 패스워드 / ...

 

 

정상, 비정상의 조합해서 테스트 케이스를 만든다.

취소선 ex) 3번, 4번 : 로그인 ID가 정상이고, 패스워드가 비정상이면 재입력된 패스워드를 고려하지 않고 바로 오류메시지를 보인다. 그래서 4번은 3번에 의해 커버가 되기 때문에 취소선이 그어졌다. => 비용 고려

 

 

테스트 케이스 명세에 대해서 실제 구체적인 테스트 케이스를 만든다.

실제 로그인 ID, 패스워드, 재입력 패스워드를 입력해서 구체적인 테스트 케이스를 만든다.

 

 

예시2 : State diagram 명세

모든 state transition(화살표)을 커버하고 잘 이루어지는지 검사하는 테스트 케이스를 만들어 보는 것