소프트웨어 테스트

🎯 테스트의 목적과 전체 구조

이 섹션에서는 소프트웨어 테스트의 기본 개념과 이 강의 학습 방향을 살펴보겠습니다.

소프트웨어 테스트는 결함을 발견하여 품질을 보증하는 활동입니다. 테스트는 결함이 없음을 증명하는 것이 아니라 결함을 찾아내는 것이 목적입니다. 이 점이 기출에서 자주 함정으로 나옵니다.

테스트의 7가지 원칙 중 기출 빈도가 높은 것은 다음과 같습니다. 결함 집중(Defect Clustering) — 결함의 80%는 전체 모듈의 20%에 집중됩니다. 살충제 패러독스(Pesticide Paradox) — 같은 테스트를 반복하면 새로운 결함을 발견하지 못합니다. 완벽한 테스트는 불가능 — 모든 경우의 수를 테스트하는 것은 현실적으로 불가능합니다.

테스트는 내부 구조 인지 여부에 따라 블랙박스(명세 기반)와 화이트박스(구조 기반)로 나뉩니다. 각 기법의 특성을 명확히 구분하는 것이 이 강의 핵심입니다.

📦 블랙박스 테스트 기법 5가지

이 섹션에서는 내부 구조를 모르는 상태에서 기능 명세를 기반으로 하는 블랙박스 테스트 기법 5가지를 살펴보겠습니다.

동등 분할(Equivalence Partitioning)은 입력 데이터를 유효·무효 등가 클래스로 나누어 각 클래스에서 대표값 하나를 선택하는 기법입니다. 예를 들어 1~100 사이 점수 입력이라면 유효 클래스(1~100)와 무효 클래스(0 이하, 101 이상)로 나누고 각각 50, -1, 150을 테스트합니다.

경계값 분석(Boundary Value Analysis)은 동등 분할의 경계 부근에서 오류가 많이 발생한다는 경험을 바탕으로 경계값과 그 바로 위아래 값을 테스트하는 기법입니다. 1~100 범위라면 0, 1, 2, 99, 100, 101을 테스트합니다. 실무에서 가장 많이 사용되는 기법입니다.

결정 테이블(Decision Table)은 복잡한 조건과 행동의 조합을 표로 정리하여 누락 없이 테스트하는 기법입니다. 조건(Condition)과 행동(Action)의 조합을 열로 표현합니다.

원인-결과 그래프(Cause-Effect Graph)는 원인(입력 조건)과 결과(출력)를 그래프로 연결하여 결정 테이블로 변환하는 기법입니다. 조건 간의 AND·OR·NOT 관계를 명시합니다.

페어와이즈(Pairwise Testing)는 모든 조합 대신 두 요인의 모든 조합을 커버하도록 최소 테스트 케이스를 선택하는 기법입니다. n개 변수의 모든 조합(2^n)이 아닌 임의의 두 쌍 조합만 테스트하여 테스트 케이스 수를 획기적으로 줄입니다.

🔬 화이트박스 테스트와 커버리지

이 섹션에서는 내부 코드 구조를 기반으로 하는 화이트박스 테스트와 커버리지 기준을 살펴보겠습니다.

화이트박스 테스트는 소스 코드의 내부 논리를 기반으로 테스트 케이스를 설계합니다. 커버리지가 높을수록 더 철저한 테스트를 의미하며, 기출에서는 커버리지 포함 관계를 묻는 문제가 자주 나옵니다.

커버리지	기준	설명	강도
문장 커버리지(SC)	모든 실행문	각 문장이 최소 1번 실행	가장 약함
분기 커버리지(DC)	모든 분기	각 조건문의 True/False 모두 실행	SC 포함
조건 커버리지(CC)	개별 조건	각 단일 조건의 True/False 모두 실행	DC 미포함 가능
MC/DC	조건+분기	각 조건이 독립적으로 결과에 영향	항공·의료 안전 필수

기출 함정: "분기 커버리지는 문장 커버리지를 포함한다" → 맞음. "조건 커버리지는 분기 커버리지를 포함한다" → 틀림. 조건 커버리지와 분기 커버리지는 포함 관계가 아닙니다. MC/DC는 둘 다 포함합니다.

암기법: "문 분 조 MC" — 문장→분기→조건+분기(MC/DC) 순으로 강도가 높아집니다. MC/DC는 항공기·의료 소프트웨어 같은 안전 필수 시스템에서 요구됩니다.

🔺 V-모델 — 테스트 4단계

이 섹션에서는 개발 단계와 테스트 단계를 1:1로 대응시킨 V-모델의 구조를 살펴보겠습니다.

V-모델은 개발 생명주기(SDLC)의 각 단계마다 대응하는 테스트 단계가 있다는 것을 시각적으로 표현한 모델입니다. 왼쪽(개발)의 각 단계가 오른쪽(테스트)의 단계와 대응됩니다.

개발 단계	대응 테스트 단계	테스트 주체	검증 기준
요구사항 분석	인수 테스트(Acceptance)	고객/사용자	사용자 요구사항 충족
시스템 설계	시스템 테스트(System)	QA팀	전체 시스템 기능·성능
상세 설계	통합 테스트(Integration)	개발팀	모듈 간 인터페이스
구현(코딩)	단위 테스트(Unit)	개발자	개별 함수·모듈

테스트는 단위 → 통합 → 시스템 → 인수 순서로 수행됩니다. 통합 테스트에는 빅뱅 통합(한번에 통합), 상향식 통합(하위 모듈부터, 드라이버 필요), 하향식 통합(상위 모듈부터, 스텁 필요), 샌드위치 통합(상향+하향 혼합) 방식이 있습니다.

스텁(Stub): 하향식 통합에서 아직 개발되지 않은 하위 모듈을 대신하는 더미 모듈. 드라이버(Driver): 상향식 통합에서 상위 모듈을 대신하는 더미 모듈. 이 둘의 차이를 묻는 문제가 자주 출제됩니다.

🐛 테스트 오라클과 결함 우선순위

이 섹션에서는 테스트 결과 판정 기준인 테스트 오라클과 발견된 결함의 우선순위 분류를 살펴보겠습니다.

테스트 오라클(Test Oracle)은 테스트 실행 결과가 올바른지 판단하는 기준입니다. 오라클의 종류는 다음과 같습니다.

• 참(True) 오라클: 모든 입력에 대해 정확한 출력을 제공 (항공·의료 등 안전 필수 시스템)
• 샘플링(Sampling) 오라클: 특정 입력에 대해서만 예상 결과를 제공
• 휴리스틱(Heuristic) 오라클: 경험적 판단으로 예상 결과를 제공
• 일관성(Consistent) 오라클: 변경 전후 결과가 동일한지 비교 (회귀 테스트)

결함 우선순위(Defect Priority)는 발견된 결함을 심각도와 우선순위에 따라 분류합니다. 기출에서는 심각도와 우선순위가 항상 일치하지 않음을 이해하는 것이 중요합니다.

등급	심각도	처리 기준
치명적(Critical)	시스템 운영 불가	즉시 수정 필수
주요(Major)	핵심 기능 비정상	빠른 수정 필요
보통(Normal)	일부 기능 비정상	일정 내 수정
경미(Minor)	사용 가능하나 불편	여유 시 수정

기출 함정: "테스트는 결함이 없음을 증명한다" → 틀림. 테스트는 결함을 발견하는 활동입니다. "단위 테스트는 QA팀이 수행한다" → 틀림. 단위 테스트는 개발자가 수행합니다.

암기법: V-모델 순서는 "요시상구 → 단통시인" — 요구사항·시스템설계·상세설계·구현에 대응하여 단위·통합·시스템·인수 테스트입니다.

📌 8강 핵심 요약과 9강 예고

이 섹션에서는 8강 전체 내용을 압축 정리합니다.

블랙박스 5기법: 동등분할·경계값·결정테이블·원인결과그래프·페어와이즈. 화이트박스 커버리지: 문장→분기(SC 포함)→MC/DC 순서로 강해짐. 조건 커버리지는 분기 커버리지를 포함하지 않음.

V-모델: 요구사항↔인수, 시스템설계↔시스템, 상세설계↔통합, 구현↔단위. 하향식=스텁 필요, 상향식=드라이버 필요. 테스트 오라클은 판정 기준, 결함은 치명·주요·보통·경미 4단계.

다음 9강에서는 형상관리와 빌드·배포 — Git 브랜치 전략, Maven·Gradle 빌드 도구, CI/CD 파이프라인, Docker와 시맨틱 버전 관리를 완벽히 정리합니다.