что такое смоук тестирование

Smoke-тестирование: назначение и примеры

Сразу после сборки программного обеспечения его нужно подвергать первичному смоук-тестированию. Эти меры направлены на быстрое выявление явных дефектов до того, как ПО будет отправлено на дальнейшее тестирование. Оперативное обнаружение ошибок на начальном этапе позволит значительно сократить время и трудозатраты на их исправление.

Что такое Smoke Tests? Это разработка минимального набора сценариев, с помощью которых тестируются базовые функции системы после каждой сборки. Другими словами, дымовое тестирование определяет, корректно ли был собран и установлен цифровой продукт. Если не сделать первичную проверку, то при наличии ошибок дальнейшие тесты будут лишней тратой времени. Если в ПО обнаружен дефект, оно сразу направляется на доработку, не проходя весь сложный цикл исследований.

Дымовые тесты исследуют стабильность системы. С помощью проверки можно определить, запускается ли программа, есть ли обратная связь с пользователем, открывается ли правильно интерфейс, выполняются ли основные функции системы.

Примером Smoke-тестов служат следующие сценарии проверки функциональности:

Дымовому тестированию можно подвергать как модернизированные продукты, так и только что выпущенные программы, которые ранее нигде не использовались. Приемочные испытания проводятся с высокой интенсивностью, поэтому проще и дешевле заказать их автоматизацию.

Достоинства дымового тестирования

Дымовая тесты конструируются таким образом, чтобы покрыть самые приоритетные функции системы. К преимуществам относятся:

Компания IBS AppLine реализует комплекс мер, направленных на проверку соответствия ПО требованиям заказчика и бизнес-задачам. Работа осуществляется в несколько этапов:

Дымовое тестирование значительно улучшает качество приложения. Оно направлено на проверку корректности переноса баз данных со старой версии на новую. Smoke-тесты контролируют корректность взаимодействия систем между собой.

IBS AppLine реализует масштабные проекты по улучшению качества программных продуктов. Наши специалисты обеспечивают максимальное тестовое покрытие нужных сегментов ПО и за короткое время проводят наиболее критичные проверки.

Источник

говориМ о тестировании
простым языком

Виды тестирования по целям: тестирование, связанное с изменениями

Именно после таких правок продукт необходимо снова протестировать. Давайте посмотрим, как именно это можно сделать.

Разработчики постоянно вносят изменения в код. И порой эти изменения могут не только принести пользу (например, исправить баг), но и добавить еще больше проблем и багов, причем в самых неожиданных на первых взгляд местах. Тоже самое можно сказать в отношении добавления новых фич в уже работающий продукт. Всегда есть вероятность, что новый код повлияет на уже существующий и добавит в нем новые баги.

Как же проверить все эти внесенные изменения? Давайте разбираться.

Существует несколько видов тестирования, связанного с изменениями:
1. Подтверждающее тестирование (Re-testing)
2. Регрессионное тестирование (Regression Testing)
3. Дымовое тестирование (Smoke Testing)
4. Санитарное тестирование (Sanity Testing)
5. Тестирование сборки (Build Verification Test)

Давайте разберем их более подробно.

Подтверждающее тестирование (Re-testing)

Подтверждающее тестирование направлено на проверку исправления бага. Суть его в том, что после исправление дефекта программное обеспечение может быть протестировано с использованием тестовых сценариев, которые завершились с ошибкой из-за найденного дефекта. То есть на новой версии программного обеспечения должны быть повторно выполнены шаги по воспроизведению сбоев, вызванных дефектом.

Целью подтверждающего тестирования является удостоверение в том, что найденный дефект был исправлен.

Предположим, что мы тестируем сайт. Положили товар в корзину, пробуем увеличить его количество, но ничего не выходит. Далее оформляем баг-репорт и отдаем разработчикам. Они его пофиксили и настает время для подтверждающего тестирование. Нам необходимо убедиться, что дефект пофикшен. Значит, как минимум, нам необходимо проверить, что баг не воспроизводится по тем шагам, которые указаны в баг-репорте. То есть продуем снова увеличить количество позиций товара в корзине и смотрим, увеличивается ли оно или снова нет.

Регрессионное тестирование (Regression Testing)

Код связан между собой и одно исправление может повлечь за собой новые проблемы. Если вернутся к примеру с корзиной, то окажется, что количество стало меняться, а вот цвет товара изменить теперь не получается.

Случилось это из-за того, что «цвет» и «количество» обращались к одному участку кода, который и был поправлен.

Получается, что изменение, внесенное в одну часть кода, будь то исправление или что-либо другое, может случайно повлиять на поведение других частей кода. Такие непреднамеренные побочные эффекты называются регрессиями. А, соответственно, регрессионное тестированиенаправлено на обнаружение таких непреднамеренных побочных эффектов.

Давайте представим это визуально.

Есть продукт. Он состоит из множества различных частей.

В одной из частей был баг и разработчик его исправил. То есть были внесены изменения в одну из частей программы (на рисунке выделено зеленым).

Данные изменения могли тем или иным образом отразиться и на работе других частей продукта. На рисунке выделено красным.

Либо может быть ситуация, когда в продукте появляется новый функционал. И его работа может повлиять на старый.

То есть нам нужно проверить работу старого функционала после исправления старого кода и/или написания нового. В этом и заключается регрессионное тестирование.

Получается, что при подтверждающим тестировании мы проверяем сам баг, а при регрессионным тестирование не вызвало ли исправление бага или написание нового кода каких-либо изменений в других местах.

Дымовое тестирование (Smoke Testing)

Дымовое тестирование — тестирование, проводимое на начальном этапе и, в первую очередь, направленное на проверку готовности разработанного продукта к проведению более расширенного тестирования.

Данный вид тестирования определяет общее состояние качества продукта.

Это короткий цикл тестов, подтверждающий (отрицающий) факт того, что приложение стартует и выполняет свои основные функции. Проверки практически всегда одинаковы и редко претерпевают изменениям. Поэтому целесообразно их автоматизировать.

Вывод о работоспособности основных функций делается на основании результатов поверхностного тестирования наиболее важных модулей приложения на предмет возможности выполнения требуемых задач и наличия быстро находимых критических и блокирующих дефектов. В случае отсутствия таковых дефектов дымовое тестирование объявляется пройденным, и приложение передается для проведения полного цикла тестирования, в противном случае, дымовое тестирование объявляется проваленным, и приложение уходит на доработку.

Данный тип тестирования позволяет на начальном этапе выявить основные быстро находимые критические дефекты.

Санитарное или Санити тестирование (Sanity Testing)

Относится к виду тестирования, которое используется с целью доказательства работоспособности конкретной функции или модуля согласно заявленным техническим требованиям.

Зачастую санитарное тестирование используют для проверки какой либо части программы или приложения в результате внесенных изменений на нее со стороны факторов окружающей среды. Выполнение его обычно происходит в ручном режиме.

Санитарное тестирование ориентировано на глубинное исследование определенной функции, а дымовое — на тестирование большого количества функционала за самые короткие сроки.

Тестирование сборки (Build Verification Test)

Направлено на определение соответствия выпущенной версии критериям качества для начала тестирования. По своим целям является аналогом дымового тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию.

Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.

Разница

Итак, на сегодняшний момент наши знания о видах тестирования выглядят следующим образом.

Источник

Дымовое и санитарное тестирование: понятия и характерные отличия

Обычно люди запутываются в значениях дымового и санитарного тестирования. Прежде всего, эти два понятия очень разные, да и QA выполняет их на разных этапах цикла тестирования.

Дымовое тестирование (англ. smoke testing)

Дымовое тестирование– это особый вид проверки программного обеспечения, направленный на тщательный анализ работоспособности разрабатываемого веб-продукта, а именно наиболее важных и критических моментов. Итоги подобных проверок применяются для того, чтобы понять, можно ли характеризовать созданное ПО как максимально стабильную сборку для последующего тестирования.

Выполнение дымового тестирования проводиться тогда, когда QA-отдел внутри компаний по обеспечению качества получает в работу новую версию ПО, изначально считая ее не до конца доработанной и исправной. При подобной проверке крайне важно убедиться в том, что все самые важные параметры тестируемого продукта функционируют корректно и согласно заявленным ожиданиям.

Философия подобного вида тестирования основывается на том, что тестировщики должны как можно ранее найти источник и причины возникновения багов и отклонить проверяемую версию на последующую доработку программистам.

Дымовые тесты очень важны, так как позволяют не проводить сложные проверки уже на стадии официального релиза, дабы не выпустить потребителям некачественное ПО.

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

Ключевые преимущества дымовых тестов

Санитарное тестирование (англ. sanity testing)

Санитарное тестирование – очень специфическая проверка работоспособности отдельных функциональных элементов, систем, веб-архитектур и расчетов. Она выполняется с единственной целью – дать 100% понятие того, что создаваемая система работает именно так, как того и требовалось.

Подобный тип тестирования нередко выполняется до старта полного цикла проведения регрессионных проверок, но только после окончания дымового тестирования.

Традиционно, санитарные проверки выполняются тогда, когда исправлен незначительный дефект внутри системы или ранее выполнялись работы по частичном редактировании логики работы ПО.

Как только изменения были внесены в код, новая сборка программного обеспечения передается на проверку в отдел тестирования. После установки сборки QA-специалисты могут выполнять эффективную проверку отредактированной функциональности вместо полной регрессии программного обеспечения, которое занимает существенно больше времени.

Если исправленные баги и редакции кода работают неверно, тогда тестировщик не имеет права принимать сборку на тест. Отметим, что любые дефекты, найденные на такой ранней стадии, смогут сэкономить массу времени на процессе проверки недоработанной сборки.

Ключевые особенности санитарного тестирования

Преимущества санитарного тестирования

Недостатки

Сравнение дымового и санитарного тестирования

Наглядные примеры использования данных тестов

Детально рассмотрим реальные примеры проведения подобных видов проверок на основе настоящих тестовых случаев.

Пример дымового тестирования

Допустим, в проверяемом ПО есть 5 модулей, а именно:

То есть, внутри данных модулей QA проводит тестирование, проверяя основную функциональность этих модулей, а точнее:

Пример санитарного тестирования

Снова представим, что есть 5 модулей:

При тестировании был найден дефект на странице авторизации. К примеру, поле для ввода пароля воспринимает комбинацию исключительно из 6 символов, что категорически не соответствует ТЗ, где указанно, что пароль может быть от 4 символов.

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

Но важно понимать, что при таком подходе тестируется только экстремальная функциональность модулей, нет никакого углубления в проверку деталей из-за отсутствия времени. Это и есть процедура санитарного тестирования.

Данные тесты проводятся только тогда, когда сборка ПО успешно прошла дымовые проверки и валидацию для последующих испытаний.

Источник

Smoke-тестирование

Smoke-тестирование – выполнение минимального набора тестов для выявления явных дефектов критичной функциональности.

Ироничное название этого вида тестирования происходит от быстрого способа проверки инженерами электроприборов: если при включении в розетку пошел дым – прибор требует доработки. Цель такого тестирования – проверить, что после очередной сборки программного продукта нет явных грубых дефектов. Как правило, данный вид тестирования проводится программистами.

Современные методологии разработки, практикуют подход непрерывной интеграции (Continuous Integration), который подразумевает частую сборку программного продукта. Сборки не всегда бывают надлежащего качества, и могут содержать дефекты в работе критичной для бизнеса функциональности, поэтому проверка должна осуществляться непосредственно после сборки и перед передачей на тестирование. Это позволяет сократить потерю времени на тестирование сборки, содержащей блокирующие дефекты.

Еще одно использование Smoke-тестов – это проверка интеграции между системами и корректности их переноса на новые стенды. А так же с целью определения корректности настройки взаимодействия между системами.

Перфоманс Лаб выполняет масштабные проекты по обеспечению качества программного обеспечения, в которых ключевое значение имеет регрессионное тестирование. Как правило, после того как тестовая модель для регрессионного тестирования, обеспечивающая оптимальное тестовое покрытие готова, мы сегментируем ее на части, в том числе выделяем набор тест-кейсов для smoke-тестирования, который позволяет за короткое время провести наиболее критичные тесты.

Обычно, наши проекты по smoke-тестированию состоят из следующих этапов:

Источник

QA evolution

Smoke testing

Это короткий цикл тестов, подтверждающий (отрицающий) факт того, что приложение стартует и выполняет свои основные функции. Данный тип тестирования позволяет на начальном этапе выявить основные быстро находимые критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать.

Пример smoke testing:

Если к примеру брать проект DI Tool STAR, то данный тип тестирования будет включать в себя проверку следующих функциональностей:
Login form (логин с валидными данными)
Log out form (клик по кнопке)
Property selection (проверка что функциональность есть и она работает)
Property Lists (что они есть, без сохранения/удаления)
Proceed to STAR
Menu (клик)
Views switching
Drawer (переключение табов, переключение кнопок внутри табов)
Export (срабатывание кнопки)
Header property selector
Favorites (проверка что функциональность есть и она работает)

Нужно определить какие задачи нужно достичь благодаря нашему приложению, какие очевидные шаги для достижения поставленной задачи, какие важные требования мы должны соблюдать и в какой последовательности.
Для этого создаем набор тестов. Набор тестов — это сгруппированная совокупность тестовых случаев, связанная определенным образом (к примеру, по функциональности).
Smoke-тесты созданы для того, чтобы проверить основную функциональность и должны быть неотъемлимой частью процесса тестирования. Они могут включать что-то простое, вроде “Могу ли я зарегистрироваться?”. Smoke-тестирование предполагает ответы ДА/НЕТ и все тест-кейсы должны быть пройдены с положительным результатом.
Smoke test должны быть быстрыми и легковесными, для того, чтобы их можно было запускать часто. В зависимости от специфика проекта, smoke test можно пройти как за несколько минут, так и за несколько часов.

Стоит понимать, что данный тип тестирования является видом тестирования продукта по глубине, а не просто видом тестовых испытаний. Как говорилось выше, данный тип тестирования определяет, пригоден ли продукт для дальнейшего, более полного тестирования. В случае, если он не проходит smoke testing — продукт необходимо отправить на доработку.
Обязательно необходимо записывать результаты прохождения теста. Это необходимо для того, чтобы сохранить записи того, что работает, а что нет. Можно разделить результаты на пройдено и провалено.
Пройдено: все отлично работает.
Провалено: не работает.

Источник