Тестирование приложения WPI для Gui-heavy

Ответ 1

ОК, ваше приложение звучит просто! Я могу поделиться своим опытом вокруг приложения, которое мы разработали недавно; это был GUI-говорящий веб-сервис для сервера, который, в свою очередь, связался с несколькими базами данных и другими веб-службами. Клиентская база составляла около 15 000 пользователей... В любом случае - это много работы независимо от того, как вы к ней подходите; это поможет вам не разжевывать ваши гвозди при каждом выпуске!

MVVM

В общем, я бы также рекомендовал шаблон MVVM и сделать как можно больше тестов без GUI. Тестирование GUI просто сложно! Мне нравится статья Джоша Смита о MSDN: " Приложения WPF с шаблоном проектирования Model-View-ViewModel" (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx)

Тестирование сценариев

Трюк с этим приложением состоял в том, что мы много тестировали, все кишки постоянно двигались, и было (как ни странно) недостаточно людей, чтобы выполнить тестовую работу для каждой итерации.

Мое решение состояло в том, чтобы придумать специальный инструмент тестирования, который использовал существующие библиотеки. У нас был простой движок script, который читал файл и выполнял команды. Фактически мы разработали DSL ( http://en.wikipedia.org/wiki/Domain-specific_language) для тестирование нашего конкретного приложения. DSL включал некоторые простые команды, чтобы сигнализировать, какое "окно" оно тестировало, какие-либо конкретные "установочные" сигналы, а затем ряд команд, за которыми следуют утверждения. Это выглядело примерно так:

Test NewXyzItem
Setup Clear_items

Press Some_button
Enter_text_into Name Bobby Joe
(...)
Press Save

Assert_db_has_itemX SomeKey

Формат каждой строки

"command" "argument" [data]

Скрипты входят в группы каталогов, а "тестовый бегун" загружает их, анализирует их и выполняет. Создание журналов и отчетов по ходу работы полезно, я получил добавление в крючок для создания скриншотов и т.д., Которые вам пригодились. Если вы заинтересованы в том, чтобы реализовать что-то подобное, и хотите, чтобы рука сообщила мне.

Полезная вещь здесь заключалась в том, что мы могли бы внести общие изменения в стратегию тестирования.

Написание скриптов становится довольно простым, что важно, потому что в итоге вы получаете множество сценариев. Элементы управления обнаруживаются по имени, поэтому вы следуете соглашению (например, "Имя" может быть "NameTextBox" в коде, или "Сохранить" может быть "SaveButton" ).

Фактически вы можете использовать NUnit и т.д.

ПРИМЕЧАНИЕ. Просто запускайте тесты в интерактивном режиме, чтобы проверить, что GUI-тест для работы с CI затруднен и проблематичен...

Данные и тестирование

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

Библиотеки

Библиотека, которую вы можете найти наиболее полезной в White "( http://white.codeplex.com/) Он может тестировать приложения Windows в целом - то есть как WPF, так и WinForms. По сути, вы в конечном итоге кодируете такие вещи:

Button button = window.Get<Button>("SaveButton");
button.Click();

Если ваше приложение делает асинхронные вызовы, вам нужно будет разработать стратегию для тестировщика, чтобы узнать, когда асинхронный вызов завершен, возможно, в строке состояния или что-то в этом роде. Это зависит от того, как вы подключаетесь...

Опять же, много работы, но ее стоит.

PK: -)

Ответ 2

Одна из основных сильных сторон WPF - это на самом деле способность НЕ нуждаться в тестировании пользовательского интерфейса, на мой взгляд. Использование подхода M-V-VM позволило бы вывести логику из области пользовательского интерфейса /messy -GUI. Имея единый тестируемый ViewModel (особенно, если вы пишете новые диалоги!), Вы можете писать модульные тесты, которые эмулируют щелчок вашего графического интерфейса.

Я бы действительно пересмотрел, чего вы хотите достичь, перейдя в WPF и чего вы хотите достичь с помощью некоторого типа автоматизированного тестирования графического интерфейса WPF. Как только это будет установлено, перейдите в переход от WinForms к WPF, если он по-прежнему подходит вашим потребностям.

Ответ 3

Как говорит Джимми Лийк, большая часть вашего тестирования должна быть сосредоточена на ViewModel. Это состоит из написания модульных тестов для ViewModel - в основном отправки команд и настройки и получения свойств.

Как только это будет сделано, 95% вашего тестирования будет в стороне. Если вы хотите сделать еще один шаг и протестировать представление, выходящее за рамки рутинных проверок, которые вы бы сделали, в любом случае существует ряд простых "проверок здравомыслия", которые вы можете легко автоматизировать, чтобы убедиться, что вы случайно не удалили важный TextBox или визуализировать невидимый индикатор.

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

• Чтобы убедиться, что все данные ViewModel связаны, найдите все Визуальные и Freezables (используя визуальное дерево) и проверьте каждое свойство привязки для его пути привязки BindingExpression.

• Чтобы убедиться, что все данные ViewModel отображаются каким-то образом, измените данные ViewModel с помощью script и после каждого изменения использует RenderTargetBitmap для захвата пользовательского интерфейса и сравнения его с ним перед изменением данных, чтобы убедиться, что пользовательский интерфейс изменилось.

• Чтобы убедиться, что значения свойств обновлены правильно, найдите все Визуальные и Freezables, и сканирует и записывает все связанные свойства на них, затем сделайте изменение, повторное сканирование и поиск в ViewModel для ожидаемого изменения для любого свойства данного типа. (Чтобы дважды проверить, вы можете использовать метод сравнения битмапов для конкретного затронутого Visual.)

• Чтобы убедиться, что все команды доступны, установите известное состояние ViewModel, затем запустите каждую команду, привязанную к кнопке, которая видна, чтобы увидеть, вызывает ли какой-либо из них ICommand или иным образом обновляет состояние ViewModel.

  /li >

• Чтобы убедиться, что свойство ViewModel на самом деле доступно для редактирования пользователем, измените содержимое или выбор каждого видимого TextBox, ComboBox, ListBox, чтобы увидеть, влияет ли какое-либо из них на свойство.

• Чтобы получить возможность проверить любые изменения, которые влияют на пользовательский интерфейс, храните базу данных, содержащую растровые снимки каждого вида в разных состояниях ViewModel, в разных размерах окон. Когда будет создана новая версия приложения, запустите ту же систему снимков и сравните ее с предыдущими растровыми изображениями. Если что-либо вообще изменилось, создайте ручную задачу для персонала QA, чтобы визуально сравнить старые и новые растровые изображения, чтобы увидеть, изменилось ли что-либо важное.

В представлении возможна другая автоматизация тестирования, но приведенное выше даст вам начало.

Снова я должен указать, что лучше всего сосредоточиться на тщательном тестировании ViewModel. Ошибки в самом представлении довольно редки, обычно обнаруживаются быстро и обычно тривиальны для исправления. Но как только тестирование ViewModel будет тщательным, имеет смысл сделать некоторую автоматизацию тестирования представлений.

Ответ 4

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

У вас здесь не так много вариантов, но:

• Рефакторинг кода по мере продвижения. Это может быть небольшое извлечение метода, поэтому вы можете unit test или перейти к соответствующей модели.
• Используйте один или несколько вариантов инструменты для тестирования Windows GUI. Обратите внимание: если вы планируете много макетов и/или контрольных изменений, задержите это как можно дольше. Инструменты в этой статье будут использовать абсолютное позиционирование действий, связанное управление (иногда с помощью внутренних идентификаторов) или смесь обоих. Поскольку их обычно нужно обучать без использования кода (ориентированного на тестировщиков QC, а не на программистов), ваши тесты прекратятся после изменения.
• Инвестируйте в человеческие тестеры. Несмотря на то, что это не очень хороший выбор, он улучшает качество конечного результата и начинает привлекать внимание руководства к стоимости рефакторинга приложения.

Ответ 5

Для тестирования приложений WPF есть несколько вещей, с которыми мы успешно справились:

• PowerShell
• TestPlant

и, возможно, будет новым функциями VSTS 2010, хотя мы не пробовали их