Что проверял исчерпывающим тестированием

Исчерпывающее тестирование: практика и примеры

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

1. Простые алгоритмы или функции с малым диапазоном входных значений

Это самый распространенный случай. Когда количество возможных входов ограничено и их можно перечислить вручную или автоматически.

Пример: функция преобразования оценок

# Функция, преобразующая числовую оценку (1-5) в буквенную (A-F)
def convert_grade(numeric_grade: int) -> str:
    if numeric_grade == 5:
        return "A"
    elif numeric_grade == 4:
        return "B"
    elif numeric_grade == 3:
        return "C"
    elif numeric_grade == 2:
        return "D"
    elif numeric_grade == 1:
        return "F"
    else:
        raise ValueError("Grade must be between 1 and 5")

Для такой функции исчерпывающее тестирование вполне реализуемо. Всего 6 значимых входных значений (1,2,3,4,5 и, например, 0 или 6 для проверки исключения).

# Пример исчерпывающего тест-кейса в pytest
import pytest

def test_convert_grade_exhaustive():
    # Все валидные входы и ожидаемые выходы
    valid_cases = [
        (5, "A"),
        (4, "B"),
        (3, "C"),
        (2, "D"),
        (1, "F")
    ]
    for input_val, expected_output in valid_cases:
        assert convert_grade(input_val) == expected_output
    
    # Проверка невалидных входов (граничные значения и исключения)
    invalid_cases = [0, 6, -1, 10]
    for invalid_val in invalid_cases:
        with pytest.raises(ValueError):
            convert_grade(invalid_val)

В данном случае мы проверили все возможные значимые входы для этой небольшой, но важной функции (ошибка в конвертации оценки может иметь серьёзные последствия).

2. Критически важные бизнес-правила с дискретным набором условий

В финансовых или регулятивных системах некоторые правила должны быть проверены на всех предусмотренных комбинациях.

Пример: правило расчета комиссии при переводе

• Тип клиента: "Новый", "Регулярный", "VIP".
• Сумма перевода: < 1000$, >= 1000$.
• Время операции: "Рабочие часы", "Нерабочие часы".

Теоретически это дает 3 * 2 * 2 = 12 комбинаций. Если это ключевое правило, влияющее на доход компании и соблюдение законодательства, мы могли написать 12 точных тестов, покрывающих каждую комбинацию, чтобы гарантировать отсутствие ошибок.

3. Конфигурационные матрицы для интеграционного тестирования

При тестировании интеграции между системами с небольшим набором конфигурационных параметров.

Пример: проверка поддержки форматов файлов в импорте данных Система принимает файлы. Параметры:

• Формат: .csv, .json, .xml.
• Кодировка: UTF-8, Windows-1251.
• Размер файла: "Малый (<1MB)", "Средний (1-10MB)", "Большой (>10MB)" (для проверки обработки).

Мы могли создать матрицу 3 * 2 * 3 = 18 конкретных тестовых файлов и проверить обработку каждого из них. Это исчерпывающая проверка для данного конфигурационного пространства.

4. Тестирование всех возможных состояний простого конечного автомата (State Machine)

Для компонентов с четко определенным и ограниченным количеством состояний и переходов.

Пример: лифт (упрощенная модель)

• Состояния: "Ожидание", "Движение вверх", "Движение вниз", "Открытие дверей", "Закрытие дверей".
• Команды: "Вызов наверх", "Вызов вниз", "Открыть", "Закрыть".

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

5. Проверка всех элементов в небольшом статическом справочнике или наборе данных

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

Пример: проверка валидации кодов стран по справочнику ISO Справочник содержит 250 кодов. Если модуль должен принимать код и возвращать название страны, мы могли написать тест, который итерируется по всему официальному списку и проверяет, что для каждого кода XX функция get_country_name("XX") возвращает корректное название, а для несуществующего кода "ZZ" — выбрасывает исключение.

Почему исчерпывающее тестирование обычно невозможно?

• Экспоненциальный рост: Для поля ввода String длиной до 10 символов уже существует астрономическое количество комбинаций.
• Взаимодействие параметров: Несколько полей с множеством возможных значений создают неподъемное количество комбинаций.
• Временные и ресурсные ограничения.

Практический вывод

В своей работе я применял подходы, максимально приближенные к исчерпывающему тестированию, только для:

1. Критически важных компонентов (финансы, безопасность, жизненно важные бизнес-правила).
2. Очень ограниченных входных пространств (как в примерах выше).
3. Где стоимость ошибки чрезвычайно высока, и полная проверка оправдывает затраты.

В остальных случаях мы использовали стратегии выбора тестовых случаев:

• Эквивалентное разбиение (тестирование по классам).
• Анализ граничных значений.
• Таблицы принятия решений (для бизнес-логики).
• Покрытие комбинаций (Pairwise) вместо полного перебора.

Исчерпывающее тестирование — это скорее философский ориентир ("мы должны проверить всё"), который на практике трансформируется в принцип максимально полного покрытия для критически важных и ограниченных по сложности областей.