Подтвердить что ты не робот

Сравнение библиотек тестирования Swing UI: FEST, WindowTester Pro и т.д.

Я не пытаюсь дублировать такие вопросы, как этот:

Структура модульного тестирования для пользовательского интерфейса Swing

Что я хотел бы знать, есть ли у кого-нибудь хорошие сравнения для различных тестовых библиотек Swing Unit, таких как:

Мы никогда не проводили никаких графических тестов, поэтому мы не знакомы с ошибками, которые могут быть впереди.

Спасибо заранее.

4b9b3361

ОТВЕТЫ

Ответ 1

У меня был довольно хороший опыт работы с Abbot и FEST, обе библиотеки с открытым исходным кодом для тестирования Swing UI.

Аббат больше не поддерживается; было немного сложно попасть, потому что рекордер не генерировал сценарии "достаточно хорошо". Фактически, я использовал рекордер для "изучения" языка script (тегов XML), и я, наконец, сам написал скрипты простым текстовым редактором. Это работало довольно хорошо.

FEST использует другой подход, в котором вы должны кодировать (на Java) ваши тесты пользовательского интерфейса. Это делает его инструментом, зарезервированным для разработчиков Java, тогда как Abbot может использоваться другими людьми (например, тестерами QA Team).

Основные проблемы с обоими инструментами и, возможно, с любым инструментом тестирования пользовательского интерфейса:

  • чтобы найти способ идентифицировать компоненты уникально без использования их положения или текстового содержимого (которое может меняться от одной версии к другой или затрудняет тестирование одного и того же приложения в другом Locale),
  • использовать правильные сроки в сценариях: эти инструменты тестирования могут запускать ваш пользовательский интерфейс намного быстрее, чем пользовательский пользователь, поэтому ваш пользовательский интерфейс может быть недостаточно быстрым для них (например, может потребоваться несколько десятков мс до откройте диалог, еще больше, чтобы заполнить таблицу из базы данных)

Для обеих проблем есть решение, хотя.

Для идентификации компонентов я настоятельно рекомендую назвать все компоненты Swing (используя Component.setName()) в пользовательском интерфейсе и использовать для этого стратегию наименования , которая может гарантировать, что одновременно нет двух компонентов с одним и тем же именем. В библиотеке guts-gui я даже разработал стратегию, которая автоматически называет Swing components, которые хранятся в виде полей в панелях, это помогает добавлять имена компонентов после того, как приложение было закодировано.

Для времени script обе фреймворки принимают значение тайм-аута, ожидая появления диалогового окна; это зависит от вас, чтобы выбрать лучшее значение, учитывая факты, которые ваши тесты могут выполняться на разных машинах с более или менее доступной мощностью. Вы должны использовать тайм-аут, который достаточно велик, чтобы гарантировать, что script не будет сообщать о ложных негативах (например, диалог, который появляется после 1 секунды, тогда как script ждет только 500 мс), но также не слишком длинный, так что когда существует реальная ошибка (например, ожидаемый диалог никогда не появляется). Я предлагаю использовать таймауты от 2 до 5 секунд, которые должны соответствовать большинству платформ тестирования и большинства приложений.

Надеюсь, что это поможет.

Ответ 2

Jemmy обеспечивает достаточно хорошие возможности для тестирования пользовательского интерфейса. Хотя это не было бы идеальным решением для тестирования JUnit, его можно было бы легко расширить в соответствии с вашими потребностями.

Я не уверен в других инструментах тестирования UI, но по сравнению с RFT он предоставляет вам дескриптор фактического объекта пользовательского интерфейса (RFT возвращает прокси-объект). Это может быть полезно из моего опыта.

Это проект с открытым исходным кодом (лицензированный по CDDL) и активно разрабатывается.

Я думаю, что другой популярный (или раньше был) был jfcUnit. Хотя я не думаю, что это активно развивается.

Ответ 3

Есть много факторов, которые следует учитывать. Запись/Повтор, поддержка Unit test, Характер изменения кода, Лицензирование, Стоимость, поддержка нескольких платформ, Тестирование с множественным внешним видом, поддержка тестирования i18n... как выглядит ваш список?

Некоторые комментарии к инструментам, которые мы использовали.

IBM Rational Functional Tester:

У этого есть возможность записывать скрипты и воспроизводить. Он поддерживает точки проверки. Одним из самых больших плюсов является отсутствие необходимости изменения кода. RFT изменяет JVM и использует расширения доступности Java для записи и тестирования. Мы используем его в основном для Java (swing/awt с множеством операций 2D и диалогов). Он также работает с браузерами.

RFT предоставляет два механизма для идентификации элементов GUI. Один использует карту объектов. Это очень слабое и имеет проблемы с долговременной ремонтопригодностью. Использование API "Найти" более программируемо, хотя для этого требуется изменение кода. Иметь все объекты с правильным именем.

Совсем не подходит для модульного тестирования.

Работает с Windows и Linux.

Очень дорогостоящая плавающая лицензия находится в диапазоне 12000 долларов США, фиксированные лицензии будут стоить половину этого. Все узлы (запись тестов и выполнение тестов) нуждаются в лицензии. Цена приблизительная и старая, но она даст представление.

Требуется реальный сеанс GUI, на окнах. (Возможно, это нормально в linux с VNC)

Джеой:  Мы перешли на jemmy для нового тестирования. Поддерживает окна, linux. Раньше она была бесплатной, не уверен, что Oracle планирует на ней. Мы добавили наш тестовый слой поверх jemmy - для утверждений и других механизмов проверки. В этой презентации на jemmy testing toolkit 'есть более подробная информация о jemmy.