Какие требования проверял в Smoke тестировании

Основные цели Smoke-тестирования (сборки)

Smoke-тестирование (другие названия: Sanity-тест, Build Verification Test, BVT) — это поверхностный, быстрый набор проверок, который выполняется после каждой новой сборки (build) программного обеспечения. Его главная цель — не найти все баги, а дать оценку: «Готова ли эта версия ПО к дальнейшему, более глубокому тестированию?». Если сборка не проходит Smoke-тест, она отправляется на доработку, и тестирование останавливается на самой ранней стадии, экономя значительные ресурсы команды.

Основная гипофаза Smoke-тестов — «успешная установка и базовый запуск». Более подробно проверяются следующие ключевые требования.

Ключевые требования, проверяемые в Smoke-тестировании

1. Установка и развертывание (Deployment)

Это первое и обязательное требование. Если ПО нельзя установить, все остальные тесты бессмысленны.

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

2. Запуск и инициализация

После установки приложение должно «ожить».

• Запуск основных исполняемых файлов: Приложение запускается без падения (crash) на этапе загрузки (splash screen, инициализация модулей).
• Загрузка основных модулей и сервисов: Критически важные системные сервисы (например, сервис авторизации, модуль работы с БД, сетевой стек) инициализируются без ошибок.
• Отсутствие блокирующих ошибок: Не появляется сообщений типа «Критическая ошибка», «Не удалось загрузить библиотеку X», требующих немедленного закрытия приложения.

3. Доступность ключевой (критичной) функциональности

Проверяются основные сценарии (happy path) наиболее важных модулей. Глубина проверки минимальна — «работает/не работает».

• Для веб-приложения:

    *   Загрузка главной страницы, страницы входа.
    *   Успешная авторизация с валидными данными.
    *   Загрузка основной дашборда/ленты после входа.
    *   Навигация между главными разделами меню.

• Для десктопного ПО:

    *   Открытие главного окна, отображение основного интерфейса.
    *   Создание нового файла/проекта.
    *   Сохранение файла.
    *   Открытие основных диалоговых окон (Настройки, Справка).

• Для мобильного приложения:

    *   Запуск, отображение splash screen и главного экрана.
    *   Реакция на базовые жесты (тап, свайп).
    *   Работа с разрешениями (если требуются для базового функционала).

4. Интеграция с внешними системами

Проверяется доступность и «отклик» критически важных внешних зависимостей.

• Соединение с сервером/БД: Приложение может установить соединение с бэкенд-сервером или базой данных (без проверки сложных запросов).
• Доступность лицензионного сервера (если применимо).
• Работа с сетью: Базовая проверка сетевых запросов (например, GET-запрос к основному API-эндпоинту возвращает не пустой ответ и код 200). Пример упрощенного скрипта-проверки:

#!/bin/bash
API_URL="https://api.example.com/health"
response=$(curl -s -o /dev/null -w "%{http_code}" $API_URL)

if [ "$response" -eq 200 ]; then
    echo "Smoke Test PASSED: Сервер доступен."
else
    echo "Smoke Test FAILED: Сервер недоступен. Код ответа: $response"
    exit 1  # Выход с ошибкой, сигнализирующий о провале сборки
fi

5. Стабильность в течение короткого времени

Приложение должно работать без падений не только в момент запуска, но и в течение короткого периода (например, 5-10 минут) при выполнении базовых операций.

Принципы формирования Smoke-набора

• Стабильность: Тесты должны быть максимально надежными, не подверженными ложным срабатываниям (false-positive). Они не зависят от изменчивых данных.
• Скорость: Весь набор должен выполняться от нескольких минут до получаса. Это позволяет быстро принять решение о судьбе сборки.
• Автоматизация: В современной разработке Smoke-тесты почти всегда автоматизированы. Они интегрированы в CI/CD-пайплайн (Jenkins, GitLab CI, GitHub Actions) и запускаются автоматически после каждой сборки.
• Изоляция от деталей: Тесты проверяют общую работоспособность, а не UI-детали, орфографию или производительность. Это задача других видов тестирования.
• Постоянство: Набор Smoke-тестов изменяется редко, только при фундаментальных изменениях в архитектуре продукта или добавлении новой критически важной фичи.

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