Опыт работы с автоматизацией пользовательского интерфейса и WPF

Мы разрабатываем довольно большое приложение на основе WPF и хотели бы включить в наш тестовый набор некоторые автоматизированные тесты пользовательского интерфейса (в котором уже содержится ряд модульных тестов).

UI Automation Framework от Microsoft частично звучит как идеальная подгонка для программного запуска и взаимодействия с приложением в тестовая установка. Тем не менее, я изо всех сил пытался найти солидные ссылки на образцы и опыт с технологией, статьи и небольшие образцы, доступные на MSDN, недостаточно, чтобы убедить меня, что это солидный выбор.

Итак, есть ли у кого-нибудь опыт реального мира с использованием UI Automation Framework в их наборе тестов? Каковы оговорки и ошибки? Любые лучшие практики при написании сценариев тестов, вы можете "записывать и воспроизводить" в формат сценариев, насколько вы должны облегчить тестирование из приложения, как вы его включили в автоматическую сборку? Должны ли мы искать в другом направлении, чем UI Automation Framework?

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

Ответ 1

Где я работаю, мы только начали оценивать некоторые тестовые инструменты для нашей системы. Мы столкнулись с инструментом white, который использует UI Automation Framework. Обратите внимание, что белый также имеет функцию записи, хотя я думаю, что он имеет проблемы и все еще разрабатывается.

Мы пытались сделать так, чтобы они выглядели как модульные тесты, т.е. [TestFixture] [Test] и т.д. то мы смогли запустить их через nunit одновременно с тестированием модуля.

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

Если вы не против платить за программное обеспечение, я бы рекомендовал TestComplete.

Ответ 2

Я нахожусь в середине выполнения UI Automation приложения WPF на работе. Я использую White и IronRuby, и он отлично работает. Я написал, как я это сделал здесь: http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/

Ответ 3

Мы сначала пошли с белым, а затем отошли от него. Он пытается быть обобщенным и абстрактным по API Win32, Winforms, Java-приложениям и API автоматизации пользовательского интерфейса MS. API автоматизации пользовательского интерфейса MS также пытается быть обобщенным и абстрактным над win32 api и winforms и WPF, поэтому вы попадаете в сценарий с наименьшим общим знаменателем-наименьшим общим знаменателем.

Результатом этого было то, что API-интерфейс поиска белых элементов просто не был достаточно гибким, чтобы найти различные элементы пользовательского интерфейса, которые нам нужно было найти, и он не выявил достаточного количества базовых элементов для автоматизации пользовательского интерфейса для нас, чтобы что-либо сделать Полезно с этим.

Мы закончили тем, что перешли на домашнюю страницу; Мы напрямую используем структуру MS UIAutomation, но у вас есть методы расширения и вспомогательные классы для обработки сценариев, которые он не адресует. (Ввод клавиатуры и мыши, в первую очередь).

Примечание: наши тестовые скрипты и встроенные фреймворки используют IronRuby. Возможность Ruby добавлять методы к существующим классам и гибкий синтаксис (в сочетании с методом method_missing) являются удивительными для такого рода вещей.