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

[Dmitry_NJ]

Если посмотреть на предложения о работе за границей, то как правило требуется знания WinRUNNER + Test Director.

Если серьезно подумываете о работе заграницей, то очень рекомендовал бы изучить LoadRunner (a еще лучше сдать сертификационный экзамен по этому продукту). Тогда ваши шансы станут намного выше. QTP/WR+TD - это довольно распространенные skills, ради них мало кто станет возиться с оформлением рабочей визы. LoadRunner - другой уровень, им владеют уже гораздо меньше людей, а спрос на таких специалистов большой. LR, конечно, не так прост, как WR/QTP, но зато ваши старания по его изучению окупятся сторицей.

[Alinabagi]

Если автора действительно интересуют различие в подходах, тогда наверное лучше было бы посмотреть аналогичные продукты Rational.

да, меня интересуют различные стратегии тестирования, причем учитывая то, что программный продукт написан на Делфи.
А что конкретно посмотреть в Ратионале? И разве там есть поддержка Делфи? А еще интересно кто-нибудь когда-нибудь пользовался TestComplete?

[barancev]

А еще интересно кто-нибудь когда-нибудь пользовался TestComplete?

Конечно, многие пользовались и пользуются. Но для политкорректности предлагаю перенести дискуссию в соответствующий форум и задать вопросы там.

[Dmitry_NJ]

Нагрузочное тестирование:
Есть инструменты (OpenSTA к примеру) - которые реально используются в довольно крупных компаниях.

Имейте в виду, что OpenSTA ограничен только рамками HTTP(S) протокола, ничего больше он делать не умеет, иными словами, если у вас обычное клиент/серверное приложение с какой-нибудь БД, то OpenSTA уже не катит. Он даже не может сделать transaction и/или page component breakdown для того же HTTP(S) трафика. Вобщем это хорошая игрушка, если все что вам нужно это сгенерировать веб трафик и замерить время без серьезного анализа причин возможных проблем, без возможности посмотреть а что творится во время нагрузочного теста за веб сервером (если за ним стоит сервер приложений и/или сервер БД).

Вобщем, если нужно просто вокруг дома покататься, то можно и на картинге, а если куда-то далеко ехать, то нужна уже машина.

[barancev]

Нагрузочное тестирование:
Есть инструменты (OpenSTA к примеру) - которые реально используются в довольно крупных компаниях.

Имейте в виду, что OpenSTA ограничен только рамками HTTP(S) протокола, ничего больше он делать не умеет, иными словами, если у вас обычное клиент/серверное приложение с какой-нибудь БД, то OpenSTA уже не катит. Он даже не может сделать transaction и/или page component breakdown для того же HTTP(S) трафика. Вобщем это хорошая игрушка, если все что вам нужно это сгенерировать веб трафик и замерить время без серьезного анализа причин возможных проблем, без возможности посмотреть а что творится во время нагрузочного теста за веб сервером (если за ним стоит сервер приложений и/или сервер БД).

Дмитрий, не шантажируйте :)

Можно пользоваться OpenSTA и ещё к нему взять несколько мониторов от других производителей, например, OptimizeIt, или даже ещё более специализировнные мониторы для сервера отдельно, для СУБД отдельно. И будет всё хорошо -- нагрузка генерируется, измерения делаются. Кончено, такое решение имеет недостаток -- отсутствие обратной связи монитора с генератором нагрузки, но это обратная связь и в комплексных решениях тоже оставляет желать лучшего.

Я не против комплексных решений, я против того, чтобы выставлять их как панацею. Более того, мне известны случаи, когда люди пользовались LoadRunner'ом, но в добавок к нему использовали ещё один генератор нагрузки, потому что родной они считали слишком "тупым и примитивным".

[Dmitry_NJ]

Можно пользоваться OpenSTA и ещё к нему взять несколько мониторов от других производителей, например, OptimizeIt, или даже ещё более специализировнные мониторы для сервера отдельно, для СУБД отдельно.

Более того, мне известны случаи, когда люди пользовались LoadRunner'ом, но в добавок к нему использовали ещё один генератор нагрузки, потому что родной они считали слишком "тупым и примитивным".

Алексей, тут я не согласен с вами.

Если добавить к OpenSTA что-то еще, то это будет уже не OpenSTA, а целый набор инструментов, к тому же еще непонятно каким образом связанных друг с другом. Речь ведь шла о возможностях самого OpenSTA, о том что сам продукт имеет сильно ограниченные возможности. Конечно, всегда можно найти как эти возможности расширить, но тогда такая связка может ведь оказаться и небесплатной в итоге. А если к OpenSTA, например, добавить еще и LoadRunner, то вообще конфетка получилась бы.

А что касается людей, которые пришли к выводу, что генератор нагрузки в LoadRunner "тупой и примитивный", то вот из-за таких персонажей LoadRunner очень долгое время и не был в открытом доступе для скачивания. Потому что велика вероятность, что неподготовленный человек самостоятельно просто не разберется в каких-то вопросах (а нагрузочное тестирование не так элементарно, как функциональное) и, естественно, будет потом говорить, что это продукт "тупой и примитивный", а не он сам. Более того, скажу что у нас есть продукты, например Business Availability Center (раньше называвшийся Topaz), которые без консалтинга вообще не продаются. Performance Center без консалтинга больше не продадут, по крайней мере, в ближайшем будущем, потому что уже есть негативные примеры того, что люди не в состоянии сами разобраться во всех деталях, в результате чего потом появляются ситуации 911 и нам (консультантам) приходится разгребать все это.

Если вы знаете что конкретно было признано "тупым и примитивным" в генераторе нагрузки LoadRunner, то я готов более детально это обсудить. Хотя мне трудно представить какого рода "интеллектуальность" ожидалась от генератора. Это простой движок, который гоняет скрипты по командам контроллера и потом просто передает собранные результаты обратно контроллеру. Вся интеллектуальная начинка "зашита" в самих скриптах и в сценарии.

[barancev]

Если добавить к OpenSTA что-то еще, то это будет уже не OpenSTA, а целый набор инструментов, к тому же еще непонятно каким образом связанных друг с другом. Речь ведь шла о возможностях самого OpenSTA, о том что сам продукт имеет сильно ограниченные возможности. Конечно, всегда можно найти как эти возможности расширить, но тогда такая связка может ведь оказаться и небесплатной в итоге. А если к OpenSTA, например, добавить еще и LoadRunner, то вообще конфетка получилась бы.

Согласен, это будет уже не OpenSTA, а некоторое "самодельное" комплексное решение. Не факт, что оно хуже, чем "брендовое", потому что возможности выбора компонентов и их комбинирования гораздо шире. Что касается бесплатности -- это вопрос неоднозначный. Если используется бесплатное ПО (скажем, сервер приложений от Sun и MySQL СУБД), то по их масштабам и мониторы бесплатные найдутся. А если WebSphere и Oracle -- так это уже само по себе сильно недёшево, но зато и мониторы "от производителя" в комплекте.

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

Какой я могу сделать вывод? Надо Меркурию больше работать над юзабилити :), надо повышать удобство использования и простоту освоения, сглаживать кривую обучения. Простые задачи должны решаться просто, даже если инструмент имеет мощные и сложные возможности для решения сложных задач.

Если вы знаете что конкретно было признано "тупым и примитивным" в генераторе нагрузки LoadRunner, то я готов более детально это обсудить. Хотя мне трудно представить какого рода "интеллектуальность" ожидалась от генератора. Это простой движок, который гоняет скрипты по командам контроллера и потом просто передает собранные результаты обратно контроллеру. Вся интеллектуальная начинка "зашита" в самих скриптах и в сценарии.

Знаю. Дело было в том, что ребята были не просто тестировщики, но и хорошие программисты, поэтому они умели генерировать много "хороших", "осмысленных" тестов автоматически, это делала программа на Java, и им показалось сложно и неэффективно реализовывать это же самое на скриптовом языке LR. Ну вот они и скомбинировали. Никаких претензий к движку. Претензии были к языку, на котором скрипты пишутся. Впрочем, возможно, это дело вкуса, языки -- вечный повод для религиозных войн :)

[Dmitry_NJ]

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

Знаю. Дело было в том, что ребята были не просто тестировщики, но и хорошие программисты, поэтому они умели генерировать много "хороших", "осмысленных" тестов автоматически, это делала программа на Java, и им показалось сложно и неэффективно реализовывать это же самое на скриптовом языке LR. Ну вот они и скомбинировали. Никаких претензий к движку. Претензии были к языку, на котором скрипты пишутся. Впрочем, возможно, это дело вкуса, языки -- вечный повод для религиозных войн :)

Вот как раз простые задачи просто и решаются. Только далеко не всегда при нагрузочном тестировании задачи бывают простые. Если, конечно, тестируется что-то серьезное. A что касается Business Availability Center (BAC), то это вообще не отдельный продукт, а целая платформа. Вряд ли системы уровня IBM Tivoli, HP OpenView или BMC Patrol продаются без консалтинга. А Mercury BAC как раз система из этого же ряда.

Вот ваши знакомые ребята как раз и есть живая иллюстрация к моему предыдущему постингу - продукт где-то получили, а как правильно им пользоваться - без понятия. Может они и хорошие программисты, но в LoadRunner'е смыслят мало. Во-первых, никакого специального скриптового языка (наподобие TSL в WinRunner) в LoadRunner'e не существует (кстати, сравните с Rational Robot/LoadTest). В зависимости от выбранного типа виртуальных пользователей - это либо стандартный ANSI C (в большинстве случаев), либо VB/VBScript/JavaScript, либо просто Java. Да, самая обыкновенная Java, на которой они свои тесты и создавали (или программа какая-то делала это за них). Зачем вместо того, чтобы гонять уже готовые тесты в LoadRunner (добавьте только транзакции, чтобы было что измерять и откомпилите в VUGen'e), надо зачем-то реализовывать тоже самое на каком-то другом языке? Спрашивается, нафига козе баян? Зато был сделан вывод о "тупости и примитивности" продукта. Хотя на самом то деле все оказалось совсем наоборот.