CodedUI или Ranorex? Автоматизация функционального тестирования .NET приложений

    Автор статьи — Татьяна Курносова, но она поехала покорять горы Киргизии. Поэтому честь опубликовать этот пост выпала мне.

    В компании 2ГИС помимо известных Desktop, Mobile и Online-приложений, разрабатывается множество внутренних Enterprise-продуктов. Эти продукты скрыты от глаз пользователей, однако, именно с их помощью выполняется колоссальная работа по обеспечению всей инфраструктуры 2ГИС картографическими и справочными данными. Обработка этих данных трудозатратна и требует безошибочных расчётов, поэтому перед «приёмом на работу» все продукты тщательно тестируются.

    В этой статье я расскажу, как мы выбирали инструменты, как анализировали их технические возможности, чтобы они вписывались в нашу инфраструктуру, и на чём остановились.



    В своё время перед нами встала задача выбора пакета, подходящего для тестирования пользовательского интерфейса используемых продуктов. Всё, что поддаётся автоматизации, мы покрываем автоматизированными тестами, и GUI — не исключение. Для этого, как известно, существуют инструменты, позволяющие имитировать действия пользователя.

    С учётом того, что тестируемые продукты реализованы на .NET, а их тестировщики знакомы с языком программирования С#, было принято решение разрабатывать тесты также на языке C#. Из большого набора инструментов, представленных на рынке, мы остановились на двух. Первый — CodedUI, который поставляется с активно используемой нами Microsoft Visual Studio. Второй — Ranorex, так как он совместим с Visual Studio, имеет удобный интерфейс и положительные отзывы тестировщиков.

    Coded UI является одним из решений, поставляемых вместе с Microsoft Visual Studio Premium/Ultimate, предоставляет доступ к библиотекам для разработки тестов.

    Ranorex Automation Tools — это полноценная среда разработки, а также набор инструментов и библиотек для написания тестов.

    Далее нам предстояло сделать выбор в пользу одного из этих продуктов.

    Критерии сравнения


    Мы сформулировали основные критерии, по которым сравнивали пакеты:
    1. Поддержка динамически генерируемых графических элементов управления (контролов)
    2. Настраиваемая система поиска контролов
    3. Простая поддержка тестов, основанных на данных (Data Driven Testing)
    4. Возможность разрабатывать свои модули (фреймворки) и использовать их при разработке тестов на C#
    5. Поддержка запуска тестов на сервере Continuous Integration (TeamCity)
    6. Генерация информативных отчетов по результату прогона тестов
    7. Возможность интеграции тестов с тест-кейсами системы тест-менджмента (TMS)
    8. Простота изучения и использования тестировщиками

    Тестовый макет


    Для сравнения возможностей было разработано тестовое приложение с GUI на базе на Windows Presentation Foundation (WPF). Оно содержало все ключевые элементы GUI, которые в будущем могут учавствовать в тестировании реальных продуктов.

    Сравнение продуктов по критериям


    1. Поддержка динамически генерируемых контролов


    CodedUI
    CodedUI предоставляет объект класса UIMap, который реализует доступ ко всем UI-элементам приложения. Можно динамически получить любой элемент интерфейса, зная его название, или путём прохождения по цепочке вложенных элементов, например:

    «Первое текстовое поле на первой вкладке»
    this.UIViewmodeltitleWindow.UIItemTabList.Tabs[0].GetChildren()[1].GetChildren()[1]
    

    Однако, такую запись можно сформировать только непосредственно в коде теста.

    Ranorex
    В Ranorex аналогом UIMap служит GUI Object Repository. Для доступа к элемнтам используется язык XPath, поэтому выбрать элемент можно сгенерировав с помощью встроенного рекордера соответствующий запрос.

    «Первое текстовое поле на первой вкладке»
    /form[1]/tabpagelist[1]/tabpage[1]/element[@classname='CardEditView']/text[4]
    

    CodedUI
    Ranorex
    По данному критерию предпочтительнее выглядит Ranorex, так как имеет более простую (легко осваиваемую) систему работы с контролами.

    2. Гибкая и настраиваемая система поиска контролов


    CodedUI
    В CodedUI по умолчанию не предусмотрена работа с XPath для поиска контролов, но можно подключить специальную библиотеку.

    Ranorex
    В Ranorex XPath выражения называются RanoreXPath. Если элемент не имеет уникального названия, то обратиться к нему можно в одно действие, зная XPath выражение для него (см. предыдущий пункт).

    CodedUI
    Ranorex
    Дополнительный балл в пользу Ranorex за поддержку XPath по умолчанию.

    3. Простая поддержка Data Driven Testing


    Data Driven Testing — это подход автоматизации тестирования, основанный на использовании тестовых наборов данных, расположенных в отдельном от исходного кода тестов хранилище.

    CodedUI
    При разработке CodedUI-тестов, для организации самой тестовой структуры и запуска теста используется фреймворк MSTest, который содержит функционал для создания Data Driven-тестов. Любой тест можно привязать к наборам данных из CSV-, XML-файла или выборки базы данных.

    Ranorex
    В Ranorex также есть возможность разрабатывать Data Driven-тесты, но исключая формат XML для данных. Видимо, разработчики Ranorex посчитали его достаточно сложным для тестировщика.

    CodedUI
    Ranorex
    По данному критерию перевес на стороне CodedUI, так как в наших продуктах формат XML очень распространён, и во многих случаях тестировщику удобней работать именно с ним.

    4. Возможность разработки фреймворков для тестирования


    Опыт автоматизации тестирования показывает, что в любом тестовом проекте рано или поздно выделяется некоторый базовый функционал, позволяющий сократить код тестов. Этот функционал затем перерастает в небольшой тестовый фреймворк. На этом этапе тесты уже можно конструировать из различных методов этого фреймворка.

    В перспективе, выбранный нами инструмент мы собираемся использовать в рамках такого фреймворка. Фреймворк инкапсулирует работу с CodedUI или Ranorex, необходимых для обращения к элементам управления пользовательского интерфейса, и предоставляет набор методов, которые можно ассоциировать с пользовательскими действиями, например, «Открыть карточку», «Заполнить форму». Любой UI-тест состоит из набора вызовов таких методов и проверок корректной обработки данных тестируемого приложения.

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

    CodedUI
    При использовании, CodedUI-тесты разрабатываются в Visual Studio на языке C#. Тесты можно расширять, дорабатывать, рефакторить до бесконечности традиционным способом, привлекать разработчиков.

    Ranorex
    Ranorex предоставляет свою IDE — Ranorex Studio, которая основана на SharpDevelop и потому имеет очень схожий с Visual Studio интерфейс и принцип работы. У Ranorex удобный инспектор элементов и возможность создавать тесты практически только кликами мышки. Кроме этого, есть возможность разрабатывать дополнительные програмные модули, которые затем будут использованы для создания более сложных тестовых сценариев.

    Однако, если модуль разрабатывает не тестировщик, а программист, или специалист по автоматизации (как в нашем случае), ему удобнее использовать Visual Studio, поскольку она имеет более приспособленную систему отладки, ReSharper и пр.

    CodedUI
    Ranorex
    Разработка фреймворка — это, в целом, не задача тестировщика, поэтому и инструмент нужен более подходящий для разработки. В целом, Ranorex Studio по этому показателю уступает CodedUI.

    5. Поддержка запуска тестов на CI-сервере


    Тестируемые приложения развёрнуты на сервере Continuous Integration (Build-сервере), в качестве которого выбран TeamCity. По командным соглашениям, все тесты коммитятся в репозиторий тестируемого продукта. Это позволяет нам использовать совместный код, одновременно обновлять и собирать код приложения и тестов на Build-сервере. Для GUI-тестов должна остаться та же схема работы.

    CodedUI
    TeamCity позволяет без труда подключить тесты, разработанные с использованием фреймворков MSTest, NUnit.

    Ranorex
    Ranorex, в свою очередь, умеет компилировать Test Suit’ы в исполняемый файл, который затем можно просто запустить как отдельную задачу сборки TeamCity.

    CodedUI
    Ranorex
    По данному критерию инструменты удобно использовать в равной степени.

    6. Генерация информативных отчетов по результату прогона


    CodedUI
    MSTest печатает результаты в формате TRX. Это XML-документ, однако невооружёным глазом его читать достаточно сложно, да и не нужно, так как TeamCity после прогона тестов предоставляет тот же отчёт в формате CSV.

    Ranorex
    IDE Ranorex предоставляет прекрасные отчёты с иллюстрациями и пояснениями. Однако, для этого тесты необходимо запускать из самой Ranorex Studio. Скомпилированные же тесты после прогона возвращают отчёт Ranorex XML, который затем можно сконвертировать в xUnit.

    CodedUI
    Ranorex
    Оба случая не дают окончательного желаемого вида тестового отчёта. Однако, у нас уже реализована утилита, которая умеет создавать тестовые прогоны в нашей системе тест-менджмента (TMS) и импортировать результаты пройденных автоматизированных тестов. Причём исходный формат отчёта может быть как xUnit, так и CSV. В TMS отчёт выглядет наглядно, человекопонятно и демонстрирует общую картину тестирования на текущий момент.

    7. Возможность интеграции тестов с тест-кейсами TMS


    Кроме импорта результатов тестирования в систему тест-менеджмента, мы импортируем и сами тест-кейсы.

    Как это происходит:

    Тестировщик разрабатывая автоматизированный тест пишет пошаговое описание непосредственно в коде тестового класса, используя специальные атрибуты. Также с помощью атрибутов указывает какому сьюту и секции пренадлежит данный кейс. Затем, при помощи специальной утилиты, импортирует все кейсы тестового проекта в соответствующий проект TMS. Импорт можно выполнять вручную или в рамках задачи сборки TeamCity. На вход этой утилите подаётся DLL-файл тестового проекта.

    Эту возможность нам хотелось бы использовать и при разработке GUI-тестов. А значит, нужна возможность подключения своих библиотек и редактирования тестов.

    CodedUI
    В Visual Studio есть возможность просмотреть и отредактировать код CodedUI-теста, даже если он записан с помощью встроенного рекордера. Это даёт возможность проставить нужные атрибуты для синхронизации с TMS. А тестовый проект по умолчанию собирается в DLL-библиотеку, которую затем можно использовать для импорта кейсов.

    Ranorex
    В Ranorex Studio тестовый проект собирается в exe-файл. То есть, при текущей реализации нашей утилиты нет возможности использовать его в качестве источника тест-кейсов.

    CodedUI
    Ranorex
    Таким образом, используя CodedUI, нам будет проще привязать нашу систему интеграции к новым тестам.

    8. Простота изучения и использования тестировщиками


    CodedUI
    1. После создания нескольких примеров на нашем тестовом приложении сразу выявились проблемы при записи встроенным рекордером действий, связанных с сознанием динамических контролов. При повторном запуске теста название контрола менялось и тест проваливался. Чтобы этого избежать и сделать тесты более универсальными, приходилось править код теста вручную.
    2. Разрабатывать тесты с использованием CodedUI можно только в среде Visual Studio. Но VS для НЕпрограммиста очень сложный и громоздкий инструмент.

    Ranorex
    Ranorex специально создан как среда тестировщика. С его помощью удобно создавать, запускать и просматривать результаты тестов. Кроме того, после разработки нами нескольких примеров для тестового приложения, проблем с поиском динамических элементов ни разу не возникало. Ranorex также успешно работал с приложениями на .NET WinForms, для которых CodedUI нам не удалось запустить.

    CodedUI
    Ranorex
    Ranorex имеет более дружелюбный для тестировщика интерфейс и систему работы с элементами.

    Вывод


    В качестве вывода приведу сводную таблицу по описанным выше критериям:
    возможность реализована
    возможность не реализована
    возможность реализована и удобна в использовании
    Критерий CodedUI Ranorex
    Поддержка динамически генерируемых контролов
    Настраиваемая система поиска контролов
    Простая поддержка Data Driven Testing
    Возможность разрабатывать свои модули
    Поддержка запуска тестов в TeamCity
    Генерация информативных отчетов по результату прогона тестов
    Возможность интеграции тестов с тест-кейсами TMS
    Простота изучения и использования тестировщиками

    По выбранным нами критериям сравнения Ranorex был оценён выше, главным образом за счёт удобства.

    В процессе анализа мы привлекали тестировщиков к разработке небольших тестовых сценариев и работать с Ranorex им показалась значительно удобней и наглядней.
    Если вы тестировщик и вам необходимо тестировать Windows-приложение с нуля и вы выбираете между покупкой лицензии на использовании Visual Studio с поддержкой CodedUI или Ranorex, то выбрать Ranorex было бы логичнее.

    Что же касается наших проектов.
    Приступая к тестированию проекта, мы условно разбиваем продукт на независимые части, которые можно тестировать по отдельности. Например, приложение имеет интерфейс, который обрабатывает данные БД через API, сервисы интеграции синхронизируют данные с другими продуктами, а хранимые процедуры на уровне БД отрабатывают по расписанию и расчитывают значения некоторых полей. И для каждой такой части разрабатывается свой набор тестов как отдельное приложение (тестовый проект = тестовый фреймворк, адаптированный под нужды тестирования продукта + множество тестов, объединённые в тестовые наборы). Все тестовые проекты являются частью решения всего тестируемого продукта.
    В эту структуру нам необходимо было добавить тестирование GUI.

    Так как у Ranorex и CodedUI по критичным для нас параметрам оценки не сильно различались, мы подумали о перспективе развития тестов.

    В конечном счёте выбор стоял между инструментом, в котором тестировщики отдельно от продукта и разработчиков будут писать GUI-тесты, и временем, потраченным на разработку всего необходимого (фреймворка, документации) для быстрой и удобной разработки тестов с использованием CodedUI.

    Поскольку во втором случае такую систему можно сделать более универсальной, мы выбрали CodedUI. Да, это больше часов разработки, но при этом у нас появлялось некоторое универсальное решение для автоматизации функционального тестирования GUI всех Enterprise-продуктов компании.
    • +29
    • 19.5k
    • 6
    2ГИС
    146.16
    Карта города и справочник предприятий
    Share post

    Comments 6

      +3
      Если честно, то статью писал явно человек, который не разобрался с Ranorex.
      Поддержка динамически генерируемых контролов

      Если писать доступ к элементам руками, а не через UIMap (свой page object), то можно сесть в гигантскую лужу, ибо нужно описывать полную иерархию контролов. Например обратится к контекстному меню по имени и классу нельзя, нужно сначала описать верхнее окно. В ranorex нет такой проблемы, так как поиск идёт в более «умно».
      Настраиваемая система поиска контролов

      Если честно, то xpath реализованный в ranorex настолько удобный и полный, что работа с ним ни чем не отличается от работы с selenium. Это даёт большой простор для написания своего page object и динамического поиска объектов, см вверх.
      Простая поддержка Data Driven Testing

      Вот тут я вообще не понимаю. Что мешает обернуть ranorex в mstest или даже в codedui? Ядро ranorex — это ranorex library. Ranorex library — это набор DLL, которые легко подключаются к тестовому проекту. Опять же говорю о том что тут работа с ranorex вообще ни чем не отличается от работы с Selenium.
      Возможность разработки фреймворков для тестирования

      И так, ranorex — это набор DLL. Контролы ищутся через xpath. Всё прекрасно работает внутри MSTest/NUnit/CodedUI. Тесты пишутся на С# в студии. Что ещё нужно для построение красивого и удобного тестового фреймворка?
      Поддержка запуска тестов на CI-сервере

      Так как тесты легко оборачиваются в MSTest, то их можно запускать на любом CI сервере.
      Генерация информативных отчетов по результату прогона

      Красиво и информативно оформить выхлоп тестов можно всегда и везде, главное желание.
      Возможность интеграции тестов с тест-кейсами TMS

      Выкидываем Ranorex Studio + пишем через нормальный тестовый юнит-тест провайдер = возможная интеграция куда угодно.
      Простота изучения и использования тестировщиками

      Хороший тестовый фреймворк можно построить и там и там. Но из коробки конечно ranorex лучше.

      Странно видеть такое не профессиональное сравнение в блоге такой компании. У себя в отделе мы используем связку Ranorex+SpecFlow+CodedUI. Тесты легко пишутся, легко поддерживаются, видны в MTM, нативно запускаются через Team Build. В прошлом году я читал доклад как мы выбирали Ranorex qa.optsconf.ru/schedule
        +2
        Вы совершенно правы, особенно что касается
        «Хороший тестовый фреймворк можно построить и там и там. Но из коробки конечно ranorex лучше.»

        Более того, даже автор статьи с вами согласен
        «По выбранным нами критериям сравнения Ranorex был оценён выше, главным образом за счёт удобства.»

        Выбор CodedUI был сделан только в аспекте конкеретных проектов
        «Что же касается наших проектов.»
        «В конечном счёте выбор стоял между инструментом, в котором тестировщики отдельно от продукта и разработчиков будут писать GUI-тесты, и временем, потраченным на разработку всего необходимого (фреймворка, документации) для быстрой и удобной разработки тестов с использованием CodedUI.»

        Вы же предлагаете купить еще один продукт, выкинуть почти все из него. Зачем, если легче добавить удобство локаторов в готовую инфраструктуру (ведь именно этот подход, основы на инфраструктуре диктует Microsoft?)
        «Выкидываем Ranorex Studio + пишем через нормальный тестовый юнит-тест провайдер = возможная интеграция куда угодно.»

        К слову, легкость написания и поддержки тестов в selenium при помощи xpath для меня крайне сомнительна. И минусов там куча, начиная от скорости работы в IE, до поддержки постоянной смены интерфейса. Но это вероятно оффтоп.
        «Если честно, то xpath реализованный в ranorex настолько удобный и полный, что работа с ним ни чем не отличается от работы с selenium.»
          0
          Выбор CodedUI был сделан только в аспекте конкеретных проектов

          В тестировании через UI это вообще главное. Особенно в десктопе. Контролы могут просто не определяться. Так что если были выбраны два инструмента, то они оба имеют достаточную поддержку технологий конкретных проектов и дальше идёт уже удобство и всё остальное.
          Вы же предлагаете купить еще один продукт, выкинуть почти все из него. Зачем, если легче добавить удобство локаторов в готовую инфраструктуру (ведь именно этот подход, основы на инфраструктуре диктует Microsoft?)

          У ranorex есть разные редакции. Для себя мы покупаем только Ranorex Runtime на CI. Разрабатываем мы тесты локально, а запускаем на виртуальных машинах. Так проще контролировать среду исполнения и не надо ждать завершения тестов.
          К слову, легкость написания и поддержки тестов в selenium при помощи xpath для меня крайне сомнительна. И минусов там куча, начиная от скорости работы в IE, до поддержки постоянной смены интерфейса. Но это вероятно оффтоп.

          Вы писали локаторы на чистом механизме CodedUI? Уверяю вас что xpath по сравнению с ним просто сказка в поддержке. А деструктивные эффекты от смены интерфейса помогают преодолеть page object + Cucumber/SpecFlow.
        +2
        А деструктивные эффекты от смены интерфейса помогают преодолеть page object + Cucumber/SpecFlow.

        или механизмы автогенерация локаторов при сборке продукта.
          0
          Александр, а можно подробней про эти механизмы автогенерации локаторов?
          Что для этого нужно от тестировщика/разработчика для реализации подхода?
            0
            Это вообще идеал Саш :) Но тут очень много необходимых предусловий к сожалению.

          Only users with full accounts can post comments. Log in, please.