블랙박스 테스트(Black-box Testing)의 핵심은 내부 코드를 보지 않고, 입력(Input)과 출력(Output) 만을 가지고 검증하는 것입니다.
이때 기준이 되는 것은 바로 개발 전에 작성된 요구사항 명세서(SRS), 화면 설계서(Wireframe/SB), 플로우 차트, 그리고 디자인 가이드(Zeplin/Figma) 입니다.
이 문서들을 기반으로 '명세 기반 기법(동등 분할, 경계값 분석, 상태 전이 등)'을 적용하여 각 도메인별로 어떻게 디테일한 테스트 케이스를 뽑아내는지 구체적으로 알아보겠습니다.
1. 전자상거래 (E-Commerce) - Web/App
- 참고 문서: 할인 쿠폰 정책서, 주문 결제 플로우 차트, 제플린(UI 디자인)
- 테스트 기법: 경계값 분석(Boundary Value Analysis), 결정 테이블(Decision Table)
[시나리오] 장바구니 쿠폰 적용 및 최종 결제 금액 검증
요구사항: "3만원 이상 구매 시 10% 할인 쿠폰 적용 (최대 5천원 할인)"
| TC ID | 테스트 케이스 설명 | 사전 조건 | 테스트 단계 (Steps) | 입력 데이터 | 예상 결과 (Expected Result) | 비고 |
| EC-01 | 최소 주문 금액 미달 시 쿠폰 적용 불가 확인 (경계값) | 로그인, 쿠폰 보유 | 1. 장바구니에 상품 담기 2. 결제 화면 진입 3. 쿠폰 적용 시도 |
상품 합계: 29,900원 | 쿠폰 선택 리스트가 비활성화되거나 '적용 불가' 메시지 출력 | 정책서 기준 |
| EC-02 | 최소 주문 금액 충족 시 할인 적용 확인 (경계값) | 로그인, 쿠폰 보유 | 1. 장바구니 상품 담기 2. 쿠폰 적용 |
상품 합계: 30,000원 | 총 결제 금액: 27,000원 (3천원 할인) 표시 | 정책서 기준 |
| EC-03 | 최대 할인 한도 적용 로직 검증 | 로그인, 쿠폰 보유 | 1. 고가 상품 담기 2. 쿠폰 적용 |
상품 합계: 100,000원 | 총 결제 금액: 95,000원 (10%인 1만원이 아닌, 최대 한도 5천원만 할인) | 정책서 기준 |
| EC-04 | 결제 버튼 UI 디자인 일치 여부 | 상품 담기 완료 | 1. 결제 수단 선택 영역 확인< 2. '결제하기' 버튼 스타일 확인 |
- | Zeplin 가이드와 버튼 색상(#FF5722), 폰트 사이즈(16px), 마진 값이 일치해야 함 | UI 명세 |
2. 금융 (Finance) - 뱅킹 앱
- 참고 문서: 이체 한도 규정집, 송금 프로세스 플로우 차트
- 테스트 기법: 동등 분할(Equivalence Partitioning), 오류 추정(Error Guessing)
[시나리오] 타행 이체 시 수수료 및 한도 체크
요구사항: "1회 이체 한도 1,000만원, 타행 이체 시 수수료 500원 (VIP 등급 면제)"
| TC ID | 테스트 케이스 설명 | 사전 조건 | 테스트 단계 (Steps) | 입력 데이터 | 예상 결과 (Expected Result) | 비고 |
| FN-01 | 일반 등급 사용자 타행 이체 (정상) | 일반 등급, 잔액 충분 | 1. 타행 계좌번호 입력 2. 이체 금액 입력 3. 이체 실행 |
이체액: 100만원 | 계좌에서 1,000,500원 차감 (이체액+수수료), 이체 성공 화면 노출 | 수수료 정책 |
| FN-02 | 1회 이체 한도 초과 시도 (경계값 +1) | 잔액 2억 보유 | 1. 타행 계좌번호 입력 2. 한도 초과 금액 입력 |
이체액: 10,000,001원 | "1회 이체 한도를 초과하였습니다" 팝업 노출 및 이체 불가 | 한도 정책 |
| FN-03 | 잔액 부족 시 처리 (수수료 포함 계산) | 잔액: 10,000원 | 1. 타행 이체 시도 | 이체액: 10,000원 | "잔액이 부족합니다(수수료 포함)" 메시지 노출 (수수료 500원 때문에 실패해야 함) | 예외 처리 |
| FN-04 | 입금 계좌번호 유효성 검사 | - | 1. 계좌번호 입력란에 특수문자 입력 | 입력: 123-456@# | 숫자와 하이픈(-) 외 입력 불가하거나, 유효하지 않은 계좌 알림 | 입력값 검증 |
3. 자동차/임베디드 (Automotive) - 클러스터(계기판) S/W
- 참고 문서: 상태 천이도(State Diagram), CAN 통신 명세서, HMI 설계서
- 테스트 기법: 상태 전이 테스트(State Transition Testing)
[시나리오] 주행 모드 변경에 따른 계기판 디스플레이 변경
요구사항: "Eco 모드에서는 배경이 초록색, Sport 모드에서는 빨간색으로 변경되며 RPM 게이지가 강조됨"
| TC ID | 테스트 케이스 설명 | 사전 조건 | 테스트 단계 (Steps) | 입력 데이터 | 예상 결과 (Expected Result) | 비고 |
| AUTO-01 | Normal → Eco 모드 전환 | 시동 ON, P단 | 1. 드라이브 모드 다이얼을 'Eco'로 변경 | Input Signal: Mode_Eco (CAN ID: 0x123 Data: 01) | 클러스터 테마가 Green 컬러로 변경, 연비 게이지 활성화 | HMI 설계서 |
| AUTO-02 | Eco → Sport 모드 전환 (주행 중) | 주행 중(40km/h) | 1. 드라이브 모드 버튼을 'Sport'로 변경 | Input Signal: Mode_Sport | 클러스터 테마 Red 변경, RPM 게이지 확대, 속도계 폰트 이탤릭체 적용 | HMI 설계서 |
| AUTO-03 | 후진 기어 입력 시 모드 변경 불가 확인 | 시동 ON, R단 | 1. 기어를 R(후진)로 변경 2. 드라이브 모드 변경 시도 |
Gear: Reverse<br>Input: Mode_Sport | 후방 카메라 화면이 최우선 출력, 드라이브 모드 변경 UI 무시 또는 "변경 불가" 토스트 팝업 | 안전 사양 |
4. IoT/AI (Smart Home)
- 참고 문서: 음성 명령어 리스트(Voice Command Spec), 예외 상황 시나리오
- 테스트 기법: 페어와이즈(Pairwise), 랜덤 테스트
[시나리오] AI 스피커를 통한 스마트 전구 제어
요구사항: "명령어 인식 후 1초 이내 동작, 밝기는 0~100 단계 조절 가능"
| TC ID | 테스트 케이스 설명 | 사전 조건 | 테스트 단계 (Steps) | 입력 데이터 | 예상 결과 (Expected Result) | 비고 |
| AI-01 | 복합 명령 처리 (전원 + 밝기) | 전구 OFF | 1. 음성 명령 입력 | 발화: "거실 불 켜고 밝기 50으로 해줘" | 전구가 켜짐과 동시에 밝기가 50%로 설정됨 (순차적 수행 확인) | 기능 명세 |
| AI-02 | 비정상 범위 값 입력 (음성) | 전구 ON | 1. 허용 범위 밖의 밝기 명령 | 발화: "밝기 200으로 해줘" | "최대 밝기는 100입니다"라고 안내 후 100으로 설정하거나 명령 취소 (명세서 정의에 따름) | 예외 처리 |
| AI-03 | 네트워크 불안정 시나리오 | Wi-Fi 신호 약함 | 1. 공유기 전원 차단 직후 명령 | 발화: "불 꺼" | 디바이스 LED가 빨간색(연결 끊김) 점멸하며 "네트워크 연결을 확인해주세요" 음성 송출 | 상태 명세 |
5. 공공/통신 (Public/Telecom)
- 참고 문서: 입력 폼 명세서(Form Spec), 과금 정책표
- 테스트 기법: 유효성 검사(Validation Check)
[시나리오] 온라인 여권 재발급 신청 폼 검증
요구사항: "영문 이름은 대문자 자동 변환, 사진은 JPG만 가능(5MB 이하)"
| TC ID | 테스트 케이스 설명 | 사전 조건 | 테스트 단계 (Steps) | 입력 데이터 | 예상 결과 (Expected Result) | 비고 |
| PUB-01 | 영문 성명 소문자 입력 시 자동 변환 | 로그인 완료 | 1. 영문 성 입력란에 소문자 입력 2. 커서를 다른 곳으로 이동(Focus out) |
입력: hong | 입력 필드 값이 HONG으로 자동 변경되어야 함 | UI/UX 정의 |
| PUB-02 | 첨부 파일 확장자 제한 검증 | - | 1. 사진 업로드 버튼 클릭 2. PNG 파일 선택 |
파일: face.png | "JPG 파일만 업로드 가능합니다" 얼럿 노출 및 업로드 차단 | 명세 준수 |
| PUB-03 | 필수 약관 미동의 시 진행 불가 | 폼 작성 완료 | 1. 필수 약관 체크 해제 2. '신청하기' 버튼 클릭 |
- | 버튼이 비활성화되어 있거나, 클릭 시 해당 약관 위치로 스크롤 이동하며 경고 문구 표시 | 플로우 차트 |
블랙박스 테스트 케이스 작성 팁
- 추적성(Traceability) 확보: TC ID 옆에 관련 요구사항 ID(예: SRS-101)를 매핑하여, 명세서의 어떤 기능이 테스트되었는지 증명해야 합니다.
- 구체적인 데이터 명시: "적절한 값 입력"이라고 쓰지 마세요. "금액란에 50,000 입력"처럼 구체적인 값을 명시해야 누가 테스트해도 같은 결과가 나옵니다.
- UI/UX 명세 반영: 기능이 동작하더라도 제플린(Zeplin)상의 여백(Margin), 폰트, 색상이 다르면 버그입니다. 명세 기반 테스트에는 디자인 검증도 포함됩니다.
블랙박스테스트,명세기반테스트,QA,테스트케이스작성법,요구사항명세서,제플린,기능명세서,소프트웨어테스팅,테스트시나리오,결함관리
'테스트 관련 강좌' 카테고리의 다른 글
| [실무 가이드] 금융부터 자율주행까지, 도메인별 완벽한 소프트웨어 테스트 시나리오 및 케이스 작성법 (1) | 2025.12.11 |
|---|---|
| [IT 용어 풀이] 사인 오프(Sign-off)와 컷오버(Cutover)의 결정적 차이: 이사 가는 날에 비유하기 (0) | 2025.11.27 |
| 2025년 SW 테스트 아웃소싱(STO) 업체 완벽 가이드: 연봉부터 주요 고객사까지 전격 비교해보니.. (2) | 2025.11.18 |
| 소프트웨어 테스트의 핵심, 블라인드 테스트와 그레이 테스트 완벽 정복 (0) | 2025.11.17 |
| CSTS 일반등급 자격증, 이 글 하나로 완벽 정복! (테스트 개요부터 자동화, 실무 팁까지 총정리) (0) | 2025.09.10 |
