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

[Case]

Не до конца вижу нагрузочное тестирование в схеме automated framework.
Нагрузочные / распределённые тесты прогоняются наравне с функциональными или это всё-таки отдельный процесс?

[Sandtod]

нагрузочные - в смысле те, которые ещё называются stress тестами?

[Case]

Стресс тесты?.. Не уверен что это именно оно.
Я понимаю стресс тест как моделирование предельных нагрузок на сервер (ну к примеру IIS под определёнными настройками держит 255 одновременных соединений - вот давайте его так и накатим, хотя в жизни реальнее 50 в системе и не будет).
А нагрузочное это скорее ближе к моделированию реальных а не пиковых нагрузок.

[el-step]

Нагрузочные -- это performance и load.
Разницу все понимают по-своему, для меня performance -- определение характеристик работы системы под различными нагрузками, а load -- проверка устойчивости работы и приемлемости характеристик под конкретной нагрузкой. А stress -- предельные и запредельные нагрузки. Но это условности.

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

[Case]

Слишком много тут по вкусу делается - вот что странно - казалось бы не первые мы и всё равно "на глазок".

[doronin]

Вот на этой ссылке указано наше понимание нагрузочного и стресс тестирования.
http://www.faqs.org/...section-15.html

[Case]

В принципе как и было сказано выше:
"Load testing is subjecting a system to a statistically representative (usually) load."
То биш нагрузочное это просто смоделировать обычную работу под нагрузкой, близкую к реальной.
А стрес:
"Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts, etc.) needed to process that load."
То биш стрес он и есть стрес, нагрузка выше планируемой, что бы поглядеть как система себя будет вести если не хватает оперативки, дисковых операций или ещё какого-нить добра.

[Case]

Остался открытым вопрос по поводу места нагрузочного тестирования при построения системы автоматизации тестирования.

[Yukhim]

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

[Case]

А по-моему как раз наоборот :) (а баба яга против)
Нагрузочное тестирование без автоматизации не реализуемо.
Я хочу промоделировать работу системы под нагрузкой, к примеру нагрузить её 100 активными пользователями, как этого добиться не автоматизируя сам процесс моделирования поведения пользователя?

[el-step]

По-моему, автоматизация не всегда применима при нагрузочном тестировании

Это интересный опыт -- поделитесь при случае? Можно отдельной темой, типа "Нагрузочное тестирование -- применение и преимущества ручных и автоматизированных методов" :)

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

[Yukhim]

Здается мне, Гарри, ты хочешь меня обидеть...
Баба яга против только потому, что не сталкивалась с таким тестированием. Нагрузка - это не только юзеры. Это самое простое, что можно сделать очень многими тулами или скриптами. Я вот последний месяц занимался нагрузочным тестированием одной аппликации (как автоматическим, так и ручным), причем ручного было больше. И не из-за того, что нету тулов, а оттого, что неприменимы они в данном случае.
Для примера (бабкам ёжкам и прочим неверующим):
вам нужно получить перфоманс метрики аппликации, которая открывает и процессит какой-то файл и пишет об этом лог, типа, начала процесить файл тогда-то, закончила тогда-то. Я понимаю, что можно написать скрипт, который будет генерить нужные файлы, подкладывать их аппликации и читать логи, но сделать такой скрипт намного сложнее, чем подложить файл руками и получить грепом 2 цифры из лога.
А наша аппликация еще и на удаленном юних сервере, на котором мы ваще ничего не можем запускать, кроме нее, родимой.
Трудно это автоматизировать...

[Case]

Трудно не значит невозможно, имхо. :)
Опять таки, вы привели узкоспециализированный пример, который не отражает картины нагрузочного тестирования как такового.
Опять таки почему проводить нагрузочное тестирование на каком-то удалённом сервере на который у вас даже прав нет? Можно ещё и танцевать в ластах, тоже не очень удобно, а как пример для обьяснения определённых ПА совсем не катит.
Тестирование провдится в тестовой лаборатории в которой у вас все возможности (ваша картина как я себе вижу - скорее рабочий сервер у заказчика).

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

[Yukhim]

Думаю, что проблема в том, что вы не тестировали таких аппликаций. Тем не менее, можно было бы внимательно прочитать мое сообщение, где я написал, что автоматизация нагрузочного тестирования не всегда возможна, а не всегда не возможна.
Неужели вы видите предмет для спора? Или вы считаете, что не возможно возникновение ситуации, когда вы просто не сможете провести автоматизацию?

[Case]

Возможно даже запросто. Почему нет? Никто не спорит, что можно придумать такое решение, которое никак не поддастся тестированию в принципе, не говоря уже о его автоматизации.

А теперь позвольте вывернуть вашу ситуацию - а зачем сделали так, что теперь нельзя автоматизировать тестирование?
Вы создали нетестируемое решение, только и всего.
Под нетестируемостью, а понимаю не дословно, что его нельзя протестить, а то что процесс нельзя автоматизировать в должной мере.

[Case]

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

[el-step]

Неужели вы видите предмет для спора?

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

[Олешка]

To MarinaK:
C учетом специфики интернет-приложений:

Performance testing
Duwamish book
Web server performance
Тестирование производительности Web-серверов

[MarinaK]

Да, спасибо, статейки про Duwamish Online application знакомы.
И хотя они про и для Web-приложения, можно что-то транспонировать частично.
А опытом никто не хочет поделиться? Наработками, соображениями...