Должны ли графические интерфейсы иметь свои собственные автоматизированные тесты? - PullRequest
7 голосов
/ 17 апреля 2010

Есть ли причина для автоматизации тестов, ориентированных на GUI (а не на вещи под ним)? По моему мнению, GUI (и изменения в нем) всегда должны тестироваться реальным человеком.

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

Ответы [ 9 ]

4 голосов
/ 17 апреля 2010

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

В результате я остановился на гибридном подходе к проектам, которые я возглавляю и управляю. Мне нравится использовать ручное тестирование в областях графического интерфейса, которые быстро меняются в течение цикла разработки. Когда все становится достаточно стабильным, мы проводим какое-то автоматическое тестирование графического интерфейса пользователя (например, Selenium для веб-приложений), которое мы включаем в процесс сборки, чтобы защититься от будущего регресса. Если это вообще возможно, люди QA пишут автоматизированные тесты. Иногда разработчикам приходится работать с тестировщиками QA, чтобы сделать это, когда автоматизированный инструмент требует слишком много кода.

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

2 голосов
/ 17 апреля 2010

Это зависит.

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

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

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

0 голосов
/ 23 апреля 2010

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

0 голосов
/ 18 апреля 2010

Да, конечно, в GUis должны быть свои юнит-тесты. См. Например IcuTest .

Проблема в том, что тестирование GUI является сложным . Как только вы это решите, мир станет вашим.

0 голосов
/ 17 апреля 2010

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

Вы получите тонны бычьего мусора, чтобы просмотреть. Юзабилити - это большое слово, но простой юзабилити-тест - это нанять вашего помощника (желательно не того, кого вы знаете, друга друга), которого вы, возможно, считаете находящимся в приложении «целевой аудиторией». Надевая camtasia / camstudio (программное обеспечение для записи на рабочем столе, возможно, будет хорошо записать его лицо). Дайте ему несколько заданий на листе бумаги (или лично, иногда бумага лучше, потому что вы не будете вмешиваться - более реалистичный сценарий). И смотри, что он делает!

Если он нуждается в помощи, то вы видите разделы внимания для будущего развития. Никогда не пытайтесь повлиять на парня, который говорит ему такие вещи, как «но посмотри, вот эта кнопка, я подумал, что так удобнее».

Вы получите гораздо лучшие результаты такого теста, чем тратите свое время на компьютерное тестирование. GUI - это ИНТЕРФЕЙС между человеком и компьютером. Модульное тестирование - это все равно что пытаться разобрать только что написанную книгу и проверить, хорошо ли это. Конечно, это устранит ошибки проверки орфографии, например, но это очень маленькая вещь -> по сравнению с реальными целями книги.

0 голосов
/ 17 апреля 2010

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

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

0 голосов
/ 17 апреля 2010

Это возможно. Для браузера у вас есть тестовые наборы, такие как селен, которые взаимодействуют с браузером.

0 голосов
/ 17 апреля 2010

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

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

0 голосов
/ 17 апреля 2010

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...