Pull to refresh

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

Reading time 6 min
Views 31K
В прошлом году в нашей компании появился не только 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


  • Какие типы приложений можно тестировать: тут набор Ranorex сравним с HP QTP: Windows native (WinForms, WPF, Win32), Java, Qt, Delphi, Flex + конечно HTML (браузеры — IE, Firefox, Chrome, Safari). В последней версии появилась также поддержка тестирования мобильных клиентов на Android и iOS, но я пока этой возможностью не воспользовался
  • Запись действий и репозитории элементов: Ranorex поддерживает как запись действий при помощи встроенного рекордера (аналогично HP QTP) так и идентификацию элементов пользовательского интерфейса при помощи компонента Ranorex Spy.
    Ranorex Spy
    Все идентифицированные элементы хранятся в XML репозитории, где каждый элемент записан при помощи XPath нотации. Например, кнопка на панели инструментов может быть описана как:
    /form[@ title~'^MyApp']//toolbar[@ controlname='mainToolbar']/button[@ controlname='addUser']
    
    На основе записи (recording) происходит авто-генерация кода (в C# либо VB.NET). Любой шаг может быть написан также вручную (например repo.MyApp.MainPain.BtnOk.Click();)
  • Идентификация элементов пользовательского интерфейса: Использование XPath (или, как он здесь называется, RanoreXPath) делает поиск необходимых элементов в большинстве случаев чрезвычайно легким. Например, поддерживаются регулярные выражения (form[@ title~'^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())
    Ranorex Recorder
  • IDE: Ranorex Studio основан на бесплатном SharpDevelop. В результате организация кода и тест кейсов максимально напоминает MS Visual Studio: Все тест-кейсы разложены по проектам. Проекты, которые используются вместе, можно объединять в решения (solutions). На выходе после компиляции мы получаем по одному EXE файлу на решение и по 1 DLL на проект. Достаточно скопировать их на тестовую машину и запустить как обычное Windows приложение
    Ranorex Studio
  • Организация тест-кейсов: На каждое решение (solution – см. выше) приходится по одному тест-сьюту. В этот тест-сьют мы добавляем необходимые нам тест-кейсы и перетягиваем recordings из наших проектов. Recording’и могут быть либо записанными автоматически, либо написанными на одном из поддерживаемых языков вручную. Здесь же в ручных модулях мы можем использовать любой необходимый нам код на C# / VB.NET, например код для доступа к реестру Windows, загрузки файлов по FTP, и т.д.
  • Data-Driven Testing: любой тест-кейс может быть связан с данными из CSV / Excel файла, либо из базы данных. Каждый модуль (запись) может иметь переменные, связанные с данными либо заполняемые в самом модуле
    image
  • Язык программирования: для написания тестов в Ranorex используются либо C# либо VB.NET. В случае с HP QTP используется VB Script. Наверное, для людей без опыта программирования VB.NET или тем более C# являются более сложными в изучении, чем VB Script. Скриптовые языки, как правило, больше подходят для автоматизации тестирования, но лично я, выбирая между C# — полноценным ОО языком с полной поддержкой .NET и скриптовым и довольно таки примитивным VB Script, конечно отдаю предпочтение C#. Для некоторых оптимальным выбором станет поддержка в Ranorex языка VB.NEТ.
    image
  • Хранение и версионирование кода: 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 формате
    image


Цена


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

Выводы


На основании нашего сравнительного тестирования Ranorex и HP QTP мы предпочли в дальнейшем использовать именно Ranorex. Главными плюсами для нас стали: удобная и понятная среда разработки, полноценная поддержка .NET разработки и языков C# и VB.NET, использование XPath для идентификации элементов в репозитории, возможность хранения тестов в нашей стандартной системе версионирования (Git), легкость интеграции с системой CI (Jenkins).
Tags:
Hubs:
+5
Comments 8
Comments Comments 8

Articles