Thief of Wealth

 

단위테스트

통합테스트

시스템테스트

인수테스트

  대상 누가 환경 어떻게 대상 문서(산출물)
단위(컴포넌트)테스트 단위모듈 개발자 개발환경 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)

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

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

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

 

* 스크립트 테스트

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

 

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

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

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

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

 

 

2020.07.07 - [QA] - 6. 테스트 계획 요소

 

'개발 > QA' 카테고리의 다른 글

6. 테스트 계획 요소  (0) 2020.07.07
5. 소프트웨어 프로세스  (0) 2020.07.07
3. SW 테스트  (0) 2020.07.03
2. 결함(defect), Error, Fault, Failure 이란?  (0) 2020.07.03
1. SW품질이란?  (0) 2020.07.03
profile on loading

Loading...