Jubula – TDD UI QA Automation Tool
Download as pptx, pdf0 likes729 views
Jubula is a comprehensive open-source UI automation tool for functional testing, supporting various desktop applications across multiple platforms. Developed by Bredex and supported by the Eclipse community, it incorporates test-driven and data-driven development methodologies, allowing for the creation and management of test cases without requiring programming skills. While Jubula offers a user-friendly environment and integrates well with continuous integration systems, it has limitations regarding project architecture and manual integration challenges.
Jubula – TDD UI QA Automation Tool
- 1. Jubula – TDD UI QA Automation tool Антон Наумович DPI Solutions
- 2. О себе Антон Наумович Более 10 лет опыта в IT • C++ тимлид и архитектор в LogicNow • В DPI Solutions курирую проекты по автоматизации • В прошлом – разработчик в Microsoft, команда Hyper-V (Windows Server) • Активист сообщества автоматизаторов COMAQA.BY
- 3. Что такое Jubula Jubula – это мощный профессиональный инструмент для автоматизации функционального тестирования ПО через графический интерфейс пользователя
- 4. История • Разработан в немецкой компании Bredex • Основан на коммерческом инструменте GUIDancer • Развивается сообществом Eclipse
- 5. • Является standalone-инструментом (существует также плагин к Eclipse) • Поддерживает автоматизацию десктопных приложений: включая Java (Swing, SWT/RCP/GEF, JavaFX), native Win32, .Net, HTML, iOS • Платформы: Windows, Linux/Unix и Mac • Полностью бесплатный и open-source Что характерно
- 6. • Клиент – интегрированная среда для разработки, запуска и анализа тестов (либо плагин к Eclipse) • Сервер (AUT Agent) – сервис для запуска AUT-приложения и контроля за выполнением тестов • Поддерживается интерфейс командной строки для интеграции в Continuous Integration системы * AUT – Application Under Test Архитектура Jubula
- 7. Только соответствие поддерживаемым технологиям: • Не нужен доступ к исходным кодам • Не нужны модификации исполняемых файлов Что требуется от AUT-приложения
- 8. • Повторное использование тестов + рефакторинг • Слой абстракций для UI-элементов • Библиотека готовых действий, “ожидалок” и проверок • Не требует навыков программирования • Record-play есть, но не рекомендуется к использованию • Test-Driven Development • Data-Driven Testing Идеология Jubula
- 9. Что же такое Test-Driven Development Разработка через тестирование: сначала пишутся тесты, затем реализуется соответствующий функционал «Разработка через тестирование поощряет простой дизайн и внушает уверенность»
- 10. Цикл Test-Driven Development • Пишем тест: конец немного предсказуем – FAIL (Red) • Пишем код до успешного прохождения тестов (Green) • Приводим код в должное состояние (Refactor)
- 11. • Раннее фиксирование требований через тесты • Знакомство бизнес-специалистов с процессами разработки • Поощряет взаимодействие между заказчиком, разработчиками, тестировщиками • Идеально подходит под agile-процессы Почему важен TDD через UI?
- 12. Data-Driven Testing – это • отвязывание данных, используемых для тестов, от самих тестов • ожидаемый результат обычно идет вместе с данными Data-Driven Testing Легко поддерживать и расширять тестовые данные
- 13. Итак Рассмотрим типовой процесс создания теста
- 14. Шаг 1 • Создаем тестовый проект
- 15. Шаг 1 • Задаем имя проекта
- 16. Шаг 1 • Выбираем тулкит в зависимости от типа приложения
- 17. Шаг 1 • Выбираем языки, используемые для тестовых данных
- 18. Шаг 1 • Указываем название приложения (произвольное)
- 19. Шаг 1 • Вносим уникальный идентификатор приложения для проекта • Выбираем директорию с приложением • Выбираем исполняемый файл
- 20. Шаг 2 • Создаем Тест-кейс • Задаем имя кейса • Открываем кейс двойным кликом
- 21. Шаг 3 Теперь нужно добавить степы в свой кейс: • Первым степом открываем приложение • Степы добавляются обычным перетаскиванием
- 22. Шаг 3 • Теперь нужно добавить к степу параметры • Имя степа (для удобства использования) • Метод активации “TITLEBAR” = клик по титульной строке приложения
- 23. Шаг 3 • Таким же образом добавляем все нужные степы • В параметрах можно использовать переменные, для использования Data- Driven подхода (=<ИМЯ ПЕРЕМЕННОЙ>) • В проверке необходимо задать оператор сравнения
- 24. Шаг 3 Добавляем данные: • Данные добавляются для всех выбранных языков • Для каждого набора данных можно задать свой оператор сравнения
- 25. Шаг 3 Добавляем имена использованных компонентов: • Поочередно проходя по степам задаем имена компонентов, с которыми будут проводиться действия, в области “Component Names”
- 26. Шаг 4 Теперь мы готовы создать тест-сьют… …с любым удобным именем
- 27. Шаг 4 Старый добрый drag-n-drop нашего кейса в область редактирования тест-сьюта:
- 28. Шаг 4 Тест готов! А красный крест на сьюте говорит о том, что функционал не реализован, а значит мы на стадии “Red”
- 29. Шаг 5 После реализации функционала делаем маппинг:
- 30. Шаг 5 • Для этого запускаем агент • Запускаем приложение • Стартуем маппер
- 31. Шаг 5 • Маппер подсвечивает элементы зеленым цветом • Сочетанием Ctrl+Shift+Q добавляем элемент в список • Перетаскиваем наш объект из кейсов на мап
- 32. Шаг 5 • Повторяем действие для всех элементов
- 33. Шаг 6 Запускаем тесты *Внимание! Приложение должно быть запущено с подключенным агентом, как мы делали перед маппингом
- 34. Шаг 6 Результаты: Fail, Something wrong!Pass, Ok! Сохраняются скриншоты
- 35. • Тестовые проекты и результаты хранятся во встроенной базе данных • При желании встроенная база заменяется на внешнюю • Возможен экспорт в XML формат для хранения в системе контроля версий Хранение тестов и результатов
- 36. Tips and tricks • Создавайте отдельные «ключевые слова» для повторяющихся действий, это увеличит повторное использование действий (Используйте Extract Test Case) • Удобно иметь отдельный тест-сьют с тестами по функционалу, который еще не реализован (Red). По мере реализации функционала тесты оттуда необходимо будет переносить в Regression • Структурируйте эти «ключевые слова», располагая их в именованных папках по категориям • Максимально используйте возможности Data-Driven Testing
- 37. Аналоги Автоматизация десктопных приложений Возможность писать как keyword, так и скриптовые тесты Мощный встроенный mapping-tool Нет поддержки TDD ОЧЕНЬ дорогая лицензия
- 38. Аналоги Автоматизация десктопных приложений «Свободная» архитектура тестового проекта Только скриптовые тесты, нет Keyword-driven Ограниченная поддержка Java-приложений Платная лицензия
- 39. Аналоги Автоматизация десктопных приложений Простой Basic-подобный синтаксис Тесты – просто набор скриптов без архитектуры Нет встроенной валидации Бесплатный
- 40. Аналоги Автоматизация десктопных приложений Поддержка Record-play Базирование на Record-play Платная лицензия Поддержка различных платформ, включая мобильные
- 41. Итого: плюсы Jubula это: • Собственный UI, встроенная база данных для хранения тестов и результатов, встроенная поддержка DDT, включая использование как встроенных, так и внешних источников данных, например .xls-файлы • Полноценный самостоятельный инструмент автоматизации, не зависящий от сторонних библиотек, инструментов, языков, IDE • Бесплатная лицензия • Встроенная поддержка TDD: маппинг объектов после написания тестовых сценариев
- 42. Итого: минусы Ложка дёгтя: • Предопределенная архитектура проекта – на больших проектах со временем образуется нагромождение степов и тест-кейсов • Тесты не портируются и не конвертируются в код • UI и flow, требующие привыкания • Ручная интеграция в Continuous Integration
- 43. Используйте Jubula, если: • нужен бесплатный инструмент • нужна базовая функциональная автоматизация через UI • хотите быстро начать автоматизацию • хотите по минимуму заниматься тестовой инфраструктурой • хотите получить плюсы TDD и DDT • хотите чтобы тесты мог разрабатывать нетехнический специалист В итоге
- 44. Спасибо! Вопросы? Антон Наумович [email protected] skype: dpi.naumovich
Editor's Notes
- #4: В книге Стива Макконела “Совершенный код” дается средний процент дефектов, которые можно обнаружить применяя тестирование различных видов (код ревью, статический анализ кода, юнит-тестирование, регрессионное тестирование). Средний процент каждой методики – около 40. Максимальный – до 70. Следовательно если мы хотим достичь качества в 90% и более – нам необходимо пользоваться комбинацией различных видов тестирования. Одним из таких видом является тестирование через интерфейс пользователя.
- #12: Очень хотелось бы методолгию TDD распространить на UI. Огромное количество проектов сейчас ведется по той или иной agile методологии. Для четкого определения такого понятия как Definition of Done настоятельно рекомендуется иметь high level acceptance test для каждого куска функционала. Этот acceptance test потом попадает в регрессию. В условиях нехватки ресурсов зачастую не хватает людей для написания автотестов. А что, если дать возможность Product Owner-у фиксировать поведение UI через разработку тестов? Убиваем много зайцев – Часть сделанной работы по автоматизации Фиксация требований UI обдумывается более вдумчиво Люди от бизнеса получают возможность непосредственно участвовать в разработке, делать что-то своими руками.
- #44: На разных платформах Запускать параллельно Запускать на клауде