Перейти к содержимому

Тестирование веб-приложений 2.0
онлайн, начало 29 марта
Программирование на C# для тестировщиков
онлайн, начало 22 марта
Логи как инструмент тестировщика
онлайн, начало 25 марта
Тестирование производительности (JMeter)
онлайн, начало 22 марта
Фотография

Дымовое тестирование при ежедневной сборке


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 27

#1 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 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 — дым). Чаще всего этот процесс достаточно хорошо автоматизирован (или должен таким быть).

----------------------------
Другие статьи раздела "Тестирование"
  • 0

#2 eire

eire

    Новый участник

  • Members
  • Pip
  • 6 сообщений
  • Город:Kiev

Отправлено 03 Январь 2006 - 09:58

Наличие грамматических и пунктуационных ошибок портит впечатление от статьи (я говорю о своем личном впечатлении ;) ).
Мне кажется, что редактирование с целью исправления таких ошибок должно быть обязательным и вряд ли вызовет "уход автора в себя".

Алексей, спасибо за перевод, статья интересная и понятная :) .
  • 0

#3 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 03 Январь 2006 - 11:26

Наличие грамматических и пунктуационных ошибок портит впечатление от статьи (я говорю о своем личном впечатлении ;) ).
Мне кажется, что редактирование с целью исправления таких ошибок должно быть обязательным и вряд ли вызовет "уход автора в себя".


Примеры грамматических ошибок в студию. Я специально ещё раз выгрузил статью в ворд: у меня ничего не "подчёркивается".

Пунктуация вещь ещё между прочим и авторская, но и тут я готов рассмотреть примеры.

PS
По-моему кака-ято нездоровая традиция появляется побубнить про редактирование? Ладно бы если предметно.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#4 eire

eire

    Новый участник

  • Members
  • Pip
  • 6 сообщений
  • Город:Kiev

Отправлено 03 Январь 2006 - 12:24

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

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

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

"достаточным для того, чтоб отслеживать не значительные дефекты" (незначительные)

Насколько я понимаю, статьи проходят через редактора, возможно, редактор ошибок не заметил, поэтому я позволила себе о них упомянуть. Ошибки мелкие, но, как мне кажется, в статье их вообще не должно быть.
  • 0

#5 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 04 Январь 2006 - 10:47

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

Достаточно интересный подход для тестера :victory:

"У вас неверное считается дискриминант"
"Да как же неверно, вот и вот..."
"Я могу не до конца понимать, что такое дискриминант, я не математик... но в ответе получается дробное число.. а у нас вроде только целые должны быть"

PS
Казалось бы и при чём тут дискриминант? :)

--------------------------------------------------------------------

За указанные логические неточности спасибо, сейчас что-то придумаем!
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#6 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 04 Январь 2006 - 10:57

Указанные вами неточности я поправил, спасибо.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#7 Nadezhda

Nadezhda

    Активный участник

  • Members
  • PipPip
  • 81 сообщений
  • Город:Харьков

Отправлено 06 Январь 2006 - 16:21

Еще:
На двери кабинета такого разработчика весит соответствующая вывеска (висит)
А ворд не подчеркнул, потому что слово "весит" тоже есть. :victory:
  • 0

#8 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 06 Январь 2006 - 18:21

Исправил, спасибо :)
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#9 astik

astik

    Активный участник

  • Members
  • PipPip
  • 79 сообщений
  • Город:Deutschland

Отправлено 09 Январь 2006 - 12:32

V provedenii Smoke Testa, my stalknulis' s takimi trudnostjami

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 ;)
  • 0

#10 Green

Green

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 10 Январь 2006 - 07:44

Не сочтите за занудство, но некоторые применяемые термины "режут ухо" (а как вам такой критерий оценки :crazy: ).

Например,
"билдование" - для меня более привычно (и более благозвучно, на мой взгляд) построение билдов;
или "дымовой тест" - слышал про дымовую шашку, но название теста, которым мы пользовались в тестовой лаборатории телевизионного завода еще в далекие 90-е был "тест на задымление".

Фраза "не будучи непрофессиональной" звучит не по русски (даже не по английски, у них нет двойных отрицаний). Лучше написать "будучи
профессиональной".

"не пишут код достаточно быстро" - тоже что и предыдущая фраза. Скорее, они пишут код достаточно медлено.

"Пока он не подчинит сборку" - получается, что он ее подчиняет-подчиняет, а она не подчиняется. Видно, недисциплинированная сборка попалась. :good: Думаю, лучше написать "починит".

"(примеры взяты из реальных компаний, зачастую, всё проще)" - не понятно, к чему относиться фраза "зачастую, все проще". Смысл понятен, но фраза построена не корректно.

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

Один небольшой совет всем, кто пишет статьи. Необходимо оценить свое творение "незаинтересованным" взглядом. В силу человеческой несовершенности это крайне трудно сделать сразу же после завершения работы. Профессиональные авторы всегда дают "вылежаться" своему материалу или читают его вслух кому-нибудь еще. Оба приема предназначены для того, что бы постараться воспринять свой текст "со стороны".
  • 0
Гринкевич Сергей

#11 Лена

Лена

    Активный участник

  • Members
  • PipPip
  • 100 сообщений
  • ФИО:Елена

Отправлено 10 Январь 2006 - 08:56

А давайте по существу статьи?
Кто-нибудь проводит ежедневные Smoke тесты и что входит в них, если можно, с конкретными примерами?
  • 0

#12 Svetikk

Svetikk

    Активный участник

  • Members
  • PipPip
  • 80 сообщений
  • ФИО:Светлана
  • Город:Днепропетровск, Украина - San Francisco, CA, USA

Отправлено 10 Январь 2006 - 11:31

А давайте по существу статьи?
Кто-нибудь проводит ежедневные Smoke тесты и что входит в них, если можно, с конкретными примерами?

Просмотр сообщения


Мы пользуемся. У нас - это что-то среднее между приемочным и регрессионным тестированием.
  • 0

#13 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 10 Январь 2006 - 13:47

У нас (проект - интеграционная платформа для решений уровня BI) с помощью своей внутренней разработки (Testing Framework) автоматизирован набор тестов (на компонентном уровне), который прогоняется перед тем как сборка идёт в тестирование. В принципе Framework делает всё тоже самое что тестировщик вручную (создаёт и настраивает компоненты, выполняет тестовые прогоны dataflow, анализирует данные) только на достаточно логически простых схемах и источниках данных. Если набор таких тестов не проходит сборка не идёт в тестирование: это блокер.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#14 Guriy

Guriy

    Опытный участник

  • Members
  • PipPipPipPip
  • 316 сообщений
  • Город:Киев, Украина

Отправлено 10 Январь 2006 - 13:52

А давайте по существу статьи?
Кто-нибудь проводит ежедневные Smoke тесты и что входит в них, если можно, с конкретными примерами?

Просмотр сообщения


Мы проводим, только не ежедневные а ежебилдовые. Билд три раза в неделю, если мы его не вернем. Прогоняются только Happy Path. То есть, без извратов - создать, отредактировать, просмотртеть, удалить.
На ежедневные у нас ресурсов просто не хватит :crazy:
  • 0

#15 Guriy

Guriy

    Опытный участник

  • Members
  • PipPipPipPip
  • 316 сообщений
  • Город:Киев, Украина

Отправлено 10 Январь 2006 - 13:55

У нас (проект - интеграционная платформа для решений уровня BI) с помощью своей внутренней разработки (Testing Framework) автоматизирован набор тестов (на компонентном уровне), который прогоняется перед тем как сборка идёт в тестирование. В принципе Framework делает всё тоже самое что тестировщик вручную (создаёт и настраивает компоненты, выполняет тестовые прогоны dataflow, анализирует данные) только на достаточно логически простых схемах и источниках данных. Если набор таких тестов не проходит сборка не идёт в тестирование: это блокер.

Просмотр сообщения


Хорошо вам, у нас юнит тесты прогоняются тоже после каждой сборки, но когда доходит дело до пользовательского интерфейса и работы с БД :cry:
  • 0

#16 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 10 Январь 2006 - 14:47

UNIT-ы это часть процесса сборки. Без них и сборка не сборка :)
У нас тоже на 100% автоматизировано, но для понимания идёт ли дым самое оно.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#17 Mila

Mila

    Постоянный участник

  • Members
  • PipPipPip
  • 192 сообщений
  • Город:Санкт-Петербург

Отправлено 10 Январь 2006 - 18:02

UNIT-ы это часть процесса сборки. Без них и сборка не сборка :)
У нас тоже на 100% автоматизировано, но для понимания идёт ли дым самое оно.

Просмотр сообщения


Т.е. получается smoke-тесты и юнит-тесты у вас практически одно и тоже? (или у меня уже граматический заскок? :crazy: )
  • 0

#18 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 10 Январь 2006 - 18:58

Почему? Unit-тесты это тесты, которые выполняются на уровне кода и должны гарантировать сборку модулей - unit-ов. А дымовые тесты это по-сути интеграционные тесты, которые гарантируют работоспособность модулей в интеграции - то есть функционируют.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#19 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 10 Январь 2006 - 19:02

Не сочтите за занудство

Не сочтём. Спасибо, исправил.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#20 stakanoff

stakanoff

    Новый участник

  • Members
  • Pip
  • 18 сообщений

Отправлено 11 Январь 2006 - 13:29

Мы проводим. Каждый день. Ессно прогоняются юнит-тесты во время сборки, ну и тестировщики выполняют функциональное тестирование на дым. А всё для того, чтобы заказчик радовался прогрессу работы над проектом.
P.S. Заказчик - извращенец
  • 0


Инструменты тестировщика: Командная строка
онлайн
Практикум по тест-дизайну 2.0
онлайн
Программирование на Phyton для тестировщиков
онлайн
Тестирование производительности (JMeter)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале