[SW공학] 다양한 종류의 SW 테스트 분류 및 정의

💡 본 문서는 '다양한 종류의 SW 테스트 분류 및 정의'에 대해 정리해놓은 글입니다.
개발한 SW에 대해 한가지 관점으로 테스트를 하게된다면, 다른 부분에 있어서 여러 문제가 발생할 수 있습니다. 이를 예방하고 이에 대한 관점을 넓히기 위해서는 다양한 종류의 SW 테스트에 대해서 아는 것이 중요합니다. 해당 문서에서는 다양한 SW 테스트를 분류하고 정리하였으니 참고하시기 바랍니다.

1. SW 테스트 분류 기준

테스트의 종류는 여러가지 분류기준에 따라서 다양하게 이름 붙여질 수 있으며, 다양한 종류의 테스트를 먼저 아래와 같이 구분하고 정리할 것입니다.

1.1 블랙박스 테스트 vs 화이트박스 테스트 

블랙박스(Black Box) 테스트: 소프트웨어 내부 구조가 어떻든 간에 외부로 나타나는 현상만을 기준으로 테스트합니다.

화이트박스(White Box) 테스트: 소프트웨어 내부 구조를 잘 이해하는 사람이 겉으로 들어나지 않는 기능들을 테스트합니다.

1.2 기능 테스트 vs 비기능 테스트 

기능(Functional) 테스트: 소프트웨어의 기능을 확인하는 테스트합니다.

비기능(Non-functional) 테스트: 소프트웨어 기능외에 비기능적인 것을 테스트합니다. 예를 들면 성능(Performance)이나 안정성(Stability) 등을 테스트한다.

이렇게 4개의 영역으로 테스트를 분류하고 각각의 테스트를 배치하면 아래 그림과 같이 분류할 수 있습니다.

2. 다양한 SW 테스트 (대분류)

보통 소프트웨어는 'V-모델'에 따라 개발하곤 합니다(최근에는 Agile 개발 방법론을 사용하여 더욱 빠른 주기를 가지긴 합니다만). 요구사항을 파악하고, 분석하여, 아키텍트를 디자인하고, 구현합니다. 소프트웨어 테스트에 있어서는 역순으로 진행하여 단위테스트, 통합테스트, 시스템 테스트, 인수테스트로 진행하고 구분합니다. 

2.1 단위 테스트(Unit Test): 모듈 확인

• 모듈 테스트라고도 하며, 시스템에서 타스트 가능한 가장 작은 단위 기능에 대해 확인하는 테스트입니다.
• 개발자가 작성한 클래스, 함수(Function)들을 테스트 대상으로 봅니다.
• 그렇기 때문에 코드를 가장 잘 이해하고 있는 코드 작성자가 테스트를 주로 진행합니다.

2.2 통합 테스트(Integration Test): 인터페이스 확인

• 개발된 각 컴포넌트(Component)를 통합하면서 발생할 수 있는 버그를 확인하기 위한 테스트입니다.
• 개별 컴포넌트만 테스트할 때는 확인할 수 없는 부분인 컴포넌트나 서브시스템과 같은 통합 단위를 테스트합니다.

2.3 시스템 테스트(System Test): 기능 확인

• 전체 시스템 관점에서 구현된 시스템이 정해진 요건에 적합한지 평가하기 위해 테스트를 수행합니다.
• 시스템 테스트는 고객의 요구사항(Requirements)을 만족시키기 위해 필요한 내용은 모두 테스트 범위에 포함시킵니다.
• 실제 운용과 같은 환경에서 시스템 전체에 대해 블랙박스 관점에서 테스트 항목을 추출하여 테스트한다.

2.4 인수 테스트(Acceptance Test): 요구 확인

• 고객의 요구사항(Requirements) 을 만족하는지 여부를 확인하는 테스트로 요구사항(Requirements)을 분석하여 테스트 항목을 추출합니다.
• 인수 테스트는 나중에 프로젝트 종료를 결정짓는 중요한 기준이 되기 때문에 프로젝트 초기부터 관리가 되어야 합니다.
• 설치 후 구입자의 현장에서 납품자도 참가하여 구입자에 의해 실시되는 시스템 또는 기능 단위의 테스트입니다.

+ 회귀 테스트(Regression Test)

• 변경, 결함 수정, 기능개선 등과 같은 원인으로 프로그램 코드에 대하여 물리적인 변경이 발생했을 경우, 새로운 결함에 대비하여 이미 실시했던 테스트케이스에 대하여 전체 또는 일부를 재시험하는 테스트입니다.
• 한번 발생한 오류는 다시 또 발생될 확률이 높다는 아이디어에서 발생한 테스트이다.
• 어떤 버그(Bug)가 발생하고 해결되면 회귀 테스트(Regression) 라벨(Label)을 달아놓고 주기적으로 회기 테스트를 수행해야 합니다.

3. 다양한 SW 테스트 정의

3.1 단위 테스트 (Unit Test)

위에서 설명한 단위 테스트 (Unit Test)의 종류에는 Positive Test, Negative Test, Boundary Test 가 있습니다.

3.1.1 포지티브 테스트(Positive Test)

• 정상적인 값을 대입하여 정상적인 결과가 나오는지 확인하는 테스트입니다.
• 단위 테스트에서 테스트 대상 Function 에 정상적인 값들만 대입하여 확인하는 테스트로 실패(Fail)가 나온다면 그 Function 은 구현이 이루어지지 않았다고 볼 수 있습니다.

3.1.2 네가티브 테스트(Negative Test)

• 비정상적인 값을 대입하여 에러처리가 제대로 이루어지는지 확인하는 테스트입니다.
• 단위 테스트에서 테스트 대상 Function 에 비정상적인 값들만 대입하여 확인하는 테스트로 실패(Fail)가 나온다면 그 Function 은 에러처리가 더 필요한 것이다.

3.1.3 경계값 테스트(Boundary Test)

• 경계값, 경계값 보다 작은값, 경계값 보다 큰값을 사용하여 테스트로 경계값 근처에서 버그가 발생할 확률이 높다는 아이디어에서 만들어졌습니다.
• 단위 테스트에서 테스트 대상 Function 에 경계값 근처의 값들을 대입하여 Function 이 제대로 대응을 하는지 확인하는 테스트입니다.

3.2 통합 테스트(Integration Test)

위에서 설명한 통합 테스트(Integration Test)의 종류에는 Stress Test, Interface Test, Memory Leak Test 가 있습니다.

3.2.1. 인터페이스 테스트(Interface Test)

• 각 모듈(Module)간에 데이터가 정상적으로 오고 가는지를 테스트 합니다.
• 개별적으로 개발된 모듈을 통합하여 연결했을 때 발생하는 오류를 확인하는 테스트입니다.

3.2.2 메모리 누수 테스트(Memory Leak Test)

• 메모리 누수 현상이 발생하면 소프트웨어에 치명적인 문제를 일으킬 수 있기에 소프트웨어에 메모리 누수 현상이 발생하는지 확인하는 테스트입니다.
• 장시간 소프트웨어를 방치하거나 또는 UI, Scenario, Monkey 테스트와 조합하여 메모리 누수를 확인합니다.

3.2.3 스트레스 테스트(Stress Test)

• 소프트웨어의 한계치를 확인하는 테스트로 요구사항을 만족시키는 목적보다는 제품의 사양(Specification)을 확인하기 위한 테스트입니다.
• 이러한 스트레스 테스트는 소프트웨어나 하드웨어의 성능을 개선하는 기준자료로도 사용되며 비 정기적인 이벤트(Event)성으로 수행되는 경우가 많습니다.

3.3 시스템 테스트(System Test): 기능 확인

위에서 설명한 시스템 테스트(System Test)의 종류에는 UI Test, Scenario Test, Smoke Test, Monkey Test, Usability Test, Stress Test 가 있습니다.

3.3.1 UI 테스트(User Interface Test)

• 사용자의 인터페이스(Interface) 기능이 표준을 준수하여 적절히 설계되고 개발되었는지 하나 하나 확인하는 테스트입니다.
• 대상 UI 컴포넌트가 정상적으로 동작하는지 확인하며, 인수 테스트와 시스템 테스트에 모두 포함되어 있습니다.

3.3.2 시나리오 테스트(Scenario Test)

• UI 테스트가 개발 UI 컴포넌트에 대한 테스트라면 시나리오 테스트는 UI 테스트의 조합으로 이루어진 테스트입니다.
• 사용자의 사용 시나리오를 바탕으로 테스트 시나리오를 작성하여 테스트를 수행하며, 이는 인수 테스트와 시스템 테스트에 모두 포함되어 있습니다.

3.3.3 스모그 테스트(Smoke Test)

• 스모그(Smoke)는 연기를 뜻하는 것으로 하드웨어 보드에서 연기가 나는지 확인하는 것을 비유한 테스트이며, 즉 아주 기본적인 기능을 확인하는 테스트입니다. 그렇기 때문에 스모그 테스트를 통과하지 못하면 그 외의 테스트는 수행할 가치가 없다고 판단하면 됩니다.
• 그래서 스모그 테스트는 모든 테스트를 수행하기 전에 선행되어 하는 테스트입니다.

3.3.4 몽키 테스트(Monkey Test)

• 원숭이가 터치스크린을 무작위로 터치하는 것을 비유한 테스트이며, 주로 UI 컴포넌트(Component)에 무작위로 클릭 이벤트(Click Event)를 전송하여 시스템에 오류가 발생하는지 확인하는 테스트입니다.
• 그렇기 때문에 테스트 수행은 일정시간 테스트를 수행하고, 그 동안 시스템에 오류 발생했는지 여부로 통과(Pass)와 실패(Fail) 을 판단합니다.

3.3.5 사용성 테스트(Usability Test)

• 사용성 테스트는 UX(User Experience) 관점에서 테스트를 수행합니다.
• 다시 말해서 기능적인 부분을 확인하는 것이 아니고 사용자가 불편하게 느낄 수 있는 부분들을 찾아내는 테스트입니다.
• 그렇기 때문에 테스트 자동화가 거의 불가능한 부분이고, 전문 UX 엔지니어가 테스트를 수행해야 합니다.

3.4 인수 테스트(Acceptance Test): 요구 확인

위에서 설명한 인수 테스트(Acceptance Test)의 종류에는 UI Test, Senario Test, Performance Test, Stability Test가 있습니다.

3.4.1 성능 테스트(Performance Test)

• 소프트웨어의 성능이 기준을 만족하는지 확인하는 테스트입니다.
• 그래서 성능에 대한 기준을 정하는 것이 매우 중요한데 요구사항에 성능이 정의되어 있으면 요구사항을 기준으로 삼아야한다.
  만약 요구사항에 성능이 정의되어 있지 않다면 고객과 합의를 통해 성능기준을 개발초기에 정의해야 합니다.
• 예를 들면 "웹 페이지(Web Page)의 반응 속도는 5초를 넘지 말아야 한다." 등의 경우가 성능 기준이라고 할 수 있습니다.

3.4.2 안정성 테스트(Stability Test)

• 소프트웨어가 안정성 기준을 만족하는지 확인하는 테스트입니다.
• 안정성 기준이 요구사항에 정의되어 있다면 요구사항을 기준으로 삼아야 하지만 그렇지 않다면 일반적인 성능을 토대로 고객과 합의하여 기준을 정해야 합니다.
• 예를들면 "1000명이 동시접속하여 24시간 사용하여도 시스템이 다운되지 않아야 한다." 등의 경우가 안정성의 기준이라고 할 수 있습니다.

3.5 번외: 추가 테스트

+ 설치 테스트 (Installation test) 

• 테스트 대상이 사용시스템에 제대로 설치되는가를 검증하며 깔끔하게 제거되는지도 확인합니다. 

+ 복구 테스트 (Recovery Test)

• 하드웨어적 오류, 회로 오류, 정전, 프로그램 오류 등으로 야기되는 여타의 장애로부터 정해진 시간 내에 시스템이 어떻게 복구되는가를 시험합니다.
• 특히 회계 시스템에서는 어떠한 자료도 처리 도중 상실되어서는 안되기 때문에 불의의 모든 사고로부터 시스템이 복구되는 것이 절대적으로 중요하며 두가지 북구 시스템으로 나눕니다.
  • 1. 자동 복구 시스템: 재 초기화, 체크포인팅 메커니즘, 데이터 복구, 재시작 등이 정확하게 수행되는지 테스트합니다.
  • 2. 수동 복구 시스템: 복구까지 소요되는 평균시간이 수용가능한지 테스트합니다.

+ 데이터 저장 테스트 (Data Storage Test)

• 대용량의 데이터를 시스템에 입력시키고 그 반응을 시험하고 데이터의 양이나 파일 크기가 변함에 따라 시스템의 반응의 변화가 있는가를 테스트합니다.
• 이는 일상적 작업을 수행하는데 충분한 저장공간을 추정가능하도록 도와주는 테스트입니다.

+ 신뢰성 테스트 (Reliability Test) 

• 프로그램, 시스템, 또는 하드웨어 장치가 얼마만큼 실패 없이 주어진 기능을 수행하는가 또는 총 운용시간 대비 정상적인 기능을 수행한 시간이 어느 정도인지를 나타내는 가동률을 측정합니다. 
• 기능에 대하여 시스템 및 어플리케이션 이 Down되지 않고 안정적으로 수행되는지를 확인하는 테스트입니다. 

+ 보안 테스트(Security Test) 

• 최근 컴퓨터 시스템에 대한 각종 위협의 증가로 인하여 권한이 없는 사용자의 데이터 액세스 및 수정을 방지하기 위한 보안 기능은 필수적이므로 시스템상의 보안기능이 업무환경에 적절한가를 시험합니다. 
• 특히 외부 컴퓨터 네트워크와 커뮤니케이션이 있는 시스템인 경우 커뮤니케이션 메시지의 기밀성, 무결성, 사용자 인증, 접근통제, 부인봉쇄 등의 보안 기능이 적절하게 제공되고 있는지를 테스트합니다. 

+ 호환성 테스트(Compatibility Test)

• 현 시스템을 다른 하드웨어와 시스템 소프트웨어로 전환하거나 현재의 시스템에 중요한 새로운 기능을 추가하는 경우에 적용하며 변경사항으로 인해 발생할지도 모르는 결점에 대비하여 시스템의 모든 부분을 테스트합니다. 
• 이를 위해 새로운 시스템의 시험결과와 비교 할 수 있는 현재 시스템의 시험 결과의 보존이 필요합니다.

참고

• [Blog] SW 테스트의 종류 총정리하기: http://blog.kimssoft.com/2017/05/blog-post_24.html
• [Blog] 소프트웨어 테스트 기법 (1) - 기법 종류: https://parksh86.tistory.com/166