Что такое sanity тестирование
Smoke-тестирование
Согласно определению ISTQB Smoke-тестирование – это набор тестов, который охватывает основные функции компонента или системы, чтобы определить, правильно ли они работают, до начала запланированного тестирования.
Иными словами – это минимальный набор тестов, прохождение которых показывает, что продукт готов к дальнейшему тестированию. Smoke-тестирование можно также назвать «Проверкой сборки», так как с помощью Smoke-тестов мы проверяем работоспособность и стабильность сборки.
Преимущества Smoke-тестирования
У дымового тестирования много достоинств. Из самых важных:
Различие между Smoke, Sanity и Регрессионным тестированием.
Как выполняется смоук-тестирование
Smoke-тестирование выполняется при каждой новой сборке. Для этого определяется минимальный набор тест-кейсов для критически важного функционала. На этапе написания тест-кейсов определяют Priority и Severity кейса. В Smoke-прогон входят кейсы с Priority High и Severity Critical, как правило, это основные пользовательские сценарии, набор кейсов для проверок интеграционных модулей. К примеру, у нас в системе используются сторонние модули для скачивания документов, отображения карт, отправки писем, регистрации через интеграционную систему – эти кейсы добавлены в Smoke-прогон.
С помощью них проверяется их рабочее состояние и дается гарантия, что все критически важные функции работают правильно. Задача – проверить, подключен ли модуль, выполняет ли он свою основную функцию. К примеру, при проверке модуля скачивания документов нужно убедиться, что документ скачивается, а что конкретно в нем отображено – это проверка в рамках регресса. Исходя из Smoke мы поняли, что модуль в общей сборке корректен и подключен к системе.
Основная цель дымового тестирования – раннее обнаружение проблем в сборке. Если в сборке присутствуют ошибки, то дальнейшее тестирование будет лишь тратой времени и ресурсов.
Как правило Smoke-тестирование выполняется вручную, но если приложение обновляется часто и есть повторяющиеся от сборки к сборке текст-кейсы, то их можно автоматизировать для экономии времени и ресурсов.
Для выполнения сценариев удобнее всего пользоваться заранее составленным чек-листом, где описан процесс, ожидаемый результат и дана информация о результате прохождения. Последнее особенно важно фиксировать. Это даст понимание о том, что работает, а что нет. Только при положительном прохождении всех сценариев Smoke-тестирование считается успешно пройденным, а сборка передается далее на тестирование.
Если же обнаружены проблемы, то сборка отклоняется и передается обратно разработчикам для исправления. После внесения исправления тестировщик снова должен провести смоук-тестирование.
Все результаты Smoke-прогона тестировщики фиксируют в системе управления. На основании этой информации формируются диаграммы Smoke-прогона.
Пример Smoke-тестирования
Например, в тестируемом приложении есть следующие основные пользовательские сценарии:
Для такого приложения тестировщик в ходе Smoke-тестирования должен проверить все основные пользовательские сценарии. Например:
Заключение
Таким образом, Smoke-тестирование или проверка сборки проводится для того, чтобы до запуска продукта убедиться, что всё работает стабильно и отвечает требованиям заказчика. Оно проводится при каждой новой сборке. У этого вида тестирования много преимуществ: оно помогает заметить дефекты на раннем этапе, повысить качество системы и экономит время.
говориМ о тестировании
простым языком
Виды тестирования по целям: тестирование, связанное с изменениями
Именно после таких правок продукт необходимо снова протестировать. Давайте посмотрим, как именно это можно сделать.
Разработчики постоянно вносят изменения в код. И порой эти изменения могут не только принести пользу (например, исправить баг), но и добавить еще больше проблем и багов, причем в самых неожиданных на первых взгляд местах. Тоже самое можно сказать в отношении добавления новых фич в уже работающий продукт. Всегда есть вероятность, что новый код повлияет на уже существующий и добавит в нем новые баги.
Как же проверить все эти внесенные изменения? Давайте разбираться.
Существует несколько видов тестирования, связанного с изменениями:
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)
Направлено на определение соответствия выпущенной версии критериям качества для начала тестирования. По своим целям является аналогом дымового тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию.
Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.
Разница
Итак, на сегодняшний момент наши знания о видах тестирования выглядят следующим образом.
Что такое sanity тестирование
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Software Testing
Разделы портала
Про инструменты
Оригинальная публикация: http://habr.com/post/358142/
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:
Оба эти вида тестирования нацелены на то, чтобы избежать потерь времени и усилий, чтобы быстрее определить недостатки ПО и их критичность, а так же то, заслуживает ли оно перехода в фазу более углублённого и тщательного тестирования или же нет.
Для лучшего понимания ниже представлена сравнительная таблица этих понятий и области применения:
| Дымовые (Smoke) | Санити (Sanity) | Регрессионные (Regression) | Ре-тест (Re-test) |
|---|---|---|---|
| Исполняются с целью проверить что критически важные функциональные части AUT работают как положено | Нацелено на установление факта того, что определённые части AUT всё так же работают как положено после минорных изменений или исправлений багов | Подтверждают, что свежие изменения в коде или приложении в целом не оказали негативного влияния на уже существующую функциональность/набор функций | Перепроверяет и подтверждает факт того, что ранее заваленные тест-кейсы проходят после того, как дефекты исправлены |
| Цель — проверить «стабильность» системы в целом, чтобы дать зелёный свет проведению более тщательного тестирования | Целью является проверить общее состояние системы в деталях, чтобы приступить к более тщательному тестированию | Цель — убедиться что свежие изменения в коде не оказали побочных эффектов на устоявшуюся работающую функциональность | Ре-тест проверяет что дефект исправлен |
| Перепроверка дефектов не является целью Smoke | Перепроверка дефектов не является целью Sanity | Перепроверка дефектов не является целью Regression | Факт того что дефект исправлен подтверждает Re-Test |
| Дымовое тестирование выполняется перед регрессионным | Санитарное тестирование выполняется перед регрессионным и после smoke-тестов | Проводится на основании требований проекта и доступности ресурсов (закрывается автотестами), «регресс» может проводиться в параллели с ре-тестами | — Ре-тест выполняется перед sanity-тестированием — Так же, приоритет ре-теста выше регрессионных проверок, поэтому должно выполняться перед ними |
| Может выполняться автоматизированно или вручную | Чаще выполняется вручную | Лучший повод для автоматизации данного вида тестирования, т.к. ручное может быть крайне затратным по ресурсам или времени | Не поддаётся автоматизации |
| Является подмножеством регрессионного тестирования | Подмножество приёмочного тестирования | Выполняется при любой модификации или изменениях в уже существующем проекте | Ре-тест проводится на исправленной сборке с использованием тех же данных, на том же окружении, но с различным набором входных данных |
| Тест-кейсы часть регрессионных тест-кейсов, но покрывающие крайне критичную функциональность | Санитарное может выполняться без тест-кейсов, но знание тестируемой системы обязательно | Тест-кейсы регрессионного тестирования могут быть получены из функциональных требований или спецификаций, пользовательских мануалов, и проводятся вне зависимости от того, что исправили разработчики | Используется тот же самый тест-кейс, который выявил дефект |
Ну а по существу?
Приведу пример разграничения понятий на моём текущем проекте.
Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
Тогда можно сделать ряд утверждений о том, какие типы тестов нужно использовать в какой момент времени:
При этом, если это api принимает так же post-запросы, то очевидно что в другой набор тестов sanity нужно включить именно эти запросы. По аналогии с UI мы будем проверять все страницы приложения.
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.
Отличие Санитарного (Sanity Testing) от Дымового (Smoke Testing) видов тестирования
Санитарное или Санити тестирование (Sanity Testing)
относится к виду тестирования, которое используется с целью доказательства работоспособности конкретной функции или модуля согласно заявленным техническим требованиям. Зачастую санитарное тестирование используют для проверки какой либо части программы или приложения в результате внесенных изменений на нее со стороны факторов окружающей среды. Выполнение его обычно происходит в ручном режиме.
Дымовое или Смоук тестирование (Smoke Testing)
рассматривается в качестве короткого цикла тестов, которые выполняются с целью подтверждения факта запуска и выполнения функций устанавливаемого приложения после сборки нового или редактируемого кода. Результаты тестирования наиболее важных сегментов приложения должны предоставить объективную информацию о наличии или отсутствии дефектов в их работе. По итогам дымового тестирования приложения либо отправляется на последующее полное тестирование, либо делается вывод о необходимости его доработки.
Довольно часто в любительской среде разработчиков программного обеспечения можно встретить утверждения о том, что эти виды тестирования являются аналогами. На наш взгляд, подобные утверждения необоснованны, так как санитарное тестирование ориентировано на глубинное исследование определенной функции, а дымовое – на тестирование большого количества функционала за самые короткие сроки.
Тестирование в здравом уме | Тестирование программного обеспечения
Sanity Testing — это разновидность регрессионного тестирования. Проверка работоспособности выполняется, чтобы убедиться, что сделанные изменения в коде работают должным образом. Проверка работоспособности — это остановка, чтобы проверить, можно ли продолжить тестирование сборки. Во время процесса проверки работоспособности команда фокусируется на проверке функциональности приложения, а не на детальном тестировании. Проверка работоспособности, как правило, выполняется на сборке, где требуется немедленное развертывание, как исправление критической ошибки.
Функциональность Sanity Testing:
Основная функциональность проверки работоспособности заключается в том, чтобы определить, что изменения или предлагаемая функциональность работают так, как ожидалось. Если проверка работоспособности не пройдена, команда тестирования отклоняет программный продукт, чтобы сэкономить время и деньги. Он выполняется только после того, как программный продукт прошел тест на дым, и группа обеспечения качества приняла его для дальнейшего тестирования.
Пример проверки здравомыслия:
В проекте электронной коммерции основными модулями являются страница входа, домашняя страница, страница профиля пользователя, регистрация пользователя и т. Д. На странице входа имеется дефект, когда поле пароля принимает менее четырех буквенно-цифровых символов, а в требовании упоминается, что этот пароль поле не должно быть ниже восьми символов. Следовательно, дефект сообщается группой тестирования команде разработчиков для ее устранения. Затем команда разработчиков исправляет обнаруженный дефект и отправляет его на проверку. Затем команда тестирования проверяет, работают ли сделанные изменения нормально или нет. Также определяется, оказывает ли это влияние на другие связанные функции. Теперь есть функция обновления пароля на странице профиля пользователя. В рамках проверки работоспособности проверяется страница входа в систему, а также страница профиля, чтобы убедиться, что проверки работают нормально в обоих местах.
Особенности Sanity Testing:
Преимущества Sanity Testing: