Comments 15
В бытность работы контактором Motorola работал над проектом по созданию инструментария для тестирования viewfinder (камара) в телефонах для платформы P2k. Мы изучали вопрос о том, что в конечном счёте будет лучше: создать собственную среду на основе бесплатной FitNesse или купить готовый продукт Stride от компании S2 software. Stride показал лёгкость в создании тестовых заданий и вызове низкоуровневых функций телефона, однако на тот момент он возвращал только значения функций. Для большинства функций работы с графикой на языке Си только 2 значения 0, если успешно и, как правило, 1 в противном случае. Нам же для того, чтобы удостовериться, что камера на телефоне отрабатывает корректно, необходимо было загружать полученные изображения и видео. За 2 месяца мы добились того, что наш проект на FitNesse позволял подгружать результат работы камеры сразу на ту же web страницу, где была тестовая таблица, и помещал в эту таблицу фотографию или видеоролик. Таким образом, можно было сразу посмотреть результат и нажать кнопку соответствует он ожидаемому или нет, а потом сохранить результаты тестирования. FitNesse оказался очень мощным инструментом для совместной разработки и тестирования даже в такой специфичной области, как разработка встроенного программного обеспечения.
Материал, безусловно, интересный. Такой вопрос: использовали ли вы это средство сами? Если да, то…
— Какие трудности ожидают при его разворачивании?
— Какие есть ограничения по функционалу?
— На каком принципе (на пальцах) можно тестировать интерфейс и поведение программы?
Как я понял, пишется набор классов, которые имитируют поведение пользователя. Далее, в методах классов что-то возвращается — это потом передается в вики?
— Как может средство сигнализировать о провалившихся тестах? Или я путаю с модульным тестированием, и в данном случае такого не требуется?
И в большей степени хотелось бы узнать о вашем или не вашем опыте применения в реальном проекте.
Спасибо.
— Какие трудности ожидают при его разворачивании?
— Какие есть ограничения по функционалу?
— На каком принципе (на пальцах) можно тестировать интерфейс и поведение программы?
Как я понял, пишется набор классов, которые имитируют поведение пользователя. Далее, в методах классов что-то возвращается — это потом передается в вики?
— Как может средство сигнализировать о провалившихся тестах? Или я путаю с модульным тестированием, и в данном случае такого не требуется?
И в большей степени хотелось бы узнать о вашем или не вашем опыте применения в реальном проекте.
Спасибо.
В догонку.
Я планирую начать масштабный проект на своей работе — базу данных. (Qt, MS Sql Server, NCReport/eXaro). Ищу подобные средства тестирования. Как быстро, по-вашему, я смогу интегрировать этот продукт в свою работу? Хватит ли, скажем, месяца, или требуется какая-то длительная доводка компонент?
Я планирую начать масштабный проект на своей работе — базу данных. (Qt, MS Sql Server, NCReport/eXaro). Ищу подобные средства тестирования. Как быстро, по-вашему, я смогу интегрировать этот продукт в свою работу? Хватит ли, скажем, месяца, или требуется какая-то длительная доводка компонент?
Интегрировать можно и за неделю, если проект только начинается. Больше всего времени займёт написание fixture для вашего кода. Хотя, если это будет делаться параллельно с самой разработкой, то процесс будет носить естественный характер и пойдёт быстрее. Я бы назвал оптимистичный сценарий в 2 недели. Неделю на изучение среды и неделю на внедрение в проект.
>Такой вопрос: использовали ли вы это средство сами?
Смотреть мой комментарий выше. Да использовал.
— Какие трудности ожидают при его разворачивании?
Особых трудностей нет. На сайте проекта есть подробное описание этого процесса. Понадобится только установить любой web server и запустить специальный батник. Обо всём этом на сайте fitnesse.org написано детально.
— Какие есть ограничения по функционалу?
Мне функционала хватало за глаза. Поэтому ограничения зависят от того как собираетесь использовать.
— На каком принципе (на пальцах) можно тестировать интерфейс и поведение программы?
Про это лучше всего написано на сайте fitnesse.org и в книге «Fit for Developing Software: Framework for Integrated Tests» by Rick Mugridge, Ward Cunningham
А на пальцах в любом случае необходима визуальная оценка человека, если речь идёт о графическом интерфейсе. Просто FitNesse позволяет сохранять результаты прогона теста для его дальнейшего анализа.
— Как может средство сигнализировать о провалившихся тестах? Или я путаю с модульным тестированием, и в данном случае такого не требуется?
Сигнализирует подкрашиванием соответствующих строк в таблице на страницах FitNesse.
С помощью FitNesse можно выполнять модульное тестирование.
И в большей степени хотелось бы узнать о вашем или не вашем опыте применения в реальном проекте.
Мой опыт рассказывать долго, а про не мой опыт в конце поста есть замечательная запись с конференции Google London Test Automation Conference (LTAC)
Смотреть мой комментарий выше. Да использовал.
— Какие трудности ожидают при его разворачивании?
Особых трудностей нет. На сайте проекта есть подробное описание этого процесса. Понадобится только установить любой web server и запустить специальный батник. Обо всём этом на сайте fitnesse.org написано детально.
— Какие есть ограничения по функционалу?
Мне функционала хватало за глаза. Поэтому ограничения зависят от того как собираетесь использовать.
— На каком принципе (на пальцах) можно тестировать интерфейс и поведение программы?
Про это лучше всего написано на сайте fitnesse.org и в книге «Fit for Developing Software: Framework for Integrated Tests» by Rick Mugridge, Ward Cunningham
А на пальцах в любом случае необходима визуальная оценка человека, если речь идёт о графическом интерфейсе. Просто FitNesse позволяет сохранять результаты прогона теста для его дальнейшего анализа.
— Как может средство сигнализировать о провалившихся тестах? Или я путаю с модульным тестированием, и в данном случае такого не требуется?
Сигнализирует подкрашиванием соответствующих строк в таблице на страницах FitNesse.
С помощью FitNesse можно выполнять модульное тестирование.
И в большей степени хотелось бы узнать о вашем или не вашем опыте применения в реальном проекте.
Мой опыт рассказывать долго, а про не мой опыт в конце поста есть замечательная запись с конференции Google London Test Automation Conference (LTAC)
Благодарю.
Что ж, буду сам изучать этот инструмент. Вы правы: не потыкав, на одних только рассказах, толком и не составишь представление о продукте. Однако ваш опыт использования так же интересен с человеческой точки зрения, а не только технической. Другими словами, было бы интересно почитать записки разработчика.
Что ж, буду сам изучать этот инструмент. Вы правы: не потыкав, на одних только рассказах, толком и не составишь представление о продукте. Однако ваш опыт использования так же интересен с человеческой точки зрения, а не только технической. Другими словами, было бы интересно почитать записки разработчика.
Описано действительно хорошо.
Я год назад этим делом пользовался краткосрочно. Почти что «поиграл». Потом надо было, собственно, работать, и пришлось перейти к обычным средствам тестирования.
Посмотрите, что Алексей Баранцев, программист-тестировщик, когда-то рассказывал о трудностях тестировщиков, которые пытались работать с FitNess.
Цитата:
Тестировщики попробовали пользоваться FIT – нет, не айс… Никакого fun нет.
Почему? Оказалось, что у них разной работы гораздо больше. Помимо unit testing и acceptance testing есть еще и интеграционное тестирование, где надо вглубь системы руки по локоть запускать, и FIT туда не влезает. Есть системное тестирование, условно говоря, его можно назвать acceptance testing, но FIT помогает только если у вас веб-приложение. Если вы зайдете на сайт FIT и посмотрите, какие там есть предопределенные, стандартные fuxtures — вы найдете fuxtures для JDBC и для веб-приложений. Всё!
А если у вас какие-то сложные протоколы, а если вам надо SMS обмениваться, если у вас нормальный обычный GUI-интерфейс — что вам делать? Нет, там не работает FIT, он doesn’t fit вообще!
Я год назад этим делом пользовался краткосрочно. Почти что «поиграл». Потом надо было, собственно, работать, и пришлось перейти к обычным средствам тестирования.
Посмотрите, что Алексей Баранцев, программист-тестировщик, когда-то рассказывал о трудностях тестировщиков, которые пытались работать с FitNess.
Цитата:
Тестировщики попробовали пользоваться FIT – нет, не айс… Никакого fun нет.
Почему? Оказалось, что у них разной работы гораздо больше. Помимо unit testing и acceptance testing есть еще и интеграционное тестирование, где надо вглубь системы руки по локоть запускать, и FIT туда не влезает. Есть системное тестирование, условно говоря, его можно назвать acceptance testing, но FIT помогает только если у вас веб-приложение. Если вы зайдете на сайт FIT и посмотрите, какие там есть предопределенные, стандартные fuxtures — вы найдете fuxtures для JDBC и для веб-приложений. Всё!
А если у вас какие-то сложные протоколы, а если вам надо SMS обмениваться, если у вас нормальный обычный GUI-интерфейс — что вам делать? Нет, там не работает FIT, он doesn’t fit вообще!
Само собой, что набор стандартных fixture не покрывает абсолютно все запросы абсолютно всех проектов. При «правильно прикрученных руках» можно заставить FitNesse и интеграционным тестированием заниматься. Мы заставили его тестировать встроенное ПО мобильного телефона, отвечающего за работу MEDL (Multimedia Engine Device abstraction Layer) — т.е. что ни на есть низкоуровневые тесты. Позже при дальнейшем создании fixture под нашу задачу мы сделали из него хороший инструмент для интеграционного тестирования. В статье, которую вы рекомендовали Алексей Баранцев основной упор делает на то, что его якобы «обманули» тем, что FitNesse может стандартным своим наполнением обеспечить весь спектр задач тестировщика. Так не бывает. Но критика должна быть конструктивной. Если вы говорите, что FitNesse — это ерунда, то предложите другое решение. Судя по статье Баранцева — альтернатива FitNesse — полностью всё делать самим с нуля. Но тогда получается, что если вам не нравиться ни один продукт современного автопрома, то вы лучше будете расстояния между городами покрывать пешком… Или изобретать собственный автомобиль (или велосипед)… Когда-то это оправдано, но чаще на этот нет ни времени и ни денег.
Прежде, чем ответить на критику моего негативного высказывания в адрес Fitnesse, мне было бы интересно узнать, какими другими инструментами автоматизации автор статьи пользовался в достаточном количестве, чтобы иметь возможность сравнивать их с Fitnesse не на учебных примерах, а «в полевых условиях»? И в чём конкретно Fitnesse у них выиграл? Тогда я хотя бы пойму, какое именно «другое решение» можно предложить, чтобы продолжить обсуждение различных «за» и «против».
Но, несмотря на мои личные предпочтения по части выбора инструментов, не могу не признать, что статья написана достаточно хорошо, так что мы с удовольствием опубликовали бы её и на нашем сайте, если автор не против.
Но, несмотря на мои личные предпочтения по части выбора инструментов, не могу не признать, что статья написана достаточно хорошо, так что мы с удовольствием опубликовали бы её и на нашем сайте, если автор не против.
Спасибо за материал.
Попробуем.
Попробуем.
по-моему, основное назначение fitnesse — это написание тестов со стороны технически неподкованного заказчика, который не очень разбирается во внутренностях системы, а вот внешние ожидания может накидать с помощью этих табличек.
уже после того как таблички с тестами составлены заказчиком и проверены QA, в дело вступают программеры, пишущие fixtures.
а вот использовать его для интеграционного тестирования, прогона юнит тестов и для ведения документации по проекту (wiki) — это, мне кажется, не совсем те задачи, для которых fitness будет лучшим решением.
основная идея (превращение вики-разметки в последовательность вызовов функций) в принципе очень хороша, но fitness сам по себе не настолько функционален, чтобы использовать его «для всего». вот как плагин к уже имеющимся сборщикам, баг тракерам, базам знаний (а-ля confluence) он смотрелся бы шикарно.
уже после того как таблички с тестами составлены заказчиком и проверены QA, в дело вступают программеры, пишущие fixtures.
а вот использовать его для интеграционного тестирования, прогона юнит тестов и для ведения документации по проекту (wiki) — это, мне кажется, не совсем те задачи, для которых fitness будет лучшим решением.
основная идея (превращение вики-разметки в последовательность вызовов функций) в принципе очень хороша, но fitness сам по себе не настолько функционален, чтобы использовать его «для всего». вот как плагин к уже имеющимся сборщикам, баг тракерам, базам знаний (а-ля confluence) он смотрелся бы шикарно.
основная идея (превращение вики-разметки в последовательность вызовов функций) в принципе очень хороша
Чем она так уж сильно лучше простого написания последовательности вызовов функций? Количество текста, который надо написать, совпадает практически один к одному. Среда написания табличек недружелюбная и не следит за отсутствием опечаток и других ошибок, которые в результате благополучно доживают до момента выполнения тестов. Да и вообще wiki-синтаксис не назовёшь сильно удобным.
Интересно выслушать мнение Джеймса Шора (который одно время был координатором проекта Fit): jamesshore.com/Blog/The-Problems-With-Acceptance-Testing.html
Sign up to leave a comment.
Автоматизация приёмочного тестирования или FitNesse для повышения качества программного продукта