Комментарии 18
А можете привести максимальное количество соединений/сек, которое способен генерировать Selenium при прохождении сценариев? Грубо, на достаточно мощном сервере.
Я, конечно, не автор, но возьму на себя смелость ответить. Порядка сотен, если сильно повезет.
Вообще я не очень понимаю, как совмещаются «Selenium» с «70 пользователями» и «нагрузочное тестирование». Для нагрузочного тестирования есть совершенно отдельный ряд инструментов и никакими driven-браузерами там, разумеется, даже близко не пользуются.
Вообще я не очень понимаю, как совмещаются «Selenium» с «70 пользователями» и «нагрузочное тестирование». Для нагрузочного тестирования есть совершенно отдельный ряд инструментов и никакими driven-браузерами там, разумеется, даже близко не пользуются.
Вы совершили простую ошибку в начале пути, когда отказались от load runner'a, признав его отклики недостоверными.
Нагрузочное тестирование подразумевает возможность разделения генерации нагрузки (jmeter или другой адекватный задаче инструмент) и измерения откликов (руками или селениумом).
Полгода назад мы проделали аналогичную работу, уперлись в ограниечение по ресурсам для браузеров.
Пришлось перерабатывать систему на совместную работу selenium и jmeter.
Нагрузочное тестирование подразумевает возможность разделения генерации нагрузки (jmeter или другой адекватный задаче инструмент) и измерения откликов (руками или селениумом).
Полгода назад мы проделали аналогичную работу, уперлись в ограниечение по ресурсам для браузеров.
Пришлось перерабатывать систему на совместную работу selenium и jmeter.
А можно чуть подробнее?
Как генерировать нагрузку в JMeter понятно.
А вот как мерить время из Selenium?
Как генерировать нагрузку в JMeter понятно.
А вот как мерить время из Selenium?
Я вам ответил ниже, ошибся кнопкой.
ИМХО, лучше даже не пытать проводить нагрузочное тестирование с помощью Selenium. Достоверные результаты можно получить, запустив JMeter с нескольких хостов. Однажды тестировали приложение, которое хостилось в Бельгии. Результаты одного и того же тест-плана, запущенного с компьютеров в Праге, Москве и Антверпене были разные, но в пределах одной статистической погрешности.
Не соглашусь. Степень достоверности результатов выше как раз у Selenium, он по поведению ближе к реальному пользователю(браузер, много хостов), чем инструменты для нагрузочного тестирования(нет браузера, только запросы к серверу, причем большинство с одного хоста).
В случае активного использования аяксов на сайте специнструменты вообще сложно применять.
Специализированные инструменты выигрывают на 2-4 порядка по потребляемым ресурсам в расчете на одного сэмулированного пользователя, поэтому и приходится использовать их, делая модель нагрузки более грубой.
В случае активного использования аяксов на сайте специнструменты вообще сложно применять.
Специализированные инструменты выигрывают на 2-4 порядка по потребляемым ресурсам в расчете на одного сэмулированного пользователя, поэтому и приходится использовать их, делая модель нагрузки более грубой.
В JMeter есть возможность записывать сценарии с помощью прокси. Берем тест-план, начинаем запись, ходим по страницам, останавливаем запись. Вычищаем запросы к статике и внешним ресурсам (политика зависит от целей тестирования: лоад/стресс). Ставим задержку на выполнение каждого потока со случайной погрешностью N +- M секунд. В чем грубость? Статику по-хорошему все-равно надо выносить на отдельный домен и там тестировать уже отдельно.
Таким образом — уже ближе к реальности.
Но все же требуется доработка напильником. Jmeter (по умолчанию) выполняет запросы к серверу последовательно, а браузер какие-то последовательно, какие-то параллельно, в зависимости от не знаю чего уж там.
И так далее.
У нас была проблема, что асинхронные запросы могут серьезно меняться от одной версии приложения к другой(от одной настройки к другой… ), поэтому каждый раз необходимо перезаписывать сценарий для jmeter.
Но все же требуется доработка напильником. Jmeter (по умолчанию) выполняет запросы к серверу последовательно, а браузер какие-то последовательно, какие-то параллельно, в зависимости от не знаю чего уж там.
И так далее.
У нас была проблема, что асинхронные запросы могут серьезно меняться от одной версии приложения к другой(от одной настройки к другой… ), поэтому каждый раз необходимо перезаписывать сценарий для jmeter.
В статье не писал, но от LoadRunner'а мы совсем не отказывались. Хотели провести следующий сценарий — сначала Selenium'ом максимально нагрузить (параллельно освоить функциональные тесты), а потом использовать как раз такую связку — LoadRunner плюс Selenium.
А в чём заключалась переработка системы под jMeter? Мне показалось, что тут нужно просто помимо Selenium'а просто jMeter запустить (само собой, настроив на нём тесты) и всё.
А что вы за web приложение тестировали? Был ли там JS? А то мы, собственно, столкнулись с проблемой того, что приложения для нагрузочного тестирования не позволяют полностью эмулировать работу браузера, а это нам было критично, так как и из за этого результаты тестов были не совсем корректны.
А в чём заключалась переработка системы под jMeter? Мне показалось, что тут нужно просто помимо Selenium'а просто jMeter запустить (само собой, настроив на нём тесты) и всё.
А что вы за web приложение тестировали? Был ли там JS? А то мы, собственно, столкнулись с проблемой того, что приложения для нагрузочного тестирования не позволяют полностью эмулировать работу браузера, а это нам было критично, так как и из за этого результаты тестов были не совсем корректны.
У нас была система функционального тестирования. Мы пытались использовать ее для нагрузки. Фейл.
Мы пытались использовать jmeter. Интерфейс асинхронный, скрипты, яваскрипты и прочий аякс — а значит недостаточно просто запросить страницу, большая часть данных передается как раз после отработки скриптов, асинхронно. Фейл.
Теперь мы создали монстра: в рамках одного теста с помощью selenium прогоняется сценарий, который автоматически записывается в lmeter. Таким образом мы перехватываем все асинхронные запросы.
Затем он парсится, параметризуется для масштабирования, затем запускается jmeter — это нагрузка.
Отклики jmeter мы не считаем, это бесполезные цифры, мы считаем совершенное им количество бизнес операций — это нагрузка на сервер.
А в это время selenium тест выполняет сценарии и запоминает отклики.
Как-то так.
Мы пытались использовать jmeter. Интерфейс асинхронный, скрипты, яваскрипты и прочий аякс — а значит недостаточно просто запросить страницу, большая часть данных передается как раз после отработки скриптов, асинхронно. Фейл.
Теперь мы создали монстра: в рамках одного теста с помощью selenium прогоняется сценарий, который автоматически записывается в lmeter. Таким образом мы перехватываем все асинхронные запросы.
Затем он парсится, параметризуется для масштабирования, затем запускается jmeter — это нагрузка.
Отклики jmeter мы не считаем, это бесполезные цифры, мы считаем совершенное им количество бизнес операций — это нагрузка на сервер.
А в это время selenium тест выполняет сценарии и запоминает отклики.
Как-то так.
Хм, так же, как и руками оно измеряется. Запоминаете время до события, вычитаете его из времени после события. Из разницы, можно вычесть лаг тестирующей системы, но он, как правило, пренебрежимо мал.
Ваши результаты как то коррелируют с тем, что происходит на боевом?
Нет, так как боевого нет — СЭД не ещё не вошла в эксплуатацию (в предпоследней главе об этом говорится).
Но как только реальные данные появятся, тесты будут переделаны под них.
Но как только реальные данные появятся, тесты будут переделаны под них.
Простите, я читал по диагонали, в надежде получить ответ только на один вопрос — можно ли получить с нагрузочного теста корпоративного приложения адекватные цифры.
У нас, к примеру, по большинству бизнес процессов вышли результаты вообще не похожие на данные с боевого(отличия на порядок и в ту и другую сторону).
У нас, к примеру, по большинству бизнес процессов вышли результаты вообще не похожие на данные с боевого(отличия на порядок и в ту и другую сторону).
С помощью LoadRunner’s нагрузочный тест был проведён, но результаты были поставлены под сомнения – при эмуляции двухсот пользователей страницы загружалась за 2 секунды плюс-минус 2%, хотя при открытии этих же страниц из браузера отображение происходило более чем за 3 секунды.
Нагрузочное тестирование отвечает за производительность на стороне сервера. Нагрузочное тестирование никак не отвечает на вопросы «как быстро отрисовывается страница на стороне клиента». Когда необходимо понять как быстро сервер может отдавать ответы — это область именно для нагрузочного тестирования. Когда нужно ответить как быстро грузятся и собирается страничка у пользователя — это тестирование клиент-сайда. Это две разных, но связных области. Для каждой области свой набор инструментов. Для первого хорошо подойдут уже упомянутые решения hp loadrunner, apache jmeter, tsung, yandex-tank, gatling-tool. Для второго как раз можно использовать selenium или что-то еще. Надеемся что скоро компания с большой буквы выложит инструмент Шуттилка events.yandex.ru/events/yasubbotnik/spb-dec-2012/talks/479/
Может сейчас вам хватает производительности Selenium и это здорово, что вы можете отвечать сразу на два вопроса. Но будьте осторожны, вы ломаете подходы, и в результате раскладываете перед собой вдвое больше граблей, на которое проще наступить.
Автоматизировать jmeter, yandex-tank так же легко, просто воспользуйтесь средством автоматизации, например Jenkins CI.
Кроме того, в большинстве случаев для работы с JMeter не нужно писать ни одной строчки кода, что очень удобно. Людям не нужно знать язык программирования, чтобы написать тест-план и провести нагрузочное тестирование.
Подведение итогов
Честно говоря меня сильно смущает график «Кол-во пользователей на Время ответа». В нагрузочном тестировании принято следить не за «средним» временем ответа, а в основном за перцентилями. За сколько мс уложились 95% ответов? Такая метрика отражает более существенные и понятные человеку значения. Среднее значение может быть около 1 секунды, и нам кажется что это нормально, а процентов 30%-40% всех ответов могут вылезать за 3 секунды, что уже, возможно, неприемлимо.
В целом, интересно, спасибо за статью, вы смогли сразу ответить на два вопроса о скорости сервер-сайда и клиент-сайда, но лучше так не делать!:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нагрузочное тестирование с помощью Selenium