Автоматизация тестирования windows приложений

Автоматизированное функциональное тестирование Windows приложений с использованием Ranorex

В прошлом году в нашей компании появился не только Web, но и Windows клиент. Так как средства автоматизации тестирования, которыми мы пользовались для Web (например Selenium) в данной ситуации мы конечно использовать не могли, перед нами возникла необходимость поиска технологии автоматизированного функционального тестирования для Windows приложений.

Критерии нашего поиска были следующими:

• Среда разработки функциональных тестов должна поддерживать как автоматическую запись тест-кейсов (для использования тестерами с минимальным опытом программирования), так и возможность писать отдельные части тестов вручную
• Так как клиент разрабатывается на C#, хотелось бы и функциональные тесты писать либо на C#, либо на одном из .NET языков
• Должна быть поддержка Data-Driven Testing
• Для идентификации элементов пользовательского интерфейса желательно должен использоваться XPath
• Код и все артефакты тестирования должны храниться в той же системе контроля версий, в которой хранится наш основной код (в нашем случае — Git)
• Данная технология автоматизированного функционального тестирования должна быть легко встроена в нашу систему непрерывной интеграции (Jenkins)

После предварительного исследования рынка, мы остановились на 2 продуктах:

1. HP QuickTest Professional, который является одним из наиболее используемых продуктов на рынке, но имеет при этом чрезвычайно высокую цену
2. Ranorex – продукт более новый (хотя я о нем впервые услышал еще в 2007 году, но тогда он был еще довольно-таки сырым), но уже часто упоминаемый в качестве альтернативы на профессиональных форумах

В течении месяца я тестировал оба продукта (HP QTP 11 и Ranorex 4) и теперь хотел бы поделится своими выводами о возможностях Ranorex, сравнением его с HP QuickTest Professional, а так же рассмотреть интеграцию Ranorex с CI сервером Jenkins (но интеграция с другими сервероми, например TeamCity, будет выглядеть аналогично).

Возможности Ranorex

‘^MyApp.*’] ), поиск всех потомков ( .//button ), логические операторы ( @ text=’OK’ OR @ controlname=’buttonOK’ ), встроенные функции ( table/row/cell[first()=’True’] ) и многое другое. Что очень удобно, каждый элемент в репозитории имеет свойство search-timeout. Например если мы работаем с кнопкой из примера выше и у окна ( form[@ title

‘^MyApp’] ) search-timeout составляет 30 секунд, то Ranorex будет в течении 30 секунд дожидаться появления этого окна (например, при старте приложения), после чего перейдет к выполнению действий с кнопкой. Это позволяет практически полностью отказаться от использования в тестах функции wait()

Элементы в репозитории: в Ranorex мы работает с различными типами элементов (например: form , toolbar , container , tree , list , и т.д.). Так как мы работает с элементами не напрямую, а с адаптерами элементов, то элемент button и в случае Windows native приложения, и в случае Java предложения и в случае Flex и т.д. будет иметь сходный набор свойств и методов (например text , pressed , click() )

IDE: Ranorex Studio основан на бесплатном SharpDevelop. В результате организация кода и тест кейсов максимально напоминает MS Visual Studio: Все тест-кейсы разложены по проектам. Проекты, которые используются вместе, можно объединять в решения (solutions). На выходе после компиляции мы получаем по одному EXE файлу на решение и по 1 DLL на проект. Достаточно скопировать их на тестовую машину и запустить как обычное Windows приложение

Организация тест-кейсов: На каждое решение (solution – см. выше) приходится по одному тест-сьюту. В этот тест-сьют мы добавляем необходимые нам тест-кейсы и перетягиваем recordings из наших проектов. Recording’и могут быть либо записанными автоматически, либо написанными на одном из поддерживаемых языков вручную. Здесь же в ручных модулях мы можем использовать любой необходимый нам код на C# / VB.NET, например код для доступа к реестру Windows, загрузки файлов по FTP, и т.д.

Data-Driven Testing: любой тест-кейс может быть связан с данными из CSV / Excel файла, либо из базы данных. Каждый модуль (запись) может иметь переменные, связанные с данными либо заполняемые в самом модуле

Язык программирования: для написания тестов в Ranorex используются либо C# либо VB.NET. В случае с HP QTP используется VB Script. Наверное, для людей без опыта программирования VB.NET или тем более C# являются более сложными в изучении, чем VB Script. Скриптовые языки, как правило, больше подходят для автоматизации тестирования, но лично я, выбирая между C# — полноценным ОО языком с полной поддержкой .NET и скриптовым и довольно таки примитивным VB Script, конечно отдаю предпочтение C#. Для некоторых оптимальным выбором станет поддержка в Ranorex языка VB.NEТ.

Хранение и версионирование кода: HP QTP хранит код и репозитории частично в бинарном формате, что делает его версионирование сторонними средствами вроде SVN или Git довольно-таки проблематичным (а собственная система версионирования на основе HP QC мне показалась чрезвычайно примитивной, например, я не нашел возможности коммита сразу нескольких ресурсов, теггирования, и т.д.). В отличие от него, Ranorex хранит весь код (в том числе созданный авто-генерацией) и все репозитории в текстовом виде (например для репозиториев используется XML format) – это дало нам возможность для версионирования и совместной разработки использовать привычный нам Git со всеми его возможностями вроде локального репозитория, теггирования и т.д.

Использование Ranorex с системой непрерывной интеграции

В отличие от HP QTP, у Ranorex нет системы, позволяющей запускать тесты по расписанию либо по внешнему триггеру на удаленных компьютерах. С одной стороны это минус, с другой мы смогли без проблем интегрировать Ranorex тесты с нашим Jenkins сервером (но подойдет любой сервер, например тот же TeamCity):

1. Компиляция Ranorex тестов: На Jenkins у нас имеется джоб Build_Ranorex_Tests. Как только один из тестеров делает push кода в наш Git-репозиторий, один из Git-hook’ов запускает этот джоб. Он состоит из двух фаз: компиляции всех решений (тест-сьютов) с использованием MS Build ( /t:Clean,Build /p:Configuration=Release ). По окончанию фазы MS Build, все необходимые для тестирования файлы (а именно EXE (по одному на решение), DLL (по одному на проект), CSV / Excel и другие) архивируются (шаг — Archive the artifacts)
2. Исполнение тестов: Далее запускается следующий “матричный” джоб на всех тестовых машинах (мы тестируем под Windows XP, Vista и Windows 7) на которых установлены Jenkins Slaves. Этот джоб сначала устанавливает последнюю версию нашего приложения (используя MSI), далее последовательно запускает EXE файлы тест-сьютов которые были скомпилированы предыдущим джобом (см. выше). После их выполнения мы получаем по одному ZIP файлу на тест-сьют, в каждом из которых содержится 1 XML файл с результатами и директория со скриншотами
3. Представление результатов: После этого скрипт (его можно сделать отдельным небольшим сьютом в Ranorex, который будет запускаться последним) переводит Ranorex XML формат в xUnit format. Благодаря этому по каждому клиенту мы имеем как репорт в Ranorex формате так и в формате понятном Jenkins’у, благодаря чему Jenkins может нарисовать график результатов тестов. Jenkins так же высылает по почте всем заинтересованным лицам результаты тестов в Ranorex формате
   

К сожалению, в отличие от того же Selenium’a, Ranorex не является бесплатным продуктом с открытым кодом. Но сравнивать систему автоматического тестирования под Windows необходимо не с Selenium, а с теми же HP QTP или IBM Rational Functional Tester. В этом случае Ranorex ne кажется таким уж и дорогим. 1 лицензия с привязкой к рабочему месту стоит 1 480 евро за покупку + 290 евро в год (начиная со второго) за дальнейшие обновления и поддержку. Это в несколько раз дешевле HP QTP и IBM Rational Functional Tester

Источник

Как автоматизировать тестирование на desktop. Часть II: Обзор фреймворков с открытым кодом

Автотестирование активно развивается для web- и mobile-проектов. Но десктопные приложения приходится тестировать до сих пор: их по-прежнему используют финансовые компании, производства, сегмент HoReCa. Зайдите в ближайший банк, кафе, ресторан — всюду вы увидите Windows Desktop. При этом тестирование таких приложений почти не развивается, информации о нем мало.

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

Подбирая инструмент для этой задачи, мы столкнулись с тем, что функции коммерческих студий ориентированы, в основном, на web- и mobile-, сами решения неоправданно удорожают проект, и не до конца понятно, что у них «под капотом». Мы стремимся к тому, чтобы до конца понять: что именно мы предлагаем клиенту, как используем, поэтому обратились к поиску инструментов с открытым кодом и выбрали оптимальный.

Итак, нашей задачей было создать пилотную версию АТ (автотестов). Конечной целью — автоматизация тестирования сложного .NET desktop приложения. При подборе инструмента выдвигали следующие требования:

Оперативность. Возможность «на выходе» просматривать отчеты из CI с ночными прогонами этих шести тестов (или получать письмо с описанием “упавших” тестов).

Прозрачность. Нужно, чтобы команда тестирования понимала, что именно проверяется в каждом шаге теста, а менеджер мог читать отчет в понятной для него форме (например: «на окне n не хватает третьего поля ввода»).

Стоимость. Необходим инструмент, который не удорожает проект без необходимости.

Сравнение бесплатных фреймворков

Первым решением, опробованным для наших задач, стал Visual Studio Coded UI .

Плюсы:

Те же технологии в тестировании, что и в разработке продукта.

Есть test recorder.

Работа с UI-контролами DevExpress.

Минусы :

Небольшой объем документации.

Test recorder генерирует плохо поддерживаемый код: тесты после записи и запуска сразу “падают” (возможно, не воспроизводится на “простых” интерфейсах).

BDD-написание тест-кейсов (с использованием, например, одного из самых популярных фреймворков на языке C# — Specflow) несовместимо “из коробки” с Coded UI.

Ограничения поиска и работы с элементами пользовательского интерфейса, накладываемые UIA API v.1 — MSAA.

Фреймворк CUITe может использоваться в дополнение к инструменту Coded UI под разные версии VS. Можно взять инструмент на заметку, но серьезных недостатков Coded UI он не исправляет.

Фреймворк TestStack.White — второе бесплатное решение, которое мы рассмотрели.

Плюсы:

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

Совместим с фреймворками BDD.

MSAA, UIA 2, 3 — на выбор.

Минусы:

“Заброшенная” кодовая база явно нуждается в рефакторинге.

Апдейт Nuget пакета не проходил с 2014 года, но в репозитории есть изменения.

Дальнейший поиск привел команду к фреймворку WhiteSharp.

Плюсы:

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

Совместим с фреймворками BDD.

Минусы:

Нет возможности нормально идентифицировать все элементы UI. Не подходит к DevExpress элементам.

Апдейт Nuget-пакета не происходил с 2016 года.

Немного документации, небольшое комьюнити.

Медленное исполнение элементарных кейсов (“открыть приложение”, “проверить содержимое строки статуса”)

У Winium.Desktop оказался большой минус — отсутствие поддержки с .NET 4.0

FlaUI — инструмент для полноценного написания тестов на языке С#. Автор подчеркивает, что он хотел переписать с чистого листа TestStack.White, убрав ненужное и устаревшее.

Плюсы:

Совместим с фреймворками BDD

Возможность использовать любую версию UIA: MSAA, UIA2 и UIA3

Поддерживаемая версия ОС Windows 7, 8, 10 (XP, скорее всего тоже, но мы не пробовали).

Хорошее комьюнити: решение проблем не только в issues, но и в чатах.

WinAppDriver + Appium — инструмент для полноценного написания тестов на языках разработки: C#, Java, Python.

Плюсы:

Разработан и поддерживается Microsoft.

Совместим с фреймворками BDD.

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

Минусы:

Поддерживаемая версия ОС Windows 10+.

Взвесив плюсы и минусы решений, мы остановились на WinAppDriver’e и FlaUI.

Пример работы с двумя выбранными решениями

Перед стартом написания тестов нужно выбрать инспектор UI-элементов. К примеру, здесь . Наши QA-специалисты предпочитают Inspect.exe и UISpy.exe.

WinAppDriver

Системные требования: Windows 10 (более новые версии ОС, к сожалению, не поддерживаются). Разумеется, необходимо скачать, инсталлировать и запустить WinAppDriver.exe . Затем мы поставили на машину Appium , запустили Appium Server (“демон”). Если не хочется писать на C# — напишем, например, на Python+Robot.

Создаём сессию приложения и подключаемся к ней:

Опишем шаг запуска приложения:

Инспектором находим кнопки и кликаем по ним:

Описываем шаг получения результата:

Шаг выхода из приложения:

В итоге, Robot-тест проверки вычисления квадратного корня будет выглядеть вот так:

Запускать тест можно как обычный робот-тест из командной строки: robot test.robot. Существует подробная документация по BDD Robot Framework . Возможно тестирование приложений из WinStore и классических приложений.

Поддерживаемые типы локаторов:

Можно сделать вывод, что это полностью Selenium-like тест. Можно применять любые паттерны тестирования: Page Object и т.д., добавить BDD framework (для Python, например, это Robot Framework или Behave ).

FlaUI

Фактически является “обёрткой” над UI Automation libraries. Коммерческие утилиты, разобранные раньше, также являются “врапперами” над предоставленным Microsoft API для автоматизации.

Windows 7 PC, VS. Запускаем приложение и аттачимся к процессу:

Инспектором находим поле ввода и отправляем в него строку:

Основные виды поиска элементов:

Можно реализовать поиск по любому поддерживаемому элементом паттерну, например, по Value или LegacyAccessible. Или по условию.

Наша команда особенно оценила класс условных ожиданий

Retry.While(foundMethod, Timeout, RetryInterval);

Внутри — выполнение в цикле входящего метода через заданный интервал на протяжении заданного таймаута. Больше никаких слипов основного потока исполнения.

Создаем объект LoginWindow, только когда логин окно действительно отображается (интервал и таймаут — дефолтные). Такой подход избавляет от нестабильных тестов.

Сроки разработки тестов. Поддержка, стабильность UI-тестов

На шесть довольно объемных Regress-сценариев из примера было заложено три месяца разработки с “нуля”, включая ознакомление проектом, исследование доступных, описанных выше, фреймворков, создание скелета проекта АТ, настройка CI (continuous integration), менеджмент и коммуникации, сопроводительную документацию. Проект выполнен и сдан в срок.

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

Помещаем тесты в Continuous Integration

Оба фреймворка поддерживают запуск тестов с использованием систем непрерывной интеграции. В нашей команде использовали TC и TFS.

При использовании фреймворка FLAUI, фреймворка SpecFlow и тестов, написанных на языке C#, в создании сборки нет ничего особенного (svc — build — run), кроме соблюдения некоторых условий на агенте исполнения тестов:

Агент сборки запускается как утилита из командной строки (вместо сервиса), обе системы это поддерживают. Необходимо установить автозапуск такого агента.

Automatic logon setup (Use SysInternals Autologon for Windows as it encrypts your password in the registry).

Отключить Windows Error Reporting. Справка на Gist: DisableWER.reg

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

RDC. Но часто можно встретить и совет пользоваться VNC (с аргументацией что: при подключении через Удаленный рабочий стол и последующем отключении, десктоп будет заблокирован When you connect using Remote desktop, then disconnect, the desktop will be locked, and UI Automation will fail)

BDD-фреймворк Specflow имеет интеграцию “на лету” c TC и TFS. Т.е. непосредственно в прогоне тестов отображается отчет об успешных и проваленных тестах.

Пример ROI автотестов

Перед внедрением автоматизации подсчитать ROI сложно, поскольку существует огромное количество неизвестных факторов и коэффициентов. (И лучше не верить калькуляции ROI в разделе прайсинга Test Complete).

Но после реализации пилотного проекта автоматизации можно привести некоторые цифры. Возьмем самую простую формулу ROI:

ROI = (Gain of Investment — Cost of Investment) / Cost of Investment

Стоимость проекта автоматизации за первый год (без поддержки):

3 месяца на покрытие автотестом Regress-прогона при работе одного инженера-разработчика в тестировании: получается, 500 часов * Dev-ставка в час . Допустим, стоимость решения (Cost of investment) оплачивается заказчиком полностью в первый год (не делится по частям, и на покупку решения не берется кредит).

Выгода:

В первой статье мы подсчитали, что чистый “прогон” регресс-тестов вручную занимает 1 месяц: 2 недели первичный прогон + 2 недели вторичный прогон (без проверки новых тестов и сопутствующих расходов).

После разработки АТ-регресса (3 месяца), 9 месяцев в году прогоны регресс-теста руками не исполняются. Будем считать, что высвободившиеся ресурсы подключили к другим проектам в компании. Сохранили: 1500 часов * QAставка в час * 2 человека в команде .

ROI = (1500*QA*2 — 500*Dev) / 500 * Dev = (6*QA — 1*Dev) / Dev

При взятии по рынку средних значений QA ставка = n, Dev ставка = 1,5n получаем:

ROI = (6n — 1,5n) / 1,5n = 3.

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

Разумеется, это самый общий подсчет, не учитывающий поддержку, амортизацию, доработку отчетности, а также качество самих автотестов. Второй подсчет ROI рекомендуется проводить после первого года использования АТ с учетом этих дополнительных фактов.

Результат

Разработанные автотесты заменяют ручные силы команды QA и высвобождают команду из двух человек для более важных проектных задач. При этом оптимально расходуются ресурсы проекта.

Да, мануальное тестирование — необходимая часть разработки. Но если ПО состоит из десятков тысяч строк кода и требует двух-трех недель от разработки новой функции до релиза, автоматизация очень важна. Чтобы понять, выгодно ли покрытие всех работ автотестами и возможно ли оно, наша команда применяет стратегию Do Pilot: то есть, автоматизирует участок работ при помощи выбранного фреймворка.

Тем не менее, если использовать в платных “коробочных” решениях для АТ все нужные функции и масштабировать команду хотя бы до двух инженеров — поддержка таких решений удорожает проект. Чтобы на заказчика ПО не ложилась необходимость платить в начале за само решение, а потом — каждый год — за его поддержку, мы рассмотрели несколько фреймворков для АТ с открытым кодом. Из предложений выбрали те, которые нас устраивают. Два найденных решения использовали для работы.

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

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

Источник