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

Фотография

2-й Слёт Тестировщиков В Москве


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

Опрос: 2-й слёт тестировщиков в Москве (22 пользователей проголосовало)

Укажите удобную дату сбора

  1. 29 сентября, суббота (13 голосов [59.09%])

    Процент голосов: 59.09%

  2. 6 октября, суббота (4 голосов [18.18%])

    Процент голосов: 18.18%

  3. другой день недели (2 голосов [9.09%])

    Процент голосов: 9.09%

  4. другая суббота (2 голосов [9.09%])

    Процент голосов: 9.09%

  5. готов в любой день (1 голосов [4.55%])

    Процент голосов: 4.55%

Голосовать Гости не могут голосовать

#61 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 02 октября 2007 - 08:35

А еще хотелось бы задать вопрос Алексею Баранцеву, который присутствовал на конференции, но не выступал: Михаил Давыдов во время своего выступления сказал, что model based testing не выходит за границы научных институтов и не используется в коммерческих организациях. Это действительно так?

Ну, я думаю, что Михаил несколько преувеличил, чтобы подчеркнуть "сложность" вопроса. Правильнее было бы сказать, что "не находит широкого применения в промышленности". Этой темой занимаются даже не столько научные институты, сколько исследовательские центры крупных промышленных компаний, таких как Microsoft, Ericsson, Nokia, Motorolla (да, в основном этим почему-то занимаются близкие к телекому комании, а не настоящие софтверные и не интеграторы). Но то, что коробочных продуктов таких практически нет -- это действительно суровая правда жизни.

А кроме того, можете почитать относительно недавнюю тему в блоге Хантера: http://blogs.msdn.co...singStates.aspx

Особенную ценность там представляет комментарий Шрини Калкарни, в котором он совершенно справедливо указывает, что с лёгкой руки Гарри Робинсона термин "model based testing" закрепился исключительно за тем видом тестирования, который можно было бы назвать "[finite state machine] model based test [design]ing". Тогда как в действительности круг моделей, которые можно использовать при тестировании далеко не ограничивается конечными автоматами.

Я с этим замечанием полностью солидарен, и как можно видеть из моей подписи, а также посмотрев наш сайт, мы практически нигде не заявляем, что мы занимаемся "model based testing".
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#62 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 02 октября 2007 - 08:45

А еще хотелось бы задать вопрос Алексею Баранцеву, который присутствовал на конференции, но не выступал: Михаил Давыдов во время своего выступления сказал, что model based testing не выходит за границы научных институтов и не используется в коммерческих организациях. Это действительно так?

Я некоторое время интересовался вопросом model-based тестирования, поэтому есть определенные соображения по этому поводу. Основная проблема данного подхода - трудоемкость описания всей модели. Фактически, нам нужно описать все (или большинство) состояний системы, определить для них переходы. С точки зрения реализации эта задача очень объемная и во всей модели очень легко запутаться. Соответственно затраты на внедрение и поддержку данного подхода могут просто не оправдать себя. И еще одна проблема - люди. Это хорошо, когда есть такой замечательный специалист, как Михаил Давыдов, который взялся это дело расколупать. Но в ксерокс же его не запихнешь, если нужно несколько знающих специалистов. Соответственно, надо бы брать других людей и доводить их знания до нужного уровня, а в случае кадрового голода и необходимости привлекать малоопытных людей, задача обучения усложняется на порядки. Поэтому, куда проще использовать любые другие подходы. Ту же декомпозицию, keyword-driven, object-based и т.п.

А вообще, по этому вопросу лучше либо поискать, либо создать тему в форуме "Автоматизированное тесторование", в которой бы вы смогли найти интересующий вас ответ.

P.S.: Заранее прошу прощения за то, что перехватил ответ на вопрос, адресованный Алексею Баранцеву касательно выступления Михаила Давыдова.
  • 0

#63 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 02 октября 2007 - 09:11

Основная проблема данного подхода - трудоемкость описания всей модели. Фактически, нам нужно описать все (или большинство) состояний системы, определить для них переходы. С точки зрения реализации эта задача очень объемная и во всей модели очень легко запутаться. Соответственно затраты на внедрение и поддержку данного подхода могут просто не оправдать себя.

Если модель получается аж сложнее реализации -- значит вы просто выбрали неправильную модель :)
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#64 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 02 октября 2007 - 09:28

Основная проблема данного подхода - трудоемкость описания всей модели. Фактически, нам нужно описать все (или большинство) состояний системы, определить для них переходы. С точки зрения реализации эта задача очень объемная и во всей модели очень легко запутаться. Соответственно затраты на внедрение и поддержку данного подхода могут просто не оправдать себя.

Если модель получается аж сложнее реализации -- значит вы просто выбрали неправильную модель :)

Вопрос не в модели, вопрос в объемах. У сложного приложения с множеством вариантов поведения проблемы с объемами неизбежны.
  • 0

#65 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 02 октября 2007 - 10:19

Модель стоит строить той степени детализации, которую Вы можете использовать в своих оракулах. Чем сложнее система - тем проще нужна модель. Пусть она и не будет учитывать все тонкости работы системы, но будет позволять пройтись по большей части функционала системы и выявить наиболее очевидные ошибки. Чисто прагматический подход...
  • 0
Best regards,
Майк.

#66 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 02 октября 2007 - 10:29

Основная проблема данного подхода - трудоемкость описания всей модели. Фактически, нам нужно описать все (или большинство) состояний системы, определить для них переходы. С точки зрения реализации эта задача очень объемная и во всей модели очень легко запутаться. Соответственно затраты на внедрение и поддержку данного подхода могут просто не оправдать себя.

Если модель получается аж сложнее реализации -- значит вы просто выбрали неправильную модель :)

Вопрос не в модели, вопрос в объемах. У сложного приложения с множеством вариантов поведения проблемы с объемами неизбежны.

Каким бы способом тесты не разрабатывались, они всё равно строятся на основании некоторой модели, даже если она нигде не зафиксирована, а существует только у тестировщика в голове. Проблема выбора модели для построения тестов актуальна всегда, независимо от степени автоматизации и/или формализации. Впрочем, можно даже шире взять -- эта проблема актуальна и не только для тестирования. Когда разработчик пишет код -- у него тоже модель в голове. И когда аналитик пишет требования -- тоже использует какую-то модель, которая сложилась у него на основании слов заказчика. И при увеличении сложности системы вполне логично, что растут и объёмы реализации, и сложность всех вообще моделей, которые используются аналитиками, разработчиками, тестировщиками и прочими иными. Поэтому говорить об абсолютных метриках не очень удобно. Тем более, что при тестировании как правило используются частные модели, описывающие отдельные аспекты, например только фукциональность или даже некоторую часть её, только защищенность, только производительность или отдельные характеристики производительность. Лучше сравнивать по-другому -- размер одной модели с размером другой модели, когда они описывают примерно одни и те же аспекты. Или не размер, а время на создание модели и поддержание её в актуальном состоянии при изменении требований. Михаил в своём докладе показал, мне кажется, весьма наглядно, что от способа организации архитектуры тестового хозяйства (а это тоже следствие выбора той или иной модели) сильно зависит, насколько тестовый набор получится расширяемым и сопровождаемым.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#67 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 02 октября 2007 - 10:54

Вообще, что-то мы не в том месте дискуссию затеяли... Если есть интерес -- предлагаю Михаилу выложить куда-нибудь доклад и открыть новую тему.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#68 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 02 октября 2007 - 11:10

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

Это понятно. Нужно искать баланс. Вопрос в том, сколько этих оракулов (ну и естественно, что брать за оракулы). Количество этих оракулов увеличивается прямо пропорционально возрастанию сложности системы. Я просто вел к тому, что сам движок, проводящий такое тестирование устроить несложно (возможно даже это одна из самых простых составляющих, если не самых интересных). Но для движка нужны ресурсы, а вот тут уже самая неприятность. Проблема, на мой взгляд, в том, что данный подход требует больших объемов описаний самих оракулов, их взаимосвязей, переходов и т.п., не говоря уже об обмене данными (хотя обходными путями это реализуется). Если взглянуть на это с точки зрения реализации в какой-то конкретной среде, то фактически эти ресурсы представляют собой определенные наборы програмного кода (классы, функции и прочее), которых может быть очень много и их взаимодействие трудно проследить по мере разрастания кода. Этому подходу очень сильно нужна визуализация представлений, причем с обеспеченным переходом между представлением и реализацией, а также по возможности между представлением и непосредственно приложением. Имеющиеся на данный момент средства автоматизации тестирования в полном объеме этого предоставить не могут (слишком уж специфичный подход). Соответственно, для нормальной работы с такими ресурсами при model-based подходе весьма полезным будет неслабое воображение.

Чтобы прочувствовать это в полной мере, попробуйте кому-то незнакомому с данным подходом показать некоторое работающее решение данного подхода применительно к конкретному приложению, при этом надо что-то добавить, что-то подкрутить. В такую систему будет достаточно сложно вникнуть даже опытному человеку. А тех же автоматизаторов с эффективным опытом не так уж и много, вы это понимаете. В основном приходится растить таких. Вот поэтому, я считаю, данный подход не получил широкого распространения в коммерческих структурах. Такой подход трудно реализовать, как минимум. Это уже не говоря о том, что его надо поддерживать вообще. Поэтому другие более простые и менее абстрагированные решения оказываются зачастую более эффективными (Не верите? Посмотрите на свои решения и представьте, как его же попытается реализовать команда "индусов", основной фичей которых является advanced level of Ctrl+C Ctrl+V).

Хотя подход сам по себе достаточно интересный. Я подумываю уже над тем, чтоб как-нить на досуге подобную системку скрутить (посмотрю на чем, может Java, может 4Test). Прикрутить бы к этому делу парочку хороших генераторов - и вообще бомба выйдет :crazy:
  • 0

#69 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 02 октября 2007 - 11:12

Вообще, что-то мы не в том месте дискуссию затеяли... Если есть интерес -- предлагаю Михаилу выложить куда-нибудь доклад и открыть новую тему.

Согласен. Так будет лучше
  • 0

#70 Mike

Mike

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 1 079 сообщений
  • Город:Москва

Отправлено 02 октября 2007 - 14:14

Доклад выложу в ближайшее время в Базе Знаний по Автоматизации.

По конференции:

К сожалению, мы с ch_ip готовили в последний момент, а потому на первые два доклада не успели (до сих кусаю себе локти, впрочем, надеюсь ещё попасть на семинар к Асхату).

По остальным докладам мои впечатления в общих чертах совпадают с таковыми Алексея Баранцева, кроме единственного пункта:

Докладчиков от Люксофт было ровно трое: Асхат, Лена и я :blush:. И особых success story у Люксофтовцев я не заметил. Там было скорее "У нас сделано так-то потому-то и потому-то" - это всё же не success story. Что касается сути Лениного доклада, то думаю его можно будет обсудить когда его (и все остальные доклады) опубликуют. Success story действительно звучали в других докладах, но не вижу в этом ничего плохого (хотя мне тоже интереснее слушать более насыщенные доклады).

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

Неформальная часть прошла отлично - хорошо посидели :rtfm: :).

Вообще, общее ощущение от конференции - "хорошо но мало". Надо повторить :crazy:
  • 0
Best regards,
Майк.

#71 Oldman

Oldman

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

  • Members
  • PipPipPipPip
  • 331 сообщений
  • ФИО:Александр

Отправлено 06 октября 2007 - 19:45

Доброго времени суток, уважаемые коллеги!

Огромное спасибо всем, кто посетил данное мероприятие.

Все материалы конференции (или ссылки на них) будут выложены на данном ресурсе http://sqa2conf.blogspot.com/

Организаторы мероприятия стараются по максимуму привести их в качественный вид.

Так что просим немного терпения и понимания.

А тем временем, можно ознакомиться со статистикой и отзывами о конференции и/или оставить свои, а также посмотреть/скачать презентации докладов.

-------------------------------------------------------------------------------------------
С уважением, организаторы II-й конференции специалистов по качеству ПО
  • 0


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

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