ㅈㄱㅈ/ㅊㄴㅅㄴ

테스트 기본 용어

SBP 2025. 4. 28. 20:36
소프트웨어 테스팅 상세 개념

소프트웨어 테스팅 상세 개념

CSTS 자격증 시험에 자주 등장하는 소프트웨어 테스팅의 주요 개념들을 자세히 설명해 드립니다.

테스트 기본 용어 (Basic Testing Terminology)

앞서 다룬 용어 외에 몇 가지 추가적인 기본 용어입니다.

  • 검증 (Verification): 제품을 '올바르게' 만들고 있는가? (Are we building the product right?) - 요구사항, 설계, 코드 등이 표준 및 명세에 부합하는지 확인하는 정적인 활동(리뷰, 인스펙션 등)을 포함합니다.
  • 확인 (Validation): '올바른' 제품을 만들고 있는가? (Are we building the right product?) - 개발된 소프트웨어가 사용자의 기대와 요구사항을 충족하는지 동적으로 실행하여 확인하는 활동입니다. 테스트 실행이 여기에 해당됩니다.
  • 디버깅 (Debugging): 테스트 중 발견된 결함(Defect)의 원인을 찾아서 수정하는 활동입니다. 이는 테스트와는 구분되는 개발자의 주요 활동입니다.
  • 요구사항 (Requirement): 소프트웨어가 수행해야 할 기능, 성능, 제약사항 등을 정의한 명세입니다. 테스트의 중요한 기준이 됩니다.

테스트 대상과 테스트 레벨 (Test Object and Test Levels)

소프트웨어 테스트는 개발 생명주기의 여러 단계에서 서로 다른 '대상'에 대해 수행되며, 이를 '테스트 레벨'이라고 합니다.

  • 단위 테스트 (Unit Testing):
    • 대상: 프로그램의 가장 작은 단위인 모듈, 컴포넌트 또는 클래스.
    • 목적: 각 단위가 설계된 대로 정확하게 동작하는지 확인합니다. 주로 개발자가 수행합니다.
  • 통합 테스트 (Integration Testing):
    • 대상: 개별 단위들이 모여 상호작용하는 인터페이스 또는 통합된 컴포넌트 그룹.
    • 목적: 단위들이 올바르게 연결되고 데이터와 제어가 예상대로 흐르는지 확인합니다.
  • 시스템 테스트 (System Testing):
    • 대상: 완전하게 통합된 시스템 전체.
    • 목적: 시스템이 명세된 기능적/비기능적 요구사항을 모두 충족하는지 종합적으로 확인합니다. 기능 테스트, 성능 테스트, 보안 테스트 등이 포함됩니다.
  • 인수 테스트 (Acceptance Testing):
    • 대상: 최종 사용자 또는 고객이 사용하게 될 완성된 시스템.
    • 목적: 시스템이 비즈니스 요구사항이나 사용자의 기대를 만족하는지, 실제 운영 환경에 배포될 준비가 되었는지 고객/사용자가 직접 확인하고 인수를 결정합니다.

피처와 테스트 유형 (Features and Test Types)

'피처(Feature)'는 소프트웨어의 특정 기능이나 특성을 의미합니다. 다양한 '테스트 유형'은 이러한 피처 또는 시스템의 특정 측면을 검증하기 위해 수행됩니다.

  • 기능 테스트 (Functional Testing): 소프트웨어가 명세된 기능을 올바르게 수행하는지 확인합니다. (예: 로그인 기능, 결제 기능)
  • 비기능 테스트 (Non-functional Testing): 소프트웨어의 품질 특성(성능, 신뢰성, 사용성, 보안 등)을 확인합니다.
    • 성능 테스트 (Performance Testing): 부하 및 스트레스 상황에서 시스템의 속도, 응답 시간 등을 측정합니다.
    • 부하 테스트 (Load Testing): 예상되는 최대 사용자 부하 하에서 시스템의 성능을 측정합니다.
    • 스트레스 테스트 (Stress Testing): 시스템이 정상적인 한계를 넘어선 극심한 부하 또는 자원 부족 상황에서 어떻게 반응하는지 확인합니다.
    • 사용성 테스트 (Usability Testing): 사용자가 소프트웨어를 얼마나 쉽고 효율적으로 사용할 수 있는지 평가합니다.
    • 보안 테스트 (Security Testing): 시스템이 외부 위협으로부터 얼마나 안전한지 확인합니다.
    • 신뢰성 테스트 (Reliability Testing): 특정 기간 동안 오류 없이 얼마나 안정적으로 동작하는지 확인합니다.
    • 호환성 테스트 (Compatibility Testing): 다양한 하드웨어, 운영체제, 브라우저 등 환경에서 소프트웨어가 올바르게 동작하는지 확인합니다.
  • 구조 테스트 (Structural Testing / White-box Testing): 소프트웨어 내부 코드 구조, 로직, 경로 등을 기반으로 테스트 케이스를 설계합니다. (예: 구문 커버리지, 결정 커버리지)
  • 변경 관련 테스트 (Change-related Testing): 소프트웨어 변경 후 수행하는 테스트입니다.
    • 재 테스트 (Re-testing / Confirmation Testing): 결함을 수정한 후 해당 결함이 올바르게 수정되었는지 확인하기 위해 수행하는 테스트입니다.
    • 회귀 테스트 (Regression Testing): 소프트웨어 변경(결함 수정, 기능 추가 등)이 기존에 정상적으로 동작하던 다른 부분에 영향을 미치지 않았는지 확인하기 위해 수행하는 테스트입니다.

테스트 설계 기법 (Test Design Techniques)

효과적인 테스트 케이스를 만들기 위한 체계적인 방법론입니다.

  • 블랙박스 기법 (Black-box Techniques): 소프트웨어 내부 구조나 코드를 알지 못한 채, 주로 요구사항 명세에 기반하여 테스트 케이스를 설계합니다.
    • 동등 분할 (Equivalence Partitioning): 가능한 입력 값을 동등한 특성을 가지는 그룹으로 나누어 각 그룹에서 대표 값으로 테스트 케이스를 선정합니다.
    • 경계값 분석 (Boundary Value Analysis): 입력 값의 경계 근처(최솟값, 최댓값, 그 바로 안팎 값)에서 오류가 자주 발생한다는 경험에 기반하여 테스트 케이스를 설계합니다.
    • 결정 테이블 테스팅 (Decision Table Testing): 여러 조건(Condition)과 그에 따른 행동(Action)의 조합을 테이블로 만들어 테스트 케이스를 도출합니다. 복잡한 비즈니스 규칙 테스트에 유용합니다.
    • 상태 전이 테스팅 (State Transition Testing): 시스템의 상태와 상태 변화(전이)를 모델링하고, 유효하거나 유효하지 않은 상태 전이를 트리거하는 입력 값으로 테스트 케이스를 설계합니다.
    • 유스케이스 테스팅 (Use Case Testing): 시스템이 사용자에게 제공하는 기능 단위인 유스케이스 흐름(기본 흐름, 대체 흐름, 예외 흐름)을 기반으로 테스트 케이스를 설계합니다.
  • 화이트박스 기법 (White-box Techniques): 소프트웨어 내부 코드 구조와 로직을 이해한 상태에서 테스트 케이스를 설계합니다. 주로 개발자나 테스터가 코드 커버리지를 높이기 위해 사용합니다.
    • 구문 커버리지 (Statement Coverage): 코드의 모든 실행 가능한 구문을 한 번 이상 실행하도록 테스트 케이스를 설계합니다.
    • 결정 커버리지 (Decision Coverage / Branch Coverage): 코드 내 모든 결정(if, while, case 등)의 모든 가능한 결과(True/False 분기)를 한 번 이상 실행하도록 테스트 케이스를 설계합니다.
    • 경로 커버리지 (Path Coverage): 코드 내 모든 가능한 독립적인 경로를 한 번 이상 실행하도록 테스트 케이스를 설계합니다. (실무에서는 모든 경로를 커버하기 어려울 수 있습니다.)
  • 경험 기반 기법 (Experience-based Techniques): 테스터의 경험, 직관, 지식 등을 활용하여 테스트 케이스를 설계합니다.
    • 오류 추정 (Error Guessing): 과거 경험이나 직관을 바탕으로 오류가 발생할 가능성이 높은 부분을 추정하여 테스트 케이스를 설계합니다.
    • 탐색적 테스팅 (Exploratory Testing): 테스트 설계와 실행을 동시에 진행하며 시스템을 탐색하고 학습하면서 테스트 케이스를 즉석에서 설계하고 실행하는 접근 방식입니다.

테스트 케이스 (Test Case)

테스트 케이스는 특정 조건 하에서 시스템이나 컴포넌트가 예상대로 동작하는지 검증하기 위해 설계된 일련의 명세입니다.

일반적으로 테스트 케이스는 다음과 같은 요소를 포함합니다.

  • 테스트 케이스 ID (Test Case ID): 각 테스트 케이스를 고유하게 식별하는 번호 또는 코드.
  • 테스트 항목 (Test Item): 테스트 대상 기능 또는 모듈.
  • 테스트 목적 (Purpose): 이 테스트 케이스를 통해 무엇을 검증하고자 하는가.
  • 사전 조건 (Preconditions): 테스트를 실행하기 전에 충족되어야 할 조건 (예: 특정 데이터 존재, 사용자 로그인 상태).
  • 입력 데이터 (Input Data): 테스트 실행 시 시스템에 제공할 값.
  • 실행 단계 (Execution Steps): 테스트를 수행하기 위한 구체적인 절차.
  • 예상 결과 (Expected Result): 테스트 단계를 수행했을 때 시스템이 보여야 하는 올바른 결과.
  • 실제 결과 (Actual Result): 테스트 실행 후 시스템에서 관찰된 실제 결과.
  • 테스트 결과 (Result): 테스트 성공(Pass) 또는 실패(Fail).
  • 비고 (Notes): 테스트 관련 추가 정보 또는 설명.

테스트 절차 (Test Process)

일반적인 소프트웨어 테스트 프로세스는 다음과 같은 활동으로 구성됩니다.

  1. 테스트 계획 (Test Planning): 테스트의 목적, 범위, 전략, 일정, 자원, 산출물, 위험 등을 정의합니다. 테스트 계획서(Test Plan)를 작성합니다.
  2. 테스트 분석 및 설계 (Test Analysis and Design): 테스트 대상을 분석하고, 테스트 목표를 정의하며, 테스트 조건을 식별하고, 테스트 케이스를 설계합니다.
  3. 테스트 구현 및 실행 (Test Implementation and Execution): 테스트 케이스를 실행 가능한 형태로 구현(테스트 스크립트 작성 등)하고, 정의된 테스트 환경에서 테스트 케이스를 실행합니다.
  4. 테스트 결과 평가 및 보고 (Test Result Evaluation and Reporting): 실제 결과를 예상 결과와 비교하여 테스트 결과를 평가하고, 결함을 기록 및 추적하며, 이해관계자에게 테스트 진행 상황 및 결과를 보고합니다.
  5. 테스트 완료 (Test Closure): 테스트 활동을 공식적으로 종료합니다. 테스트 완료 보고서를 작성하고, 테스트 자산을 정리하며, 회고 활동을 수행합니다.

테스트 환경 (Test Environment)

테스트 환경은 소프트웨어 시스템을 테스트하기 위해 필요한 하드웨어, 소프트웨어, 네트워크, 데이터, 도구 등의 총체적인 설정입니다.

실제 운영 환경과 최대한 유사하게 구축하는 것이 중요하며, 일관적이고 안정적인 환경을 유지해야 신뢰할 수 있는 테스트 결과를 얻을 수 있습니다.

테스트 환경 구축 및 관리는 테스트 프로세스의 중요한 부분입니다.

이 정보들이 CSTS 학습에 큰 도움이 되기를 바랍니다. 계속 응원하겠습니다!