Десктоп проект что это
На чем писать мультиплатформенное desktop-приложение? Взгляд менеджера
Сегодня авторы большинства приложений уже не могут позволить себе выпускаться под одну платформу. Early adopters сидят под маками, мейнстрим сидит под Win32, а гики и адепты open source предпочитают Linux. Каждая из этих аудиторий обладает уникальными свойствами, а поэтому важна для большинства проектов.
Данная статья задумывалась как открытая попытка разобраться, на чем стоит писать мультиплатформенное desktop-приложение. Приглашаю высказать свое мнение людей с опытом создания таких приложений.
Изначально определим критерии, по которым будем оценивать различные платформы. В первую очередь — это удобство пользователя. Уверен, что вы замечали общие черты у приложений, написанных под разные платформы. Во вторую — это интересы проекта. Моя задача — построить успешный бизнес, а не играться с различными инструментами.
Обозначим рамки исследования. Мое приложение — небольшая утилита для пользователя-«чайника», которая качает файлы из интернета: минимум GUI, небольшой набор функциональности, использование внешних С++ библиотек.
Ну что, начнем. Какие есть варианты? Я рассмотрю Java, C#, C++, Python. Буду рад, если вы расскажите о других альтернативах.
Данный язык/среда изначально задумывались как нечто мультиплатформенное. На Java написано большое количество приложений, крупные проекты вроде Eclipse используют именно этот фреймворк.
Все приложения, которыми мне доводилось пользоваться, не использовали «родной» интерфейс Win32. Не знаю, чем руководствовались разработчики, но с точки зрения конечного пользователя это выглядит очень не симпатично.
Примеры приложений: Eclipse, ZDE, клиент для Gnutella Limewire.
Плюсы: мультиплатформенность, большое количество кадров, развитость фреймворка.
Минусы: необходимость установки фреймворка, кривость GUI, низкая производительность.
Аналогично с Java, приложения на C# имеют большой минус — необходимость устанавливать фреймворк. Я сам отказался от установки несколько приложений, которые требовали этого фреймворка. Менее продвинутые пользователи будут ещё более требовательными.
В остальном — сплошные плюсы, на мой взгляд.
Примеры приложений😕
Плюсы: мультиплатформенность, большое количество кадров, хорошая производительность, развитость фреймворка.
Минусы: необходимость установки фреймворка.
Старичок дотянул до наших дней и замечательно себя чувствует. Много приложений под платформы Linux и Windows до сих пор пишутся на этом языке.
Программы, написанные на C++, являются примером для других по размеру дистрибутива и экономному использованию системных ресурсов (процессор, память). Тем не менее у разработчиков есть масса претензий к С++. По моему мнению, язык является «устаревшим» и его популярность в дальнейшем будет снижаться, что подтверждается индексом TIOBE.
С точки зрения развития проекта, по сравнению с динамическими интерпретируемыми языками (вроде Ruby и Python), разработка на данном языке может иметь менее высокую скорость и более высокие издержки изменения проекта. Для стартапа, которому не столь важна производительность приложения, это может стать существенным минусом.
Примеры: Firefox.
Плюсы: отличная производительность, большое количество кадров, большое количество библиотек.
Минусы: невысокая скорость разработки.
Python
Взглянуть на Python в качестве платформы для desktop-приложений меня заставила программа MusicBrainz Picard. Несмотря на свою скриптовую сущность, Python легко собирается в один exe-файл, не требуя от пользователя установки дополнительных компонентов.
В случае разработки небольшого приложения, интерпретируемые языки вроде Python будут большим плюсом. Легкость написания и высокая скорость изменения приложения пригодится любому стартапу.
Огромным минусом различных «модных» технологий является их низкое распространение, а значит серьезные проблемы в поиске квалифицированных кадров. Ситуация с поиском программистов итак плачевная, а если ограничиться узким языком — можно вообще никого не найти. С другой стороны, храбрость перейти на новый язык имеют наиболее прогрессивные разработчики. Может получиться так, что выбрав «перспективный» язык, мы сразу отсечем миллионы середнячков, оставив себе выбор из нескольких перспективных разработчиков.
Пример: MusicBrainz Picard, оригинальный BitTorrent.
Плюсы: высокая скорость разработки и изменений, хорошая интеграция с библиотеками на С и С++.
Минусы: мало кадров, низкая производительность.
Выводы
К сожалению, любая из вышеперечисленных платформ имеет свои плюсы и минусы, однозначного решения найти не удалось. Выбор одной из них сегодня принесет преимущества и недостатки, влияние которых на проект мы увидим только завтра.
Я пока выбираю между С++ и Python. Первый является «надежным» решением с известными недостатками. Второй является «рискованным», но интересным и перспективным. Надеюсь, ваши отзывы помогут мне сделать окончательный выбор. Какую платформу выбрали бы вы на моем месте?
PS. Я сейчас ищу программистов в этот стартап (с++/python/php), поэтому если кому интересно — присылайте свое резюме.
Десктопное приложение на Python: UI и сигналы
Авторизуйтесь
Десктопное приложение на Python: UI и сигналы
Считается, что Python не лучший выбор для десктопных приложений. Однако, когда в 2016 году я собирался переходить от разработки сайтов к программному обеспечению, Google подсказал мне, что на Python можно создавать сложные современные приложения. Например blender3d, который написан на Python.
Но люди, не по своей вине используют уродливые примеры графического интерфейса, которые выглядят слишком старыми, и не понравятся молодёжи. Я надеюсь изменить это мнение в своем туториале. Давайте начнём.
Мы будем использовать PyQt (произносится «Пай-Кьют»). Это фреймворк Qt, портированный с C++. Qt известен тем, что необходим C++ разработчикам. С помощью этого фреймворка сделаны blender3d, Tableau, Telegram, Anaconda Navigator, Ipython, Jupyter Notebook, VirtualBox, VLC и другие. Мы будем использовать его вместо удручающего Tkinter.
Требования
Установка
Вам нужно установить только PyQt. Откройте терминал и введите команду:
Мы будем использовать PyQt версии 5.15. Дождитесь окончания установки, это займёт пару минут.
Hello, World!
Создайте папку с проектом, мы назовём его helloApp. Откройте файл main.py, лучше сделать это vscode, и введите следующий код:
Этот код вызывает QGuiApplication и QQmlApplicationEngine которые используют Qml вместо QtWidget в качестве UI слоя в Qt приложении. Затем, мы присоединяем UI функцию выхода к главной функции выхода приложения. Теперь они оба закроются одновременно, когда пользователь нажмёт выход. Затем, загружаем qml файл для Qml UI. Вызов app.exec(), запускает приложение, он находится внутри sys.exit, потому что возвращает код выхода, который передается в sys.exit.
Добавьте этот код в main.qml:
Этот код создает окно, делает его видимым, с указанными размерами и заголовком. Объект Text отображается в середине окна.
Теперь давайте запустим приложение:
Вы увидите такое окно:
Обновление UI
Давайте немного обновим UI, добавим фоновое изображение и время:
Внутри типа ApplicationWindow находится содержимое окна, тип Rectangle заполняет пространство окна. Внутри него находится тип Image и другой прозрачный Rectangle который отобразится поверх изображения.
Если сейчас запустить приложение, то текст появится в левом верхнем углу. Но нам нужен левый нижний угол, поэтому используем отступы:
После запуска вы увидите следующее:
Показываем текущее время
Модуль gmtime позволяет использовать структуру со временем, а strftime даёт возможность преобразовать её в строку. Импортируем их:
Теперь мы можем получить строку с текущим временем:
Строка «%H:%M:%S» означает, что мы получим время в 24 часовом формате, с часами минутами и секундами (подробнее о strtime).
Давайте создадим property в qml файле, для хранения времени. Мы назовём его currTime.
Теперь заменим текст нашей переменной:
Теперь, передадим переменную curr_time из pyhton в qml:
Это один из способов передачи информации из Python в UI.
Запустите приложение и вы увидите текущее время.
Обновление времени
Для того чтобы обновлять время, нам нужно использовать потоки. Для этого я предлагаю использовать сигналы.
Чтобы использовать сигналы нам нужен подкласс QObject. Назовём его Backend.
У нас уже имеется свойства для строки со временем curr_time, теперь создадим свойство backend типа QtObject в файле main.qml.
Передадим данные из Python в qml:
В qml файле один объект QtObject может получать несколько функций (называемых сигналами) из Python.
Создадим тип Connections и укажем backend в его target. Теперь внутри этого типа может быть столько функций, сколько нам необходимо получить в backend.
Таким образом мы свяжем qml и сигналы из Python.
Мы используем потоки, для того чтобы обеспечить своевременное обновление UI. Создадим две функции, одну для управления потоками, а вторую для выполнения действий. Хорошая практика использовать в названии одной из функций _.
Создадим pyqtsignal и назовём его updated, затем вызовем его из функции updater.
В этом коде updated имеет параметр arguments, который является списком, содержащим имя функции «updater». Qml будет получать данные из этой функции. В функции updater мы вызываем метод emit и передаём ему данные о времени.
Обновим qml, получив сигнал, с помощью обработчика, название которого состоит из «on» и имени сигнала:
Теперь нам осталось вызвать функцию updater. В нашем небольшом приложении, использовать отдельную функцию для вызова сигнала не обязательно. Но это рекомендуется делать в больших программах. Изменим задержку на одну десятую секунды.
Функция bootUp должна быть вызвана сразу же после загрузки UI:
Всё готово
Теперь можно запустить программу. Время будет обновляться корректно. Для того, чтобы убрать рамку, вы можете добавить в qml файл следующую строку:
Так должен выглядеть файл main.py:
Вот содержимое файла main.qml:
Сборка приложения
Для сборки десктопного приложения на Python нам понадобится pyinstaller.
Чтобы в сборку добавились все необходимые ресурсы, создадим файл spec:
Настройки файла spec
Параметр datas можно использовать для того, чтобы включить файл в приложение. Это список кортежей, каждый из которых обязательно должен иметь target path(откуда брать файлы) и destination path(где будет находится приложение). destination path должен быть относительным. Чтобы расположить все ресурсы в одной папке с exe-файлами используйте пустую строку.
Измените параметр datas, на путь к вашей папке с UI:
Параметр console установим в false, потому что у нас не консольное приложение.
Параметр name внутри вызова Exe, это имя исполняемого файла. name внутри вызова Collect, это имя папки в которой появится готовое приложение. Имена создаются на основании файла для которого мы создали spec — main.py.
Теперь можно запустить сборку:
В папке dist появится папка main. Для запуска программы достаточно запустить файл main.exe.
Так будет выглядеть содержимое папки с десктопным приложением на Python:
О том, как использовать Qt Designer для создания UI приложений на Python читайте в нашей статье.
Десктопизация по-питоновски. Инструменты для создания автотестов
Автоматизация тестирования – неотъемлемая часть процесса обеспечения качества. Мы в нашей практике чаще всего разрабатываем тесты для веб-, мобильных приложений и API, но сегодня хотим рассказать о более редком направлении – тестировании десктоп-приложений.
Кратко рассмотрим подходы, инструменты, технологии и «грабли», на которые можно наступить при выполнении этой задачи. Статья будет полезна специалистам, которые хотят попробовать автоматизировать ежедневную монотонную работу, а также коллегам по цеху в сфере автоматизации gui-тестирования – как начинающим, так и разработчикам с опытом.
По архитектуре большинство десктоп-решений можно разделить на слои UI, Business, Transport и DB, а по их соотношению – на следующие группы:
standalone-приложения (все слои в одном месте);
клиент-серверные – тонкий клиент» (ui на клиенте, остальное на сервере);
«толстый клиент» (ui и business на клиенте, db-сервер).
Подобные решения чаще всего реализуют в web, чтобы обеспечить их гибкость, кроссплатформенность, легкость в разработке и поддержке. Из-за этой тенденции становится меньше десктоп-проектов, как и запросов на автотесты для них – по нашим наблюдениям, их доля не превышает 5-10% среди других проектов, поэтому для поиска актуального how-to гайда иногда нужно немало времени. Однако, в энтерпрайзе по-прежнему много десктопных приложений, качество работы которых оказывает влияние на бизнес.
Особенности
Рассмотрим несколько особенностей, которые мы учитываем при создании автотестов для десктопа:
Для начала нам нужен активный десктоп. Некоторые методы не смогут отработать, если запустить тесты через RDP и свернуть это окно. К счастью, для этого есть “костыли”:
перехват сессии rdp через tscon на саму себя позволит оставить рабочий стол активным с отключенным соединением;
небольшая правка реестра на хосте оставит активным рабочий стол на удалённой машине, что обеспечит возможность свернуть окно rdp-сессии.
На первый взгляд может показаться, что при работе с приложением с различными локализациями существуют затруднения: например, что некоторые локаторы будут находиться по имени элемента, которое может различаться в разных локализациях. Однако, на практике эти элементы достаточно легко найти по определенным критериям (тип, automation_id, активности и т.д.).
Поиск нужного элемента иногда выливается в интересную историю. Если открыть несколько разных приложений, то число элементов в дереве по ним может добраться до десяти тысяч, что значительно замедлит поиск отдельного элемента. Для того чтобы этого избежать, принято использовать поиск элементов по системе «родитель-наследник». Например, исходное окно приложения будет «родительским» элементом, а тулбар в нём – «дочерним». По мере «хождения» по приложению можно существенно ускорить поиск, отсекая лишние элементы и оставляя только нужную нам ветку. Данный подход имеет свои особенности. Например, некоторые приложения могут кидать popup-окно вне дерева элементов вкладки и даже самого приложения. В таком случае, именно рабочий стол следует принимать как исходный родительский элемент и работать от него.
Взаимодействие с элементами в случае MS UIA может происходит через обычные COM-интерфейсы, но допускается использовать и нестандартные, и это не редкость. Для Python есть библиотека comtypes, которая в связке с CPython решает такие вопросы.
Хотя технология MS UIA и имеет относительно подробную документацию, понять её «с лёту» может быть трудно. Для быстрого погружения можно воспользоваться разделом How-to Topics с полезными советами (на английском, само собой) и примерами кода (С#), но не стоит возлагать на него лишние надежды.
Комьюнити меньше, чем в других направлениях (web, mobile, api), поэтому вы можете столкнуться с недостатком информации.
Подходы
Существуют три основных подхода к автотестам desktop-приложений: координатный метод, распознавание изображений и accessibility. Все реализующие их инструменты взаимодействуют с первым слоем, UI.
Суть координатного метода – в эмулировании клика мыши по указанным координатам. Это самый легко реализуемый и простой метод с большим количеством библиотек. К минусам стоит отнести неустойчивость к изменениям, сложную поддержку тестов и невозможность извлечения данных из приложения.
Распознавание изображений – технология поиска местоположения на экране на основе изображения области или отдельного элемента. Хотя этот метод с каждым годом развивается и совершенствуется, на данный момент его инструменты все еще бывают нестабильны и “прожорливы”. В некоторых кейсах возможно получить значение поля с помощью методологий распознавания текста.
Accessibility-метод – достаточно стабильный и совершенный. Позволяет удобно управлять приложением во время теста, получать и использовать любые атрибуты элементов. Используется привычный подход с локаторами. Сами локаторы можно детектить с помощью инструмента Inspect из пакета Windows SDK.
Инструменты
На Github в топ инструментов для автоматизации десктопа входят следующие:
RobotJS – фреймворк для JavaScript (координатный подходом);
pyautogui – Python-фреймворк (координатный подход + распознавание изображений);
AutoHotkey (C++) – keyword-driven фреймворк (accessibility);
Appium Desktop – один из самых популярных фреймворков для автоматизации мобильных приложений (accessibility);
pywinauto – фреймворк для Python (accessibility).
В одном из наших проектов команда SDET-разработчиков использовала Python, и для относительной унификации процесса разработки и поддержки автотестов мы выбрали фреймворк на этом языке. На основе этого опыта мы предлагаем рассмотреть подробнее несколько инструментов для Python.
1) Pyautogui
Вот несколько примеров команд, которые помогут познакомиться с этим популярным инструментом.
Как получить текущую позицию курсора:
. или размер экрана в целом:
При этом размеры второго экрана выводятся некорректно. Кликаем дважды по точке на экране:
Фреймворк позволяет искать область на основе заранее подготовленного скриншота:
Также можно найти целый список областей:
Помимо этого, фреймворк также умеет работать с клавиатурой и создавать alert-подобные окна с функцией ввода. В документации перечисленные функции описаны подробнее, впрочем, без каких-либо неожиданностей.
2) Lackey (SikuliX)
Библиотеку Lackey мы выбрали как пример инструмента для реализации подхода с распознаванием изображения. Она работает на основе библиотеки Sikuli с использованием “великого и ужасного” OpenCV для распознавания элементов на экране. Сам OpenCV поддерживает, например, технологию CUDA, которая может дать ускорение распознавания в 5-100 раз. Вычислительные мощности видеокарт имеют стабильный ежегодный прирост, и подобные технологии дают хорошую прибавку.
Клик по распознанному элементу:
Документация Lackey составлена достаточно подробно, однако, отдельные вопросы – например, прикручивание CUDA – приходится искать отдельно.
3) Pywinauto
Одна из популярных библиотек в рамках accessibility-подхода. На данный момент поддерживает технологии Win32 API и UIA, но есть подвижки в сторону AT SPI.
Запуск приложения:
Ни для кого не секрет, что поиск рабочих локаторов процесс довольно трудоемкий. В проекте мы использовали инструмент Inspect, он входит в пакет Windows SDK и скачивается отдельно. Фреймворк позволяет нам искать элементы по критериям, которые с лёгкостью можно получить “на лету” через этот инструмент:
Левая половина окна инструмента отражает дерево элементов от рабочего стола и позволяет искать и выбирать инструменты, а правая содержит критерии поиска (в т.ч. координаты относительно края экрана), атрибуты элемента, поддерживаемые паттерны (методы взаимодействия) и список дочерних отношений с другими элементами.
В числе удобных “фишек” инструмента: вывод границ элемента и краткий список атрибутов сразу при наведении, быстрый переход к родительским/дочерним элементам.
Локаторы можно искать и иными путями. Например, список элементов и критерии для их поиска может печатать сам фреймворк через функцию print_control_identifiers.
Открываем закладку бокового меню:
И ожидаем открытия списка с файлами:
Файлов в нашей директории очень много. Ускорим поиск файла, используя родительский элемент из предыдущего шага, и проверим его активность:
Методы в документации описаны довольно подробно, у вас не будет особых трудностей с тем, чтобы разобраться в коде (до момента с подключением comtypes).
Технологии
Фреймворки, которые мы перечислили выше, это своеобразные “обёртки” для технологий, обеспечивающих управление на стороне ОС:
Windows: Win32 API, MS UI Automation
Mac: Apple Accessibility API
Расскажем подробнее о технологиях под Windows, т.к. подавляющее число gui-приложений пишут под эту ОС.
Поддерживаемость архитектур построения приложений
Частично Windows Forms, без WPF
Особенности архитектуры тестового фреймворка
В нашей практике мы чаще всего применяем паттерн Page Object. Однако, так как в десктопе в большинстве случаев вся архитектура строится как “слоистая”, при таком подходе мы получаем достаточно длинную наследуемую цепочку из родительских элементов. Поэтому для того чтобы облегчить читаемость кода, нужно прокачать его до Page Elements, где среди «пейджей» выделяются общие элементы и выносятся в отдельный объект. На этапе проектирования архитектуры важно выстроить иерархию классов (пейджей) и для этого изучить UI приложения. При этом с ростом количества тестов огрехи в архитектуре могут дорого стоить.
Не следует забывать и о паттернах проектирования. Тут нам точно пригодятся двое из ларца – “декоратор” и “посредник”, и вполне вероятно, что в эту компанию может затесаться синглтон.
“Декоратор” в разработке автотестов используется повсеместно. Чаще всего в фикстурах.
При переключении вкладки в одном из пейджей нам необходимо будет сообщить об этом другим пейджам. Тут на помощь придёт “посредник”.
При построении архитектуры автотестов для веб-приложения мы считаем, что у нас есть элемент и десяток методов для взаимодействия с ним. Десктоп “открывает дверь ногой” и представляет нам около 40 разных типов элементов (link): от простого checkbox до сложного DataGrid. Если говорить о количестве методов взаимодействия с каждым из типов, то тот же checkbox мы можем «выделить» 4 разными способами. Случается, что в приложении попадаются и «кастомные» элементы, и «общаться» с ними приходится путём “чёрной уличной магии” – обращения к низкоуровневому comtypes или нативной C#-библиотеке.
Возможные проблемы при автоматизации
Из-за взаимодействия с UI к списку можно смело добавить все «грабли» автоматизации тестирования UI. Как вишенка на торте, встречаются случаи, когда элемент приложения уже существует, но долго инициализируется – и вызов метода управления может не отработать корректно, так как элемент неактивен.
Есть довольно частный кейс с фреймворком pywinauto. Например, в приложении реализован поиск по товарам. Если результат поиска достаточно велик или весь список товаров выводится при открытии окна с поиском, то количество элементов в этом списке будет следующим: количество колонок*кол-во строк в результате*3 (в нашем кейсе). Если строк будет более двух сотен, то pywinauto не справится с таким количеством объектов. Есть подозрения, что и другие фреймворки accessibility-подхода имеют подобную особенность. Как вполне рабочий вариант, можно реализовать метод обхода дерева генератором через фреймворк и comtypes.
Вывод
В нашей статье мы рассмотрели проблематику и особенности тестирования desktop-приложений, с которыми столкнулись, кратко пробежались по инструментам, технологиям и подходам. В выводе хочется подсветить главный вопрос, который напрашивается после прочтения статьи: “стоит ли погружаться в автоматизацию десктопа?”.
По нашему опыту, автоматизация тестирования под десктоп не так сложна, как может показаться на первый взгляд. При принятии решения об автоматизации владелец продукта, как правило, исходит из частоты изменения функционала, текущего этапа проекта и его сложности. Подробнее об этих критериях мы рассказали ранее.
Кроме того, стоит учитывать и следующие особенности:
в зависимости от окружения автотесты desktop-приложения могут быть менее быстрыми и стабильными относительно остальных видов
более требовательны к компетенциям DevOps и/или SDET в случае необходимости параллелизации или внедрения через CI/CD
Так или иначе, автоматизация десктоп-приложения по сравнению с ручным тестированием дает ощутимый прирост – по нашему опыту, от 3 до 30 раз – к скорости прохождения тестов и снижает влияние человеческого фактора на процессы обеспечения качества.
Надеемся, что у нас получилось внести чуть больше ясности в эту область автоматизации. Будем рады, если наша статья окажется вам полезной. А если вам есть что сказать в ответ – ждем ваших комментариев!