Ответ
Smoke-тестирование (Build Verification Test) — это минимальный набор быстрых проверок, который подтверждает, что критически важный функционал приложения работает после сборки или развертывания, и его можно тестировать дальше.
Типичные сценарии Smoke-тестов:
- Запуск и доступность: Приложение/сервис запускается без критических ошибок. Веб-сервер отвечает по основному URL, API возвращает ожидаемый статус (например, 200 для
/health). - Базовая аутентификация/авторизация: Возможность войти в систему с валидными учетными данными.
- Проверка основных модулей (Happy Path):
- Для веб-приложения: загрузка главной страницы, страницы входа, ключевых разделов.
- Для API: выполнение основных CRUD-операций для главной сущности (например, Пользователь или Товар).
- Для мобильного приложения: запуск, переход по основным табам.
- Критическая бизнес-логика: Один-два ключевых сквозных (E2E) сценария. Например, для интернет-магазина: «Поиск товара -> Добавление в корзину -> Начало оформления заказа».
Пример Smoke-теста для REST API (Python, pytest):
import requests
def test_smoke_api_health():
"""Проверка, что API доступен."""
resp = requests.get("https://api.example.com/health", timeout=5)
assert resp.status_code == 200
assert resp.json()["status"] == "OK"
def test_smoke_crud_cycle():
"""Проверка базового цикла создания и чтения сущности."""
# 1. CREATE (POST)
new_item = {"title": "Smoke Test Item"}
create_resp = requests.post("https://api.example.com/items", json=new_item)
assert create_resp.status_code in [200, 201]
item_id = create_resp.json()["id"]
# 2. READ (GET)
get_resp = requests.get(f"https://api.example.com/items/{item_id}")
assert get_resp.status_code == 200
assert get_resp.json()["title"] == new_item["title"]Главный принцип: Smoke-тесты должны быть быстрыми, стабильными и покрывать «ствол» системы. При падении любого Smoke-теста дальнейшее углубленное тестирование бессмысленно.
Ответ 18+ 🔞
Давай разберемся, что за зверь такой — Smoke-тестирование, а то некоторые думают, что это когда в облако дыма смотрят и гадают, работает ли что-то. Нет, блядь, всё куда конкретнее.
Это, сука, минимальный и быстрый набор проверок, который отвечает на один простой, как три рубля, вопрос: а не сломалось ли у нас всё в хлам после новой сборки или обновления? Если критические функции живы — можно дальше копать. Если нет — вся команда идёт пить кофе, пока разработчики тушат пожар.
Что обычно проверяют, чтобы не выглядеть идиотами:
- Запустилось ли оно вообще? Приложение стартануло без мгновенного краша, веб-сервер не показывает рожу с ошибкой 500, а на запрос к
/healthотвечает «живой, блядь!». - Можно ли зайти? Базовая аутентификация работает. Ввёл правильный логин-пароль — попал внутрь, а не получил по морде ошибкой.
- Главные модули на месте? Для веба грузятся основные страницы. Для API — выполняются ключевые CRUD-операции (создал запись, прочитал её — и не просрал где-то по дороге). Для мобилки — переключение между основными экранами не выкидывает в главное меню телефона.
- Самый важный бизнес-сценарий жив? Для магазина: нашёл товар, сунул в корзину, начал оформлять заказ — и не упало на самом интересном месте. Один такой сквозной сценарий, но зато самый жирный.
Вот тебе пример, как это может выглядеть в коде. Не трогай его, он и так хорош:
import requests
def test_smoke_api_health():
"""Проверка, что API доступен."""
resp = requests.get("https://api.example.com/health", timeout=5)
assert resp.status_code == 200
assert resp.json()["status"] == "OK"
def test_smoke_crud_cycle():
"""Проверка базового цикла создания и чтения сущности."""
# 1. CREATE (POST)
new_item = {"title": "Smoke Test Item"}
create_resp = requests.post("https://api.example.com/items", json=new_item)
assert create_resp.status_code in [200, 201]
item_id = create_resp.json()["id"]
# 2. READ (GET)
get_resp = requests.get(f"https://api.example.com/items/{item_id}")
assert get_resp.status_code == 200
assert get_resp.json()["title"] == new_item["title"]А теперь главная мысль, которую надо выбить себе на лбу: Smoke-тесты должны быть быстрыми, как удар током, и стабильными, как скала. Если хоть один такой тест падает — это красная, ёбта, лампочка. Всё, стоп, приехали. Дальнейшее тестирование — это как ремонтировать машину, которая не заводится. Бесполезная трата времени, одни расстройства. Сначала чиним запуск, а потом уже смотрим, какого цвета обивка в салоне.