개발 단계별 테스트 (단위, 시스템, 통합, 인수 테스트)

출처: 4. 개발 단계별 테스트 (단위, 시스템, 통합, 인수 테스트) (tistory.com)

단위테스트

통합테스트

시스템테스트

인수테스트

	대상	누가	환경	어떻게	대상	문서(산출물)
단위(컴포넌트)테스트	단위모듈	개발자	개발환경	White Box	최소단위함수, 모듈	요구사항정의서 개념/상세설계서 기능설계서 명세서 인터페이스 설계서
통합테스트	통합모듈	개발자	개발환경	Gray Box	외부 인터페이스연결 내부모듈간 연결	단위산출물 통합시험계획서/절차서/결과서
시스템 테스트	전체시스템	테스터(제 3자)	실환경(유사하게)	Gray Box	기능/비기능 테스트 * 비기능: 서능/신뢰성 테스트 도구사용 연계테스트 (입/출력모듈)	단위+통합산출물 실증시험계획서/절차서결과서 메뉴얼
인수 테스트	전체시스템	사용자, 고객	실환경	Black Box	출시 예정제품	단위+통합+시스템 산출물 결함리포트 결과보고서 피드백

 

 

 

- Validation 과 Verification 차이

 

Validation : 시스템이 사용자의 요구사항을 만족하며 개발되고 있는가?

Verification : 시스템이 명세를 만족하면서 개발되고 있는가?

 

 

단위 테스트 (Unit test or Component test)

 

- 테스트가 가능한 최소 단위로 나누어진 소프트웨어 (모듈, 프로그램, 객체, 클래스 등) 내에서 결함을 찾고 그 기능을 검증하는것.

- 구현 단계에서 각  모듈이 구현된 후에,  단위 테스트를 수행

- 모듈을 단독적으로 실행할 수 있는 환경이 필요하다.

 

"테스트 데이터"를 "테스트 드라이버"에 입력으로 넣고

"모듈"을 호출하고 모듈아래의 "테스트 스텁"들을 호출하여 연산을 하고

"모듈"은 "테스트 드라이버"에 실행결과를 반환.

 

테스트 드라이버란?

 

- 테스트 대상이 되는 모듈을 호출하여 준비한 테스트 데이터를 제공하고 모듈의 실행 결과를 받는 모듈

- 일반적으로 상향식 테스트에서 아직 통합되지 않은 상위 컴포넌트의 동작을 시뮬레이션 하기 위해 사용.

 

테스트 스텁이란?

 

- 호출되는 모듈의 개발이 완료되지 않은 경우, 호출하는 모듈을 시험하기 위해 생성한 더미 모듈.

- 함수와 헤더 등의 코드 루틴만 정의하고 내부 코드는 제한적으로 구현하거나 구현하지 않는 경우가 많음.

통합 테스트 (Integration Test)

 

- 모듈을 통합하는 과정에서 수행되는 테스트

- 모듈 간의 상호 작용이 올바르게 되는지를 검사하는 테스트

- 통합 테스트에서 오류가 발생되는 경우

* 개별적인 모듈에 대한 테스트가 불충분하여 오류가 발생한다.

* 개별 모듈에서 동일한 전역변수를 사용하는 등의 실수로 인해 모듈간의 예기치 못한 상호작용이 발생하여 오류가 발생한다.

 

통합 테스트 전략.

 

=> 빅뱅 통합

- 개별적인 모듈에 대해 단위 테스트를 수행한 후에 전체 시스템에 대해 한번에 통합테스트를 수행한다.

- 단시간에 테스트가 가능하나 오류가 발생했을 경우 오류가 발생한 모듈 및 원인을 찾기가 매우 어려움.

 

=> 점진적 테스트

- 한번에 모듈들을 통합하지 않고 점진적으로 모듈들을 통합하면서 테스트.

- 하향식 통합, 상향식 통합, 샌드위치 통합 방식이 있음.

 

==> 하향식 통합 (상->하)

- 시스템을 구성하는 모듈들의 계층 구조에서 가장 상위에 있는 모듈부터 시작하여 하위에 있는 모듈들을 점진적으로 통합하는 방식.

- 상위 모듈을 테스트할때 하위 모듈을 대치할 테스트 스텁이 필요하다.

1. 가장 상위 모듈을 테스트하기 위해 하위 모듈을 테스트 스텁으로 대치한 후 테스트 수행.

2. 깊이 우선 방식이나 너비 우선 방식을 사용하여 테스트 스텁을 한번에 하나씩 실제 모듈로 대치하고 추가된 모듈이 호출하는 하위 모듈을 테스트 스텁으로 대치한 후 회귀 테스트를 수행한다.

 

장점: 설계상의 오류를 빨리 발견할 수 있음. (위에서 부터 보기 때문에 전체적으로 체크가능)

단점: 많은 수의 테스트 스텁이 필요하고 만약 테스트 스텁의 비용이 많이 든다면 비효율적, 

블랙박스 테스트만을 사용하는 경우에는 하위모듈이 충분하게 테스트되지 않을 수 있음.

 

==> 상향식 통합 (하->상)

- 하위 모듈을 먼저 통합하고 상위에 있는 모듈들을 통합하는 방식으로, 테스트드라이버가 필요함.

1. 하위 모듈을 클러스터링한 후에 테스트 드라이버를 작성하여 테스트 수행.

2. 클러스터를 테스트한 후에 테스트 드라이버를 제거하고 결합.

3. 위 과정을 시스템이 완전히 통합될 때까지 반복하여 수행.

 

장점: 하위에 있는 모듈들을 충분하게 테스트할 수 있음.

테스트 스텁을 제공하는 비용이 들지않음.

단점: 설계오류를 조기에 발견하지 못함.

 

==>  샌드위치 통합.

- 상향식, 하향식 통합방식을 절충하여 통합하는 방식.

모듈별로 어떤경우는 테스트드라이버생성해서 상향식으로, 어떤경우는 테스트스텁을 생성해서 하향식으로 테스트.

 

 

 

 

시스템 테스트 (System test)

 

- 통합 테스트가 완료된 후에 완전한 시스템에 대해 수행하는 테스트.

- 단위 테스트나 통합테스트가 기능이 올바르게 수행되는지를 검증하는 것에 중점을 둔다면, 시스템 테스트는 시스템의 기능 측면에서 뿐만 아니라, 비기능적인 요구사항도 만족되는지를 검증한다.

 

* 비기능 : 사용성, 견고성, 신뢰성, 보안성, 성능

 

=> 견고성 테스트 (Robustness Test)

- 시스템이 비정상적인 경우에도 얼마나 동작이 원활하게 이루어지는가를 나타내는 속성.

- 네거티브테스트( 시스템이 기대하지 않는 입력들을 테스트 데이터로 이용 )

 

=> 신뢰성 테스트 (Reliability Test)

- 시스템이 어느 기간동안 요구되는 서비스를 제공하는 능력 측정.

- 가용성(availability): 시스템이 주어진 기간동안 서비스를 실제로 제공할 수 있는지를 나타내는 속성

ex) 가용성이 0.995이면 1000시간에 995시간 단위 동안 서비스를 제공한다는 뜻.

- 복구성: 이중화/백업/복구

- MTTF (mean time to failure): 시스템이 운영된 후 오류가 발생할 때 까지의 평균동작 시간.

ex) MTTF가 100이면 100시간단위 마다 1개의 오류가 발생할 수 있는것을 의미한다.

 

=> 성능 테스트 (Performance Test)

- Load Test

: 사전에 정의된 부하 모델을 기반으로 부하상태에서의 성능을 측정

- Stress Test

: 어플리케이션 및 서버 시스템의 성능적 한계를 측정.

- Endurance Test

: 시스템의 안정성 검증 (메모리 누수 등)

 

 

인수테스트 (Acceptance Test)

- 실제 사용자 환경에서, 사용자의 입장으로 테스트 수행.

- 인수 기준을 만족하는 가를 검사하는 것이 주요 목적이다.

- 시스템 테스트에서 사용한 테스트 케이스들을 이용할 수 있다.

- 인수테스트 유형에는 알파테스트/베타테스트가 있다.

 

* 알파테스트: 사용자에 의해 테스트하는데 개발자환경

* 베타테스트: 클로즈베타(제한된실유저, 실환경), 오픈베타(누구나실유저, 실환경)

 

 

==== 그 외 테스트 ====

* 스모크 테스트

: 빌드가 테스트할만한 수준인지를 확인하는 테스트.

모듈의 중요한 기능의 일부분, 화면이동 경로, 회귀테스트범위의 일부분 등을 체크하는 역할.

 

전체적으로 보면

단위테스트=>통합테스트=>시스템테스트=>인수테스트 인데

 

세부적으로 보면

단위테스트=>통합테스트=> (스모크테스트)+시스템테스트+(회귀테스트) => (스모크테스트)+인수테스트+(회귀테스트)

로 이루어진다.

 

* 회귀 테스트 (Regression Test)

- 소프트웨어가 수정된 후에 변경이 올바르게 되었는지를 검사하기 위한 테스트

- 프로그램 수정 전에 정상적으로 동작했던 기능들이 수정된 후에도 여전히 동작하는지 시험.

- 수정되기 전에 작성된 테스트 케이스를 실행하여 수정전의 기능들이 정상적으로 동작하는지 확인한다.

 

* 스크립트 테스트

- 테스트 계획 및 테스트 설계 후 테스트를 수행하는 방식

 

* 탐색적 테스트 (경험적 테스트)

- 테스트 계획이나 테스트케이스 설계 과정을 거치지 않고 테스터의 직관, 능력에 의지해 경험적으로 탐색하여 수행.

- 비형식적이고 창의적인 테스트

- 도메인 지식이 부족하면 테스트하기 어려움.