Навантажувальне тестування: кому потрібне, основні інструменти та сценарій. Досвід FavbetTech

До певного періоду часу performanсe-тестування в FAVBET Tech не вважали найпріоритетнішим завданням. Іноді це призводило до того, що коли до команди QA потрапляли запити на проблеми через навантаження, їх обробляли фахівці, які лише частково орієнтувалися в напрямі.

Зараз під performance-тестування в компанії виділили окрему команду, а визначення, чи буде новий сервіс частиною highload-інфраструктури, є обов’язковим завданням кожного девменеджера.

Як будувалися ці процеси і як вони працюють зараз, у партнерському інтерв’ю про highload-системи розповідає QA Manager з FAVBET Tech Ігор Гунько.

Що таке тестування навантаження та кому воно потрібне

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

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

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

Найпопулярнішими є такі види цього напряму:

1. Навантажувальне тестування (load testing). Це перевірка системи в очікуваному навантаженні. Наприклад, вона має витримувати на хвилину 50 тис. авторизацій користувачів. Тож ми генеруємо цю кількість і перевіряємо, чи видасть сервер успішну відповідь у вигляді якоїсь вебсторінки. При цьому load-тестування завжди зводиться до коротких проміжків часу. Тобто у нас є якась цифра (наприклад, кількість циклів) і ми маємо її обробити за короткий проміжок часу (наприклад, хвилину або годину).
2. Стрес-тестування (stress testing). Це перевірка системи вище очікуваних навантажень. При цьому дивляться на два основні показники. Перший – під яким навантаженням і де саме починаються перші збої в системі. Другий – при яких умовах буде повний відказ системи або вона почне масштабуватись, а саме додасть оперативної пам’яті або збільшить кількість процесорів тощо.
3. Тест на стабільність (stability test). Це те саме, що й load-тестування, але на довгому проміжку часу: від доби до кількох днів. При цьому не вимірюють швидкість відповідей або інші кількісні показники, але дивляться, як поводиться система з огдяду на ресурси. Скільки використовує пам’яті, чи не виникає черг у сервісах тощо. Завдяки цьому можна спрогнозувати, які hardware-ресурси будуть потрібними за пів року – рік.
4. Об’ємне тестування (volume testing). Відрізняється від попередніх тим, що контролює обсяги даних, під якими виконується навантаження. Наприклад, ми перевірили, що система дозволяє користувачу завантажувати файли, а далі починаємо потроху їх збільшувати: не кількість, а сам обсяг. Як-от, ті самі 10 файлів, але не 1 МБ кожен, а 5 МБ. Потім 10 МБ тощо.

Чому для performance-тестування у FAVBET Tech виділили окрему команду

Компанія FAVBET Tech дуже виросла, і з цим пов’язано багато внутрішньої перебудови: структурної й технічної. Це вплинуло і на підходи до performance-тестування.

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

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

Інколи performance-тестувальники доєднуються до роботи паралельно з розробкою, щоб встигнути зібрати дані та підготуватися до тестування. Тобто раніше performance-тестувальники йшли до розробників, а зараз – навпаки.

Тестуванням навантаження займається команда із цього напряму. Вона невелика, складається із двох інженерів, але повноцінна та самодостатня для наших поточних потреб. Наша команда QA Performance є частиною QA-відділу, але вони вузькопрофільні фахівці. Це щось середнє між DevOps, розробником та іноді QA Automation. Це люди, які вміють програмувати, знають інструменти для проведення навантажувального тестування і розуміють специфіку того, як працюють highload-системи.

Правильно побудовані процеси дозволяють їм паралельно виконувати завдання для двох-трьох різних команд. Зазвичай це від чотирьох до шести запитів на місяць від різних сервісів платформи.

Як працює performance-тестування у FAVBET Tech

1. Робота починається з опитування. У FAVBET Tech є сформовані опитувальники для нових сервісів і тих, що ми вже тестували. Їх заповнює команда розробки, надаючи performance-тестувальникам достатню картину для того, щоб проаналізувати вимоги та почати створювати тестовий сценарій.
2. Заготівля драфтового сценарію тестування. Він погоджується з девкомандою. Це необхідно для того, щоб у нас був швидкий фідбек, чи це те, що потрібно. Як ми знаємо, не завжди продукт може відповідати кінцевим вимогам замовника, тому ми намагаємося мінімізувати всі ризики ще від початкового етапу.
3. Коли в нас є драфт, ми його відшліфовуємо та готуємо для попереднього прогону на тестовому середовищісервері. Там ми можемо подивитися, як він працює на якихось мінімальних показниках: дізнатися, яке навантаження треба буде використати на реальному продакшені.
4. Етап планування. Дізнаємося в команди розробки, які в неї зараз є показники за поточними сервісами та чого ми очікуємо. Наприклад, під мінімальним навантаженням оброблення даних займає умовних півтори секунди на користувача. Якщо це буде одночасно 10 тис. користувачів, яка швидкість відповіді має бути? Півтори секунди чи не більше двох? Чи критично вже, якщо буде 3–4,5? Це необхідно, щоб performance-тестування не зводилось лише до пошуку неочікуваних помилок, які можуть виникнути під навантаженням.
5. Збір команди. На простий сервіс необхідно мінімум 3–4 людини. Це завжди представник performance-команди, DevOps (щоб слідкувати за інфраструктурою), представник від замовника (команди розробки) та мануальний тестувальник (щоб перевірити сервіс після навантаження). Додатково може бути фахівець з бази даних і support-інженер.
6. Власне, тестування. Частіше за все проводиться в години, коли всі сплять. Бувають різні типи помилок і цілей, які ми переслідуємо. Performance-тест може знайти або нові помилки, або відтворити старі. Наприклад, ми знаємо, що місяць тому під час якогось матчу була ось така проблема з боку користувачів, а яка саме з технічного боку, що саме було причиною її відтворення (сума факторів) – за логами дізнатися неможливо. Тоді тестувальники намагаються підібрати такі вхідні дані, щоб відтворити  очікувану проблему і в момент відтворення дослідити її детальніше. Коли ж ми тестуємо нові сервіси, це простіше – у нас є конкретні базові показники та конкретні сценарії. При цьому можемо додатково виловити якісь супутні баги і проблеми під навантаженням.
7. Готуємо коротке самарі для менеджменту, який вранці прокинеться та першочергово його прочитає. Туди додають назви сервісів, які були навантажені, і перелік проблем, які були помічені. Можливо, якщо для чогось потрібен детальніший аналіз після проведеного тесту, то ми робимо позначку. Детальний аналіз із зануренням у логіку того, як працював сервіс, займає один робочий день.

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

Які інструменти використовують для тестування highload-систем

Основний інструмент, який ми використовуємо для performance-тестування – це JMeter, оскільки він має широку підтримку протоколів і готових плагінів. Його ми використовуємо давно, тому встигли мінімізувати його недоліки.

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

Якщо якийсь сценарій не вдається покрити JMeter (що буває доволі рідко), тоді використовуємо Grafana k6 – він більш гнучкий і легковісний, оскільки допомагає писати сценарії вручну на JavaScript. Колись була ідея використовувати Locust – там теж можна писати кодна Python, але на той момент у нас не було сформованої команди з навичками програмування цією мовою, тож від ідеї вирішили відмовитися.

Отже, performanсe-тестування є життєво необхідним для таких highload-платформ, як наша. Професійні фахівці + правильно побудовані процеси + розумно налаштована інфраструктура і програмні інструменти для тестування – усе це на 100% дасть лише позитивні результати. А ще вкаже, як можна поліпшити ваші програмні продукти, які неможливо виявити звичайним ручним і автоматизованим тестуванням.

Більше про FAVBET Tech