кто-нибудь использовал sikuli для тестирования своих приложений на основе gui?

<p> <a href="http://sikuli.csail.mit.edu/">sikuli</a> , кажется, обладает огромным потенциалом. кто-нибудь пытался использовать это как инструмент для тестирования? или лучше подойдет для автоматизации действий пользователей?</p>

<p>цитирование <a href="http://sikuli.csail.mit.edu/documentation.shtml#/trac/wiki/unittesting">юнит тестирование для gui</a> (в проекте <a href="http://sikuli.csail.mit.edu/documentation.shtml">документация</a> ):</p><blockquote> <p>sikuli предназначен для поддержки модульного тестирования графического интерфейса путем интеграции с junit. панель модульного тестирования можно открыть, щелкнув view/unit test или ярлык cmd-u на mac (или ctrl-u в windows/linux). </p> </blockquote><p>итак, хотя я понимаю, что sikuli изначально нацелен на автоматизацию gui, он определенно может быть использован для тестирования gui (что тесно связано, если учесть, что тестирование gui = автоматизация gui + структура верификации). посмотрите на <a href="http://sikuli.csail.mit.edu/documentation.shtml#examples/testjedit.sikuli/testjedit.html">модульное тестирование для gui (jedit)</a> для полного примера (и посмотрите <code>assertxxx</code> на изображениях). </p><p>и действительно, я вижу большой потенциал в sikuli для тестирования, поскольку кажется, что он очень облегчает написание тестов, даже без написания ни одной строки реального приложения (например, просто с использованием некоторых начальных макетов). sikuli может стать отличным компаньоном для различных видов тестирования (bdd, приемочное тестирование и т.д.).</p><p>это действительно потрясающее программное обеспечение, очень впечатляющее.</p>

<p>я широко использую sikuli для автоматизации тестирования пользовательского интерфейса. я «опоздал» на вечеринку sikuli, обнаружив ее в январе 2011 года. я действительно рад, что обнаружил ее поздно, потому что, хотя она была многообещающей ранее, я не думаю, что до sikuli x1.0-rc1 (что произошло в декабре ) было выпущено, что он был готов к прайм-тайм.</p><p>ранее я использовал testquest и eggplant для автоматизации тестирования пользовательского интерфейса. на мой взгляд, sikuli бьет их обоих руками вниз. я искренне верю, что у него есть потенциал, чтобы кардинально изменить то, как люди выполняют автоматизацию тестирования пользовательского интерфейса, к лучшему, и буду распространять его среди окружающих.</p><p>правильное использование sikuli означает, что вы <strong><em>not</em></strong> придерживаетесь модели «запись и воспроизведение». скорее, вы должны подходить к разработке автоматизации тестирования с помощью sikuli - как вам нужно со всеми инструментами - в качестве задачи разработки программного обеспечения.</p><p>в настоящее время мы занимаемся переносом dsl автоматизации пользовательского интерфейса (domain specific language), который мы создали для eggplant, в sikuli. одной из ключевых функций, которые мы будем использовать в dsl, являются возможности распознавания текста sikuli. это позволит нам запускать один и тот же сценарий для разных локализованных версий нашего продукта.</p><p>поскольку sikuli основан на <a href="http://opencv.willowgarage.com/wiki/">opencv (для распознавания изображений)</a> и <a href="http://code.google.com/p/tesseract-ocr/">tesseract-ocr (для распознавания текста)</a> , он обладает невероятной мощностью и гибкостью.</p>

<p>также см. документ: <a href="http://groups.csail.mit.edu/uid/projects/sikuli/sikuli-chi2010.pdf">http://groups.csail.mit.edu/uid/projects/sikuli/sikuli-chi2010.pdf</a> </p>

<p>записал рабочий процесс с помощью веб-приложения flex. потребовалось время, чтобы найти надежную стратегию создания скриншотов, но как только я это сделал, скрипт продолжал работать даже после того, как я изменил цветовую схему своего рабочего стола! синтаксис становится немного неловким, хотя, когда вам нужно щелкнуть конкретный элемент управления в наборе похожих элементов управления, то есть флажки, поля ввода. похоже, единственный способ сделать это - использовать <code>find()</code> в сочетании с <code>right(); left(); inside()</code>. похоже, чем меньше скриншоты, тем надежнее они обнаружены. по моему мнению, хорошей практикой будет включать в скриншоты только важные объекты и делать их как можно более атомарными, но без ущерба для их уникальности.</p>

<p>чтобы автоматизация тестов sikuli была менее ориентированной на разработчиков, также посетите сайт robotframework.org. там есть учебник о том, как сделать (настраиваемую) тестовую библиотеку sikuli для robot framework</p><p> <a href="http://blog.mykhailo.com/2011/02/how-to-sikuli-and-robot-framework.html">http://blog.mykhailo.com/2011/02/how-to-sikuli-and-robot-framework.html</a> </p><p>и я создал простую общую версию, а также </p><p> <a href="http://code.google.com/p/simplesikuli">http://code.google.com/p/simplesikuli</a> </p><p>и если когда-либо были ограничения для sikuli с точки зрения обработки окон, элементов управления графическим интерфейсом, взаимодействия мыши и клавиатуры, вы всегда можете дополнить его еще одним отличным бесплатным инструментом тестирования: autoit. autoit сам по себе также имеет ограничения: когда вы объединяете его с sikuli, они восполняют недостатки каждого инструмента, заменяя инструменты тестирования графического интерфейса пользователя коммерческого уровня.</p>

<p>@jordan, абсолютная точка зрения на «правильное использование sikuli» означает, что вы не следуете модели «запись и воспроизведение». скорее, вы должны подходить к разработке автоматизации тестирования с помощью sikuli - как вам нужно со всеми инструментами - в качестве задачи разработки программного обеспечения.</p><p>я создал комплексное решение для автоматизации тестирования приложений для видеоконференций, созданное крупнейшим в мире производителем пк. они не понимали, что это полный проект разработчика, а не операция «укажи и щелкни», которую может выполнить любая обезьяна. попытка объяснить проблемы кодирования с помощью динамически типизированного языка была невозможна.</p><p>из моего опыта самая большая проблема - это управление имиджем. я использовал файловую систему и configparser для первой итерации автоматизации тестирования. использование configparser работало, однако это было трудно реализовать. в будущем я планирую использовать капли. sikuli не поддерживает прямое извлечение изображений из бд (пока), хотя у меня есть обходной путь.</p><p>использование ide имеет решающее значение, поскольку sikuli ide не имеет и инструментов разработки. у двух ide, которые я настроил, netbeans и eclipse/pydev есть свои проблемы. они отлично подходят для кодирования, однако ложные ошибки, внедрение пробела и потеря кода делают оба решения не идеальными. я кодирую и тестирую в netbeans, выполняю в sikuliide и сохраняю все в блокноте как резервную копию.</p><p>несмотря на любые трудности, я большой сторонник сикули. sikuli может изменить автоматизацию тестирования, сделав ее доступной для всего сообщества qa без необходимости быть oo кодером.</p>

<p>я только что опубликовал свой собственный фреймворк для тестирования приложений gui, используя skikuli + robotframework.</p><p>sikuliframework предоставляет объектно-ориентированную абстракцию поверх sikuli, чтобы помочь с взаимодействующими элементами gui, такими как наборы кнопок, флажков, переключателей, окон и диалоговых иерархий для автоматизации и тестирования gui. он также тесно интегрирован с robotframework.</p><p> <a href="https://github.com/smysnk/sikuli-framework">https://github.com/smysnk/sikuli-framework</a> </p>

<p>sikuli основан на сопоставлении статических изображений. так что это подходит только для ситуаций, когда графический интерфейс достаточно стабилен. для динамического gui, такого как анимация или gui, который включает в себя некоторую случайность, это не так применимо. </p><p>и sikuli покрывает только визуальную часть тестируемого. он понятия не имеет, действительно ли внутреннее состояние соответствует ожидаемому. </p>

<p>вот мой взгляд на удивительность sikuli для автоматизации тестирования: <a href="http://pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/">http://pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/</a> </p><p>у меня есть надежный кроссплатформенный набор тестов для miro.</p>

<p>я фанат sikuli и считаю, что он дополняет другие тесты и может сэкономить большую часть усилий по ручному тестированию.</p><p>однако, чтобы понять все правильно, требуется время…. я сделал второй снимок за два года, и во второй раз мне удалось добиться хороших результатов, так как я был лучше знаком с окружающей средой.</p><p>он поставляется с интуитивно понятным ide и python позволяет легко расширять несколько вещей .. очень легко менять позиции нажатия, устанавливать допуск и записывать вещи. как только вы научитесь записывать и проверять документацию, вы сможете легко использовать минимальные изображения и повысить точность. он ловит изменения в графическом интерфейсе и дает результаты довольно легко. также легко дождаться определенного события. проверка ошибок проста.</p><p>самая большая проблема в том, что записанные тесты часто дают сбой, если вы просто запускаете их на другом компьютере, а не на том, на котором они были записаны. это может быть связано с сопоставлением шаблонов на основе сравнения изображений. можно повысить вероятность совпадения, указав значения допуска. но иногда становится раздражающим продолжать изменять толерантность. я рекомендую использовать другой набор образов на разных платформах и предпочтительно запускать его на одной машине или виртуальной машине.</p><p>если у вас есть общий набор рабочих процессов, вы можете создать библиотеку этих общих функций, таких как (открыть-закрыть-сохранить проект, изменить настройки) и использовать их в разных сценариях. это становится очень простым, поскольку библиотека становится всеобъемлющей. это также означает, что вам придется менять сценарий только в одном месте, и это будет отражаться во всех сценариях.</p><p>я также создал простую структуру (<strong>image attach</strong>) для запуска тестов и записи результатов с использованием c # .net. можно создать что угодно для создания простого тестового приложения. просто нужно запустить тест из командной строки и проверить результаты . <a href="https://i.stack.imgur.com/fbvfo.png"> <img src="https://i.stack.imgur.com/fbvfo.png" alt="enter image description here"> </a> </p><p>я работал в небольшой команде, в которой у нас были ограниченные ресурсы для тестирования. с sikuli я фактически сэкономил усилия существующей команды qa, а также помог мне поймать ошибки, прежде чем выдвинуть их на главную.</p><p>я рекомендовал sikuli членам других команд в моей компании, и они используют его для создания набора данных для моделей ml. они сделали это, автоматизировав свое приложение engg с параметрами.</p><p>sikuli занимает время, чтобы погрузиться вначале. но если все сделано правильно, это может сэкономить много усилий.</p>

<p>я использовал sikuli для тестирования gui, также я смог интегрировать его с hudson.</p>

<p>на самом деле я пишу рамки для тестирования gui/обработки ошибок с sikuli. это великолепно.</p>