테스트 케이스 설계와 레벨별 테스트
목차 20
16강이 빌드·배포 자동화(CI/CD)였다면, 17강은 그 CI 안에서 무엇을 어떻게 검사하는가 의 본체다. 테스트의 원칙(7원리)부터 케이스 설계, V모델 4단계↔4레벨 거울 매칭, 레벨별 테스트(단위→통합→시스템→인수), 기법 분류(화이트/블랙박스), 회귀까지 — 한 대의 자동차가 공장에서 도로로 나가는 검수 전 과정을 통째로 잡는다. 13강 단위 테스트(JUnit)·16강 Jenkins가 여기서 회귀 테스트(CI 자동 실행) 로 이어진다. 매 회차 한 문제 이상 보장되는 정조준 단원이며, 점수밭은 다섯 — 결조초집결살정 · V모델 거울 · 단통시인 · 알=개·베=고 · 화이트=커버리지·블랙=동경결상.
핵심 암기: 테스트 7원리 결조초집결살정 · 출제 70% 핵심 3 살집조(살충제·집중·조기) · 케이스 5요소 식·항·입·기·절 · V모델 4단계↔4레벨 거울 매칭 · V모델 진행 순서 단통시인(단위→통합→시스템→인수) · 알파 vs 베타 알=개·베=고 · 화이트박스 커버리지 강도 문장 < 분기 < 조건 < 경로 · 기법 분류 화이트=커버리지 / 블랙=동경결상 · 회귀 = 수정 + 기존 기능 + 재실행
테스트의 원리와 테스트 케이스
테스트 정의 — 결함 발견 ≠ 품질 증명 ·테스트 개요·1순위·
[정의] 소프트웨어 테스트(Software Testing) = 소프트웨어가 명세된 요구사항을 만족하는지 확인하고, 결함(defect)을 발견 하기 위해 의도적으로 실행·관찰하는 활동.
[핵심] 테스트는 결함이 있다는 것 은 증명해도 결함이 없다는 것 은 절대 증명하지 못한다. 입력 조합은 무한대인데 테스트는 그중 일부만 돌리기 때문이다. 그래서 ISTQB 7원리의 1번이 결함 존재성(Testing shows the presence of defects).
💡 시험으로 치면 100문제 중 5문제 틀린 걸 찾는 활동이지, 100문제 다 맞았다고 "모든 분야에서 완벽하다"를 증명하는 활동이 아니다. 시험 범위 밖은 모른다.
🔑 암기 테스트 = 결함의 존재를 발견 / 부재(품질 완벽)는 증명 못 함. ⚠️ 함정 '테스트 통과 = 버그 없음' · '품질을 완벽하게 증명한다' 표현이 보이면 100% 함정. 정답은 항상 '결함의 존재를 발견 · 부재는 증명 못 함'. 🎯 빈출 정의 함정으로 거의 매회 등장. 7원리 1번(결함 존재성)과 직결.
★테스트 7원리 — 결조초집결살정★ ·테스트 원리·1순위·
[정의] 테스트 7원리 = ISTQB(국제 소프트웨어 테스팅 자격위원회) 표준으로 정착한 일곱 원칙. 매 회차 한 문제 이상 보장.
[표] 결조초집결살정 — 일곱 글자 한 줄 매칭.
| # | 원리 | 한 줄 요약 |
|---|---|---|
| 결 | 결함 존재(Presence of Defects) | 테스트는 결함의 존재 만 증명, 부재는 증명 못 함 |
| 조 | 조기 테스트(Early Testing) | 일찍 시작할수록 비용 적게 듦(Shift Left) |
| 초 | 초완전성 불가(Exhaustive Impossible) | 모든 입력 조합 검증은 불가능 — 위험 기반 우선순위 |
| 집 | 결함 집중(Defect Clustering) | 파레토 80/20 — 결함 80%는 모듈 20%에 |
| 결 | 결함 부재의 궤변(없음 오류) | 결함 0건이라도 요구 못 맞추면 무용지물 |
| 살 | 살충제 패러독스(Pesticide Paradox) | 같은 케이스 반복 → 새 결함 X, 갱신 필수 |
| 정 | 정황 의존성(Context Dependent) | 안전 SW vs 게임 SW — 테스트 강도·기법 다름 |
🔑 암기 결조초집결살정 일곱 글자. 다 못 외우면 다음 카드의 살집조 라도. ⚠️ 함정 '없음 오류(결함 0건=품질 완벽)' 와 '결함 존재' 를 뒤바꾸는 함정. 두 번째 '결' = 결함 부재의 궤변(없음 오류)으로 구분. 🎯 빈출 7원리 단독 출제 거의 매회. 그중 살충제 패러독스가 단독 1순위. 📝 기출 '~원리에 해당하지 않는 것?' · 정의→원리 매칭 단골.
★살집조 — 출제 70% 핵심 3원리★ ·테스트 원리·1순위·
[정의] 7원리 중 시험 출제가 70% 집중되는 핵심 셋 = 살충제 패러독스 · 결함 집중 · 조기 테스트. 7원리를 다 못 외워도 살집조만큼은 확실히 외워두면 합격 라인을 넘긴다.
[표] 세 원리의 시험 키워드.
| 원리 | 핵심 정의 | 시험 키워드 |
|---|---|---|
| 살충제 패러독스 | 동일 케이스 반복 → 새 결함 발견 X. 케이스를 주기적으로 검토·갱신·추가해야 함 | 반복 · 갱신 · 발견율 감소 |
| 결함 집중 | 결함은 특정 모듈에 몰림. 파레토 80/20 — 결함 80%가 모듈 20%에서 | 파레토 · 80/20 · 특정 모듈 |
| 조기 테스트 | 가능한 한 빠른 시점(요구·설계)부터 시작. Shift Left — 늦게 발견할수록 수정 비용 폭증 | Shift Left · 일찍 · 비용 1→200 |
[흐름] 살충제 = 케이스 노화 / 조기 = 비용 곡선. 비용은 늦게 발견할수록 기하급수.
[조기 테스트 — 발견이 늦을수록 비용 폭증 (일반론)]
요구 단계 비용 1
설계 단계 비용 5
구현 단계 비용 10
테스트 단계 비용 50
운영 단계 비용 100~200
💡 살충제는 같은 모기약을 매년 쓰면 모기가 내성을 갖는 것과 같다 — 같은 케이스만 반복하면 코드가 그 케이스에 적응해 결함이 안 잡힌다. 💡 조기 테스트는 집을 다 짓고 기둥 오류를 발견하는 것과 설계도에서 발견하는 것의 차이다. 가장 강력한 Shift Left는 PR 단계 CI 자동 테스트 — push 즉시 단위 테스트가 돌고 통과 못 하면 머지 차단.
🔑 암기 살(반복 X·갱신 O) · 집(파레토 80/20) · 조(Shift Left·1→200). ⚠️ 함정 셋이 서로 자리 바뀜. 'Shift Left = 결함이 모듈에 몰림'(조기 ≠ 집중) · '동일 케이스 반복이 결함 집중'(반복 = 살충제) · '결함 80%는 시간 80%에'(파레토는 시간이 아닌 모듈 80/20). 🎯 빈출 살충제 단독이 1순위 — '동일 케이스 반복 + 갱신' 키워드 둘 중 하나만 보여도 살충제. 결함 집중·조기도 매회 단골. 📝 기출 살충제 정의 매칭(보리스 베이저 1990 Software Testing Techniques 정식화) · 파레토 매칭.
테스트 케이스 5요소 — 식·항·입·기·절 ·테스트 케이스·
[정의] 테스트 케이스(Test Case) = 하나의 테스트 시나리오를 검증하기 위한 입력·실행 조건·기대 결과의 명세서. 시험으로 치면 '채점 기준표 한 줄'. 7원리가 '왜 테스트하는가'라면, 케이스는 '어떻게 테스트하는가'의 구체 단위.
[표] 5대 구성요소 — 식·항·입·기·절.
| # | 요소 | 영문 | 예시 |
|---|---|---|---|
| 식 | 식별자 | Test Case ID | TC-LOGIN-001 |
| 항 | 항목 | Test Item | 로그인 인증 |
| 입 | 입력값 | Input | ID="user1", PW="abc123" |
| 기 | 기대 결과 | Expected Output | 로그인 성공·홈 화면 이동 |
| 절 | 절차 | Procedure / Steps | 화면 진입 → ID 입력 → PW 입력 → 버튼 클릭 |
[참고] 부가 항목(시험 비중 낮음): 사전조건·사후조건·환경·우선순위.
💡 채점 기준표를 미리 적어두지 않으면 결과를 봐도 합격인지 불합격인지 판정하지 못한다. '이 입력에 이 결과가 나와야 한다'를 미리 적어둔 것이 케이스.
🔑 암기 식·항·입·기·절 다섯 글자. ⚠️ 함정 '개발자 의도' · '코드 줄 수' · '테스트 비용' 이 5요소 보기에 끼면 그게 정답(아님). 5요소는 식·항·입·기·절뿐. '요구사항 ID'는 추적성 연결일 뿐 5요소 아님. 🎯 빈출 '케이스 구성요소가 아닌 것?' 소거형. 5요소 아닌 항목을 끼워 넣는 함정 단골.
테스트 주변 용어 4종 + 오라클 4종 ·테스트 케이스·
[표] 케이스 주변에 함께 묶여 나오는 4종 — 자리만 뒤바뀐 함정이 단골.
| 용어 | 정의 | 한 줄 비유 |
|---|---|---|
| 테스트 시나리오 | 여러 케이스를 사용자 흐름 순서로 묶은 시퀀스 | 스토리보드 — 케이스=컷, 시나리오=컷의 흐름 |
| 테스트 오라클 | 결과가 정답인지 판정하는 기준(정답 출처) | 신탁(神託) — 정답을 알려주는 메커니즘 |
| 테스트 베드 | 테스트 실행 환경·인프라(HW·SW·데이터) | 무대·세트장 — 연기할 공간 |
| 테스트 하네스 | 테스트를 자동 실행하고 결과를 수집하는 보조 도구 | 안전벨트 — 자동 실행을 떠받치는 장치 |
[분류] 오라클은 정답이 어디서 오느냐에 따라 4종. 시험은 4종 분류까지 묻는다.
| # | 오라클 종류 | 한 줄 정의 | 사용 시점 |
|---|---|---|---|
| 참 | 참(True) | 모든 입력에 대해 정답을 아는 완전한 기준 | 안전 SW(의료·항공·군) — 정확도 100% |
| 샘플 | 샘플링(Sampling) | 일부 입력에 대해서만 정답을 아는 부분 기준 | 입력 조합이 많을 때 대표 케이스만 |
| 휴 | 휴리스틱(Heuristic) | 일부는 정확, 나머지는 추정·경험 기반 판정 | 명세가 모호할 때 |
| 일관 | 일관성 검사(Consistency) | 이전 버전 실행 결과와 비교해 동일하면 통과 | 회귀 테스트 — 기존 동작 유지 검증 |
🔑 암기 주변 용어 = 시(흐름)·오(정답)·베(환경)·하(자동 실행) / 오라클 4종 = 참(완전)·샘플(일부)·휴(추정)·일관(이전과 비교). ⚠️ 함정 '환경을 제공하는 것은 오라클'(환경=베드) · '자동 실행 보조는 베드'(자동 실행=하네스) · '여러 케이스 흐름은 오라클'(흐름=시나리오). 자리 뒤바꿈 단골. 🎯 빈출 4종 매칭 + 오라클 4종 분류. 회귀와 짝지어 일관성 검사 오라클이 자주 출제.
케이스 설계 4절차 — 계획 → 설계 → 실행 → 리포팅 ·테스트 케이스·
[흐름] 케이스 한 건이 만들어지는 표준 4단계. 순서를 뒤바꾼 함정이 단골.
[테스트 케이스 설계 4절차]
① 계획 — 목표·범위·일정·자원·도구 결정(테스트 계획서)
↓
② 설계 — 케이스 5요소 작성 + 우선순위 + 시나리오 구성
↓
③ 실행 — 베드에서 케이스 실행 + 결과 기록 + 결함 등록
↓
④ 리포팅 — 결함 통계·커버리지·종료 보고서
↓
(다음 릴리스로 케이스 갱신 → 살충제 패러독스 회피)
🔑 암기 계 → 설 → 실 → 리. '계획부터, 리포팅으로 끝'. ⚠️ 함정 '리포팅이 가장 먼저' · '설계가 가장 마지막' 같은 순서 뒤바꿈이 단골. 순서는 고정. 🎯 빈출 '케이스 작성 절차에 해당하는 것?' · 순서 정렬형.
V모델과 레벨별 테스트
V모델 정의 — 폭포수 확장 ·V모델·1순위·
[정의] V모델(V-Model) = 폭포수(Waterfall) 모형을 확장한 SDLC. 폭포수가 일직선 끝에 테스트 한 번이라면, V모델은 각 개발 단계마다 짝이 되는 테스트 단계를 매칭 시킨 V자 형태. 1980년대 후반 독일 정부 표준에서 정식화.
[표] V모델 핵심 특징.
| 특징 | 한 줄 |
|---|---|
| 거울 매칭 | 좌측 개발 4단계 ↔ 우측 테스트 4단계가 위아래 거울 |
| 조기 테스트 내장 | 테스트 설계가 개발 초반부터 진행(Shift Left 실현) |
| 확인·검증 분리 | 좌측 = 확인(Verification·맞게 만들었나) / 우측 = 검증(Validation·맞는 걸 만들었나) |
| 폭포수 확장 | 순방향 흐름 + 위험 분석 없음(위험 분석은 나선형 모형의 특징) |
💡 짓기 전 좌측에서 '요구→기본 설계→상세 설계→시공'으로 내려가고, 시공 후 우측에서 '시공 검수→건물 검수→전체 점검→입주 확인'으로 올라가는 건축 설계·준공 검수의 거울. 안전 중심 분야(금융 코어뱅킹·의료기기·항공)에서 표준에 가까운 절차로 운영된다.
🔑 암기 V모델 = 폭포수 + 단계별 테스트 짝 매칭. 위험 분석 없음. ⚠️ 함정 '위험 분석 단계가 있다'가 나오면 V모델이 아니다 — 위험 분석 = 나선형(Spiral) 모형. SDLC 5종 비교(폭포수·프로토타입·나선형·V모델·애자일)는 54강에서 본격. 🎯 빈출 정의 매칭 + 위험 분석 함정 차단.
★V모델 4단계↔4레벨 거울 매칭★ ·V모델·시그니처·1순위·
[흐름] 17강 마스터 도식. 좌측에서 내려가 코딩 바닥을 찍고, 우측에서 거울처럼 올라온다. 도식을 그대로 보기로 옮긴 형태로 매회 출제 1순위.
[V모델 — 좌측 개발 ↔ 우측 테스트 거울]
요구분석 ───────────────────────── 인수 테스트 (가장 큰 단위)
시스템설계 ──────────────── 시스템 테스트
상세설계 ─────────── 통합 테스트
구현 ──────── 단위 테스트 (가장 작은 단위)
↘ ↗
코딩 (V의 바닥)
좌측 = 확인(맞게 만들었나) ↔ 우측 = 검증(맞는 걸 만들었나)
[표] 4단계 ↔ 4레벨 거울 매칭 — 출제 1순위 즉답표.
| 좌측 개발 단계 | ↔ | 우측 테스트 레벨 | 매칭 근거 |
|---|---|---|---|
| 요구분석 | ↔ | 인수 테스트 | 요구 충족 = 고객이 받을지 |
| 시스템설계 | ↔ | 시스템 테스트 | 단어가 그대로 매칭(가장 직관적) |
| 상세설계 | ↔ | 통합 테스트 | 모듈 인터페이스 설계 = 모듈 결합 검증 |
| 구현(코딩) | ↔ | 단위 테스트 | 코드 한 단위 작성 = 그 단위 검증 |
🔑 암기 자가 검증 한 줄 — '위에 있을수록 큰 단위'. 요구분석(가장 큰 그림)↔인수(가장 큰 그림), 구현(가장 작은 코드)↔단위(가장 작은 검증). ⚠️ 함정 매칭 자리 뒤바꿈 — '구현↔인수'(→구현↔단위) · '요구분석↔단위'(→요구분석↔인수) · '상세설계↔시스템'(→상세설계↔통합). 망설이면 '위에 있을수록 큰 단위'로 자가 검증. 🎯 빈출 도식 그대로를 보기로 옮긴 매칭 문제가 매회 1순위. 이 한 장이 17강 전체를 묶는다. 📝 기출 '옳지 않은 매칭은?' 소거형 단골. 1과목 5강 결합도/응집도, 13강 단위/통합과 함께 모든 테스트 강의의 중심축.
단통시인 — V모델 4레벨 진행 순서 ·V모델·1순위·
[흐름] 거울 매칭의 우측 4레벨만 떼서 진행 순서 로 외운 것. 작은 단위에서 큰 단위로.
[V모델 우측 4레벨 진행 순서]
① 단위 — 함수·메서드·클래스 (코드 한 조각)
↓
② 통합 — 모듈 결합·인터페이스
↓
③ 시스템 — 전체 시스템 (기능 + 비기능)
↓
④ 인수 — 고객·실 환경 (릴리스 직전)
[표] 4레벨 한 줄 — 검증 주체·대상.
| # | 레벨 | 검증 주체 | 검증 대상 |
|---|---|---|---|
| 단 | 단위(Unit) | 개발자 | 함수·메서드·클래스 |
| 통 | 통합(Integration) | 개발자·QA | 모듈 간 인터페이스 |
| 시 | 시스템(System) | QA | 전체 시스템(기능 + 비기능) |
| 인 | 인수(Acceptance) | 고객·발주자 | 요구 충족 여부 |
💡 자동차 4단계 검수 — 부품 단품 검사(단위) → 완성차 시운전(통합) → 출고 직전 종합 주행(시스템) → 고객 시승회(인수).
🔑 암기 단통시인 — 단위·통합·시스템·인수. ⚠️ 함정 순서 뒤바꿈 — '단위→시스템→통합→인수'(시·통 자리 바뀜) · '인수→시스템→통합→단위'(역순). 시스템이 먼저(개발 조직 안), 인수가 마지막(고객 환경). 🎯 빈출 진행 순서 정렬형이 매회. '거꾸로 = 함정'이면 무조건 단통시인.
① 단위 테스트 — 부품 단품 검사 ·레벨별 테스트·
[정의] 단위 테스트(Unit Test) = 함수·메서드·클래스 같은 가장 작은 단위(unit)를 격리 해서 검증. 개발자가 작성·실행 하고, 내부 코드를 보면서(화이트박스 비중 ↑) 진행. V모델 우측 가장 아래 칸.
[표] 단위 테스트 4본질.
| 본질 | 한 줄 |
|---|---|
| 단품 | 함수 1개·메서드 1개·클래스 1개 단위 |
| 격리 | 외부 의존(DB·API·파일)은 Mock·Stub으로 대체 |
| 빠름 | 1초당 수백 건 실행 가능 |
| 자동화 친화 | xUnit 계열 — JUnit·Jest·PyTest·NUnit |
💡 엔진·브레이크·핸들을 한 부품씩 떼어 테스트 벤치에 올려 작동 OK인지 확인하는 부품 단품 검사. 다른 부품과의 연결은 임시 시뮬레이터(Mock·Stub)로 대체. CI 파이프라인 핵심 — push → 빌드 → JUnit 자동 실행 → 커버리지 미달 시 머지 차단(16강 Jenkins 회수).
🔑 암기 단위 = 단품·격리·JUnit·개발자·화이트박스 비중 ↑. ⚠️ 함정 Mock(행위 검증·호출 기록) vs Stub(상태 검증·고정 응답) 매칭은 13강에서 본격 — 단위 = 화이트박스 비중이지 블랙박스 아님. 🎯 빈출 '함수·메서드 단위 검증' · 'JUnit·개발자가 코드 보면서' → 단위.
② 통합 테스트 — 완성차 시운전 ·레벨별 테스트·
[정의] 통합 테스트(Integration Test) = 단위 테스트를 통과한 모듈들을 결합 해서 모듈 간 인터페이스·상호작용 을 검증. V모델 우측 두 번째 칸.
[표] 통합 4방식 — 키워드 매칭만(스텁/드라이버 본격 예제는 18강).
| 방식 | 한 줄 키워드 |
|---|---|
| 하향식(Top-Down) | 상위 → 하위, 스텁(Stub) 으로 하위 대체 |
| 상향식(Bottom-Up) | 하위 → 상위, 드라이버(Driver) 로 상위 대체 |
| 빅뱅(Big-Bang) | 모듈을 다 만들고 한 번에 결합 |
| 샌드위치(Sandwich) | 하향 + 상향 동시(하이브리드) |
💡 부품(단위)이 통과한 다음 한 차에 결합해 도로에서 굴려보는 완성차 시운전. 부품끼리 잘 맞물리는지(인터페이스)가 핵심. 실제 의존(DB·API)과 연결하므로 블랙박스 비중 ↑.
🔑 암기 통합 = 결합·인터페이스·완성차 시운전. 하향식↔스텁 / 상향식↔드라이버. ⚠️ 함정 하향식↔스텁, 상향식↔드라이버 자리 뒤바꿈이 단골. '상위 대체=드라이버, 하위 대체=스텁'으로 구분. 본격 비교(하스상드)는 18강. 🎯 빈출 '모듈 결합·인터페이스 검증' · '하향식·상향식·스텁·드라이버' → 통합.
③ 시스템 테스트 — 기능 + 비기능 ·레벨별 테스트·1순위·
[정의] 시스템 테스트(System Test) = 통합을 통과한 전체 시스템 이 기능 + 비기능 요구사항을 모두 만족하는지 검증. V모델 우측 세 번째 칸, 시스템설계의 거울.
[표] 검증 대상 — 기능은 통합까지 본 영역, 비기능이 시스템 테스트에서 본격.
| 구분 | 검증 대상 |
|---|---|
| 기능(Functional) | 로그인·결제·검색 동작 (통합까지 본 영역) |
| 비기능(Non-Functional) | 성능·부하·보안 / UI·UX·호환성 / 가용성·신뢰성·내구성 |
[표] 비기능 테스트 주요 종류.
| 종류 | 한 줄 |
|---|---|
| 성능(Performance) | 정상 부하에서 응답시간·처리량 측정 |
| 부하(Load) | 점진적 부하 증가로 한계점 측정 |
| 스트레스(Stress) | 한계점 초과 부하로 안정성 검증 |
| 내구성(Endurance) | 장시간 부하로 메모리 누수·성능 저하 검증 |
| 보안(Security) | 인증·인가·암호화·취약점 검증 |
| 호환성(Compatibility) | 다양한 OS·브라우저·디바이스 동작 검증 |
💡 출고 직전 종합 주행 + 충돌 안전성 + 연비 + 소음 + 고온 환경 검사. 굴러가는지(기능)뿐 아니라 비기능까지 모두. 부하는 피크 트래픽 시뮬레이션, 회복력은 무작위 서버 종료 후 자동 복구 검증(카오스 엔지니어링) — 도메인마다 비기능의 초점이 다르다.
🔑 암기 시스템 = 전체 시스템 + 기능 + 비기능. ⚠️ 함정 '시스템 테스트는 기능만 검증한다' · '성능·보안은 시스템 테스트 대상이 아니다' · '부하는 단위 테스트에서' 는 100% 함정. 정답은 항상 기능 + 비기능. 🎯 빈출 '기능만' 함정이 매년 단골. 비기능 종류 매칭.
④ 인수 테스트 6종 + 알파 vs 베타 ·레벨별 테스트·1순위·
[정의] 인수 테스트(Acceptance Test) = 사용자·고객·발주자가 요구 충족 여부를 확인하고 인수 여부를 결정 하는 최종 테스트. 개발자가 아닌 사용자 시각. V모델 우측 가장 위 칸, 요구분석의 거울.
[표] 인수 테스트 6종 — 알파·베타가 단독 빈출 1순위, 나머지는 키워드 매칭만.
| # | 종류 | 한 줄 |
|---|---|---|
| ① | 사용자 인수(UAT) | 실제 사용자가 요구 충족 여부 확인 |
| ② | 운영 인수(Operational) | 운영팀이 운영 절차·장애 대응 검증 |
| ③ | 계약 인수(Contract) | 발주자가 계약 요구사항 충족 검증 |
| ④ | 규제 인수(Regulatory) | 규제기관·법령 요구사항 충족 검증 |
| ⑤ | 알파(Alpha) | 개발자 입회·통제 환경·일부 사용자 |
| ⑥ | 베타(Beta) | 개발자 입회 X·실 환경·다수 사용자 |
[표] 알파 vs 베타 — 알=개·베=고. 자리만 바꾼 함정이 매년 단골.
| 비교 축 | 알파 테스트 | 베타 테스트 |
|---|---|---|
| 장소 | 개발자 측 통제 환경(사내) | 실제 사용자의 실 환경(필드) |
| 개발자 입회 | O (관찰·즉시 디버깅) | X (사용자 단독·피드백만 회수) |
| 참여자 수 | 일부(소규모·내부) | 다수(대규모·일반 사용자) |
| 시점 | 베타보다 먼저 | 알파보다 나중·정식 출시 직전 |
| 한 줄 즉답 | 알파 = 개발자 측 | 베타 = 고객 측 |
💡 사내 시승 vs 고객 시승. 알파는 개발자가 옆에서 보며 사내 직원이 시승(즉시 디버깅 O, 환경 제한적), 베타는 개발자 없이 고객이 실 환경에서 시승(진짜 변수 다 들어감, 즉시 디버깅 어려움). 그래서 알파 → 베타 순서.
🔑 암기 인수 6종 = UAT·운영·계약·규제·알파·베타 / 핵심은 알=개·베=고. 보기 한 줄마다 '개발자 측인가 고객 측인가'만 자가 검증. ⚠️ 함정 '알파 = 실 환경·다수'(→베타) · '베타 = 개발자 입회'(→알파) · '베타가 먼저'(→알파가 먼저) · '알파 다수, 베타 일부'(반대). '발주자' = 계약, '규제기관·법령' = 규제. 🎯 빈출 알파/베타 자리 뒤바꿈이 단독 1순위. 6종 키워드 매칭.
테스트 기법 분류와 회귀
★화이트박스 vs 블랙박스★ ·테스트 기법·1순위·
[정의] 두 박스의 결정적 차이는 내부 코드를 보느냐, 외부 결과만 보느냐.
- 화이트박스(White-Box·구조 기반) = 내부 구조·코드 흐름을 보면서 검증. 개발자가 코드 로직 분석.
- 블랙박스(Black-Box·명세 기반) = 외부 결과·명세만 보면서 검증. QA가 입력 → 출력만 봄.
[표] 화이트 vs 블랙 — 출제 1순위 분류표.
| 비교 축 | 화이트박스 | 블랙박스 |
|---|---|---|
| 별칭 | 구조 기반·Glass Box | 명세 기반·Specification-Based |
| 본질 | 내부 구조·코드 흐름 | 외부 결과·기능 명세 |
| 검증 대상 | 코드 한 줄·분기·경로 | 입력 → 출력 |
| 검증 주체 | 개발자(코드 작성자) | QA(명세 기반) |
| V모델 위치 | 단위 중심(우측 하단) | 통합·시스템·인수 중심(우측 상단) |
| 대표 기법 | 커버리지 4종(문장·분기·조건·경로) | 6기법(동등분할·경계값·결정테이블·상태전이·유스케이스·원인결과) |
[흐름] 화이트박스 커버리지 4종의 강도 순서 — 약함에서 강함으로.
약함 ◄──── 문장 < 분기 < 조건 < 경로 ────► 강함
(실행문) (참/거짓) (개별 조건) (모든 경로)
[표] 커버리지 4종 정의.
| # | 커버리지 | 한 줄 정의 |
|---|---|---|
| ① | 문장(Statement) | 모든 실행문을 최소 1회 실행 (가장 약함) |
| ② | 분기(Branch/Decision) | 모든 분기(if·else·switch)의 참/거짓 양쪽 |
| ③ | 조건(Condition) | 분기 안 개별 조건식의 참/거짓 양쪽 |
| ④ | 경로(Path) | 모든 실행 경로의 조합(가장 강함) |
[참고] 화이트박스 기타 — 기초경로(맥케이브 순환 복잡도 V(G)=E−N+2)·데이터흐름·루프·제어흐름. 블랙박스 기타 — 오류추정·분류트리. 순환 복잡도 정량 계산과 6기법 worked 예제는 18강에서 본격.
🔑 암기 화이트 = 내부 코드(커버리지) / 블랙 = 외부 결과(동경결상). 레벨과 짝지어 단=내 · 통=외. 강도 순서 문장 < 분기 < 조건 < 경로. ⚠️ 함정 '동등분할 = 화이트박스 커버리지'(→블랙박스 6기법) · '블랙박스가 코드 내부 분석'(→화이트) · '단위 = 블랙박스 비중'(→화이트) · '경로가 가장 약함'(→가장 강함) · '맥케이브가 블랙박스'(→화이트 기초경로). 자리 뒤바꿈이 매년 단골. 🎯 빈출 '블랙박스 기법이 아닌 것?'에 분기 커버리지를 끼워 넣는 함정 1순위. 동등분할이 어느 박스냐가 단골. 📝 기출 화블 기법 분류 소거형 매회.
회귀 테스트 — 수정 후 기존 기능 재검증 ·테스트 기법·
[정의] 회귀 테스트(Regression Test) = 소스 코드를 수정한 후, 그 수정이 기존 기능에 부정적 영향을 주지 않았는지 재실행 해서 검증. 새 케이스를 만드는 게 아니라 기존 케이스 풀을 다시 돌린다 — 그래서 자동화 친화·CI 표준.
[흐름] 세 키워드 중 둘 이상이면 100% 회귀.
[회귀 = 수정 + 기존 기능 + 재실행]
① 수정(Modification) — 새 코드·기능·버그 패치
② 기존 기능(Existing) — 수정 영향을 받을 수 있는 기존 기능
③ 재실행(Re-execution) — 기존 테스트 케이스를 다시 돌림
[흐름] CI 안에서 자동 회귀 — 16강 Jenkins로 모인 큰 그림이 여기서 완성.
[코드 수정이 운영까지 가는 자동 흐름]
개발자 코드 수정 → push
↓
CI 트리거 → 자동 빌드
↓
├─ 단위 테스트 (화이트박스·단=내)
├─ 회귀 테스트 (기존 케이스 풀 자동 재실행)
└─ 통합 테스트 (블랙박스·통=외)
↓
통과 → 머지 → 운영 배포
[표] 회귀 vs 살충제 패러독스 — 헷갈리기 쉬운 한 쌍.
| 비교 축 | 회귀 테스트 | 살충제 패러독스 |
|---|---|---|
| 본질 | 수정 후 기존 기능 재검증 | 동일 케이스 반복 → 새 결함 X |
| 케이스 | 재사용(그래서 안전) | 갱신해야 함(그래서 위험) |
| 시험 키워드 | 수정·재실행·기존 기능 | 반복·갱신·발견율 감소 |
💡 새 약(코드 수정)을 처방한 뒤 그 약이 기존 작용에 부작용을 일으키지 않는지 재검사하는 정기 검진. 코드 수정 시 결제·환불·쿠폰 수십~수백 건이 CI 안에서 수 분~수십 분 내 자동 재실행되고, 운영에서 발견된 결함은 회귀 풀에 자동 추가돼 재발을 막는다.
🔑 암기 회귀 = 수정 + 기존 기능 + 재실행. CI 자동 실행이 표준. ⚠️ 함정 '회귀는 새 케이스로 새 기능 검증'(→기존 케이스로 기존 기능) · '회귀 = 살충제 패러독스와 동일'(별개 — 살충제는 케이스 노화 경고) · 'CI 자동 실행은 단위 테스트만'(회귀도 자동 실행 표준). 🎯 빈출 정의 매칭 + CI 자동 실행 통합형. 16강 Jenkins·13강 JUnit·14강 Git과 묶인 통합 보기가 정답인 패턴.
기출 다지기
[기출 1 출제] 다음 보기에서 설명하는 소프트웨어 테스트 원리로 가장 적절한 것은? (설명→용어 찾기)
동일한 테스트 케이스를 반복하여 실행하면 새로운 결함을 발견하기 어려워진다. 따라서 테스트 케이스는 주기적으로 검토하고 갱신해야 한다.
- ① 결함 집중
- ② 조기 테스트
- ③ 살충제 패러독스
- ④ 정황 의존성
정답 및 해설 보기
정답 ③
'동일 케이스 반복 + 갱신' 두 키워드 직격 = 살충제 패러독스. 같은 케이스만 반복하면 코드가 그 케이스에 적응해 새 결함이 안 잡힌다. 1990년 보리스 베이저(Boris Beizer)가 정식화, ISTQB 7원리 6번.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 오답 | 결함이 모듈에 몰림(파레토). '반복'과 무관 |
| ② | 오답 | Shift Left — 일찍 시작. '갱신'과 무관 |
| ③ | 정답 | '동일 케이스 반복 + 갱신' 직격 |
| ④ | 오답 | 도메인마다 강도 다름. '반복'과 무관 |
🔑 '반복·갱신·발견율 감소' 둘 이상이면 100% 살충제.
[기출 2 출제] 다음 중 테스트 케이스의 구성요소에 해당하지 않는 것은? (아닌 것 고르기)
- ① 식별자
- ② 항목명
- ③ 입력값
- ④ 개발자 의도
정답 및 해설 보기
정답 ④
케이스 5요소 = 식·항·입·기·절. '개발자 의도'는 5요소에 없는 함정 보기다.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 5요소 | 식별자(TC-001) |
| ② | 5요소 | 항목(검증 대상) |
| ③ | 5요소 | 입력값 |
| ④ | 정답(아님) | 개발자 머릿속 — 케이스에 적지 않음 |
🔑 '개발자 의도'·'코드 줄 수'·'테스트 비용'이 보기에 끼면 그게 정답(아님).
[기출 3 출제] 다음 중 V모델에서 좌측 개발 단계와 우측 테스트 레벨의 매칭으로 옳지 않은 것은? (아닌 것 고르기)
- ① 요구분석 ↔ 인수 테스트
- ② 시스템설계 ↔ 시스템 테스트
- ③ 상세설계 ↔ 시스템 테스트
- ④ 구현 ↔ 단위 테스트
정답 및 해설 보기
정답 ③
상세설계 ↔ 통합 테스트가 정답 매칭. ③은 시스템설계가 들어갈 자리에 상세설계가 끼어든 함정이다.
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 옳음 | 요구 충족 = 고객 인수 |
| ② | 옳음 | 단어 직관 매칭 |
| ③ | 정답(틀림) | 상세설계 ↔ 통합(인터페이스 설계=결합 검증) |
| ④ | 옳음 | 코드 작성 = 그 단위 검증 |
🔑 '위에 있을수록 큰 단위'로 자가 검증. 요구분석↔인수, 구현↔단위.
[기출 4 출제] 다음 중 V모델에서 테스트가 진행되는 순서로 옳은 것은? (옳은 순서 고르기)
- ① 단위 → 시스템 → 통합 → 인수
- ② 단위 → 통합 → 시스템 → 인수
- ③ 인수 → 시스템 → 통합 → 단위
- ④ 통합 → 단위 → 시스템 → 인수
정답 및 해설 보기
정답 ②
단통시인 — 단위 → 통합 → 시스템 → 인수. 작은 단위에서 큰 단위로 올라간다.
| 순서 | 레벨 | 검증 대상 |
|---|---|---|
| 단 | 단위 | 함수·메서드·클래스 |
| 통 | 통합 | 모듈 결합·인터페이스 |
| 시 | 시스템 | 전체 시스템(기능+비기능) |
| 인 | 인수 | 고객·실 환경 |
🔑 ①은 시·통 자리 바뀜, ③은 역순, ④는 단·통 자리 바뀜. '거꾸로 = 함정'이면 단통시인.
[기출 5 출제] 다음 중 알파 테스트와 베타 테스트에 대한 설명으로 옳은 것은? (옳은 설명 고르기)
- ① 알파 테스트는 실 환경에서 다수의 일반 사용자가 진행한다
- ② 알파 테스트는 개발자가 있는 통제 환경에서 일부 사용자가 진행한다
- ③ 베타 테스트는 개발자가 입회한다
- ④ 베타 테스트는 알파 테스트보다 먼저 진행한다
정답 및 해설 보기
정답 ②
알=개·베=고 — 알파 = 개발자 측(통제 환경·일부), 베타 = 고객 측(실 환경·다수).
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 오답 | 실 환경·다수는 베타 |
| ② | 정답 | 알파 = 통제 환경·일부 |
| ③ | 오답 | 베타는 개발자 입회 X |
| ④ | 오답 | 알파 → 베타 순서 |
🔑 보기 한 줄마다 '개발자 측인가 고객 측인가'만 자가 검증.
[기출 6 출제] 다음 중 시스템 테스트의 검증 대상으로 옳은 것은? (옳은 설명 고르기)
- ① 함수·메서드 단위의 코드 동작
- ② 모듈 간 인터페이스 결합
- ③ 시스템 전체의 기능 + 비기능(성능·부하·보안·호환성)
- ④ 고객의 인수 여부 결정
정답 및 해설 보기
정답 ③
시스템 테스트만 기능 + 비기능 을 함께 검증한다. ①은 단위, ②는 통합, ④는 인수.
| 선지 | 판정 | 정체 |
|---|---|---|
| ① | 오답 | 단위 테스트 |
| ② | 오답 | 통합 테스트 |
| ③ | 정답 | 시스템 = 전체 + 기능 + 비기능 |
| ④ | 오답 | 인수 테스트 |
🔑 '기능만 검증한다'는 100% 함정. 성능·보안은 시스템 테스트 핵심 대상.
[기출 7 출제] 다음 중 블랙박스 테스트 기법에 해당하지 않는 것은? (아닌 것 고르기)
- ① 동등 분할
- ② 경계값 분석
- ③ 결정 테이블
- ④ 분기 커버리지
정답 및 해설 보기
정답 ④
블랙박스 6기법 = 동등분할·경계값·결정테이블·상태전이·유스케이스·원인결과. 분기 커버리지는 화이트박스 커버리지 4종 중 하나다.
| 선지 | 분류 | 정체 |
|---|---|---|
| ① | 블랙 | 6기법 |
| ② | 블랙 | 6기법 |
| ③ | 블랙 | 6기법 |
| ④ | 정답(아님) | 분기 = 화이트박스 커버리지 |
🔑 '문장·분기·조건·경로 = 화이트' / '동·경·결·상·유·원 = 블랙'. '동등분할 = 화이트박스'도 100% 함정.
[기출 8 출제] 다음 보기에서 설명하는 테스트로 가장 적절한 것은? (설명→용어 찾기)
코드를 수정한 후, 그 수정이 기존 기능에 부정적 영향을 주지 않았는지 기존 테스트 케이스를 다시 실행해서 검증한다. CI 파이프라인에서 자동 실행이 표준이다.
- ① 단위 테스트
- ② 시스템 테스트
- ③ 인수 테스트
- ④ 회귀 테스트
정답 및 해설 보기
정답 ④
'수정 + 기존 기능 + 재실행' 세 키워드 직격 = 회귀 테스트. 새 케이스가 아니라 기존 케이스 풀을 다시 돌리는 게 정체이고, 그래서 CI 자동 실행이 표준이다(16강 Jenkins 회수).
| 선지 | 판정 | 근거 |
|---|---|---|
| ① | 오답 | 함수·메서드 단위 검증 |
| ② | 오답 | 전체 시스템 + 기능 + 비기능 |
| ③ | 오답 | 고객 인수 결정 |
| ④ | 정답 | 수정 + 기존 + 재실행 직격 |
🔑 'CI 자동 실행은 단위 테스트만'도 함정 — 회귀도 자동 실행 표준.
한 장 요약
| 영역 | 핵심 | 암기팁 |
|---|---|---|
| 테스트 정의 | 결함 발견 ≠ 품질 증명. 존재는 증명, 부재는 증명 못 함 | 통과=버그 없음 = 함정 |
| 테스트 7원리 | 결함존재·조기·초완전성불가·집중·없음오류·살충제·정황 | 결조초집결살정 |
| 출제 70% 핵심 3 | 살충제(반복X·갱신) · 집중(파레토 80/20) · 조기(Shift Left·1→200) | 살집조 |
| 케이스 5요소 | 식별자·항목·입력·기대결과·절차 | 식·항·입·기·절 |
| 주변 용어 / 오라클 | 시나리오·오라클·베드·하네스 / 참·샘플·휴·일관 | 시오베하 / 참샘휴일관 |
| 영역 | 핵심 | 암기팁 |
|---|---|---|
| 케이스 설계 4절차 | 계획 → 설계 → 실행 → 리포팅 | 계·설·실·리 |
| V모델 정의 | 폭포수 확장 + 단계별 테스트 짝. 위험 분석 없음 | 위험 분석 = 나선형(함정) |
| V모델 거울 매칭 | 요구↔인수·시스템설계↔시스템·상세설계↔통합·구현↔단위 | 위에 있을수록 큰 단위 |
| 진행 순서 | 단위 → 통합 → 시스템 → 인수 | 단통시인 |
| 레벨별 본질 | 단위=단품/통합=결합/시스템=기능+비기능/인수=고객 | 단=화이트, 통 이상=블랙 |
| 영역 | 핵심 | 암기팁 |
|---|---|---|
| 인수 6종 | UAT·운영·계약·규제·알파·베타 | 알파/베타가 1순위 |
| 알파 vs 베타 | 알파=개발자 측(통제·일부) / 베타=고객 측(실환경·다수) | 알=개·베=고 |
| 화이트 vs 블랙 | 화이트=커버리지 4종 / 블랙=6기법 | 화이트=커버리지·블랙=동경결상 |
| 커버리지 강도 | 문장 < 분기 < 조건 < 경로 | 경로가 가장 강함 |
| 회귀 테스트 | 수정 + 기존 기능 + 재실행. CI 자동 실행 표준 | 회귀=수정+기존+재실행 |
🎯 합격 한 끗: 17강 출제의 80% 이상이 다섯 매칭 안에서 나온다 — 결조초집결살정(=살집조) · V모델 거울 매칭 · 단통시인 · 알=개·베=고 · 화이트=커버리지·블랙=동경결상. 시험 직전엔 이 다섯과 함정 5쌍만 다시 훑고 들어간다.
🌟 함정 5쌍 종합(시험장 직전 5분 카드): ① '블랙박스 = 코드 내부 분석' → 코드 내부는 화이트 · ② '동등 분할 = 화이트박스' → 블랙박스 6기법 · ③ '구현 ↔ 인수' → 구현 ↔ 단위 · ④ '알파 = 실 환경·다수' → 알파는 통제·일부 · ⑤ '살충제 = 결함이 모듈에 몰림' → 살충제는 동일 케이스 반복, 모듈 집중은 결함 집중.
