Кто-нибудь использовал SIKULI для тестирования своих приложений на основе GUI?

SIKULI Кажется, имеет огромный потенциал. Кто-нибудь пытался использовать это как инструмент для тестирования? Или он лучше подходит для автоматизации действий пользователей?

12 ответов


цитирую модульное тестирование для GUI (проект документация):

Sikuli предназначен для поддержки модульного тестирования для GUI путем интеграции с junit. Панель модульного тестирования можно открыть, щелкнув View / Unit Test или ярлык Cmd-U на Mac (или Ctrl-U на Windows/Linux).

Итак, хотя я понимаю, что SIKULI изначально нацелен на автоматизацию GUI, его определенно можно использовать для тестирования GUI (что тесно связано, если вы считаете, что тестирование GUI = GUI automation + verification framework). Взгляните на модульное тестирование для GUI (JEdit) для полного примера (и см. assertXXX на изображениях).

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

Это очень замечательная программа, Очень впечатляет.


Я широко использую Sikuli для автоматизации тестирования пользовательского интерфейса. Я "опаздываю" в партию Сикули, обнаружив ее в январе 2011 года. На самом деле я рад, что обнаружил это поздно, потому что, хотя это было многообещающе раньше, я не думаю, что до Sikuli x1.0-rc1 (который произошел в декабре) был выпущен, что он был готов к прайм-тайму.

ранее я использовал TestQuest и баклажаны для автоматизации тестирования пользовательского интерфейса. По-моему, Сикули бьет их обоих наотмашь. Я действительно верю, что у него есть потенциал резко изменить, как люди выполняют автоматизацию тестирования пользовательского интерфейса к лучшему и будут евангелизировать его для людей вокруг меня.

правильное использование Sikuli означает, что вы не после модели" запись и воспроизведение". Скорее, вы должны подходить к разработке автоматизации тестирования с Sikuli-как и ко всем инструментам-как к задаче разработки программного обеспечения.

в настоящее время мы находимся в процессе портирования UI automation DSL (домен Специфический язык) мы построили для баклажанов Сикули. Одна из ключевых особенностей, которую мы будем использовать в нашем DSL, - это возможности распознавания текста Sikuli. Это позволит нам запустить тот же скрипт в различных локализованных версиях нашего продукта.

потому что Sikuli строит на OpenCV (для распознавания изображений) и tesseract-ocr (для распознавания текста), оно имеет неимоверно количество силы и гибкости.



записан рабочий процесс с помощью веб-приложения Flex. Потребовалось некоторое время, чтобы выяснить надежную стратегию создания скриншотов, но как только я это сделал, скрипт продолжал работать даже после того, как я изменил цветовую схему рабочего стола! Синтаксис становится немного неудобным, хотя, когда вам нужно щелкнуть определенный элемент управления в коллекции аналогичных элементов управления, т. е. флажки, поля ввода. Похоже, единственный способ сделать это-использовать find() в сочетании с right(); left(); inside(). Кажется, чем меньше скриншоты, тем более надежно они обнаружены. Imo хорошей практикой было бы включать только значимые объекты на скриншотах и делать их как можно более атомарными, но без ущерба для их уникальности.


@jordan, Absolutley spot on ' использование Sikuli правильно означает, что вы не следуете модели "запись и воспроизведение". Скорее, вы должны подходить к разработке автоматизации тестирования с Sikuli-как и ко всем инструментам-как к задаче разработки программного обеспечения.

Я создал сквозное решение автоматизации тестирования для тестирования приложения видеоконференцсвязи, сделанного крупнейшим в мире производителем ПК. Они не понимали, что это был полный проект dev, а не точка и щелчок операция, которую может выполнить любая обезьяна. Попытка объяснить проблемы кодирования динамически типизированным языком была невозможна.

из моего опыта самой большой проблемой является управление изображениями. Я использовал файловую систему и configparser для первой итерации автоматизации тестирования. Использование configparser работало, однако было сложно реализовать. В будущем я планирую использовать блобы. Sikuli не поддерживает прямое извлечение изображений из БД (пока) хотя у меня есть обходной.

использование IDE имеет решающее значение, так как Sikuli IDE не имеет и инструментов разработки. В 2 IDE, которые я настроил, NetBeans и Eclipse/PyDev имеют свой собственный набор проблем. Они отлично подходят для кодирования, однако ложные ошибки, инъекция пробелов и потеря кода делают оба менее идеальных решения. Я кодирую и тестирую в NetBeans, выполняю в SikuliIDE и сохраняю все в блокноте в качестве резервной копии.

несмотря на любые трудности encounteres я большой сторонник Sikuli. Sikuli имеет потенциал для изменения автоматизации тестирования, что делает его доступным для всего сообщества QA без необходимости быть кодером OO.


для меньшего разработчика центральная автоматизация тестирования для Sikuli, также проверить RobotFramework.org - ... Существует учебник о том, как сделать (пользовательскую) тестовую библиотеку Sikuli для Robot Framework

http://blog.mykhailo.com/2011/02/how-to-sikuli-and-robot-framework.html

и я также создал простую универсальную версию

http://code.google.com/p/simplesikuli

и если когда-либо были ограничения для Сикули в терминах из обработки окон, GUI-элементов управления, взаимодействия мыши и клавиатуры вы всегда можете дополнить его другим отличным бесплатным инструментом тестирования: AutoIt. AutoIt сам по себе также имеет ограничения, когда вы объединяете его с Sikuli, они компенсируют недостатки каждого инструмента, чтобы заменить инструменты тестирования GUI коммерческого класса.


вот мой взгляд на удивительность Sikuli для автоматизации тестирования: http://pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/

У меня есть надежный кросс-платформенный набор тестов для Miro.


Я на самом деле пишу фреймворк для тестирования/обработки ошибок GUI с sikuli. Это здорово.


Я использовал sikuli для тестирования GUI, также я смог интегрировать его с HUDSON.


Я только что опубликовал свою собственную структуру для тестирования приложений GUI с помощью Skikuli + RobotFramework.

SikuliFramework предоставляет объектно-ориентированную абстракцию поверх Sikuli, чтобы помочь с взаимодействующими элементами GUI, такими как наборы кнопок, флажков, переключателей, окон и диалоговых иерархий для автоматизации и тестирования GUI. Он также имеет плотную интеграцию с RobotFramework.

https://github.com/smysnk/sikuli-framework


Sikuli основан на статическом сопоставлении изображений. Поэтому он подходит только для ситуаций, когда GUI достаточно стабилен. Для динамического GUI, такого как анимация или GUI, который включает в себя некоторую случайность, это не так применимо.

и Sikuli охватывает только визуальную часть тестируемого. Он понятия не имеет, действительно ли внутреннее состояние таково, как ожидалось.


этой видео упоминает ,что " он терпит небольшие изменения [sic] в их внешнем виде."Я опасаюсь усилий, необходимых, когда изменения превышают "немного". Интерфейс впечатляет, но чрезмерные ложные срабатывания могут легко замедлить тестирование.