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

[Guriy]

Спасибо Дмитрий :)

[Куатор]

Заготовки для стресс-тестирования (поправьте, если что не так):

1) Недостаточно места на диске
2) Недостаточно памяти
3) CPU загружен на 100% другим процессом
4) Обрыв сети (если программа работает с сетью)
5) Выключение питания (или Reset)
6) Остановка/пауза сервера БД
7) Перегруз системы (например сервера DoS-атакой)
...

С 5-м пунктом тесно связан такой вид тестирования как recovery - способность системы восстанавливаться после некорректного завершения работы (как пример, Word).
Как-то так :)

P.S: Целью нагрузочного тестирования обычно является проверка параметров системы под нагрузкой, а перегруз - это уже стресс-тестирование. Например, целью нагрузочного тестирования системы может быть такая проверка : При одновременной работе n-го количества юзеров, время отклика транзакции не превышает какого-то значения.
Какое количество юзеров вообще может выдержать система и хоть как-то ещё работать - это уже ближе к стресс.

[LeshaL]

Заготовки для стресс-тестирования (поправьте, если что не так):

1) Недостаточно места на диске
2) Недостаточно памяти
3) CPU загружен на 100% другим процессом
4) Обрыв сети (если программа работает с сетью)
5) Выключение питания (или Reset)
6) Остановка/пауза сервера БД
7) Перегруз системы (например сервера DoS-атакой)
...

С 5-м пунктом тесно связан такой вид тестирования как recovery - способность системы восстанавливаться после некорректного завершения работы (как пример, Word).
Как-то так :)

P.S: Целью нагрузочного тестирования обычно является проверка параметров системы под нагрузкой, а перегруз - это уже стресс-тестирование. Например, целью нагрузочного тестирования системы может быть такая проверка : При одновременной работе n-го количества юзеров, время отклика транзакции не превышает какого-то значения.
Какое количество юзеров вообще может выдержать система и хоть как-то ещё работать - это уже ближе к стресс.

На мой взгляд, почти все не так. Стресс тестирование - это пункт №7 (возможно №3). Остальное - тестирование надежности/помехоустойчивости (robustness testing).
Разница в том, что система в случае с первого по шестой должна либо как-то работать, либо как-то разумно отказаться работать, либо, как вы сами написали, восстановиться.

[barancev]

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

А если система три дня работала, через неё прокачался мильон транзакций, и для всех кроме одной единственной время отклика в полтора раза ниже заданной планки в 100 миллисекунд, а для одной транзакции на три миллисекунды больше -- результат тестирования отрицательный?

[Troubleshooter]

Заготовки для стресс-тестирования (поправьте, если что не так):

1) Недостаточно места на диске
2) Недостаточно памяти
3) CPU загружен на 100% другим процессом
4) Обрыв сети (если программа работает с сетью)
5) Выключение питания (или Reset)
6) Остановка/пауза сервера БД
7) Перегруз системы (например сервера DoS-атакой)
...

С 5-м пунктом тесно связан такой вид тестирования как recovery - способность системы восстанавливаться после некорректного завершения работы (как пример, Word).
Как-то так :)

P.S: Целью нагрузочного тестирования обычно является проверка параметров системы под нагрузкой, а перегруз - это уже стресс-тестирование. Например, целью нагрузочного тестирования системы может быть такая проверка : При одновременной работе n-го количества юзеров, время отклика транзакции не превышает какого-то значения.
Какое количество юзеров вообще может выдержать система и хоть как-то ещё работать - это уже ближе к стресс.

На мой взгляд, почти все не так. Стресс тестирование - это пункт №7 (возможно №3). Остальное - тестирование надежности/помехоустойчивости (robustness testing).
Разница в том, что система в случае с первого по шестой должна либо как-то работать, либо как-то разумно отказаться работать, либо, как вы сами написали, восстановиться.

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

[Boltick]

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

А вот еще один сценарий. Приложение работает под несколькими серверами в кластере. Вдруг один умер и нагрузка на других мгновенно увеличилась. Чем не стрессовый сценарий?

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

[Куатор]

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

А если система три дня работала, через неё прокачался мильон транзакций, и для всех кроме одной единственной время отклика в полтора раза ниже заданной планки в 100 миллисекунд, а для одной транзакции на три миллисекунды больше -- результат тестирования отрицательный?

Тут стоило бы уточнить:
1) Либо множество разных транзакций (a, b, c, d.. ) и одна из них в течении лоудтеста превышает заданный порог
2) Либо транзакция одна единственная (a), но пробегает миллионы раз, и единожды превысила порог
Всё же формулировка задачи подразумевает второй случай ( я таки прав? :) ), тогда нам стоит обратить свой взор на погрешности измерений Погрешности измерений. Приведённый пример называется "промах":

Грубая погрешность (промах) — погрешность, возникшая вследствие недосмотра экспериментатора или неисправности аппаратуры (например, если экспериментатор неправильно прочёл номер деления на шкале прибора или если произошло замыкание в электрической цепи).

Ну, конечно перевести это дело в привычные термины (возможно, что-то произошло с сетью, может с самой системой). "Промахи" обычно просто отбрасываются. Перформанс Инженер может проинвестигировать проблему, повторить лоудтест, если это не особо затратно (что врдяли :) ), в большинстве случае это лишено смысла.
Если пример всё же подразумевает первый случай, то на каждую транзакцию стоит выставить свой порог, если транзакция "d" несколько тысяч раз пробежала успешно (1,5 раза меньше порога), а один раз случился "промах", смотри случай 2.

[Куатор]

На мой взгляд, почти все не так. Стресс тестирование - это пункт №7 (возможно №3). Остальное - тестирование надежности/помехоустойчивости (robustness testing).
Разница в том, что система в случае с первого по шестой должна либо как-то работать, либо как-то разумно отказаться работать, либо, как вы сами написали, восстановиться.

LeshaL, возможно ты и прав :)
Моё понимание сего действа совпадает (как мне кажется) с автором статьи в википедии.

In software testing, a system stress test refers to tests that put a greater emphasis on robustness, availability, and error handling under a heavy load, rather than on what would be considered correct behavior under normal circumstances. In particular, the goals of such tests may be to ensure the software does not crash in conditions of insufficient computational resources (such as memory or disk space), unusually high concurrency, or denial of service attacks.

Забавно, что эту статью в википедии я не читал ранее, может стоило :)

[barancev]

Лично я придерживаюсь точки зрения, согласно которой все эти разные названия -- от лукавого, и на тренингах своих пытаюсь отучить слушателей говорить разные длинные слова, потому что они умно и солидно звучат. Разные вариации тестирования производительности -- суть разные профили нагрузки. Для некоторых профилей придумали отдельные названия, так исторически сложилось, и так проще общаться. Но при условии, что собеседник понимает, о каком профиле идёт речь. А если не понимает -- надо просто показать ему картинку и сказать: "под стресс-тестированием я подразумеваю вот это".

Можете посмотреть вот эту замечательную статью Алексея Булата, где он пишет ровно про это: http://alexeybulat.b.../blog-post.html
А в википедии -- длинно, пафосно, и совершенно непрактично.