Smoke- vs Sanity-тестирование: что это такое и в чём разница
В разработке программного обеспечения (ПО) важно различать виды тестирования, чтобы обеспечить высокое качество продукта. Двое из этих видов — смоук-тестирование и санити-тестирование — часто вызывают вопросы относительно их различий и применения.
В этой статье мы подробно рассмотрим каждый из этих подходов, их цели, задачи и случаи, когда их следует использовать.
Что такое смоук-тестирование
Определение и цель
Смоук-тестирование (от англ. Smoke Testing) также известное как «Дымовое тестирование» = быстрая проверка ключевой работоспособности приложения после сборки. Для неё выбирается небольшое подмножество тестов из всей базы, покрывающее основные функции, без детализации и глубоких проверок.
Цель — убедиться, что продукт в принципе работоспособен и может быть передан на дальнейшее тестирование.
Основные задачи смоук-тестирования
Проверка запуска приложения: Убедиться, что система успешно запускается без ошибок.
Проверка основной функциональности: Подтвердить работоспособность ключевых функций приложения.
Решение о дальнейшем тестировании: Определить, готова ли система к более глубокому тестированию или требуется немедленная доработка.
Применение смоук-тестирования на практике
После каждой новой сборки или обновления системы проводится дымовое тестирование. Например, при добавлении новой функции команда тестирования проверяет, что основные функции приложения работают корректно и не нарушены. Это позволяет выявлять критические дефекты на ранних этапах разработки, обеспечивая стабильность и надежность продукта.
Что такое санити-тестирование
Определение и цели
Санити-тестирование (от англ. Sanity Testing), так называемая «Проверка на вменяемость» = узконаправленное исследование конкретных изменений или исправлений в коде.
Основные цели направлены на подтверждение корректности внесённых изменений в код, подтверждение отсутствия новых дефектов, проверку общей стабильности системы после правок.
Основные задачи санити-тестирования
Проверка исправлений: Убедиться, что ранее обнаруженные дефекты были успешно устранены.
Оценка новой функциональности: Подтвердить корректность работы недавно добавленных функций.
Быстрая проверка стабильности: Определить, не появились ли новые дефекты после внесения изменений.
Применение тестирования на согласованность
Санити-тестирование проводится после внесения небольших изменений или исправлений в код. Например, после исправления бага команда тестирования выполняет санити-тесты, чтобы убедиться, что проблема решена и система работает стабильно.
Сравнение подходов: Чем отличаются Смоук- и Санити-тестирование
Что проверяется
Начальные проверки охватывают только базовые функции — например, запуск приложения, авторизацию, переход по основным страницам или доступность ключевых компонентов интерфейса — они нужны, чтобы убедиться, что система в целом запускается и не «падает» сразу после сборки. Проверки стабильности касаются лишь отдельных компонентов, изменённых в последнем коммите, — будь то логика, багфиксы или элементы интерфейса.
Когда применяются
Первая группа запускается сразу после сборки. Это экспресс-проверка перед запуском полного тестового прогона.
Вторая используется после конкретных правок в уже проверенной версии. Она помогает подтвердить, что фиксы не вызвали побочных эффектов.
Цель проверок
Поверхностная проверка — отсечь критичные баги до регресса.
Точечная — убедиться в надёжности последних изменений.
Кто запускает и как часто
Первый набор может запускаться как вручную, так и автоматически — чаще всего после каждого билда.
Второй — выборочно и по необходимости, при каждом изменении кода в стабильной ветке.
Частота и объём зависят от практик команды. Например, в CI-сценариях smoke-запуски выполняются автоматически при каждом коммите, а sanity-наборы — только при ручном триггере или изменении критичных компонентов. Но оба подхода работают быстрее, если хорошо настроены фильтры и запускаются выборочно, без всей тестовой базы.
Пример практического применения смоук- и санити-тестов
Представим, что в новом релизе приложения был обновлён алгоритм авторизации, из-за чего возникла ошибка, связанная с невозможностью входа пользователей с определёнными символами в пароле.
Сначала выполняется смоук-тестирование, чтобы убедиться, что приложение вообще запускается, базовые функции вроде входа и выхода работают без критических ошибок.
Затем, после обнаружения и исправления конкретного бага в авторизации, проводится санити-тестирование исключительно для проверки этого исправления и связанных с ним областей.
Чёткое разделение ролей смоук- и санити-тестирования помогает быстро находить критические ошибки и оперативно проверять исправления. Правильно используя оба подхода, команда сокращает риски выпуска нестабильного продукта и ускоряет выход релизов.
Как сочетать смоук- и санити-тестированием
Смоук- и санити-тестирование не взаимоисключающие подходы, а части одной стратегии. Вместо выбора между ними команды назначают отдельные теги smoke и sanity на тесты в зависимости от цели их запуска. Смоук- и санити-наборы запускаются в разных ситуациях и служат разным целям, но работают в связке.
Оценка пригодности сборки к дальнейшему тестированию
Смоук-тесты подходят для быстрой проверки общей работоспособности приложения после новой сборки. Они позволяют сразу выявить критические ошибки.
Локальная валидация правок
Санити-тесты эффективны при внесении точечных изменений, таких как исправление конкретного дефекта или добавление небольшой функциональности, которая не затрагивает всю систему.
Как реализовано смоук- и санити-тестирование в ТестОпс
В ТестОпс реализация смоук- и санити-тестирования основана на использовании тегов, пользовательских полей, гибкой фильтрации и селективных запусков. Такой подход позволяет гибко управлять наборами тестов, запускать только нужные сценарии и ускорять тестирование в релизном цикле.
Селективные запуски особенно важны в этой схеме. Они позволяют запускать только необходимую часть тестовой базы — например, только те тесты, которые помечены соответственно тегами smoke или sanity, или относятся к конкретному компоненту приложения. Это сокращает время тестирования, экономит ресурсы и помогает быстрее получать обратную связь.
ТестОпс предоставляет удобный интерфейс для настройки выборки и запуска тестов. Через фильтры можно собрать нужный набор по тегу, владельцу, компоненту или статусу. А благодаря связке с CI-сервером через настроенные джобы, такие выборочные запуски можно автоматизировать.
Дополнительно, в разделе «Запуски» отображается актуальный статус выполнения тестов в реальном времени — это упрощает мониторинг и позволяет оперативно реагировать на сбои.
Смоук-тестирование в ТестОпс
Теги и пользовательские поля: Пометьте минимально необходимый набор тестов тегом smoke или создайте пользовательское поле (например, Тип запуска), чтобы отделить смоук-набор от остальных. Такой подход помогает поддерживать компактную и быструю выборку, которая проверяет базовую работоспособность системы.
Фильтрация и отбор: Используйте фильтр для отбора только тех тестов, которые помечены как smoke, без необходимости запускать всю тестовую суиту.
Селективный запуск: Настройте селективный запуск на стороне CI-сервера с помощью джобы в разделе «Джобы» в ТестОпс. Это позволит запускать только отобранные smoke-тесты, а не весь набор.
Санити-тестирование в ТестОпс
Пользовательские поля и компоненты: Санити-тесты удобно структурировать с помощью тега sanity и пользовательского поля Component, если вы хотите проверять конкретные модули или зоны приложения после правок.
Гибкая фильтрация: ТестОпс позволяет создать фильтр, который отбирает только тесты с тегом sanity, либо, например, sanity + компонент = «Авторизация». Это даёт точную выборку под конкретные изменения.
Селективный запуск через джобы: Как и для смоук-проверок, селективный запуск позволяет выполнять только нужные sanity-тесты. Это особенно эффективно при проверке фиксов без необходимости запускать полную регрессию.
Как применять оба подхода эффективно
Смоук- и санити-тесты не исключают друг друга. Смоук проверяет, запускается ли система и работают ли основные функции. Санити помогает быстро убедиться, что конкретное исправление не вызвало побочных эффектов. Используйте оба подхода в связке: так вы быстрее найдёте критические ошибки и подтвердите стабильность перед релизом.
📚 Попробуйте в работе
Узнайте больше о возможностях настройки CI-интеграции в системе управления тестированием ТестОпс: