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

[Sudo -NAT]

Здравствуйте.
У нас в компании внедряется нагрузочное тестирование, и я хотел бы узнать, с чего начинать внедрение нагрузочного тестирования? Поделитесь опытом, с начинающим!

P.S. Если есть ссылочки на хорошие книги по теме, поделитесь.

[BaAbaKa]

Хотелось бы более подробно понять что именно тестировать собираетесь?

[serega]

Внедряется или принято решение внедрить?

Начинается обычно с определения целей: что будем делать (и что не будем делать), зачем и какие бонусы от этого будем иметь

[van]

Есть хорошая книга:
http://www.software-...are_testing.htm

Там все подробно описано.

[Sudo -NAT]

Хотелось бы более подробно понять что именно тестировать собираетесь?

Давайте вы мне будете задавать конкретные вопросы, а я вам выдавать ответы, просто я понятия не имею, что можно упомянуть про АС что бы приблизиться к обсуждению нагрузочного тестирования :)

Внедряется или принято решение внедрить?

Принято решение внедрять!

Начинается обычно с определения целей: что будем делать (и что не будем делать), зачем и какие бонусы от этого будем иметь

Для начала мы, хотим проверить АС на "Прочность", какие нагрузки она сможет выдержать.
Бонус. Я думаю пока один, мы станем более уверенными в нашем ПО.

[serega]

Для начала мы, хотим проверить АС на "Прочность", какие нагрузки она сможет выдержать.
Бонус. Я думаю пока один, мы станем более уверенными в нашем ПО.

Прекрасное основание
Надеюсь, топ-менеджемент им удовлетворен и готов вкладывать ресурсы и время в это дело

Выделите наиболее критичные функции системы, вы же не собираетесь всю АС проверять на "Прочность".

Задокументируйте план и стратегию работ, согласуйте с руководством.

Исходя из поставленных задач и архитектуры системы начинайте выбирать подходящий тул.

И не забудьте про бюджет проекта, если Вам критична стоимость тулов.

[Sudo -NAT]

Выделите наиболее критичные функции системы, вы же не собираетесь всю АС проверять на "Прочность".

Что вы подразумеваете под словом "критичные"?
Функционал, который имеет большую вероятность выхода из строя или функционал, загружающий АС больше остальных? (тут как посмотреть на понятие критичность)

Задокументируйте план и стратегию работ, согласуйте с руководством.

Это общий принцип работы и тут всё понятно!

Исходя из поставленных задач и архитектуры системы начинайте выбирать подходящий тул.

Что вы можете порекомендовать, учитывая, что наша компания разрабатывает ПО на Java и C#?

[serega]

Что вы подразумеваете под словом "критичные"?
Функционал, который имеет большую вероятность выхода из строя или функционал, загружающий АС больше остальных? (тут как посмотреть на понятие критичность)

Здесь Вы уж сами напрягитесь

Что вы можете порекомендовать, учитывая, что наша компания разрабатывает ПО на Java и C#?

Для Java не знаю, а C# сейчас подддерживают праткически все тулы.
Вы разберитесь сначала, что нагружать будете

[Dmitry_NJ]

Что вы подразумеваете под словом "критичные"?
Функционал, который имеет большую вероятность выхода из строя или функционал, загружающий АС больше остальных? (тут как посмотреть на понятие критичность)

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

Что вы можете порекомендовать, учитывая, что наша компания разрабатывает ПО на Java и C#?

На чем вы разрабатываете ваше ПО имеет очень слабое отношение к выбору тула для нагрузочного тестирования. Вы прежде всего должны хорошо понимать архитектуру тестируемой системы и, в частности, знать по какому протоколу происходит общение клиента с сервером. Вот это и будет определять выбор тулов. Ну и ваш бюджет, конечно. Это само собой.

[Dmitry_NJ]

Для Java не знаю, а C# сейчас подддерживают праткически все тулы.

Это каким же образом тулы для нагрузочного тестирования имеют какую-то поддержку C#? Я что-то не вижу никакой связи.

[Green]

Начинается обычно с определения целей: что будем делать (и что не будем делать), зачем и какие бонусы от этого будем иметь

Для начала мы, хотим проверить АС на "Прочность", какие нагрузки она сможет выдержать.
Бонус. Я думаю пока один, мы станем более уверенными в нашем ПО.

Тестирование, и нагрузочное тестирование не исключение, - это моделирование. Вначале делается предположение, затем создается модель, которая позволит проверить предположение.

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

Полагаю, что самым первым шагом должен быть шаг по изучению теории. На этом форуме нагрузочное тестирование обсуждается довольно подробно. Так же можно посмотреть вот эту книгу:
Тестирование производительности Web-приложений Microsoft. NET

[Sudo -NAT]

Есть хорошая книга:
http://www.software-...are_testing.htm
Там все подробно описано.

Взял книгу, начинаем читать :)

[serega]

Это каким же образом тулы для нагрузочного тестирования имеют какую-то поддержку C#? Я что-то не вижу никакой связи.

Никаким. Зато когда захочется функционального - это будет важно.

[Dmitry_NJ]

Никаким. Зато когда захочется функционального - это будет важно.

Вот именно, что никаким. Когда захочется функционального, то и речь пойдет о выборе тула для функционального тестирования (автор топика даже не заикался об этом). Там и требования к тулу будут другими. А выбирать тул для нагрузочного тестирования по требованиям к тулу для функционального тестирования это как набирать борцов сумо по требованиям для легкоатлетов.

[a66at]

Это каким же образом тулы для нагрузочного тестирования имеют какую-то поддержку C#? Я что-то не вижу никакой связи.

Ну вот например TestManager совершенно точно умеет выполнять на удалённых нагрузочных станциях безинтерфейсные "клиентские" java-приложения, которые реализуют его API для контроля выполнением и сбора счётчиков времён отклика. В таких приложениях, если хорошенько попрыгать над CLASSPATH, можно использовать любые другие доступные Java библиотеки, например реализующие всякие протоколы к серверу (RMI, CORBA, EJB или вообще что-то экзотическое, типа JMX).
Мне рассказывали, что LR тоже так может, причём ещё круче: он как раз может пускать .net приложения, а не только java; да ещё его API предусматривает многопоточные vusers. Может быть это правда маркетинговые сказки?

[Dmitry_NJ]

Ну вот например TestManager совершенно точно умеет выполнять на удалённых нагрузочных станциях безинтерфейсные "клиентские" java-приложения, которые реализуют его API для контроля выполнением и сбора счётчиков времён отклика.

Вы путаете 2 совершенно разных понятия. Поддержка конкретного языка программирования в качестве языка для разработки нагрузочных скриптов в том или ином туле не имеет в общем случае ничего общего с тем, на каком языке программирования реализовано тестируемое приложение. Java это не протокол, а язык программирования. Ваше Java приложение может использовать HTTP, RMI или что-то еще для связи с сервером. И как эта связь будет реализована в каком-то конкретном туле - на Java, C или на каком-то своем собственном языке программирования, как в Rational Robot - это дело конкретного тула. А уж API самого тула, который позволяет ему делать мониторинг, вообще никаким боком к скриптам не относится. TestManager это вообще не инструмент для создания скриптов.

Мне рассказывали, что LR тоже так может, причём ещё круче: он как раз может пускать .net приложения, а не только java;

У вас с терминологией какая-то путаница. LR не запускает никаких приложений. Он запускает скрипты, создаваемые в VuGen.

да ещё его API предусматривает многопоточные vusers. Может быть это правда маркетинговые сказки?

Если вы имеете в виду запуск виртуальных пользователей (в том числе и .NET VUsers) в multithreading режиме, то это не сказки.

[a66at]

Поддержка конкретного языка программирования в качестве языка для разработки нагрузочных скриптов в том или ином туле не имеет в общем случае ничего общего с тем, на каком языке программирования реализовано тестируемое приложение.

Ну наверное всё-таки в частном случае. Именно в том, когда тул поддерживает нужный протокол. :) JMX, к слову, не только для мониторинга предназначен, но например для выполнения административных задач на серверных компонентах. Конечно, нагрузочно тестировать административные действия вряд ли понадобится, я просто привёл пример протокола, скриптование которого не реализовано (по моим сведениям, может быть ошибаюсь).

TestManager это вообще не инструмент для создания скриптов.

А я и не сказал, что он для создания скриптов. Зато можно ему в TDS положить заранее собранный jar, который реализует некоторый API rational, API нужный для связи с сервером и заглушку визуальной части (если у приложения вообще есть визуальная часть). Потом стандартным образом указать на какой нагружалке сколько таких jar запустить, обратно вернутся и сохранятся в TDS статусы выполнения и времена отклика, точно такие, как если бы это был скрипт, по ним можно отчёты построить.

У вас с терминологией какая-то путаница. LR не запускает никаких приложений. Он запускает скрипты, создаваемые в VuGen.

Ну ладно, пусть будут скрипты. Если язык скипта "Java vuser", то писать его придётся самому без Recording и Correlation, можно в нём сделать import чему угодно, а выполняться он будет всё равно в JVM (ну это тоже мне так кажется, в LR я не проверял). Т.е. фактически то же самое, что в TM, может быть ещё с многопоточностью. А могло бы этого не быть. Тогда нельзя бы было сказать, что LR поддерживает java, а можно было бы сказать, что он поддерживает некоторые протоколы используемые в J2EE. :)

[Dmitry_NJ]

JMX, к слову, не только для мониторинга предназначен, но например для выполнения административных задач на серверных компонентах. Конечно, нагрузочно тестировать административные действия вряд ли понадобится, я просто привёл пример протокола, скриптование которого не реализовано (по моим сведениям, может быть ошибаюсь)

Вот именно, что вы привели пример абсолютного левого (с точки зрения нагрузочного тестирования) протокола, который никто и не собирался реализовывать для скриптования. С точки зрения нагрузочного тестирования это тот самый "неуловимый Джо", который никому не нужен.

Ну ладно, пусть будут скрипты. Если язык скипта "Java vuser", то писать его придётся самому без Recording и Correlation, можно в нём сделать import чему угодно, а выполняться он будет всё равно в JVM (ну это тоже мне так кажется, в LR я не проверял). Т.е. фактически то же самое, что в TM, может быть ещё с многопоточностью. А могло бы этого не быть. Тогда нельзя бы было сказать, что LR поддерживает java, а можно было бы сказать, что он поддерживает некоторые протоколы используемые в J2EE. :)

Ну и к чему вы все это сказали? Да, LR поддерживает Java в качестве языка разработки скриптов. И что с того? А мог бы использовать какой-то свой универсальный язык, который служил бы wrapper для той же Java или для чего угодно. Template VUsers, такие как Java VUser, используются только в случаях, когда требуемый протокол просто не поддерживается out-of-the-box. В таком случае тул вообще на 99% не будут рассматривать в качестве возможного приобретения. Ручками Java код писать можно и за гораздо меньшие деньги и в гораздо более удобном редакторе, чем VUGen.

Ta же Java может использоваться и для разработки обычных Web/HTTP VUsers, для которых дефолтным языком разработки является С. Это просто язык, используемый самим тулом, а не язык, на котором разрабатываются приложения. Тот факт, что они в некоторых случаях могут совпадать, вовсе не говорит о том, что если бы они не совпадали, то и тестировать такие приложения в данном туле было бы нельзя.

[a66at]

С точки зрения нагрузочного тестирования это тот самый "неуловимый Джо", который никому не нужен.

Ладно, в моей команде происходит замена. После недолгих размышлений JMX заменяется на t3 и ormi (не уверен что их ловит "Java-RMI").

Ну и к чему вы все это сказали?

Собственно в пользу верного на мой взгляд утверждения о поддержке тулами OO языков и всех их имеющихся и части будущих библиотечных функций и протоколов. :) Можно иметь различные мнения нужно ли это индустрии или нет, но оно есть.

Да, LR поддерживает Java в качестве языка разработки скриптов. И что с того?

Нехороший какой-то диалог у нас получается, но всё-таки скажу: "Мне кажется, что это луч света в тёмном царстве и он указывает нам направление развития".

А мог бы использовать какой-то свой универсальный язык, который служил бы wrapper для той же Java или для чего угодно.

Собственно ведь так и есть, и есть также наблюдаемые факты, что знание каких-то там "универсальных языков" в общем-то не гарантирует хорошо проведённого нагрузочного тестирования. Это даже если оставить в стороне занимательный процесс "актуализации" таких скриптов.

В таком случае тул вообще на 99% не будут рассматривать в качестве возможного приобретения. Ручками Java код писать можно и за гораздо меньшие деньги и в гораздо более удобном редакторе, чем VUGen.

Я, собственно, к тому и вёл, что от скриптов написанных на языке с независимым runtime до отказа от дорогостоящих тулов всего три шага, и этот отказ может позитивно (ну с точки зрения простого обывателя) сказаться на бюджете. По-моему очень хорошее утверждение и неплохо бы ему остаться в топике "С чего начать нагрузочное тестирование" для пользователей поиска. А то как-то очень быстро обсуждение перескочило на тулы. Лично мне, например, импонирует идея отказа от тулов и создания взамен квалифицированных рабочих мест. По крайней мере, в компаниях-разработчиках.

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

С этим сложно поспорить (я кажется и не спорил). Наоборот могу подтвердить, что в LR в некоторых случаях продуманы существенные удобства ("http/web"), а в некоторых, особо клинических, различие в языках просто обязательно ("Oracle NCA"). Диявол скрывается в количественных оценках нужности тех или иных фич.

[Dmitry_NJ]

Так, ну дискуссия вообще ушла в совершенно другую сторону. Какие языки разработки скриптов должны поддерживаться в тулах, должны ли они быть такими же, как и языки разработки тестируемых приложений, или какими-то другими. Неподдерживаемые тулами протоколы (зачем такой тул вообще рассматривать?), отказ от тулов вообще и создание "квалифицированных рабочих мест" и прочее и прочее. Это все, конечно, очень интересно, но к первоначальному вопросу о выборе тула для нагрузочного тестирования это вообще все не имеет никакого отношения.