Desktop приложения что это
Особенности тестирования десктопных приложений
Десктопные приложения – это полнофункциональные программы, которые работают вне зависимости от других приложений и требуют наличие оператора. Для их работы необходимы достаточные аппаратные ресурсы компьютера, само приложение и набор функций для работы с приложением.
Такие приложения размещаются на компьютере пользователя. Они не требуют для работы подключение к интернету, взаимодействуют с пользователем посредством стандартного интерфейса, имеют более высокое быстродействие, зависят от используемой операционной системы и требуют установку на каждый компьютер пользователя, желающего работать с данным приложением. Это текстовые редакторы, медиа-плееры, программы расчета, исчисления, изучения – в общем все программы, которые установлены у нас на компьютерах, являются desktop-приложениями. Так как мы имеем доступ к системным файлам программы, данный тип приложений более уязвим, и полностью зависит от действий пользователя.
Особенности тестирования десктопных приложений
Основные особенности тестирования десктопных приложений от веб-приложений заключаются в следующем:
| Параметр | Desktop приложение | Web приложение |
| Доступ к сети Internet | не требуется | необходим. исключение: некоторые приложения могут временно работать автономно |
| Установка/обновление | Должно быть развёрнуто или установлено. | Единовременная настройка. Одна установка для всех пользователей. |
| Интерфейс взаимодействия | Стандартные интерфейсы, стандартное взаимодействие | Разнообразный интерфейс взаимодействия. |
Плюсы — разнообразие реализации, минусы, сложности — кроссбраузерная совместимость. Решается применением библиотек на JavaScritp, внедрением стандартов.
При тестировании десктопных приложений необходимо учитывать особенности, перечисленные выше.
Виды тестирования которые необходимо проводить на десктопных приложениях помимо основных (функционального, GUI, юзабилити и т.д) также имеют свои особенности:
Выполняя тестирование установки проверяется:
Для тестирования обновлений специально устанавливают старую версию программы, она сразу же находит обновления и обновляется. Выполняя тестирование обновлений нужно:
Выполняя тестирование удаления проверяем:
Имея опыт(сразу оговорюсь, что не такой большой) разработки как настольных, так и web приложений, могу провести сравнение этих видов приложений с разных сторон.
И так, сегодня 2010 год. Мир ИТ динамичен, как ничто другое. Всё меняется. Вот и в мире программных продуктов происходят заметные изменения. Всё бОльшую роль играют веб приложения. Этот вид приложений появился не сразу. Сначала были просто статичные сайты, после в сайты начали внедрять скрипты. Сложность сайтов начала возрастать. И вот, не успели моргнуть глазом, как «сайты» стали таким же сложным программным продуктом, как и обычные десктоп-приложения. Сайтами их уже язык не поворачивается назвать — это уже приложения. Уже есть инструменты для создания таких приложений, паттерны проектирования, освоенные практики. А тут ещё «облака». Всё чаще люди переходят с Word на Google Docs. Уже приятнее и удобнее пользоваться веб-интерфейсом для просмотра почты(GMail). Всё чаще и чаще появляются разный веб-софт, сервисы.
Произведём сравнительный анализ приложений.
Под обычными приложениями будем считать приложения, установленные на локальной машине.
Под веб-софтом будет иметь ввиду приложения, доступ к которому осуществляется через веб-интерфейс посредством браузера.
«То о бэнтли я мечтал, то о мазерати,
То рыбалка, то футбол, то с друзьями пати…»
Группа Жуки
Захотелось мне что-то провокационной статьи, так сказать взбодрить чем-то наше профессиональное сообщество. Хватит заумных статей и философских рассуждений. Итак, делимся на две команды: «любители Соса-Cola – горнолыжники – виндсерферы» против «любители Pepsi – сноубордисты – кайтеры». Счет на табло 0-0, начинаем!
Правила игры и критерии оценок
Сначала давайте определимся, что же будем считать десктопным приложением, а что же веб-клиентом:
При использовании любого из перечисленных клиентских приложений может применяться трехзвенная архитектура – Аллилуйя! Термины «толстый» и «тонкий» клиент сюда не вплетаем. Веб-клиент можно создать совсем не «тонким», ровно также как и с десктопного приложения по максимуму снять обработку бизнес-логики.
Что каждый из пользователей, владельцев системы, архитекторов и сотрудников служб безопасности ждет от программного продукта и клиентского приложения:
Для простоты будем считать, что каждое удачное попадание – 1 очко, т.к. бессмысленно сравнивать, что важнее мобильность или безопасность.
Надеюсь, разобрались и можно начинать «играть». Звучат гимны команд, понеслась…
Первый период
В каждой второй конкурсной документации (если не чаще), в разделе технических требований, можно заметить требования к наличию веб-клиента или веб-доступа. Возникает резонный вопрос «Вам вот это зачем, помимо того, что это модно?»
Как правило, обоснования такие:
Безопасность и надежность – очень серьезный вопрос. Некоторые организации принципиально не хотят и не предоставляют возможность работы в корпоративных системах за пределами своего домена. Необходимость применения средств криптографической защиты информации (СКЗИ) и электронной подписи (ЭП) уже давно никому доказывать не надо, за нас это делают регуляторы. Для использования данных технологий необходимо обращаться к сторонним библиотекам, не все веб-приложения это «любят» и имеют ограничения. Стабильность работы самих браузеров также является потенциально узким местом, причем повлиять на это разработчик бизнес-приложения может не всегда. Оффлайн работа, объективно, чаще и проще реализуются с использованием десктопных приложений. В принципе отдельных организаций пока еще пугает работа в браузере (да-да в том самом, в котором сотрудники просиживают часами в социальных сетях, выкладывая туда всю свою подноготную). Это прорыв по флангу и счет 1-1. Звучит свисток, первая половина игры закончена, команды уходят в свои СЭД закрывать накопившиеся поручения.
Второй период
Все покупатели хотят видеть «свой» продукт, отличный от множества других. Конечно, сложно на это надеяться, покупая массовый коробочный продукт. А сделать его «под заказ» значительно дороже и рисково. Но только не в IT области.
Повальная мода на скины, по-моему, уже прошла, или я постарел, и иметь не классическую «морду» аудио-проигрывателя мне уже не принципиально. Тем не менее, возможность изменить цветовую раскраску, логотипы, иконки, шрифты базовых интерфейсов – хороший бонус для клиента. Десктопные приложения могут предоставлять возможность применения цветовой темы, настройки отдельных интерфейсных элементов, но веб-приложения, применяя каскадные таблицы стилей, с этим справляются явно лучше. Возможность кастомизации определяется степенью развития самого программного продукта и тип клиентского приложения тут не должно иметь особой роли. Счет 2-1 и «браузерники» вырываются вперед.
Функциональность – важнейшее требование к любому программному продукту. Исторически считается, что десктопные приложения более функциональны и эргономичны. Если пытаться разрабатывать веб-клиент с нуля, то так оно и будет. Но с годами были разработаны целые интерфейсные библиотеки, позволяющие творить «чудеса»:
Про визуальную красоту реализации я и говорить не буду – там все очень достойно. Подозреваю, что компании больше и охотнее разрабатывают новые интерфейсные элементы под браузеры, чем для традиционных win32-приложений.
Современный пользователь компьютера не меньше времени проводит в браузере, чем тратит его на работу с десктопным приложением. И первый вариант работы сложнее ему не кажется. Зато возможность масштабирования в браузере, отдельным категориям пользователей, приносит ощутимую пользу. Опасность у ворот команды веб-клиента была устранена. Счет по-прежнему 2-1.
Корпоративная информационная система растет вместе с компанией. А значит, количество рабочих мест увеличивается, расширяется линейка клиентских устройств для работы в системах. Мировые лидеры разрабатывают новые операционные системы и платформы, и угнаться за ним не так просто. А надо ли? Может быть, доверим им обеспечить совместимость распространенного программного обеспечения, а если такая совместимость не возможна, в их же интересах предоставить альтернативу. Вот такими финтами и перепасовками в центре поля одна из команд пробирается к воротам соперника.
Разрабатывая веб-приложения с соблюдением стандартов можно надеяться, что программное обеспечение будет корректно работать во всех браузерах, по крайней мере, в первой пятерке. Чуда тут не происходит, и существует масса нюансов связанных с различной интерпретацией одной и той же разметки. Разработчики каждый день видят в системах баг-трекинга заявки из разряда «функция А не корректно работает в браузере Б, а в остальных браузерах все ОК». Но эти труды стоят получаемых бонусов.
Когда пользователь заходит на рядовой публичный сайт в Интернете он надеется увидеть корректное представление страниц с сохранением всей заложенной функциональности. Причем, посетитель сайта не хочет знать «под какие устройства» сайт создавался (стационарный компьютер или ноутбук, планшет или смартфон), это его вообще не должно беспокоить. Почему же ровно также не рассуждать пользователю корпоративной информационной системы. Зачем пользователю, находящемуся вне офиса и имеющему на руках планшет за 1000$ переживать, что он не сможет исполнить поручение, выданное ему в СЭД. Надо ли сотруднику при выборе планшета изучать вопрос, а сможет ли он конкретно с этого планшета (с его операционной системой), корректно работать в десятках корпоративных систем своей организации. А если завтра он купит другой планшет (с другой программной платформой), система на нем будет ровно такой же, к которой он привык или уже другой, а придется что-то заново скачивать и устанавливать?
В идеале, я бы хотел, что бы разработчики бизнес-приложений сосредоточились на самих продуктах, а не тратили время на разработку одного и того же под разные платформы (те же яйца только в профиль). И одним из путей вижу применение в качестве клиентских приложений полнофункциональных веб-клиентов с адаптивным веб-дизайном. Это красивая комбинация заканчивается неберущимся ударом, и счет становится 3-1. Веб-клиент заслуженно побеждает десктопное приложение. Крики радости, брызги шампанского, смазливые девицы окружают победителей.
Послесловие
После матча болельщики еще долго спорили, обсуждали острые моменты и не объективное судейство, но счет на табло уже ничто не изменит. Ставки сделаны господа, ставок больше нет!
Как тестировать приложение, если вы не тестировщик
Небольшая оговорка: берем ситуацию, когда всю разработку вы передали одной команде, а не распределили разные этапы между фрилансерами.
Вы, как создатель своего продукта или услуги, понимаете как он работает, какие связи между процессами и чего хотят клиенты. Поэтому при тестировании хорошо определяете ошибки и недочеты.
Конечно, ваши возможности ограничены — как знаниями и навыками, так и техническим оснащением. Вы не сможете проверить работу приложения на разных устройствах или его безопасность, наличие ошибки в коде. Но вам подвластно проверить, как работает функционал и какие упущения во внешнем виде, удобство приложения.
Сценарии тестирования
Ваша задача — встать на место пользователя и пройти его путь от входа в приложение до закрытия, при этом выполнить все действия, которые ему доступны. В ходе прохождения выявить проблемы, с которыми пользователь не должен сталкиваться, или найти изъяны в дизайне, которые водят его в заблуждение. В профессиональной среде такие сценарии называются «функциональное тестирование» и «тестирование удобства пользования». Для каждого мы написали принципы и основные моменты, на которые нужно обратить внимание.
Функциональное тестирование
Мы разработали веб-приложение для сервиса грузоперевозок Shustrikoff. Стоимость доставки зависит от удаленности от центра города, поэтому при тестировании проверяли адреса на границе Казани и другого района. Также можно проверить заявки в разных районах города, заказ назначенный на границе дневного и ночного тарифа и т.п.
Тестирование удобства пользования
Оформляем и передаем информацию разработчикам
Включаем режим «бюрократии», потому что правильно оформленная ошибка сэкономит вам и разработчикам часы работы. 
Представьте: разработчики не будут уточнять детали каждой ошибки, переспрашивать, для разъяснений не понадобятся эти звонки по телефону, которые мало кто любит (Привет миллениалам!). В ваших отношениях с командой будет процветать гармония и полное взаимопонимание.
Скорее всего команда уже использует определенный сервис для работы с задачами, где и собирает всю информацию по приложению. Поэтому они могут дать внешний доступ, чтобы вы в этом же пространстве вносили информацию по результатам своего тестирования. Собирайте все в единой структуре в одном месте.
В какой-то момент вам захочется отправить информацию по небольшой ошибке в общий чат — это же небольшая ошибка, подправить ее займет 10 минут.
Остановитесь! Иначе информация затеряется в куче других сообщений и ошибка не будет исправлена.
Тестирование десктопных приложений. Тесты конфигураций десктопного приложения
Перед началом работы с системой или тестируемым приложением необходимо определенным образом настроить его или сконфигурировать. И на этом этапе работы тоже могут быть баги.
Как тестировщику находить их? Давайте разбираться.
С конфигурациями десктопного приложения у тестировщика вяжется два аспекта.
1. Конфигурации самого приложения.
Чтобы тестировать продукт, мы должны знать, как его конфигурировать – то есть как указать правильные настройки, которые необходимы, чтобы ПО работало адекватно, ну или вообще работало. Например, это могут быть параметры базы данных, логин и пароль от нее, профиль пользователя (его права, набор функциональностей, которые ему доступны), набор плагинов, который должна запустить данная конфигурация, и т.д.
Если указать эти конфигурации неправильно, то приложение не будет работать корректно, и мы будем получать ошибку не по причине того, что программный код написан неправильно, а потому что программа не может выполнить требуемого из-за неправильной конфигурации.
Например, не может выдать информацию по причине отсутствия доступа к базе данных. Или выдает не тот результат, который мы ожидаем, по причине того, что в конфигурациях указана не та БД (база данных). Поэтому, приступая к тестированию продукта, надо познакомиться не только с интерфейсом и технической документацией, но также разобраться в тонкостях параметров конфигурации.
Параметры конфигурации программного обеспечения указываются обычно в текстовом файле. Его можно изменять вручную или в специальном интерфейсе. Обычно для этого достаточно простого блокнота. Более удобной и продвинутой программой является Notepad++.
2. Конфигурационное тестирование.
Это специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.). Оно проводится в ситуациях, когда надо подобрать оптимальные конфигурации для адекватной и бесперебойной работы ПО. Особое значение этот вид тестирования имеет при миграции на другую платформу. В этом случае нам необходимо проверить наш продукт на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.
ISTQB не выделяет конфигурационное тестирование как отдельный вид. Вышеописанные тесты попадают под определение тестирования портируемости (portability testing).
Чтобы осуществлять такое тестирование, нужно разобраться не с конфигурациями тестируемого продукта, а с конфигурациями окружения. Причем во внимание следует брать не только программные средства (драйвера и библиотеки, стороннее ПО, которое может повлиять на наше, типы и версии ОС, ее конфигурации) но и аппаратные (количество и тип процессоров, объем памяти, параметры сети и сетевые адаптеры).
Определить конфигурацию рабочей машины можно, зайдя в Bios компьютера (как это сделать, можно прочитать, например, здесь). Какие-то типовые советы по определению и изменению конфигурации компьютера на основе информации из BIOS дать нелегко, так как интерфейс и возможности у разных типов и ревизий BIOS отличаются, и бывает, что довольно существенно. Но в интернете об этом есть достаточно информации. Достаточно сделать запрос, упомянув фирму и модель своей рабочей машины.
Конфигурации системы Windows хранятся в реестре Windows. Это сложная древовидная структура, в которой до конца не разбираются, наверно, даже ее создатели, настолько она сложна и объемна. Информации по реестру много, начинающему тестировщику, да и вообще пользователю, стоит помнить, что не стоит вносить какие-либо изменения в реестр Windows, если ты на 100% не уверен, что ты делаешь. Если такая уверенность составляет хотя бы 99% – лучше всего записать, что конкретно в реестре было изменено.
Написание автоматических тестов для тестирования пользовательского интерфейса десктопных приложений
Постановка задачи
В начале нужно оговориться, что приведенные ниже методики рассчитаны на применение программистами, желающими автоматизировать процесс проверки созданного ими же UI, так что для команды QA, не владеющей хотя бы базовыми навыками программирования, боюсь, статья окажется мало полезной. Так же замечу, что тесты для UI ни в коем случае не могут считать юнит-тестами, не должны быть включены в цикл написания кода через TDD и желательно должны выполняться на отдельном сервере во время сборки билда(в идеале, конечно, после каждого коммита). Почему не локально? Потому что это будет очень медленно, начнет раздражать и через какое-то время разработчик просто забьет на их запуск.
Задача для примера у нас будет простая – есть приложение с двумя кнопками. По нажатию первой в текстом поле будет появляться определенный текст(пусть будет “Habrahabr”). По нажатию на вторую туда же будет выводиться текущее время и дата.
Обзор существующих решений
Для специфичных контролов, UI Automation предоставляет набор дополнительных оберток, называемых AutomationPatterns, например ExpandCollapsePattern, SelectionItemPattern и т.д., позволяющий, соответственно, использовать специфичный для этих контролов функционал, например возможность развернуть/свернуть экспандер.
Достоинства
Недостатки
Примеры тестов для поставленной задачи
Текст после нажатия на вторую кнопку реализовать не получится, ввиду того, что текущее время всегда разное, а замокировать что-либо мы не можем.
2. White project
Бесплатный фреймворк с кодеплекса, основанный на UI Automation. Достоинства и недостатки те же, отличается только более удобным и расширенным api для работы с деревом контролов.
Примеры тестов для поставленной задачи
3. Visual Studio 2010 Coded UI Test
Coded UI — решение от майкрософт, появившееся в 2010 студии и неоднократно описанное, в том числе и на хабре, например здесь и здесь.
Достоинства
Недостатки
В целом, набор недостатков тот же, что и у UI Automation. Отдельно только надо выделить то, что возможность работы есть только в определенных версиях 2010 студии(Ultimate, Premium, Professional). Причем если запуск тестов возможен во всех трех, то создание соответствующего типа item’а в проекте и запуск рекордера возможен только в версиях Ultimate и Premium. И если для своих домашних проектов и можно скачать с торрентов купить Ultimate версию, то для коммерческого проекта, где речь идет о лицензии для десятков разработчиков такой шаг может натолкнуться на непонимание со стороны вышестоящего начальства и бухгалтерии.
Код тестов я приводить не буду, ввиду того, что он является автогенереным и по-этому особого интереса не представляет.
4. Test Complete и ему подобные
Системы, подобные Test Complete можно обобщить в одну группы. Я не стану описывать их подробно, т.к. это тема отдельное статьи, выделю лишь некоторые моменты. Основное их достоинство — широкий спектр применений, отсутствие необходимости в навыках программирования и наличие отдельной, не требующих Visual Studio, системы по создание, хранению и поддержки тестов. Недостатки же повторяют предыдущие решения — платность, отношение к тестируемой системе, как к «черному ящику», без возможности мокирования плюс Test Complete имеет собственную среду для запуска тестов, так что использоваться обычный mstest не получится.
Сделаем что-нибудь свое
Если вы пишите UI своего приложения на WPF, то для его тестирования можно воспользоваться классом VisualTreeHelper. Алгоритм довольно простой — запускаем в тест-методе наше приложение в отдельном потоке, получаем через VisualTreeHelper нужный контрол, эмулируем эвенты и считываем значения для ассертов.
Для более удобного создания тестов, для себя я сделал небольшой утилитный класс, упрощающий выполнение рутинных действий:
var window = application.Get(x => x.MainWindow);
var textBox = _mainWindow.FindChild((TextBox el) => el.Name == «SomeText» );
Достоинства
Недостатки
Примеры тестов для поставленной задачи
Тут я просто замокировал вызов DateTime.Now с помощью фреймворка Moles, обзор которого можно посмотреть, например, здесь.
Создание application и получение из него окна, естественно, можно внести в статический конструктор тестового класса, дабы ускорить время прохождения сьюиты тестов и упростить их код.
Заключение
Какой именно путь выбрать для автоматизации тестирования UI следует решать, исходя из конкретных реалиев текущего проекта и собственного опыта. Я же постарался осветить основные методы написания тестов для UI, которые мне довелось опробовать и показать их достоинства и недостатки. Надеюсь, что эта статья окажется для вас полезной.