Перейти к содержимому

Chrome DevTools: Инструменты тестировщика
онлайн, начало 27 февраля
Английский для тестировщиков
онлайн, начало 2 марта
Школа для начинающих тестировщиков
онлайн, начало 27 февраля
Git: инструменты тестировщика
онлайн, начало 27 февраля
Фотография

Стресс-тестирование


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 28

#21 Guriy

Guriy

    Опытный участник

  • Members
  • PipPipPipPip
  • 316 сообщений
  • Город:Киев, Украина

Отправлено 22 Февраль 2005 - 11:26

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

#22 Куатор

Куатор

    Постоянный участник

  • Members
  • PipPipPip
  • 247 сообщений
  • ФИО:Комендантов Илья
  • Город:Украина, Одесса

Отправлено 27 Август 2010 - 10:49

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

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

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

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

#23 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 27 Август 2010 - 11:07

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

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

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

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

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

#24 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 830 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 27 Август 2010 - 11:52

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

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

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium


#25 Troubleshooter

Troubleshooter

    Опытный участник

  • Members
  • PipPipPipPip
  • 398 сообщений
  • Город:Киев

Отправлено 30 Август 2010 - 20:52


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

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

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

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

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


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

#26 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 31 Август 2010 - 09:08

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

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

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

#27 Куатор

Куатор

    Постоянный участник

  • Members
  • PipPipPip
  • 247 сообщений
  • ФИО:Комендантов Илья
  • Город:Украина, Одесса

Отправлено 07 Сентябрь 2010 - 07:24


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

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

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

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


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

#28 Куатор

Куатор

    Постоянный участник

  • Members
  • PipPipPip
  • 247 сообщений
  • ФИО:Комендантов Илья
  • Город:Украина, Одесса

Отправлено 07 Сентябрь 2010 - 07:31

На мой взгляд, почти все не так. Стресс тестирование - это пункт №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.

Забавно, что эту статью в википедии я не читал ранее, может стоило :)
  • 0
Идеальный тестировщик - человек с золотыми руками, растущими из ж...

#29 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 830 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 07 Сентябрь 2010 - 19:32

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

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

Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium



Практикум по тест-дизайну 2.0
онлайн
Школа для начинающих тестировщиков
онлайн
Школа тест-аналитика
онлайн
Техники локализации плавающих дефектов
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале