Как сверишь ожидаемый и фактический результат

Сверка ожидаемого и фактического результата в тестировании

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

Основные подходы к сверке

1. Автоматизированная проверка через assertion (утверждения) В автоматизированных тестах сверка выполняется программно с помощью утверждений. Это позволяет быстро и точно сравнить большое количество данных.

# Пример на Python с использованием pytest
def test_calculate_total_price():
    # Ожидаемый результат
    expected_total = 150.75
    
    # Фактический результат (вызов тестируемой функции)
    actual_total = calculate_price(quantity=3, price=50.25)
    
    # Сверка через assertion
    assert actual_total == expected_total, \
        f"Ожидалось {expected_total}, но получено {actual_total}"

2. Визуальная сверка в UI-тестировании Для графических интерфейсов добавляю сравнение скриншотов или проверку конкретных элементов:

// Пример на Playwright
await test('Check login page', async ({ page }) => {
  await page.goto('/login');
  
  // Проверка наличия элементов
  await expect(page.locator('#username')).toBeVisible();
  await expect(page.locator('#password')).toBeVisible();
  
  // Проверка текста
  await expect(page.locator('.welcome-text'))
    .toHaveText('Добро пожаловать в систему');
});

3. Сравнение данных в API-тестировании При тестировании API сравниваю структуру и содержимое JSON-ответов:

// Пример на Java с REST Assured
@Test
public void testUserApiResponse() {
    given()
        .when()
        .get("/api/users/1")
        .then()
        .statusCode(200) // Проверка HTTP статуса
        .body("id", equalTo(1))
        .body("name", equalTo("Иван Иванов"))
        .body("email", containsString("@example.com"));
}

Методология сравнения

Детальный процесс сверки включает:

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

2. Определение критериев сравнения:

   • Точное соответствие (для числовых значений, кодов)
   • Частичное соответствие (для текстов с переменными данными)
   • Структурное соответствие (для JSON/XML)
   • Визуальное соответствие (для UI)

3. Учет контекста сравнения:

   • Динамические данные (даты, ID, временные метки)
   • Округление числовых значений
   • Регистр символов в строках
   • Пробелы и форматирование

4. Обработку несоответствий:

   • Логирование различий с детализацией
   • Определение серьезности расхождения
   • Документирование дефектов с четким указанием expected/actual

Инструменты и техники

Для разных типов проверок использую:

• Текстовое сравнение: diff-инструменты, регулярные выражения
• Сравнение структур данных: специализированные библиотеки (например, deep-diff для JavaScript)
• Визуальное тестирование: Applitools, Percy
• Сравнение баз данных: проверка запросов, сравнение дампов

Особые случаи

Недитерминированные тесты (с случайными данными, зависимостью от времени):

# Использование диапазонов или паттернов вместо точных значений
def test_transaction_timestamp():
    actual_time = get_transaction_time()
    
    # Проверяем, что время в разумных пределах
    assert datetime.now() - timedelta(minutes=5) <= actual_time <= datetime.now()

Сравнение сложных структур:

// Глубокое сравнение объектов
const expected = { user: { id: 1, profile: { name: 'Test' } } };
const actual = getUserData();

// Использование специализированной библиотеки
const differences = DeepDiff.diff(expected, actual);
assert(Object.keys(differences).length === 0, 'Объекты отличаются');

Лучшие практики

• Четкая документация ожидаемых результатов в тест-кейсах
• Использование констант и фабрик данных для эталонных значений
• Многоуровневая проверка (статус код + заголовки + тело ответа)
• Визуализация различий при отчете о дефектах
• Регулярный рефакторинг проверок для поддержания читаемости

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