Что такое smoke тестирование?

Что такое smoke-тестирование?

Smoke-тестирование — это минимальный набор тестов, выполняемый после сборки или развертывания нового билда (сборки) программного обеспечения, чтобы убедиться, что критически важные функции системы работают и сборка стабильна для дальнейшего, более глубокого тестирования. Основная цель — быстро определить, является ли билд «дымящимся» (англ. smoke — дым), то есть содержит ли он настолько серьезные дефекты, что дальнейшее тестирование бессмысленно. Термин пришел из электроники: если при включении устройства из него пошел дым, дальнейшая проверка бесполезна — устройство нерабочее.

Ключевые характеристики smoke-тестов

• Высокая скорость выполнения: Тесты должны быть быстрыми, чтобы дать почти мгновенную обратную связь команде разработки.
• Покрытие основных сценариев: Проверяются не все функции, а только самые важные, «пути счастья» (happy paths) для ключевых модулей. Например, для интернет-магазина: запуск приложения, вход пользователя, просмотр каталога, добавление товара в корзину.
• Поверхностное тестирование: Не углубляются в граничные случаи, негативные сценарии или производительность. Главный вопрос: «Система запускается и выполняет свои основные функции?».
• Стабильность и детерминизм: Smoke-тесты должны быть максимально надежными и давать одинаковый результат при одинаковых условиях. Ложные срабатывания (false positives) здесь очень дороги.
• Частое выполнение: Проводятся после каждой новой сборки, часто интегрируются в процесс CI/CD (Continuous Integration/Continuous Delivery).

Место smoke-тестирования в жизненном цикле

Smoke-тесты — это первый защитный барьер в цепочке тестирования нового билда. Их логическое место:

1. Разработчик создает новый билд.
2. Запускается smoke-сuite (набор smoke-тестов).
3. Если smoke-тесты провалились -> билд отвергается, возвращается разработчикам на исправление. Глубокое тестирование не начинается.
4. Если smoke-тесты прошли -> билд считается условно стабильным, и QA-инженеры приступают к регрессионному, функциональному и другим видам тестирования.

Пример smoke-теста для веб-приложения

Рассмотрим на примере простого REST API для управления пользователями. Smoke-тест может проверять доступность сервиса и базовую работу ключевого эндпоинта.

import pytest
import requests

BASE_URL = "https://api.example.com/v1"

class TestSmoke:
    """Набор smoke-тестов для проверки стабильности билда API."""

    def test_service_is_alive(self):
        """Проверка, что сервис отвечает на health check."""
        response = requests.get(f"{BASE_URL}/health", timeout=5)
        assert response.status_code == 200
        assert response.json()["status"] == "OK"

    def test_create_and_get_user_flow(self):
        """Проверка базового потока создания и получения пользователя."""
        # 1. Создание пользователя (основная функция)
        user_data = {"name": "John Smoke", "email": "john.smoke@test.com"}
        create_response = requests.post(f"{BASE_URL}/users", json=user_data, timeout=5)
        assert create_response.status_code == 201
        created_user = create_response.json()
        user_id = created_user["id"]

        # 2. Получение только что созданного пользователя
        get_response = requests.get(f"{BASE_URL}/users/{user_id}", timeout=5)
        assert get_response.status_code == 200
        retrieved_user = get_response.json()

        # 3. Проверка целостности данных
        assert retrieved_user["name"] == user_data["name"]
        assert retrieved_user["email"] == user_data["email"]

    def test_main_endpoints_respond(self):
        """Проверка, что основные эндпоинты возвращают не 5xx ошибки."""
        endpoints = ["/users", "/products", "/orders"]
        for endpoint in endpoints:
            response = requests.get(f"{BASE_URL}{endpoint}", timeout=5)
            # Важно: мы не проверяем бизнес-логику, а лишь факт работоспособности
            assert response.status_code != 500, f"Endpoint {endpoint} вернул 500 ошибку"

Практическая реализация в CI/CD

В современных DevOps-практиках smoke-тесты автоматизированы и встроены в конвейер сборки.

# Пример секции pipeline в GitLab CI
stages:
  - build
  - smoke
  - test

smoke-test:
  stage: smoke
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest tests/smoke/ --maxfail=1 --tb=short  # Останавливаемся при первой же ошибке
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"  # Запускаем smoke на каждый push в main

Отличие от других видов тестирования

• Vs Sanity-тестирование: Часто эти термины используют как синонимы, но есть нюанс. Sanity-тестирование обычно точечное, проводится после исправления конкретного дефекта или небольшого изменения, чтобы убедиться, что правки работают и не сломали очевидные вещи. Smoke — более широкий, всегда после сборки.
• Vs Регрессионное тестирование: Регрессионное тестирование — глубокое и полное, направленное на проверку того, что новые изменения не сломали существующий функционал. Smoke — это его быстрое, поверхностное подмножество, «входной билет» для регресса.

Заключение

Smoke-тестирование — это неотъемлемая практика DevOps, которая экономит время и ресурсы команды. Оно выступает как эффективный фильтр, отсеивая нерабочие сборки на самой ранней стадии. Для QA Automation инженера важно уметь проектировать и поддерживать быстрый, стабильный и содержательный smoke-сuite, который станет надежным фундаментом для всего последующего процесса обеспечения качества.