Чи розумно не мати критеріїв проходження / відмови для стрес-тесту


10

Тільки для наочності, стрес-тест, який я написав, стабільно збільшує навантаження на систему, поки не досягне точки розриву. Він теоретично працює нескінченно, але оскільки системні ресурси кінцеві, очікується, що через деякий час він вийде з ладу. У мене очікуване навантаження для системи, але це перевіряється окремо в тесті навантаження . Мета цього стресового тесту - дізнатися, яке навантаження я можу нанести на систему, перш ніж мені потрібно здійснити масштабування.


Я зараз складаю стрес-тест для системи, і мені цікаво, чи є сенс мати критерії проходження / відмови. За характером випробування навантаження стабільно збільшується, поки не досягне точки зламу (тобто не виходить з ладу ). Я, очевидно, заздалегідь не знаю, що таке точка розриву, і тому ніякого очікування навантаження система не впорається (теоретично все одно).

Тепер у мене є інші тести продуктивності , щоб перевірити систему під очікуваної навантаження і т.д., які можна легко встановити PASS / FAIL критерії, і я міг би використовувати ці критерії в якості основи для мого стрес - тесту. Іншими словами, я міг би встановити мінімальну базову лінію для досягнення мого стресового тесту, але я не впевнений, чи правильно це робити (це «дублювання» мого іншого тесту?).

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


1
Якщо у вас немає пропуску / невдачі, чому ви робите тест?
RemcoGerlich

@RemcoGerlich Тож я можу знати межі системи? Це допоможе в плануванні потужностей тощо
Алекс

Я думаю, що планування потужностей - це те, коли ви вирішите, яке мінімальне навантаження має бути в змозі працювати з вашою системою (тож у вас є критерій пропуску пропуску).
RemcoGerlich

@ RemcoGerlich Можливо, у мене змішані умови, але в основному у мене очікуване навантаження (яке тестується окремо), але я використовую цей стрес-тест, щоб визначити, в який момент (тобто кількість користувачів) мені потрібно буде масштабування інфраструктури. Це окремий тест, оскільки зміни в системі можуть змінити навантаження, з якою система може впоратися, що не було видно в тесті навантаження.
Олексій

@ Алекс, немає, у вас не заплутані умови. Ви точно описуєте стрес-тест. Проблема у вас полягає в тому, що немає пропусків / збоїв, пов'язаних зі стрес-тестуванням, тому його не можна легко запустити, використовуючи інструменти "тестування одиниць".
Девід Арно

Відповіді:


10

У стрес-тесті ваше завдання полягає не в тому, щоб визначити стрес, який повинен мати можливість суб'єкт. Це виміряти стрес, який він потребує до того, як не вдасться.

Ви можете використовувати критерії ефективності, щоб визначити, що таке стрес-збій. Але результат стресового тесту не проходить / провалюється. Це "не вдалося після 90 годин при 100% використанні при вентиляції на 50%.


одне питання. Чи повинен стрес-тест спричинити збій системи? Іншими словами. Чи є крах, який ми вважаємо "провалом"?
Лаїв

3
@laiv Стресовий тест повинен викликати стрес. І продемонструйте, як суб'єкт реагує на цей стрес. Якщо це спричинить збої в системі, це слід задокументувати. Стресові випробування повинні спричинити збої та показати, що потрібно, щоб їх викликати. Збій системи - це збій, якщо припустити, що система, що вийшла з ладу, не відповідає її вимогам до продуктивності. Вони зазвичай роблять.
candied_orange

1

Це залежить від вимог, якщо ваші вимоги вказують на те, що очікуваний результат для продуктивності програми - це X і насправді ви отримали Y, значить, це збій.
Якщо у вас немає визначених вимог, ви можете підкреслити свою систему та збирати межі даних, а потім розібратися та виконати ці обмеження.


0

Ви можете легко оновити ваш основний стрес-тест, щоб також підтримувати перевірку проходження / відмови QA. Ідеально, коли X може бути налаштований (наприклад, для різних гілок випуску).

Результатом буде, failякщо система зламається до того, як навантаження досягне X, і passякщо вона не зламається. Вам просто доведеться припинити збільшувати навантаження, як тільки воно досягне значення X у сценарії "підтримка".

Автоматизований тест IMHO, подібний цьому, може бути дуже корисним у контексті CI / CD, особливо у виробничих галузях.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.