소프트웨어 테스팅의 종류

업무상 필요해 소프트웨어 테스트의 종류에 대해 조사하다가 일목요연하게 잘 정리된 글을 발견했다. 각 항목들에 대해 최소한의 정의들로만 구성되어 있어 논란의 여지가 남아있는 항목도 있다. 아직까지도 정확한 단어 사용이 힘들지만, 여기에 사용된 단어의 정의에 대해서는 업계의 대다수 사람들이 공감할 수 있으리라 생각된다.

 

Happy Testing!!!

출처: http://www.softwaretestinghelp.com/types-of-software-testing/

 

블랙 박스 테스팅(Black box testing) – 시스템의 내부 설계(Internal system design)는 이 테스팅 유형에서 고려할 대상이 아니다. 테스트는 요구사항(Requirement) 및 기능성(Functionality)에 기반해서 이루어진다.

 

화이트 박스 테스팅(White box testing) – 이 테스팅은 애플리케이션의 코드 내부의 로직(Logic)에 대한 지식을 기반으로 수행된다. 글래스 박스(유리상자 혹은 투명상자) 테스팅으로도 알려져 있다. 이 유형의 테스팅을 수행하기 위해서는 내부적으로 소프트웨어와 코드가 어떻게 동작하는지를 알고 있어야만 한다. 화이트 박스 테스트는 코드 구문(Statements), 분기(Branches), 경로(Paths), 조건(Conditions) 커버리지 등으로 분류할 수 있다.

 

유닛 테스팅(Unit testing) – 각각의 소프트웨어 컴포넌트나 모듈 대상 테스팅을 의미한다. 일반적으로 테스터가 아니라 프로그래머에 의해 수행되며, 이를 수행하기 위해서는 프로그램 내부에서 수행되는 코드와 프로그램 설계에 대해 매우 해박한 지식을 가지고 있어야 한다. 테스트 드라이브 모듈(Test drive modules)이나 테스트 하네스(Test harnesses) 개발이 필요할 수도 있다.

 

점진적인 통합 테스팅(Incremental integration testing) – 바텀업(Bottom up) 방식의 테스팅. 예를 들어, 애플리케이션에 새로운 기능이 추가되는 것에 대해 지속적으로 이어지는 테스팅과 같은 것이다. 애플리케이션의 기능성과 모듈은 이미 각각 충분히 테스트 되어있는 상태여야 한다. 프로그래머 혹은 테스터에 의해 수행된다.

 

통합 테스팅(Integration testing) – 통합 이후에 결합된 기능들을 검증하기 위한 통합 모듈 테스팅. 여기서 모듈은 일반적으로 코드 모듈, 개별 애플리케이션, 네트워크 상의 클라이언트와 서버 애플리케이션 등이 될 수 있다. 이 유형의 테스팅은 특히 클라이언트/서버 및 분산 환경 시스템에 적절하다.

 

기능 테스팅(Functional testing) – 이 유형의 테스팅은 내부적인 부분을 무시하고 결과값이 요구사항대로 나왔는지, 혹은 그렇지 않은지에 초점을 맞춘다. 블랙박스 타입의 테스팅이 애플리케이션의 기능 요구사항 검증에 적합하다.  

 

시스템 테스팅(System testing) – 각각의 요구사항에 대해 전체 시스템이 테스트된다. 전체 요구사항 명세에 기반한 블랙 박스 타입의 테스팅으로 모든 조합 가능한 시스템의 부분들을 커버한다.

 

엔드-투-엔드 테스팅(End-to-end testing) – 시스템 테스팅과 유사하며, 데이터베이스와 네트워크 커뮤니케이션의 사용, 혹은 다른 종류의 하드웨어, 애플리케이션, 혹은 시스템에 대한 상호 작용과 같은 실제 사용자 환경을 모방한 환경에서 사용되는 모든 애플리케이션에 대한 테스팅을 포함한다.

 

새너티 테스팅(Sanity testing) – 새로운 소프트웨어 버전이 주요 테스팅 업무를 수행하기에 충분히 적합한가를 판단하기 위해 수행하는 테스트. 만약 애플리케이션에서 사용 초기에 크래시(Crash)가 발생한다면, 시스템은 더 이상의 테스팅을 수행할 정도로 충분히 안정적이라고 말할 수 없으며, 빌드 혹은 애플리케이션은 이 부분을 수정해야 한다.

 

리그레션 테스팅(Regression testing) – 애플리케이션의 모든 모듈 및 기능에 대한 수정 사항을 테스팅 하는 것. 리그레션 테스팅에서 모든 시스템을 커버하는 것은 무척 어려운 일이므로 일반적으로 이러한 유형의 테스팅에는 자동화 테스팅이 사용된다.

 

인수 테스팅(Acceptance testing) – 일반적으로 이 유형의 테스팅은 시스템이 고객이 명세한 요구사항을 충족했는지를 검증하기 위해 사용된다. 사용자 혹은 고객이 애플리케이션을 인수(Accept)할 것인지를 결정하기 위해 수행한다.

 

부하 테스팅(Load testing) – 어느 지점에서부터 시스템의 반응 시간이 지연되거나(Degrades), 혹은 반응이 실패하는지를 알아보기 위해 부하의 범위 안에서 웹 사이트를 테스트 하는 것과 같은, 부하가 걸리는 상황 하에서 시스템의 동작을 검사하기 위해 수행하는 일종의 퍼포먼스 테스트.

 

스트레스 테스팅(Stress testing) – 명세에서 허용된 것 이상의 스트레스를 가해서 어떻게 그리고 언제 시스템에서 장애가 발생하는지를 체크하기 위한 테스트. 저장 용량을 초과하는 데이터를 저장하거나, 복잡한 데이터베이스 쿼리를 입력하거나, 시스템에 지속적으로 입력값을 입력하거나 혹은 데이터베이스에 부하를 거는 것과 같은 심각한 부하를 주는 테스트를 수행한다.

 

퍼포먼스 테스팅(Performance testing) – ‘스트레스’ 혹은 ‘부하’ 테스팅과 종종 혼용되어 사용되는 단어. 시스템이 퍼포먼스 요구사항을 충족하는지 검증하는 행위이다. 이를 위해 각기 다른 퍼포먼스와 부하 툴을 사용한다.

 

사용성 테스팅(Usability testing) – 사용자 친화적(User-friendliness)인지를 점검하는 것. 애플리케이션의 플로우와 신규 사용자들이 쉽게 애플리케이션을 이해할 수 있는지, 사용자가 원하는 어떤 시점에서도 적합한 도움말이 제공되는지 등이 테스트된다.

 

설치/삭제 테스팅(Install/uninstall testing) – 각기 다른 하드웨어와 소프트웨어 환경 및 다른 OS 하에서 전체, 부분, 혹은 업그레이드 설치/삭제 프로세스를 테스트한다.

 

회복 테스팅(Recovery testing) – 크래쉬, 하드웨어 장애 혹은 다른 심각한 문제들로부터 시스템이 어떻게 복구되는지를 테스트 하는 것

 

보안 테스팅(Security testing) – 해킹이 시스템을 뚫고 들어갈 수 있는지를 검증하는 것. 인가 받지 않은 내부 혹은 외부의 액세스로부터 시스템이 어떻게 스스로를 방어하는지에 대해 테스트한다. 외부 공격으로부터 시스템, 데이터베이스가 안전한지를 체크한다.

 

호환성 테스팅(Compatibility testing) – 특정한 하드웨어/소프트웨어/OS/네트워크 환경 및 각기 다른 조합 하에서 소프트웨어가 어떻게 동작하는지를 테스트한다.

 

비교 테스팅(Comparison testing) – 앞서 출시된 제품 혹은 유사한 제품과 비교해 제품의 장단점을 비교함

 

알파 테스팅(Alpha testing) – 이 유형의 테스팅을 위해 사내에서 가상 유저 환경이 조성될 수 있다. 개발의 마지막 부분에서 이 테스트가 수행된다. 이 테스팅의 결과로 사소한 디자인 변경 등이 이루어 질 수 있다.

 

베타 테스팅(Beta testing) – 일반적으로 엔드 유저에 의해 완료되는 테스팅. 상용화를 위한 애플리케이션 릴리즈 이전의 최종 테스팅이다.

 

Happy Testing!!!