Что такое дымовое тестирование?
Томас Гамильтон
⚡ Умное резюме
Дымовое тестирование определяет, достаточно ли стабильна новая сборка для тестирования. На этой странице объясняется, когда его следует запускать, кто его запускает, как работает цикл и как автоматизированные наборы тестов контролируют современные конвейеры доставки.
Что такое дымовое тестирование?
Дымовые испытания — это процесс тестирования программного обеспечения, который определяет, является ли развернутая сборка программного обеспечения стабильной или нет. Дымовое тестирование является подтверждением для команды контроля качества приступить к дальнейшему тестированию программного обеспечения. Он состоит из минимального набора тестов, выполняемых в каждой сборке для проверки функциональности программного обеспечения. Дымовое тестирование также известно как «проверочное тестирование сборки» или «проверочное тестирование».
Проще говоря, дымовое тестирование означает проверку работоспособности важных функций и отсутствие критических ошибок в тестируемой сборке. Это мини-тестирование и быстрая регрессия основных функций. Оно помогает определить, есть ли в сборке ошибки, из-за которых дальнейшее тестирование становится пустой тратой времени и ресурсов.
Сравнить Тестирование дыма против здравомыслия
Зачем мы проводим дымовую проверку?
Дымовое тестирование играет важную роль в разработке программного обеспечения, поскольку оно обеспечивает корректность системы на начальных этапах. Благодаря этому мы можем сэкономить трудозатраты на тестирование. Только после завершения дымового тестирования мы приступаем к функциональному тестированию.
- Все самые сложные элементы конструкции будут выявлены с помощью дымовой проверки.
- С помощью дымового контроля большинство дефектов выявляется на начальных стадиях. разработка программного обеспечения.
- С помощью дымового тестирования мы упрощаем обнаружение и исправление серьезных дефектов.
- С помощью дымового тестирования команда контроля качества может обнаружить дефекты функциональности приложения, которые могли возникнуть в новом коде.
- Дымовое тестирование выявляет основные серьезные дефекты.
Пример 1: Окно регистрации: возможность перехода к следующему окну с действительным именем пользователя и паролем при нажатии кнопки «Отправить».
Пример 2: Пользователь не может выйти из веб-страницы.
Когда проводится дымовая проверка?
Эти преимущества проявляются только в том случае, если проверка запускается в нужный момент. Дымовое тестирование проводится всякий раз, когда разрабатываются новые функции программного обеспечения и интегрируются с существующей сборкой, развернутой в среде контроля качества/тестирования. Оно гарантирует корректную работу всех критически важных функций. На диаграмме ниже показано, как сборка попадает в среду контроля качества до начала дымового тестирования.
При этом методе тестирования команда разработчиков развертывает сборку в отделе контроля качества. Тестировщики берут и запускают подмножество тестовых случаев для проверки критически важных функций сборки. Эта серия тестовых случаев предназначена для выявления ошибок в сборке. Если эти тесты пройдены успешно, команда контроля качества продолжает работу. Функциональное тестирование.
Любой сбой указывает на необходимость вернуть систему команде разработчиков. Всякий раз, когда в сборке происходят изменения, мы проводим дымовое тестирование, чтобы гарантировать стабильность.
Пример: - В окне входа в систему добавлена новая кнопка регистрации, и сборка развертывается с новым кодом. Мы проводим дымовое тестирование новой сборки.
Дымовые тесты позволяют подготовить сборку к дальнейшему формальному тестированию и призваны продемонстрировать стабильность системы и соответствие требованиям. Главная цель — выявление серьезных проблем на ранней стадии. Сборка включает в себя все файлы данных, библиотеки, многократно используемые модули и компоненты, необходимые для реализации одной или нескольких функций продукта.
Что произойдет, если мы не проведем дымовую проверку?
Если не проводить дымовую проверку на ранних стадиях, дефекты могут быть обнаружены на более поздних этапах, что может обойтись дорого. дефект Выявленная на более поздних этапах проблема может стать препятствием, влияющим на выпуск готовых результатов.
Кто будет проводить проверку дымом?
После выпуска сборки в среду контроля качества инженеры по обеспечению качества/руководитель отдела контроля качества проводят тестирование дыма. Всякий раз, когда выходит новая сборка, команда контроля качества определяет основные функции приложения для проведения дымового тестирования. Команда контроля качества проверяет наличие тормозов в тестируемом приложении.
Как проводить дымовую проверку?
Дымовое тестирование обычно проводится вручную, хотя существует возможность выполнить то же самое с помощью автоматизации. Оно может варьироваться от организации к организации.
Ручное дымовое тестирование
Дымовое тестирование проводится для обеспечения корректного прохождения критических путей и отсутствия препятствий для функциональности. Для выявления критических дефектов в системе берутся приоритетные функциональные тестовые случаи. Если тест пройден успешно, функциональное тестирование продолжается. Если тест не пройден, сборка отклоняется и отправляется обратно команде разработчиков для исправления.
Отдел контроля качества снова начинает дымовое тестирование с новой версией сборки. Дымовое тестирование проводится на новой сборке и будет интегрировано со старыми сборками для поддержания корректности системы. Перед проведением дымового тестирования команда контроля качества должна проверить правильность версий сборок.
Автоматизированное дымовое тестирование
Автоматизация тестирования используется для Регрессионное тестированиеОднако мы также можем использовать набор автоматизированных тестовых случаев для запуска в рамках дымового тестирования. С помощью автоматизированных тестов разработчики могут немедленно проверять сборку, как только она будет готова к развертыванию.
Вместо повторного тестирования вручную при каждом развертывании новой сборки программного обеспечения для этой сборки выполняются записанные сценарии дымового тестирования. Он проверяет, работают ли основные функции должным образом. Если тест не пройден, они могут исправить сборку и немедленно повторно развернуть сборку. Благодаря этому мы можем сэкономить время и обеспечить качественную сборку среды контроля качества.
Используя автоматизированный инструмент, инженер по тестированию записывает все ручные шаги, выполняемые при сборке программного обеспечения.
Цикл дымовых испытаний
Приведенная ниже блок-схема показывает, как выполняется дымовое тестирование. После развертывания сборки в QA и успешного прохождения дымовых тестов мы переходим к функциональному тестированию. Если дымовой тест не пройден, мы прекращаем тестирование до тех пор, пока проблема в сборке не будет устранена.
Рекомендации по разработке сценариев дымовых испытаний
Знать цикл — это одно; нужно продолжатьping Другой важный аспект – это комплекс мер, обеспечивающий его надежность. Комплект для дезинфекции дымом заслуживает своего места только тогда, когда он остается компактным, быстрым и воспроизводимым.
- Сначала составьте карту критических путей: Перечислите рабочие процессы, которые делают продукт пригодным для коммерческого использования, такие как вход в систему, поиск, ввод данных, оплата и выход из системы. Если какой-либо из них не работает, сборка теряет ценность для тестировщика.
- Номер должен быть неглубоким, но широким: Вместо того чтобы углубленно изучать один модуль, лучше один раз пройтись по каждому основному модулю. Граничные значения, отрицательные данные и формулировки сообщений об ошибках должны использоваться в функциональном тестировании, а не здесь.
- Ограничить время выполнения: Большинство команд проводят забег от десяти до пятнадцати минут, а количество участников в зале ограничивается примерно двадцатью-тридцатью минутами. контрольные примерыЗабег, который длится час, перестаёт быть препятствием и превращается в узкое место.
- При каждой сборке запускайте одни и те же тесты: Последовательность позволяет связать сбой с кодом, а не с изменением выбора тестов.
- Устраните нестабильные и сильно зависимые случаи: Случай, когда проверка проходит успешно, а затем завершается неудачей без каких-либо изменений в коде, подрывает доверие к системе. Заглушки или имитации нестабильных сторонних сервисов, где... фреймворк автоматизации тестирования позволяет.
- Вынести одно однозначное решение: В каждом случае необходимо ожидать хотя бы одного результата, чтобы сборку можно было принять или отклонить без обсуждения.
- Установите версию пакета с помощью сборки: Сохраняйте тестовые сценарии в том же репозитории, что и код приложения, чтобы параметры проверки всегда соответствовали тестируемой версии.
RevВ каждом релизе пересматривайте пакет программ: исключайте из рассмотрения случаи, когда функции больше не актуальны, и добавляйте новые, критически важные рабочие процессы.
Дымовое тестирование в конвейерах CI/CD
Разработанный таким образом набор тестов достаточно дешев, чтобы запускать его при каждом коммите, а именно этого требуют современные методы доставки. непрерывная интеграция сервер, например Jenkins Программа компилирует код, развертывает его в тестовой среде, а затем запускает тестовый набор в качестве первого автоматизированного этапа. Успешное завершение переводит артефакт на этапы функционального и регрессионного тестирования, а неудачное — завершает конвейер с ошибкой и уведомляет разработчика, внесшего изменения, в течение нескольких минут.
Обычно используются два варианта развертывания. Первый, перед слиянием, проверяет основную ветку, подтверждая каждый запрос на слияние, а второй, после развертывания, подтверждает доступность и правильную настройку развернутой среды. Команды, практикующие непрерывное развертывание, часто добавляют третий, сокращенный вариант развертывания в производственной среде сразу после релиза.
Поскольку конвейер выполняет набор тестов много раз в день, тестовые случаи должны быть неинтерактивными, самоочищающимися и независимыми. Любой случай, ожидающий решения человека или оставляющий тестовые данные, приведет к остановке конвейера.
Преимущества дымового тестирования
Вот несколько преимуществ, перечисленных для дымового тестирования.
- Простота в использовании и высокая скорость работы.
- Критические ошибки и дефекты легко обнаружить и исправить на ранних стадиях.
- Улучшает качество системы
- Снижает риск
- Прогресс легче оценить.
- Экономит усилия и время тестирования
- Минимизирует риски интеграции
⚠ Важное ограничение: Прохождение проверки работоспособности сборки (так называемый «проходной дымовой тест») лишь подтверждает её пригодность для тестирования. Основные функции затрагиваются поверхностно, поэтому мелкие дефекты, граничные случаи и редко используемые функции остаются скрытыми до проведения функционального и регрессионного тестирования. Никогда не следует рассматривать «зелёный дымовой тест» как признак отсутствия дефектов в сборке.
Дымовое тестирование против проверки адекватности против регрессионного тестирования
Все три запускаются после изменения кода, поэтому их часто путают. Они различаются по масштабу, глубине и вопросу, на который каждая из них отвечает.
Тестирование кода, проводимое в среде разработки для обеспечения корректности приложения перед передачей сборки в отдел контроля качества, называется «проверкой работоспособности» (Sanity testing). Это процесс, который проверяет, соответствует ли разрабатываемое приложение своим основным функциональным требованиям.
Тестирование работоспособности определяет завершение этапа разработки и принимает решение о том, передавать или не передавать программный продукт на дальнейший этап тестирования.
| ОСНОВА | ТЕСТИРОВАНИЕ ДЫМОМ | ПРОВЕРКА НА РАЗУМНОСТЬ | РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ |
|---|---|---|---|
| Объем | Широкая и мелководная | Узкий и глубокий | Широкий и глубокий |
| Ответ на вопрос | Достаточно ли стабильна эта сборка для тестирования? | Работает ли это конкретное решение? | Что-нибудь из того, что раньше работало, сломалось? |
| Последовательность | Во-первых, при каждой сборке | После успешного прохождения проверки на дымообразование | После проверки на адекватность |
| Типичная продолжительность | 10 до 15 минут | 30 до 60 минут | Hours до дней |
| Автоматизация подходит | Очень высоко | Умеренный, часто ручной режим | Очень высоко |
На практике они выполняются последовательно: дымовое тестирование для проверки работоспособности сборки, тестирование на корректность для подтверждения внесенных изменений и регрессионное тестирование, когда позволяет график.
Примеры примеров испытаний на дым
В таблице ниже представлен краткий набор данных по анализу дымовых потоков, по одной строке на каждый критический путь.
| Т.ИД | СЦЕНАРИИ ТЕСТИРОВАНИЯ | ОПИСАНИЕ | ЭТАП ИСПЫТАНИЯ | ОЖИДАЕМЫЙ РЕЗУЛЬТАТ | ФАКТИЧЕСКИЙ РЕЗУЛЬТАТ | статус |
|---|---|---|---|---|---|---|
| 1 | Действительные учетные данные для входа | Проверьте функцию входа в веб-приложение, чтобы убедиться, что зарегистрированный пользователь может войти в систему с именем пользователя и паролем. | 1.Запустите приложение 2.Перейдите на страницу входа. 3.Введите действительное имя пользователя. 4.Введите действительный пароль 5.Нажмите кнопку входа в систему. |
Вход должен пройти успешно | как и ожидалось | Проходить |
| 2 | Добавление функциональности элемента | Возможность добавить товар в корзину | 1.Выберите список категорий. 2.Добавьте товар в корзину. |
Товар должен быть добавлен в корзину | Товар не добавляется в корзину | Файл |
| 3 | Функция выхода из системы | Проверьте функцию выхода из системы | 1. выберите кнопку выхода | Пользователь должен иметь возможность выйти из системы. | Пользователь не может выйти из системы | Файл |
