Что такое десктопное приложение
говориМ о тестировании
простым языком
Тестирование десктопных приложений. Что такое десктопные приложения?
Что такое десктопные приложения, чем они отличаются от веб и мобильных приложений и будут ли тестировщики десктопных приложений востребованы в будущем? Ответы на эти вопросы найдете в сегодняшней статье.
Все статьи в рамках данного цикла написаны совместно с одним из наших преподавателей, а именно Еленой Выналек.
Что такое десктопные приложения?
Десктопные приложения — это программы, которые способны работать на любой машине, используя только аппаратные ресурсы компьютера, код самого приложения (который находится локально на рабочем компьютере) и библиотеки (предназначенные для этого приложения и которые тоже находятся на локальном хосте).
Иными словами, десктопные приложения — это, например, Photoshop, Gimp, Notepad++, группа программ Microsoft Office, Libre Office и т.д. То есть приложения, которые мы устанавливаем на компьютер или ноутбук.
При этом такие приложения могут иметь многопользовательский режим. Они предоставляют доступ к функциям и определенному набору данных в зависимости от введенного логина и пароля. То есть, в одном приложении на одном устройстве вы можете сидеть под разными аккаунтами (например, десктопная версия мессенджера Телеграмм).
Десктопные приложения могут работать целиком автономно, на локальной машине, например, NotePad++, LibreOffice, MSOfice. Получается, что мы их установили себе на стационарное устройство (компьютер, ноутбук) и все данные по этому приложению хранятся на нашем устройстве.
Также десктопные приложения могут требовать для полноценной работы выхода в интернет, откуда они черпают данные для полноценной работы. Примером таких приложений могут быть десктопные версии различных мессенджеров (Вайбер, Телеграмм).
Для полноценной работы такому ПО нужен, как минимум, доступ к базе данных, которая, чаще всего, находится на удаленном сервере. Как раз доступ к удаленному сервису осуществляется через интернет или интранет (то есть интернет в миниатюре, который построен на использовании протокола IP для обмена и совместного использования некоторой части информации внутри этой организации).
Десктопное приложение занимает память компьютера. Это может влиять на его производительность. К тому же требует индивидуального запуска. Поэтому можно услышать мнение, что скоро десктопные приложения «вымрут» и пользователи будут работать в облаке, используя браузер, или в мобильных приложениях (многие из которых, кстати, являются аналогами веб).
Так ли это? И чем десктопное приложение отличается от веб и мобильного? Давайте разберемся.
Различия десктопного и веб приложений
Различия десктопного и мобильного приложения
Вымрут ли десктопные приложения?
Многие думают, что десктопные приложения «вымрут». Но скорее всего, если это случится, то очень и очень нескоро.
Ведь в отличие от веб-приложений, десктопы более безопасны и имеют средства развертывания подобные веб-приложениям. Например, RDP, то есть специальный протокол, разработанный компанией Microsoft для удаленного управления ОС Windows (протокол удалённого рабочего стола). Это позволяет фирмам работать только в своем домене. Также десктопные приложения более функциональны, чем мобильные приложения.
________________________________
Так что тестировщики десктопных приложений, по-видимому, еще очень долго будут востребованы на рынке IT-услуг.
________________________________
Desktop приложения
Использование программного обеспечения в бизнесе является необходимостью. Цифровизация позволяет внедрять новые инструменты, расширяет возможности бизнеса, улучшает взаимодействие между компанией и клиентом. Но возникает вопрос, какой тип приложений использовать: браузерное или десктопное приложение? В чем разница? Какие преимущества у разработки десктоп приложения, какие возможности оно предоставляет? Давайте разберемся.
Что такое десктопное приложение?
Desktop приложения – это программы, которые нуждаются в ОС настольного компьютера для своей работы. Они устанавливаются в систему через специальный инсталлятор, используют для работы ресурсы компьютера.
Главная особенность таких программ – возможность работать автономно, без подключения к интернету. Современные приложения все равно предлагают работать с подключением, но это нужно для того, чтобы использовать различные устройства, включить в проект других пользователей или обновлять программу без ручной переустановки.
Многие компании беспокоятся о безопасности, поэтому не хотят, чтобы приложения подключались к интернету. В таком случае разработка десктопных приложений может вестись “под ключ”, а подключение возможно в закрытой локальной сети.
Преимущества Desktop приложения
Считается, что такой тип программ быстрее, а функциональность гораздо шире. Это действительно так, но стоит отметить, что зависят эти параметры в основном от характеристик компьютера. Попробуйте поставить свой софт на слабое «железо» и быстро убедитесь в этом сами. Но разработка Desktop приложений действительно имеет свои преимущества.
Функциональность
Заказывая персональную разработку, вы получаете уникальные функции для бизнеса, которые помогут вашей компании. Главная особенность – широкие возможности для функционала. Можно реализовать практически любую идею. При этом интерфейс будет удобным, привычным и интуитивно понятным для пользователей.
Безопасность и надежность
Браузерные приложения уязвимы. Дело в том, что разработчики не могут повлиять на безопасность браузера, а веб-приложение напрямую зависит от его работы. Десктоп приложение – это гарантия безопасности и сохранности данных. Поэтому многие компании выбирают такое цифровое решение для своего предприятия.
Мобильность
Десктоп приложения можно разрабатывать под различные операционные системы и даже использовать с мобильного устройства, сделав нативную версию. Но для синхронизации данных необходимо подключаться к интернету. Тем не менее, мобильность подразумевает использование приложения в любых условиях и дает возможность управлять бизнес-процессами компании когда угодно.
Быстродействие
Принцип работы Desktop приложения прост: программа использует ресурсы компьютера, его память и возможности. С одной стороны, это может стать недостатком, если оборудование недостаточно хорошее. Но с другой, заказывая индивидуальную разработку, учитываются особенности системы. С должной оптимизацией такое приложение будет «летать» и выполнять задачи эффективно.
Возможности десктопных приложений
Разработка Desktop приложений для бизнеса открывает новые горизонты. Внедрение диджитал продуктов в компанию позволяет повысить эффективность, автоматизировать многие процессы компании и оптимизировать работу. Все это происходит благодаря возможностям, которые дает цифровой продукт. У десктопных приложений есть целый ряд возможностей:
Это далеко не все возможности программ, которые устанавливаются на компьютер. Индивидуальная разработка позволяет получить эффективное приложение для бизнеса, которое отвечает конкретным запросам. Как это работает?
Разработка десктопных приложений в Wezom
WEZOM предлагает услугу разработки десктопных приложений для бизнеса. Сам процесс разработки идет по такому пути:
Так вы получаете качественное десктопное приложение, предназначенное персонально для вашей компании. По своей структуре оно может быть как простым, так и насыщенным и функциональным. Главное – чтобы софт решал свои задачи. Позвоните нам, и мы обсудим детали, проведем консультацию и поможем определиться с функциями, которые выведут ваш бизнес на новый уровень.
Оставьте ваши контактные данные. Наш менеджер свяжется и проконсультирует вас.
Десктопное приложение или веб-клиент – вот в чем вопрос!
Захотелось мне что-то провокационной статьи, так сказать взбодрить чем-то наше профессиональное сообщество. Хватит заумных статей и философских рассуждений. Итак, делимся на две команды: «любители Соса-Cola – горнолыжники – виндсерферы» против «любители Pepsi – сноубордисты – кайтеры». Счет на табло 0-0, начинаем!
«То о бэнтли я мечтал, то о мазерати,
То рыбалка, то футбол, то с друзьями пати…»
Группа Жуки
Захотелось мне что-то провокационной статьи, так сказать, взбодрить чем-то наше профессиональное сообщество. Хватит заумных статей и философских рассуждений. Итак, делимся на две команды: «любители Соса-Cola – горнолыжники – виндсерферы» против «любители Pepsi – сноубордисты – кайтеры». Счет на табло 0-0, начинаем!
Правила игры и критерии оценок
Сначала давайте определимся, что же будем считать десктопным приложением, а что – веб-клиентом:
При использовании любого из перечисленных клиентских приложений может применяться трехзвенная архитектура. Аллилуйя! Термины «толстый» и «тонкий» клиент сюда не вплетаем. Веб-клиент можно создать совсем не «тонким», ровно также как и с десктопного приложения по максимуму снять обработку бизнес-логики.
Что каждый из пользователей, владельцев системы, архитекторов и сотрудников служб безопасности ждет от программного продукта и клиентского приложения:
Для простоты будем считать, что каждое удачное попадание – 1 очко, так как бессмысленно сравнивать, что важнее – мобильность или безопасность.
Надеюсь, разобрались, и можно начинать «играть». Звучат гимны команд, понеслась…
Первый период
В каждой второй конкурсной документации (если не чаще) в разделе технических требований можно заметить требования к наличию веб-клиента или веб-доступа. Возникает резонный вопрос «Вам вот это зачем, помимо того, что это модно?»
Как правило, обоснования такие:
Безопасность и надежность – очень серьезный вопрос. Некоторые организации принципиально не хотят и не предоставляют возможность работы в корпоративных системах за пределами своего домена. Необходимость применения средств криптографической защиты информации (СКЗИ) и электронной подписи (ЭП) уже давно никому доказывать не надо, за нас это делают регуляторы. Для использования данных технологий необходимо обращаться к сторонним библиотекам, не все веб-приложения это «любят» и имеют ограничения. Стабильность работы самих браузеров также является потенциально узким местом, причем повлиять на это разработчик бизнес-приложения может не всегда. Оффлайн работа, объективно, чаще и проще реализуются с использованием десктопных приложений. В принципе отдельных организаций пока еще пугает работа в браузере (да-да в том самом, в котором сотрудники просиживают часами в социальных сетях, выкладывая туда всю свою подноготную). Это прорыв по флангу и счет 1-1. Звучит свисток, первая половина игры закончена, команды уходят в свои СЭД закрывать накопившиеся поручения.
Второй период
Все покупатели хотят видеть «свой» продукт, отличный от множества других. Конечно, сложно на это надеяться, покупая массовый коробочный продукт. А сделать его «под заказ» значительно дороже и рисково. Но только не в IT области.
Повальная мода на скины, по-моему, уже прошла, или я постарел, и иметь не классическую «морду» аудио-проигрывателя мне уже не принципиально. Тем не менее, возможность изменить цветовую раскраску, логотипы, иконки, шрифты базовых интерфейсов – хороший бонус для клиента. Десктопные приложения могут предоставлять возможность применения цветовой темы, настройки отдельных интерфейсных элементов, но веб-приложения, применяя каскадные таблицы стилей, с этим справляются явно лучше. Возможность кастомизации определяется степенью развития самого программного продукта и тип клиентского приложения тут не должно иметь особой роли. Счет 2-1 и «браузерники» вырываются вперед.
Функциональность – важнейшее требование к любому программному продукту. Исторически считается, что десктопные приложения более функциональны и эргономичны. Если пытаться разрабатывать веб-клиент с нуля, то так оно и будет. Но с годами были разработаны целые интерфейсные библиотеки, позволяющие творить «чудеса»:
Про визуальную красоту реализации я и говорить не буду – там все очень достойно. Подозреваю, что компании больше и охотнее разрабатывают новые интерфейсные элементы под браузеры, чем для традиционных win32-приложений.
Современный пользователь компьютера не меньше времени проводит в браузере, чем тратит его на работу с десктопным приложением. И первый вариант работы сложнее ему не кажется. Зато возможность масштабирования в браузере, отдельным категориям пользователей, приносит ощутимую пользу. Опасность у ворот команды веб-клиента была устранена. Счет по-прежнему 2-1.
Корпоративная информационная система растет вместе с компанией. А значит, количество рабочих мест увеличивается, расширяется линейка клиентских устройств для работы в системах. Мировые лидеры разрабатывают новые операционные системы и платформы, и угнаться за ним не так просто. А надо ли? Может быть, доверим им обеспечить совместимость распространенного программного обеспечения, а если такая совместимость не возможна, в их же интересах предоставить альтернативу. Вот такими финтами и перепасовками в центре поля одна из команд пробирается к воротам соперника.
Разрабатывая веб-приложения с соблюдением стандартов можно надеяться, что программное обеспечение будет корректно работать во всех браузерах, по крайней мере, в первой пятерке. Чуда тут не происходит, и существует масса нюансов связанных с различной интерпретацией одной и той же разметки. Разработчики каждый день видят в системах баг-трекинга заявки из разряда «функция А не корректно работает в браузере Б, а в остальных браузерах все ОК». Но эти труды стоят получаемых бонусов.
Когда пользователь заходит на рядовой публичный сайт в Интернете он надеется увидеть корректное представление страниц с сохранением всей заложенной функциональности. Причем, посетитель сайта не хочет знать «под какие устройства» сайт создавался (стационарный компьютер или ноутбук, планшет или смартфон), это его вообще не должно беспокоить. Почему же ровно также не рассуждать пользователю корпоративной информационной системы. Зачем пользователю, находящемуся вне офиса и имеющему на руках планшет за 1000$ переживать, что он не сможет исполнить поручение, выданное ему в СЭД. Надо ли сотруднику при выборе планшета изучать вопрос, а сможет ли он конкретно с этого планшета (с его операционной системой), корректно работать в десятках корпоративных систем своей организации. А если завтра он купит другой планшет (с другой программной платформой), система на нем будет ровно такой же, к которой он привык или уже другой, а придется что-то заново скачивать и устанавливать?
В идеале, я бы хотел, что бы разработчики бизнес-приложений сосредоточились на самих продуктах, а не тратили время на разработку одного и того же под разные платформы (те же яйца только в профиль). И одним из путей вижу применение в качестве клиентских приложений полнофункциональных веб-клиентов с адаптивным веб-дизайном. Это красивая комбинация заканчивается неберущимся ударом, и счет становится 3-1. Веб-клиент заслуженно побеждает десктопное приложение. Крики радости, брызги шампанского, смазливые девицы окружают победителей.
Послесловие
После матча болельщики еще долго спорили, обсуждали острые моменты и не объективное судейство, но счет на табло уже ничто не изменит. Ставки сделаны господа, ставок больше нет!
Мобильные приложения vs десктопное программное обеспечение
Если вы когда-либо интересовались разработкой приложений для бизнеса, вы, вероятно, пытались провести какое-то сравнение между десктопными и мобильными приложениями. Смартфоны стали неотъемлемой частью нашей жизни, и без мобильного телефона все превратилось бы в полный хаос. Итак, важность мобильных телефонов полностью осознается. А как быть с компьютерами и ПО для них?
Разница десктопных и мобильных приложений
Обычно на ум приходят мобильные приложения, они созданы для мобильных устройств, загружаются в «магазинах приложений», таких как iTunes или Google Play, и доступны через значок на рабочем столе вашего телефона. Их создание может быть сложной задачей, поскольку необходимо разрабатывать разные мобильные приложения для Apple и Android, и по большей части код нельзя использовать совместно с платформами устройств. У Instagram, Facebook и многих других социальных сетей есть мобильные приложения. Сегодня, когда большинство людей думают о приложениях, они видят смартфоны, планшеты и значки.
Настольные приложения, или десктопное ПО, запускаются на компьютере, и для их работы не требуется доступ в Интернет. Они могут быть представлены в виде значков и часто входят в стандартную комплектацию новых компьютеров. Примеры включают Paint, Блокнот или iPhoto. Под ними также могут подразумевать настраиваемое «приложение», используемое для определенной цели в корпоративной среде.
Могут ли мобильные приложения «стереть» десктопное ПО?
Когда появились магазины приложений для смартфонов, мало кто задумывался, насколько они революционны. Теперь же приложений настолько много, что они действительно начинают понемногу вытеснять настольные ПК и, соответственно, десктопные приложения.
Хотя магазины приложений для смартфонов привели к появлению небольших одноразовых программ, разработчики не готовы отказываться от настольных приложений. Разработчики считают, что полнофункциональное программное обеспечение еще не умерло и по-прежнему будет занимать свое место на рабочих столах пользователей. Небольшие масштабы и ограниченные функции приложений для смартфонов являются побочным продуктом технических ограничений, таких как слабые процессоры и низкая емкость памяти на ранних моделях телефонов. Более мощные устройства с более мощными микропроцессорами и памятью позволят создавать более функциональные приложения.
Когда речь идет о бизнесе, стоит подумать о том, чтобы скомбинировать десктопное ПО и мобильные приложения. Например, для ресторанного бизнеса можно разработать систему учета, которая будет установлена на компьютерах администрации и позволит быстро и удобно принимать заказы, вести бухгалтерию, рассчитывать смены для сотрудников и так далее. А мобильное приложение для ресторанов станет отличным помощником для клиентов, ведь там можно посмотреть меню, забронировать столик или сделать предзаказ.
Раздельное мышление
Мобильные приложения предназначены для выполнения определенной задачи или набора, поэтому что бы вам ни нужно было сделать, для этого всегда есть приложение. Конечные пользователи ищут в «магазинах» приложений все, что им нужно, а разбиение на категории только помогает. И когда пользователь определяет, какой приложение выбрать для своей цели, он его загружает. При том исключительно для выполнения конкретно этой цели, не более. Никто не использует фитнес-приложение для проверки цен на акции. А понятные иконки разделяют приложения и упрощают доступ.
В этом мобильные приложения значительно уступают десктопному ПО, которое может совмещать в себе десятки функций, при этом интегрируя их друг с другом. Тем не менее, если узнать сколько стоит разработка приложения и сравнить с ценой на десктопное ПО, приложения снова выигрывают.
Выводы
При том что у всех вариантов есть свои плюсы и минусы, мы рекомендует тщательно изучить особенности каждого из них, прежде чем сделать выбор. Десктопное ПО, как и веб-инструменты, позволяет объединить весь необходимый функционал в одном месте, интегрировать необходимые системы между собой и автоматизировать значительную часть работы. Мобильные приложения дают возможность выполнять определенные функции с любого места и в любой момент, при этом отлично дополняя софт на компьютере.
Десктопизация по-питоновски. Инструменты для создания автотестов
Автоматизация тестирования – неотъемлемая часть процесса обеспечения качества. Мы в нашей практике чаще всего разрабатываем тесты для веб-, мобильных приложений и 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 раз – к скорости прохождения тестов и снижает влияние человеческого фактора на процессы обеспечения качества.
Надеемся, что у нас получилось внести чуть больше ясности в эту область автоматизации. Будем рады, если наша статья окажется вам полезной. А если вам есть что сказать в ответ – ждем ваших комментариев!