SikuliX - ооочень медленно. Как ускорить?

#1

Добрый день, коллеги.

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

Написал все на Sikuli скриптах. что то около 400 одинаковых фича-файлов.
Сам скрипт несложный, но механика его выполнения из Ванессы такова:

  • запустить (.cmd) файл из установки sikuli
  • выполнить скрипт
  • закрыть sikuli
    все это примерно 30 секунд
    умножить на количество запусков и получаем 6+ часов.
    Сам скрипт пытался оптимизировать уменьшая области поиска кнопок, помогло но не сильно, раньше 10 часов все “бегало”.

Вот и вопрос. А есть ли какие то еще способы ускорить работу с сикули скриптами?

Чисто визуально больше времени уходит именно на запуск самой сикули, чем на исполнение скрипта.

Можно ли запустить сикули как службу, чтобы она все время вертелась в фоне и ловила запуски скриптов из Ванессы?

1 Симпатия
#2

Очень интересная тема.

По серверу Sikuli пока ничего сказать не могу, нужно подумать.

А можешь как-то поделиться этими Sikuli-скриптами?

#3

напомни почту ))

#4

aartbear@gmail.com

#5

Sikuli можно запустить в режиме сервера. VA уже умеет с ним работать, ADD - пока нет.

#6

Скомуниздил работу с сервером из VA.
Принципиально моя работа с сикули построена так:
я запускаю скрипт и передаю файл лога

runsikulix.cmd -r ПутьКСкрипту > ПутьКЛогуСкрипта

в самом скрипте через print(“Нашел предупреждение”) я получал в логе строку “Нашел предупреждение”.
После прогона скрипта в 1С я анализировал этот лог находил ключевые слова и вызывал падение сценария с расшифровкой ошибки (которую сам придумал).

Сервер сикули это по сути один файл питоновский, в котором все скрипты в виде процедур написаны, который завис в цикле и поэтому не закрывается, а цикл этот ждет некий файл, который ему подсовывает 1С, когда “запускает” сикули скрипт. Запуск скрипта на сервере, это запись текстового файла с названием скрипта (=название процедуры в файле сервера) и некие параметры.

Мой фокус с файлами логов на каждый запуск скрипта не прокатил, т.к IDE запущена и пишет все print() в лог этого “сервера” и там адская мешанина.

Передаю через параметры путь к логу конкретного скрипта, получаю проблему “файл занят другим процессом” то есть 1С пытается читать файл лога, когда IDE еще его не отпустила. Получаю еще большую задержку в целом.

Хотел быстрее, а получил медленнее.

Пока результаты печальные. С наскоку не вышло.

#7

Сделал так.
Вместо чтения лога после выполнения скрипта, скрипт пишет в указанное место файлики
0.txt
1.txt
2.txt
3.txt
это коды ошибок
в 1с после прогона скрипта ищу эти файлики и вызываю падение шага с описанием ошибки по этим кодам.

Суммарно все действия привели к снижению времени выполнения одного скрипта с 73с до 29с.

Скрипты все одинаковые, они работают с разными документами.
Профит.

Спасибо за наводку, коллега.

#8

@Maku-shimo Сделаешь PR в ADD по серверу Сикули?

#9

Не уверен, что это будет качественно.
Я делал на коленке.

#10

Начни, я помогу

#11

Оказалось все не так радужно ((
Запуск всех фич показал очень странное поведение.
Через 5-7 фич идет успешное выполнение скрипта, но между этим идет конфликт за удаление управляющего файла, того самого, в котором передается имя скрипта.

“Выполнить через сикули сервер” для 1С означает записать управляющий файл и ждать появления файла ответа рядом". То есть она не ждет выполнения скрипта через cmd (0 или 1), она ждет появления файла ответа. А еще раньше перед записью управляющего файла 1С его удаляет. Но он еще занят IDE Сикули. вот и получается, что 1С работает быстрее чем IDE и например 3-я фича удаляет управляющий файл который еще не “отпустило” после выполнения скрипта из 1-й фичи.

Пытался управлять процессом всякими ожидалками на удаление управляющего файла, наличия файла ответа и т.д. Но получилось еще хуже.
Ожидание выполнения скрипта (файла ответа) отваливалось по таймауту и валило шаг. Сервер сикули становился недоступен для 1С и держал файл лога, так что нельзя было заново запустить сервер.

Кароче. я ухожу на спринт и вернусь к этому вопросу через неделю.

продолжение следует…

#12

Мы тоже. @artbear возьмем в проработку ? что там по приоритетем ?