Sikuli не находит pattern при выполнении тестов с помощью Hudson


(vitaly.gorbenko) #1

Добрый день!

Хотел добавить в автоматизированные тесты проверку изображений, но столкнулся с непобедимой пока проблемой :(  Заключется она в том, что Sikuli, будучи интегрированным в  Selenium тесты,  запускаемые при помощи Hudson, не находит pattern-ы , хотя при выполнении из Eclipse тесты успешно проходят. Добавил снятие скриншота при помощи Sikuli , оказалось ему доступен лишь черный экран, а окно браузера он не видит.

Запустил Hudson с системной учетной записью и разрешил взаимодействие с рабочим столом. На Win7  при запуске теста повляется окошко, предупреждающее, что в интерактивном режиме запускается программа, и позволяющее переключиться в тот сеанс. И вот после переключения в  интерактивынй сеанс этот рабочий стол становится доступным для Sikuli и тест проходит успешно. 

Поиск в инете способов обойти эту проблему не дал результатов :(

Вдруг они есть - прошу поделиться информацией  :)

 


(Taras) #2

Sikuli не будет работать с конт.интегрейшн по ходу


(Леша) #3

Подозреваю, что у вас Hudson запущен как служба, а не как приложение. Для корректной работы тестов, взаимодействующих с UI необходимо соблюдений нескольких условий:

1) Hudson/Jenkins должен быть запущен как приложение, а не как сервис (говорят, что как-то можно и работать с сервисом настройкой прав на запуск приложений)

2) у вас должен быть активный сеанс пользователя системы, у вас не должно быть никаких скринсейверов


(rpwheeler) #4

На форуме вопросов-ответов Silkuli на днях сбросили вот такой линк:

http://netjunki.org/blog/jenkins-and-sikuli-integration
Jenkins and Sikuli Integration

Я не работаю ни с Hudson ни с Jenkins, "я просто разместил объяву". Видимо, кто-то решал эту задачу и *чего-то добился*, владеющие английским могут попробовать задать ему вопросы в комментариях, если что.


(vitaly.gorbenko) #5

Спасибо! запущенный как приложение Hudson, позволяется Sikuli взаимодействовать с броузером.  Не совсем то, что мне нужно, но похоже других вариантов пока нет :(  


(vitaly.gorbenko) #6

Спасибо! но мой случай немного отличается, у меня Win7+Hudson+Selenium WebDriver+Thucydides. Встречал ссылки, где на unix-ах люди запускали  Hudson+Sikuli в интерактивных сессиях, под виндой рецептов пока не нашел :(


(Mykhailo Poliarush) #7

да на linux используют виртуальный экран для этого xvfb, например, а для винды я тоже затрудняюсь ответить.

как-то все делают на linux всякие там сервера.

если узнаете, дайте плиз знать, интересно!


(apetrovskiy) #8

Казалось бы, уже много раз писал об этом - наверное, каждый читает только по туле, с которой ... скажем, занимается. :)

Берём гугль, можно хром, и делаем такой запрос: "msdn.microsoft.com: session 0 service"

Сегодня мои первые два линка такие:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb756986.aspx

http://msdn.microsoft.com/en-us/library/windows/hardware/gg463353.aspx

читаем в любом из них:

"In Windows XP®, Windows Server® 2003, and earlier versions of the Windows® operating system, all services run in the same session as the first user who logs on to the console. This session is called Session 0. Running services and user applications together in Session 0 poses a security risk because services run at elevated privilege and therefore are targets for malicious agents that are looking for a means to elevate their own privilege levels.

The Windows Vista® and Windows Server® 2008 operating systems mitigate this security risk by isolating services in Session 0 and making Session 0 non-interactive. In Windows Vista and Windows Server 2008, only system processes and services run in Session 0. The first user logs on to Session 1, and subsequent users log on to subsequent sessions. This approach means that services never run in the same session as users' applications and are therefore protected from attacks that originate in application code."

Как лечить? Читаем ремедис (лекаки):

"

Quick solution:

  • If the application's service uses a UI, a built-in mitigation in Windows Vista and Windows Server 2008 allows the user to interact with the Session 0 UI in a special desktop. This desktop will make available the UI specific to the application, rather than the entire Session 0 desktop.

  • If the application creates globally named objects, use the Windows XP compatibility mode to ensure that the application will continue to work with the Session 0 services. (это шутка такая: XP Mode == XP)

Compatibility test:

  • Test and verify the application on Windows XP in a Terminal Server mode or a Fast User Switching (FUS) mode. If the application works properly on Windows XP in these scenarios, it is very likely to work under Windows Vista and Windows Server 2008.

  • Verify that the application functions properly after applying the Windows XP compatibility mode, which contains mitigation for some of the Session 0 issues.

  • Test the driver in Windows Vista and Windows Server 2008 to ensure that it runs properly. If such a test is not possible, test the driver in Windows XP with FUS enabled and multiple users logged on. If the driver works correctly for the second and subsequent logged-on users, it is not likely to be affected by the Session 0 changes in Windows Vista and Windows Server 2008. The only issues that this test does not detect are those related to the absence of the video driver in Session 0 in Windows Vista and Windows Server 2008.

Leverage Windows Vista and Windows Server 2008 capability:

  • Use client or server mechanisms such as remote procedure call (RPC) or named pipes to communicate between services and applications.

  • Use the WTSSendMessage function to create a simple message box on the user’s desktop. This allows the service to give the user a notification and request a simple response.

  • For more complex UI, use the CreateProcessAsUser function to create a process in the user's session.

  • Explicitly choose either the Local\ or Global\ namespace for any named objects, such as events or mapped memory that the service makes available."

Волшебники редкость в наши дни, не ждите, что разработчики фришного тестировочного софта, да ещё и кросс-платформенного, обойдут мелкософт. Если только сделают в соответствии с этими указаниями (но это довольно трудно).

Так что, по-простому: 1) XP/2003/XP Mode 2) запустить ваш код в юзерском процессе, не в серверном 3) долой всякие там скринсейверы и заспыпания машинок 4) автологон приветствуется


(Леша) #9

Берём гугль, можно хром, и делаем такой запрос: "msdn.microsoft.com: session 0 service"

Когда знаешь, что искать - зачем что-то тогда вообще искать? :)

За ссылки на msdn - спасибо, будет теперь теоретическое обоснование практического опыта.


(apetrovskiy) #10

На самом деле, для гуёвых тестов надо иметь юзерскую сессию (т.е. залогиниться через три кнопки или автологоном). Если же сессия есть, я могу смело запустить скрипт и залочить экран, он будет молотить под скринсейвером. Это верно для уже запущенного теста, так и для отложенного: если поставить слип и залочить экран, то и так тест работает. Всё дело в наличии активной юзерской сессии и возможности с ней интерактивно общаться.


(Леша) #11

Какие тесты вы запускаете таким образом? Какой инструмент используете?

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


(apetrovskiy) #12

Я пришёл к любопытным выводам.

Тестировал скрипт http://uiautomation.codeplex.com/downloads/get/446786 -> UIARunner\testTMXwithAutoGeneration_5.ps1

Вообще говоря, скрипт этот - плохой тест. Он тысячу раз делает простые действия в калькуляторе. Надо что-то более сюитоподобное будет попробовать.

Смотрел в четырёх комбинациях:

powershell.exe + locked

powershell.exe elevated + locked

powershell.exe + locked + screensaver

powershell.exe elevated + locked + screensaver

Во всех четырёх случаях часть тестов не нашла контролы. После несколькосекундного отмерзания, все тесты пошли дальше.

Однако, тот же скрипт на UIARunner.exe ( http://uiautomation.codeplex.com/downloads/get/446783 ) продолжил работу как ни в чём ни бывало! Приложение скомпилено с параметром highestAvailable, поэтому потом буду проверять, что же это за фокус: или повышенные привилегии спасают от скринсейвера, или баг в UIARunner.

Скринсейвер при залогоненном юзере стартует с привилегиями юзера: http://msdn.microsoft.com/en-us/library/cc144066(v=vs.85).aspx

"The security context of the screen saver is dependent on whether a user is interactively logged on. If a user is interactively logged on when the screen saver is invoked, the screen saver runs in the security context of the interactive user. If no user is logged on, the security context of the screen saver is dependent on the version of Windows being used."

Однако, это не объясняет, почему тесты на элевейченном пауэршелле зафейлились.

В итоге, получилось вот что: UIARunner замедляется, скорость падает до 1 trps, но тесты идут. На примере этого скрипта: было 98 успешных и 14 фейленых, залочил машинку, разлочил - 160 успешных и двадцать с чем-то фейленых (там соотношение 12 пассед на 2 файлед), т.е. соотношение соблюдено, фейлы под расчёт.

Я из интереса поиграюсь на других скриптах. Хотя особого смысла нет - достаточно же отключить скринсейвер (руками или через политики), и ВСЁ будет работать.

 


(apetrovskiy) #13

Сегодня запускал на залоченном экране свои юнит-тесты UIAutomation. Удивился высокому уровню прохождения. После этого, спускаясь вниз в БЦ, снова поставил на выполнение на залоченном компе.

Вот результаты:

всего юнит-тестов: 394

отвалилось по причине изменения кода: 3

отвалилось, потому что отваливается всегда: 1

"потери на залоченность": 5

5/394=1,3% неидеально, не неплохой рейт имхо.


(Mykhailo Poliarush) #14

поздравляю, действительно хорошие результаты :)


(apetrovskiy) #15

Несколько раз проверял (в основном, на Windows 8 RP, i.e. build 8400) - на удивление, 99% (это не прикидка, а расчёт - примерно 4 из 395) тестов выполняются под скринсейвером. Отрабатывают даже Win32 клики (т.е., SetCursorPos и SendMessage, впрочем, последнее работает по хэндлу, был бы хэндл. Но работает медленнее, наверное, Automation tree работает под скринсейвером медленнее - командлеты работать медленнее не могут, в них забит таймаут).

Скорее всего, QTP в целом или плагин, который работал у вас, юзают что-то, что ломается под скринсейвером. Возможно, ходят по координатам или ещё делают лишние проверки, которые не отрабатывают. Кстати, надо будет проверить хождение по координатам - Move-UIACursor, возможно, проверяется недостаточно строго.

тул - http://UIAutomation.CodePlex.com

(впрочем, если нет надобности в скринсейвере, лучше его убрать от греха)