테스트레벨과 테스트타입의 차이는, 조금 헷갈릴 수도 있는 내용이기도 합니다.
테스트 레벨과 테스트 타입에 대해 기재해보겠습니다.
Test Level and Test Type
테스트레벨과 테스트타입의 차이는, 조금 헷갈릴 수도 있는 내용이기도 합니다.
- Test Level : 테스트 대상 아이템의 통합정도에 따라 구분지을 수 있는 테스트활동의 단계
- Test Type : 특정 테스트 목적을 실현하기 위한 테스트 케이스 혹은 테스트의 집합
Test Level
테스트 대상 아이템의 통합정도에 따라 구분지을 수 있는 테스트활동의 단계를 의미합니다. 테스트 레벨은 개발을 진행해나가는 활동, 즉 요건정의 기본설계, 상세설계 등과 관련지을 수 있을 것 입니다.
그렇다면 테스트레벨에는 어떠한 것들이 있을까요?
1. Component Test / Unit Test
보통 컴포넌트 테스트, 유닛 테스트라고 부르는, 개별적으로 테스트가능한 컴포넌트들을 테스트하는 단계 라고 생각하시면 됩니다. 테스트 대상은 보통 메소드나 클래스 단위의 코드나 데이터 구조 등이 해당됩니다.
유닛테스트를 실행하는 목적은 아래와 같습니다.
- 컴포넌트의 기능/비기능 동작이 설계대로인지
- 해당 컴포넌트에 결함은 없는지 확인하기 위해.
보통 이 부분은 개발자들이 직접 테스트코드를 작성하여 확인하는 것이 일반적입니다.
2. Integration Test
결합테스트는 컴포넌트간의 결합 혹은 시스템 간의 결합으로 크게 2가지로 나누어볼 수 있습니다만, 보통은 전자의 뜻으로 많이 통용됩니다.
결합테스트를 실행하는 목적은 아래와 같습니다.
- 테스트 대상간의 인터페이스에 존재하는 결함을 찾아내기 위해.
- 인터페이스의 기능/비기능 동작이 설계대로 동작하는지 확인하기 위해
입니다.
TestBase로는
- 소프트웨어 설계서
- 시스템 설계서
- 시퀀스 다이어그램
- 인터페이스 혹은 통신 프로토콜 스펙
- 유스케이스
- 외부 인터페이스 정의서
등이 있을 수 있으며, 테스트 대상은 보통 데이터베이스나 인터페이스, API등이 해당됩니다. 결합테스트도 많은 부분을 개발자들이 직접 확인을 하나, 경우에 따라서는 QA/Tester가 확인하기도 합니다.
3. System Test (E2E Test)
시스템 테스트는 시스템이나 프로덕트 전체의 동작을 확인하는 단계입니다. 시스템의 전체. 끝에서 끝까지 본다는 의미로 E2E(End to End) Test라고도 하기도 합니다.
시스템 테스트를 하는 목적은 아래와 같습니다.
- 시스템이 완전하며 기대한대로 동작하는지 확인하기 위해
- issue를 실제 동작환경으로 놓치지 않도록 하기 위해
TestBase로는
- 기능/비기능 요구사항 명세서
- 유스케이스
- 시스템 매뉴얼, 유저 매뉴얼
- Epic 혹은 User-story
등이 있습니다. 테스트 대상으로는 보통 System / Application / Product 등이라고 정의할 수 있는, 큰 단위의 결합된 완전한 소프트웨어입니다.
4. Acceptance Test
인수테스트는 시스템 테스트와 마찬가지로 프로덕트나 시스템의 전체 동작을 확인합니다. 단, 이 단계는 실제 고객이 정의한 요구사항대로 동작하는지, 고객의 관점에서 혹은 고객이 직접 체크한다는 것이 시스템 테스트와 다른 점입니다. (고객에게 납품할 때 요구한대로 프로그램이 만들어져있는지)
인수 테스트의 목적은 앞서 말씀드린대로, 고객의 요구사항에 충족하는지 확인하기 위한 테스트이며, Testbase 역시 고객이 정의한 요구사항 명세서 혹은 법적계약서, 시스템 문서, 프로덕트 설치 순서 등이 기반이 됩니다.
Test Pyramid
테스트 레벨의 특징으로는 후반 (아래 그림에서는 상위단계)로 진행할 수록,
- Test에 소모되는 시간이 많아지며,
- Issue 발생 시에 소모되는 비용이 비싸진다
라는 점입니다.
때문에 빠른 단계 (아래 그림에서는 하위 단계)에서 최대한 많은 issue를 찾아낼 필요가 있습니다.
Test Type
특정 테스트 목적을 실현하기 위한 테스트 케이스 혹은 테스트의 집합입니다.
1. Functional Test (Blackbox Test)
기능테스트는, 정의된 요구사항대로 동작하는지를 검증하기 위한 테스트입니다.
TestBase로는
- 요구사항 명세서
- 유스케이스
- Epic or User-story
등이 있습니다. 보통 기능테스트를, 블랙박스 테스트(Blackbox test) 라고 하기도 하는데요, 내부 구조 상태를 모르는 상태에서 (Blackbox) 진행하는 테스트입니다.
기능테스트를 진행할 때 사용하는 테스트 기법들로는
- 동치분할법
- 경계값 분석
- Decision Table
- Sequence test
등이 있겠습니다.
기능테스트를 수행하기 위해서는, 비즈니스 요건, 기획 요건 등, 소프트웨어 혹은 기능이 구현되게 된 계기를 깊게 이해하고 있다면 좀 더 수월하고 올바른 테스트를 진행할 수 있을 것입니다.
2. Non-Functional Test
비기능테스트는, 기능 이외의 것을 검증하는 테스트입니다. 즉 "무엇을 하는지" 를 확인하는 것이 아닌, "어떻게 동작하는지" 를 확인합니다. 컴포넌트나 시스템의 특성을 주로 확인합니다.
보통 Testbase로는 계측/평가가 가능한 항목이 기재된 문서들이며, 정량적으로 정의된 항목을 측정하여 수치화하고 그것을 평가하게 됩니다.
좀 더 세부적으로 나누어보면 아래와 같을 것 입니다.
- Performance test : 성능 테스트
- Load test : 부하 테스트(성능 테스트의 일종, 예측가능한 사용량의 최저치, 평균, 최고치 등을 확인)
- Stress test : 스트레스 테스트 (특정한 부하, 메모리 혹은 서버의 리소스의 가용성을 확인)
- Interoperability test : 상호운용성 테스트 (각각의 컴포넌트나 시스템 간의 interface등을 확인)
- Maintainability test : 유지보수 테스트 (얼마만큼 유지보수가 원활한지
- Reliability test : 신뢰성 테스트 (지정된 조건에서 지정한 기간동안 실행이 원활한지. System down이 발생하지 않는지.)
- Security test : 보안 테스트 (데이터 액세스 권한 등을 확인)
3. Structural Test (Whitebox Test)
구조적 테스트는 시스템 내부 구조나 구현을 기반으로 하여 테스트케이스를 작성하고 실시하는 테스트입니다. 컴포넌트 혹은 시스템의 구조가 올바르며 요구사항대로 구현되어있는지를 확인하는 것이 주 목적입니다. 내부구조를 파악하고 실시하기 때문에, 화이트 박스 테스트(Whitebox test) 라고도 하기도 합니다.
TestBase로는
- Source code
- Work flow
- Data flow
- Control flow
- Architecture diagram
등이 있습니다.
보통 이 구조적테스트가, Test Coverage를 측정하기에 용이합니다. (해당 기능이 테스트가 되었는지, 테스트에 문제가 없는지를 코드레벨 단위로 알 수 있기 때문)
4. Confirmation and Regression Test
변경부분 테스트 혹은 회귀 테스트는, 테스트를 진행하면서 발생한 issue를 수정 및 기존 기능에 추가로 기능 추가 및 변경이 발생하였을 때, 기존의 기능에 issue가 없는지 다시 한 번 확인하는 테스트입니다.
보통은 테스트 후반 부에 실시하는 경우도 있습니다만, 코드의 Refactoring과 같은 작업이 발생했을 시에도, 실시하기도 합니다.
또한 OS의 변경, 브라우저의 버전 업, 데이터베이스의 버전업 등과 같이 환경적 변경요인이 발생하였을 때도 실시합니다.
Test level과 Test Type의 관계
- Test level에는, Test type이 포함됩니다. (종속적인 관계)
- 모든 Test Type은, 모든 Test level에서 실시할 수 있습니다.
- 모든 소프트웨어 / 시스템 / 프로덕트에 대해 각 Test level에서 모든 Test type을 적용하여 실시할 필요는 없습니다.
또한, 적용이 필요한 Test Type이 있다면, 되도록 빠른 Test level에서 실행하는 것이, 수정 Cost를 절약할 수 있습니다.
Ref
