С чего начать нагрузочное тестирование?
#1
Отправлено 10 января 2007 - 11:01
У нас в компании внедряется нагрузочное тестирование, и я хотел бы узнать, с чего начинать внедрение нагрузочного тестирования? Поделитесь опытом, с начинающим!
P.S. Если есть ссылочки на хорошие книги по теме, поделитесь.
#2
Отправлено 10 января 2007 - 11:40
руководитель отдела тестирования,
Объединенная компания «Афиши» и «Рамблера»
http://www.rambler.ru/jobs/
#3
Отправлено 10 января 2007 - 12:00
Начинается обычно с определения целей: что будем делать (и что не будем делать), зачем и какие бонусы от этого будем иметь
#4
Отправлено 11 января 2007 - 08:01
#5
Отправлено 11 января 2007 - 09:31
Давайте вы мне будете задавать конкретные вопросы, а я вам выдавать ответы, просто я понятия не имею, что можно упомянуть про АС что бы приблизиться к обсуждению нагрузочного тестирования :)Хотелось бы более подробно понять что именно тестировать собираетесь?
Принято решение внедрять!Внедряется или принято решение внедрить?
Для начала мы, хотим проверить АС на "Прочность", какие нагрузки она сможет выдержать.Начинается обычно с определения целей: что будем делать (и что не будем делать), зачем и какие бонусы от этого будем иметь
Бонус. Я думаю пока один, мы станем более уверенными в нашем ПО.
#6
Отправлено 11 января 2007 - 11:14
Для начала мы, хотим проверить АС на "Прочность", какие нагрузки она сможет выдержать.
Бонус. Я думаю пока один, мы станем более уверенными в нашем ПО.
Прекрасное основание
Надеюсь, топ-менеджемент им удовлетворен и готов вкладывать ресурсы и время в это дело
Выделите наиболее критичные функции системы, вы же не собираетесь всю АС проверять на "Прочность".
Задокументируйте план и стратегию работ, согласуйте с руководством.
Исходя из поставленных задач и архитектуры системы начинайте выбирать подходящий тул.
И не забудьте про бюджет проекта, если Вам критична стоимость тулов.
#7
Отправлено 11 января 2007 - 13:00
Что вы подразумеваете под словом "критичные"?Выделите наиболее критичные функции системы, вы же не собираетесь всю АС проверять на "Прочность".
Функционал, который имеет большую вероятность выхода из строя или функционал, загружающий АС больше остальных? (тут как посмотреть на понятие критичность)
Это общий принцип работы и тут всё понятно!Задокументируйте план и стратегию работ, согласуйте с руководством.
Что вы можете порекомендовать, учитывая, что наша компания разрабатывает ПО на Java и C#?Исходя из поставленных задач и архитектуры системы начинайте выбирать подходящий тул.
#8
Отправлено 11 января 2007 - 13:20
Здесь Вы уж сами напрягитесьЧто вы подразумеваете под словом "критичные"?
Функционал, который имеет большую вероятность выхода из строя или функционал, загружающий АС больше остальных? (тут как посмотреть на понятие критичность)
Для Java не знаю, а C# сейчас подддерживают праткически все тулы.Что вы можете порекомендовать, учитывая, что наша компания разрабатывает ПО на Java и C#?
Вы разберитесь сначала, что нагружать будете
#9
Отправлено 12 января 2007 - 01:19
Вообще-то, как правило, под критичностью понимают критичность для бизнеса, потому что системы создаются и работают не для IT-шников, а для того, чтобы достичь каких-то бизнес целей. Вот под этим углом и рассматривайте ваш функционал - какая его часть (какие бизнес-процессы, выполняемые системой) нанесет больший урон бизнесу если не будет работать или будет работать нестабильно.Что вы подразумеваете под словом "критичные"?
Функционал, который имеет большую вероятность выхода из строя или функционал, загружающий АС больше остальных? (тут как посмотреть на понятие критичность)
На чем вы разрабатываете ваше ПО имеет очень слабое отношение к выбору тула для нагрузочного тестирования. Вы прежде всего должны хорошо понимать архитектуру тестируемой системы и, в частности, знать по какому протоколу происходит общение клиента с сервером. Вот это и будет определять выбор тулов. Ну и ваш бюджет, конечно. Это само собой.Что вы можете порекомендовать, учитывая, что наша компания разрабатывает ПО на Java и C#?
#10
Отправлено 12 января 2007 - 01:23
Это каким же образом тулы для нагрузочного тестирования имеют какую-то поддержку C#? Я что-то не вижу никакой связи.Для Java не знаю, а C# сейчас подддерживают праткически все тулы.
#11
Отправлено 12 января 2007 - 07:07
Для начала мы, хотим проверить АС на "Прочность", какие нагрузки она сможет выдержать.Начинается обычно с определения целей: что будем делать (и что не будем делать), зачем и какие бонусы от этого будем иметь
Бонус. Я думаю пока один, мы станем более уверенными в нашем ПО.
Тестирование, и нагрузочное тестирование не исключение, - это моделирование. Вначале делается предположение, затем создается модель, которая позволит проверить предположение.
В случае нагрузочного тестирования нужно "плясать от печки". Что именно Вы хотите проверить, в каких единицах, где граница между хорошо-плохо (критерии успешности) и только потом Вы задумываетесь - как это сделать. Но, уверяю Вас, если Вы будете знать ответы на предыдущие вопросы, то и со второй частью проблем не будет.
Полагаю, что самым первым шагом должен быть шаг по изучению теории. На этом форуме нагрузочное тестирование обсуждается довольно подробно. Так же можно посмотреть вот эту книгу:
Тестирование производительности Web-приложений Microsoft. NET
#12
Отправлено 12 января 2007 - 10:40
Взял книгу, начинаем читать :)Есть хорошая книга:
http://www.software-...are_testing.htm
Там все подробно описано.
#14
Отправлено 13 января 2007 - 02:17
Вот именно, что никаким. Когда захочется функционального, то и речь пойдет о выборе тула для функционального тестирования (автор топика даже не заикался об этом). Там и требования к тулу будут другими. А выбирать тул для нагрузочного тестирования по требованиям к тулу для функционального тестирования это как набирать борцов сумо по требованиям для легкоатлетов.Никаким. Зато когда захочется функционального - это будет важно.
#15
Отправлено 13 января 2007 - 17:11
Ну вот например TestManager совершенно точно умеет выполнять на удалённых нагрузочных станциях безинтерфейсные "клиентские" java-приложения, которые реализуют его API для контроля выполнением и сбора счётчиков времён отклика. В таких приложениях, если хорошенько попрыгать над CLASSPATH, можно использовать любые другие доступные Java библиотеки, например реализующие всякие протоколы к серверу (RMI, CORBA, EJB или вообще что-то экзотическое, типа JMX).Это каким же образом тулы для нагрузочного тестирования имеют какую-то поддержку C#? Я что-то не вижу никакой связи.
Мне рассказывали, что LR тоже так может, причём ещё круче: он как раз может пускать .net приложения, а не только java; да ещё его API предусматривает многопоточные vusers. Может быть это правда маркетинговые сказки?
#16
Отправлено 13 января 2007 - 20:32
Вы путаете 2 совершенно разных понятия. Поддержка конкретного языка программирования в качестве языка для разработки нагрузочных скриптов в том или ином туле не имеет в общем случае ничего общего с тем, на каком языке программирования реализовано тестируемое приложение. Java это не протокол, а язык программирования. Ваше Java приложение может использовать HTTP, RMI или что-то еще для связи с сервером. И как эта связь будет реализована в каком-то конкретном туле - на Java, C или на каком-то своем собственном языке программирования, как в Rational Robot - это дело конкретного тула. А уж API самого тула, который позволяет ему делать мониторинг, вообще никаким боком к скриптам не относится. TestManager это вообще не инструмент для создания скриптов.Ну вот например TestManager совершенно точно умеет выполнять на удалённых нагрузочных станциях безинтерфейсные "клиентские" java-приложения, которые реализуют его API для контроля выполнением и сбора счётчиков времён отклика.
У вас с терминологией какая-то путаница. LR не запускает никаких приложений. Он запускает скрипты, создаваемые в VuGen.Мне рассказывали, что LR тоже так может, причём ещё круче: он как раз может пускать .net приложения, а не только java;
Если вы имеете в виду запуск виртуальных пользователей (в том числе и .NET VUsers) в multithreading режиме, то это не сказки.да ещё его API предусматривает многопоточные vusers. Может быть это правда маркетинговые сказки?
#17
Отправлено 14 января 2007 - 10:34
Поддержка конкретного языка программирования в качестве языка для разработки нагрузочных скриптов в том или ином туле не имеет в общем случае ничего общего с тем, на каком языке программирования реализовано тестируемое приложение.
Ну наверное всё-таки в частном случае. Именно в том, когда тул поддерживает нужный протокол. :) JMX, к слову, не только для мониторинга предназначен, но например для выполнения административных задач на серверных компонентах. Конечно, нагрузочно тестировать административные действия вряд ли понадобится, я просто привёл пример протокола, скриптование которого не реализовано (по моим сведениям, может быть ошибаюсь).
TestManager это вообще не инструмент для создания скриптов.
А я и не сказал, что он для создания скриптов. Зато можно ему в TDS положить заранее собранный jar, который реализует некоторый API rational, API нужный для связи с сервером и заглушку визуальной части (если у приложения вообще есть визуальная часть). Потом стандартным образом указать на какой нагружалке сколько таких jar запустить, обратно вернутся и сохранятся в TDS статусы выполнения и времена отклика, точно такие, как если бы это был скрипт, по ним можно отчёты построить.
Ну ладно, пусть будут скрипты. Если язык скипта "Java vuser", то писать его придётся самому без Recording и Correlation, можно в нём сделать import чему угодно, а выполняться он будет всё равно в JVM (ну это тоже мне так кажется, в LR я не проверял). Т.е. фактически то же самое, что в TM, может быть ещё с многопоточностью. А могло бы этого не быть. Тогда нельзя бы было сказать, что LR поддерживает java, а можно было бы сказать, что он поддерживает некоторые протоколы используемые в J2EE. :)У вас с терминологией какая-то путаница. LR не запускает никаких приложений. Он запускает скрипты, создаваемые в VuGen.
#18
Отправлено 14 января 2007 - 16:35
Вот именно, что вы привели пример абсолютного левого (с точки зрения нагрузочного тестирования) протокола, который никто и не собирался реализовывать для скриптования. С точки зрения нагрузочного тестирования это тот самый "неуловимый Джо", который никому не нужен.JMX, к слову, не только для мониторинга предназначен, но например для выполнения административных задач на серверных компонентах. Конечно, нагрузочно тестировать административные действия вряд ли понадобится, я просто привёл пример протокола, скриптование которого не реализовано (по моим сведениям, может быть ошибаюсь)
Ну и к чему вы все это сказали? Да, LR поддерживает Java в качестве языка разработки скриптов. И что с того? А мог бы использовать какой-то свой универсальный язык, который служил бы wrapper для той же Java или для чего угодно. Template VUsers, такие как Java VUser, используются только в случаях, когда требуемый протокол просто не поддерживается out-of-the-box. В таком случае тул вообще на 99% не будут рассматривать в качестве возможного приобретения. Ручками Java код писать можно и за гораздо меньшие деньги и в гораздо более удобном редакторе, чем VUGen.Ну ладно, пусть будут скрипты. Если язык скипта "Java vuser", то писать его придётся самому без Recording и Correlation, можно в нём сделать import чему угодно, а выполняться он будет всё равно в JVM (ну это тоже мне так кажется, в LR я не проверял). Т.е. фактически то же самое, что в TM, может быть ещё с многопоточностью. А могло бы этого не быть. Тогда нельзя бы было сказать, что LR поддерживает java, а можно было бы сказать, что он поддерживает некоторые протоколы используемые в J2EE. :)
Ta же Java может использоваться и для разработки обычных Web/HTTP VUsers, для которых дефолтным языком разработки является С. Это просто язык, используемый самим тулом, а не язык, на котором разрабатываются приложения. Тот факт, что они в некоторых случаях могут совпадать, вовсе не говорит о том, что если бы они не совпадали, то и тестировать такие приложения в данном туле было бы нельзя.
#19
Отправлено 14 января 2007 - 19:54
Ладно, в моей команде происходит замена. После недолгих размышлений JMX заменяется на t3 и ormi (не уверен что их ловит "Java-RMI").С точки зрения нагрузочного тестирования это тот самый "неуловимый Джо", который никому не нужен.
Собственно в пользу верного на мой взгляд утверждения о поддержке тулами OO языков и всех их имеющихся и части будущих библиотечных функций и протоколов. :) Можно иметь различные мнения нужно ли это индустрии или нет, но оно есть.Ну и к чему вы все это сказали?
Нехороший какой-то диалог у нас получается, но всё-таки скажу: "Мне кажется, что это луч света в тёмном царстве и он указывает нам направление развития".Да, LR поддерживает Java в качестве языка разработки скриптов. И что с того?
Собственно ведь так и есть, и есть также наблюдаемые факты, что знание каких-то там "универсальных языков" в общем-то не гарантирует хорошо проведённого нагрузочного тестирования. Это даже если оставить в стороне занимательный процесс "актуализации" таких скриптов.А мог бы использовать какой-то свой универсальный язык, который служил бы wrapper для той же Java или для чего угодно.
Я, собственно, к тому и вёл, что от скриптов написанных на языке с независимым runtime до отказа от дорогостоящих тулов всего три шага, и этот отказ может позитивно (ну с точки зрения простого обывателя) сказаться на бюджете. По-моему очень хорошее утверждение и неплохо бы ему остаться в топике "С чего начать нагрузочное тестирование" для пользователей поиска. А то как-то очень быстро обсуждение перескочило на тулы. Лично мне, например, импонирует идея отказа от тулов и создания взамен квалифицированных рабочих мест. По крайней мере, в компаниях-разработчиках.В таком случае тул вообще на 99% не будут рассматривать в качестве возможного приобретения. Ручками Java код писать можно и за гораздо меньшие деньги и в гораздо более удобном редакторе, чем VUGen.
С этим сложно поспорить (я кажется и не спорил). Наоборот могу подтвердить, что в LR в некоторых случаях продуманы существенные удобства ("http/web"), а в некоторых, особо клинических, различие в языках просто обязательно ("Oracle NCA"). Диявол скрывается в количественных оценках нужности тех или иных фич.Тот факт, что они в некоторых случаях могут совпадать, вовсе не говорит о том, что если бы они не совпадали, то и тестировать такие приложения в данном туле было бы нельзя.
#20
Отправлено 15 января 2007 - 04:05
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных