테스트 케이스란? 작성 방법과 실제 예시 완전 가이드

테스트 케이스란 소프트웨어가 올바르게 동작하는지 확인하기 위한 「검증 절차서」입니다. 본 글에서는 테스트 케이스의 작성 방법·구성 요소·실무에서 활용할 수 있는 설계 노하우를 실제 예시와 함께 설명합니다. 「무엇을 써야 할지 모르겠다」「정상 케이스밖에 떠오르지 않는다」「사람마다 내용이 달라진다」는 고민을 갖고 계신 분께도 도움이 될 내용입니다.

「감으로 테스트하기」와 테스트 케이스에 기반한 설계 테스트는 버그 발견율과 팀 내 재현성 면에서 큰 차이가 납니다. 테스트 케이스 작성법을 익히는 것이 품질 보증의 출발점입니다.

테스트를 진행할 때 「어디서부터 시작해야 할지 모르겠다」 「테스트 내용이 사람마다 다르다」 「같은 버그를 반복해서 놓친다」는 문제는 많은 현장에서 발생합니다.

이러한 문제의 근본 원인 중 하나가 테스트 케이스 설계가 모호하다는 것입니다. 테스트 케이스를 올바르게 작성할 수 있게 되면 버그 누락이 줄고 팀 내 리뷰도 수월해집니다.

테스트 케이스란? 정의와 역할

테스트 케이스란 「특정 조건에서 소프트웨어의 동작을 검증하기 위한 절차와 예상 결과를 정의한 문서」입니다.

쉽게 말하면, 다음 네 가지 질문에 답하는 세트입니다.

테스트 케이스가 있으면 다음과 같은 효과를 기대할 수 있습니다.

• 누가 실행해도 동일한 내용을 테스트할 수 있다 (재현성)
• 무엇을 테스트했고 하지 않았는지 명확해진다 (추적성)
• 버그가 재발했을 때 어떤 테스트가 누락됐는지 파악하기 쉽다
• 새 팀원이 합류해도 즉시 테스트를 인수인계받을 수 있다

테스트 케이스의 구성 요소

테스트 케이스에 포함하는 항목은 프로젝트나 툴에 따라 다릅니다. 아래가 기본 구성입니다.

규모가 큰 프로젝트에서는 아래 항목이 추가되기도 합니다.

테스트 케이스 관리 툴 비교표

툴 선택은 팀 규모와 운용 방식에 따라 달라집니다.

테스트 케이스 작성 순서

아래 순서를 따르면 누락이나 중복을 방지하기 쉬워집니다.

단계 1 — 명세 확인

먼저 명세서·요구사항 정의서·수락 조건(AC)을 읽습니다. 「어떤 입력에 대해 무엇이 일어나야 하는가」의 조건을 정리하는 것이 출발점입니다. 명세가 모호한 부분은 테스트 케이스를 작성하기 전에 개발자나 PO에게 확인해 두면 재작업을 줄일 수 있습니다.

단계 2 — 테스트 관점 추출

명세에서 테스트할 패턴을 「정상·비정상·경계값」 3가지로 분류합니다(자세한 내용은 후술). 이 분류가 있으면 테스트 케이스의 누락을 발견하기 쉬워집니다.

단계 3 — 테스트 케이스 작성

분류한 패턴마다 「사전 조건·실행 단계·예상 결과」를 구체적으로 기술합니다. 이때 테스트 케이스 1개 = 확인 포인트 1개의 원칙을 지키는 것이 중요합니다. 여러 확인을 하나로 묶으면 어디서 실패했는지 특정하기 어려워집니다.

단계 4 — 리뷰

작성한 테스트 케이스는 자기 점검만이 아니라 다른 사람에게 리뷰받으면 누락을 발견하기 쉬워집니다. 「이 단계로 실제로 재현할 수 있는가」 「예상 결과는 구체적인가」 2가지를 중심으로 확인받아 보세요.

단계 5 — 실행·기록·업데이트

테스트 케이스는 만들고 끝이 아닙니다. 실행 결과(Pass/Fail)를 기록하고 명세 변경이 있으면 업데이트합니다. 오래된 테스트 케이스는 「테스트한 기분」만 줄 뿐, 실제로는 품질을 보증하지 못하는 경우가 있으므로 주의가 필요합니다.

테스트 케이스 작성법【좋은 예·나쁜 예】

같은 「로그인 기능 테스트」라도 작성 방법에 따라 품질이 크게 달라집니다.

❌ 나쁜 테스트 케이스 예시

문제점：

• 「로그인한다」라는 단계로는 무엇을 입력하는지 다른 사람이 재현할 수 없다
• 「로그인된다」로는 어느 화면으로 이동하면 합격인지 판단할 수 없다
• 사전 조건이 없으므로 테스트 사용자가 없는 환경에서는 실행할 수 없다

✅ 좋은 테스트 케이스 예시

개선 포인트：

• 테스트 명에 「정상」이라는 분류를 명기해 테스트 의도가 한눈에 보인다
• 사전 조건에 구체적인 사용자 정보를 기재해 누구든지 재현할 수 있다
• 실행 단계를 번호로 세분화해 어느 단계에서 실패했는지 특정하기 쉽다
• 예상 결과에 「이동 URL」과 「표시 텍스트」를 구체적으로 기술해 판정 기준이 명확하다

정상·비정상·경계값 분류

테스트 케이스를 작성할 때 3가지로 분류해 생각하면 커버리지가 높아집니다.

테스트 케이스 작성 시 자주 하는 실수

15년 이상의 현장 경험에서 반복해 목격한 실수 4가지를 소개합니다.

자동화 테스트(pytest)에 테스트 케이스 적용하기

이 챕터의 샘플 코드는 GitHub에서도 공개하고 있습니다：github.com/YOSHITSUGU728/automated-testing-portfolio

테스트 케이스에서 자동화 테스트까지의 흐름

테스트 케이스는 설계에서 끝나지 않고, pytest에 녹여냄으로써 자동화 테스트로 지속 활용할 수 있습니다.

pytest parametrize로 테스트 케이스 표를 코드화하기

작성한 테스트 케이스 목록은 pytest의 @pytest.mark.parametrize를 사용해 그대로 코드화할 수 있습니다. 여기서는 로그인 폼 입력 유효성 검사 함수를 예시로 테스트 케이스 표와 코드의 대응 관계를 보여드립니다.

import pytest

def validate_login_form(email: str, password: str) -> dict:
    """Validate login form input (format and length checks only).

    Note: This does NOT perform actual authentication.
    It is a utility function for checking input format.
    """
    if not email or not password:
        return {"success": False, "message": "Please enter your email and password"}
    if "@" not in email:
        return {"success": False, "message": "Invalid email format"}
    if len(password) < 8:
        return {"success": False, "message": "Password must be at least 8 characters"}
    return {"success": True, "message": "Input is valid"}

# 테스트 케이스 목록을 그대로 파라미터로 변환
@pytest.mark.parametrize("test_id, email, password, expected_success, expected_message", [
    # 정상 케이스 (유효한 입력 형식)
    ("TC-FORM-001", "test@example.com", "Password123", True,  "Input is valid"),
    # 비정상: 빈 입력
    ("TC-FORM-002", "",                "Password123", False, "Please enter your email and password"),
    ("TC-FORM-003", "test@example.com", "",            False, "Please enter your email and password"),
    # 비정상: 이메일 형식 오류
    ("TC-FORM-004", "invalid-email",   "Password123", False, "Invalid email format"),
    # 경계값: 비밀번호 길이 (조건: 8자 이상)
    ("TC-FORM-005", "test@example.com", "Pass123",    False, "Password must be at least 8 characters"),  # 7자 (하한-1)
    ("TC-FORM-006", "test@example.com", "Pass1234",   True,  "Input is valid"),                          # 8자 (하한 경계값)
])
def test_login_form_validation(test_id: str, email: str, password: str,
                               expected_success: bool, expected_message: str) -> None:
    result = validate_login_form(email, password)
    assert result["success"] == expected_success, f"[{test_id}] 'success' 값이 예상과 다릅니다"
    assert result["message"] == expected_message, f"[{test_id}] 'message' 값이 예상과 다릅니다"

FAQ

📋 정리

테스트 케이스의 품질은 그대로 테스트 전체의 품질로 이어집니다. 먼저 가까운 기능(로그인·폼 유효성 검사 등)으로 테스트 케이스를 한 번 작성해 보면 설계 감각이 몸에 배어 갑니다. 테스트 케이스가 있는 상태와 없는 상태에서는 팀의 리뷰 효율과 버그 발견율이 크게 달라지는 것을 실감할 수 있을 것입니다.