Сообщений в теме: 17

[snark]

Кто нибудь имел дело с loadUi ?
Насколько ее можно исползовать как замену JМeter например?

[tab15]

Присоединяюсь к вопросу.

[fesd]

а самим попробовать использовать?

[snark]

а самим попробовать использовать?

Пробовать, я пробую. Пока нравится. Но хотелось бы услышать мнение людей, которые это использовали в продакшене (2 года jMeter,3 года loadUI). Какие подводные камни, киллерфичи, и пр.

[AxelM]

а самим попробовать использовать?

Пробовать, я пробую. Пока нравится. Но хотелось бы услышать мнение людей, которые это использовали в продакшене (2 года jMeter,3 года loadUI). Какие подводные камни, киллерфичи, и пр.

Попробовал только что loadUI.
Всем известно, что на интерфейс LoadRunner, Jmeter, Grinder и т.д. без слез не взглянешь. loadUI -- это штука, которая поражает своим внешним видом. Такого вы не найдете даже в медиа-плеерах: ползунки, рычажки и прочие свистелки

 loadui1.PNG   180,01К   71 Количество загрузок:

Ребята подключили даже midi-клавиатуру. Так и представил себе тестировщика ди-джея.



Однако написать более-менее сложный тест на loadUI вряд ли удастся: количество окон получится угрожающе большим. Спасает положение возможность разработки тестов на Groovy. Т.е., например, вытащить значение из ответа при помощи regexp вы сможете уже только зная программирование, рачажки тут не помогут.

Стоит отдать должное архитектуре loadUI. После беглого осмотра: динамически меняется heap у агентов, логи ведутся в БД, сам сценарий пишется в xml, плагины написаны на Groovy (не нравится -- поменяй код под себя), в качестве репортера -- JasperReports (сохраняй отчет во что хочешь). Об отчетах стоит сказать отдельно: сравнение разных запусков, совмещение графиков, куча всяких показателей.

В проектах, где тесты -- это воспроизведение бизнес-процесса, думаю, loadUI будет не слишком удобен. Но взглянуть на него обязательно стоит. Как минимум получите эстетическое удовольствие.

[OVA]

А что нужно заменить? Генератор нагрузки не устраивает? Или работа с данными? Raw Data + R сильно лучше средне-бесполезных свистелок.

[AxelM]

На одном Raw Data + R далеко не уедешь. Хочу генератор нагрузки, описываемый функцией (допустим, у меня его параметры меняются часто во времени), хочется отчет одной кнопкой, который было бы не стыдно показать, хочется сравнения результатов разных запусков по n показателям.
Опять же, для Raw Data обработчик напиши, для R скрипт составь, для сбора статистики с сервера скрипт напиши, для графикогенерилки, для отчетохранилки, дли сравнивалки, для экпортилки, для БД, для рассылки и т.д. В итоге, собственно тестирование занимает малое время, бОльшее -- программирование.

[OVA]

Я тоже очень хочу чтобы я такой сидел и мне все делали хорошо забесплатно. Но так не бывает.
Большая часть готовых коробочных изделий отлично работает ровно до тех пор пока нет потребности или желания за рамки этой коробки выбраться (а оно возникает, если вы собираетесь серьезно заниматься своей работой, а не отчеты красивые рисовать). А дальше *ВНЕЗАПНО* начинается опять же то же что вы написали. И это в лучшем случае. Потому что обработку сырых данных написать достаточно один раз. Скрипты на R тоже не сильно сложно, если разобраться что и как там работает. Сборка любой метрики так же пишется ровно один раз. А если это все еще и не нужно прикручивать к уже существующему решению с закрытым кодом и/или уродским API, то занимает оно не так уж и много времени.
Генерацию графиков и прочее на R писать не надо. Оно само отлично с рядом задач справляется.

Ну и любимое - сколько времени у вас уходит на прогон тестов? сколько на их написание? сколько на дизайн? сколько на анализ результатов?

[AxelM]

Если говорить в рамках loadUI, то я написал, что его архитектура позволяет писать/изменять плагины по своему усмотрению. Возможно кому-то, а судя по клиентам smart bear, такие фирмы есть, этого вполне достаточно, а значит есть причина и остальным посмотреть на этот инструмент. Поэтому, собственно, я и написал свой пост.

Что касается общих вещей, то я уже давно не питаю иллюзий на счет того, что надо что-то написать один раз и будешь пользоваться им всегда. Да, все перечисленное выше написать не сложно и у меня, как и у многих, наверное, здесь есть свой маленький лунапарк. Но, как мне кажется, уникальная особенность именно тестирования производительности заключается в том, что оно совмещает собственно тестирование, программирование, аналитику. Думаю, каждому тут нравится что-то больше, что-то меньше. Мне -- аналитика и мат. статистика (может, потому, что именно сейчас я устал писать эти лунапарки). Вот, собственно так просто, без холивара.

[OVA]

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

[volk's]

Всем привет! есть вопросец) а в чем отличие soapUI от loadUi?
soapUI - больше подходит для тестирования функционала
loadUi - для тестирования производительности !?

каким инструментом пользуетесь?)

[snark]

Ну вы в общем сами себе ответили.

каким инструментом пользуетесь?)

При необходимости обоими. Это не конкурирующие , а дополняющие инструменты. soapUI можно видеть как один из компонентов для loadUI. А можно и наоборот, рассматривать loadUI как обертку для запуска кейсов soapUI.

[AlexTheWizard]

каким инструментом пользуетесь?)

soapUI естественно использую для функционального тестирования, что касается loadUi серьезного тестирования на нем не делал, но пару раз его посмотрел. В целом впечатления:

• красиво, прикольно;
• можно прикрутить тесты из soapUI ;
• Может не нашел, но как его запустить скажем из-под Линукса в консольном режиме, на ночь, например, оставить?
• ИМХО, сложилось впечатление, что у него могут быть проблемы с гибкостью в плане описания различных ситуаций и интерпретирования результатов в зависимости от них.

В скором времени возможно придется заняться нагрузочными тестами по soap, для начала буду пытаться прикрутить JMeter...

[tab15]

Вопрос по loadUI 2.0. Объясните, пожалуйста, где там можно найти время response time желательно для каждого реквеста? В Statistic Workbench показывает только график из которого сильно ничего не прочитаешь - экспорт ничего не дает:(

[Черная Команда]

По мне JMeter лучше тул. Да, если вы выбираете тулы только из-за внешнего вида, то loadUI лучший вариант :)

В JMeter есть все необходимое, а чего нету? Так велком ту исходники и пишем свои плагины :))))
Вообще конечно у всех свои плюсы и минусы)

[volk's]

ну поработав с jmeter я заметил, что он проц хорошо кушает на больших нагрузках, если листенеры включать, причем даж которые не такие информативные.
а в loadUI у меня норм нагрузка шла в 1000 потоков. Ну, в принципе, и jmeter из командной строки запустить можно, тогда норм все.
у меня в связи с этим есть вопрос кстати.
Если мы jmeter из командной строки запустили, посли прогонки теста, можно будет посмотреть как-нибудь, ну например, листенер Graph result?

[tab15]

Не уверен, но с jmeter скорей всего будут в нашем случае проблемы:
1 - придется переписывать тесты, которые уже готовы в soapUI (это сотни служеб взаимосвязанные разной не тривиальной логикой)
2 - не знаю как jmeter справляется с ws-addressing (к сожалению нам придется иметь с ним дело и при нагрузочных тестах)
3 - почти из каждой службы нужно вытаскивать по нескольку параметров и передавать в другие службы (много писанины с поиском в xml этих параметров)

Пока похоже придется обойтись средствами самого soapUI. Какую то особую выгоду в использовании free-версии loadUI не вижу (а платная дорогая собака)

[volk's]

А на что способен вообще loadUI!?
ну в каких случаях его применять?
какаю max нагрузку можно сгенерить?