Опыт работы с UI Automation и WPF

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

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

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

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


wpf ui-automation
person soren.enemaerke    schedule 13.03.2009    source источник
comment
Этот вопрос не следует закрывать, поскольку ответы содержат информацию, основанную на реальном опыте работы с технологиями. Поскольку автоматизация тестирования сейчас является довольно горячей темой, держу пари, эта информация ценна для многих людей.   -  person Ondrej Sotolar    schedule 31.10.2014

Ответы (3)


arrow_upward
7
arrow_downward

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

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

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

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

person Bijington    schedule 18.03.2009
comment
TestComplete — это инструмент «нажми и работай», а TestStack.White — это фреймворк C#. Это совершенно разные решения: первое ориентировано на тестировщиков, второе — на программистов. - person Ondrej Sotolar; 31.10.2014

arrow_upward
6
arrow_downward

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

person Nat Ritmeyer    schedule 17.02.2010
comment
Очень хорошая запись, Нат. Большой палец вверх от меня - person soren.enemaerke; 18.02.2010
comment
Борьба с Уайтом стала слишком мучительной, поэтому я написал bewildr (github.com/natritmeyer/bewildr) . Он используется на BBC и отлично работает! - person Nat Ritmeyer; 13.06.2012

arrow_upward
2
arrow_downward

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

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

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

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

person Orion Edwards    schedule 08.06.2010
comment
Эдвардс, почему вы не попробовали Microsoft.VisualStudio.TestTools.UITesting API (тот, который используется в кодированном тесте пользовательского интерфейса за кулисами)? Я спрашиваю, потому что я только что перешел на этот из МАУ. - person atiyar; 11.04.2011
comment
@Nero: три причины. Во-первых, его не было до выпуска Visual Studio 2010. Во-вторых, вам нужно приобрести Премиум-версию VS вместо Стандартной, что является ОГРОМНЫМ скачком в цене, особенно здесь, в Новой Зеландии. В-третьих, я посмотрел на тестовые материалы пользовательского интерфейса, написанные Visual Studio, и мне это совсем не понравилось. Он был слишком сложным, непростым в использовании и трудным для отладки. Сам базовый код API может быть лучше, чем то, что генерирует Visual Studio, но я не смотрел на это в то время, так как не понимал, что вы можете использовать его независимо. - person Orion Edwards; 29.04.2011