десктопное приложение что это

Какое бизнес-приложение нужно вашей компании: web или desktop?

Какое бизнес-приложение нужно вашей компании: web или desktop?

Идея написать статью на эту тему возникла в 2020 году, когда к нам с запросом на разработку ПО обратился крупный региональный производитель профлиста. Компании понадобилось приложение для менеджмента заказов на производство и доставку, и уже был определен примерный список требований.

Одним из пожеланий заказчика была разработка именно десктоп-приложения. Однако в процессе обследования и оценки задач мы вместе с клиентом пришли к выводу, что быстрее разработать web-приложение на платформе Jmix (ранее Cuba Platform).

И это далеко не первый случай, когда на этапе дискавери заказчик уверен в преимуществах десктоп-приложений, но в итоге делает выбор в пользу веба. Почему так происходит, какие плюсы и минусы у веба и десктопа, и какое приложение подойдет именно вашей компании — вы узнаете из этой статьи.

Важно! Так как статья ориентирована на читателей, которые знакомы с IT-сферой и разработкой ПО скорее на уровне пользователей, чем на уровне системных администраторов, для начала определим предмет разговора и уточним, что мы понимаем под вебом и под десктопом.

Веб-приложение — программа, которой вы можете пользоваться в любом удобном для вас браузере. Перед первым запуском ее не нужно устанавливать на ваш компьютер, достаточно вести адрес для доступа в строке браузера.

Десктопное приложение — программное обеспечение, которое вы используете в отдельном интерфейсе, а не в браузере. Перед использованием его придется обязательно установить на компьютер пользователя.

Это поверхностная разница на уровне очевидных для пользователя моментов, хотя на самом деле отличий у этих двух типов приложений гораздо больше.

Мифы о десктоп-приложениях

Еще 10-15 лет назад на рынке программного обеспечения царствовали именно десктоп-приложения, а веб только-только начинал развиваться. Процесс массового перехода к вебу происходил постепенно, и вот уже мы открываем большую часть необходимых для работы программ именно в браузере. Но, тем не менее, в представлении многих пользователей именно десктоп остался символом надежности, быстродействия и простоты. Так ли это на самом деле? Рассмотрим и попробуем опровергнуть самые распространенные мифы.

Миф №1 «Десктоп всегда безопаснее, а из веб-приложения нашу информацию могут украсть»

И да, и нет. Если сервер находится «снаружи» организации, и доступ к нему недостаточно защищен, то данные могут украсть независимо от того, будете ли вы пользоваться десктоп или веб приложением. То есть тут мы путаем «технологию разработки» и собственно архитектуру системы, и то, как организована защита передачи данных. Первично именно то, где находится сервер, насколько он защищен, и насколько защищены каналы доступа с клиентских ПК до сервера.

Технология разработки и интерфейс – этот как раз или веб-клиент, или десктоп. Это та часть, через которую пользователь взаимодействует с программой и запускает какие-то процессы. Защитить информацию на этом уровне можно только путем настройки доступа: создать надежные пароли и организовать их безопасное хранение, настроить уровни прав доступа для разных групп пользователей, установить на ПК антивирусы, которые обнаружат вредоносное и шпионское ПО.

Но самое ценное – собственно коммерческая информация, например, список клиентов и договоров – находится в базе данных. Местом ее хранения может быть:

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

Или если облачный сервер защищен от доступа посторонних, но пользователи получают доступ к данным через открытые каналы интернет без использования шифрования (VPN) – ваши данные под угрозой в любом случае.

Миф №2 «Десктоп работает и без интернета, а веб-приложение важна высокая скорость соединения»

Возможно, 10 лет назад это утверждение еще можно было назвать правдивым, но сегодня оно точно перешло в разряд мифов, и вот почему. Как веб, так и десктоп приложению для корректной работы может требоваться интернет, если:

Пример: вам нужно простое десктоп-приложение для ведения сделок и хранения базы клиентов, которое будет работать на собственном сервере в офисе. Для удобства менеджеров в приложение встроена проверка потенциального контрагента по ИНН с указанием возможных рисков.

Для проверки система обращается к открытым источникам в интернете. Если в офисе отключили интернет, менеджеры смогут спокойно работать с самим приложением. Однако автоматическая проверка по ИНН не будет работать до того момента, пока не восстановится соединение.

Если в аналогичном примере у компании не один, а два офиса, а сервер вынесен за пределы офисной сети и доступен только удаленно, при отключении интернета любое приложение будет недоступно.

Миф №3 «Десктопные приложения проще и понятнее, чем веб»

Такое впечатление может сложиться после сравнения какой-то простейшей десктоп-программы, разработанной под конкретную задачу, и сложной многофункциональной веб-системы, такой как Битрикс24. И здесь мы снова сталкиваемся с тем, что выбор технологии разработки не влияет сам по себе на удобство интерфейса. Одинаково непонятную или наоборот удобную для пользователя систему можно построить как в виде «настольного» приложения, так и в его веб-версии.

Совет: Заказчикам бизнес-приложений еще на этапе формирования своих пожеланий разработчику не стоит забывать о такой важной части, как обучение и «онбординг» пользователей. Именно от того, насколько интерфейс приложения учитывает сценарии работы пользователей, и от того, насколько гладко и успешно пройдет обучение, зависит, будут ли сотрудники использовать систему, или внутри коллектива начнется саботаж и деньги на разработку будут потрачены зря.

А еще хотя бы частично автоматизированная схема обучения позволяет не тратить время на обучение нового сотрудника, а позволяет ему самостоятельно познакомиться с основными сценариями в режиме обучения с подсказками, и задать вопросы.

Плюсы и минусы десктоп-приложений

После того, как мы развеяли распространенные мифы о десктопе, стоит разобраться, что на самом деле представляют из себя современные «настольные» программы, и кому они подходят.

Преимущества десктопных бизнес-приложений

Возможные «минусы» выбора десктоп-приложений для бизнеса

Веб-приложения: преимущества и недостатки

Преимущества

Гибкие и кросс-платформенные решения, дешевле разработка

Это одна из главных причин, по которой сегодня веб-приложения практически заменили десктоп. Существующие фреймворки позволяют при разработке учитывать требования практически всех популярных браузеров, а не создавать отдельное приложение или адаптацию под каждый из них. Это делает разработку в несколько раз дешевле и быстрее, а полученные в результате приложения — более гибкими с точки зрения изменений и доработок в перспективе.

В первую очередь кросс-платформенность важна для разработки коммерческих продуктов. Приложение, которое будут использовать тысячи или даже миллионы пользователей из разных стран, должны по умолчанию подходит под большую часть популярных устройств и операционных систем на выбранных рынках.

Но не стоит думать, что при заказе бизнес-приложения для компании на 15-20 пользователей этот пункт не важен. Даже если сейчас вам известно, на каких именно устройствах и платформах будет использоваться разработанное решение, уже через 1-2 года ситуация может измениться.

Например, так произошло при разработке приложения для одного из наших клиентов. После завершения разработки и успешного внедрения клиент решил масштабировать решение на филиал в другом городе. И внезапно оказалось, что в парке пользовательских ПК есть старые машины с операционной системой Windows 7.

Благодаря тому, что приложение было разработано на платформе Jmix, нам удалось успешно запустить программу даже на такой «древней» операционке. Если бы вместо веб-приложения мы разработали десктоп, то заказчику было бы проще купить новые ПК, чем дорабатывать приложение под Windows 7 ради нескольких рабочих мест.

Проще в установке и поддержке

Выше мы уже описывали процесс обновления версии десктоп-приложения. А теперь сравните с вебом: достаточно за 5-10 минут загрузить обновления на сервер и попросить пользователей «перелогиниться» в системе. Даже если в компании более 50-80 пользователей, провести обновление будет намного проще, чем в случае с десктопом.

Недостатки веб-приложений для бизнеса

Можно сказать, что минусами веб-приложений считаются те же моменты, которые относят к плюсам у десктопных, поэтому не будем раскрывать их подробно, а повторим тезисно:

Десктоп или веб: какое приложение подойдет для решения ваших бизнес-задач?

Разработку десктоп-приложения стоит выбрать, когда вашей компании необходима программа для:

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

Источник

Почему «настольные» приложения на компьютере теперь не важны?

На Gizmodo вышла правильная заметка, о том, что нам вскоре не понадобятся полноценные «десктопные» приложения. Эта интересная тема, вокруг которой мы часто крутились. Ваш браузер – это и есть операционная система, и этот подход во многих случаях стирает грань между конкурентными решениями, macOS и Windows.

Нажмите кнопку «Пуск» на «Винде» или «Док» на «Маке» и подумайте: из всего списка настольных приложений, какие вы используете на самом деле, а главное, какие из них нельзя заменить онлайн-версиями программ в браузере? Конечно, найдётся пара, тройка профессиональных решений, если вы графический дизайнер или видео инженер, но если говорить об обычной повседневной жизни и работе?

Вся жизнь в браузере

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

Офисные задачи легко, а главное удобно воспроизводятся в Google Docs. Музыка и видео прослушиваются «онлайн» и не приходится ничего скачивать. Лёгкие графические редакторы уже давно работают в браузерах. Чего стоит Google Photo со своими возможностями.

Microsoft и Apple реализовали часть ключевых функций своего софта в облаке. Вы можете сидеть на Mac и использовать Microsoft Office в браузере. Или наоборот, сидя за Windows пользоваться пакетом iWork и iCloud от Apple.

Работа с почтой с лёгкостью выполняется через окно браузера, а учитывая вездесущий Google со своими сервисами, то почта автоматически превращается в ежедневник, календарь и файловое хранилище.

Переписка и общение чаще всего выполняются при помощи отдельных клиентов. Telegram, Skype, Slack и прочие сервисы, все они мультиплатформенные, и к тому же все они имеют веб-версию. Не удивлюсь, если через год использовать плагин для браузера, чтобы переписываться в Telegram, будет проще, чем скачать полноценный клиент на компьютер.

В чем плюс отказа от настольных приложений?

Работа в облаке имеет ряд преимуществ. Главное из них, мобильность и лёгкая смена платформ. В любое время и в любом месте вы подходите к компьютеру и не задумываетесь, на какой ОС он работает. Просто открываете браузер, вводите логин и пароль от своей учётной записи Google и ваша рабочая станция готова.

Уход от настольных приложений, которые служили вам на протяжении десятилетий может показаться безумием, но большинство из нас действительно не нуждается в них, так как мы привыкли находить достойную альтернативу в облаке. Лично я не храню документы, фото и видео на диске своего ноутбука и облаку как-то больше доверяю.

Возможно, стоит составить отдельный текст с подборкой сервисов и программ, которые позволяют с комфортом работать в окне браузера.

Источник

QA evolution

Особенности тестирования десктопных приложений

Особенности тестирования десктопных приложений

Десктопные приложения – это полнофункциональные программы, которые работают вне зависимости от других приложений и требуют наличие оператора. Для их работы необходимы достаточные аппаратные ресурсы компьютера, само приложение и набор функций для работы с приложением.

Такие приложения размещаются на компьютере пользователя. Они не требуют для работы подключение к интернету, взаимодействуют с пользователем посредством стандартного интерфейса, имеют более высокое быстродействие, зависят от используемой операционной системы и требуют установку на каждый компьютер пользователя, желающего работать с данным приложением. Это текстовые редакторы, медиа-плееры, программы расчета, исчисления, изучения – в общем все программы, которые установлены у нас на компьютерах, являются desktop-приложениями. Так как мы имеем доступ к системным файлам программы, данный тип приложений более уязвим, и полностью зависит от действий пользователя.

Особенности тестирования десктопных приложений

Основные особенности тестирования десктопных приложений от веб-приложений заключаются в следующем:

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

Виды тестирования которые необходимо проводить на десктопных приложениях помимо основных (функционального, GUI, юзабилити и т.д) также имеют свои особенности:

Выполняя тестирование установки проверяется:

Для тестирования обновлений специально устанавливают старую версию программы, она сразу же находит обновления и обновляется. Выполняя тестирование обновлений нужно:

Выполняя тестирование удаления проверяем:

Источник

Десктопизация по-питоновски. Инструменты для создания автотестов

Автоматизация тестирования – неотъемлемая часть процесса обеспечения качества. Мы в нашей практике чаще всего разрабатываем тесты для веб-, мобильных приложений и 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 раз – к скорости прохождения тестов и снижает влияние человеческого фактора на процессы обеспечения качества.

Надеемся, что у нас получилось внести чуть больше ясности в эту область автоматизации. Будем рады, если наша статья окажется вам полезной. А если вам есть что сказать в ответ – ждем ваших комментариев!

Источник