Когда проводится регрессионное тестирование?

Question

Когда проводится регрессионное тестирование?

Тип вопроса: Основы тестирования Вероятность: 10% Категория: QA Тестировщик

Ответ

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

Основные триггеры для запуска регрессионных тестов:

После исправления дефекта: Проверяется не только исправленный сценарий, но и связанная функциональность.
После добавления новой функциональности: Убеждаемся, что новая фича не сломала старые.
При слиянии веток (merge) в Git: Особенно важно при интеграции feature-веток в основную (main/develop).
После рефакторинга кода: Когда внутренняя структура меняется без изменения внешнего поведения.
Перед выпуском релиза (Release Candidate): Комплексная проверка стабильности всей системы.
После изменений в окружении: Обновление ОС, библиотек, серверов и т.д.

Практика:

Автоматизация: Ключевые регрессионные тесты должны быть автоматизированы для частого и быстрого прогона.
CI/CD: Регрессионные тесты интегрируются в пайплайн непрерывной интеграции (CI) и запускаются автоматически при каждом коммите или пулл-реквесте.

Пример сценария:

# Автоматизированный регрессионный тест для функции логина
def test_login_regression():
    # Проверяем, что базовый сценарий все еще работает
    assert login("valid_user@example.com", "SecurePass123!") == True
    # Проверяем, что старые баги не вернулись (регрессия)
    assert login("", "") == False  # Пустые поля
    assert login("user", "pass") == False  # Неверный пароль
    # Проверяем связанную функциональность (например, блокировка после N попыток)
    for _ in range(5):
        login("attacker", "wrong")
    assert login("valid_user@example.com", "SecurePass123!") == False  # Аккаунт должен быть временно заблокирован

Цель — минимизировать регрессионные дефекты (старые баги, которые вернулись, или работающий функционал, который сломался).

Ответ 18+ 🔞

Да ты посмотри, какая интересная штука — регрессионное тестирование! Это ж как в старом анекдоте: починил одно, а три других сломалось, блядь. Вот именно от этого кошмара оно и спасает.

Смысл в чём, ёпта? Ты там в коде что-то подкрутил, новую плюшку впендюрил, багу старую прибил — и всё, доволен как слон. Ан нет, сука! Надо проверить, не разъехался ли твой новый гениальный код по всем старым, рабочим штукам. Вот это и есть регрессия — когда система, как мартышка, начинает пятиться назад и наступать на те же грабли.

Так когда же надо эту проверку включать, а? Да почти всегда, блядь!

Багу завалил. Ну ок, поправил. Но мало проверить, что эта конкретная хуйня теперь работает. Надо ещё глянуть, а не потянул ли ты за собой шлейф из других косяков? Всё связанное — в топку тестов!
Фичу новую запилил. Красота! Но эта твоя красота должна вписаться в уже существующий интерьер, а не ломать все стены, как слон в посудной лавке. Старое должно работать как часы.
Ветки в гите смержил. Вот тут вообще пиздец может начаться. Ты в своей ветке творил одно, Петя в соседней — другое. Слили это всё в одну кучу — и понеслась: конфликты, несовместимости, одни сплошные "вротберунчики". Регрессия всё это выловит.
Код отрефакторил. Внешне всё то же самое, но внутри всё перелопатил. А вдруг, блядь, где-то логику криво перенёс? Только полный прогон тестов успокоит душу.
Релиз готовишь. Самый ответственный момент, терпения ноль ебать. Тут надо всю систему прощупать вдоль и поперёк, чтобы не вышло как в том бородатом анекдоте: "Запускаем в продакшен — и молимся".
Окружение поменялось. Обновили версию библиотеки или сервер переехал — и всё, привет, неожиданные сюрпризы. Регрессия помогает понять, что сломалось именно из-за этого.

А как на практике-то, блядь?

Автоматизируй, ёпта! Если каждый раз руками всё проверять — это ж до второго пришествия. Надо, чтобы тесты сами бегали, как угорелые, при каждом чихе в коде.
В CI/CD их! Сделал коммит — пайплайн схватил твой код, запустил на нём все регрессионные тесты и сказал: "Всё пиздато, можно мержить" или "Чувак, бля, ты всё сломал, иди фикси".

Вот, смотри, наглядный пример, как это может выглядеть:

# Автоматизированный регрессионный тест для функции логина
def test_login_regression():
    # Проверяем, что базовый сценарий все еще работает
    assert login("valid_user@example.com", "SecurePass123!") == True
    # Проверяем, что старые баги не вернулись (регрессия)
    assert login("", "") == False  # Пустые поля
    assert login("user", "pass") == False  # Неверный пароль
    # Проверяем связанную функциональность (например, блокировка после N попыток)
    for _ in range(5):
        login("attacker", "wrong")
    assert login("valid_user@example.com", "SecurePass123!") == False  # Аккаунт должен быть временно заблокирован

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