Автоматизиране на десктопен GUI на Python + pywinauto: как да се съчетаят c MS UI Automation

Библиотека Python pywinauto — това е проект с отворен код за автоматизация на настолни GUI приложения в Windows. През последните две години се появиха нови значителни функции:

• Поддръжка на технологията MS UI Automation. Интерфейсът остава същият, и сега се поддържат: WinForms, WPF, Qt5, Windows Store (UWP) и много други — почти всичко, което съществува в Windows.
• Система за бекенди/плъгини (в момента има два: по подразбиране "win32" и новия "uia"). Плавно се насочваме към крос-платформеност.
• Win32 хукове за мишка и клавиатура (горещи клавиши в духа на pyHook).

Също така ще направим кратък преглед на опциите с отворен код за настойчива автоматизация (без претенции за сериозно сравнение).

Тази статия е частично тълкуване на доклад от конференцията SQA Days 20 в Минск (запис на видео и слайдове), частично българска версия Ръководство за начинаещи за pywinauto.

• Основни подходи
  • Метод на координатите
  • Разпознаване на стандартни изображения
  • Технологии за достъпност
• Основни технологии за настолна достъпност
  • Старият добър Win32 API
  • Microsoft UI Automation
  • AT-SPI (Linux)
  • Apple Accessibility API
• Как да започнете работа с pywinauto
  • Точки за вход за автоматизация
  • Спецификации на прозорци/елементи
  • Магия на достъпа по атрибут и ключ
  • Пет правила за магически имена

Нека започнем с кратък преглед на отворените технологии в тази област. За настолни GUI приложения е малко по-сложно, отколкото за уеб, който има Selenium. Ето основните подходи:

Метод на координатите

Хардкодим точки на кликване, се надяваме на успех.
[+] Крос-платформен, лесно реализируем.
[+] Лесно да се направи "record-replay" запис на тестове.
[-] Най-нестабилен към промени в резолюцията на екrana, теми, шрифтове, размери на прозорци и т.н.
[-] Необходими са огромни усилия за поддръжка, често е по-лесно да се генерират тестовете от нулата или да се тестват ръчно.
[-] Автоматизира само действия, за верификация и извличане на данни има други методи.

Инструменти (крос-платформени): autopy, PyAutoGUI, PyUserInput и много други. Обикновено по-сложните инструменти включват тази функционалност (не винаги крос-платформени).

Струва си да се каже, че методът на координатите може да допълва останалите подходи. Например, за собствена графика може да кликнете на относителни координати (от левия горен ъгъл на прозореца/елемента, а не на целия екран) — обикновено това е достатъчно надеждно, особено ако вземем предвид дължината/ширината на целия елемент (тогава и различната резолюция на екрана не би попречила).

Друг вариант: да се избере само една машина за тестове със стабилни настройки (не крос-платформен, но в някои случаи става).

Разпознаване на стандартни изображения

[+] Крос-платформен
[+-] Относително надежден (по-добре от координатния метод), но все пак изисква хитрости.
[-+] Относително бавен, тъй като изисква ресурсите на CPU за алгоритми за разпознаване.
[-] За разпознаване на текст (OCR), обикновено няма говор => не може да се извлекат текстови данни. Доколкото ми е известно, съществуващите OCR решения не са особено надеждни за този тип задачи и не се използват широко (добре дошли в коментарите, ако това вече не е така).

Инструменти: Sikuli, Lackey (съвместим с Sikuli, на чист Python), PyAutoGUI.

Технологии за достъпност

[+] Най-надеждният метод, тъй като позволява търсене по текст, независимо от това как е нарисуван от системата или фреймворка.
[+] Позволява извличане на текстови данни => по-лесно е да се верифицират резултатите от тестовете.
[+] Обикновено е най-бързият, тъй като почти не изразходва ресурси на CPU.
[-] Трудно е да се направи крос-платформен инструмент: абсолютно всички open-source библиотеки поддържат една-две технологии за достъпност. Windows/Linux/MacOS не се поддържа напълно от никого, освен от платени като TestComplete, UFT или Squish.
[-] Не винаги такава технология е налична изобщо. Например, тестването на зареждащия екран вътре в VirtualBox — тук без разпознаване на изображения не може да се мине. Но в много класически случаи все пак подходът за достъпност е приложим. В следващата част ще стане въпрос за него.

Инструменти: TestStack.White на C#, Winium.Desktop на C# (съвместим със Selenium), MS WinAppDriver на C# (съвместим с Appium), pywinauto, pyatom (съвместим с LDTP), Python-UIAutomation-for-Windows, RAutomation на Ruby, LDTP (Linux Desktop Testing Project) и неговата Windows версия Cobra.

LDTP — вероятно единственият крос-платформен open-source инструмент (по-скоро семейство от библиотеки) на базата на технологии за достъпност. Въпреки това, той не е особено популярен. Аз самият не съм го използвал, но по отзиви интерфейсът му не е най-удобният. Ако има позитивни отзиви, моля, споделете в коментарите.

Тестов backdoor (а.к.а. вътрешен велосипед)

За крос-платформени приложения самите разработчици често създават вътрешен механизъм за осигуряване на testability. Например, създават служебен TCP сървър в приложението, тестовете се свързват към него и изпращат текстови команди: какво да се натисне, откъде да се вземат данни и т.н. Надеждно, но не универсално.

Основни технологии за настолна достъпност

Старият добър Win32 API

Повечето Windows приложения, написани преди WPF и след това Windows Store, са изградени по един или друг начин на Win32 API. А именно, MFC, WTL, C++ Builder, Delphi, VB6 — всички тези инструменти използват Win32 API. Дори Windows Forms — в значителна степен съвместими с Win32 API.

Инструменти: AutoIt (подобен на VB) и Python обвивка pyautoit, AutoHotkey (собствен език, има IDispatch COM интерфейс), pywinauto (Python), RAutomation (Ruby), win32-autogui (Ruby).

Microsoft UI Automation

Основното предимство: технологията MS UI Automation поддържа огромното мнозинство от GUI приложения на Windows с редки изключения. Проблемът: тя не е много по-лесна за изучаване от Win32 API. В противен случай никой нямаше да прави обвивки над нея.

Всъщност, това е набор от custom COM интерфейси (предимно, UIAutomationCore.dll), а също така има .NET обвивка под формата на namespace System.Windows.Automation. Между другото, тя има внесен бъг, поради който някои UI елементи могат да бъдат пропуснати. Затова е по-добре да се използва UIAutomationCore.dll директно (ако сте чували за UiaComWrapper на C#, това е то).

Видове COM интерфейси:

(1) Основен IUknown — „коренът на злото“. Най-ниското ниво, никак не user-friendly.
(2) IDispatch и производни (например, Excel.Application), които могат да се използват в Python с помощта на пакета win32com.client (включен в pyWin32). Най-удобният и красив вариант.
(3) Custom интерфейси, с които работи външен Python пакет comtypes.

Инструменти: TestStack.White на C#, pywinauto 0.6.0+, Winium.Desktop на C#, Python-UIAutomation-for-Windows (тяхният изходен код на C обвивки над UIAutomationCore.dll не е разкрит), RAutomation на Ruby.

AT-SPI

Въпреки че почти всички дистрибуции от семейството на Linux са построени върху X Window System (в Fedora 25 „иксите“ бяха заменени с Wayland), „иксите“ позволяват работа само с прозорци на върхово ниво и мишка/клавиатура. За подробен анализ по бутони, списъчни кутии и т.н. — съществува технология AT-SPI. Най-популярните прозоречни мениджъри имат така наречения AT-SPI регистров демон, който осигурява автоматизируем GUI за приложения (както минимум поддържат Qt и GTK).

Инструменти: pyatspi2.

pyatspi2, на мое мнение, съдържа твърде много зависимости от типа на същия PyGObject. Самата технология е достъпна под формата на обикновена динамична библиотека libatspi.so. Има Reference Manual. За библиотеката pywinauto планираме да реализираме поддръжка на AT-SPI точно така: чрез зареждане на libatspi.so и модул ctypes. Има малък проблем само в използването на нужната версия, тъй като за приложенията на GTK+ и Qt те са малко различни. Вероятният релиз на pywinauto 0.7.0 с пълна поддръжка за Linux може да се очаква през първата половина на 2018 г.

Apple Accessibility API

В MacOS има собствен език за автоматизация AppleScript. За реализиране на нещо подобно в Python, разбира се, трябва да се използват функции от ObjectiveC. Започвайки, изглежда, още от MacOS 10.6, в предварително инсталираната версия на Python се включва пакетът pyobjc. Това също така ще опрости списъка с зависимости за бъдеща поддръжка в pywinauto.

Инструменти: Освен езика Apple Script, трябва да обърнете внимание на ATOMac, известен още като pyatom. Той е съвместим по интерфейса с LDTP, но също така е самостоятелна библиотека. Има пример за автоматизация на iTunes в macOS, написан от моя студент. Има известен проблем: не работят гъвкавите тайминги (методите waitFor*). Но, като цяло, е неплоха работа.

Как да започнете работа с pywinauto

Първоначално е добре да се екипирате с инспектора на GUI обекти (това, което наричат Spy tool). Той ще помогне да се изучи приложението отвътре: как е изградена йерархията на елементите, какви свойства са налични. Най-известните инспектори на обекти са:

• Spy++ — част от Visual Studio, включително Express или Community Edition. Използва Win32 API. Също така е известен клонът му AutoIt Window Info.
• Inspect.exe — част от Windows SDK. Ако е инсталиран, можете да го намерите на 64-битова Windows в папката C:Program Files (x86)Windows Kits<winver>binx64. В самия инспектор е нужно да изберете режим UI Automation вместо MS AA (Active Accessibility, предшественик на UI Automation).

След като разгледате приложението, избирате бекенда, който ще използвате. Достатъчно е да посочите името на бекенда при създаване на обект Application.

• backend=»win32″ — все още се използва по подразбиране, добре работи с MFC, WTL, VB6 и други наследствени приложения.
• backend=»uia» — нов бекенд за MS UI Automation: идеално работи с WPF и WinForms; също е добър за приложения на Delphi и Windows Store; работи с Qt5 и някои Java приложения. И като цяло, ако Inspect.exe вижда елементите и техните свойства, значи този бекенд е подходящ. Всъщност, повечето браузъри също поддържат UI Automation (Mozilla по подразбиране, а за Chrome при стартиране е нужно да му подадете команден ключ --force-renderer-accessibility, за да видите елементите на страниците в Inspect.exe). Разбира се, конкуренцията с Selenium в тази област едва ли е възможна. Просто още един начин за работа с браузър (може да е полезен за крос-продуктови сценарии).

Точки за вход за автоматизация

Приложението е достатъчно проучено. Време е да създадете обект Application и да го стартирате или да се присъедините към вече стартирано. Това не е просто клонинг на стандартния клас subprocess.Popen, именно въведен обект, който ограничава всички ваши действия в границите на процеса. Това е много полезно, ако са стартирани няколко инстанции на приложението, а не искате да засягате останалите.

from pywinauto.application import Application
app = Application(backend="uia").start('notepad.exe')

# Описваме прозореца, който искаме да намерим в процеса Notepad.exe
dlg_spec = app.UntitledNotepad
# изчакваме прозорецът наистина да се появи
actionable_dlg = dlg_spec.wait('visible')

Ако искате да управлявате веднага няколко приложения, класът ще ви помогне Работен плот. Например, в калкулатора на Win10 иерархията на елементите е разпъната по няколко процеса (не само calc.exe). Така че без обект Работен плот не можете да минете.

from subprocess import Popen
from pywinauto import Desktop

Popen('calc.exe', shell=True)
dlg = Desktop(backend="uia").Calculator
dlg.wait('visible')

Кореновият обект (Приложение или Работен плот) е единственото място, където трябва да посочите бекенда. Всичко останало прозрачно се вписва в концепцията "спецификация->обвивка", за която ще стане въпрос по-нататък.

Спецификации на прозорци/елементи

Това е основната концепция, на която се базира интерфейсът на pywinauto. Можете да опишете прозорец/елемент приблизително или по-подробно, дори ако той все още не съществува или вече е затворен. Спецификацията на прозореца (обект WindowSpecification) съхранява критериите, по които да се търси реален прозорец или елемент.

Пример за детайлна спецификация на прозореца:

>>> dlg_spec = app.window(title='Untitled - Notepad')

>>> dlg_spec


>>> dlg_spec.wrapper_object()

Самото търсене на прозореца се извършва чрез извикването на метода .wrapper_object(). Той връща някакъв "обвивка" за реалния прозорец/елемент или хвърля ElementNotFoundError (понякога ElementAmbiguousError, ако са намерени няколко елемента, т.е. необходимо е да се уточнят критериите за търсене). Тази "обвивка" вече може да извършва определени действия с елемента или да получава данни от него.

Python може да скрие извикването, така че крайният код да стане по-кратък. Препоръчваме да го използвате само за отстраняване на проблеми. Следващите две реда правят абсолютно едно и също: .wrapper_object()dlg_spec.wrapper_object().minimize() # отстраняване на проблеми dlg_spec.minimize() # продукция

Има много критерии за търсене за спецификацията на прозореца. Ето само няколко примера:

Списък на всички възможни критерии можете да намерите в документацията на функцията

# могут иметь несколько уровней
app.window(title_re='.* - Notepad$').window(class_name='Edit')

# можно комбинировать критерии (как AND) и не ограничиваться одним процессом приложения
dlg = Desktop(backend="uia").Calculator
dlg.window(auto_id='num8Button', control_type='Button')

pywinauto.findwindows.find_elements(…) Python опростява създаването на спецификации на прозорците и разпознава атрибутите на обекта динамично (вътре е презаписан методът.

Магия на достъпа по атрибут и ключ

__getattribute__ __getattribute__). Разбира се, името на атрибута подлежи на същите ограничения, както и името на всяка променлива (не можете да вмъквате пробели, запетайки или други специални символи). За щастие, pywinauto използва така наречения алгоритъм за „най-добро съвпадение“, който е устойчив на печатни грешки и малки вариации.

app.UntitledNotepad
# същото като
app.window(best_match='UntitledNotepad')

Ако все пак са необходими Unicode строки (например за руски език), пробелите и т.н., можете да получите достъп по ключ (като че ли е обикновен речник):

app['Untitled - Notepad']
# същото като
app.window(best_match='Untitled - Notepad')

Пет правила за магически имена

Как да разберете стандартните магически имена? Тези, които се присвояват на елемента преди търсенето. Ако зададете име, което е доста близко до стандартното, значи елементът ще бъде намерен.

1. По заглавието (текст, име): app.Properties.OK.click()
2. По текста и по типа на елемента: app.Properties.OKButton.click()
3. По типа и по номера: app.Properties.Button3.click() (имената Button0 и Button1 са свързани с първия намерен елемент, Button2 — с втория, и нататък по реда — това е исторически установено)
4. По статичния текст (отляво или отгоре) и по типа: app.OpenDialog.FileNameEdit.set_text("") (полезно за елементи с динамичен текст)
5. По типа и по текста вътре: app.Properties.TabControlSharing.select("General")

Обикновено две-три правила се прилагат едновременно, рядко повече. За да проверите какви конкретни имена са налични за всеки елемент, можете да използвате метода print_control_identifiers(). Той може да отпечата дървото на елементите както на екрана, така и в файл. За всеки елемент се отпечатват неговите стандартни магически имена. Също така можете да копирате оттам по-подробни спецификации на дочерните елементи. Резултатът в скрипта ще изглежда така:

app.Properties.child_window(title="Contains:", auto_id="13087", control_type="Edit")

Самото дърво на елементите — обикновено доста голяма поредица.

>>> app.Properties.print_control_identifiers()

Идентификатори на контрол:

Диалог - 'Windows NT Properties' (L688, T518, R1065, B1006)
[u'Windows NT PropertiesDialog', u'Dialog', u'Windows NT Properties']
child_window(title="Windows NT Properties", control_type="Window")
   |
   | Изображение - '' (L717, T589, R749, B622)
   | [u'', u'0', u'Image1', u'Image0', 'Image', u'1']
   | child_window(auto_id="13057", control_type="Image")
   |
   | Изображение - '' (L717, T630, R1035, B632)
   | ['Image2', u'2']
   | child_window(auto_id="13095", control_type="Image")
   |
   | Редактиране - 'Име на папката:' (L790, T596, R1036, B619)
   | [u'3', 'Edit', u'Edit1', u'Edit0']
   | child_window(title="Folder name:", auto_id="13156", control_type="Edit")
   |
   | Статичен текст - 'Тип:' (L717, T643, R780, B658)
   | [u'Type:Static', u'Static', u'Static1', u'Static0', u'Type:']
   | child_window(title="Type:", auto_id="13080", control_type="Text")
   |
   | Редактиране - 'Тип:' (L790, T643, R1036, B666)
   | [u'4', 'Edit2', u'Type:Edit']
   | child_window(title="Type:", auto_id="13059", control_type="Edit")
   |
   | Статичен текст - 'Местоположение:' (L717, T669, R780, B684)
   | [u'Location:Static', u'Location:', u'Static2']
   | child_window(title="Location:", auto_id="13089", control_type="Text")
   |
   | Редактиране - 'Местоположение:' (L790, T669, R1036, B692)
   | ['Edit3', u'Location:Edit', u'5']
   | child_window(title="Location:", auto_id="13065", control_type="Edit")
   |
   | Статичен текст - 'Размер:' (L717, T695, R780, B710)
   | [u'Size:Static', u'Size:', u'Static3']
   | child_window(title="Size:", auto_id="13081", control_type="Text")
   |
   | Редактиране - 'Размер:' (L790, T695, R1036, B718)
   | ['Edit4', u'6', u'Size:Edit']
   | child_window(title="Size:", auto_id="13064", control_type="Edit")
   |
   | Статичен текст - 'Размер на диска:' (L717, T721, R780, B736)
   | [u'Size on disk:', u'Size on disk:Static', u'Static4']
   | child_window(title="Size on disk:", auto_id="13107", control_type="Text")
   |
   | Редактиране - 'Размер на диска:' (L790, T721, R1036, B744)
   | ['Edit5', u'7', u'Size on disk:Edit']
   | child_window(title="Size on disk:", auto_id="13106", control_type="Edit")
   |
   | Статичен текст - 'Съдържа:' (L717, T747, R780, B762)
   | [u'Contains:1', u'Contains:0', u'Contains:Static', u'Static5', u'Contains:']
   | child_window(title="Contains:", auto_id="13088", control_type="Text")
   |
   | Редактиране - 'Съдържа:' (L790, T747, R1036, B770)
   | [u'8', 'Edit6', u'Contains:Edit']
   | child_window(title="Contains:", auto_id="13087", control_type="Edit")
   |
   | Изображение - 'Съдържа:' (L717, T773, R1035, B775)
   | [u'Contains:Image', 'Image3', u'Contains:2']
   | child_window(title="Contains:", auto_id="13096", control_type="Image")
   |
   | Статичен текст - 'Създаден:' (L717, T786, R780, B801)
   | [u'Created:', u'Created:Static', u'Static6', u'Created:1', u'Created:0']
   | child_window(title="Created:", auto_id="13092", control_type="Text")
   |
   | Редактиране - 'Създаден:' (L790, T786, R1036, B809)
   | [u'Created:Edit', 'Edit7', u'9']
   | child_window(title="Created:", auto_id="13072", control_type="Edit")
   |
   | Изображение - 'Създаден:' (L717, T812, R1035, B814)
   | [u'Created:Image', 'Image4', u'Created:2']
   | child_window(title="Created:", auto_id="13097", control_type="Image")
   |
   | Статичен текст - 'Атрибути:' (L717, T825, R780, B840)
   | [u'Attributes:Static', u'Static7', u'Attributes:']
   | child_window(title="Attributes:", auto_id="13091", control_type="Text")
   |
   | Чекбокс - 'Само за четене (Приложимо само за файлове в папката)' (L790, T825, R1035, B841)
   | [u'CheckBox0', u'CheckBox1', 'CheckBox', u'Read-only (Only applies to files in folder)CheckBox', u'Read-only (Only applies to files in folder)']
   | child_window(title="Read-only (Only applies to files in folder)", auto_id="13075", control_type="CheckBox")
   |
   | Чекбокс - 'Скрит' (L790, T848, R865, B864)
   | ['CheckBox2', u'HiddenCheckBox', u'Hidden']
   | child_window(title="Hidden", auto_id="13076", control_type="CheckBox")
   |
   | Бутон - 'Разширени...' (L930, T845, R1035, B868)
   | [u'Advanced...', u'Advanced...Button', 'Button', u'Button1', u'Button0']
   | child_window(title="Advanced...", auto_id="13154", control_type="Button")
   |
   | Бутон - 'ОК' (L814, T968, R889, B991)
   | ['Button2', u'OK', u'OKButton']
   | child_window(title="OK", auto_id="1", control_type="Button")
   |
   | Бутон - 'Отмяна' (L895, T968, R970, B991)
   | ['Button3', u'CancelButton', u'Cancel']
   | child_window(title="Cancel", auto_id="2", control_type="Button")
   |
   | Бутон - 'Прилагане' (L976, T968, R1051, B991)
   | ['Button4', u'ApplyButton', u'Apply']
   | child_window(title="Apply", auto_id="12321", control_type="Button")
   |
   | TabControl - '' (L702, T556, R1051, B962)
   | [u'10', u'TabControlSharing', u'TabControlPrevious Versions', u'TabControlSecurity', u'TabControl', u'TabControlCustomize']
   | child_window(auto_id="12320", control_type="Tab")
   |    |
   |    | TabItem - 'Общи' (L704, T558, R753, B576)
   |    | [u'GeneralTabItem', 'TabItem', u'General', u'TabItem0', u'TabItem1']
   |    | child_window(title="General", control_type="TabItem")
   |    |
   |    | TabItem - 'Споделяне' (L753, T558, R801, B576)
   |    | [u'Sharing', u'SharingTabItem', 'TabItem2']
   |    | child_window(title="Sharing", control_type="TabItem")
   |    |
   |    | TabItem - 'Сигурност' (L801, T558, R851, B576)
   |    | [u'Security', 'TabItem3', u'SecurityTabItem']
   |    | child_window(title="Security", control_type="TabItem")
   |    |
   |    | TabItem - 'Предишни версии' (L851, T558, R947, B576)
   |    | [u'Previous VersionsTabItem', u'Previous Versions', 'TabItem4']
   |    | child_window(title="Previous Versions", control_type="TabItem")
   |    |
   |    | TabItem - 'Персонализиране' (L947, T558, R1007, B576)
   |    | [u'CustomizeTabItem', 'TabItem5', u'Customize']
   |    | child_window(title="Customize", control_type="TabItem")
   |
   | TitleBar - 'Няма' (L712, T521, R1057, B549)
   | ['TitleBar', u'11']
   |    |
   |    | Меню - 'Система' (L696, T526, R718, B548)
   |    | [u'System0', u'System', u'System1', u'Menu', u'SystemMenu']
   |    | child_window(title="System", auto_id="MenuBar", control_type="MenuBar")
   |    |    |
   |    |    | MenuItem - 'Система' (L696, T526, R718, B548)
   |    |    | [u'System2', u'MenuItem', u'SystemMenuItem']
   |    |    | child_window(title="System", control_type="MenuItem")
   |    |
   |    | Бутон - 'Затвори' (L1024, T519, R1058, B549)
   |    | [u'CloseButton', u'Close', 'Button5']
   |    | child_window(title="Close", control_type="Button")

В някои случаи печатането на цялото дърво може да забави производителността (например, в iTunes на една вкладка с цели три хиляди елемента!), но може да се използва параметърът depth (дълбочина): depth=1 — самият елемент, depth=2 — само непосредствените деца и така нататък. Може да се задава и в спецификациите при създаване на child_window.

Примери

Постоянно допълваме списъка с примери в хранилището. От последните, трябва да спомена автоматизацията на мрежовия анализатор WireShark (това е добър пример за приложение на Qt5; въпреки че тази задача може да се решава и без графичен интерфейс, тъй като има scapy.Sniffer от Python пакета scapy). Има и пример за автоматизация на MS Paint с неговия Ribbon инструментариум.

Още един отличен пример, написан от моя студент: плъзгане на файл от explorer.exe на Chrome страница за Google Drive (той ще премине в основното хранилище по-късно).

И, разбира се, пример за абонамент за събития от клавиатурата (горещи клавиши) и мишката:
hook_and_listen.py.

Благодарности

Отделно благодаря на тези, които постоянно помагат за развитието на проекта. За мен и Валентина това е постоянно хоби. Двама от моите студенти от ННГУ наскоро защитиха бакалавърските си степени по тази тема. Александър направи голям принос в поддръжката на MS UI Automation и наскоро започна да разработва автоматичен генератор на код по принципа „запис-възпроизвеждане“ на основата на текстови свойства (това е най-сложната функция), засега само за бекенда „uia“. Иван разработва нов бекенд под Linux на основата на AT-SPI (модулите mouse и keyboard на база python-xlib — вече са в версии 0.6.x).

Тъй като от доста време преподавам специален курс по автоматизация на Python, част от магистърските студенти изпълняват домашни задания, реализирайки малки функции или примери за автоматизация. Някои ключови неща в етапа на изследвания също бяха открити от студенти. Въпреки че понякога трябва да следя качеството на кода. За това много помагат статичните анализатори (QuantifiedCode, Codacy и Landscape) и автоматичните тестове в облака (услугата AppVeyor) с покритие на кода около 95%.

Също така благодаря на всички, които оставят отзиви, създават бъгове и изпращат пул реквести!

Допълнителни ресурси

За въпросите следим по тега на StackOverflow (неотдавна се появи тег в руската версия на SO) и по ключовата дума на Тостера. Има рускоязичен чат в Gitter’е.

Всеки месец обновяваме рейтинга на open-source библиотеки за тестиране на GUI. По количество звезди в GitHub, самоъствременните им растат само Autohotkey (те имат много голяма общност и дълга история) и PyAutoGUI (в значителна степен благодарение на популярността на книгите на нейния автор Al Sweigart: «Automate the Boring Stuff with Python» и други).

Източник: habr.com