GUI Testing

Question

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Новое направление - игнорировать тесты GUI. Смотрите рисунок ModelViewPresenter от Фаулера в качестве ориентира link text

Answer 7

Ярчайших образом я могу сказать, что это:

Не тратьте свое время на написание автоматизированных тестов GUI.

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

Answer 8

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

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

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

Answer 9

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

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

Answer 10

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

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

Answer 11

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

Answer 12

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

Answer 13

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