Как соотносятся Sanity, Smoke и регрессионное тестирование
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Соотношение Sanity, Smoke и регрессионного тестирования
В практике контроля качества Sanity Testing, Smoke Testing и Регрессионное тестирование — это взаимосвязанные, но различные по целям и глубине проверки виды тестирования. Их соотношение можно представить как пирамиду или воронку проверок, где каждый последующий этап требует больше времени и охватывает больше функциональности.
Определение и цели каждого типа
1. Smoke Testing (Дымовое тестирование)
Smoke Testing — это поверхностная, быстрая проверка стабильности сборки (build) перед запуском более глубокого тестирования. Основная цель — убедиться, что критическая функциональность приложения работает после новой интеграции кода, и сборка не "задымилась" (не сломалась полностью).
- Когда выполняется: Сразу после получения новой сборки от разработчиков.
- Объем: Небольшой набор позитивных сценариев для ключевых модулей (например: запуск приложения, авторизация, переход на главную страницу, создание сущности).
- Аналог: Проверка, заводится ли машина после ремонта, горят ли основные лампочки на приборной панели.
// Пример высокоуровневого Smoke-сценария для веб-приложения
// 1. Открыть главную страницу (проверить код ответа 200)
// 2. Выполнить успешный вход в систему
// 3. Перейти в основной раздел (например, "Документы")
// 4. Убедиться, что контент раздела загружается
// Если любой шаг падает - сборка нестабильна для дальнейшего тестирования.
2. Sanity Testing (Здравомысленное/быстрое функциональное тестирование)
Sanity Testing — это узконаправленная, углубленная проверка одного или нескольких конкретных исправлений или новых функций после сборки, прошедшей Smoke-тест. Цель — убедиться, что заявленные изменения работают корректно и рационально, без проверки смежных областей.
- Когда выполняется: После успешного Smoke-теста, когда нужно проверить конкретный багфикс или новую фичу.
- Объем: Глубокое, но сфокусированное тестирование одной конкретной функциональной области. Это подмножество регрессионного тестирования.
- Аналог: После того как машина завелась, механик проверяет именно отремонтированный узел — тормоза заменили, проверяем только их.
# Пример Sanity-сценария после фикса бага "Нельзя добавить товар в корзину"
def test_add_item_to_cart_sanity():
login(user) # Шаг из Smoke-теста
open_catalog()
item = find_item("Test Product")
add_to_cart(item)
assert cart_count() == 1, "Товар не добавлен в корзину" # Основная проверка фикса
# Мы НЕ проверяем удаление из корзины, оформление заказа и т.д.
3. Регрессионное тестирование (Regression Testing)
Регрессионное тестирование — это всеобъемлющая проверка того, что последние изменения в коде не сломали существующую, ранее рабочую функциональность приложения. Это самый широкий и глубокий тип из трех.
- Когда выполняется: После Smoke- и Sanity-тестов, перед выпуском версии в релиз или на staging-окружение. Часто автоматизировано.
- Объем: Широкий охват: повторное исполнение тестов для ключевых и смежных функциональных областей, затронутых изменениями, а также основных "вех" (happy paths) всего приложения.
- Аналог: Полный техосмотр машины после ремонта одного узла, чтобы убедиться, что ремонт не повлиял на работу двигателя, электроники, подвески и т.д.
Ключевые соотношения и отличия
| Критерий | Smoke Testing | Sanity Testing | Регрессионное тестирование |
|---|---|---|---|
| Основная цель | Проверить стабильность сборки | Проверить работоспособность конкретных изменений | Проверить отсутствие регресса в существующей функциональности |
| Глубина | Поверхностно, "по верхам" | Узко и глубоко в одной области | Широко и глубоко по многим областям |
| Отношение к изменениям | Проверяет сборку в целом | Проверяет новые/исправленные функции | Проверяет старые, но работавшие функции |
| Время выполнения | Минуты (5-30) | Десятки минут (15-60) | Часы, дни (зависит от автоматизации) |
| Является ли подмножеством | Нет. Это входной контроль. | Да, подмножество регрессионного | Нет. Это широкое множество проверок. |
Практический рабочий процесс (Sequential Relationship)
Типичный поток в цикле разработки выглядит так:
- Получена новая сборка.
- Запускается Smoke Test Suite.
* **Если падает:** Сборка отвергается, возвращается разработчикам. Регрессия не имеет смысла.
* **Если проходит:** Сборка считается условно стабильной. Переход к следующему шагу.
- Запускается Sanity Testing для конкретных задач текущего спринта/фикса.
* **Если падает:** Фиксы/фичи не работают, как заявлено. Сборка может быть отвергнута или возвращена на доработку.
* **Если проходит:** Изменения валидированы. Можно углубляться.
- Запускается полный или частичный набор Регрессионных тестов.
* Фокус на областях, **наиболее подверженных влиянию** последних изменений (так называемое **"выборочное регрессионное тестирование"**), и на самой критической функциональности продукта.
Вывод
Таким образом, Smoke — это страховочная сетка для процессинга нестабильных сборок, Sanity — лупа для детального изучения конкретных изменений, а Регрессионное — защитный щит для всего продукта. Sanity-тестирование часто является первой, целевой частью более широкого регрессионного тестирования. Все вместе они образуют многоуровневую систему проверок, которая экономит время команды, отсекая явно сломанные сборки на раннем этапе (Smoke), и обеспечивает уверенность в качестве как новых (Sanity), так и старых (Regression) функций продукта перед выпуском.