Разумно ли иметь критерии прохождения / провала для стресс-теста?

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

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

Теперь у меня есть другие тесты производительности для тестирования системы при ожидаемой нагрузке и т. Д., Для которых я легко могу установить критерии прохождения / сбоя, и я мог бы использовать эти критерии в качестве основы для своего стресс-теста. Другими словами, я мог бы установить минимальный базовый уровень для моего стресс-теста, но я не уверен, что это правильно (это «дублирует» мой другой тест?).

Я надеюсь, что кто-то с большим опытом в тестировании производительности может помочь мне здесь. Какие критерии прохождения / провала использовали другие при стресс-тестировании (если есть)?

В стресс-тесте ваша задача не определить стресс, который должен выдержать субъект. Это измерить стресс, который требуется, прежде чем он терпит неудачу.

Вы можете использовать критерии производительности, чтобы определить, что такое стресс-провал. Но результат стресс-теста не проходит / не проходит. Он «вышел из строя через 90 часов при 100% загрузке с нарушением вентиляции на 50%».

Это зависит от требований, если ваши требования указывают, что ожидаемый результат для производительности приложения - это X, а на самом деле вы получили Y, так что это Fail.
Если у вас нет определенных требований, вы можете подвергнуть свою систему стрессу и собрать граничные данные, а затем выяснить и документировать эти ограничения.

Вы можете легко обновить свой первичный стресс-тест, чтобы он также поддерживал проверку на прохождение / провал QA, что-то вроде «возможность достичь / выдержать нагрузку Х без поломок». В идеале X настраивается (например, для разных веток релиза).

Результат будет, failесли система сломается до того, как нагрузка достигнет X, и passесли она не сломается. Вам просто нужно прекратить увеличивать нагрузку, как только она достигнет значения X в сценарии «сустейна».

ИМХО такой автоматический тест может быть очень полезен в контексте CI / CD, особенно в производственных отраслях.