Как тестировать десктопные приложения
Сейчас оно состоит из десятков тысяч строк кода, а это сотни тестов и примерно полтора месяца, которые требуются на первичное ручное тестирование:
Две недели на первичный ручной прогон регресс тестов.
Две недели на повторный прогон.
Время на исправление ошибок и возможные накладки.
По мере исправления ошибок затрачиваемое время растет, могут случаться накладки во время планирования и контроля. Итого — примерно 1,5 месяца работы двоих инженеров , которые обычно задействованы на выполнении регрессионных проверок.
Полквартала для завода, производства или банка, когда нужно срочно доработать функционал, внести правку, добавить модуль, оборачиваются потерей денег.
Заказчику нужны быстрые релизные итерации: запрос, разработка, короткое тестирование и внедрение. Главное — оставить качество на прежнем уровне, а лучше — повысить его по объективным количественным критериям. Именно так появляется необходимость автоматизации тестирования.
Конечно, не все в тестировании можно автоматизировать, и некоторые задачи все еще приходится делать вручную. Но если нужно узнать, насколько автоматизация возможна, полезна и пригодна на конкретном проекте, — команда WaveAccess пользуется manage-паттерном автотестирования “Do Pilot” (“создай пилотную версию”).
Стратегия Do Pilot заключается в том, чтобы автоматизировать часть работ и оценить их результат: потраченное время, масштабируемость тестов, стоимость их поддержки. То есть, сделать пилотную версию автотеста (АТ), а затем принять решение о том, стоит ли переводить всё тестирование в автоматизацию.
Всегда проще потратить пару недель, чтобы понять: найден полезный инструмент, пригодный для бизнеса, или это потеря времени.
К результату выдвинули требования:
Оперативность. Имеется возможность “на выходе” просматривать отчеты из CI (Continuous Integration) с ночными прогонами этих 6-ти тестов или получать письмо с описанием “упавших” тестов.
Прозрачность. Команда тестирования понимает, что именно проверяется в каждом шаге теста, а менеджер может читать отчет, написанный в понятной для него форме (например, "на окне n не хватает третьего поля ввода").
Стоимость. Выбранный и нструмент не удорожает проект без необходимости.
Главный вопрос, который встал перед нами, — поиск подходящего инструмента для написания АТ, который отвечал бы всем критериям.
Как мы уже сказали выше: web- и mobile-технологиях автотестирование сейчас преобладает. Рассмотрим, что же, все-таки, можно найти на этом поле для Windows Desktop.
Платные инструменты. TestComplete
Одним из лидеров платных фреймворков является полноценная студия для АТ TestComplete от SmartBear . У решения есть триал-период, есть положительные отзывы пользователей.
Выбираем решение "из коробки" на одного пользователя:
Выбираем кастомизированное решение, убираем "Web" и "Mobile".
Пытаемся максимально снизить цену. За возможность безлимитного тестирования и другие необходимые аддоны все же придется доплатить 1700 € для одной лицензии .
Научить команду тестирования пользоваться студией TestComplete можно, получив сертификаты по 150-700 € за каждый . Возьмём один базовый TestComplete Certification .
Итак, 4000 € за студию и один год поддержки на 1 пользователя . Однако заказчику мы хотели предложить такое решение, которое при сохранении качества платных решений “из коробки” не вынуждало бы его платить такую сумму нам, а через год — продолжать платить уже за продление лицензии.
Платные инструменты. Telerik Test Studio
Следующий платный инструмент — Telerik Test Studio. Его цены:
Но за каждую вспомогательную функцию придется платить:
Эта сумма — 2499 + 899 +599 = 4000$ — включает только одного пользователя и год поддержки . Умножив ее на количество пользователей, а на данном проекте команда WaveAccess состояла из двух инженеров, получаем итоговую цену: 8000$ за год. И многие другие платные фреймворки также удивляют ценообразованием.
Мы стремимся к оптимизации ресурсов при сохранении качества. Но главное — мы стремимся к тому, чтобы до конца понять: что именно мы предлагаем клиенту, как используем. Поэтому ПО с открытым программным кодом предпочтительнее, чем коробочное решение — этакий “кот в мешке”.
Часть II: Обзор фреймворков с открытым кодом
Автотестирование активно развивается для web- и mobile-проектов. Но десктопные приложения приходится тестировать до сих пор: их по-прежнему используют финансовые компании, производства, сегмент HoReCa. Зайдите в ближайший банк, кафе, ресторан - всюду вы увидите Windows Desktop. При этом тестирование таких приложений почти не развивается, информации о нем мало.
Эта статья написана по опыту одного из наших проектов: необходимо было тестирование Windows Desktop приложения с десятками тысяч строк кода. Ручная проверка подобного решения заняла бы слишком много времени, поэтому мы решили разработать пилотную версию автотестов для выполнения проекта.
Подбирая инструмент для этой задачи, мы столкнулись с тем, что функции коммерческих студий ориентированы, в основном, на web- и mobile-, сами решения неоправданно удорожают проект, и не до конца понятно, что у них "под капотом". Мы стремимся к тому, чтобы до конца понять: что именно мы предлагаем клиенту, как используем, поэтому обратились к поиску инструментов с открытым кодом и выбрали оптимальный.
Оперативность. Возможность "на выходе" просматривать отчеты из CI с ночными прогонами этих шести тестов (или получать письмо с описанием “упавших” тестов).
Прозрачность. Нужно, чтобы команда тестирования понимала, что именно проверяется в каждом шаге теста, а менеджер мог читать отчет в понятной для него форме (например: "на окне n не хватает третьего поля ввода").
Стоимость. Необходим инструмент, который не удорожает проект без необходимости.
Первым решением, опробованным для наших задач, стал Visual Studio Coded UI .
Те же технологии в тестировании, что и в разработке продукта.
Есть test recorder.
Работа с WinForms.
Работа с UI-контролами DevExpress.
Небольшой объем документации.
Test recorder генерирует плохо поддерживаемый код: тесты после записи и запуска сразу “падают” (возможно, не воспроизводится на “простых” интерфейсах).
Ограничения поиска и работы с элементами пользовательского интерфейса, накладываемые UIA API v.1 — MSAA.
Фреймворк CUITe может использоваться в дополнение к инструменту Coded UI под разные версии VS. Можно взять инструмент на заметку, но серьезных недостатков Coded UI он не исправляет.
Фреймворк TestStack.White — второе бесплатное решение, которое мы рассмотрели.
Совместим с фреймворками BDD.
MSAA, UIA 2, 3 — на выбор.
“Заброшенная” кодовая база явно нуждается в рефакторинге.
Апдейт Nuget пакета не проходил с 2014 года, но в репозитории есть изменения.
Дальнейший поиск привел команду к фреймворку WhiteSharp.
Совместим с фреймворками BDD.
Нет возможности нормально идентифицировать все элементы UI. Не подходит к DevExpress элементам.
Апдейт Nuget-пакета не происходил с 2016 года.
Немного документации, небольшое комьюнити.
Медленное исполнение элементарных кейсов (“открыть приложение”, “проверить содержимое строки статуса”)
Совместим с фреймворками BDD
Возможность использовать любую версию UIA: MSAA, UIA2 и UIA3
Поддерживаемая версия ОС Windows 7, 8, 10 (XP, скорее всего тоже, но мы не пробовали).
Хорошее комьюнити: решение проблем не только в issues, но и в чатах.
Разработан и поддерживается Microsoft.
Совместим с фреймворками BDD.
Невысокий порог вхождения, если был опыт написания тестов для веба или мобильных платформ.
Поддерживаемая версия ОС Windows 10+.
Взвесив плюсы и минусы решений, мы остановились на WinAppDriver’e и FlaUI.
На рынке так много программных продуктов для тестирования, что может показаться, будто для всего найдется готовое решение и нет необходимости тратить время и усилия на разработку инструментов тестирования. На самом деле это не так. Мы в «ЛАНИТ Экспертизе» убедились в этом, когда появилась задача тестирования Desktop-приложений, и теперь делимся с вами опытом.
В отличие от автоматизации WEB, API или мобильных приложений, тестирование Desktop в некоторой степени – «экзотика», и на это есть несколько причин:
- Отсутствуют качественные Open source решения, наподобие Selenium для Web, а те, что есть, либо сильно устарели, либо неудобны в использовании. Иными словами, воспитывают в автоматизаторах смирение и обреченность.
- Коммерческие продукты хоть и обладают широким функционалом и удобством в использовании, стоят зачастую дороже, чем вся автоматизация и используют vendor lock-in бизнес-модель, которая также накладывает дополнительные затраты и ограничения (переобучение персонала, отсутствие возможности использовать существующие наработки и решения, полная зависимость от поставщика ПО и т.п.).
- Ввиду стремительного развития web-технологий, Desktop понемногу отмирает, что сильно сказывается на развитии и поддержке инструментов тестирования и наличии квалифицированных специалистов в этой области.
Обзор предлагаемых решений показал, что Open source продуктов не так уж много. Сначала мы испытали Winium – Automation framework for Windows platforms.
Winium – это фреймворк для тестирования Desktop Windows приложений на базе Selenium. Он обладает всеми основными требованиями, которые были необходимы для работы с предстоящим проектом:
- поддержка WinForms и WPF приложений;
- REST-протокол взаимодействия между тестами и тестируемым приложением;
- возможность взаимодействия с Selenium (а конкретно Java + Selenium).
Дальнейший анализ инструментов тестирования показал, что наиболее оптимальный вариант – это реализация своего инструмента. Имеющиеся продукты обладали теми или иными серьезными недостатками, а комбинировать несколько решений не представлялось возможным. Так как абсолютно все Open source решения использовали взаимодействие со стандартной библиотекой Windows Automation API, то было принято решение взять за основу ядро FlaUI Core, построенное на основе взаимодействия с данной библиотекой, и обладающее полным функционалом взаимодействия с элементами тестируемого приложения. Затем добавить поддержку Selenium REST API, аналогично Winium. Так родился проект FlaNium.
На данный момент в состав проекта входят пока только два компонента.
FlaNium.Desktop.Driver – основной компонент, представляющий из себя драйвер взаимодействия с тестируемым приложением посредством Windows Automation API и использующий протокол взаимодействия Selenium REST API.
FlaNium.WinAPI – Java-библиотека, расширяющая протокол Selenium REST API и добавляющая дополнительные возможности по настройке и взаимодействию с FlaNium драйвером. Также данная библиотека позволяет типизировать стандартный Selenium WebElement и привести его к компонентам тестируемого приложения, добавляя дополнительные методы взаимодействия, характерные определенному типу элемента.
Кто хоть немного сталкивался с тестированием, а особенно с тестированием Web-приложений знает, что такое Selenium WebDriver. Есть много информации про Selenium, поэтому в статье мы не будем рассматривать плюсы и минусы, а также особенности работы с Selenium, а рассмотрим лишь особенности работы с FlaNium драйвером.
Перед началом работы с FlaNium драйвером необходимо загрузить последнюю версию драйвера, а также прописать следующие зависимости в pom.xml:
Далее производим настройку и инициализацию драйвера:
После получения экземпляра FlaniumDriver можно осуществлять поиск контролов приложения и взаимодействовать с ними через стандартные методы библиотеки Selenium.
Есть возможность поиска элементов по XPath, Name, Id (AutomationId) и ClassName, а также поддерживаются пять параметров поиска с помощью XPath – AutomationId, Name, ClassName, HelpText, ControlType.
Для более комфортной работы лучше воспользоваться такими инструментами как FlaUInspect, UISpy и подобными, так как они значительно упрощают написание тестов приложения, позволяя визуально отобразить структуру и параметры элементов приложения. Данные инструменты также позволяют понять, как можно обратиться к различным элементам или какие паттерны поддерживает конкретный из них.
Благодаря расширению протокола Selenium есть возможность типизировать любой WebElement и получить дополнительные возможности для работы. Для этого необходимо создать экземпляр требуемого класса и передать WebElement в качестве параметра:
Рассмотрим на примере, для чего нужна типизация и что нам даёт расширение протокола Selenium. Возьмем для примера выбор значения из выпадающего списка:
На рисунке ниже изображено тестируемое приложение (слева) и инспектор (справа):
У нас есть элемент ComboBox, согласно инспектору, доступа к элементам списка у нас нет, чтобы его получить необходимо раскрыть список нажав на кнопку «Открыть».
После раскрытия списка мы получаем доступ ко всем вложенным элементам и можем осуществлять поиск и выбор необходимого элемента.
Вот так будет выглядеть код при использовании стандартных Selenium-методов:
А вот так будет выглядеть то же самое, но при использовании методов типизированных элементов библиотеки FlaNium.WinAPI:
Как мы видим, использование данных методов значительно упрощает взаимодействие и сокращает код. С полным списком поддерживаемых элементов и реализованных методов можно ознакомиться по ссылке.
Мы не изобретали ничего кардинально нового, но взяв в основу преимущества Winium и FlaUI, скомпоновали продукт с удобным универсальным интерфейсом и широкими возможностями взаимодействия с тестируемым приложением. Удалось объединить протокол Selenium REST и библиотеки Windows Automation API.
Давайте рассмотрим, чем же обязан FlaNium этим двум проектам:
На момент написания статьи драйвер уже внедрен в один из наших проектов и успешно работает. Вложив силы и время в разработку собственного драйвера, удалось значительно сократить время и потратить меньше усилий на создание фреймворка и его внедрение, а также сильно упростить написание тестов.
Поскольку драйвер использует универсальный протокол взаимодействия, стало возможным использовать уже имеющийся фреймворк тестирования с некоторыми изменениями. Была добавлена работа с элементами посредством библиотеки FlaNium.WinAPI и реализована логика работы с конкретным тестируемым приложением. Также удалось избежать сложностей при работе с элементами приложения, поскольку используется полноценная библиотека взаимодействия и не возникало ситуаций, когда нет доступа к какому-либо параметру элемента.
Кроме всего перечисленного, внедрение данного драйвера позволило отказаться от вендорского ПО для тестирования, сократив стоимость автоматизации и её поддержки на значительную сумму, а также унифицировать стек технологий и требования к квалификации автоматизаторов.
Мы не останавливаемся на достигнутом и продолжаем развивать данный проект. Помимо взаимодействия с приложениями посредством Windows API ведется разработка технологии взаимодействия с приложением «изнутри» посредством инжекта исполняемой библиотеки в код тестируемого приложения. Данная технология необходима, например, для полноценного тестирования Delphi приложений, чего нельзя добиться с помощью стандартного Windows API.
С конфигурациями десктопного приложения у тестировщика вяжется два аспекта.
1. Конфигурации самого приложения.
Чтобы тестировать продукт, мы должны знать, как его конфигурировать – то есть как указать правильные настройки, которые необходимы, чтобы ПО работало адекватно, ну или вообще работало. Например, это могут быть параметры базы данных, логин и пароль от нее, профиль пользователя (его права, набор функциональностей, которые ему доступны), набор плагинов, который должна запустить данная конфигурация, и т.д.
Если указать эти конфигурации неправильно, то приложение не будет работать корректно, и мы будем получать ошибку не по причине того, что программный код написан неправильно, а потому что программа не может выполнить требуемого из-за неправильной конфигурации.
Например, не может выдать информацию по причине отсутствия доступа к базе данных. Или выдает не тот результат, который мы ожидаем, по причине того, что в конфигурациях указана не та БД (база данных). Поэтому, приступая к тестированию продукта, надо познакомиться не только с интерфейсом и технической документацией, но также разобраться в тонкостях параметров конфигурации.
Параметры конфигурации программного обеспечения указываются обычно в текстовом файле. Его можно изменять вручную или в специальном интерфейсе. Обычно для этого достаточно простого блокнота. Более удобной и продвинутой программой является Notepad++.
2. Конфигурационное тестирование.
Это специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.). Оно проводится в ситуациях, когда надо подобрать оптимальные конфигурации для адекватной и бесперебойной работы ПО. Особое значение этот вид тестирования имеет при миграции на другую платформу. В этом случае нам необходимо проверить наш продукт на совместимость с объявленным в спецификации оборудованием, операционными системами и программными продуктами третьих фирм.
ISTQB не выделяет конфигурационное тестирование как отдельный вид. Вышеописанные тесты попадают под определение тестирования портируемости (portability testing).
Чтобы осуществлять такое тестирование, нужно разобраться не с конфигурациями тестируемого продукта, а с конфигурациями окружения. Причем во внимание следует брать не только программные средства (драйвера и библиотеки, стороннее ПО, которое может повлиять на наше, типы и версии ОС, ее конфигурации) но и аппаратные (количество и тип процессоров, объем памяти, параметры сети и сетевые адаптеры).
Определить конфигурацию рабочей машины можно, зайдя в Bios компьютера (как это сделать, можно прочитать, например, здесь). Какие-то типовые советы по определению и изменению конфигурации компьютера на основе информации из BIOS дать нелегко, так как интерфейс и возможности у разных типов и ревизий BIOS отличаются, и бывает, что довольно существенно. Но в интернете об этом есть достаточно информации. Достаточно сделать запрос, упомянув фирму и модель своей рабочей машины.
Конфигурации системы Windows хранятся в реестре Windows. Это сложная древовидная структура, в которой до конца не разбираются, наверно, даже ее создатели, настолько она сложна и объемна. Информации по реестру много, начинающему тестировщику, да и вообще пользователю, стоит помнить, что не стоит вносить какие-либо изменения в реестр Windows, если ты на 100% не уверен, что ты делаешь. Если такая уверенность составляет хотя бы 99% – лучше всего записать, что конкретно в реестре было изменено.
1. Требования
1.1. к объекту
1.1.1.1. Надежность соединения
1.1.1.2. Безопасность соединения
1.1.2. Не функциональные
1.1.2.1. Простота подключения к прокси серверу
1.1.2.2. простота использования
1.2. к окружению
1.3. необходимые инструменты
1.3.1. Подключение к сети
1.3.1.1. Wifi соединение
1.3.1.1.1. роутер с UpnP порт 7775
1.3.1.2. Интернет соединение
1.3.2. Java Runtime invironment 1.8.0
1.3.3. Прокси сервер
1.3.4. Apache Jmeter
2. Информация об объекте
2.1. Объект исследования
2.1.1. Десктопное приложение для Android "Socks".
2.2. Описание
2.2.1. Разработано на основе Java 8. Поддерживается платформами Windows и Mac. Запускается с помощью исполняемого файла Socks_tool. exe
2.3. Характеристики
2.3.1. Упрощает подключение к прокси серверу.
2.4. Функции объекта
2.4.1. подключение к прокси серверу
2.5. Внешний вид
2.5.1. Простой дизайн
2.5.2. Понятный интерфейс
2.6. Компоненты
2.6.1. Фоновая служба
2.6.1.1. запускает соединение с прокси сервером
2.6.1.2. Независимо от выключения программы запоминает запрос и поддерживает его определенное время
2.6.1.3. передает данные ip адреса DNS службе
2.6.1.3.1. регистрирует недавно установленную программу, как потенциальный прокси сервер
2.6.1.3.2. запоминает ip и присваивает уникальное значение Id.
2.6.1.3.3. Сформированный id будет использован, как часть доменного имени
2.7. Спецификация
2.7.1. Соединение с прокси сервером поддерживает только TCP трафик
2.7.2. Запуск программы возможен только с установленной Java средой
2.7.3.2. модель девайса
2.7.3.3. сегмент местоположения
2.7.3.4. Счетчик соединений
2.8. Принципы работы приложения
2.8.1. 1. Запуск приложения
2.8.2. 2. Выбор сервера для подключения
2.8.3. 3. Соединение с прокси сервером
2.8.4. 4. Получение нового ip адреса прокси сервера
2.8.5. 5. Обновление соединения с сетью
2.8.6. 6. Возможность свернуть окно программы в SystemTray
2.8.7. 7. Выход из приложеня
3. Критерии к выполнению тестирования
3.1. Начало выполнения
3.1.1. Знакомство с ТЗ или составление ТЗ
3.1.2. Анализ Объекта
3.1.4. Выделение ресурсов
3.1.5. Подготовка инструментов
3.2. Конец выполнения
3.2.1. Результаты тестирования удовлетворяют критериям качества приложения
3.2.2. Нет критичных и High багов
3.2.3. ZBB (Zero Bug Bounce)
4. тестирование
4.1. Цели
4.1.1. Оценить на сколько продукт соответствует требованиям
4.1.2. Оценить на сколько ожидаемый результат тестирования соответствует фактическому результату
4.1.3. Оценить качество приложения и понять, требуется ли действия по его улучшению.
Читайте также: