Дымовое тестирование при ежедневной сборке
#1
Отправлено 02 января 2006 - 13:22
Перевод: Алексей Лемешко
Источник: Steve McConnell, Construx Software Builders, P.O. Box 6922, Bellevue, WA 98008.
E-mail: stevemcc@construx.com — WWW: http://www.construx.com/stevemcc/
Если Вы хотите создать простую компьютерную программу, которая состоит из одного файла, Вам просто необходимо собрать и связать весь написанный вами код в этот файл. На самом обычном проекте, которым занимается команда разработчиков, существуют сотни, даже тысячи файлов. Это «способствует» тому, что процесс создания выполнимой программы становится всё более сложным и трудоёмким: вы должны «собирать» программу из различных компонентов.
Практика применяемая, к примеру, в Microsoft и некоторых других компаниях, занимающихся разработкой ПО, заключается в ежедневной сборке (билдовании) программы, которая дополняется дымовым тестированием. Ежедневно, после того, как каждый файл собран (сбилдован, построен), связан (слинкован), и объединен в выполнимую программу, сама программа подвергается достаточно простому набору тестов, цель которых заключается в том, чтобы увидеть, «дымит» ли программа во время работы. Эти тесты и называются дымовыми (от англ. smoke — дым). Чаще всего этот процесс достаточно хорошо автоматизирован (или должен таким быть).
----------------------------
Другие статьи раздела "Тестирование"
#2
Отправлено 03 января 2006 - 09:58
Мне кажется, что редактирование с целью исправления таких ошибок должно быть обязательным и вряд ли вызовет "уход автора в себя".
Алексей, спасибо за перевод, статья интересная и понятная :) .
#3
Отправлено 03 января 2006 - 11:26
Наличие грамматических и пунктуационных ошибок портит впечатление от статьи (я говорю о своем личном впечатлении ;) ).
Мне кажется, что редактирование с целью исправления таких ошибок должно быть обязательным и вряд ли вызовет "уход автора в себя".
Примеры грамматических ошибок в студию. Я специально ещё раз выгрузил статью в ворд: у меня ничего не "подчёркивается".
Пунктуация вещь ещё между прочим и авторская, но и тут я готов рассмотреть примеры.
PS
По-моему кака-ято нездоровая традиция появляется побубнить про редактирование? Ладно бы если предметно.
Редактор портала www.it4business.ru
#4
Отправлено 03 января 2006 - 12:24
"Доведя проект до стабильного состояния раз, он будет оставаться стабильным всегда."
"Наблюдая, за тем, что продукт работает и с каждым днем обрастает все более новыми качествами и функциями, моральный дух разработчиков, по идее, должен расти и абсолютно не важно, что же именно должен делать этот продукт."
(возможно, это задумка автора, если он хотел сказать, что сам моральный дух наблюдает, но в этом предложении есть пунктуационные ошибки)
"достаточным для того, чтоб отслеживать не значительные дефекты" (незначительные)
Насколько я понимаю, статьи проходят через редактора, возможно, редактор ошибок не заметил, поэтому я позволила себе о них упомянуть. Ошибки мелкие, но, как мне кажется, в статье их вообще не должно быть.
#5
Отправлено 04 января 2006 - 10:47
Достаточно интересный подход для тестераЯ не лингвист, поэтому могла неверно определить вид ошибок (грамматические и т.д.), просто хотела подчеркнуть, что они не относятся к предметной области, а только к правилам языка.
"У вас неверное считается дискриминант"
"Да как же неверно, вот и вот..."
"Я могу не до конца понимать, что такое дискриминант, я не математик... но в ответе получается дробное число.. а у нас вроде только целые должны быть"
PS
Казалось бы и при чём тут дискриминант? :)
--------------------------------------------------------------------
За указанные логические неточности спасибо, сейчас что-то придумаем!
Редактор портала www.it4business.ru
#6
Отправлено 04 января 2006 - 10:57
Редактор портала www.it4business.ru
#7
Отправлено 06 января 2006 - 16:21
На двери кабинета такого разработчика весит соответствующая вывеска (висит)
А ворд не подчеркнул, потому что слово "весит" тоже есть.
#8
Отправлено 06 января 2006 - 18:21
Редактор портала www.it4business.ru
#9
Отправлено 09 января 2006 - 12:32
1. Zakazchik chasto menjaet ne tol'ko logiku programmy no i GUI.
avtomatizirovanye test skripty prihodit'sja perelopachivat'.
2. Sroki sdachi ne vyderzhivajut'sja ili sdaet'sja vse v poslednii den' i syrym.
t.e normal'noe funkzional'noe testirovanie ne vozmozhno provesti ne govorja o Integrazionnom Smoke Teste.
Kto nit' nashel protivojadie?
Ili nado idti dushit menedzherov proekta?
P.S. A pro kozlinye roga na dveri eto fishka!
A to "narod" ne znaet kak ih za spinoi klichat ;)
#10
Отправлено 10 января 2006 - 07:44
Например,
"билдование" - для меня более привычно (и более благозвучно, на мой взгляд) построение билдов;
или "дымовой тест" - слышал про дымовую шашку, но название теста, которым мы пользовались в тестовой лаборатории телевизионного завода еще в далекие 90-е был "тест на задымление".
Фраза "не будучи непрофессиональной" звучит не по русски (даже не по английски, у них нет двойных отрицаний). Лучше написать "будучи
профессиональной".
"не пишут код достаточно быстро" - тоже что и предыдущая фраза. Скорее, они пишут код достаточно медлено.
"Пока он не подчинит сборку" - получается, что он ее подчиняет-подчиняет, а она не подчиняется. Видно, недисциплинированная сборка попалась. Думаю, лучше написать "починит".
"(примеры взяты из реальных компаний, зачастую, всё проще)" - не понятно, к чему относиться фраза "зачастую, все проще". Смысл понятен, но фраза построена не корректно.
"Добавляйте ревизию в сборку"
Нельзя добавить ревизию в сборку, так как это разные понятия. Сборка - это набор скомпилированных и проверенных файлов, а "ревизия" - это действие по проверке чего-то. Ревизию можно осуществлять, а объектом ревизии может быть сборка.
Один небольшой совет всем, кто пишет статьи. Необходимо оценить свое творение "незаинтересованным" взглядом. В силу человеческой несовершенности это крайне трудно сделать сразу же после завершения работы. Профессиональные авторы всегда дают "вылежаться" своему материалу или читают его вслух кому-нибудь еще. Оба приема предназначены для того, что бы постараться воспринять свой текст "со стороны".
#11
Отправлено 10 января 2006 - 08:56
Кто-нибудь проводит ежедневные Smoke тесты и что входит в них, если можно, с конкретными примерами?
#13
Отправлено 10 января 2006 - 13:47
Редактор портала www.it4business.ru
#14
Отправлено 10 января 2006 - 13:52
А давайте по существу статьи?
Кто-нибудь проводит ежедневные Smoke тесты и что входит в них, если можно, с конкретными примерами?
Мы проводим, только не ежедневные а ежебилдовые. Билд три раза в неделю, если мы его не вернем. Прогоняются только Happy Path. То есть, без извратов - создать, отредактировать, просмотртеть, удалить.
На ежедневные у нас ресурсов просто не хватит
#15
Отправлено 10 января 2006 - 13:55
У нас (проект - интеграционная платформа для решений уровня BI) с помощью своей внутренней разработки (Testing Framework) автоматизирован набор тестов (на компонентном уровне), который прогоняется перед тем как сборка идёт в тестирование. В принципе Framework делает всё тоже самое что тестировщик вручную (создаёт и настраивает компоненты, выполняет тестовые прогоны dataflow, анализирует данные) только на достаточно логически простых схемах и источниках данных. Если набор таких тестов не проходит сборка не идёт в тестирование: это блокер.
Хорошо вам, у нас юнит тесты прогоняются тоже после каждой сборки, но когда доходит дело до пользовательского интерфейса и работы с БД :cry:
#16
Отправлено 10 января 2006 - 14:47
У нас тоже на 100% автоматизировано, но для понимания идёт ли дым самое оно.
Редактор портала www.it4business.ru
#18
Отправлено 10 января 2006 - 18:58
Редактор портала www.it4business.ru
#19
Отправлено 10 января 2006 - 19:02
Не сочтём. Спасибо, исправил.Не сочтите за занудство
Редактор портала www.it4business.ru
#20
Отправлено 11 января 2006 - 13:29
P.S. Заказчик - извращенец
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных