HtmlUnit + Selenium в рамках производства
В настоящее время я использую HtmlUnit и Selenium для управления им (WebDriver) в своем производственном коде.
Я программирую и взаимодействую с различными веб-сайтами программно с этими библиотеками и добился определенного успеха и не испытываю проблем с памятью (гарантируя, что сессии всегда очищаются).
Мне интересно, подходят ли эти библиотеки для производственной среды или не рекомендуются. Это трудно найти через Google из-за огромного количества информации об автоматическом тестировании, а не о том, как я их использую.
Я понимаю, что это довольно общий вопрос, но я ищу совет по поводу этих библиотек и потенциально лучших альтернатив.
3 ответа
WebDriver и Selenium идеально подходят для производственной среды. Я использую их довольно широко в течение 2 лет на распределенной сетке с несколькими машинами / несколькими центрами обработки данных, и у меня не было абсолютно никаких проблем с производительностью и стабильностью, с которыми мы не могли бы справиться.
Наш предпочтительный драйвер - Firefox (тяжелее, чем HTMLUnit, и его сложнее настроить), и нам пришлось настроить сетку, чтобы понять, сколько экземпляров мы можем запустить. Наш максимум стабильности был 1 на ядро
Наши экземпляры selenium/webdriver работают 24/7 в течение 2 лет (1 год с селеном 1, а другой инкрементно мигрирует selenium 2/ WebDriver) и с соответствующим мониторингом (вы должны отслеживать использование памяти / использование процессора) и кучу нагрузочное тестирование, мы достигли хорошего уровня, где мы испытали несколько месяцев без перезапуска процесса
Мы также широко использовали HTMLUnit и одинаково довольны этой библиотекой
Суть моего поста: ДА, эти библиотеки готовы к производству. Но, как и все производственное программное обеспечение, вы должны будете сравнить его использование, чтобы найти подходящую конфигурацию для оптимальной стабильности. Я рекомендую вам использовать Selenium Grid в производстве, что является отличным способом распараллелить процесс
Я использую HtmlUnit для чего-то похожего в производстве, и у меня было немало проблем - в основном связанных с производительностью. В настоящее время я переключился на версию снимка HtmlUnit 2.10, где были реализованы некоторые важные для меня улучшения производительности (например, замена ArrayList.contains()
с HashSet.contains()
на DomNode.addDomChangeListener()
).
Тем не менее, загрузка процессора довольно высока на страницах с большим количеством JavaScript. Как правило, я не могу запустить более 10 из них одновременно на двухъядерном Linux. Я считаю, что HtmlUnit использует Rhino (движок JavaScript) только в режиме интерпретатора, что довольно медленно. Кроме того, вы должны быть осторожны с освобождением всех ресурсов, используемых HtmlUnit, чтобы избежать утечек памяти.
В целом, безусловно, заметно, что HtmlUnit был разработан для запуска сравнительно коротких тестовых случаев и не долго работающих серверных приложений. Можно настроить его достаточно, чтобы он был управляемым, но, безусловно, могло бы быть и лучше.
Другой подход, который я нашел многообещающим, - это phantom-js, безголовая версия браузера WebKit, родного приложения, которое намного быстрее работает на JavaScript.
Как правило, используйте свое тестирование "интуиции" по этому поводу. Что делает WebDriver и HTMLUnit, так это то, что он моделирует реального пользователя, выполняющего некоторые действия на веб-странице.
Моя личная интуиция говорит, что я должен делать как можно меньше производственных испытаний. Так что я лично использовал бы эти инструменты только для проверки, если мое веб-приложение еще живо.
Да, это общий ответ на общий вопрос, но попробуйте это:
Соберите людей, ответственных за веб-приложение, и спросите их:
Должно ли оно быть проверено на производстве? (так что всегда есть небольшой шанс, что некоторые клиенты увидят эти тестовые данные)
Если да, что должно быть проверено на производстве?
Если да, должно ли это быть автоматизировано?
И тогда у вас есть ответ;)