Сообщений в теме: 6

[rlabs]

Возникла вот задача - автоматизированное тестирование GUI приложения, написанного на Java.

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

Я пока присматриваюсь к Abbot. Большинство остальных решений, как я понял, не поддерживают программирование тестов (только запись/воспроизведение макросов)

[barancev]

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

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

Из коммерческих, видимо, для тестирования Java GUI удобнее всего использовать IBM Rational Functional Tester, но это я говорю чисто теоретически, опыта его использования у меня нет.

Мне приходилось использовать два некоммерческих продукта для тестирования Java GUI -- Jemmy и Abbot. Причем в обоих тесты разрабатывались вручную с нуля, без предварительной записи.

Я лично отдаю предпочтение Jemmy, мне его API кажется наиболее удобным. Я даже затрудняюсь объяснить, почему. Он какой-то более объектно-ориентированный, что ли -- удобно организованная архитектура, легко расширяется для собственных элементов UI. Кроме того, там уже есть заготовленные средства для работы с элементами UI среды разработки NetBeans, а нам приходилось разрабатывать плагины для нее.

Однако, сейчас мы разрабатываем ПО также с использованием SWT, а не только Swing, поэтому постепенно начинаем использовать Abbot, так как у него, в отличие от остальных, есть поддержка и для того, и для другого. Мне Abbot не нравится, но жизнь заставляет.

[Dmitry_NJ]

Я пока присматриваюсь к Abbot. Большинство остальных решений, как я понял, не поддерживают программирование тестов (только запись/воспроизведение макросов)

С чего вы взяли? Запись это всего лишь вспомогательный инструмент, позволяющий существенно сократить время на разработку тестов. Также как визуальные редакторы в средах разработки позволяют существенно сэкономить время на выполнение рутинных операций при создание GUI приложения. Если вы предпочитаете лопату экскаватору, то это ваше право. Но в кабинете экскаватора есть и лопата. Если хотите писать весь код ручками, то прекрасно сможете это делать с теми же WR/QTP, Robot, SilkTest и пр. подобными инструментами.

[rlabs]

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

[...]

Однако, сейчас мы разрабатываем ПО также с использованием SWT, а не только Swing, поэтому постепенно начинаем использовать Abbot, так как у него, в отличие от остальных, есть поддержка и для того, и для другого. Мне Abbot не нравится, но жизнь заставляет.

Большле спасибо за столь развернутый ответ.
Разумеется, в первую очередь я смотрел на бесплатные продукты. Кроме того, нужна кроссплатформенность (нужно тестировать под Windows и как минимум под парой-тройкой *nix-систем).

До Jemmy я пока не добрался (впрочем, и по Abbot'у только документацию почитал), но вообще как раз их двоих и рассматривал как кандидатуры. Просто у меня не очень хорошо пока с тем, что называется "оценивать пригодность инструмента тестирования". А вообще, да, нам тоже нужно SWT/Swing приложение тестировать.

[rlabs]

С чего вы взяли? Запись это всего лишь вспомогательный инструмент, позволяющий существенно сократить время на разработку тестов. Также как визуальные редакторы в средах разработки позволяют существенно сэкономить время на выполнение рутинных операций при создание GUI приложения. Если вы предпочитаете лопату экскаватору, то это ваше право. Но в кабинете экскаватора есть и лопата. Если хотите писать весь код ручками, то прекрасно сможете это делать с теми же WR/QTP, Robot, SilkTest и пр. подобными инструментами.

Да ни с чего я не брал.
Просто по самому банальнейшему запросу в Google на одной из ссылок можно посмотреть список "хорошо известных" инструментов, и против каждого описание - "capture/playbak tool" или "programmaticaly.. ". смысл в том, что часть этих инструментов действительно умеет только записать и воспроизвести, и пригодна поэтому только для презентаций/демонстраций.

а кабинета в экскаваторе нет :-)

[Dmitry_NJ]

Просто по самому банальнейшему запросу в Google на одной из ссылок можно посмотреть список "хорошо известных" инструментов, и против каждого описание - "capture/playbak tool" или "programmaticaly.. "

Ну на заборе тоже написано. А там дрова...

а кабинета в экскаваторе нет :-)

Упс. Описка вкралась    Имелась в виду кабина экскаватора.

[barancev]

А вообще, да, нам тоже нужно SWT/Swing приложение тестировать.

На всякий случай (поскольку SWT и Swing написаны через слеш) для предотвращения недоразумений замечу, что это две совсем разные технологии разработки GUI от разных вендоров: AWT/Swing -- это технология Sun, входящая в их стандартный дистрибутив JDK, а SWT/JFace -- это технология IBM, разработанная в рамках проекта Eclipse и распространяющаяся как с Eclipse, так и самостоятельно.