Что такое тест-кейс и из каких частей он состоит?

Что такое тест-кейс и из каких частей он состоит?

Тест-кейс (Test Case) — это формализованная документация, описывающая набор конкретных шагов, условий (прекондиций) и данных, необходимых для проверки определённого аспекта функциональности или характеристики программного продукта. Основная цель тест-кейса — детализировать один конкретный способ проверки соответствия системы её требованиям. Это фундаментальная единица тестирования, которая служит как инструкцией для тестировщика, так и доказательством выполненной проверки и её результата.

Тест-кейс не следует путать с более широкими понятиями, такими как тестPlан или чек-лист. Он является атомарной, воспроизводимой и документируемой процедурой. В контексте автоматизации тестирования тест-кейс часто напрямую соотносится с методом (функцией) в тестовом скрипте, содержащим логику проверки (assertions).

Основные компоненты (части) тест-кейса

Стандартная структура тест-кейса может варьироваться в зависимости от процесса компании и инструментов (JIRA, TestRail, Zephyr), но её ключевые элементы остаются универсальными. Обычно она включает следующие части:

1. Идентификационные и классифицирующие данные

• ID / Уникальный идентификатор: Уникальный номер или код для ссылок и управления (например, TC_APP_LOGIN_001).
• Название (Title/Summary): Краткое, информативное описание цели теста (например, "Проверка успешного логина с валидными credentials").
• Приоритет (Priority): Показывает важность теста относительно других (High/Medium/Low), что помогает планировать выполнение.
• Связанные требования (Requirement ID): Ссылка на спецификацию или user story, которую проверяет данный кейс (например, ссылка на REQ_FUNC_AUTH-01).

2. Контекст и условия выполнения

• Модуль / Компонент (Module/Component): Определяет часть системы, которую тестируют (например, "Authentication Service").
• Прекондиции (Preconditions): Описывают состояние системы или необходимые действия до начала теста. Например:

  # Пример прекондиций в формате Gherkin
  Given пользователь не авторизован в системе
  And учетная запись пользователя "test_user" существует и активна
  And сервис авторизации доступен (status 200)
  

• Тестовые данные (Test Data): Конкретные входные значения, используемые в тесте. Например, для теста логина:

  {
    "username": "valid_user@example.com",
    "password": "CorrectPass123!"
  }
  

3. Процедура выполнения (шаги)

• Шаги теста (Test Steps): Последовательность четких, воспроизводимых действий, которые выполняет тестировщик или автоматический скрипт. Каждый шаг должен быть атомарным и содержать ожидаемый результат на этом шаге.

  ### Шаги для теста логина:
  1. Открыть главную страницу приложения (https://app.example.com).
  2. Нажать на кнопку "Sign In" в хедере.
  3. В поле "Email" ввести значение `valid_user@example.com`.
  4. В поле "Password" ввести значение `CorrectPass123!`.
  5. Нажать кнопку "Login".
  

• Ожидаемый результат (Expected Result): Описание того, как система должна реагировать после выполнения всех шагов. Это критерий успеха/неуспеха теста. Например:

    > Пользователь перенаправляется на страницу своего профиля (`/profile`). В верхнем правом углу отображается его имя (`"Welcome, valid_user"`). Сессия пользователя активна.

4. Результаты выполнения и пост-кондиции

• Фактический результат (Actual Result): Заполняется после выполнения теста. Описывает реальное поведение системы.
• Статус (Status): Итог сравнения ожидаемого и фактического результата. Стандартные значения: Passed, Failed, Blocked, Not Executed.
• Посткондиции (Postconditions):** Описывают состояние системы после теста, особенно если оно отличается от исходного. Например: "Пользователь авторизован. Требуется очистка сессии для следующих тестов."
• Комментарии / Примечания (Comments/Notes): Поле для дополнительной информации: ошибок, скриншотов, ссылок на баг-репорт, особенностей окружения.

Пример структурированного тест-кейса в табличном представлении

В автоматизированном тестировании эта структура напрямую воплощается в код. Например, вышеописанный тест-кейс в виде скрипта на Python с использованием pytest может выглядеть так:

import pytest
from selenium.webdriver.common.by import By

class TestLogin:
    
    @pytest.mark.high
    @pytest.mark.auth
    def test_successful_login_with_valid_credentials(self, driver):
        """TC_AUTH_LOGIN_01: Успешный логин с валидными email и паролем."""
        # Прекондиции и тестовые данные
        TEST_EMAIL = "test@domain.com"
        TEST_PASSWORD = "Qwerty123"
        LOGIN_URL = "https://app.example.com/login"
        DASHBOARD_URL = "https://app.example.com/dashboard"

        # Шаги теста (Test Steps)
        driver.get(LOGIN_URL)
        driver.find_element(By.ID, "email").send_keys(TEST_EMAIL)
        driver.find_element(By.ID, "password").send_keys(TEST_PASSWORD)
        driver.find_element(By.XPATH, "//button[text()='Login']").click()

        # Проверка ожидаемого результата (Expected Result Assertion)
        assert driver.current_url == DASHBOARD_URL
        welcome_message = driver.find_element(By.CSS_SELECTOR, ".welcome-msg").text
        assert welcome_message == f"Welcome, {TEST_EMAIL.split('@')[0]}"

        # Пост-кондиции могут быть реализованы в teardown
        # (например, логика logout после всех тестов класса)

Таким образом, хорошо составленный тест-кейс — это не просто список действий, а полноценный, самодостаточный артефакт, который обеспечивает воспроизводимость, ясность цели и точную оценку качества проверяемого функционала.