Как протестировать пользовательский интерфейс Eclipse Juno RCP

Мы разрабатываем RCP на основе Eclipse. Недавно мы обновились до Eclipse Juno, и в настоящее время мы сосредоточены на качестве, что, конечно, привлекло внимание к автоматическим тестам, поскольку приложение довольно большое, а усилия по тестированию задерживают выпуск релизов.

Мы уже пишем тесты JUnit, но меня больше интересуют тесты пользовательского интерфейса. С более старыми Eclipse это не будет проблемой. Вокруг полно хороших тестовых фреймворков. К сожалению, с Juno все изменилось из-за добавленной возможности переключать пользовательский интерфейс SWT по умолчанию с помощью Swing или JavaFX (по крайней мере, это то, что я понял об изменениях, вызывающих проблемы).

Таким образом, большинство тестовых инструментов больше не работают должным образом. Из прошлого опыта видно, что:

  • SWTBot, кажется, в последнее время не пользуется большой популярностью и очень нестабилен (не может найти элементы в некоторых версиях)
  • Window Tester кажется неплохим, но имеет много проблем с идентификацией элемента во время тестового запуска (особенно со всплывающими окнами, такими как помощь по содержимому или всплывающие подсказки).
  • Судя по всему, Froglogics Squish поддерживает Juno, но поскольку лицензия стоит около 2,5 тысяч евро, я должен пройти
  • Похоже, то же самое и с QF-Test (слишком дорого).
  • Остается Jubula (или GUIDancer, коммерческая Jubula), которую мы пробовали в прошлом, но у которой были такие же проблемы, как у Window Tester и SWTBot (нестабильная с точки зрения изменений в платформе Eclipse). и трудности с обнаружением некоторых элементов)

Мне нужно знать, на каком инструменте сосредоточиться / на каком доверять. Есть ли у кого-нибудь опыт работы с одним из инструментов или даже в настоящее время тестируется Juno RCP (или сама Juno, если на то пошло)? Или кто-нибудь знает, как Eclipse тестирует свою платформу (если они вообще это делают)?

Поиск информации, связанной с «тестом», «Juno» и «UI/GUI», выдает только коммерческие продукты.

Для меня важно найти инструмент, с помощью которого я смогу использовать разработанный тест-кейс даже в будущих выпусках, а это означает: Проект фреймворка, который имеет некоторую поддержку сообщества, чтобы иметь возможность быстро адаптироваться. Также важно также найти такие вещи, как всплывающие подсказки, оверлеи или помощь/предложения контента) — аналогично Selenium по сравнению с базовым HTMLUnit.

На данный момент я даже не слишком забочусь об интеграции, отчетности или соответствии стандартам.


person Peter Ilfrich    schedule 16.10.2012    source источник
comment
Очевидно, рынок с открытым исходным кодом не поддерживает узкоспециализированные RCP Juno, поэтому вам нужно использовать проприетарные инструменты.   -  person Peter Ilfrich    schedule 07.12.2012


Ответы (2)


Я бы посоветовал вам также взглянуть на Xored Q7, который используется для тестирования графического интерфейса некоторых из Проекты Eclipse, включая Eclipse DLTK, Eclipse LDT, Eclipse Tigerstripe, и этот инструмент просто идеален: он позволяет разрабатывать десятки тестов пользовательского интерфейса в день на одного инженера и не имеет проблем со стабильностью и неправильной записью. Он разработан специально и только для тестирования приложений на основе Eclipse и, очевидно, является лучшим в своей нише.

Однако это стоит денег, которые могут быть для вас блокировщиком (например, squish), но у них есть бесплатная версия сообщества, которой достаточно для большинства случаев использования. Как и те ребята из Xored, которые только что представили модель ценообразования с оплатой за выполнение тестов — инструменты будут бесплатными, и вам придется платить по мере их использования только за тесты, выполняемые ежемесячно (бесплатно менее 5000). Подробнее о новой модели можно прочитать здесь eclipse-testing.com.

person Andrey Platov    schedule 01.11.2012
comment
Я пробовал Q7 в течение нескольких часов. Обработка вспомогательного контента немного громоздка. Поведение иногда немного отличается от ручного выполнения. Я не смог найти хорошей документации по командам ECL, и мой основной визуальный редактор не мог быть правильно доступен. Он не использовал правильные координаты, указанные в скрипте, и операции перетаскивания также не могли быть выполнены. При записи и воспроизведении это работало, но при тестовом выполнении объект не сильно тянулся. Это несоответствие делает его практически невозможным для использования. - person Peter Ilfrich; 04.11.2012
comment
Привет @peter, Большое спасибо за отзыв. Я был слишком оптимистичен, распространяя слова о поддержке Juno, которая только что появилась и далека от идеала. Но команда будет рада работать с вами, чтобы устранить все несоответствия, если вы захотите связаться с нами и подробно указать на ошибки (например, поделиться своей AUT, если это возможно, и т. д.). Большое спасибо, и С уважением, - person Andrey Platov; 13.11.2012
comment
Попробовал последнюю версию на другом компьютере, и она работала хорошо. Большинство моих проблем решились. Есть некоторые шероховатости, но по сравнению с другими инструментами тестирования (такими как Squish) его легко использовать разработчику тестов. - person Peter Ilfrich; 07.12.2012

Вы можете найти исчерпывающую таблицу инструментов GUI-тестирования в Eclipse Wiki: http://wiki.eclipse.org/Automated_Testing#UI_tests

Одно важное решение, которое вы должны принять: хотите ли вы использовать мышь для записи/создания тестов (Jubula, QFTest, ...), хотите ли вы иметь возможность вручную писать тестовый код (SWTBot,... ), или если вы хотите иметь возможность делать и то, и другое (WindowTester Pro, ...).

Eclipse Juno довольно новый, и я ожидаю проблем со всеми перечисленными инструментами, однако миграция не должна занять много времени, так как большинство этих инструментов в основном ориентированы на тестирование SWT-виджетов, а Juno по-прежнему использует SWT. До сих пор я не слышал ни о каком приложении RCP, серьезно использующем JavaFX, кроме как для технических демонстраций, но мне было бы любопытно их увидеть!

Проблема, я думаю, скорее в том, что тестирование Eclipse сложно, а тестирование GUI особенно сложно. Возможно, вы захотите ознакомиться с этим исследованием, в котором выявляются и объясняются основные проблемы: http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2011-010.pdf

Если верить этому исследованию, JUnit-тестирование обычно предпочтительнее, чем GUI-тестирование. Что ж, с Juno у вас есть большое преимущество, заключающееся в том, что модульное тестирование Eclipse теперь проще, чем когда-либо, потому что фреймворк переключился с наследования и синглетонов на внедрение зависимостей, что делает его гораздо более тестируемым.

person Max Hohenegger    schedule 16.10.2012
comment
Спасибо, что поделились некоторыми знаниями. Я посмотрю исследование. Моя основная проблема только с тестированием Junit заключается в том, что сам интерфейс может быть очень сложным, что не позволяет нам собрать некоторые проблемы, которые могут возникнуть. Я знаю, что Juno довольно нов, и я надеюсь, что тестовые фреймворки догонят его. Однако, со всеми последними новостями/блогами/и т. д., к сожалению, я довольно скептически отношусь к быстрому улучшению установленных фреймворков. Но, по крайней мере, важно знать, что это вселенная, с которой мне приходится иметь дело. - person Peter Ilfrich; 17.10.2012
comment
Правда, помимо технических проблем очень много. Например, я предпочитаю WindowTester Pro, потому что он позволяет записывать тесты и генерирует код из записи. После этого вы можете удобно реорганизовать сгенерированный код и запустить его как тест JUnit из Eclipse. Однако в настоящее время Google затрудняет участие в проекте, а переход к первоклассному проекту Eclipse кажется медленным, что откладывает необходимую миграцию. - person Max Hohenegger; 17.10.2012