Автор статьи — Татьяна Курносова, но она поехала покорять горы Киргизии. Поэтому честь опубликовать этот пост выпала мне.
В компании 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 — это полноценная среда разработки, а также набор инструментов и библиотек для написания тестов.
Далее нам предстояло сделать выбор в пользу одного из этих продуктов.
Критерии сравнения
Мы сформулировали основные критерии, по которым сравнивали пакеты:
- Поддержка динамически генерируемых графических элементов управления (контролов)
- Настраиваемая система поиска контролов
- Простая поддержка тестов, основанных на данных (Data Driven Testing)
- Возможность разрабатывать свои модули (фреймворки) и использовать их при разработке тестов на C#
- Поддержка запуска тестов на сервере Continuous Integration (TeamCity)
- Генерация информативных отчетов по результату прогона тестов
- Возможность интеграции тестов с тест-кейсами системы тест-менджмента (TMS)
- Простота изучения и использования тестировщиками
Тестовый макет
Для сравнения возможностей было разработано тестовое приложение с 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-продуктов компании.
Автор: jetfreeman
