Pull to refresh
8
0
Леонид Руденко @LeonSabr

User

Send message
Спасибо за отзыв.

Небольшой комментарий, почему для своей задачи я выбрал не одну большую конфигурацию, а несколько более мелких: для виртуальных машин и для selenoid. Есть две проблемы:

1) При пересоздании виртуальной машины в vSphere требуется время, чтобы новый ip попал в DNS.
Допустим, я хочу обновить докер на виртуальной машине. Подготовил новый шаблон. При пересоздании виртуальной машины с сохранением hostname в vSphere требуется время, чтобы новый ip попал в DNS. Пока этого не произойдет, terraform не может пойти в docker на машине по hostname и создать selenoid-инфраструктуру. Скорее всего, эту проблему можно решить, но с приложением усилий специалистов по нашим сетям.

2) Не хочется выполнять апгрейд кластера с даунтаймом. Вроде «сегодня с 2 до 3 ночи браузеры для тестов будут недоступны».
Поэтому я убираю нагрузку с половины selenoid, обновляю их, возвращаю в кластер, выводя вторую половину. После чего завершаю обновление и получаю полностью обновленный кластер. Ни один идущий тест при этом не пострадает. Если допустить даунтайм, то ничего не мешает поместить все selenoid в одну terraform-конфигурацию и один раз сделать terraform apply, обновляя весь кластер разом.

В итоге, если решить проблему с DNS и допустить даунтайм, то получится одна terraform-конфигурация, и обновление инфраструктуры будет выполняться одним terraform apply. Но даунтайм иметь не хочется.
Если вы предлагаете использовать Sikuli IDE, то это видится неприемлемым. Как и популярная в свое время Selenium IDE.

Если использовать обвязку для webdriver, то я не совсем понимаю, как подружить sikuli с Selenium Grid, ведь фактически машина, на которой выполняется тест, и машина, на которой запущен используемый браузер, — это разные машины. А без грида мы получим неприемлемое время выполнения полного набора тестов.

В общем, хочется больше подробностей, как вы видите sikuli в качестве альтернативы описанному решению.
Интересно, может быть использовали какой-то умный алгоритм сравнения скриншотов? Понятно, что реальный браузер — зачастую самое медленное звено тестов, но и оптимизация сравнения больших скриншотов видится полезной.
Не совсем честно, но, оглядываясь на долю этого браузера и несовершенство его реализации Selenium Webdriver, мы говорим «это тоже webkit, нам хватит Chrome».
Каким образом вы перезапускаете тесты, чтоб исключить случайности? Если автоматически, то как с этим работает CI? Если автоматически, то как отслеживаете, какие тесты часто падают случайно и что с ними делаете?

После выполнения сценария понятно, есть ошибка или нет. Если есть ошибка, не завершая теста, мы выполняем сценарий заново с помощью механизма рул в junit. Отчет содержит ошибку, если она воспроизвелась заданное нами число раз. Соответственно, CI про это ничего не знает. Через некоторое время использования таких тестов приходит знание, какие колдунщики стабильны, а какие нет. Могу привести примеры нестабильных колдунщиков: время [который час], панорамы [панорама москвы], игры [игры онлайн]. Это либо анимация, либо сильно случайные данные. Срабатывания этих тестов однотипны и легко отличимы от реальных проблем.
Кто первый работает с результатами screenshot-based тестов: разработчики, тестировщики, автотестеры?

Удалось передать эксплуатацию тестов ручным тестировщикам (в большей степени) и разработчикам (в меньшей степени). Есть довольно прозрачный механизм запуска тестов и получения отчета в понятном стороннему от автоматизации человеку виде. От автоматизаторов теперь зависит добавление новой функциональности и поддержка тестовых сценариев (локаторы изменились, запросы протухли) — но и тут большая помощь идет от ручных тестировщиков. Мы дали им возможность редактировать и добавлять сценарии отдельно от кода.
Какова вероятность ложного срабатывания отдельного теста? Сколько тестов всего? Сколько тестов ложно срабатывают в каждой сборке? Сколько времени ежедневно тратится на поддержку системы в контексте ложных срабатываний?

Вероятность распределена неравномерно по тесткейсам. Есть тесткейсы, которые никогда не давали ложного срабатывания. Есть тесткейсы, которые почти всегда дают срабатывание (писал об этом выше, про нестабильные колдунщики). Для домена ru сейчас используетсяя около 700 тесткейсов. Скажем так, «срабатывает» около 10% тестов из запуска в нормальных условиях. Нормальные условия — это когда не меняют глобальные библиотеки стилей.

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

Есть наша статистика, которую посчитали при запуске тестов в эксплуатацию: после появления тестов, время тестирования поисковой выдачи в одном браузере/домене сократилось с 90 минут до 46 (из которых 8 уходило на анализ отчета автотестов). Экономию в 44 минуты на каждый браузер/домен нужно умножить на число поддерживаемых конфигураций.
Кто-то из перечисленных писал код для аутсорс-проекта в какой-нибудь SuperSoft Puper Luxeware? Они как раз таки ученые.
Почему-то постоянно отправляет на страницу создания BattleTag, хотя он уже указан в профиле…
Школа возродилась, это хорошо. Участвовал в JASS-2009, но тогда андроид еще не был мейнстримом. Вроде бы из-за проблем с финансированием в 2010 и 2011 школа не проводилась? Теперь успевайте подавать заявки на «обратную» школу Ferienakademie, она еще круче. Побываете на октоберфесте заодно.
А среди вышеперечисленного есть аналоги по функционалу Selenium для мобильного браузера? Очень интересует возможность тестировать поведение мобильных веб-страницы в нативных браузерах.
Остается надеяться, что Вы знаете, что нужно пользователю.
А на каком физическом принципе это работает?
Возможно, имелись в виду сами девайсы?
Могу предложить решение — сделайте главную страницу виджетной (для этого надо настроить какой-либо имеющийся виджет, добавить/удалить виджет, просто переместить виджеты). Плашка изменит форму и все будет OK.
А началось с древнего аниме Odin: Photon Sailer Starlight 1985 года…
В оригинале статьи (по ссылке источник) нет ни слова про солнечный ветер.
Должно быть, имеет место непонимания различия между солнечным ветром (ионизированные частицы) и световым давлением (электромагнитное излучение).

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Registered
Activity