Какие сценарии входят в Smoke

Smoke-тестирование: цели и базовые сценарии

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

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

• Высокий приоритет: Проверяют критически важную функциональность.
• Быстрое выполнение: Набор должен выполняться за минуты, а не часы.
• Широкая область покрытия: Затрагивают основные модули системы.
• Стабильность: Не должны быть хрупкими или давать ложные срабатывания.
• Повторяемость: Легко запускаются автоматически.

Типовые сценарии, входящие в Smoke Suite

Сценарии зависят от типа приложения (веб, мобильное, десктопное, API), но их можно сгруппировать по общим категориям.

1. Проверка доступности и целостности системы

• Загрузка главной страницы/экрана приложения: Успешный HTTP-ответ (код 200), отсутствие критических ошибок в консоли браузера или логах сервера.
• Проверка здоровья сервисов (Health Checks): Доступность ключевых API-эндпоинтов, баз данных, кэша, внешних зависимостей.

  # Пример простого API smoke-теста на Python с requests
  import requests
  
  def test_main_page_availability():
      response = requests.get("https://api.example.com/health", timeout=5)
      assert response.status_code == 200
      assert response.json()["status"] == "OK"
  
  def test_critical_service_health():
      services = ["/auth/health", "/db/health", "/cache/health"]
      for service in services:
          resp = requests.get(f"https://api.example.com{service}")
          assert resp.status_code == 200, f"Service {service} is down"
  

• Проверка версии сборки: Соответствие деплойленной версии ожидаемой.

2. Проверка ядра бизнес-логики (Happy Path)

Это минимальные «счастливые пути» для самых важных функций.

• Для интернет-магазина:

    *   Поиск товара.
    *   Добавление товара в корзину.
    *   Переход в корзину и отображение добавленного товара.
    *   Начало процесса оформления заказа (до шага оплаты).

• Для социальной сети/форума:

    *   Успешный вход зарегистрированным пользователем (**аутентификация**).
    *   Загрузка ленты/списка тем.
    *   Создание нового поста/комментария.

• Для банковского приложения:

    *   Вход в систему.
    *   Просмотр баланса основного счета.
    *   Получение списка последних операций.

3. Проверка базовых операций с данными (CRUD)

Smoke-тесты часто проверяют минимальную работоспособность операций создания, чтения, обновления и удаления для главной сущности.

// Пример smoke-сценария для CRUD статьи в блоге (псевдокод)
describe('Blog Article Smoke Tests', () => {
    it('should CREATE a draft article', () => { ... });
    it('should READ the created article', () => { ... });
    it('should UPDATE the article title', () => { ... });
    // DELETE может не входить в smoke, если не является критической частотой использования
});

4. Проверка критических интеграций

• Успешное завершение процесса входа через основной метод аутентификации (например, логин/пароль).
• Корректное отображение данных, подгружаемых из основной базы данных.
• Для мобильных приложений — проверка запуска на минимально поддерживаемой версии ОС.

5. Проверка среды и конфигурации

• Загрузка основных конфигурационных файлов и переменных среды.
• Проверка доступности необходимых портов и внешних сервисов (например, SMTP-сервера для отправки писем).

Что НЕ входит в Smoke-тестирование?

Важно понимать границы:

• Детальное тестирование всех функций.
• Тестирование крайних случаев (edge cases) и негативных сценариев.
• Проверка нефункциональных требований (нагрузочное, стресс-тестирование, углубленная проверка UI/UX).
• Регрессионное тестирование полного функционала.

Практический подход к формированию Smoke Suite

1. Определите «скелет» приложения: Без каких функций продукт бессмыслен?
2. Совместная работа: Сценарии должны быть согласованы с разработчиками, аналитиками и продакт-менеджерами.
3. Автоматизация: Идеальный smoke-набор — это набор автоматических скриптов, интегрированных в CI/CD пайплайн (Jenkins, GitLab CI, GitHub Actions). Они запускаются автоматически после каждой сборки.
4. Регулярный ревью: Набор должен эволюционировать вместе с продуктом. Устаревшие сценарии нужно удалять, а под новые критические функции — добавлять.

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