테스트의 종류는 여러가지 분류기준에 따라서 다양하게 이름 붙여질 수 있다.
이 글에서는 아래와 같이 테스트 종류를 구분하고 정리할 것이다.
- 블랙박스 테스트 vs 화이트박스 테스트
소프트웨어 내부 구조가 어떻든 간에 외부로 나타나는 현상만을 기준으로 테스트한다.
화이트박스(White Box) 테스트
소프트웨어 내부 구조를 잘 이해하는 사람이 겉으로 들어나지 않는 기능들을 테스트한다.
- 기능 테스트 vs 비기능 테스트
소프트웨어의 기능을 확인하는 테스트한다.
비기능(Non-functional) 테스트
소프트웨어 기능외에 비기능적인 것을 테스트한다. 예를 들면 성능(Performance)이나 안정성(Stability) 등을 테스트한다.
이렇게 4개의 영역으로 테스트를 분류하고 각각의 테스트를 배치하면 아래 그림과 같이 분류할 수 있다.
- 인수 테스트(Acceptance Test)
그래서 요구사항(Requirements)을 분석하여 테스트 항목을 추출한다.
인수 테스트는 나중에 프로젝트 종료를 결정짓는 중요한 기준이 되기 때문에 프로젝트 초기부터 관리가 되어야한다.
- 시스템 테스트(System Test)
시스템 테스트는 고객의 요구사항(Requirements)을 만족시키기 위해 필요한 내용은 모두 테스트 범위에 포함시킨다.
다만 통합 테스트(Integration Test)처럼 화이트박스 테스트는 아니고 블랙박스 관점에서 테스트 항목을 추출하여 테스트한다.
- 통합 테스트(Integration Test)
개별 컴포넌트만 테스트할 때는 확인할 수 없는 부분을 확인하기 위한 테스트이다.
- 유닛 테스트(Unit Test)
개발자가 작성한 함수(Function)의 기능 하나 하나를 테스트한다.
그렇기 때문에 코드를 가장 잘 이해하고 있는 코드 작성자가 테스트를 주로 진행한다.
- UI 테스트(User Interface Test)
대상 UI 컴포넌트가 정상적으로 동작하는지 확인한다.
UI 테스트는 인수 테스트와 시스템 테스트에 모두 포함되어 있다.
- 시나리오 테스트(Scenario Test)
사용자의 사용 시나리오를 바탕으로 테스트 시나리오를 작성하여 테스트를 수행한다.
시나리오 테스트는 인수 테스트와 시스템 테스트에 모두 포함되어 있다.
- 성능 테스트(Performance Test)
그래서 성능에 대한 기준을 정하는 것이 매우 중요한데 요구사항에 성능이 정의되어 있으면 요구사항을 기준으로 삼아야한다.
만약 요구사항에 성능이 정의되어 있지 않다면 고객과 합의를 통해 성능기준을 개발초기에 정의해야 한다.
예를 들면 "웹 페이지(Web Page)의 반응 속도는 5초를 넘지 말아야 한다." 등의 경우가 성능 기준이라고 할 수 있다.
- 안정성 테스트(Stability Test)
안정성 기준이 요구사항에 정의되어 있다면 요구사항을 기준으로 삼아야 하지만 그렇지 않다면 일반적인 성능을 토대로 고객과 합의하여 기준을 정해야 한다.
예를들면 "1000명이 동시접속하여 24시간 사용하여도 시스템이 다운되지 않아야 한다." 등의 경우가 안정성의 기준이라고 할 수 있다.
- 스모그 테스트(Smoke Test)
즉, 아주 기본적인 기능을 확인하는 테스트이다.
그렇기 때문에 스모그 테스트를 통화하지 못하면 그 외의 테스트는 수행할 가치가 없다고 판단하면 된다.
그래서 스모그 테스트는 모든 테스트를 수행하기 전에 선행되어 하는 테스트이다.
- 몽키 테스트(Monkey Test)
주로 UI 컴포넌트(Component)에 무작위로 클릭 이벤트(Click Event)를 전송하여 시스템에 오류가 발생하는지 확인하는 테스트이다.
그렇기 때문에 테스트 수행은 일정시간 테스트를 수행하고, 그 동안 시스템에 오류 발생했는지 여부로 통과(Pass)와 실패(Fail) 을 판단한다.
- 사용성 테스트(Usability Test)
다시 말해서 기능적인 부분을 확인하는 것이 아니고 사용자가 불편하게 느낄 수 있는 부분들을 찾아내는 테스트이다.
그렇기 때문에 테스트 자동화가 거의 불가능한 부분이고, 전문 UX 엔지니어가 테스트를 수행해야 한다.
- 스트레스 테스트(Stress Test)
스트레스 테스트는 요구사항을 만족시키는 목적보다는 제품의 사양(Specification)을 확인하기 위한 테스트라고 할 수 있다.
예를들면 소프트웨어에 동시접속자의 숫자를 늘려가면서 웹 페이지(Web Page)의 반응속도를 테스트하고 기록한다.
이렇게 기록된 웹 페이지 반응속도는 소프트웨어나 하드웨어의 성능을 개선하는 기준자료가 될 수 있다.
따라서 스트레스 테스트는 비 정기적인 이벤트(Event)성으로 수행되는 경우가 많다.
- 인터페이스 테스트(Interface Test)
개별적으로 개발된 모듈을 통합하여 연결했을 때 발생하는 오류를 확인하는 테스트이다.
- 회귀 테스트(Regression Test)
한번 발생한 오류는 다시 또 발생될 확률이 높다는 아이디어에서 발생한 테스트이다.
그래서 기능 테스트중 가장 큰 범위에 걸쳐 있는 테스트이다.
어떤 버그(Bug)가 발생하고 해결되면 동일한 버그(Bug)가 발생하는지 확인할 수 있는 테스트 항목이 있어야 한다.
그래서 만약 이미 존재하는 테스트이면 회귀 테스트(Regression) 라벨(Label)을 달아놓고, 그렇지 않다면 테스트 항목을 새로 추가하고 라벨(Label)을 달아 놓아야한다.
이렇게 라벨(Label)을 달아 놓고 주기적으로 회기 테스트를 수행해야 한다.
- 메모리 누수 테스트(Memory Leak Test)
장시간 소프트웨어를 방치하거나 또는 UI, Scenario, Monkey 테스트와 조합하여 메모리 누수를 확인한다.메모리 누수 현상이 발생하면 소프트웨어에 치명적인 문제를 일으킬 수 있기 때문에 이런 테스트를 통해 미리 탐지하는 것이다.
- 포지티브 테스트(Positive Test)
단위 테스트에서 테스트 대상 Function 에 정상적인 값들만 대입하여 확인하는 테스트이다.
포지티브 테스트에서 실패(Fail)가 나온다면 그 Function 은 구현이 이루어지지 않았다고 볼 수 있다.
- 네가티브 테스트(Negative Test)
단위 테스트에서 테스트 대상 Function 에 비정상적인 값들만 대입하여 확인하는 테스트이다.
네가티브 테스트에서 실패(Fail)가 나온다면 그 Function 은 에러처리가 더 필요한 것이다.
- 경계값 테스트(Boundary Test)
단위 테스트에서 테스트 대상 Function 에 경계값 근처의 값들을 대입하여 Function 이 제대로 대응을 하는지 확인하는 테스트이다.
경계값 근처에서 버그가 발생할 확률이 높다는 아이디어에서 만들어진 테스트이다.
소프트웨어 테스트를 나름대로 정리해보았다.
각각의 테스트에 대해서 그 동안의 경험을 토대로 분류한 것이다.
그래서 다소 자의적으로 해석한 부분이 있을 수 있다.
예를 들면 나는 안정성 테스트(Stability Test)를 인수 테스트(Acceptance Test)의 비기능 테스트(Non-functional)로 분류하였다.
그런데 몽키 테스트(Monkey Test)와 스트레스 테스트(Stress Test)도 안정성 테스트(Acceptance Test)의 한 종류로 해석한다면 안정성 테스트의 범위가 달라질 것이다.
이렇듯 해석하기에 따라서는 다르게 분류될 수도 있는 것이기 때문에 위의 분류는 내 개인적인 생각임을 밝혀둔다.
0 개의 댓글:
댓글 쓰기