Что значение добавляется от испытания с помощью дыма?
Моя ставка на разные определения столбцов
DECLARE @qrt VARCHAR(3);
vs
whatever is FROM FyQm f WHERE f.Quarter = @qrt
'Q2 ' with a blank or null probably does not equal f.Quarter which may be defined as VARCHAR(2)
Возможно, мы могли бы попробовать этот sql, чтобы увидеть, что каждый критерий имеет несколько строк
Select Sum(1) as cntAll ,Sum (CASE When c.Group = 'HR' Then 1 Else 0 End) as cntGroup ,Sum (CASE When c.bFlag IS NULL Then 1 Else 0 End) as cntbFlag ,Sum (CASE When s.Report IN ('P', 'N') Then 1 Else 0 End) as cntsReport ,Sum (CASE When CONVERT(VARCHAR(6), c.changedate, 112) IN ('200204', '200205', '200206') Then 1 Else 0 End) as cntchangedate ,Sum (CASE When c.GroupLabel = 'Hr43234' Then 1 Else 0 End) as cntGroupLabel FROM cforms c INNER JOIN spitems s ON c.Id = s.FormId[ 115] Может быть, пора последовать совету @scsimon и добавить обратно критерии по одному и посмотреть, какой из них блокирует все строки
-- WHERE c.Group = 'HR' -- AND c.bFlag IS NULL -- AND s.Report IN ('P', 'N') -- AND CONVERT(VARCHAR(6), c.changedate, 112) IN ('200204', '200205', '200206') -- AND c.GroupLabel = 'Hr43234'
9 ответов
Значение любого тестирования должно увеличить Вашу уверенность в реализации. Выполнение 'испытания с помощью дыма" этого вида здесь для увеличения уверенности, что это действительно становилось созданным правильно, и что нет никаких главных и смущающих ошибок, как UI не подойдет. Таким образом, это - в основном тест низкого усилия, чтобы подтвердить, что ничто действительно главное не пошло не так, как надо.
Это не может звучать очень полезным, но я видел, что в большой степени протестированный код приводит "испытание с помощью дыма" к сбою из-за, например, неожиданный отказ в сборке или поврежденном изображении. Обычно, когда это демонстрируется важному клиенту.
Отвечать на вопрос, "что такое испытание с помощью дыма?", предположите тестирование элемента электрического или электронного оборудования.
Включите его и включите питание:
- Вы видите, что он включает (например, экран или индикатор питания)? Хороший!
- Вы видите, что какой-либо дым выходит из него? Плохо!
И это - все! "Испытание с помощью дыма" является минимальным тестом: не строгий тест.
Значение "испытания с помощью дыма" - то, что это дешево, или экономически эффективно: например, для 1% стоимости полного теста это это ловит 90% наиболее вероятных ошибок. Например, на примитивной фабрике тостера Вы могли бы сделать:
- Дорогостоящий тест начального дизайна
- Дорогостоящий тест прототипа
- Дорогостоящий тест первого объекта от строки массового производства
- Дешевое, испытание с помощью дыма каждого последующего объекта от строки массового производства
Я не уверен, какое место "испытания с помощью дыма" имеют в эти дни в разработке программного обеспечения, теперь, когда автоматизированное тестирование стало более популярным. В былые времена люди защитили "ежедневную сборку", поскольку мера QA (а именно, для помощи с "непрерывной интеграцией")... и затем, защищенная "ежедневно создает и испытание с помощью дыма" как способ добиться большего успеха, чем просто ежедневная сборка (т.е. делает ежедневную сборку и проверяет, работает ли это вообще)..., но в эти дни, лучше, чем это могла бы быть "ежедневная сборка и обширный автоматизированный набор тестов".
При определении испытания с помощью дыма как "Пробегите основные характеристики системы, чтобы удостовериться, что они работают", затем я думаю, что существует значение в этом. Модульные тесты, в то время как необходимо не все включено. Они не находят ошибок интеграции. До автоматизации тестирования я должен все же видеть систему, которая может быть полностью протестирована с автоматизацией, и даже если Вы можете, такая автоматизация занять время и усилие выполнить.
В основном значение, которое я вижу в нем, позволяет, удостоверяются, что изменяется, мы сделали к коду, сегодня не повредил ничего, что работало вчера. В зависимости от того, насколько дисциплинированный Ваши методы кодирования, это - не всегда данный.
Мы делаем этот тип испытания с помощью дыма, где я работаю.
Большое значение - то, что мы можем удостовериться, что все части совмещаются перед переворачиванием его пользователям для тестирования приемлемости для пользователя. Приложение, что я думаю о жизнях на трех серверах, плюс, говорит с унаследованной системой. Удостоверение, что мы можем пробежать и что каждая часть может говорить с другими частями, что она должна, является легким и важным тестом.
Испытание с помощью дыма - то, потому что помещение поврежденного программного обеспечения в руке пользователей может быть чрезвычайно дорогостоящим: это может потратить впустую время многих людей, это может потребовать управления, встреч, и т.д. зафиксировать. Таким образом стоит провести определенное время для каждой сборки, к удостоверяется, что это не повреждается, может сохранить Вас много времени, если проблема когда-нибудь происходит.
Общее правило: всегда более дешево найти проблемы как можно раньше.
И, если Вы не попробовали его точно, как пользователь сделал бы, Вы не можете быть уверены, что это будет работать точно как он, должен. Всегда существуют неожиданные проблемы, которые только человек может поймать, например, визуальные проблемы, проблемы установки...
Таким образом автоматизированные тесты должны всегда дополняться (маленьким) ручным тестом, прежде, чем поместить портфель заказов пользователей.
Как любая лучшая практика, действительно необходимо верить в него для выполнения на, он - возвраты. Испытание с помощью дыма или Верификация Сборки должны делаться по крайней мере каждый день с каждой сборкой, или если у Вас нет ежедневной сборки, затем каждый день так или иначе, чтобы проверить, что Ваша среда произошла.
Знание, что способным из каждого дня цикла тестирования является преимущество. Если Вы не будете выполнять испытание с помощью дыма каждый день для тестирования основной возможности соединения или функциональности, то Вы не сможете сообщить, что Вы заблокированы при тестировании, и у группы разработчиков не будет того направления на том, что является самыми высокими приоритетными ошибками для фиксации.
Я рекомендовал бы зарегистрированную метрику временной шкалы Ваших испытаний с помощью дыма по сравнению с блокированием уровень выполнения теста и дефекты. Это может препятствовать тому, чтобы Вы были похожи на узкое место, и могло сохранить Ваше рабочее место, если кто-либо относится к Вам достаточно серьезно.
Испытание с помощью дыма определенно стоит усилия.
Вот превосходная статья Steve McConnell, позвонившего, "Ежедневно Создают и Испытание с помощью дыма". Это было тем, что представило меня идее.
Поскольку больше информации о Непрерывной Интеграции и ежедневных сборках смотрит на превосходное введение Martin Fowler к теме.
HTH
удачи,
Ограбить
Я предположу, что Ваше значение "испытания с помощью дыма" совпадает с моим - т.е. попытайтесь аварийно завершить программу всегда, Вы можете.
Я изучил значение этого 20 + несколько лет назад, когда я только что закончил (или таким образом, я думал), главная часть кода для WYSIWYG-редактора. Я гордо показал его своему коллеге (Эй Dbell!), кто сказал, "Аккуратный!". Он сразу создал абзац приблизительно с 1 000 символов в нем, скопировал его тысячи времен и создал документ приблизительно 32 МБ, удалил все, отменил его, и программа, абсолютно взорванная.
Я был полностью испуган и сказал, "Вы не можете сделать этого!". Он усмехнулся и сказал, "Почему нет?"
Нахождение и решение проблемы (который оказался легким копировать, после того как Вы знали то, на что были похожи пороговые события) раскрыли тонкую и серьезную ошибку в управлении памятью. Простое тестирование щелчка кнопки никогда не раскрывало бы его.
Современным днем, эквивалентным из этого, является Пух, тестирующий (http://en.wikipedia.org/wiki/Fuzz_testing). Это не замена для пошагового тестирования требований, но это будет часто выставлять проблемы, что никакой другой метод не будет.
По-моему, "Испытание с помощью дыма" незадолго до финальной версии, является ли выпуск пользователю или команде QA, абсолютно необходимо. Автоматизированное тестирование может только протестировать, а также сценарии были записаны, и всегда существует потенциал, что что-то будет пропущено.
Простой интерфейсный дефект мог испортить восприятие Вашего приложения к QA или пользователю и заставить их подозревать или подвергать сомнению фундаментальные основные компоненты. Без однажды прежде, чем выпустить его Вы открываете себя до восприятия Вашего программного обеспечения, как являющегося низким качеством только из-за некоторых небольших интерфейсных ошибок.