최근 수정 시각 : 2025-05-08 01:02:29

소프트웨어 테스트




SWEBOK(소프트웨어 공학 지식 체계)
{{{#!wiki style="margin:0 -10px -5px; min-height:calc(1.5em + 5px); word-break: keep-all"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-5px -1px -11px"
<colbgcolor=#009000><colcolor=#FFF> 개발 생애주기 Software Requirements, Software Architecture, Software Design, Software Construction, Software Testing, Software Engineering Operations, Software Maintenance
지원·관리 Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Engineering Models & Methods, Software Quality, Software Security
전문성·경제성 Software Engineering Professional Practice, Software Engineering Economics
기초 Computing Foundations, Mathematical Foundations, Engineering Foundations
}}}}}}}}} ||



소프트웨어 테스트 (Software Testing)

1. 개요

소프트웨어 테스트(Software Testing)는 개발된 시스템이나 구성요소가 명세된 요구사항을 만족하는지 여부를 판단하기 위해 수행하는 검증 활동이다. 소프트웨어의 결함을 발견하고, 위험을 줄이며, 신뢰성을 높이기 위한 핵심 활동으로 정의한다.

테스트는 단순한 디버깅을 넘어, 예방적 품질 확보와 사용자 만족을 위한 전략적 수단으로 자리 잡고 있다. Agile, DevOps, CI/CD와 같은 최신 개발 방식에서도 테스트는 전 주기에 걸쳐 반복적으로 수행되는 필수 요소이다.

2. 정의 및 범위

테스트는 소프트웨어 시스템이나 구성요소를 실행해 결함을 드러내는 과정이며, 명세된 요구사항과 실제 동작 간의 차이를 식별하는 데 목적이 있다.

SWEBOK V4.0에서는 테스트의 범위를 다음과 같이 설정한다.
  • 정적 테스트와 동적 테스트 모두 포함
  • 모든 테스트 수준: 단위(Unit), 통합(Integration), 시스템(System), 인수(Acceptance)
  • 자동화 및 수동 테스트 방식
  • 기능, 성능, 보안, 사용성 등 다양한 테스트 관점
  • 테스트 계획부터 실행, 종료까지 전체 프로세스

3. 목적 및 원칙

테스트의 주요 목적
  • 결함 검출: 소프트웨어의 오류·실패를 조기에 발견
  • 품질 확보: 요구사항 충족 여부와 제품의 신뢰성 보장
  • 리스크 완화: 운영 중 발생할 수 있는 실패 가능성을 줄임
  • 의사결정 지원: 출시 여부, 개선 필요성 등을 판단하는 근거 제공

테스트의 기본 원칙
  • 완벽한 테스트는 불가능하다
  • 결함은 군집하는 경향이 있다
  • 초기 테스트가 효과적이다
  • 동일 테스트의 반복은 가치가 감소한다
  • 테스트는 컨텍스트에 의존한다

4. 핵심 개념

4.1. 검증(Verification) vs 타당성 확인(Validation)

파일:상세 내용 아이콘.svg   자세한 내용은 소프트웨어 V&V 문서
#!if (문단 == null) == (앵커 == null)
를
#!if 문단 != null & 앵커 == null
의 [[소프트웨어 V&V#s-|]]번 문단을
#!if 문단 == null & 앵커 != null
의 [[소프트웨어 V&V#|]] 부분을
참고하십시오.

4.2. 결함, 오류, 실패, 리스크

SWEBOK에서는 테스트에서 다루는 핵심 용어를 다음과 같이 구분하여 정의한다.
  • 결함(Fault/Defect): 소프트웨어 내부에 존재하는 코드 또는 설계상의 문제
  • 오류(Error): 개발자 또는 사용자의 실수로 인해 발생한 잘못
  • 실패(Failure): 실행 중 결함이 발현되어 시스템이 예상과 다른 동작을 하는 상태
  • 리스크(Risk): 특정 결함이나 실패가 비즈니스나 사용자에게 영향을 줄 가능성과 심각도

결함 → 오류 → 실패로 이어지는 흐름 속에서, 테스트는 이 문제들을 사전에 발견하고, 리스크를 줄이는 행위로 작용한다.

5. 테스트 수준

소프트웨어 테스트는 적용되는 범위와 추상화 수준에 따라 여러 단계(Level)로 구분된다. 각 수준은 개발 생명주기와 밀접히 연계된다.
  • 인수 테스트 (Acceptance Testing)
  • 시스템 테스트 (System Testing)
  • 통합 테스트 (Integration Testing)
  • 단위 테스트 (Unit Testing)


6. 테스트 유형

SWEBOK V4.0에서는 "테스트 목표" 관점으로 유형을 정리한다.
  • 규격 적합성 테스트(Conformance Testing): 표준·사양·설계서·프로세스 등에 SUT(System Under Test)가 정확히 부합하는지 확인한다.
  • 규제 준수 테스트(Compliance Testing): 법률·정부 규제·산업 규격 충족 여부를 증명하기 위해 수행한다. 외부 감사·인증과 연계되는 경우가 많다.
  • 설치 테스트(Installation Testing): 실제 운영 환경(하드웨어·OS·네트워크)에 배포 후 정상 동작과 설치 절차를 검증한다.
  • 알파/베타 테스트(Alpha & Beta Testing): 출시 전 제한된 사용자에게 제공해 현장 피드백과 잠재 결함을 수집한다.
  • 회귀 테스트(Regression Testing): 수정·리팩터링 후 기존 기능이 영향을 받지 않았는지 선택적으로 재‑실행한다. Agile·CI/CD 흐름에서 필수 활동이다.
  • 우선순위 테스트(Prioritization Testing): 결함 검출률·커버리지 극대화를 위해 테스트 케이스 실행 순서를 최적화한다.
  • 비기능 테스트(Non-Functional Testing): 성능·신뢰성·확장성 등 품질 특성을 집중 점검한다.
    • 성능(Performance), 부하(Load), 스트레스(Stress), 볼륨(Volume)테스트
    • 장애 복구(Failover)·신뢰성(Reliability)·회복(Recovery)테스트
    • 호환성(Compatibility)·구성(Configuration)·인프라(Infra)테스트
    • 확장성(Scalability)·탄력성(Elasticity) 테스트
  • 보안 테스트(Security Testing): 기밀성·무결성·가용성을 위협하는 공격·오용을 탐지한다. 정적 분석·침투 테스트·퍼징 등이 포함된다.
  • 프라이버시 테스트(Privacy Testing): 개인 정보 보호 요구(예: GDPR) 충족과 데이터 유출 위험을 평가한다.
  • 인터페이스·API 테스트(Interface / API Testing): 컴포넌트 간 데이터·제어 흐름이 명세대로 교환되는지 확인한다. 파라미터 조합·경계 조건을 자동 생성해 검증한다.
  • 사용성·HCI 테스트(Usability & Human-Computer Interaction): 학습 용이성·효율성·오류 회복성 등을 실제 사용자 행태로 평가한다.

7. 테스트 설계 기법

SWEBOK V4.0은 테스트 케이스를 "어떻게 뽑을 것인가" 관점에서 명세(기능)기반, 구조(코드)기반, 경험기반으로 큰 틀을 잡고, 세부 분류를 덧붙인다. 각 기법은 단위~인수 단계 어디에서든 선택적으로 적용된다.

7.1. 명세‑기반(블랙박스) 기법

외부 입·출력 행동만 보고 테스트 데이터를 도출한다. 일반적으로 코딩을 할 때 작성하는 테스트가 이에 해당한다.
  • 동등 분할(Equivalence Partitioning): 입력을 "유효/무효" 동치 클래스로 나눠 대표값만 테스트
  • 경계값 분석(Boundary Value Analysis): 오류가 집중되는 극값 근처를 집중 공략
  • 조합/페어와이즈(Combinatorial / Pair-wise): 매 t-wise 입력 조합을 최소 수의 케이스로 커버
  • 결정 테이블·트리 / 원인‑결과 그래프: 조건‑행동 매핑을 체계화해 모든 조합 검증
  • 상태 전이(State Transition): FSM 모델의 상태·전이를 목표 커버리지만큼 실행
  • 시나리오·유스케이스 기반: 사용자 흐름·스토리를 그대로 테스트 절차로 변환
  • 구문·랜덤·예외 유발 테스트 등: 형식 명세·난수·예외 경로를 활용한 파생 기법

7.2. 구조‑기반(화이트박스) 기법

코드 내부 제어·데이터 흐름을 분석해 커버리지를 정량화한다.
  • 제어 흐름(Control Flow): 문장, 분기, 조건, MC/DC, 경로 등 계층적 기준 설정
  • 데이터 흐름(Data Flow): 정의‑사용(DEF-USE) 체인을 따라 All-Defs, All-Uses, All-DU-Paths 등

7.3. 경험‑기반 기법

테스터의 도메인 지식·직관을 활용해 결함이 숨어 있을 법한 영역을 탐색한다.
  • 에러 추정(Error Guessing): 과거 결함 패턴·전문가 경험을 토대로 케이스 설계
  • 탐색적 테스트(Exploratory): 학습·설계·실행을 동시 반복하며 즉흥적으로 범위 확장
  • 애드혹·몬키·버디·게이미피케이션·퀵·스모크 등: 공식 절차 대신 창의적·경량 방법으로 빠른 결함 탐색

7.4. 결함‑기반·변이(Mutation) 기법

특정 결함 모델·변종 코드(mutant)를 의도적으로 만들어 "살해" 여부로 테스트 효과를 측정·강화

7.5. 사용 프로필·통계 기법

실제 운영 빈도를 반영한 운용 프로필(Operational Profile)로 신뢰성·MTBF 등을 추정하거나, 무작위 샘플링으로 품질 지표를 통계적으로 확보하여 테스트

7.6. 도메인·기술 특화 기법

객체지향·실시간·웹·임베디드·AI/ML·블록체인 등 대상의 고유 위험을 반영해 파생 모델·시뮬레이션·하드웨어‑인‑더‑루프(HIL)등을 적용

8. 테스트 프로세스