Пользовательский интерфейс модульного тестирования. Какой эффективный способ?

Question

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

Для сложных правил проверки я имею в виду:

• «Отключить кнопку X, если я вставлю значение в текстовое поле Y»
• «Включить комбинированный список, если я вставляю значение в текстовое поле» ...... ......

Наиболее многообещающий образец, который я нашел, предложен М. Фаулером (http://martinfowler.com/eaaDev/ModelViewPresenter.html).

Есть ли у вас опыт модульного тестирования пользовательского интерфейса? В качестве технологического стека я использую: .NET 3.5 и библиотеку виджетов Windows Forms.

Answer 1

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

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

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

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

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

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

Answer 2

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

Тестирование контроллеров и логики с использованием разделения MVC / MVP, предложенного Мартином Фаулером, является отличным началом, но вам часто нужно дополнять его средствами автоматизации, такими как WinRunner или QTP, чтобы полностью протестировать пользовательский интерфейс в автоматическом режиме.

Answer 3

Для сложных правил проверки я имею в виду:

* "Disable button X if I Insert a value in textfield Y"

Эти правила проверяют и Model, и View, и это делает их жесткими. Вместо этого проверьте, что при вставке значения в текстовое поле Y модель получает это значение; что модель с пустым Y имеет X_ENABLED == false, а с непустым Y имеет X_ENABLED == true; и что, учитывая модель с X_ENABLED == true, кнопка просмотра включена. Только два из этих тестов связаны с пользовательским интерфейсом, и они должны быть настолько простыми, что в значительной степени не могут потерпеть неудачу. Поместите сложную логику в модель, где она легко проверяется.

Answer 4

По определению юнит-тестирование не очень хорошо для тестирования интерфейса. Модульное тестирование должно проверять внутреннюю функциональность одного объекта. Для функционального тестирования, получите основу для этого. Рассмотрим такие вещи, как Mercury (сейчас HP) Quality Center или Performance Center. Если у вас ограниченный бюджет, попробуйте Selenium.

Функциональные тесты являются шагом по сравнению с модульными тестами, и их не следует путать с другими.

Answer 5

Неудобное тестирование пользовательского интерфейса - это, как уже говорили, боль. Я просто хотел бы добавить, что новая функция Team Foundation 2010 Test & Lab Manager является отличным способом как ручного тестирования пользовательского интерфейса, так и автоматизации последующих тестов . Он достаточно умен, чтобы распознавать структуры GUI при запуске тестов, по крайней мере для WinForms, WPF и веб-сайтов.