Пользовательский интерфейс Поблочного тестирования. Что такое эффективный путь?
У меня есть приложение клиента/сервера учета и платежной ведомости, где существует несколько входных форм со сложными правилами подтверждения правильности данных. Я нахожу эффективный способ выполнить поблочное тестирование пользовательского интерфейса.
Поскольку сложная проверка постановляет, что я имею в виду:
- "Кнопка X Disable, если я Вставляю значение в текстовое поле Y"
- "Включите поле комбинированного списка, если я вставляю значение в текстовое поле"............
Самый многообещающий шаблон, который я нашел, предлагается M. Fowler (http://martinfowler.com/eaaDev/ModelViewPresenter.html).
У Вас есть опыт о Поблочном тестировании Пользовательского интерфейса? Как технологический стек я использую:.NET 3.5 и Библиотека Виджета Windows Forms.
5 ответов
Я бы не назвал это «модульным тестированием» в точности, но я добился определенного успеха в запуске автоматических тестов для пользовательского интерфейса WinForms, а также в веб-интерфейсе с использованием WatiN.
Предполагая, что вы можете получить дескриптор окна приложения, которое хотите протестировать, у вас должна быть возможность написать много кода C # для тестирования функциональности пользовательского интерфейса.
Многие люди осуждают идею попытаться запустить автоматические тесты для пользовательского интерфейса, потому что есть так много всего, что вы не можете протестировать таким образом. Например, ни один автоматический тест не заметит, что шрифт некрасивый, или какой-то текст сбивает с толку, или кнопка немного смещена по центру. Нет никаких сомнений в том, что для таких вещей вам определенно нужен умный человек, смотрящий в экран.
Однако, помимо этого типа тестирования, определенно существует большой набор повторяющихся тестов, которые можно автоматизировать и выполнять регулярно. В большинстве крупных приложений есть целый набор сценариев регрессионного тестирования, которые необходимо выполнять вручную, когда выходит новый выпуск. Эти тесты обычно представляют собой то, чему вы можете научить обезьяну, просто список инструкций, как щелкнуть эту ссылку, ввести текст, щелкнуть эту кнопку, проверить полученное сообщение и т. Д. Эти вещи - ужасная трата времени вашего тестировщика качества, и делает их несчастными, так что если их можно автоматизировать - отлично. Эти типы тестов должны иметь возможность автоматически запускаться вашим сервером сборки каждый день, и их можно сделать гораздо более тщательными, чем любое ручное тестирование.
Опять же, он не обнаружит странных и неожиданных вещей, но даст вам определенную уверенность в том, что ваше небольшое изменение не сломало какой-то другой экран, о котором вы никогда не слышали, на другой стороне приложения.
Конечно, это приводит к увеличению продолжительности работы разработчиков, потому что небольшие изменения в приложении могут нарушить тесты по глупым причинам, как и любое автоматическое тестирование, но это должно сэкономить вам массу времени при тестировании и отладке. Вам решать, стоит ли это того для вас, но я думаю, что это соображение не следует отбрасывать так быстро, как вы обычно видите.
Тестирование пользовательского интерфейса сложное и, как правило, лучше всего проводить на более высоком уровне тестирования, чем модульное тестирование.
Тестирование контроллеров и логики с использованием разделения MVC / MVP, предложенного Мартином Фаулером, является отличным началом, но вам часто нужно дополнить его инструментами автоматизации, такими как WinRunner или QTP, чтобы полностью протестировать пользовательский интерфейс в автоматическом режиме.
Для сложных правил проверки я имею в виду:
* «Отключить кнопку X, если я вставляю значение в текстовом поле Y "
Эти правила проверяют и модель, и представление, и это делает их трудными. Вместо этого проверьте, что когда вы вставляете значение в текстовое поле Y, модель получает это значение; что модель с пустым Y имеет X_ENABLED == false, а с непустым Y имеет X_ENABLED == true; и что, учитывая модель с X_ENABLED == true, кнопка просмотра активна. Только два из этих тестов связаны с пользовательским интерфейсом, и они должны быть настолько простыми, чтобы практически не потерпеть неудачу. Поместите сложную логику в модель, где ее легко протестировать.
Untit testing пользовательский интерфейс - это, как говорили другие, боль. Я просто хотел бы добавить, что новая функция Team Foundation 2010 Test & Lab Manager - отличный способ как выполнять ручное тестирование пользовательского интерфейса, так и автоматизировать последующие тесты. Достаточно умен, чтобы распознавать структуры графического интерфейса пользователя при запуске тестов, по крайней мере, для WinForms, WPF и веб-сайтов.
Юнит-тестирование не так хорошо для тестирования интерфейса, по определению. Юнит-тестирование должно проверять внутреннюю функциональность отдельной сущности. Для функционального тестирования приобретите фреймворк для этого. Рассмотрите такие вещи, как Mercury (теперь HP) Quality Center или Performance Center. Если у вас ограниченный бюджет, попробуйте Selenium.
Функциональные тесты - это шаг вперед по сравнению с модульными тестами, и их не следует путать друг с другом.