Skip to content

테스팅 용어

테스팅의 기초

  • 테스팅: 소프트웨어 제품과 관련 작업 산출물이 특정 요구명세를 만족하는지 결정하고, 목적에 부합하는지 입증하고 결함을 찾아내기 위해 해당 산출물을 계획, 준비, 평가하는 정적/동적인 모든 수명주기 활동으로 구성된 프로세스
  • 커버리지: 특정한 커버리지 항목이 테스트 스위트에 의해 이행되는 백분율 정도
  • 디버깅: 소프트웨어에서 장애의 원인을 발견하고, 분석하여 제거하는 절차
  • 테스트 오라클: 테스트 대상 소프트웨어의 실제 결과와 비교할 목적으로 예상 결과를 결정하는 근거
  • 밸리데이션: 요구사항이 컴포넌트나 시스템을 특정하게 의도적으로 사용 또는 활용하는 것을 충족시키는지 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.
  • 베리피케이션: 명세된 요구사항이 충족되었는지를 조사에 의해서나 객관적인 증거 제공으로 확인하는 것.

    테스팅은 밸리데이션과 베리피케이션을 모두 포함하는 활동

오류, 결함, 장애

  • 오류: 부정확한 결과를 초래하는 인간의 활동
  • 결함: 필요한 기능을 수행하지 못하도록 하는 컴포넌트나 시스템 상의 결점. 결함의 예는 부정확한 구문이나 부정확한 데이터 정의 등이다. 실행 중에 결함이 발생할 경우, 컴포넌트나 시스템의 장애를 야기시킬 수 있다.
  • 장애: 컴포넌트나 시스템이 예상된 인도나 서비스 또는 예상 결과와 실제적인 편차를 보이는 것.
  • 근본 원인: 불일치를 유발하는 근원적인 요소. 이것은 프로게스 개선을 통해 영구적으로 제거할 수 있다.

품질

  • 품질: 컴포넌트, 시스템 또는 프로세스가 명시된 요구사항과 사용자/고객의 필요와 기대를 충족시키는 정도.
  • 품질 보증: 품질 요구사항이 충족될 것이라는 신뢰감을 제공하는 데에 집중하는 품질 관리의 한 부분.

테스트 프로세스

  1. 테스트 계획: 의도된 테스트 활동의 범위, 접근법, 자원 그리고 일정을 기술하는 문서. 테스트 계획은 다른 테스트 항목, 테스트 대상의 기능 및 특성, 테스팅 업무, 업무 담당 배정, 테스터의 독립성 정도, 테스트 환경, 사용할 테스트 설계 기법과 테스트 측정 기법, 선택의 근거, 그리고 긴급 대책을 요하는 모든 리스크를 식별한다. 테스트 계획은 테스트 기획 프로세스를 기록한 것이다.

    산출물: 테스트 계획

  2. 테스트 모니터링: 테스트 프로젝트의 상태를 정기적으로 점검하는 것과 관련된 활동을 다루는 테스트 관리 업무. 리포트는 실제(결과)를 계획한 것과 비교하여 준비된다.

    테스트 제어: 테스트 프로젝트에 계획 대비 차이가 나타나면 계획대로 진행되도록 정정 행동을 전개하고 적용하는 테스트 관리 업무.

    산출물: 테스트 진행 현황 보고서

  3. 테스트 분석: 테스트 베이시스를 분석하여 테스트 컨디션을 식별

    산출물: 테스트 컨디션, 테스트 차터

    테스트 베이시스: 요구사항을 내포하고 있는 모든 문서. 테스트 케이스는 테스트 베이시스를 토대로 만들어 진다. 문서가 오직 공식적 수정절차의 방법에 의해 수정될 수 있다면, 해당 테스트 베이시스를 동결 테스트 베이시스라 부른다

  4. 테스트 설계: 테스트 컨디션을 기반으로 상위 수준 테스트 케이스, 상위 수준 테스트 케이스 세트, 기타 테스트 웨어를 생성 (어떻게 테스트 할 지 결정)

    테스트 베이시스, 테스트 컨디션, 테스트 케이스 간의 양방향 추적성 설정

    산출물: 테스트 케이스

    테스트 케이스: 특별한 목표 또는 테스트 상황을 테스팅하기 위해 개발된 입력값, 실행 사전조건, 예상 결과, 실행 사후조건들의 집합. 특별한 목표와 테스트 상황은 특정 프로그램 경로를 실행하거나 지정된 요구사항을 준수하는지 검증하는 것을 의미한다.

  5. 테스트 구현: 테스트를 실행하기 위해 필요한 모든 것이 갖춰져 있는가 라는 질문에 답하는 활동

    산출물: 테스트 스위트

    테스트 스위트: 테스트 대상 컴포넌트나 시스템에 사용되는 여러 테스트 케이스의 집합. 테스트 스위트는 테스트 사후조건이 주로 다음 테스트를 위한 사전조건이 되는 테스트 케이스로 구성된다.

  6. 테스트 실행: 테스트 항목, 테스트 대상, 테스트 도구, 테스트 웨어 등의 고유 번호 (ID) 와 버전 기록

  7. 테스트 완료: 완료된 테스트 활동에서 데이터를 수집해서 경험, 테스트웨어, 기타 관련 정보를 축적하는 활동

    산출물: 완성된 테스트웨어

    테스트웨어: 테스트를 계획, 설계, 실행하는 테스트 프로세스동안 생성된 산출물. 테스트웨어는 테스팅에 사용되는 문서, 스크립트, 입력값, 예상 결과, 시작과 마무리 절차, 파일, 데이터베이스, 환경, 그리고 모든 추가적인 소프트웨어 또는 유틸리티를 포함한다.

소프트웨어 개발 수명주기와 테스팅

수명주기 모델에 적용하기 좋은 테스팅의 특성

  • 모든 개발 활동은 그에 상응하는 테스트 활동이 있다.
  • 각 테스트 레벨은 그 레벨에 맞는 구체적인 목적을 갖는다.
  • 주어진 테스트 레벨에 맞는 테스트 분석과 설계는 상응하는 개발 활동이 이루어지고 있는 동안 시작해야 한다.
  • 테스터가 요구사항과 설계의 정의와 개선을 위한 대화에 참여하고, 작업 산출물의 초안이 나오는 즉시 리뷰에 참여한다.

수명주기 모델

  • 순차적 개발
    • V 모델: 각 개발 단계에 테스트를 부여
  • 점진적, 반복적 개발
    • 래셔널 통합 프로세스(RUP): 몇 개월의 주기를 반복하며 개발
    • 스크럼: 며칠이나 몇 주의 주기를 반복하며 개발
    • 칸반: 칸반 보드로 진행상태나 사람, 업무 종류를 파악하는 방법
    • 나선형(프로토타이핑): 실험적인 증분을 만들며 개발

테스트 레벨

  • 테스트 레벨: 함께 편성되고 관리되는 테스트 활동의 그룹. 테스트 레벨은 프로젝트에서 책임과 연관되어있다.

  • 컴포넌트 테스트: 통합된 컴포넌트 간의 인터페이스와 상호작용에서의 결함

  • 통합 테스트: 통합된 컴포넌트나 시스템 간의 인터페이스와 상호작용에서의 결함

    • 컴포넌트 통합 테스팅: 컨포넌트 간의 통신
    • 시스템 통합 테스팅: 시스템간의 통신 장애나 인터페이스
  • 시스템 테스트: 명시된 요구사항을 만족하는지 확인하기 위해 통합된 시스템을 테스트 하는 절차. 컴포넌트나 부분 시스템이 하나의 시스템으로 동작하게 되면서 시스템 기능 및 성능과 관련된 고객의 요구사항이 완벽하게 수행되는지를 모든 시스템 구성요소를 통합한 후 평가한다.

    • 엔드 투 엔드 기능 작성을 테스트한다.
  • 인수 테스트: 비즈니스 프로세스, 사용자 또는 비즈니스 요구사항, 규제, 설치 절차를 평가한다.

    • 사용자 인수 테스팅 (UAT, User Acceptance Testing)
      • 실제 또는 시뮬레이션 도니 환경에서 사용자가 사용하기에 적합한지 확인
    • 운영 인수 테스팅 (OAT, Operational Acceptance Testing)
      • 운영자 또는 시스템 관리 직원에 의해 수행되는 테스팅
      • 백업 및 복원, 업그레이드, 복구, 데이터 이관 등을 테스트한다
    • 계약 및 규제 인수 테스팅
      • 계약 및 규제에 대한 테스팅
    • 알파, 베타 테스팅
      • 알파 테스팅: 개발조직 외부에 위치한 개발 환경 또는 개발자 사이트에서 잠재적 사용자, 고객 또는 독립된 테스트 팀에 의해 수행되는 가상 혹은 실제 운영상의 테스팅. 알파 테스팅은 내부 인수 테스팅의 한 형태로, 상용 소프트웨어 테스팅에 주로 적용된다.
      • 베타 테스팅: 컴포넌트나 시스템이 사용자/고객의 요구를 충족하는지, 비즈니스 프로세스에 적합한지 등을 결정하기 위해 개발자를 참여시키지 않고, 잠재/기존 고객(사용자)이 외부사이트에서 직접 수행하는 운용상의 테스팅. 베타 테스팅은 주로 상용 소프트웨어가 시장의 피드백을 얻기 위한 목적으로, 외부 인수 테스트의 한 형태로 수행된다.

테스트 유형

  • 기능 테스팅: 시스템이 해야하는 기능을 평가
    • 모든 테스트 레벨에서 수행, 블랙박스 기법 활용
  • 비기능 테스팅: 기능성과 연관시키지 않고 신뢰성, 효율성, 유지보수성 그리고 이식성 등과 같은 컴포넌트나 시스템의 품질 특성이나 속성을 테스팅.

변경 관련 테스팅

  • 확인 테스팅: 결함을 제대로 수정했는지 확인하는 것
  • 리그레션 테스팅: 소프트웨어 혹은 실행 환경이 변경되었을 때, 변경되지 않은 소프트웨어 영역에 새로운 결함이 유입되었는지 확인하기 위해 이전에 테스트된 프로그램을 (다시) 테스팅 하는 것.

유지보수 테스팅

  • 유지보수 테스팅: 운영 중인 시스템의 변경이 운영 중인 시스템에 미치는 영향력에 대한 테스팅.
  • 유지보수의 계기
    • 개선을 위한 변경 (릴리즈나 긴급 변경, 업그레이드 등)
    • 이관을 위한 변경 (데이터 전환 및 신규 환경에 대한 테스트)
    • 단종 (데이터 이관이나 장시간의 데이터 유지, 복원/회수 절차)

정적 테스팅

정적 테스팅

  • 정적 테스팅: 작업 산출물을 수동으로 검사하거나 도구를 기반으로 평가하는 방법. 대부분의 작업 산출물은 정적 테스팅으로 테스트할 수 있다.
  • 동적 테스팅: 컴포넌트나 시스템 소프트웨어를 실행하면서 수행하는 테스팅.

리뷰 유형

  • 공식 리뷰: 인스펙션과 같이 문서화된 절차와 검토를 위한 요구사항을 갖는 리뷰.
  • 비공식 리뷰: 공식적인(문서화된) 절차를 따르지 않는 리뷰. 버디 체크, 페어링, 짝 리뷰 등이 있다.
  • 기술 리뷰: 명세서와 계획에 대한 적합성 평가 및 변경 무결성 보증
  • 워크쓰루: 개발 산출물 작성 중에 저자에 의해 진행되며, 개발팀이나 관심 그룹이 소프트웨어 제품을 검토
  • 인스펙션: 개발 산출물 작성 완료 후 저자 외 다른 동료가 소프트웨어의 에러, 규격, 표준 위배 사항을 검토

리뷰 기법

  • 애드혹: 검토자에게 리뷰 수행 방법 안내 X, 작업 산출물을 순차적으로 읽어 이슈 식별/기록
  • 체크리스트 기반: 잠재 결함 식별을 위해 경험에서 도출한 일련의 질문으로 구성. 작업 산출물 유형별로 작성, 주기적으로 개선
  • 시나리오: 검토자는 작업 산출물에 대한 구조화된 지침 제공, 특정 결함 유형을 식별
  • 관점 기반: 요구사항 및 기술 작업 산출물에 사용, 검토자가 개별 리뷰 중 다양한 이해관계자의 관점 사용하여 중복 이슈↓ 검토자가 리뷰 대상 작업 산출물로부터 이해관계자 관점 기반 산출물 작성
  • 역할 기반: 검토자가 작업 산출물을 개별 이해관계자 역할의 관점에서 평가하는 기법

테스트 기법

블랙박스 테스트

  • 테스트 베이시스를 통해 테스트 컨디션을 도출한다.
  • 블랙박스 테스트 기법
    • 동등 분할: 변수를 동일한 크기로 분할하여 각 분할에 대해 테스트한다.
      모든 테스트 레벨에 적용할 수 있다.
    • 경계값 분석: 최소, 최대 경계 값에 대해 테스트한다.
      모든 테스트 레벨에 적용할 수 있다.
    • 결정 테이블 테스팅: 조건과 예상 동작을 조합으로 표기하여 테스트한다. 모든 조건 조합을 식별하는 데 도움을 준다.
    • 상태 전이 테스팅: 기존 이력에 따라 어떻게 다르게 실행되는지를 테스트한다.
    • 유스케이스 테스팅: 액터(사용자)가 대상에 대해 수행할 수 있는 동작을 수행할 수 있는지 테스트한다.

화이트박스 테스트

  • 테스트 베이시스, 코드, 아키텍스 설계를 통해 테스트 컨디션을 도출한다.
  • 화이트박스 테스트 기법:
    • 구문 테스팅: 코드 구문을 실행한다.
    • 결정 테스팅: 코드에 존재하는 결정문(if, case)을에 따라 실행되는 코드를 테스트한다.

    100% 구문 커버리지는 코드에 존재하는 모든 실행 가능한 구문을 테스트했다는 것을 의미하지만, 모든 결정 로직을 테스트했다는 것을 보장하지는 않는다. 하지만 100% 결정 커버리지 달성은 100% 구문 커버리지를 보장한다.

경험 기반 테스트

  • 테스터, 개발자, 사용자의 지식과 경험과 같은 테스트 베이시스를 통해 테스트 컨디션을 도출한다.
  • 경험 기반 테스트 기법:
    • 오류 추정: 애플리케이션의 과거 동작, 발생하기 쉬운 오류 유형에 대한 테스터의 지식을 기반으로 오류, 경함 및 장애 발생을 예측하는 기술이다.

    • 탐색적 테스팅: 사전에 정의되지 않은 테스트를 테스트 실행 중에 동적으로 설계, 실행한다. 더 많은 테스트가 필요한 영역을 탐색할 수 있다.

      세션 기반 테스팅으로 정해진 시한(time-box)동안 수행하여, 테스트 목적이 포함된 테스트 차터를 활용해 테스팅 방향을 설정한다. 명세가 충분하지 않거나 시간이 부족한 경우 유용하다.

      다른 기법과 통합하여 사용할 수도 있다.

    • 체크박스 기반 테스팅: 체크리스트에 기록된 테스트를 실행한다. 기존 체크리스트를 확장, 수정하며 사용한다. 기능 및 비기능을 포함한 다양한 테스팅에 활용될 수 있다.

리뷰에서의 역할과 책임

  • 저자:
    • 리뷰 대상 작업 산출물 작성
  • 관리자:
    • 리뷰 계획, 실행, 제어 결정
    • 인력, 예산, 시간 할당
    • 진행 비용 대비 효과 모니터링
  • 중재자(촉진자):
    • 효과적 회의 진행 보장
    • 다양한 관점 중재, 리뷰의 성공 여부에 결정적인 역할
  • 리뷰 리더:
    • 리뷰에 대한 책임
    • 참여자 결정
  • 검토자:
    • 작업 산출물의 잠재적 결함 식별
  • 서기:
    • 새로운 결함, 결정 사항 기록
    • 개별 리뷰 활동에서 발견한 잠재 결함 수집

테스트 관리

테스트 전략 유형

  • 분석적: 특정 요소에 대한 분석을 기반으로 한 테스트 전략
    리스크를 분석해 집중적으로 테스팅해야 할 곳을 결정하는 것 -> 리스크 기반 테스팅

  • 모델기반: 제품의 특성 특면에 대한 모델을 제작하여 실제 테스트 수행
    제품의 특성 특면에 대한 모델을 제작하여 실제 테스트 수행

  • 방법론적: 사전에 정의한 테스트 셋이나 테스트 컨디션을 체계적으로 사용
    체계적으로 장애, 경험, 체크리스트, SW 품질 기반 테스팅

  • 프로세스 및 표준 준수: 외부 규정이나 표준을 기반으로 테스트
    외부 규정이나 표준을 기반으로 테스트를 분석, 설계, 구현

  • 전문자의 조언 또는 자문: 외부 전문가의 조언, 가이드를 바탕으로 커버리지 등 기준을 정한다.

  • 리그레션-기피: 기존 기능에 대한 리그레션 테스트 기피를 목표
    보유한 테스트 관련 자료, 리그레션 테스트 자동화 스크립트, 표준 테스트 슈트 등의 재사용을 통한 테스팅

  • 반응적: 테스트 실행 중 발생하는 이벤트에 따라 반응적으로 수행하는 테스트.
    이전 테스트 결과에서 얻은 지식을 통해 테스트를 설계, 구현하며 즉각 테스트를 실행 -> 경험 기반 테스팅

시작 조건과 종료 조건

  • 시작 조건: 특정 테스트 활동을 시작하기 위해 정의한 사전 조건

    • 테스트 가능한 요구사항, 사용자 스토리나 모델(예: 모델 기반 테스트 전략을 따르는 경우)의 가용 여부
    • 이전 테스트 레벨의 종료 조건을 충족한 테스트 항목의 가용 여부
    • 테스트 환경 가용 여부
    • 필요한 테스트 도구 가용 여부
    • 테스트 데이터와 기타 필요한 자원의 가용 여부
  • 종료 조건: 특정 테스트 레벨이나 테스트 세트가 끝났음을 선언하기 위해 만족해야 할 조건

    • 계획한 테스트 실행 완료
    • 정의한 커버리지 수준 (예: 요구사항, 사용자 스토리, 인수 조건, 리스크, 코드 등의 커버리지)의 도달
    • 신뢰성, 수행 효율성, 사용성, 보안성, 기타 관련된 품질 특성의 수준이 원하는 수준에 도달

    종료 조건을 충족하지 못한 상황에서도 예산 소진, 예정된 시간 경과, 시장 출시 압박 등의 이유로 테스트 활동을 조기에 마감하는 경우도 많다.

테스트 추정 기법

  • 메트릭 기반 기법: 기존 유사한 프로젝트에서 얻은 메트릭이나 보편적인 값을 바탕으로 테스트 노력 예측
  • 전문가 기반 기법: 테스팅 작업의 책임자나 전문가의 경험을 기반으로 테스트 노력 예측
    • 플래닝 포커: 주로 애자일 소프트웨어 개발에서 사용자 스토리에 필요한 코력을 추정하고자 사용하는 합의 기반 추정 기번
    • 와이드밴드 델파이: 팀원의 집단 지성을 이용하여 정확한 추정을 목표로 수행하는 전문가 기반 테스트 추정 기법

테스팅에 사용하는 메트릭

  • 테스팅 활동이나 종료 시점에 아래와 같은 사항을 평가하기 위해 메트릭을 수집할 수 있다.

    • 계획한 일정과 예산 대비 진행 상황
    • 결함 정보 (결함 밀도, 발견한 결함, 수정한 결함, 실패율, 확인 테스트 결과)
    • 테스트 접근법의 타당성
    • 목적 대비 테스트 활동의 효과

리스크

  • 리스크 수준: 장애 발생 가능성과 영향도를 조합하여 결정
  • 제품 리스크: 작업 산출물이 사용자나 이해관계자의 합당한 니즈를 충족하지 못할 가능성
  • 품질 리스크: 제품 리스크가 특정 품질 특성과 연관되는 경우
  • 프로젝트 리스트: 프로젝트 목적 달성에 부정적인 영향을 줄 수 있는 상황 (프로젝트, 조직, 정치적, 기술적, 공급자 이슈 등)

테스트 지원 도구

테스트 도구 분류

  • 테스팅 및 테스트웨어 관리 지원 도구: SW 수명주기 전체에 걸쳐 모든 테스팅 활동에 사용
    • 테스트 관리 도구와 애플리케이션 주명주기 관리 도구(ALM)
    • 요구사항 관리 도구, 결함 관리 도구, 형상 관리 도구, 지속적인 통합 도구
  • 정적 테스팅 지원 도구
    • 정적 분석 지원 도구
  • 테스트 설계 및 구현 지원 도구
    • 모델 기반 테스팅 도구
    • 테스트 데이터 준비 도구
  • 테스트 실행 및 로깅 지원 도구
    • 테스트 실행 도구 (리그레션 테스트 수행 등)
    • 커버리지 도구 (요구사항, 코드 커버리지 등)
    • 테스트 하네스
  • 성능 측정과 동적 분석 지원 도구
    • 성능 테스팅 도구, 동적 분석 도구
  • 특수 목적 테스팅 지원 도구
    • 데이터 품질 평가, 변환/마이그레이션
    • 사용성, 접근성, 현지화, 보안, 이식성 테스팅

테스트 도구 고려 사항

  • 캡처 기반 테스트 접근법: 테스터의 수동적인 조작을 녹화해 테스트를 자동화하는 방법. 테스트 스크립트의 수가 많은 경우 유지보수 힘듦

  • 데이터 주도 접근법: 테스트 입력값과 기대 결괏값을 스프레드시트에 저장하고 공통 스크립트로 테스트를 반복 실행하는 방법

  • 키워드 주도 테스트 접근법: 해야 할 행동을 설명하는 키워드로 연관된 테스트를 실행하는 방법, 스크립트에 익숙하지 않아도 테스팅에 기여 가능


참고