CC BY
21
УДК 004.416.2
П. А. Садовников, А.Ю. Дроздов, Ю.Н. Фонин
Дизайн-центр Московского физико-технического института (государственного университета)
Jubula: инструмент для автоматического тестирования графического интерфейса Java-приложений
Данная статья рассказывает об опыте применения системы тестирования графического интерфейса Eclipse. В ней приводится перечень свойств, которыми должен обладать инструмент для проверки GUI, а также обзор нескольких подобных инструментов. Большая часть статьи посвящена устройству и особенностям Jubula, самой продвинутой и неординарной системы из кандидатов. Рассмотрены способы хранения и проведения тестов, отображение их результатов, а также возможности интеграции отладочной среды с другими средствами сопровождения программ. В конце приводится заключение, в каких случаях лучше использовать этот инструмент.
Ключевые слова: тестирование, автоматизация, графический интерфейс, GUI, Java.
P. A. Sadovnikov, A. Yu. Drozdov, Yu.N. Fonin
Design Center of the Moscow Institute of Physics and Technology
Jubula: instrument for automated Java-application's GUI
testing
This article relates an experience of using the environment for automated testing of Java-application's graphical interface. At the beginning a list of necessary properties, an instrument for GUI testing and a review of several similar instruments are provided. Most of the article is devoted to intrinsic organisation and features of Jubula, the most advanced and extraordinary system among the candidates. Means of keeping and conducting tests, displaying their results and other testing tools integration capabilities are examined. In conclusion, it is shown in which cases one should use this instrument.
Key words: testing, automatisation, graphical interface, GUI, Java. Введение
Сложно переоценить важность тестирования кода. Действительно, если отвечающий за функциональность код не работает или работает не по спецификациям, то пользователь не будет пользоваться продуктом, каким бы красивым не был интерфейс. Провалившая тестирование производительности программа тоже вряд ли порадует заказчика.
Однако код, который хорошо выполняет своё назначение в лабораторных условиях, ещё не достаточен для работы приложения в целом. Следующая ступень - тестирование графической надстройки над логикой. Разумеется, эту проверку тоже следует автоматизировать.
На этом этапе отлавливаются:
• грубые ошибки: отсутствие, недоступность или полная неработоспособность некоторых элементов,
• исключения при передаче данных от графического интерфейса к логике: отсутствие валидации данных, искажение или потеря информации,
• ошибки локализации: неправильные надписи,
• удобство использования: перегруженность элементами, нечитаемый шрифт, неудобная навигация. Неавтоматизируемо оценить удобство может только человек.
С этой проблемой столкнулась наша организация, разрабатывающая плагин для Eclipse. Потребовался инструмент, с помощью которого мы могли бы проверять показатели среды разработки после проведения определённых манипуляций, в частности значения регистров. Работа выполнена при поддержке Министерства образования и науки в рамках договора № 02.G25.31.0061 от 12 февраля 2013 года (в соответствии с Постановлением Правительства Российской Федерации от 9 апреля 2010 г. № 218).
Хотя исходный код Eclipse доступен, тестировать его «изнутри» было бы чрезвычайно трудоёмко, поэтому был необходим продукт с возможностью работать в режиме «чёрного ящика», без явного внедрения в код. Разумеется, проверка графического интерфейса связана со многими другими особенности [1]:
• Внутренняя логика приложения обычно хорошо поддаётся модульному тесту. К сожалению, это неверно для GUI. Невозможно протестировать кнопку или контекстное меню в отрыве от всего остального интерфейса.
• Из чего следует, что практически невозможно полностью покрыть тестами графический интерфейс или, по крайней мере, достаточно к этому приблизиться. Слишком много возможных последовательностей действий пользователя.
• Откуда, в свою очередь, следует, что тесты должны следовать типичным операциям пользователя. Они описываются в спецификациях, которые впоследствии редактируются на основе отзывов тестировщиков.
• Желательно, чтобы средство автоматического тестирования поддерживало парадигмы Test Driven Development и Data Driven Development.
• В случае обнаружения ошибки инструмент должен недвусмысленно сообщать её причину. Например, если при нажатии кнопки текст в текстовом поле не изменился, это может вызываться разными причинами: не выполнены внешние условия, кнопка была неактивна, поле стало недоступно или программа вовсе зависла.
Обзор автоматических средств тестирования
Для автоматического тестирования GUI-приложений существует огромное множество средств. При проведении сравнительного анализа хотелось выбрать оптимальное, которое бы удовлетворяло вышеуказанным особенностям тестирования графического интерфейса, но в то же время было бесплатным. После предварительного отбора были опробованы:
• Abbot
• AutoIt
• HP WinRunner
• Jemmy
• Jubula/GUIdancer
• Ranorex
• Robotframework
• Sikuli
• SilkTest
• SwingLibrary Demo
• SWTBot
Test CompleteSilkTest, Test Complete, HP WinRunner и Robotframework были отброшены сразу, так как хоть и имеют великолепный набор функций и подходят для тестирования чего угодно, но платны и довольно дороги.
Abbot, Jemmy и SwingLibrary Demo — вовсе не отдельные утилиты для тестирования, а open-source библиотеки. Они удобны для проверки отдельных компонентов будущего приложения на стадии разработки, но обработать с их помощью уже готовый продукт довольно трудоёмко. Ни одна из этих библиотек не поддерживает режим «чёрного ящика» и не предоставляет тестировщику удобный интерфейс для записи тестов и отслеживания результатов. Кроме того, в каждой из них не хватает поддержки определённых графических библиотек Java. Ranorex к тому же слишком ориентируется на простое воспроизведение тестов, записанных при помощи рекордера.
AutoIt хорошо подходит для автоматизации приложений c графическим интрефейсом, а также славится простым Basic-подобным синтаксисом, но не обладает встроенной ва-лидацией данных. Плюс тесты в этом инструменте сложно поддаются структуризации. Недостаёт и интеграции со внешними средствами.
SWTBot плагин/библиотека была хорошим кандидатом. По ней есть документация и живая ветка форума. Тесты можно писать как кодом, так и рекордером. Кроме того, SWTBot обладает несколькими режимами тестирования, в том числе и с использованием встроенного отладчика. Является, по сути, надстройкой JUnit. Однако, во-первых, иногда отказывается воспроизводить свои же записанные тесты, во-вторых, нестабилен, в-третьих, требует доступ к исходному коду тестируемого приложения.
Из оставшихся был выбран Jubula, бесплатный аналог GUIdancer благодаря следующим достоинствам [2]:
• быстрое обучение,
• два режима работы: рекордер тестов и конструктор,
• бесплатная (открытый исходный код),
• большой help-файл,
• быстро ставится, всё из коробки,
• кросс-платформенная,
• обновляется.
Из недостатков следует отметить малую известность и отсутствие представления тестов в виде кода: тесты представлены в виде «кирпичиков» конструктора. Однако понятный даже для рядового пользователя интерфейс, система рефакторинга тестов и служба разметки элементов GUI делает работу намного легче. Более того, разработку тестов в конструкторе можно отрядить даже новичку в программировании, так как конструктор не требует ни строчки кода.
Обзор конкретных свойств Jubula Общая информация
Изначально компания BREDEX поддерживала два инструмента тестирования: Jubula с открытым исходным кодом и платный GUIdancer с дополнительными возможностями [3]. С самого появления эти инструменты заслужили популярность в сообществе
Eclipse Foundation, что выразилось в награде «лучший коммерческий продукт для разработки» в 2010 году [4]. В связи с переходом BREEDEX на бизнес-модель предоставления услуг вместо программ, с 2015 года GUIdancer окончательно отправился в архив, а Jubula поглотила все его возможности. Теперь этот инструмент поддерживает не только разнообразные Java-графические приложения, основанные на технологиях Swing, SWT/RCP/GEF, JavaFX, но и программы, созданные для .NET и iOS. Существует как автономная версия продукта, так и версия в виде плагина к Eclipse. Мы использовали Jubula как отдельный продукт, так как этот вариант стабильнее и предоставляет больше возможностей для точной настройки и получения информации из тестов.
Таблица1
Краткое сравнение инструментов тестирования по общим признакам
Инструмент Платный Справка Обучение Обновление Баги
SilkTest да много легко часто мало
HP WinRunner да много средне часто мало
Robotframework да много легко часто мало
Ranorex да много средне часто мало
Abbot нет мало сложно редко средне
Jemmy нет мало сложно редко средне
SWTBot нет мало средне редко много
SwingLibrary нет мало сложно часто средне
AutoIt нет средне средне редко средне
Ranorex нет средне легко часто средне
Jubula нет средне легко часто средне
Такое разнообразие продуктов тестирования вкупе с возможностью обращаться к внутренним свойствам графических компонентов поддерживается, возможно, благодаря способу взаимодействия с тестируемой программой. Например, для поддержки классов Rich Client Platform Jubula использует специальную библиотеку, обеспечивающую перехваты обращений к ним (также известны среди программистов как хуки/hooks). Её достаточно добавить в папку библиотек тестируемого приложения и отметить в конфигурации, а при релизе продукта - так же легко убрать.
Для подключения к приложению Jubula использует AUT agent (AUT - application under test, тестируемое приложение), специальную подпрограмму-демона, обеспечивающую TCP/IP-мост между исполнителем задач и объектом испытаний. Такая структура позволяет проводить распределённое тестирование, а также взаимодействовать с другими сервисами и инструментами, призванными облегчить жизнь программиста.
Вместе с Jubula предоставляется документация в виде подробного help-файла. Кроме того, существует довольно крупное сообщество пользователей этого инструмента с собственным форумом. В случаях, когда система тестирования разворачивается в крупных компаниях, компания BREDEX может предоставить платную поддержку и семинары отделу тестирования.
Представление и хранение тестов
Тесты создаются и представляются пользователю в виде «кирпичиков» конструктора. Каждый «кирпичик» представляет либо базовое действие пользователя, либо их блок, выделенный как процедура тестирования. Такой подход немного непривычен для программиста, предпочитающего всюду видеть код, но имеет свои преимущества. Во-первых, не нужно учить новый язык, конструктор интуитивно понятен, и к разработке тестов можно подключаться почти сразу. Во-вторых, конструктор работает в режиме «чёрного ящика»: объекты соотносятся со своими символьными именами, а не строчками ко-
да. Поэтому ЛиЪи^ не предполагает наличия навыков программирования у тестировщика. Следовательно, к разработке можно привлечь даже самых неопытных членов команды или быстро перебросить человеческие ресурсы на тестирование.
Рис. 1. Настройка процедуры тестирования. Показано меню, позволяющее указать переменную информацию, передаваемую в подтест
Отсутствие кода также позволяет решить проблему с программированием методом копировать-вставить, бичом многих разработчиков. В Jubula используется принцип «переиспользование вместо копирования»: попросту нельзя склонировать несколько действий в другое место. Вместо этого используется метод Extract Test Case: выделенные действия переносятся в отдельную процедуру. Её свойства можно настроить таким образом, чтобы некоторая информация передавалась извне, как аргументы в функцию в классических языках программирования.
В Jubula нет выражений if или for [5]. Можно выполнить assert или проверку для каждого элемента из набора, но в явном виде инструкции ветвления и цикла недоступны. Это ещё одна непривычная вещь, с которой сталкивается программист при первом знакомстве с Jubula. С другой стороны, благодаря отсутствию рекурсивного вызова подтестов и бесконечных циклов, тест не может выполняться вечно, какой бы неудачной не была очередная версия GUI.
Существует также альтернативный способ создания тестов: рекордер. Специальная подпрограмма запускается вместе с AUT и записывает все действия тестировщика в отдельную процедуру. Подобный способ удобен, но документация предостерегает от его использования. Такие тесты намного сложнее поддерживать, теряются многие преимущества «конструк-торного» подхода.
На случай, если средствами Jubula никак не обойтись, предусмотрена возможность запуска внешних программ. Таким же способом во время прохождения теста можно вывести дополнительную информацию в консоль или лог-файл.
Для соотнесения реальных графических объектов с их символьными представлениями внутри теста используется специальный режим маркирования объектов (Object Mapping). Для этого не нужно знать исходный код приложения: благодаря специальным перехватчикам, внедрённым на этапе добавления отладочной библиотеки, Jubula сама может опреде-
лить, где во внутренности программы находится элемент, а также его свойства. Система маркирования объектов работает отлично, она может восстановить привязку графического объекта к внутреннему идентификатору, даже если он сместился или немного изменился в новой версии. Но даже если ЛдЬи^ во время воспроизведения записанного теста не смогла найти определённый объект, она попытается использовать эвристические методы, чтобы всё-таки продолжить тест.
Рис. 2. Режим нанесения на карту. В правом нижнем углу можно видеть AUT - Eclipse с тестируемым плагином. Зелёная рамка вокруг консоли означает, что этот объект можно отмаркировать. Сверху-слева расположен длинный список уже соотнесённых элементов, список распознанных элементов, которым ещё не были сопоставлены внутренние имена (выделен красным) и список имён без элементов (пуст)
Объекты можно начать маркировать ещё задолго до того, как будет написана логика их действия, поэтому нет практически никаких ограничений на парадигму Test Driven Development.
Как сами тесты, так и данные для них хранятся в специальной внутренней базе данных [6]. При желании её можно изменить на внешнюю, удобную для отдела тестирования. Таким образом, несколько человек стандартными SQL-средствами могут независимо добавлять новые тестовые данные и выполнять поиск с фильтрами, чтобы проверить, не дублируют ли они работу друг друга. Как и большинство других инструментов, Jubula придерживается парадигмы DDT (Data Driven Testing): данные для проверки не «вшиты» в тест, а поставляются в виде отдельного набора. Такой подход позволяет не создавать однотипные тесты, а повторять одну и ту же процедуру для всех данных из множества.
Кроме того, благодаря ациклической структуре тестов их можно экспортировать в XML-формате, чтобы перенести на компьютер без доступа к Интернету или поделиться
ими в Интернете. Благодаря такому платформонезависимому представлению, а также тому, что Jubula написана на Java, можно ожидать, что результаты тестов не будут зависеть от операционной системы, на которой они проводятся.
Выполнение тестов и получение их результатов
Во время прохождения теста Jubula выполняет действия, как если бы их выполнял пользователь, то есть действительно запускает тестируемое приложение, водит мышкой по элементам и эмулирует щелчки. С одной стороны, такой подход более близок к реальной ситуации, а значит, позволяет найти больше ошибок. С другой - требует, чтобы за компьютером во время проведения теста никто не работал, иначе фокус исполнителя задач собьётся.
По умолчанию при провале теста или проверки внутри него проведение всех тестов останавливается. Обычно это нежелательно. Чтобы восстановиться после сбоя, используется Event Handler, обработчик внештатной ситуации [7]. Например, если исполнитель тестов не сумел найти компонент, можно указать несколько типов поведения: продолжить выполнение, тщательнее попытаться ещё раз, начать следующий тест или поставить всё на паузу до вмешательства человека, возможно, с какими-то дополнительными действиями.
Следует быть осторожным, когда тестируемое приложение может хранить информацию между разными запусками. В нашем случае AUT, то есть Eclipse, запоминал настройки среды, например, какие меню пользователь скрыл во время предыдущего запуска. Тест, призванный проверять это действие, закрывая меню нажатием на кнопку в его заголовке, корректно выполнился бы только раз, ведь после первого выполнения меню уже было бы скрыто, и исполнитель не сумел бы найти кнопку, которую должен нажать. В таких случаях нужно либо после выполнения всех проверок запускать очерёдность действий, переводящих программу в некоторое изначальное состояние, или перед тестируемым действием выполнять действие, которое обязательно делает следующее действие возможным (в рассмотренном случае - раскрыть все меню, возможно, комбинацией горячих клавиш).
Таблица2
Сравнение двух подходов к обработке исключений
Начало теста
Начало теста
Действие 1
Действие 1
Действие 2
Ошибка
Действие 2
Ошибка
I
Действие 3
Процедура восстановления
Действие 3
Процедура сброса
Действие 4
Действие 4
Завершение
Завершение
Примечание: Подход слева желательно использовать при ошибках в действиях, не влияющих на дальнейшее исполнение программы. Подход справа следует использовать для критических ошибок.
По умолчанию результаты просто отображаются внутри ЛиЪи1а. При провале показывается причина и скриншот программы в момент сбоя. Также можно организовать хранение
тестов в базе данных, автоматическое преобразование результатов в заданный формат и отображение результатов в сервисе контроля версий. Но в возможности Jubula входит не только сбор информации о том, какие действия выполняются в текущий момент, но также хранение некоторой перспективы, как развивался проект и метаинформация о тестах. В частности:
• Интеграция с JIRA+Jenkins позволяет отслеживать, кто и когда создал или должен покрыть тестами определённый функционал. Встроенные меню позволяют заходить в репозиторий задач прямо из Jubula или добавлять новую задачу прямо из окна с результатами тестов [8, 9].
• BIRT позволяет вывести историю прохождения тестов и множество полезных графиков, показывающих, как развивался проект.
• Jacoco позволяет узнать процент покрытия кода тестами и различную информацию о «нагрузке» на различные ветви в программе [10].
Заключение
Тогда как крупной организации лучше выбрать платный продукт, Jubula может быть оптимальным инструментом для небольшой компании, занимающейся разработкой Java-приложений. Для бесплатного инструмента с открытым исходным кодом Jubula обладает всеми необходимыми особенностями для тестирования GUI и поддерживает большое количество других возможностей. Она позволяет даже в отсутствие полноценного отдела тестирования срочно перебросить людей на проверку кода, добавить в систему отслеживания проблем новые задачи или быстро сформировать отчёт по результатам теста. Система маркирования объектов позволяет писать тесты вперёд кода, что тоже ценно для маленьких компаний. Время, пока согласуются отдельные детали внутренней работы приложения, не тратится впустую.
Среди недостатков хотелось бы отметить некоторую неотлаженность и непривычный интерфейс самой Jubula. Кроме того, настораживает отсутствие циклов и ограниченное использование условных операторов. Без них сложно реализовать, например, нагрузочное тестирование, для которого, впрочем, есть специальные утилиты. На больших проектах образуется сложная иерархия тестовых задач, так что для многолетней разработки лучше выбрать что-то другое.
Работа выполнена при поддержке Министерства образования и науки в рамках договора № 02.G25.31.0061 от 12 февраля 2013 года (в соответствии с Постановлением Правительства Российской Федерации от 9 апреля 2010 г. № 218).
Литература
1. Reminnyi O. Functional GUI Testing Automation Patterns [Электронный ресурс] // infoq URL: http://www.infoq.com/articles/gui-automation-patterns (дата обращения: 22.07.15).
2. Jubula Features Testtool review [Электронный ресурс] // infoq URL: https://www.testtoolreview.de/en/testtool-overview/tool-list/tooldetail/479-jubula/ (дата обращения: 22.07.15).
3. BREDEX company site [Электронный ресурс] // BREDEX URL: http://testing.bredex.de/ (дата обращения: 22.07.15).
4. Eclipse Awards Winners [Электронный ресурс] // infoq URL: http://www.infoq.com/news/2010/03/eclipse-awards/ (дата обращения: 22.07.15).
5. Vogel J. Jubula Summary [Электронный ресурс] // eclipse URL: http://www.eclipse.org/forums/index.php/t/302031/ (дата обращения: 22.07.15).
6. Eclipse Jubula Database [Электронный ресурс] // eclipse URL: http://marketplace.eclipse.org/content/eclipse-jubula-database-drivers (дата обращения: 22.07.15).
7. Dealing With Errors In Tests: Event Handlers [Электронный ресурс] // eclipse URL: http://help.eclipse.org/juno/index.jsp?topic=/%2Forg.eclipse.jubula. client.ua.help/%2Fhtml/%2Fmanual/%2Fnode214.html (дата обращения: 22.07.15).
8. Automating Eclipse Jubula Tests with Jenkins [Электронный ресурс] // devnotesblog URL: https://devnotesblog.wordpress.com/2011/06/14/automating-eclipse-jubula-tests-with-jenkins/ (дата обращения: 22.07.15).
9. UI Tests Say More With JIRA + Jubula [Электронный ресурс] // atlassian URL: http://blogs.atlassian.com/2013/11/guest-blog-ui-tests-say-more-with-jira-jubula/ (дата обращения: 22.07.15).
10. Jacoco [Электронный ресурс] // eclemma URL: http://www.eclemma.org/jacoco/ (дата обращения: 22.07.15).
References
1. Reminnyi O. Functional GUI Testing Automation Patterns [Internet resource] // infoq URL: http://www.infoq.com/articles/gui-automation-patterns (visited: 22.07.15).
2. Jubula Features Testtool review [Internet resource] // infoq URL: https://www.testtoolreview.de/en/testtool-overview/tool-list/tooldetail/479-jubula/ (visited: 22.07.15).
3. BREDEX company site [Internet resource] // BREDEX URL: http://testing.bredex.de/ (visited: 22.07.15).
4. Eclipse Awards Winners [Internet resource] // infoq URL: http://www.infoq.com/news/2010/03/eclipse-awards/ (visited: 22.07.15).
5. Vogel J. Jubula Summary [Internet resource] // eclipse URL: http://www.eclipse.org/forums/index.php/t/302031/ (visited: 22.07.15).
6. Eclipse Jubula Database [Internet resource] // eclipse URL: http://marketplace.eclipse.org/content/eclipse-jubula-database-drivers (visited: 22.07.15).
7. Dealing With Errors In Tests: Event Handlers [Internet resource] //
eclipse URL: http://help.eclipse.org/juno/index.jsp?topic=/%2Forg.eclipse.jubula. client.ua.help/%2Fhtml/%2Fmanual/%2Fnode214.html (visited: 22.07.15).
8. Automating Eclipse Jubula Tests with Jenkins [Internet resource] // devnotesblog URL: https://devnotesblog.wordpress.com/2011/06/14/automating-eclipse-jubula-tests-with-jenkins/ (visited: 22.07.15).
9. UI Tests Say More With JIRA + Jubula [Internet resource] // atlassian URL: http://blogs.atlassian.com/2013/11/guest-blog-ui-tests-say-more-with-jira-jubula/ (visited: 22.07.15).
10. Jacoco [Internet resource] // eclemma URL: http://www.eclemma.org/jacoco/ (visited: 22.07.15).
Поступила в редакцию 12.10.2015.
