HtmlUnit + Selenium в производстве

WebDriver и Selenium идеально подходят для производственной среды. Я использую их довольно широко в течение 2 лет в распределенной сетке с несколькими машинами / несколькими центрами обработки данных, и у меня не было абсолютно никаких проблем с производительностью или стабильностью, с которыми мы не могли бы справиться.

Мы предпочитаем драйвер Firefox (тяжелее, чем HTMLUnit, и его сложнее настроить), и нам пришлось настроить сетку, чтобы понять, сколько экземпляров мы можем запустить. Наш максимум для стабильности был 1 на ядро

Наши экземпляры selenium/webdriver работают круглосуточно и без выходных уже 2 года (1 год с selenium 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, так это то, что он имитирует реального пользователя, выполняющего некоторые действия на веб-странице.

Моя личная интуиция подсказывает, что я должен проводить как можно меньше производственного тестирования. Так что лично я бы использовал эти инструменты только для проверки, если мое веб-приложение еще живо.

Да, это общий ответ на общий вопрос, но попробуйте следующее:

Соберите людей, ответственных за веб-приложение, и спросите их:

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

• Если да, то что нужно тестировать на производстве?

• Если да, то должна ли она быть автоматизирована?

И тогда у вас есть ответ ;)