Библиотека Microsoft UI Automation Vs Coded UI Test

Я очень много нового в Testing или Test Automation. Недавно я был назначен проекту для автоматизации тестирования пользовательского интерфейса приложения WPF. После небольшого поиска в MSDN и других я немного смущен тем, должен ли я использовать библиотеку автоматизации Microsoft UI или новую функцию тестирования кодированного пользовательского интерфейса VS 2010. Я не получаю четкое представление о том, какое из них применяется в каких сценариях, какие преимущества есть у другого и какой из них подходит для меня (еще раз у меня есть CAD, например приложение WPF, которое пропускает много AutomationIds, и я должен автоматизировать его тестирование ui). ПОЖАЛУЙСТА, ПОМОГИТЕ!!!

Ответ 1

В основном Microsoft UIA - это новая библиотека доступности в .NET 4.0. Приложения WPF и средства управления имеют встроенную поддержку МАУ через класс AutomationPeer.

Coded-UI test - инструмент автоматизации записи и воспроизведения, в котором используется библиотека Microsoft UIA. Поскольку это инструмент по сравнению с написанием кода на С#, он повышает производительность QA для записи большего количества тестовых случаев.

Для приложений с поддержкой автоматизации, запланированных в нее, Coded-Ui должен быть достаточным. Если отсутствуют идентификаторы AutomationID, убедитесь, что элементы управления имеют уникальное свойство, например Name. Используйте UIVerify или Inspect для проверки этого.

Если NO уникальное свойство avialble, есть другие ниже упомянутые методы, которые вы можете использовать в сочетании с Coded-UI.

Из мероприятия Когда ваше приложение получает событие автоматизации UI, исходный объект, переданный вашему обработчику событий, является элементом AutomationElement. Например, если вы подписались на события с измененной фокусировкой, источник, переданный вашему AutomationFocusChangedEventHandler, является элементом, который получил фокус. Дополнительные сведения см. В разделе Подписка на события автоматизации пользовательского интерфейса.
От точки: Если у вас есть координаты экрана (например, позиция курсора), вы можете получить AutomationElement с помощью статического метода FromPoint.
Из оконной ручки: Чтобы извлечь элемент AutomationElement из HWND, используйте статический метод FromHandle.
От Focused Control: Вы можете получить элемент AutomationElement, который представляет сфокусированное управление из статического свойства FocusedElement.

Ответ 2

Если вы можете использовать и использовать Кодированный тест пользовательского интерфейса, перейдите по этому маршруту. Убедитесь, что ваша конфигурация

Ответ 3

Библиотека автоматизации пользовательского интерфейса - это низкоуровневая библиотека. Обычно вы не хотите писать тесты против него напрямую, поскольку для этого требуется довольно приличный объем работы.

Я бы рекомендовал посмотреть на более высокоуровневые библиотеки. Вы упомянули одного из них - кодированный пользовательский интерфейс; другим хорошим выбором будет White от TestStack. Они оба подходят для разных проектов. Кодированный пользовательский интерфейс хорош, если вы не хотите вкладывать много усилий в свой тестовый пакет. В то же время, это не так сильно масштабируется, поэтому, если вы собираетесь писать много тестов, вам лучше выбрать White.

Здесь я более подробно разбираю две структуры: Кодированный пользовательский интерфейс против белого

Ответ 4

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

Я начал "полу-фреймворк" с помощью библиотеки CodedUITest и разработал парадигму для разделения деталей автоматизации на код (С#). В принципе, я создаю драйвер, который читает, что нужно делать из таблицы (таблиц), где каждая строка в ней является тестовым этапом (или указателем на сценарий в другом листе). В настоящее время, неполный, но многообещающий, я работаю против приложения WPF с частичным успехом. Одной из основных проблем является то, что разработчики пренебрегли однозначным и последовательным определением элементов управления.

Bey