테스트 관련 강좌

[실무 심화] 명세서와 제플린을 씹어먹는 도메인별 블랙박스 테스트 설계 전략 (명세 기반)

프리스케이터 2025. 12. 12. 10:33

블랙박스 테스트(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. '신청하기' 버튼 클릭		 - 버튼이 비활성화되어 있거나, 클릭 시 해당 약관 위치로 스크롤 이동하며 경고 문구 표시 플로우 차트

블랙박스 테스트 케이스 작성 팁

  1. 추적성(Traceability) 확보: TC ID 옆에 관련 요구사항 ID(예: SRS-101)를 매핑하여, 명세서의 어떤 기능이 테스트되었는지 증명해야 합니다.
  2. 구체적인 데이터 명시: "적절한 값 입력"이라고 쓰지 마세요. "금액란에 50,000 입력"처럼 구체적인 값을 명시해야 누가 테스트해도 같은 결과가 나옵니다.
  3. UI/UX 명세 반영: 기능이 동작하더라도 제플린(Zeplin)상의 여백(Margin), 폰트, 색상이 다르면 버그입니다. 명세 기반 테스트에는 디자인 검증도 포함됩니다.

 

블랙박스테스트,명세기반테스트,QA,테스트케이스작성법,요구사항명세서,제플린,기능명세서,소프트웨어테스팅,테스트시나리오,결함관리

저작자표시 (새창열림)