12. Testing

테스팅이란?

테스팅이란 프로그램을 실제로 사용하기 전에 결함을 찾아내는 과정을 의미한다. 역사에 기록된 소프트웨어 오류들(LINK)을 살펴보면, 출시 전 테스팅 작업이 얼마나 중요한지 새삼 깨달을 수 있다.

Untitled

테스팅 방법은 여러가지가 있다. 일반적 테스트, 정적 분석, 인스펙션, Formal proofs of correctness 등이다. 각자 장단점이 있으므로 본인에게 적합한 테스트를 선택하자.

테스트의 구조

테스트 방법을 사용할 때 주의할 점이 있다. 테스트는 버그가 있다(Presence)라는것은 잘 보여주는데, 버그가 없다(Absence)는 것은 보여주기 어렵다. 테스트 결과에 문제가 없다고 완전무결한 것이 아니라는 말이다. 그래도 테스트를 하는 이유는 비용 대비 효과가 좋기 때문이다.

Untitled

테스트의 구조는 위의 이미지와 같다.

  • Test Suite → 테스트 케이스들의 집합

    Untitled

  • Test Procedure/Test script → 테스트를 진행하는 전체 과정

  • Test Environment → 테스트 환경

    함수 하나만을 단독으로 테스트하기는 어렵다. 그 인자로 들어가는 계산이나 테스트하려는 함수를 감쌀 필요가 있기 때문이다. 이때 테스트에게 호출되는 함수를 Stub, 테스트를 호출하는 함수를 Driver라고 한다. 둘을 합쳐서 Test Harness라고 부르기도 한다.

  • IUT(Implementation Under Test) → 테스트 하려는 프로그램

테스트 케이스 설계

테스트를 설계할 때 주의해야 할 사항 3가지가 있다.

  • 결함을 찾으려는 목적성이 있어야 한다.
  • 빠지는 것 없이 온전한 방법이어야 한다.
  • 경제적으로 최소한의 테스트케이스를 사용해 시간과 비용을 절약해야 한다.

테스팅 vs 디버깅

둘의 의미를 혼동해서는 안된다.

  • 테스팅 → 문제가 발생하는지를 확인하는 것.
  • 디버깅 → 문제의 위치를 찾아내고 이를 해결하는 것.

테스팅 레벨

Untitled

규모에 따라서 테스팅 레벨 차이가 생긴다. 주의점만 짚어보자.

  • System testing → 개발자 입장에서 설계대로 제작되었는지 테스팅.
  • Acceptance testing → 고객 입장에서 요청대로 제작되었는지 테스팅.
  • Regression testing → 버전 변경시 기존 기능에 문제가 발생했는지 테스팅.

Untitled

공개 범위에 대해서도 레벨을 다르게 할 수 있다.

  • Developer → 개발자가 스스로 테스팅.
  • Alpha → 동료 개발자들과의 테스팅.
  • Beta → 실 사용자 표본과의 테스팅.
  • Product release → 실전 데이터.

블랙박스 테스트

앞서, 규모나 공개 범위 등에 차이를 두어 테스트를 진행하는 방법을 알아보았다. 이제는 명세서에 점검 기준을 두었는지, 코드 세부사항에 점검 기준을 두었는지를 기준으로 테스팅을 나눠보자.

Untitled

블랙박스 테스팅은 명세서만을 알고 소프트웨어 코드는 모르는 상태로 진행하는 테스팅이다. 명세서에 나온 내용들을 최대한 커버하는지 확인하는 것을 목적으로 한다. 명세서에 나타나지 않은 오류는 찾을 수 없다는 단점이 있다.

블랙박스 테스트의 장점

  • 명세서를 기준으로 하기에 소프트웨어의 목적(Domain)에 집중할 수 있다.
  • 코드가 없으니 구현 이전에도 테스트가 가능하다.
  • 논리결함을 발견하기 용이하다.
  • 클래스나 모듈같은 단위에 얽메이지 않는다.

블랙박스 테스트 수행법

  1. 독립적으로 특정 가능한 특징들을 찾는다.
  2. 특징과 관련된 입력을 찾는다.

  3. 입력 조합을 통해 테스트케이스 명세서를 제작한다.

    → 각 선택 조합, 모든 조합, Pairwise 조합 등의 조합법이 있다.

  4. 테스트케이스 명세서에 기반한 구체적 테스트케이스를 제작한다.

화이트박스 테스트

Untitled

화이트박스 테스트는 명세서는 모르지만 내부 코드를 알고있기에, 이를 기반으로 테스트하는 것을 의미한다. 코드로 구현된 내용들을 최대한 커버하는 것을 목표로 한다. 다만 테스트케이스의 양이 많기에 자원이 많이 소모된다.

화이트박스 테스트의 장점

  • 테스트간의 비교가 가능하다.
  • 코드를 베이스로 하므로 객관적인 추적이 가능하다.

화이트박스 테스트 작성법

Untitled

이러한 제어 흐름 그래프(Control-flow Graph)를 사용한다. 제어흐름 그래프는 커버 범위에 따라서 테스트 케이스의 수가 달라지는데, 커버 범위의 종류는 아래와 같다.

Untitled

각 종류별 설명은 다음에 추가하겠다.

참고자료