Що таке навантажувальне (load) і стрес-тестування? Практичний гайд для вебзастосунків

Будь-який застосунок працює нормально, поки ним користується жменька людей. Справжнє питання - що станеться, коли маркетингова кампанія «вистрелить», почнеться розпродаж або аудиторія клієнта подвоїться за три місяці. Навантажувальне (load) і стрес-тестування - це дві дисципліни, які дають відповідь на це питання ще до того, як її на собі відчують ваші користувачі чи інвестори.

Обидва підходи належать до ширшої категорії тестування продуктивності і обидва симулюють трафік на ваш застосунок. Але вони ставлять різні питання, використовують різні патерни навантаження і дають різне розуміння системи. Плутати ці два підходи - поширена помилка, яка змушує команди тестувати не той сценарій.

1. Що таке навантажувальне (load) тестування?

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

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

2. Що таке стрес-тестування?

Стрес-тестування діє навпаки: воно свідомо піднімає трафік вище очікуваного рівня і продовжує його нарощувати, доки система не почне сповільнюватись, повертати помилки або взагалі не відмовить. Мета - не підтвердити нормальну поведінку, а знайти точку відмови і побачити, як саме система ламається.

Чи деградує застосунок «граційно», повертаючи закешовані дані або зрозуміле повідомлення про помилку? Чи він падає повністю, псує дані або тягне за собою базу даних? Стрес-тестування дає відповідь саме на це питання, і часто це єдиний спосіб виявити каскадні збої, які ніколи не проявляються за нормального навантаження.

3. Навантажувальне vs. стрес-тестування: ключові відмінності

Обидва підходи використовують спільні інструменти й методологію, але мають різну мету:

• Мета: навантажувальне тестування підтверджує продуктивність за очікуваного трафіку. Стрес-тестування шукає точку відмови та поведінку системи за її межами.
• Патерн трафіку: навантажувальне тестування використовує стабільне, реалістичне навантаження. Стрес-тестування безперервно нарощує трафік, часто далеко за межі будь-якого реального сценарію.
• Критерій успіху: тест навантаження проходить, якщо метрики залишаються в межах SLA. Стрес-тест «успішний», коли він знаходить точку відмови і підтверджує, що падіння безпечне (без втрати даних, з чітким повідомленням про помилку і відновленням після спаду трафіку).
• Коли запускати: навантажувальне тестування зазвичай проводять перед кожним великим релізом. Стрес-тестування запускають рідше - перед великим запуском, очікуваним сплеском трафіку або після значних архітектурних змін.

4. Ключові метрики для відстеження

Незалежно від того, який тест ви проводите, кілька тих самих метрик показують, чи здорова система:

• Час відповіді / перцентилі затримки: середні значення приховують проблеми - відстежуйте p95 і p99, адже навіть невеликий відсоток дуже повільних запитів здатний зіпсувати досвід реальним користувачам.
• Пропускна здатність: кількість запитів на секунду (RPS) або транзакцій на секунду (TPS), яку система витримує без деградації.
• Частка помилок: відсоток невдалих запитів (тайм-аути, відповіді 5xx) зі зростанням навантаження.
• Використання ресурсів: CPU, пам'ять, з'єднання з базою даних і глибина черг на кожному рівні стеку, а не лише на сервері застосунку.
• Одночасні користувачі / точка відмови: максимальна кількість одночасних користувачів чи запитів, яку система витримує до того, як продуктивність або доступність обвалиться.

5. Популярні інструменти

Не потрібно будувати це з нуля - зрілі open-source та комерційні інструменти покривають більшість потреб:

• k6: сучасний, зручний для розробників інструмент навантажувального тестування, тести пишуться на JavaScript, легко запускається в CI/CD.
• Apache JMeter: давній стандарт як для навантажувального, так і для стрес-тестування, з GUI та підтримкою широкого спектра протоколів.
• Gatling: інструмент на базі Scala, створений для сценаріїв з високою пропускною здатністю, з чіткими, зручними для читання HTML-звітами.
• Locust: Python-фреймворк, у якому поведінка користувача описується кодом, добре підходить для складних, реалістичних сценаріїв.
• Artillery: легкий інструмент на основі YAML, який органічно вписується в проєкти на Node.js та serverless API.

6. Коли запускати такі тести

Тестування продуктивності працює найкраще, коли це звичка, а не разова подія перед великим дедлайном:

• Перед публічним запуском або великим релізом фічі - щоб знайти вузькі місця, поки ще є час їх виправити.
• Перед прогнозованими сплесками трафіку - розпродажем, анонсом продукту, маркетинговою кампанією чи сезонним попитом.
• Після значних архітектурних змін: нова база даних, новий шар кешування, міграція на serverless або нова інтеграція зі сторонніми сервісами.
• На регулярній основі для критично важливих для бізнесу систем - як частина CI/CD-пайплайну, щоб регресії продуктивності виявлялись так само, як і регресії функціональності.

Висновок: чому це важливо для вашого бізнесу

Навантажувальне і стрес-тестування - це не просто пункт у чек-листі QA, а страховка від найгіршого моменту для збою: моменту, коли ваш продукт нарешті привертає увагу. Сторінка оформлення замовлення, яка «вилітає» під час розпродажу, або система бронювання, що падає, коли кампанія стає вірусною, - це реальні втрачені гроші й реальна втрата довіри.

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