Шаблоны автоматизации пользовательского интерфейса и лучшие практики для настольных приложений

Фон

В настоящее время я автоматизирую некоторые тесты для плагина для MS Office. Мы создаем тесты Coded UI в VS 2010. Я полагаю, я мог бы использовать инструмент « Построитель тестов Coded UI », но он не очень подходит для моего конкретного случая.

Из-за этого я создал свой собственный класс UI Map и методы расширения для каждого элемента управления / карты UI, где я добавляю различные функциональные возможности действий. Например, нажмите кнопки или подтвердите некоторые значения пользовательского интерфейса.

Сценарии тестовых случаев в тестовых классах.

Я новичок в этой области, а также я новичок в тестировании автоматизации.

Вопрос

Будут ли люди любезны поделиться своим опытом и советами по передовым методам автоматизации тестирования настольных приложений с точки зрения программирования / проектирования?

Лучшая практика для UI Automation Testing - делать как можно меньше. Пользовательский интерфейс часто меняется, что означает, что вам постоянно приходится обновлять свою автоматизацию. Обычно желательно структурировать код продукта таким образом, чтобы можно было автоматизировать тестирование без автоматизации пользовательского интерфейса.

Тем не менее, вы не всегда можете избавиться от автоматизации пользовательского интерфейса. Вы упомянули офис, поэтому я предполагаю, что вы пишете для Windows и используете .Net. Я делаю совсем немного в моей нынешней работе. Вот некоторые из вещей, которые я узнал.

1) Посмотрите на библиотеки UIAutomation, которые были представлены в .Net 3.0. Они предоставляют обширную и довольно простую в использовании библиотеку для автоматизации. (Http://msdn.microsoft.com/en-us/library/ms753107.aspx)

2) Загрузите UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)

3) Сделайте интерфейсы вашего продукта автоматизируемыми.

3a) Если это WPF, поместите AutomationID на все.

3b) Попытайтесь создать отличительные имена элементов управления и окон (имена классов пользовательского интерфейса, а не имя класса исходного кода). Если вы не знаете, что я имею в виду, загрузите UI Spy и начните смотреть на окна. Обратите внимание, сколько окон в разных приложениях имеют имя класса # 32770. Это имя класса для диалогового окна Windows. Любое окно, которое расширяет диалог и не устанавливает свое собственное имя, по умолчанию это. Это вызывает все виды горя с точки зрения автоматизации пользовательского интерфейса.

4) Избегайте выражений Thread.Sleep (). Попробуйте использовать официанты (см. Документацию UIAutomation).

5) НИКОГДА не смешивайте тестовый код с кодом автоматизации пользовательского интерфейса. Создайте отдельные библиотеки для автоматизации пользовательского интерфейса. Назовите эти библиотеки из ваших тестов. При изменении пользовательского интерфейса это значительно упростит обновление автоматизации.

6) Всегда регистрируйте слушателя для события пользовательского интерфейса перед выполнением действия, которое вызовет событие. На практике это означает, что вы будете работать с потоками.

6a) Пример: не начинайте ждать события открытия окна после нажатия кнопки, чтобы открыть окно. Окно может открыться до регистрации официанта и никогда не получить событие.

7) Никогда не думайте, что открывшееся окно - это то, что вам нужно. Все виды окна могут неожиданно открыться в Windows.

Я мог бы продолжать дальше, но это становится немного длиннее.

Создавайте функциональные тесты из повторно используемых вариантов использования

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

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

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

Это означает, что у вас есть какой-то комплексный функциональный тест, содержащий список вариантов использования. Эти варианты использования содержат методы тестовой структуры, которые вызывают поведение приложения (нажмите кнопку X) и проверяют поведение (экран становится синим).

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

Если вам интересно читать дальше, я писал об этом подходе в другом месте, но статья предназначена для веб-приложений на Java (с использованием Maven и SeleniumRC), а не для настольных приложений, которые вы запросили.