Ответ
Это виды тестирования, отличающиеся по цели, глубине и объему проверок, выполняемых на разных этапах разработки.
Smoke-тестирование (Дымовое, Build Verification Test - BVT)
- Цель: Быстро проверить, что критически важные функции системы работают после новой сборки (билда) или развертывания. Ответ на вопрос: "Можно ли начинать более глубокое тестирование?"
- Объем: Минимальный набор позитивных сценариев, покрывающих основной путь (happy path) ключевых модулей (например, запуск приложения, аутентификация, создание сущности).
- Когда выполняется: Сразу после каждой новой сборки. Часто автоматизировано и запускается в CI/CD первым.
- Мой опыт: В одном из проектов smoke-сценарий состоял из 15 автоматизированных тестов, которые проверяли доступность главной страницы, логин, переход в личный кабинет и отображение основных виджетов. Если падал хотя бы один — сборка считалась непригодной для регресса.
Sanity-тестирование (Санитарное, "здравомыслие")
- Цель: Узконаправленная проверка конкретных изменений (нового функционала или исправления бага) после smoke-тестов. Ответ на вопрос: "Работает ли именно то, что мы изменили, как ожидалось?"
- Объем: Неглубокое тестирование только затронутой функциональности и смежных областей.
- Когда выполняется: После smoke-тестов, перед полным регрессом. Часто выполняется вручную.
- Пример: После исправления бага с расчетом скидки в корзине, sanity-чек включает: добавление товара, применение скидки, оформление заказа. Мы не проверяем весь функционал корзины, а только сценарии, связанные с исправлением.
Regression-тестирование (Регрессионное)
- Цель: Полная проверка всего существующего функционала приложения после изменений. Ответ на вопрос: "Не сломали ли новые изменения что-то работавшее ранее?"
- Объем: Максимально широкий. Включает повторное выполнение всех релевантных тестов (функциональных, интеграционных, иногда нефункциональных) для проверки ранее работавшей функциональности.
- Когда выполняется: После sanity-тестирования, перед выпуском версии в продакшн. Активно автоматизируется.
- Мой подход: Регрессионный набор у нас делился на "полный" (запускался перед релизом) и "быстрый" (ядро критических тестов, запускался ежедневно). Мы использовали теговую систему в Pytest (
@pytest.mark.regression,@pytest.mark.smoke) для гибкого управления запуском.
Итог: Smoke — "заводится ли машина?", Sanity — "работает ли новая печка?", Regression — "а все остальное в машине после установки печки работает как раньше?"
Ответ 18+ 🔞
А, ну это же классика, про которую каждый второй джуниор путается, а потом на проекте выходит пиздец! Слушай сюда, я тебе на пальцах объясню, чтобы даже мартышлюшка с бананом в руке поняла.
Представь, что у тебя есть машина. Не просто машина, а какая-нибудь раздолбанная «девятка», которую ты каждый вечер чинишь в гараже, добавляя новые приблуды и заклеивая старые дыры скотчем.
Smoke-тестирование (Дымовое) Это когда ты только что прикрутил новую печку, собрал весь этот конструктор обратно, садишься за руль и поворачиваешь ключ зажигания. Завелась? Фары горят? Печка дует, а не дымит? Отлично, ёпта! Это и есть smoke-тест. Его цель — не проверить, как машина едет по бездорожью, а понять, вообще нахуй она жива после твоих вмешательств. Можно ли её выкатывать из гаража для дальнейших проверок? Если не заводится — всё, пизда, дальше даже смотреть нечего, надо разбирать обратно. В мире софта это обычно пачка быстрых автотестов, которые гоняют после каждой сборки. Упал один — вся сборка в помойку, доверия к ней ебать ноль.
Sanity-тестирование (Санитарное, проверка «здравомыслия») Допустим, smoke прошёл, машина завелась. Но ты же чинил конкретно печку! Значит, теперь надо проверить именно её. Включаешь на полную, греет? Переключаешь режимы, работают? Воздух не воняет горелой проводкой? Вот это и есть sanity. Это не про всю машину, а про узкую область изменений. Ты отвечаешь на вопрос: «А та херня, которую я только что починил, работает ли так, как я задумал, или я опять где-то накосячил?». Часто это ручные проверки, быстрые и точечные. Сделал — и можно уже думать о более масштабных тестах.
Regression-тестирование (Регрессионное) А вот это, чувак, самая жопа. Это когда ты проверил печку, и она вроде греет. Но ты-то знаешь свою «девятку»! Вполне могло оказаться, что, пока ты возился с проводкой печки, ты отъебал магнитолу, у тебя перестали работать дворники, а бензобак теперь протекает. Регресс — это полная, тотальная проверка всего, что работало до твоих правок. Выкатываешь машину на полигон и начинаешь: разгон, торможение, повороты, свет, сигнал, обогрев стекол, кондер (если есть), аудиосистема — всё, блядь, до последней кнопки! Цель одна: убедиться, что новые фичи или багфиксы не сломали старый, отлаженный функционал. Это долго, нудно и овердохуища ресурсов жрёт, поэтому его стараются максимально автоматизировать. На нормальных проектах есть «тяжёлый» регресс перед релизом и «лёгкий» — для ежедневных проверок ядра.
Короче, итог:
- Smoke: Заводится ли машина после сборки? (Да/Нет)
- Sanity: А та деталь, которую я вчера чинил, работает? (Да/Нет)
- Regression: А всё остальное, что работало вчера, всё ещё работает? (Надеюсь, что да)
Запомни эту аналогию, и тебя на собеседовании хоть ночью разбуди — отбабахаешь как по маслу. Главное — не путай, а то бывало, начинают регресс гонять на сломанной сборке… Э, сабака сука, время на ветер, волнение ебать, терпения ноль ебать!