Какова добавленная стоимость от теста на дым? - PullRequest
6 голосов
/ 09 января 2009

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

Ответы [ 9 ]

9 голосов
/ 09 января 2009

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

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

5 голосов
/ 09 января 2009

Чтобы ответить на вопрос «что такое тест на дым?», Представьте, что вы тестировали образец электрического или электронного оборудования.

Подключите его и включите питание:

  • Вы видите, что он включается (например, экран или индикатор питания)? Хорошо!
  • Вы видите какой-нибудь дым , выходящий из него? Плохо!

И это все! «Тест на дым» - это минимальный тест: не строгий тест.

Значение «теста на дым» заключается в том, что он дешевый или экономически эффективен: например, за 1% стоимости полного теста он улавливает 90% наиболее вероятных ошибок. Например, на примитивной тостерной фабрике вы можете сделать:

  • Дорогое испытание первоначального проекта
  • Дорогое испытание по прототипу
  • Дорогое испытание первого изделия с линии массового производства
  • Дешевый тест на дым для каждого последующего изделия с линии массового производства

Я не уверен, какое место занимают "тесты на дым" в эти дни в разработке программного обеспечения, теперь, когда автоматизированное тестирование стало более популярным. В старые времена люди выступали за «ежедневную сборку» в качестве меры обеспечения качества (в частности, чтобы помочь с «непрерывной интеграцией») ... а затем выступали за «ежедневную сборку и тест на дымность » как способ лучше, чем просто ежедневная сборка (т. е. ежедневная сборка и проверяет, работает ли она вообще) ... но в наши дни лучше, чем это может быть "ежедневная сборка и обширный автоматизированный набор тестов" .

5 голосов
/ 09 января 2009

Если вы определяете тест на дым как «Выполните основные функции системы, чтобы убедиться, что они работают», то я думаю, что в этом есть смысл. Модульные тесты, хотя и необходимы, не все включено. Они не находят ошибок интеграции. Что касается автоматизации тестирования, мне еще предстоит увидеть систему, которая может быть полностью протестирована с помощью автоматизации, и даже если вы можете, такая автоматизация требует времени и усилий.

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

3 голосов
/ 09 января 2009

Мы проводим тестирование дыма там, где я работаю.

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

1 голос
/ 09 января 2009

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

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

1 голос
/ 09 января 2009

Проверка дыма определенно стоит усилий.

Вот отличная статья Стива Макконнелла под названием " Ежедневное тестирование сборки и дыма ". Именно это и привело меня к идее.

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

НТН

ура

Rob

1 голос
/ 09 января 2009

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

Общее правило: всегда дешевле найти проблемы как можно раньше .

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

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

1 голос
/ 09 января 2009

Я предполагаю, что ваше значение «теста на дым» такое же, как и у меня - то есть попытайтесь взорвать программу любым доступным способом.

Я понял ценность этого более 20 лет назад, когда я только что закончил (или так думал) основной кусок кода для редактора WYSIWYG. Я с гордостью показал это своему офисному товарищу (Эй, Дебл!), Который сказал: «Аккуратно!». Он немедленно создал абзац, содержащий около 1000 символов, скопировал его тысячи раз и создал документ размером около 32 МБ, удалил все, отменил его, и программа полностью взорвалась.

Я был в ужасе и сказал: «Ты не можешь этого сделать!». Он ухмыльнулся и сказал: «Почему бы и нет?»

Обнаружение и устранение проблемы (которую оказалось легко воспроизвести, когда вы узнали, как выглядят пороговые события) выявили небольшую и серьезную ошибку в управлении памятью. Простое тестирование нажатием кнопки никогда бы его не раскрыло.

Современным эквивалентом этого является Fuzz-тестирование (http://en.wikipedia.org/wiki/Fuzz_testing).. Оно не заменяет пошаговое тестирование требований, но часто выявляет проблемы, которых нет у других методов.

0 голосов
/ 17 марта 2009

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

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

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

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