Хорошо, может быть, я что-то пропустил, но я действительно не вижу смысла в Selenium. В чем смысл открытия браузера с помощью кода, нажатия кнопок с использованием кода и проверки текста с использованием кода? Я прочитал веб-сайт, и я вижу, как в теории было бы хорошо автоматически использовать unit test ваши веб-приложения, но в конце концов, это не займет много времени, чтобы написать весь этот код, а не просто щелкнуть и визуально проверить вещи работать?
Я не понимаю...
Он позволяет вам писать функциональные тесты в вашей "единичной" среде тестирования (проблема заключается в названии более позднего).
Когда вы тестируете приложение через браузер, вы обычно тестируете систему полностью интегрированной. Подумайте, что вам уже нужно протестировать свои изменения, прежде чем совершать их (тесты на дым), вы не хотите проверять его вручную снова и снова.
Что-то действительно приятное, это то, что вы можете автоматизировать ваши тесты на дым, и QA может увеличить их. Довольно эффективно, поскольку это уменьшает дублирование усилий и приближает всю команду.
Ps как любая практика, которую вы используете в первый раз, когда у нее есть кривая обучения, поэтому она обычно занимает больше времени в первый раз. Я также предлагаю вам взглянуть на шаблон Object Object, он помогает поддерживать чистоту тестов.
Обновление 1: Обратите внимание, что тесты также будут запускать javascript на страницах, что помогает тестировать высокодинамичные страницы. Также обратите внимание, что вы можете запускать его с разными браузерами, поэтому вы можете проверять проблемы с несколькими браузерами (по крайней мере, на функциональной стороне, поскольку вам все равно нужно проверить визуальную).
Также обратите внимание, что по мере того, как количество страниц, на которые распространяются тесты, вы можете быстро создавать тесты с полным циклом взаимодействий. Используя шаблон страницы страницы, они выглядят так:
LastPage aPage = somePage
.SomeAction()
.AnotherActionWithParams("somevalue")
//... other actions
.AnotherOneThatKeepsYouOnthePage();
// add some asserts using methods that give you info
// on LastPage (or that check the info is there).
// you can of course break the statements to add additional
// asserts on the multi-steps story.
Важно понимать, что вы постепенно об этом говорите. Если это уже построенная система, вы добавляете тесты для функций/изменений, над которыми вы работаете. Добавляем все больше и больше возможностей на этом пути. Вместо этого вы направляете руководство, обычно скрываете то, что вы пропустили для тестирования, поэтому, если вы внесли изменения, которые затрагивают каждую страницу, и вы проверите подмножество (по мере того как время не позволяет), вы знаете, какие из них вы фактически протестировали, и QA может работать с там (надеюсь, добавив еще больше тестов).
Это обычная вещь, о которой говорят об модульном тестировании в целом. "Мне нужно написать в два раза больше кода для тестирования?" Здесь применяются те же принципы. Выплата - это возможность изменить ваш код и знать, что вы ничего не нарушаете.
Потому что вы можете повторять тест САМЫЙ снова и снова.
Если ваше приложение составляет еще 50+ страниц, и вам нужно делать частые сборки и тестировать его по сравнению с X-номером основных браузеров, это имеет большой смысл.
Представьте, что у вас есть 50 страниц, каждая из которых содержит по 10 ссылок, а некоторые - с несколькими этапами, которые требуют от вас пройти через формы, вводя около 100 различных наборов информации, чтобы убедиться, что они работают правильно со всеми номерами кредитных карт, всех адресов во всех странах и т.д.
Это невозможно проверить вручную. Это становится настолько склонным к человеческой ошибке, что вы не можете гарантировать, что тестирование было выполнено правильно, неважно, что тестирование доказало о тестируемой вещи.
Кроме того, если вы придерживаетесь современной модели разработки, у многих разработчиков все работают на одном и том же сайте в отключенном, распределенном виде (некоторые работают на сайте со своего ноутбука, например, на самолете), то человеческие тестеры даже не смогут получить к нему доступ, а тем более терпение повторить проверку каждый раз, когда один разработчик пытается что-то новое.
На любом приличном размере веб-сайта тесты должны быть автоматизированы.
Точка такая же, как при любом автоматическом тестировании: для записи кода может потребоваться больше времени, чем "просто щелкнуть и визуально проверить работу", возможно, 10 или даже 50 раз больше.
Но любое нетривиальное приложение должно быть проверено более чем в 50 раз в конце концов, а ручные тесты - это раздражающая работа, которая, вероятно, будет опущена или сделана подкожно под давлением, что приводит к тому, что ошибки остаются неоткрытыми до тех пор, пока они не будут (или после) важные сроки, что приводит к стрессовым сеансам ночного кодирования или даже к прямым денежным потерям из-за контрактных штрафов.
Selenium (наряду с подобными инструментами, такими как Watir) позволяет запускать тесты с пользовательским интерфейсом вашего веб-приложения способами, которые хорошо подходят компьютерам: тысячи раз в одночасье или через несколько секунд после каждой проверки исходного кода. (Обратите внимание, что есть много других образцов для тестирования пользовательского интерфейса, которые люди намного лучше, например, замечая, что какая-то странная вещь, не связанная напрямую с тестом, несовместима.)
Есть другие способы задействовать весь стек вашего приложения, глядя на сгенерированный HTML, а не на запуск браузера для его отображения, например Webrat и Mechanize. Большинство из них не имеют возможности взаимодействовать с JavaScript-тяжелыми интерфейсами; Селен вы здесь несколько освещали.
Selenium будет записывать и повторно запускать все ручные нажатия и ввод текста для проверки вашего веб-приложения. Снова и снова.
С течением времени мои исследования показали мне, что я стараюсь делать меньше тестов и начинаю пропускать некоторые или забывать о них.
Selenium вместо этого возьмет каждый тест, запустит его, если он не вернет то, что вы ожидаете, он может сообщить вам.
Существует предварительная стоимость времени для записи всех этих тестов. Я бы рекомендовал его как модульные тесты - , если у вас его нет, начните использовать его с самыми сложными, обидчивыми или самыми обновленными частями вашего кода.
И если вы сохраните эти тесты как классы JUnit, вы можете повторно запустить их на досуге, как часть вашей автоматизированной сборки или в тестах с плохим человеком, используя JMeter.
В прошлой работе мы использовали unit test наше веб-приложение. Если веб-приложение меняет внешний вид, тесты не нужно переписывать. Тесты типа записи и повторного воспроизведения должны быть переделаны.
Зачем вам Селен? Потому что тестеры - это люди. Они ходят домой каждый день, не всегда могут работать в выходные, принимать отходы, принимать праздничные дни, время от времени уходить в отпуск, скучать, делать повторяющиеся задачи и не всегда могут полагаться на них, когда они вам нужны.
Я не говорю, что вы должны избавиться от тестеров, но автоматизированный инструмент тестирования пользовательского интерфейса дополняет тестеры системы.
Точка - это способность автоматизировать то, что было до ручного и трудоемкого теста. Да, для написания тестов требуется время, но как только они написаны, их можно запустить так часто, как пожелает команда. Каждый раз, когда они запускаются, они проверяют, что поведение веб-приложения является последовательным. Selenium - не идеальный продукт, но он очень хорош в автоматизации реалистичного взаимодействия с браузером.
Если вам не нравится подход Selenium, вы можете попробовать HtmlUnit, я считаю его более полезным и легким для интеграции в существующие модульные тесты.
Для приложений с богатыми веб-интерфейсами (как и многие проекты GWT) Selenium/Windmill/WebDriver/etc - это способ создания приемочных тестов. В случае GWT/GXT код конечного пользовательского интерфейса находится в JavaScript, поэтому создание приемочных тестов с использованием обычных тестовых примеров junit в принципе не может быть и речи. С помощью Selenium вы можете создавать тестовые сценарии, соответствующие действиям пользователя и ожидаемым результатам.
Основываясь на моем опыте работы с Selenium, он может выявлять ошибки в логике приложения и пользовательском интерфейсе (в случае, если ваши тестовые примеры хорошо написаны). Работа с передними концами AJAX требует дополнительных усилий, но это по-прежнему возможно.
Я использую его для тестирования многостраничных форм, так как это берет на себя обязательство печатать одно и то же снова и снова. И наличие возможности проверить, присутствуют ли некоторые элементы, отлично. Опять же, используя форму в качестве примера, ваш последний тест на селен может проверить, появляется ли в конце процесса заказа что-то вроде "Спасибо г-ну Роджерсу за заказ...".