유스케이스 테스트란？기본·대체·예외 플로우의 설계 방법＋Playwright 구현

유스케이스 테스트란 사용자가 목적을 달성하기까지의 일련의 조작 플로우（유스케이스）를 테스트 시나리오로 변환하는 테스트 설계 기법입니다. E2E 테스트의 시나리오 설계·리그레션 테스트의 우선순위 결정에 특히 효과를 발휘합니다.

유스케이스 테스트를 사용하면 「사용자가 실제로 수행하는 조작」을 그대로 테스트 시나리오로 변환할 수 있어 「동작은 하지만 사용할 수 없다」는 사용자 관점의 버그를 근본적으로 발견할 수 있습니다.

「단위 테스트는 모두 통과하고 있는데 실제로 사용해보면 동작하지 않는다」「정상계만 테스트하고 있어서 사용자가 할 것 같은 조작의 버그가 본번에서 발생했다」——이런 문제는 사용자 관점의 테스트 설계가 부족하기 때문입니다.

• 단위 테스트나 기능 테스트만으로는 「사용자의 조작 플로우 전체」를 검증할 수 없다
• 정상계（기본 플로우）만 테스트하여 대체 플로우·예외 플로우가 누락된다
• 테스트 시나리오가 엔지니어의 시점으로 작성되어 실제 사용자 조작과 괴리가 있다

유스케이스 테스트는 이런 문제를 해결하는 기법입니다. 이 글에서는 개념부터 구체적인 시나리오 설계·Playwright E2E 테스트로의 응용까지 한 번에 해설합니다.

유스케이스 테스트란？

유스케이스 테스트란 「사용자가 시스템을 사용하여 목적을 달성하기까지의 일련의 조작 플로우（유스케이스）」를 테스트 시나리오로 변환하는 테스트 설계 기법입니다.

예를 들어 「상품을 구매한다」는 유스케이스라면 로그인→상품 선택→카트 추가→결제 정보 입력→주문 확정→완료 확인이라는 일련의 플로우를 그대로 테스트 시나리오로 만듭니다. 사용자의 시점에서 시스템을 검증하기 때문에 단위 테스트로는 발견할 수 없는 「플로우 전체에서 처음 나타나는 버그」를 찾아낼 수 있습니다.

상태 전이 테스트와의 차이란？

같은 「플로우를 테스트하는」 기법이어도 유스케이스 테스트와 상태 전이 테스트는 시점과 목적이 다릅니다. 실무에서는 혼동되기 쉽기 때문에 정리해 둡니다.

유스케이스 테스트와 E2E 테스트의 차이란？

자주 혼동되는 두 가지 개념이지만 역할이 완전히 다릅니다.

유스케이스 테스트의 기본 구조란？

유스케이스 테스트는 「기본 플로우」「대체 플로우」「예외 플로우」의 3가지로 구성됩니다.

실례①：상품 구매 유스케이스의 테스트 설계

EC 사이트의 「상품을 구매한다」 유스케이스를 기본 플로우·대체 플로우·예외 플로우로 나누어 테스트 시나리오를 설계합니다.

기본 플로우（정상계）

대체 플로우（정상이지만 다른 경로）

예외 플로우（에러·이상）

실례②：회원 가입 유스케이스의 테스트 설계

또 다른 대표적인 유스케이스 「회원 가입을 한다」의 테스트 설계입니다.

Playwright × pytest에의 응용

유스케이스 테스트로 설계한 시나리오는 Playwright × pytest의 E2E 테스트에 직접 변환할 수 있습니다. 1유스케이스＝1테스트 파일의 구성이 실무의 베스트 프랙티스입니다.

폴더 구성 예시

tests/
├── conftest.py
└── e2e/
    ├── test_purchase.py        # 유스케이스：상품을 구매한다
    ├── test_register.py        # 유스케이스：회원 가입을 한다
    └── test_login.py           # 유스케이스：로그인한다

test_purchase.py：상품 구매 유스케이스의 E2E 테스트

import pytest
from playwright.sync_api import Page, expect

# ── 기본 플로우 ──────────────────────────────────
def test_purchase_basic_flow(logged_in_page: Page):
    """기본 플로우：로그인 완료 사용자가 상품을 구매한다"""
    # Step 2: 상품 선택
    logged_in_page.goto("localhost:3000/products/1")
    expect(logged_in_page.locator("h1.product-title")).to_be_visible()

    # Step 3: 카트에 추가
    logged_in_page.click("#add-to-cart")
    expect(logged_in_page.locator(".cart-badge")).to_have_text("1")

    # Step 4: 구매 절차로
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.click("#checkout-btn")

    # Step 5: 주문 확정
    logged_in_page.fill("#card-number", "4111111111111111")
    logged_in_page.fill("#expiry", "12/26")
    logged_in_page.fill("#cvv", "123")
    logged_in_page.click("#confirm-order-btn")
    expect(logged_in_page.locator(".order-complete")).to_be_visible()

# ── 대체 플로우 ──────────────────────────────────
def test_purchase_with_coupon(logged_in_page: Page):
    """대체 플로우：쿠폰 적용하여 구매한다"""
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.fill("#coupon-input", "DISCOUNT10")
    logged_in_page.click("#apply-coupon-btn")
    # 쿠폰 적용 후 금액이 올바른지 확인
    expect(logged_in_page.locator(".discount-amount")).to_be_visible()

# ── 예외 플로우 ──────────────────────────────────
def test_purchase_payment_failure(logged_in_page: Page):
    """예외 플로우：결제 실패 시 에러 메시지가 표시되고 카트가 유지된다"""
    logged_in_page.goto("localhost:3000/cart")
    logged_in_page.click("#checkout-btn")
    # 무효한 카드 번호로 결제
    logged_in_page.fill("#card-number", "0000000000000000")
    logged_in_page.click("#confirm-order-btn")
    # 에러 메시지가 표시되는가
    expect(logged_in_page.locator(".payment-error")).to_be_visible()
    # 카트 내용이 유지되는가
    expect(logged_in_page.locator(".cart-badge")).to_have_text("1")

⚠️ 유스케이스 테스트에서 자주 있는 실패 패턴 4선

실무에서 유스케이스 테스트를 설계할 때 빠지기 쉬운 실패를 소개합니다.

FAQ

📋 이 글의 정리

유스케이스 테스트의 최대 가치는 「사용자가 실제로 수행하는 조작」을 기점으로 함으로써 단위 테스트로는 발견할 수 없는 「플로우를 넘나드는 버그」를 체계적으로 발견할 수 있는 점입니다. 먼저 가까운 서비스의 「상품을 구매한다」「회원 가입을 한다」는 유스케이스에서 기본 플로우·대체 플로우·예외 플로우를 써내는 것부터 시작해 보세요.