Как бы протестировал парадокс Монти Холла?

Тестирование парадокса Монти Холла: подход QA Automation Engineer

Парадокс Монти Холла — это вероятностная задача, основанная на игровом шоу, где участник выбирает одну из трех дверей (с авто за одной и ничего за двумя другими). После выбора ведущий открывает одну из оставшихся пустых дверей и предлагает изменить выбор. Парадокс утверждает, что изменение выбора увеличивает вероятность победы с 1/3 до 2/3. Как QA Automation Engineer, я бы протестировал это утверждение, используя методологию автоматизированного тестирования, симуляции и анализа данных.

Стратегия тестирования

1. Анализ требований и формализация логики:

    *   **Исходное состояние**: 3 двери (`Door1`, `Door2`, `Door3`), один автомобиль, два "пустяка".
    *   **Действие 1**: Пользователь делает первоначальный выбор (фиксируется).
    *   **Действие 2**: Ведущий открывает одну из НЕвыбранных дверей, которая гарантированно пуста.
    *   **Действие 3**: Пользователь принимает решение — остаться на первоначальном выборе или переключиться на другую закрытую дверь.
    *   **Ожидаемый результат**: Вероятность победы при стратегии "переключиться" должна быть ~66.7%, при стратегии "остаться" ~33.3%.

1. Разработка автоматизированной симуляции (тестового сценария):

    Я бы создал скрипт, который многократно исполняет логику игры, собирая статистику. Ключевые компоненты:

    *   **Генератор случайных размещений**: Автомобиль случайно размещается за одной из трех дверей каждый раунд.
    *   **Моделирование выбора пользователя**: Первый выбор также случайный.
    *   **Логика ведущего**: Алгоритм, который определяет, какую пустую дверь открыть после первого выбора.
    *   **Сбор статистики по двум стратегиям**: "Остаться" и "Переключиться".

import random
from collections import Counter

def simulate_monty_hall(num_trials=10000):
    stay_wins = 0
    switch_wins = 0
    
    for _ in range(num_trials):
        # Размещаем авто случайно
        doors = ['goat', 'goat', 'car']
        random.shuffle(doors)
        
        # Первый выбор игрока (индекс 0, 1, 2)
        first_choice = random.randint(0, 2)
        
        # Логика ведущего: открыть одну из НЕвыбранных пустых дверей
        possible_host_opens = [i for i in range(3) if i != first_choice and doors[i] == 'goat']
        host_open = random.choice(possible_host_opens)
        
        # Определяем дверь для стратегии "переключиться"
        # Это единственная закрытая дверь, не выбранная сначала и не открытая ведущим
        switch_option = [i for i in range(3) if i != first_choice and i != host_open][0]
        
        # Проверяем победу для стратегии "остаться"
        if doors[first_choice] == 'car':
            stay_wins += 1
        
        # Проверяем победу для стратегии "переключиться"
        if doors[switch_option] == 'car':
            switch_wins += 1
    
    print(f"Total trials: {num_trials}")
    print(f"Stay strategy wins: {stay_wins} ({stay_wins/num_trials*100:.2f}%)")
    print(f"Switch strategy wins: {switch_wins} ({switch_wins/num_trials*100:.2f}%)")
    return stay_wins/num_trials, switch_wins/num_trials

# Запуск симуляции
stay_prob, switch_prob = simulate_monty_hall(100000)

1. Критерии проверки (тест-кейсы):

    *   **Основной тест**: После N симуляций (например, 100000) вероятность победы при переключении должна быть статистически близка к 2/3 (~66.67%), а при сохранении выбора — к 1/3 (~33.33%). Используем допуск ±1% для больших N.
    *   **Тест на корректность логики ведущего**: Ведущий никогда не открывает дверь с автомобилем и никогда не открывает выбранную игроком дверь. Добавим assertion проверки в код.
    *   **Тест на граничные условия/вариации**: Что если дверей 4? Или ведущий открывает door не всегда? Эти сценарии проверят устойчивость парадокса к изменению условий.
    *   **Статистическая значимость**: Используем методы (например, доверительные интервалы) чтобы убедиться, что результаты не случайная флуктуация.

# Тест с проверкой логики ведущего (Unit Test стиль)
def test_host_logic():
    for _ in range(1000):
        doors = ['goat', 'goat', 'car']
        random.shuffle(doors)
        first_choice = random.randint(0, 2)
        
        # Все возможные двери для открытия ведущим
        possible_opens = [i for i in range(3) if i != first_choice and doors[i] == 'goat']
        
        # Выбор ведущего
        host_open = random.choice(possible_opens)
        
        # Assertion проверки
        assert host_open != first_choice, "Host opened player's door!"
        assert doors[host_open] == 'goat', "Host opened car door!"
        assert len(possible_opens) > 0, "No valid door for host to open!"
    print("Host logic test passed.")

test_host_logic()

Расширенное тестирование и анализ

• Интеграция с фреймворками: Можно обернуть симуляции в pytest или unittest для структурированного отчетности.
• Генерация отчетов и графиков: Использование matplotlib для визуализации распределения вероятностей при увеличении числа испытаний. Это подтверждает стабилизацию результатов около теоретических значений.
• Параметризованное тестирование: Проверка сценариев с разным количеством дверей (например, 4, 5) и анализ изменения вероятностей.
• Property-based testing: Используя библиотеку как Hypothesis, можно автоматически генерировать множество различных начальных условий и проверять инварианты (например, "вероятность переключения всегда > вероятность остаться").

# Пример параметризованного теста (концепт)
def simulate_generalized_monty(num_doors, num_trials):
    # Авто за одной, пустяки за остальными
    # Ведущий открывает все пустые кроме одной (оставляя выбор игрока и одну другую)
    # Обобщенная логика
    pass

# Проверим для 4 дверей: теория говорит, что переключение дает 3/4 победы.

Выводы для QA процесса

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

• Автоматизация позволяет провести миллионы испытаний быстро, что невозможно вручную.
• Результаты симуляции служат фактическим доказательством, дополняющим математическое.
• Методология напрямую применима в QA для тестирования сложных бизнес-логик, игровых механик или алгоритмов, где результат зависит от вероятностей и состояний.
• Комбинация unit-тестов (логика ведущего) и интеграционных/статистических тестов (вероятности) дает полную картину.

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