2009-09-09 6 views
3

В настоящее время мы используем Fitness для тестирования подсистем. мы имеем много вопросов, с помощью инструмента, мало говоряFitnesse vs anyother tool test tool

  1. время разработки для написания Крепеж является более писать фактический код
  2. вопросы, связанные с проверкой в ​​из библиотек DLL, так что Qa может проверить их
  3. Проблемы запуска FitNesse для проекта, который использует NHibernate
  4. ограниченной онлайн помощь

Мы планируем использовать другой инструмент, чтобы сделать тестирование Несколько вариантов, которые мы знаем, являются

  1. SOAP UI
  2. рассказчиком

Я не уверен, будет ли у нас подобные проблемы с этими инструментами Было бы здорово знать, если кто-то имеет опыт используя этот инструмент и может направить нас

В нашем проекте мы приняли TDD, поэтому у нас есть Nuits для модульного тестирования. Было бы здорово, если бы кто-нибудь знал о инструментах/идеях, которые могли бы расширить nunits для тестирования подсистемы.

ответ

1

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

Структура, в которой я готовил хранимые тесты в виде файлов XML, с использованием простой разметки стиля xUnit. Затем xml-файлы были преобразованы в исполняемые тесты с использованием таблицы стилей. Я закончил преобразование тестов в Tcl/Expect, но вы могли превратить их во что угодно. Фактически, если вы хотите, вы можете преобразовать их на несколько языков, в зависимости от ваших потребностей.

Несколько люди любезно напомнили мне (так же, как вы напомните вам бедную dottering дедушка о слюне на подбородке), что мы находимся в 21 м века, когда они спросить, почему я выбрал бы Tcl через некоторые более современный язык. Как оказалось, для целей такого тестирования я еще не нашел лучшего выбора. Язык Tcl по-прежнему ногами в этой области. Поверьте мне, я однажды не проснулся и не сказал себе «что мне нужно, чтобы тестовая среда была реализована на языке сценариев, который все будут ненавидеть!»

Верьте или нет, я действительно искал инструмент, любой инструмент, который имел следующие характеристики:

  • Кроссплатформенность. Это не подлежит обсуждению. Мы делаем много кросс-платформенной разработки, и мы уже используем WAY слишком много инструментов, которые не поддерживают кросс-платформенную разработку.
  • Простой синтаксис. Скажите, что вы хотите о Tcl, но синтаксис очень обычный. Я знал, что некоторый собственный код, вероятно, ползет даже в XML-файлы (и первоначально это был только Tcl, без XML), и я хотел, чтобы синтаксис был понятным для не-программиста. Эта простота является основной прочностью Tcl. Как оказалось, это также упростило преобразование XML.
  • Бесплатно.Моя любимая цена ;-)
  • Письменные тесты как простые xml-файлы разрешали не-программистам писать тесты уровня приема клиентов - не требуется программирование.
  • Легко расширенный.

Я не отправлялся в дом, увеличивая это до такой степени, насколько я есть. Первоначально я рассматривал установленные тестовые рамки, такие как DejaGnu и android. В основном у них было слишком много функций. Они были настолько нагружены, что я не думал, что им будет легко начать проект без большого обучения. Глядя на DejaGnu, меня заинтересовал Tcl в целом, и после краткого взгляда на tcltest я почти сдался. Как DejaGnu, так и tcltest предполагают, что вы являетесь продвинутым скриптом Tcl, который я не думал, что кто-либо из моих компаний когда-либо будет. Кроме того, я хотел, чтобы платформа тестирования (если возможно) поддерживала xUnit-тип тестовой среды, и ни один из этих инструментов не выполнялся.

В конце концов я нашел TclTkUnit, платформу тестирования на основе Tcl, разработанную вдоль линий xUnit. Это был всего лишь короткий шаг логики, чтобы понять, что я могу запустить TclTkUnit в Expect вместо tclsh и получить все, что мне нужно.

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

В другом проекте нам нужна очень простая атмосфера sim/stim, чтобы подражать человеку, бросающему переключатели и нажав кнопки на части оборудования, которого у нас не было. Прошло всего несколько часов, чтобы взломать тестовую структуру для работы в качестве симулятора. Создание структуры заняло определенную работу, но мы чувствовали, что в долгосрочной перспективе это принесло пользу. Я действительно считаю, что эти типы непредвиденных последствий создания ваших собственных инструментов - это то, почему люди в гибком сообществе & XP, в частности, всегда были такими сильными сторонниками.

+0

У меня нет ничего против TCL, но FYI «Ожидающая» подобная семантика была перенесена на другие языки, например pexpect для Python (http://pypi.python.org/pypi/pexpect). – orip

+0

Вы использовали их недавно? В прошлый раз, когда я смотрел на это, у меня было достаточно проблем с надежностью, что я чувствовал, что они отрицательно повлияли на тест. Если тест не удался, я не хотел задаваться вопросом, где проблема: SUT или тестовая среда? Проблема для меня заключалась в том, что pyexpect или jexpect открывали открытые соединения сокетов. – DaveParillo

0

Мы используем модульные тестеры, такие как NUnit, для тестирования наших подсистемных тестов - тесты не волнуют, как они запускаются. Тем не менее, у него нет документального подхода к фитнесу.

+0

Итак, в Nunits, как вы убедились, что QA может запускать тесты с разными входами, один из способов, о которых я думал раньше, заключался в том, чтобы дать лист excel для ввода разных входных данных для запуска тестов; но это звучало слишком старомодно. Не могли бы вы сообщить мне, как это было достигнуто? – Balaji

3

Инструменты тестирования компонентов - это все функции вызова. Ваши тесты вызывают функции, которые вызывают в «светильниках», которые затем вызывают в SUT. Любой инструмент, основанный на этой предпосылке, столкнется с проблемами, о которых вы говорите выше.

Однако большинство из этих проблем являются управляемыми. Например, вы не должны писать много светильников. Если да, то что-то не так. Во-вторых, ваши светильники должны быть немного больше, чем код подключения для вызова API-интерфейсов в вашем приложении. Если ваши светильники выполняют значительную работу, то что-то не так.

В большинстве сред FitNesse количество светильников довольно мало. Например, существует более двухсот приемочных испытаний для самого фитнеса, но количество светильников в порядке порядка дюжины, и все они относительно просты.

Получить помощь на сайте [email protected] Люди, как правило, очень отзывчивы к вопросам.

1

Мы приняли подход, основанный на Fitnesse, но практически без кода, используя GenericFixture (google для Anubhava, чтобы найти его сайт Wordpress) для Fitnesse. Это позволяет нам создавать «исполняемые тестовые рассказы», ​​используя язык, дружественный к бизнес-стороне (в отличие от технической стороны). Этот язык, который очень легко определяется, практически без кодирования, в Generic Fixture, называется DSL (доменным языком). Поэтому мы можем написать наши тестовые рассказы, используя, например, медицинских терминов или даже на другом языке, кроме английского.В основном то, что мы получаем, превращает наши Случаи использования в исполняемые рассказы. Мы начинаем использовать его в большом проекте (15 чел. В течение 2 лет), и кажется (до сих пор) иметь хорошее будущее. Он легко позволяет Test Driven Development или создание тестов после разработки (традиционный подход). Это вики-основанная (Fitnesse), и ее функциональность по верстке и рефакторингу доказана до сих пор. Я могу дать больше информации, если кто-то заинтересован.

С уважением,

Aristotelis.

 Смежные вопросы

  • Нет связанных вопросов^_^