테스트란?

요구사항 충족을 확인하는 행위

테스트를 하는 이유?

작성한 프로그램이 의도대로 작동하는지 검증하기 위해

어디서 테스트의 필요성을 왜 느꼈는가?

• 서버를 통해 API로 받아오는 값을 다루는 작업의 경우와 논리적 사고가 필요한 작업의 경우

• 경우의 수를 파악할 때 미흡함을 느낌

그래서(So?) Software Test Methodology

Testing Approach

Static Testing | 정적 테스팅

실제 시스템이 구현되기 전에 요구사항 정의서, 걸계서, 소스 코드 등의 개발 산출물을 테스팅 하는 것을 의미한다.

• 리뷰
  • 코드를 포함하여 소프트웨어 개발 및 테스트 산출물을 검토하고 테스팅 하는 방법이다.

Testing Levels

Unit Testing | 단위 테스팅

테스트가 가능한 (최소)단위로 나누어진 소프트웨어 내에서 결함을 찾고 그 기능을 검증하는 것이며, 개발 수명주기의 정황과 시스템에 의존적이면서도 시스템의 다른 부분에서 격리하여 독립적으로 수행해야 한다.

일반적으로 단위 테스팅은 코드를 중심으로 수행한다.

코드를 작성한 프로그래머가 직접 테스트에 참여하여, 결함을 발견 할 때마다 바로 수정하고, 결함에 대한 기록 과정은 생략하는 것이 일반적이다.

Integration Testing | 통합 테스팅

컴포넌트간의 인터페이스를 테스트 하는 것은 물론, OS, 파일 시스템, 하드웨어 또는 시스템간 인터페이스와 같은 시스템의 각기 다른 부분과 상호 연동하는 동작을 테스트 한다.

하나 이상의 테스트 레벨이 있을 수 있으며, 다양한 크기의 테스트 대상에 대해 수행될 수 있다.

System Testing | 시스템 테스팅

개발 프로젝트 차원(범위)에서 정의된 전체 시스템 또는 제품의 동작에 대해 테스트 하는 것이다.

테스팅에서 발견하지 못하여 발생할 수 있는 “환경특성 장애” 리스크를 최소화하기 위해서 시스템 테스팅은 가능한 범위에서 실제 최종 사용 환경 또는 이와 유사한 환경에서 수행해야 한다.

시스템 테스팅은 기능 및 비기능 요구 사항을 모두 검증해야 한다.

Acceptance Testing | 인수 테스팅

시스템을 사용하는 고객이나 사용자가 전담하여 수행하는 경우가 대부분인데, 다른 이해관계자도 참여할 수 있다.

시스템을 배포하거나 실제 사용할만한 준비가 되었는지에 대해 평가한다.

• 목적

  • 시스템이나 시스템의 일부 또는 특정한 비기능적인 특성에 대해 “확신”을 얻는 것