🎯 블랙박스 테스트란(명세 기반 테스트)?
소프트웨어 내부 구조나 코드에 대한 정보 없이,
입력과 출력만을 기준으로 테스트하는 기법이다.
사용자의 입장에서 “기능이 제대로 작동하는가?”만 확인한다.
- 프로그램 외부 사용자의 요구사항 명세를 보면서 수행하는 (기능)테스트 이다.
- 소프트웨어의 특징, 요구사항, 설계 명세서 등에 초점을 맞춰 테스트가 이루어진다.
- 기능 및 동작 위주의 테스트를 진행하기 때문에 내부 구조나 작동 원리를 알지 못해도 가능하다.
- 명세 기반 테스트이다.
[동경결상 유분페 원비오]
| 유형 | 키워드 | 요약 개념 설명 | 예시 |
| 동등 분할 테스트 (=동치 분할, 균등 분할, 동치 클래스 분해 테스트) Equivalence Partitioning Testing | 입력값 그룹 나눔 | 유효/무효 값을 그룹으로 나누고 각 그룹에서 대표값 하나만 테스트 | 나이 입력값: 0~120 (유효), –5, 200 (무효) |
| 경계값 분석 테스트 (=한계값 테스트) Boundary Value Analysis Testing | 경계값 근처 테스트 | 에러가 잘 발생하는 최소/최대 값 주변을 집중적으로 테스트 | 1~100일 때 → 0,1 / 100,101 |
| 결정 테이블 테스트 | 조건-결과 조합 | 조건과 그에 따른 결과를 표로 정리하고 누락 없이 테스트 | (회원여부, 결제수단) → 할인율 결정 |
| 상태 전이 테스트 | 상태 흐름 확인 | 어떤 이벤트에 따라 시스템 상태가 어떻게 변하는지 확인 | ATM: 로그인 → 실패 → 계좌잠금 |
| 유스케이스 기반 테스트 | 사용자 시나리오 | 사용자의 실제 사용 흐름을 기반으로 테스트를 설계 | 검색 → 장바구니 → 결제 → 배송 |
| 분류 트리 테스트 | 속성 값 분류 | 입력 조건들을 트리 구조로 분류하여 조합을 테스트 | 남성+20대+서울, 여성+30대+부산 등 |
| 페어와이즈 테스트 | 조건쌍 조합 | 전체 조건 조합 대신, 2개씩 쌍으로 조합해 효율적인 테스트 | A,B,C 조건 중 (A&B), (A&C), (B&C) 조합 테스트 |
| 원인-결과 그래프 테스트 | 논리 연결 | 원인(조건)과 결과를 논리 회로처럼 그래프로 연결해 테스트 도출 | "로그인 실패" → 경고창 표시, 3회 실패 → 계정 잠금 |
| 비교 테스트 | 유사 시스템 비교 | 기존 시스템이나 유사 제품과 결과를 비교하여 테스트 | 버전1 vs 버전2의 출력 비교 |
| 오류 추정 테스트 | 오류 발생 예상 | 과거에 오류가 잦았던 부분을 중심으로 테스트 집중 | 입력 폼에 자주 오류 나면 그 부분을 반복 테스트 |
🧩 동등 분할 테스트(=동치분할, 균등분할, 동치클래스분해)
✅ 1. 개념 설명
🔹 동등 분할 테스트란?
**입력값을 의미 있는 그룹(=동등 클래스)**으로 나누고,
각 그룹(클래스)에서 대표값 하나만 선택해 테스트하는 방식이야.
🧠 2. 비유로 이해하기
🍎 비유: 과일 상자 검사
너가 사과, 배, 감이 섞인 과일 상자를 받았다고 해보자.
이걸 다 일일이 다 까서 확인하지 않고, 종류별로 하나씩만 먹어보는 것이 동등 분할이야.
- 사과 10개 → 하나만 까봄
- 배 7개 → 하나만 까봄
- 감 5개 → 하나만 까봄
✅ 사과 대표가 괜찮으면 사과는 OK!
❌ 만약 배 대표에서 이상 있으면 → 전체 배가 의심 대상!
🧪 3. 실제 예시로 이해하기
예시: 나이 입력 칸 (0 ~ 120세만 가능)
사용자가 자신의 나이를 입력하는 프로그램이 있다고 하자.
입력 가능한 나이는 0세 이상 120세 이하야.
이때 가능한 입력값은?
- ❗ 유효 입력값 (Valid Class)
- 0 ≤ 나이 ≤ 120
- ⚠️ 무효 입력값 (Invalid Class)
- 나이 < 0
- 나이 > 120
▶ 동등 분할 클래스 분리
| 클라스 이름값 | 예시 | 설명 |
| 유효값 클래스 | 0~120 | 정상적인 나이 범위 |
| 무효값 클래스 1 | -1, -100 | 음수 값은 허용되지 않음 |
| 무효값 클래스 2 | 121, 200 | 나이가 너무 많음 (초과값) |
✅ 테스트할 대표값 선택 예시
- 유효 클래스 → 25
- 무효 클래스 1 → -1
- 무효 클래스 2 → 130
👉 이렇게 총 3개의 대표값으로 테스트하면,
전체 범위를 다 검사하지 않아도 핵심 오류를 잡아낼 수 있어!
📌 4. 왜 사용하는가?
- 입력값이 너무 많을 때 테스트 케이스를 효율적으로 줄이기 위해
- 동일한 결과가 나올 가능성이 높은 값들끼리 묶어서 대표만 테스트
- 실무에서 자주 쓰이는 핵심 기법이야 (검사 효율성 높임)
📝 5. 정리 포인트
| 목적 | 입력값을 의미 있는 그룹으로 나눠 효율적인 테스트 |
| 전략 | 각 그룹(=동등 클래스)에서 대표값 1개만 선택 |
| 장점 | 테스트 케이스 수를 줄이고, 테스트 누락 없이 설계 가능 |
| 핵심 질문 | “이 값과 저 값이 동일한 의미라면, 하나만 테스트하면 되지 않을까?” |
💬 더 쉬운 요약 한 줄
“비슷한 건 묶고, 하나만 검사하자!”
= 동등 분할 테스트
🧩 경계값 분석 테스트(=한곗값 테스트)
✅ 1. 개념 설명
🔹 경계값 분석 테스트란?
입력값의 **최솟값, 최댓값 경계 근처(±1)**에서
오류가 발생하기 쉬운 지점들을 집중적으로 테스트하는 기법이야.
📌 왜? → 대부분의 오류는 경계에서 발생하기 때문이야!
🧠 2. 비유로 이해하기
🚪 비유: 문턱 넘기
사람들이 문을 통과할 때, 가장 자주 넘어지는 위치는 문턱이지?
- 문 중간: 멀쩡히 잘 지나감
- 문턱 바로 위: 발이 걸려서 넘어질 가능성 큼
👉 그래서 문턱 주변(경계)을 집중적으로 점검하는 것과 같아!
🧪 3. 실제 예시로 이해하기
예시: 나이 입력 (1세 ~ 100세 입력 가능)
▶ 테스트할 값
| 테스트 구간 | 입력값 | 설명 |
| 최소값 전 | 0 | ❌ 오류 유도 |
| 최소값 | 1 | ✅ 정상 |
| 최소값+1 | 2 | ✅ 정상 |
| 최대값-1 | 99 | ✅ 정상 |
| 최대값 | 100 | ✅ 정상 |
| 최대값 초과 | 101 | ❌ 오류 유도 |
👉 총 6개 테스트 케이스로 경계 근처를 철저히 확인!
🧠 왜 이렇게 하냐면?
- 사람이 실수하는 가장 대표적인 영역이 경계값이야
- 프로그래머가 조건문을 >=인지 >로 잘못 쓰는 실수도 많고
- “이거 100까지만 입력되게 했는데 101도 들어가네?” 같은 문제 잡기 쉬워!
📌 4. 정리 포인트
| 항목 | 설명 |
| 목적 | 오류가 자주 나는 **경계(최소/최대 근처)**를 집중 테스트 |
| 방법 | 최소/최대 값과 그 주변(–1, +1) 값을 포함해 테스트 |
| 테스트 수 | 일반적으로 6개 (하한–1, 하한, 하한+1, 상한–1, 상한, 상한+1) |
| 장점 | 단순하지만 효과 높은 테스트 기법 |
📘 5. 유사 개념과 비교
| 기법 | 차이점 |
| 동등 분할 | 그룹으로 나누고 대표값만 테스트 |
| 경계값 분석 | 각 그룹의 경계 주변 값들을 정밀하게 테스트 |
👉 경계값 분석은 동등 분할의 확장판이라 볼 수 있어!
💬 쉬운 요약 한 줄
“문턱에서 자주 넘어지니까, 문턱부터 검사하자!”
= 경계값 분석 테스트
🧩 결정 테이블 테스트
✅ 1. 개념 설명
🔹 결정 테이블 테스트란?
여러 조건들의 **조합에 따른 결과(동작)**를 표 형태로 정리한 뒤,
조건-결과 관계가 누락 없이 잘 동작하는지 확인하는 테스트야.
📌 조건이 많아질수록 복잡해지기 때문에, 체계적으로 정리하는 데 유용해!
🧠 2. 비유로 이해하기
🍱 비유: 택배 배송 정책
지역과 무게에 따라 배송비가 달라지는 상황!
- 조건1: 지역 (도서산간 / 일반)
- 조건2: 무게 (5kg 이하 / 초과)
- 결과: 배송비 3000원 / 5000원 / 7000원
👉 조건 → 결과를 표로 만든 게 결정 테이블이야!
🧪 3. 실제 예시로 이해하기
예시: 쇼핑몰 할인 정책
조건:
- 회원 여부 (Y, N)
- 결제 수단 (카드, 현금)
결과:
- 회원 + 카드 → 10% 할인
- 회원 + 현금 → 5% 할인
- 비회원 → 할인 없음
▶ 결정 테이블
| ① | Y | 카드 | 10% 할인 |
| ② | Y | 현금 | 5% 할인 |
| ③ | N | 카드 | 할인 없음 |
| ④ | N | 현금 | 할인 없음 |
👉 이렇게 정리된 테이블을 보고 각 조합대로 시스템이 정확히 동작하는지 테스트하는 거야.
📌 4. 왜 사용하는가?
- 조건이 2~3개 이상 되면 직접 머리로 관리하기 어려움
- 조건과 결과 간의 조합을 표로 정리하면 누락 없이 확인 가능
- 로직이 복잡한 경우 특히 유용함
✅ 5. 정리 포인트
| 목적 | 조건 조합에 따른 모든 결과를 누락 없이 테스트 |
| 구조 | 조건 x 결과의 조합을 **표 형식(테이블)**으로 정리 |
| 장점 | 복잡한 조건 처리를 체계적이고 명확하게 테스트 |
| 활용처 | 할인 정책, 요금제, 정책 로직 등 조건-행동 분기가 많은 시스템 |
🧠 6. 핵심 요약 한 줄
“조건과 결과를 표로 정리해서 빠짐없이 점검하자!”
= 결정 테이블 테스트
💡 7. 유사 개념과 차이점
| 테스트 유형 | 차이점 |
| 조건 커버리지(화이트박스) | 코드 내부 조건 하나하나를 체크함 |
| 결정 테이블 테스트(블랙박스) | 입력 조건 조합 → 출력 결과 확인 (사용자 관점) |
🧩 상태 전이 테스트
✅ 1. 개념 설명
🔹 상태 전이 테스트란?
시스템의 상태가 어떤 조건(입력)에 따라 어떻게 바뀌는지를 테스트하는 기법이야.
“현재 상태에서 어떤 이벤트가 발생하면 다음 상태로 잘 바뀌는가?”를 보는 거지.
📌 특히, 시스템이 상태를 기억하거나, 흐름에 따라 반응이 달라지는 경우에 적합해!
🧠 2. 비유로 이해하기
🚦 신호등 비유
- 신호등은 현재 상태가 "빨간불"이면,
- 타이머(=이벤트)가 발생할 때 → "초록불" 상태로 **전이(변화)**되지?
이처럼 시스템이 상태 → 입력 → 상태의 흐름을 갖는다면
상태 전이 테스트로 그 흐름이 정확한지 점검하는 거야!
🧪 3. 실제 예시로 이해하기
예시: ATM 로그인 시스템
시스템 정의:
- 최대 3번 로그인 실패하면 계좌 잠금 상태
- 로그인 성공 시 정상 상태로 복귀
| 현재 상태 | 이벤트(입력) | 다음 상태 | 설명 |
| 미로그인 | 로그인 실패 | 1회 실패 | 1회 틀림 |
| 1회 실패 | 로그인 실패 | 2회 실패 | 계속 틀림 |
| 2회 실패 | 로그인 실패 | 계좌 잠김 | 3번 틀려서 잠김 |
| 계좌 잠김 | 로그인 시도 | 계좌 잠김 | 상태 유지 |
| 미로그인 | 로그인 성공 | 로그인됨 | 성공 시 정상 이동 |
| 1~2회 실패 | 로그인 성공 | 로그인됨 | 성공 시 초기화 |
👉 이런 상태와 이벤트의 전이 흐름을 표로 그려서, 각 경로가 정상 작동하는지 테스트하는 게 핵심이야!
🧩 유스케이스 테스트
✅ 1. 개념 설명
🔹 유스케이스 테스트란?
사용자의 실제 사용 시나리오를 기준으로
시스템이 제대로 동작하는지 확인하는 테스트 기법이야.
📌 복잡한 조건이나 내부 로직이 아니라,
“사용자는 실제로 어떻게 행동할까?”를 따라가며 테스트하는 거야.
🧠 2. 비유로 이해하기
🛒 비유: 마트에서 장보기
- 고객이 마트에 들어와서,
- 상품을 고르고
- 장바구니에 담고
- 계산대에 가서 결제하고
- 영수증을 받고 나가는 흐름
👉 이게 하나의 **유스케이스(사용 흐름)**이고,
이 전체 과정이 정상적으로 작동하는지 확인하는 게 유스케이스 테스트야!
🧪 3. 실제 예시로 이해하기
예시: 온라인 쇼핑몰
사용자 시나리오: “회원이 상품을 검색해서 구매까지 완료하는 과정”
▶ 유스케이스 시나리오
- 홈페이지 접속
- 로그인
- 상품 검색
- 상품 선택 후 장바구니 담기
- 장바구니 확인
- 결제 진행
- 주문 완료 화면 확인
이 전체 흐름이 끊기지 않고 잘 작동하는지 확인하는 것 = 유스케이스 테스트
✅ 4. 왜 사용하는가?
- 실제 사용자의 시나리오 기반이기 때문에,
시스템이 현실에서 정말 잘 작동하는지 테스트할 수 있어 - 기술보다 **사용자 경험(UX)**에 초점을 맞춘 테스트임
📌 5. 정리 포인트
| 목적 | 사용자의 **전체 흐름(Use Case)**이 정상적으로 작동하는지 확인 |
| 핵심 | 사용자가 기대하는 행동 시나리오를 따라가며 테스트 |
| 초점 | 기능이 아닌 상황과 절차의 연결성 |
| 테스트 범위 | 보통 여러 기능을 하나의 시나리오로 묶어 테스트함 |
🎯 유스케이스 테스트가 효과적인 경우
- 고객 서비스 흐름 (쇼핑몰, 은행, 병원 등)
- 로그인 → 서비스 이용 → 결제처럼 단계적인 흐름이 중요한 경우
- 기능 간 연결이 중요한 워크플로우 기반 시스템
💬 핵심 요약 한 줄
“실제 사용자처럼 행동해 보며, 시스템이 끝까지 잘 작동하는지 확인한다”
= 유스케이스 테스트
🧩분류 트리 테스트
✅ 1. 개념 설명
🔹 분류 트리 테스트란?
입력 값의 속성들을 분류하고,
각 속성의 가능한 값 조합을 트리 구조로 정리해 테스트 케이스를 만드는 기법이야.
📌 조건이 많고 조합이 다양할 때, 체계적으로 누락 없이 테스트하기 위해 사용해!
🧠 2. 비유로 이해하기
🎄 비유: 크리스마스트리 속성 정리
예를 들어, 크리스마스트리를 고를 때:
- 🎄 종류: 소나무 / 전나무
- 🎨 색상: 초록 / 하양 / 빨강
- 🌟 장식 여부: 있음 / 없음
→ 이걸 트리 구조로 정리하면,
모든 가능한 조합을 빠짐없이 보기 쉽게 나눌 수 있어.
이렇게 속성(조건)과 값(분류)을 트리 형태로 분류해서
테스트 케이스를 도출하는 게 분류 트리 테스트야!
🧪 3. 실제 예시로 이해하기
예시: 회원 가입 폼 테스트
가입 폼에는 다음과 같은 조건이 있어:
- 성별: 남 / 여
- 나이: 성인 / 미성년자
- 국적: 내국인 / 외국인
이걸 트리 구조로 정리하면 아래처럼 나와:
┌─ 남
성별 ───┤
└─ 여
┌─ 성인
나이 ───┤
└─ 미성년자
┌─ 내국인
국적 ───┤
└─ 외국인가능한 조합 예:
- 남 + 성인 + 내국인
- 여 + 미성년자 + 외국인
- ...
→ 이 조합들을 바탕으로 테스트 케이스를 뽑아서 테스트하는 것이 분류 트리 테스트야.
📌 4. 왜 사용하는가?
- 조건이 많을수록 경우의 수가 기하급수적으로 늘어나는데,
- 분류 트리를 사용하면 누락 없이 체계적으로 정리할 수 있어.
📌 특히, 페어와이즈 테스트 전에 전체 조합을 시각적으로 보는 데 유용해.
✅ 5. 정리 포인트
| 목적 | 여러 속성과 값들의 모든 조합을 빠짐없이 정리 |
| 구조 | 조건과 값을 트리 형태로 표현 |
| 특징 | 시각적으로 명확하고, 누락 없는 테스트 설계 가능 |
| 활용처 | 폼 입력, 기기 설정, 정책 적용 등 조건이 다양한 기능 테스트 |
💬 핵심 요약 한 줄
“조건과 값들을 트리로 나눠서, 가능한 모든 조합을 테스트한다!”
= 분류 트리 테스트
+) 분류 트리 vs 결정 테이블 비교
| 항목 | 분류 트리 테스트 | 결정 테이블 테스트 |
| 🧠 기본 개념 | 조건들을 트리 구조로 나눠서 모든 값 조합을 시각적으로 정리 | 조건과 결과를 **표 형식(테이블)**으로 나눠 논리 조합을 정리 |
| 🧩 구조 중심 | **조건(속성)**을 계층적으로 구분 | 조건 조합 → 결과 매핑에 중점 |
| 🎯 목적 | 가능한 모든 입력 조합 파악 (누락 없이) | 조건 조합별 정확한 결과 도출 검증 |
| 👁️ 시각화 | 트리 구조로 조합 도출이 쉬움 | 표로써 조건/결과 대응 관계가 명확 |
| 🛠️ 활용 상황 | 폼 입력, 설정값 조합, 조건 분기 많을 때 | 비즈니스 룰, 정책 로직, 할인 정책 등 |
| ✅ 예시 | 성별/연령/지역 분류 후 조합 확인 | 회원+카드 결제 → 10% 할인 |
🧩 페어와이즈 테스트
✅ 1. 개념 설명
🔹 페어와이즈 테스트란?
여러 입력 조건이 있을 때,
각 조건들 간의 모든 2개씩 쌍(pair) 조합을 테스트하는 기법이야.
전체 조합을 다 하지 않고도 높은 오류 검출 효과를 얻을 수 있어.
📌 “조건은 많지만, 전부 조합하면 너무 많다! → 그럼 2개씩만 다 해보자!” 라는 생각에서 출발한 테스트야.
🧠 2. 비유로 이해하기
🎲 비유: 주사위 실험
- 4개의 주사위를 던져서 나올 수 있는 모든 조합을 테스트하면
→ 6⁴ = 1296가지나 돼! (너무 많아 😱)
→ 대신, 주사위 2개씩만 조합해서 오류를 찾자!
모든 조건을 전부 조합하는 건 너무 많고 비효율적이야.
그 대신 조건 2개씩 조합해도 대부분의 오류는 잡힌다!
🧪 3. 실제 예시로 이해하기
예시: 스마트폰 설정 테스트
조건 4개:
| 통신사 | SKT / KT / LGU+ |
| 언어 | 한국어 / 영어 |
| OS | Android / iOS |
| 다크모드 | ON / OFF |
→ 전체 조합: 3 × 2 × 2 × 2 = 24가지
😵 모든 조합을 테스트하기엔 너무 많아!
▶ 페어와이즈 테스트 적용
- 각 조건 2개씩만 짝지어서 가능한 모든 조합을 커버하도록
- 일반적으로 6~8개의 테스트 케이스로 전체 조합의 핵심 쌍을 커버 가능
👉 테스트 수는 줄이고, 오류 탐지는 유지!
✅ 4. 왜 사용하는가?
- 조건이 많을수록 전체 조합은 기하급수적으로 증가
- 그런데 대부분의 오류는 2개 조건 사이 상호작용에서 발생함
- 그래서 효율적으로 오류를 발견할 수 있는 방법으로 쓰임
📌 5. 정리 포인트
| 목적 | 조건이 많을 때, 효율적으로 테스트 케이스 수를 줄이면서 오류를 잘 찾는 법 |
| 핵심 전략 | 모든 조건의 2개씩 쌍 조합을 커버 |
| 장점 | 전체 조합의 20~30% 테스트로 80% 이상의 오류 발견 가능 |
| 적합한 상황 | 설정, 옵션, 환경 변수 등 조건이 많고 전체 조합이 불가능할 때 |
🎯 페어와이즈가 효과적인 경우
- 기기 종류 + 언어 + 설정 등 테스트 매트릭스가 커지는 상황
- QA 자동화 시 테스트 케이스 수 줄여야 할 때
- 테스트 시간은 부족한데 커버는 많이 하고 싶을 때
💬 핵심 요약 한 줄
“조건이 많을 땐, 2개씩 쌍으로 다 테스트하자!”
= 페어와이즈 테스트
🧩 원인-결과 그래프 테스트
✅ 1. 개념 설명
🔹 원인-결과 그래프 테스트란?
입력 조건(=원인)과 출력 결과(=결과)의 관계를 논리 회로처럼 그래프로 표현한 뒤,
테스트 케이스를 도출하는 기법이야.
📌 여러 조건(원인)이 복잡하게 얽혀 있을 때,
이게 어떤 결과로 이어지는지를 논리적으로 명확하게 정리할 수 있어.
🧠 2. 비유로 이해하기
💡 비유: 전등 스위치
- 원인:
- A: 벽 스위치를 켰다
- B: 전기가 공급되고 있다
- 결과:
- 전등이 켜진다
→ A와 B가 모두 만족해야 전등이 켜지지?
이런 논리 관계를 AND 조건으로 묶어서 시각화하고,
그걸 기반으로 테스트하는 게 바로 원인-결과 그래프 테스트야!
🧪 3. 실제 예시로 이해하기
예시: 회원 할인 조건
조건 (원인):
- A: 회원이다
- B: 구매 금액이 10만원 이상이다
- C: 카드로 결제한다
결과:
- X: 10% 할인이 적용된다
▶ 논리 구조 예시
- "A AND (B OR C)"일 때 → X 발생
즉, 회원이면서
(구매 금액이 충분하거나, 카드 결제일 경우)
→ 할인됨
▶ 테스트 케이스 도출 예
| A (회원) | B (10만 이상) | C (카드 결제) | 결과 (할인) |
| Y | Y | N | Y |
| Y | N | Y | Y |
| Y | N | N | N |
| N | Y | Y | N |
→ 위처럼 조건과 결과 간 논리 관계를 기반으로 테스트 케이스를 만들 수 있어!
✅ 4. 왜 사용하는가?
- 조건이 많고 조합이 복잡할 때,
- 그 관계를 논리 회로처럼 시각화해서 누락 없이 테스트할 수 있음
- 특히 복잡한 비즈니스 로직, 정책 판단, 할인 조건 등에 유용
📌 5. 정리 포인트
| 목적 | 원인과 결과의 논리적 관계를 명확히 표현하고 테스트 |
| 구성 | 원인(입력 조건) → 논리 연산 → 결과(출력) |
| 장점 | 복잡한 조합을 체계적으로 시각화하고 케이스 도출 가능 |
| 적합한 상황 | 조건이 얽힌 로직, 할인 정책, 정책 룰 엔진 등 |
💬 핵심 요약 한 줄
“여러 조건이 모이면 어떤 결과가 나오는지, 논리적으로 정리하고 테스트하자!”
= 원인-결과 그래프 테스트
🧩 비교 테스트
✅ 1. 개념 설명
🔹 비교 테스트란?
**새로운 시스템(또는 기능)**과
기존 시스템/표준 시스템과의 결과를 비교하여
차이점이나 문제점을 파악하는 테스트 기법이야.
📌 목표는 단순히 "제대로 동작하는가?"가 아니라
"전에 비해 좋아졌나? 문제 생겼나?"를 비교하는 데 초점이 있어!
🧠 2. 비유로 이해하기
🍜 비유: 라면 신제품 비교 시식
- A 제품: 기존 라면
- B 제품: 신제품 라면
👉 A와 B를 나란히 시식해서 비교해보고,
“맛이 괜찮아졌는지, 더 짜졌는지, 전보다 나은지” 확인하는 것과 같아.
이런 식으로 기존 vs 신규를 동시에 비교해서 차이를 찾아내는 게 비교 테스트야!
🧪 3. 실제 예시로 이해하기
예시: 업데이트된 검색 기능 비교
시스템 A: 기존 검색 시스템
시스템 B: 업데이트된 새로운 검색 알고리즘
비교 대상 항목:
- 검색 속도
- 정확도
- 결과 수
- 필터 기능 동작 여부
👉 테스트 방법:
- 같은 검색어로 A와 B 시스템에 검색을 해보고,
- 출력 결과, 정렬 순서, 필터 작동 등을 비교함
📌 차이가 있다면: 개선된 것인지 / 오류인지 / 퇴화된 건지 확인 필요!
✅ 4. 왜 사용하는가?
- 새로운 기능을 만들거나 기존 기능을 수정했을 때
"전보다 좋아졌는지, 망가졌는지" 판단이 필요함 - 특히, 기존 시스템이 정답처럼 동작하는 레퍼런스일 경우 매우 효과적임
📌 5. 정리 포인트
| 목적 | 신구 시스템 간 결과 차이 확인 |
| 전략 | 동일한 입력을 기준으로 A vs B 결과 비교 |
| 장점 | 변경으로 인한 문제 발생 여부를 직접적으로 확인 가능 |
| 적합한 상황 | 시스템 리뉴얼, 버전 비교, 타사 제품 비교 등 |
🎯 비교 테스트가 효과적인 상황
- 웹사이트 개편 전후의 기능 차이 확인
- 새로운 알고리즘이나 정책 적용 후 테스트
- A/B 테스트처럼 두 버전의 성능 비교
- 경쟁사와의 기능 비교 (벤치마킹 테스트)
💬 핵심 요약 한 줄
“기존과 비교해서, 지금 제대로 작동하는가?”
= 비교 테스트
🧩 오류 추정 테스트
✅ 1. 개념 설명
🔹 오류 추정 테스트란?
과거 경험, 직관, 유사 사례를 기반으로
오류가 발생할 가능성이 높은 부분을 집중적으로 테스트하는 기법이야.
📌 “이런 부분에서 오류가 자주 났었어”
→ 개발자/테스터의 감(직관)과 경험을 활용해 예측하는 거야.
🧠 2. 비유로 이해하기
🔧 비유: 자주 고장 나는 전자제품 점검
예를 들어, 에어컨 점검을 한다고 할 때:
- 매년 고장 나는 부위는 “리모컨 배터리”나 “냉매 누수” 부위야.
👉 그러면 굳이 전체를 처음부터 뜯어보지 않고,
고장 확률이 높은 곳부터 점검하지?
이게 바로 오류 추정 테스트야!
🧪 3. 실제 예시로 이해하기
예시: 회원가입 폼 테스트
입력 필드:
- 이메일
- 비밀번호
- 나이
- 전화번호
👉 경험상 아래와 같은 오류가 자주 발생함:
- 이메일 @ 없이 입력 → 에러
- 비밀번호 6자 미만 → 에러
- 나이 음수 입력 → 에러
- 전화번호에 문자 포함 → 에러
전략:
→ 위 문제들이 자주 발생하는 걸 과거 경험으로 알고 있다면,
그 부분을 의도적으로 집중 테스트하는 것이 오류 추정 테스트야!
✅ 4. 왜 사용하는가?
- 모든 테스트 기법이 논리적으로 완벽히 커버할 수 없는 틈새 영역을 보완
- 경험 많은 테스터나 개발자가 주로 사용하는 "감각 기반" 테스트
- 시간이 부족하거나 자동화 어려운 상황에서 빠르게 오류를 찾아내는 데 효과적
📌 5. 정리 포인트
| 목적 | 오류가 자주 나는 부분을 집중 테스트 |
| 전략 | 경험·직관·과거 사례를 기반으로 테스트 케이스 설계 |
| 장점 | 빠르게 핵심 오류를 찾아낼 수 있음 |
| 단점 | 주관적이고, 경험 없는 사람은 수행 어려움 |
| 활용처 | 입력 검증, UI 테스트, 오류 다발 구역 등 |
💬 핵심 요약 한 줄
“예전에 자주 터졌던 부분부터 찔러보자!”
= 오류 추정 테스트
'자격증 > 정보처리기사' 카테고리의 다른 글
| [정보처리기사 실기 이론] 네트워크 신기술 용어 (1) | 2025.07.17 |
|---|---|
| [정보처리기사 실기 이론] 디자인 패턴 유형 | 행위패턴(Behavioral Patterns) 쉽게 이해하기 - 중재자/인터프리터/이터레이터/템플릿메소드/옵저버/상태/방문자/커맨드/전략/메멘토/책임연쇄 (10) | 2025.07.16 |
| [정보처리기사 실기 이론] 화이트박스 테스트 개념 및 유형 종류, 커버리지 개념 (3) | 2025.07.14 |
| [정보처리기사 실기 이론] 네트워크 공격 기법 - 스니핑/네트워크 스캐너/스니퍼/패스워드 크래킹/IP스푸핑/ARP스푸핑/ICMP 리다이렉트/트로이목마 (1) | 2025.07.13 |
| [정보처리기사 실기 이론] 세션 하이재킹(Session Hijacking) 개념 | 탐지 방법 (0) | 2025.07.11 |