Лекция
Привет, Вы узнаете о том , что такое дымовое тестирование, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое дымовое тестирование, smoke testing , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..
Понятие дымовое тестирование пошло из инженерной среды:
"При вводе в эксплуатацию нового оборудования ("железа") считалось, что тестирование прошло удачно, если из установки не пошел дым."
В области же программного обеспечения, дымовое тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.
Вывод о работоспособности основных функций делается на основании результатов поверхностного тестирования наиболее важных модулей приложения на предмет возможности выполнения требуемых задач и наличия быстронаходимых критических и блокирующих дефектов. В случае отсутствия таковых дефектов дымовое тестирование объявляется пройденным, и приложение передается для проведения полного цикла тестирования, в противном случае, дымовое тестирование объявляется проваленным, и приложение уходит на доработку.
Аналогами дымового тестирования являются Build Verification Testing и Acceptance Testing, выполняемые на функциональном уровне командой тестирования, по результатам которых делается вывод о том, принимается или нет установленная версия программного обеспечения в тестирование, эксплуатацию или на поставку заказчику.
Для облегчения работы, экономии времени и людских ресурсов рекомендуется внедрить автоматизацию тестовых сценариев для дымового тестирования.
Отличие санитарного тестирования от дымового (Sanity vs Smoke testing)
Smoke testing (Дымовое тестирование) | Sanity testing (Проверка работоспособности, санитарное тестирование) |
Выполняется на начальных сборках программного продукта перед регрессионным тестированием | Проводится на сборках, которые успешно прошли дымовые испытания и перед циклом регрессионного тестирования |
Тестируемая сборка может быть стабильной или нестабильной | Тестируемая сборка относительно стабильна |
Мотивом является проверка стабильности новой собранной версии продукта в целом | Основной целью является проверка рациональности системы в деталях, чтобы приступить к более тщательному тестированию |
Сбой при тестировании приводит к немедленному отказу от этой сборки программного обеспечения | Сбой в проверке работоспособности помещает сборку программного обеспечения в список отклоненных |
Может выполняться как разработчиками, так и тестировщиками | Обычно проводится тестировщиками |
Включает документацию и работу по сценариям | Не делает акцента на какой-либо документации и работу по сценариям |
Можно рассматривать как общий вид тестирования, поверхностно покрывающий все основные функции без глубокого тестирования | Специализированная или более детально ориентированная методика тестирования, направлена на определенную функциональность или функцию |
Может быть выполнено как автотестами, так и вручную | Обычно выполняется вручную |
Экономит усилия команды тестировщиков и минимизирует время работы над дефектной сборкой программного обеспечения | Сохраняет время в условиях, когда его недостаточно для максимально обширного регрессионного тестирования |
Дымовое тестирование, также известное как Build Verification Testing, является благом для разработки программного обеспечения, поскольку его можно использовать в качестве метода проверки, который может гарантировать стабильность и 100% работоспособность продукта.
Короче говоря, это самый простой доступный метод для тестирования всех функций приложения.
Давайте подробно рассмотрим процесс дымового тестирования.
Предположим, вы заказываете книгу на Amazon . Как только вы получите посылку, первое, что вы сделаете, - это убедитесь, что посылка адресована вам, а затем убедитесь, что посылка не повреждена и не порвана.
Далее , вы открываете пакет и увидеть книгу , что вы заказали , а также убедиться , что это новый, не старый.
Вы листаете страницы, чтобы убедиться, что все в порядке. Об этом говорит сайт https://intellect.icu . Правильно? Что ж, вы только что прошли дымовой тест на посылке.
Таким же образом, когда у вас есть программный продукт или мобильное приложение, вы проводите ряд базовых проверок, чтобы убедиться, что программное обеспечение или приложение готовы к тестированию. Этот вид тестирования, который проводится для того, чтобы убедиться, что сборка достаточно стабильна, чтобы пройти регрессионное и функциональное тестирование , называется Smoke Testing.
Представьте себе ситуацию, когда у вас есть команда тестирования, состоящая из 10 человек.
Теперь, когда сборка готова, все начинают тестирование. Может возникнуть ситуация, когда либо ожидаемых изменений кода в сборке нет, либо даже некоторые основные функции нарушены.
Не зная об этом факте, все 10 тестировщиков начинают тестировать приложение и выявляют дефекты для обнаруженных сбоев.
Теперь, в конце концов, команда разработчиков может вернуться и сказать, извините, что это неправильная сборка, или команда QA может остановить тестирование, заявив, что существует слишком много проблем.
Но опять же 10 человек уже потратили на это свои 8 часов, что означает потерю 80 часов продуктивности. Кроме того, если проблема была обнаружена раньше, команда разработчиков могла бы начать работу над ней и решить ее раньше.
Это причина, по которой нам нужно провести дымовой тест, прежде чем переходить к полноценному циклу тестирования.
Это помогает находить неисправности на ранних этапах жизненного цикла продукта.
Дымовое тестирование обычно занимает максимум 60 минут и должно проводиться для каждой новой сборки, каждого нового выпуска, даже если это означает ежедневное выполнение.
Когда продукт станет стабильным, вы можете даже подумать об автоматизации дымовых тестов и запуске его в конвейере CI. В конвейере CI / CD дымовой тест очень важен, потому что он предотвратит запуск нестабильной или сломанной сборки в производство.
Теперь, когда у нас есть представление о Smoke Testing, мы теперь поймем, какие сценарии необходимо включить в Smoke Testing. Читайте дальше, чтобы понять различные тестовые примеры и причину, по которой они являются частью набора Smoke Testing.
1) Проверка сборки : первым и самым важным шагом дымового теста является проверка сборки, номера сборки и доступности среды. Все усилия по тестированию будут потрачены впустую, если сборка неправильная.
2) Создание учетной записи : если ваше приложение предполагает создание пользователя, вам следует попытаться создать нового пользователя и проверить, успешно ли система позволяет вам это сделать. Это важный момент, который часто упускается из виду, поскольку тестировщики продолжают использовать старые учетные данные без тестирования для нового пользователя.
3) Вход в систему Выход : если это возможно в вашей SUT (тестируемая система), в рамках дымового теста вы должны попытаться успешно войти в систему со старыми и вновь созданными учетными данными. Также убедитесь, что вы можете успешно выйти из системы без каких-либо ошибок.
4) Критически важные для бизнеса функции : это очень важно. Для всех основных или критически важных функций мы должны провести простой тест, чтобы убедиться, что наиболее часто используемые функции не нарушены.
5) Сценарии интеграции: это самая важная часть дымового теста. Эффективность этой части зависит от понимания тестером интеграции системы. Например, если тестировщик знает, что какие-то данные текут из системы A в систему B, то он должен сделать это как часть дымового теста (любое значение 1). Это также делается для того, чтобы система не сломалась ни в одной из этих точек интеграции.
6) Добавить / изменить / удалить: данные всегда сохраняются в базе данных. Три основных операции в базе данных: добавление записи, редактирование записи и удаление записи. Таким образом, чтобы обеспечить надлежащее соединение с базой данных, в рамках дымового теста необходимо попытаться создать, отредактировать и удалить запись, которая применима в тестируемой системе.
7) Общая навигация: последняя часть - общая навигация. То есть нужно пройти через приложение, попытаться коснуться часто используемых функций и страниц, чтобы убедиться, что вся навигация работает должным образом.
1) Руководство
Обычно Smoke Testing выполняется вручную, чтобы убедиться, что навигация происходит плавно и не мешает функциональности.
Однако проведение дымовых испытаний может варьироваться от компании к компании в зависимости от требований.
Читайте также: Тестирование черного ящика - методы, примеры и типы
После завершения сборки программного обеспечения оно переходит в QA, где будут выполнены критически важные функциональные тестовые примеры.
В случае сбоя программное обеспечение будет отправлено команде разработчиков, чтобы можно было внести в него необходимые исправления.
После исправления программное обеспечение снова пройдет дымовые испытания и будет сравниваться со старой сборкой.
2) Автоматизация
Когда времени меньше и новая сборка готова к развертыванию, автоматизацию можно использовать для дымового тестирования.
Предварительно записанные тестовые примеры дыма могут быть запущены против сборки.
Если тест оказался неудачным, может быть сделано необходимое исправление, и программное обеспечение может быть развернуто в течение короткого промежутка времени.
Подготовка - установите предпочтительную атмосферу для теста, такую как копирование файлов, настройка сервера, установка лицензии и т. Д.
Получите необходимые документы - убедитесь, что все необходимые файлы, необходимые для запуска теста, находятся с вами.
Сценарий - убедитесь, что вы используете один сценарий для запуска тестов. После выполнения сценария убедитесь, что отчет был сохранен, чтобы в случае сбоя сборки о нем можно было сообщить разработчикам.
Обеспечьте чистую среду - остановите сервер, удалите файлы или даже очистите таблицы базы данных и т. Д. Убедитесь, что были предприняты все необходимые шаги для обеспечения запуска теста в чистой среде.
После того, как основная сборка программного обеспечения будет завершена, оно будет протестировано, чтобы определить, работает оно хорошо или нет.
Вся команда QA собирается вместе и обсуждает основные функции программного обеспечения, после чего будет проведен дымовой тест, чтобы выяснить его состояние.
Короче говоря, дымовой тест проводится в атмосфере разработки, чтобы убедиться, что сборка удовлетворяет требованиям.
Тестирование на работоспособность проводится для проверки того, что после исправления функциональные возможности работают правильно в соответствии с требованиями. Во время проверки работоспособности глубокое тестирование выполняться не будет.
Несмотря на то, что тестирование здравомыслия и дымовое тестирование могут показаться похожими, есть различия.
Дымовое тестирование.
Чтобы проверить критические функции
Проверить, работают ли новые функции или исправлены ошибки
Используется для проверки стабильности системы
Используется для проверки рациональности, чтобы перейти к более глубоким испытаниям
Выполняется как разработчиками, так и тестировщиками
Только для тестировщиков
Форма приемочного тестирования
Форма регрессионного тестирования
Сборка может быть стабильной и нестабильной при выполнении дымового тестирования
Относительно стабильна при выполнении проверки работоспособности
Все приложение протестировано
Критические компоненты проверены
Вывод
Если все пункты рассмотрены, вы можете быть уверены, что у вас есть готовый хороший набор для дымовых тестов.
Мы всегда должны помнить о том, что дымовой тест не должен длиться более 60 минут.
тестирование сборки , build verification test ,
санитарное тестирование , проверка согласованности , проверка исправности , sanity testing ,
Выводы из данной статьи про дымовое тестирование указывают на необходимость использования современных методов для оптимизации любых систем. Надеюсь, что теперь ты понял что такое дымовое тестирование, smoke testing и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.
Комментарии
Оставить комментарий
Качество и тестирование программного обеспечения. Quality Assurance.
Термины: Качество и тестирование программного обеспечения. Quality Assurance.