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

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

Спасибо, Джефф

Ответ 1

У вас есть (по крайней мере) 2 проблемы - сложность среды (сервера) и сложность GUI.

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

С другой стороны, среда - это область, которую можно приручить. Если ваше приложение архивировано с использованием метода Injection/Inversion Dependency Injection/Inversion (где вы добавляете "серверный компонент в приложение" ), вы можете использовать "макет" соответствующих серверных интерфейсов, чтобы вы могли использовать script тестовые примеры.

Объединение этих двух методов позволит вам автоматизировать тестирование графического интерфейса.

Последняя мысль - удачи!

Ответ 2

Другие инструменты для тестирования GUI, которые я могу предложить, это: Thoughtworks White, PyWinAuto, AutoIt, AutoHotKey.

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

Ответ 3

В зависимости от того, где вы находитесь в спектре MVC (что является чрезмерным термином), тестирование представления может быть механическим процессом обеспечения того, чтобы правильные методы модели вызывались в ответ на правильные входные данные для представления для тестирования некоторого клиента боковая проверка того, кто знает.

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

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

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

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

Ответ 4

Mercury QuickTest Pro, Borland SilkTest и Ranorex Recorder - это некоторые инструменты для тестирования графического интерфейса.

Ответ 5

Если ваше приложение основано на веб-интерфейсе, вы можете писать тесты с помощью таких инструментов, как WatiN или Selenium.

Если ваше приложение основано на Windows.NET, вы можете попробовать White.

Ответ 6

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

Новая тенденция - игнорировать тесты GUI. См. Шаблон ModelViewPresenter от Fowler в качестве ориентира текст ссылки

Ответ 7

Самый ясный способ сказать это:

Не тратьте время на автоматические тесты графического интерфейса.

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

Ответ 8

Мы используем тестирование GUI в нашем проекте, и оно имеет свои побочные эффекты. У разработчиков, однако, есть один критический принцип: держите слой GUI как можно более тонким!

Это означает отсутствие логики в классах GUI. Отделите это в моделях презентаций, ответственных за проверку ввода и т.д.

Для тестирования на машине Unix мы используем сервер Xvfb как DISPLAY при выполнении тестов.

Ответ 9

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

Ответ 10

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

Ответ 11

Не пропустите "U" в "GUI"
Я имею в виду: если то, что вы пытаетесь проверить, все работает правильно и работает так, как планировалось работать, тогда вы можете следовать ответу Seb Rose.

Но, пожалуйста, не забывайте, что интерфейс USER должен быть обращен к пользователям ПОЛЬЗОВАТЕЛЕЙ, а не ЛЮБОЙ пользователь, а TARGET USER, к которому было приложено приложение. Таким образом, после того, как вы уверены, что все работает так, как будто оно должно работать, ставьте каждый тест/экран/форму в тесте командой из пользователей, представляющих каждую группу разных пользователей, которые могут использовать ваше приложение: продвинутые пользователи, администраторы, MS Office пользователи, пользователи с низким уровнем профиля компьютера, пользователи с высоким профилем компьютера... а затем, получите критику каждого пользователя, сделайте микс, повторно подключите свой графический интерфейс, если это необходимо, и вернитесь к пользовательскому тесту пользователя GUI.

Ответ 12

Я нашел WinTask, чтобы быть очень хорошим способом тестирования GUI. Если вы не постоянно меняете то, как ОС относится к каждому элементу пользовательского интерфейса, WinTask обращается к элементам пользовательского интерфейса по имени, поэтому, даже если макет изменяется, элементы пользовательского интерфейса все еще могут быть нажаты/изменены/выбраны.

Ответ 13

Для SIMPLE веб-тестирования GUI попробуйте iMacros (простой плагин Firefox, имеет классную функцию для отправки всего теста другому человек ) Обратите внимание, что SIMPLE пишется с помощью Initials...