Графический интерфейсы пользователя должны иметь свои собственные автоматизированные тесты?
Есть ли какая-либо причина автоматизации тестов, которые фокусируются на GUI (а не к вещам под нею)? По-моему, GUI (и изменения в нем) должен всегда тестироваться живым человеком.
Что можно получить с автоматизированными тестами фокусировки GUI? Мой собственный опыт состоял в том, что тесты фокусировки GUI почти всегда повреждаются, потому что кто-то изменил что-то на действительно серьезном основании. Они редко, кажется, находят что-либо интересным.
9 ответов
Это сложный вопрос. Инструменты и фреймворки автоматизированного тестирования отлично справляются со своей задачей и стоят потраченного времени и усилий, если графический интерфейс не меняется слишком сильно. Проблема с автоматическим тестированием заключается в том, что оно выходит из строя именно тогда, когда вам это нужно больше всего: когда графический интерфейс быстро меняется в течение цикла разработки.
В результате я остановился на гибридном подходе к проектам, которые я возглавляю и управляю. Мне нравится использовать ручное тестирование тех областей графического интерфейса, которые быстро меняются в течение цикла разработки. Как только все станет достаточно стабильным, мы проводим какое-то автоматическое тестирование графического интерфейса (например, Selenium для веб-приложений), которое мы добавляем в процесс сборки, чтобы предотвратить регресс в будущем. Если возможно, специалисты по тестированию напишут автоматизированные тесты. Иногда разработчикам приходится объединяться с тестировщиками QA, чтобы сделать это, когда автоматизированный инструмент требует слишком большого количества кода.
Этот гибридный подход, кажется, работает хорошо, пока мы используем хорошие методы проектирования, которые должным образом разделяют задачи, чтобы модульные тесты могли правильно выполнять всю лежащую в основе логику. Единственное, чего вы должны избегать, - это встраивать логику приложения в слой графического интерфейса.
Зависит от того, «какую» часть графического интерфейса вы тестируете. Проверяете ли вы поведение системы с помощью теста графического интерфейса пользователя или хотите проверить, правильно ли отображается ваш графический интерфейс в любое время.
В последнем случае это зависит от вашего приложения. Если верстка и дизайн важны, я согласен. Однако, если это какое-то приложение, основная функциональность которого не связана с макетом, нет смысла тратить время на тестирование макета. Было бы лучше написать тест GUI, который проверял бы функциональность, используя GUI вместо вызовов некоторых функций. Таким образом, реальное поведение лучше моделируется.
Люди отлично умеют тестировать графические интерфейсы. Хотя они дорогие. Инструменты автоматического тестирования, по крайней мере теоретически, снижают стоимость тестирования пользовательских интерфейсов. Если вы выпускаете частые релизы, время ручного тестирования пользовательского интерфейса может быстро возрасти.
Я лично никогда не видел, чтобы инструменты автоматизированного тестирования пользовательского интерфейса окупали свои затраты на установку для проектов, над которыми я работал. Их тесты, как правило, нестабильны и плохо реагируют на изменения макета. По этой причине я не решаюсь им доверять. Однако я был бы счастлив, если бы ошибся.
Мой подход в этой ситуации обычно заключается в модульном тестировании слоев без графического интерфейса пользователя, использовании автоматизированного тестирования графического интерфейса, насколько это возможно, а затем ручном тестировании всего, что осталось . Я также использую ручное тестирование для специального обнаружения дефектов для выявления отсутствующих тестовых случаев.
На мой взгляд, это обеспечивает наилучшее соотношение покрытия тестирования к стоимости. В конечном итоге это зависит от того, чего вы пытаетесь достичь - это критически важное программное обеспечение или простое приложение, в котором сбой является просто неудобством?
Лучше пусть сначала будет тестирование юзабилити. Кроме того, как вы собираетесь тестировать графический интерфейс модуля? Что будет на выходе? Если кто-то щелкает что-то и получает то, что «изначально» искал? Что следует считать неприемлемым поведением?
Вы получите массу ерунды, которую нужно будет просмотреть. Юзабилити - это громкое слово, но простой юзабилити-тест - это нанять вашего друга (желательно не кого-то, кого вы знаете, друг друга), которого вы могли бы считать целевой аудиторией приложения. Включите camtasia / camstudio (программное обеспечение для записи на рабочем столе, может быть полезно записать его лицо). Дайте ему несколько задач на листе бумаги (или лично, иногда бумага лучше, потому что вы не будете мешать - более реалистичный сценарий). И смотрите, что он делает!
Если ему потребуется помощь, вы увидите участки, которым будет уделено внимание для будущего развития. Никогда не пытайтесь повлиять на парня, говоря ему такие вещи, как "но вот эта кнопка, я подумал, что так удобнее".
Вы получите гораздо лучший результат такого теста, чем тратите время на межкомпьютерное тестирование. GUI - это ИНТЕРФЕЙС между человеком и компьютером. Интерфейс для модульного тестирования похож на попытку разобрать книгу, которую вы только что написали, и посмотреть, есть ли в ней что-то хорошее. Конечно, он устранит, например, ошибки проверки орфографии, но это очень мелочь -> по сравнению с настоящими целями книги.
Да, конечно, GUis должны иметь собственные модульные тесты. См., Например, IcuTest .
Проблема в том, что тестирование графического интерфейса сложно. Как только вы это решите, мир принадлежит вам.
Это зависит от обстоятельств.
Если ваш графический интерфейс представляет собой относительно тонкий слой над вашей бизнес-логикой, а мелкие ошибки в графическом интерфейсе не критичны для вашего бизнеса, вы можете не тратить время на тщательное тестирование графического интерфейса с помощью модульных тестов. Возможно, тогда лучше потратить время на тестирование более важного кода.
Если ваш графический интерфейс очень сложен и является важным аргументом в пользу вашего приложения, вы можете потратить время на его автоматическое и ручное тестирование. Автоматическое тестирование не полностью заменяет ручное тестирование, так как вам по-прежнему нужны люди-тестировщики, чтобы убедиться, что графический интерфейс выглядит правильно, а интерфейс ясен и интуитивно понятен.
См. Википедию для получения дополнительной информации о тестировании графического интерфейса пользователя - например, путем записи ввода мыши и клавиш и их воспроизведения. Существует также список программного обеспечения , которое может помочь вам в создании модульных тестов GUI.
Это возможно. Для браузера у вас есть тестовые наборы, такие как селен, которые взаимодействуют с браузером.
Если у вас есть повторяющиеся монотонные задачи в тестирование графического интерфейса пользователя, и это необходимо для нескольких комбинаций браузеров и ОС, автоматизация графического интерфейса стоит того. С помощью техник сопровождения можно ответить на знаменитый вопрос: «Изменения пользовательского интерфейса сделают автоматизацию неуместной».