Василий Рябов vasily-v-ryabov

Стучатся — не значит, что полностью завоевали рынок. Серверные свитчи с 10Г есть уже пару лет, хоть и дороги. Пользовательский сегмент подтянется очень скоро (в основном, продукты анонсированы или будут в ближайшее время). Доступны в России пока только high end материнки (в основном, геймерские) и PCIe карточки с 10Г. NAS'ы уж больше года есть с 10Г (мне кажется, это наиболее реальное применение на данный момент, хоть оно и не массовое).

Прошу прощения. Видимо, я слишком далёк от мира IoT. Не знал про этот термин. Подумал греншным делом, что cloud так перевели.

Уже куплена неделю назад. :) И коллегам нравится. На Хабре как раз месяц назад статья была с отрывком из неё, так и нашёл.

Отличная статья! По примеру 4: есть аналогичная фишка в Python (разница между time.time() и timeit.default_timer() — такая же, и мы это видели отнюдь не в UI тестах, мы железо тестируем), ещё там же заметил опечатку в коде: в первом куске long en (должно быть long end).

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

Рейтинг тупо по звёздам на гитхабе. Ниже ещё есть по вопросам на StackOverflow, но там я про Appium забыл. В следующем месяце добавлю, он там будет лидером. :)

Так получилось, что pywinauto я использую с 2010 года и начал поддерживать его в опен сорсе с лета 2015-го. Поддержку UIA мы выпустили в ноябре 2016-го, а WinAppDriver появился весной 2016-го. Узнал я про WinAppDriver в июне 2017-го. В этом году гонка продолжается. Мы уже год работаем над "record-replay" фичей (планируем релизить осенью, думали, что будем первыми в опен сорсе с подобным), а Microsoft взял да и выпустил свой UI Recorder в июне этого года. Правда, я его пробовал и пока не смог получить ничего вменяемого.

Вообще, умеет. Как раз майкрософтовский WinAppDriver совместим с Appium, и там есть на 14-м месте appium-for-mac. :)

А десктоп мало чем тестируется, и не всякий. Из юзабельных — топ-12 из рейтинга, который я обновляю раз в месяц. На каждой оси — свои технологии доступа к текстовым свойствам. На Windows большинство покрывается технологией MS UI Automation API: она сложна, поэтому есть более простые в освоении библиотеки (это pywinauto, TestStack.White, MS WinAppDriver, FlaUI и Winium.Desktop). На Линуксе это AT-SPI, но там реально простых библиотек пока нет, есть зубодробительные. На макоси есть встроенный AppleScript и pyatom — очень даже годный, хоть и Python2.7 только и в установке не очень прост. Я со своими студентами пытаюсь все эти технологии собрать в pywinauto в максимально простом виде, тут ещё 2-3 года работы, учитывая, что это хобби (на основной работе я сейчас вообще не GUI занимаюсь). Ещё есть распознавалки эталонных картинок типа Sikuli, pyautogui, lackey. Они менее надёжны и подкушивают CPU, но зато универсальней не придумаешь.

Привет от декстопников. Для десктопного UI точно так же полезно детальнее указывать, где именно находится кнопка, какой у неё class_name, title и так далее. Какие-то вещи вроде ControlID или обычного индекса лучше не использовать. В общем, некоторые отличия разве что в списке стабильных и не очень стабильных пропертей/локаторов.

Что касается вменяемых ошибок, то это вообще к любому коду относится, не только к тестам.

Ну, и под инфраструктуру Selenium есть майкрософтовский WinAppDriver. Они нас внезапно опередили с релизом UI Recorder'а — они пока единственные с такой фичей в опен сорсе (правда, я ещё не пробовал, но полагаю, что он тоже на текстовых свойствах, иначе смысла нет).

Из годных топ-12 вот отсюда: https://github.com/pywinauto/pywinauto/wiki/UI-Automation-tools-ratings Из них pyautogui, sikuli и lackey работают фактически только с картинками, autopy — вообще только с голой мышкой и клавиатурой. Остальные в той или иной степени с текстовыми свойствами элементов (как правило, на одной оси). Из быстрорастущих тулов под C# можно отметить молодой проект FlaUI, автор которого занимался поддержкой TestStack.White, но плюнул и решил сделать с нуля.

SWAPY сейчас не поддерживается. Он совместим только со старой версией pywinauto 0.5.4, где был единственный backend="win32" и все методы в стиле CamelCase. Вроде бы на третьем питоне он работал. В любом случае, pywinauto 0.5.4 работает на третьем питоне, как и более новые.

Вообще, у меня студенты набросали инспектор объектов: https://github.com/pywinauto/py_inspect
Всего на 150 строк кода. Правда, полуручного генератора скриптов там нет, зато можно переключать бэкенды. В будущем мы хотим вернуться к нему и полноценно встроить в экосистему, если раньше кто-нибудь не поможет.

Сейчас главные приоритеты — это генератор скриптов в стиле "record-replay" и поддержка Линукса.

На здоровье! Осталось только machine learning прикрутить. :) Акциями же торгуют боты, почему мебелью нельзя?

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

Грустная история. Мне как раз интересно было, как ребята Яндекс.Браузер тестируют…
История с велосипедом, оставшимся внутри компании, не нова. Почему-то мало кто опен сорсит код в этой нише.

Возможно, в этом конкретном случае comtypes и бессилен (пардон, пока не вникал глубоко), но он точно умеет больше, чем win32com.client. Мы его используем, подгружая UIAutomationCore.dll, где тоже нет IDispatch.

Такого мнения ещё не встречал. Так что на этом месте прошу подробнее. Просто не нравится или мешает чему-то конкретному?

Можно. Впрочем, недавно нашёл способ проще: через удалённый psexec с ключом -i. Работает всегда и без бубнов с VNC сервером. Хоть из-под Jenkins, хоть из-под Ansible.

О, спасибо за полную расшифровку доклада! В картинках оно явно лучше зашло, чем скучным текстом.

Можно. Нормальная ссылка на чат.
Нормальная ссылка на слайды (там всё clickable).

Да, и это тоже, кстати. Спасибо!

Кто начал разбираться, мог бы погуглить. Подобная статья уже была на Хабре в 2011-м: https://habrahabr.ru/post/130690/ Тогда она была более своевременной, хоть и написана более сложным языком. Если есть цель сделать хорошую обучающую статью (это хорошая цель), то здесь объём всё же маловат для целой статьи. Если это отправная точка подхода, можно было и про подход развернуть. Опять же, сугубо моё мнение.

Да я знаю, искал когда-то. .NET машину поднять несложно. Надо ещё и DLL заинжектить. Но не суть важно. Просто пример привёл, какой минимальной сложности вопросы должны подниматься на Хабре (сугубо моё мнение), чтобы не понижать планку ресурса.

Вот здесь кое-что упомянуто. Сам не пробовал. Не уверен, что он использует именно AT-SPI. Планируем сделать собственный инспектор объектов в комплекте, в том числе для AT-SPI. На PyQt5 с учётом архитектуры pywinauto такой инспектор делается за сотню строк кода максимум. Конечно, когда будет готов AT-SPI бэкенд в pywinauto.