Як провести тестування навантаження: що потрібно знати та якими інструментами користуватися

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

Мене звати Андрій Кушлак, я QA-спеціаліст в NIX та спікер IT-конференції NIX MultiConf. Сьогодні я розповім, для чого використовується навантажувальне тестування і на що варто звернути увагу початківцям. Також наведу кілька типових проблем, з якими я стикався як тестувальник, та поясню, як їх вирішити.

Зміст

1. Коли необхідне навантажувальне тестування
2. Мета навантажувального тестування
3. Що потрібно знати QA-спеціалісту
3.1 Інструменти для написання скриптів
3.2 Знання мов програмування
3.3 Знання архітектури застосунку
3.4 Знання систем CI/CD-процесу
3.5 Розуміння бізнес-значення і головних функцій продукту
4. Інструменти для навантажувального тестування
4.1 Сервісні інструменти
4.2 Браузерні інструменти
5. Де можна отримати більше знань про навантажувальне тестування
6. Висновок

---

Коли необхідне навантажувальне тестування

Припустимо, що команда розробників створила сайт для клієнта. Але за деякий час він повернувся та пожалівся на невисоку швидкість завантаження сайту — і попросив це виправити.

Розробники проаналізували ситуацію та виявили, що на сервері замало ресурсів. Коли сайт відвідувало мало користувачів, це не було проблемою. Проте згодом сайт став популярнішим, а ресурси залишились на базовому рівні. Через це швидкість роботи сайту знизилася.

Щоб уникнути такої проблеми у майбутньому, розробники вирішили проводити спеціальні тести і перевіряти проєкти на перфоманс. Так і з’явилося навантажувальне тестування.

В моєму житті все було саме так. Одного разу проєкт, яким займалася наша команда, почав рости, і замовник повідомив: деякий функціонал вже не працює або працює погано. Врешті 20% користувачів були незадоволені застосунком.

Проблема полягала в нестачі ресурсів. Ця ситуація дала поштовх для створення нашого першого навантажувального скрипту. Потім був другий, третій, п’ятий — і все трансформувалося в повноцінний напрям у вигляді навантажувального тестування.

У нас сформувалася команда, яка знаходила проблеми і повертала проєкт на доопрацювання з оптимізацією коду, архітектури тощо.

Мета навантажувального тестування

• Переконатися, що застосунок однаково якісно працює як з одним, так і з безліччю користувачів. При цьому час запиту від юзера до сервера і назад не має змінюватися. Щоправда, в реальному житті він все одно змінюється. Тому необхідно перевірити, що зміни не настільки критичні, щоб дратувати користувачів.
• Перевірити працездатність застосунку під значним трафіком. Сайт чи застосунок під навалою великої кількості користувачів не повинен постійно перезавантажуватись та крутити спінери. Яскравий приклад — коли інтернет-магазин розпочинає акцію зі знижками на всі товари. В такому випадку трафік може зрости, припустимо, з 10000 до мільйона користувачів. А це може критично вплинути на перфоманс. Спеціалісти з навантажувального тестування мають перевірити, як сайт поводиться за таких умов.
• Оцінити якість роботи застосунку при нормальному навантаженні. Наведу приклад з власної практики. Маємо хмарний застосунок на мікросервісах, в одному з яких на тестах знайдено проблему. Цей мікросервіс перезавантажувався за тиждень п’ять разів без зрозумілих причин. Проаналізувавши ситуацію, ми виявили, що розробники так «оптимізували» код, що кожен запит від клієнта до сервера зберігався в оперативній пам’яті. Для сервісу було виділено 2 ГБ: по одному для нього та для кешу. І хоча кожен запит займав дуже мало місця, після мільйона таких запитів кеш переповнювався. Через це сервіс не міг обробляти значний обсяг даних і був змушений перезавантажуватися для очищення кешу.

Що потрібно знати QA-спеціалісту

Інструменти для написання скриптів

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

На одному проєкті ми використовували Gatling — гарний інструмент, який нам підходив на 100%. Проте замовник попросив додати нову функцію в проєкт. І для неї ми не змогли з цим інструментом написати навантажувальний тест. Gatling працює на HTTP, а нова функціональність — на MQTT.

Сам інструмент може працювати із цим протоколом, але тільки в платній версії (ми ж використовували безкоштовну). Як би ми не прикручували бібліотеки чи плагіни, ми могли це запустити, але результати були б поганими. Тому довелося шукати нові інструменти для цього функціоналу. В результаті всі скрипти ми написали на Gatling та один — на мові Golang.

Знання мов програмування

Звичайно, всі інструменти мають документацію з описом, як правильно працювати з ними, як можна застосовувати ті чи інші методи, які є фішки.

Але бувають моменти, коли треба все одно писати самому: генератори даних, плагіни для покриття певного функціоналу тощо. Для цього достатньо знати мову на середньому рівні, щоб самостійно писати тести.

Якщо у вас не виходить написати щось самому, можна звернутися до команди розробки. Бажано, щоб ваш інструмент мав ту саму мову, на якій створюється застосунок. Це дає можливість працювати спільно з девелоперами. Розробники зможуть допомогти із написанням генератора чи бібліотеки, показати правильну структуру проєкту та розказати про best practices. Так їм буде не тільки простіше, але й цікавіше.

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

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

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

Знання архітектури застосунку

Ви маєте розуміти, як запит іде через інтернет, файрвол чи оболонки мікросервісу та повертається до користувача. Так ви зможете спрогнозувати, де погіршився перфоманс запиту і де були втрати часу на обробку та доставку до якоїсь точки.

В нашій практиці ми також переконалися у важливості подібних знань. Після появи помилок в одному застосунку в логах ми знайшли лише 30% відправлених запитів. Помилки були у форматі таймаут. Тобто запит йшов на сервер, ставав у чергу на обробку, певний час не міг дочекатися відповіді, а тому відвалювався. Необхідно було розібратися, чому немає цих помилок у логах.

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

Коли ми тестували все на маленьких навантаженнях, не було жодних проблем. Однак на великих — скрипт не міг опрацювати такий потік запитів і ставив їх у чергу. В результаті черга розросталася настільки, що не могла дочекатися відповіді. Тож ми попросили девопсів пофіксити цей момент.

Знання систем CI/CD-процесу

Ці системи доставляють код від розробників на сервер (тестовий або сервер клієнта). Працюють вони не лише з кодом. За допомогою CI/CD ви можете писати автотести, перфоманс-тести та будь-які інші.

Спочатку ми запускали перевірки локально на робочих комп’ютерах, але так неможливо вижати стільки ресурсів, щоб серйозно навантажити деякі мікросервіси. Більше того, при великому навантаженні закінчувалися ресурси комп’ютера. Тому ми зробили і додали в проєкт Jenkins job на сервері та почали на ньому запускати тести.

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

Розуміння бізнес-значення і головних функцій продукту

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

Функцій у застосунка може бути 500, а протестувати необхідно лише п’ять, тому що вони найважливіші та критичні.

У якості приклада згадаймо роботу банківської системи. Коли ви оформлюєте картку, вам створюють рахунок, і ви можете робити транзакції в своєму застосунку. Якщо клієнтів мільярд, стільки ж буде запитів на створення акаунту. Але ж вони стартують не одночасно, а за деякий період. Після одного інший профіль клієнту не потрібний. Запит одноразовий, а відкриття картки відбувається раз на 3-5 років. Однак потім йдуть мільярди запитів транзакцій — і це головний функціонал застосунку. Тому потрібно уважно тестувати саме ці функції, а інші — достатньо прогнати раз і переконатися, що проблем немає.

Інструменти для навантажувального тестування

Для цього різновиду тестування існує безліч інструментів. Кожен із них перевіряє щось своє: бази даних, ресурси, мережу на пропускну здатність тощо. Ми ж тестуємо насамперед дві речі — сервіси і візуальну частину (назвемо її браузерним перфоманс-тестуванням). Що ж нам необхідно для роботи?

Сервісні інструменти

Jmeter

Передусім це Jmeter — він дуже популярний і використовує мови Java та Groovy. Ця тулза дуже проста, бо візуальна. Ви відкриваєте проєкт та у віконці блоками виставляєте, як буде йти запит і що будете робити. Потім треба вписати URL і дані, які потрібно передати для відправлення та перевірки, та забрати дані з відповіді мікросервісу.

Тут непотрібно багато знань з програмування — можна самому створити банальні скрипти. Jmeter має велику кількість бібліотек та плагінів і може тестувати все:

• візуальну частину;
Курс Job Interview Crash Course від Enlgish4IT.
Отримайте 6 шаблонів відповідей на співбесіді, які ви зможете використовувати для структурування своїх відповідей. Отримайте знижку 10% за промокодом ITCENG.
Приєднатися
• бекенд;
• бази даних;
• MQTT.

У нашій команді за допомогою Jmeter ми написали 5-10 скриптів, а потім перейшли на Gatling.

Gatling

Gatling створено на базі мови Scala, він скриптовий. Тому тут вже необхідно писати код. Для нашої команди цей інструмент виявився кращим в експлуатації, адже в нас багато скриптів і важливо їх підтримувати для фіксу проблем.

Наприклад, у проєкті змінилася логіка отримання авторизації. Якщо було б 50 скриптів, то з Jmeter потрібно пройти по всім для правки одного URL. Зі скриптовим Gatling достатньо написати одну функцію для логіну та отримання авторизації і змінити URL в цьому методі, щоб інші тести працювали, як слід. Дуже приваблива альтернатива.

Locust

Хоча ще є Locust — достатньо популярний скриптовий інструмент на Python, який в цілому виконує ті ж функції, що й Gatling.

Браузерні інструменти

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

• коли з’являється перший контент;
• коли можна клікнути на елементи сторінки;
• коли сторінка повністю готова до роботи з користувачем;
• скільки сторінка завантажувалася тощо.

Google Lighthouse

На перше місце я би тут поставив Google Lighthouse. Він є в будь-якому браузері. Для генерації репорту вам достатньо зайти на сторінку, натиснути F12 або відкрити інструменти розробника, знайти вкладку Lighthouse і там натиснути кнопку Generate Report.

У Google Lighthouse використовується кольорова палітра з червоним маркером для позначення критичних результатів, жовтим — для поганих та зеленим — для хороших.

Також цей інструмент має базу знань для аналізу. Завдяки цьому звіт одразу показує, де виникла проблема, і пропонує варіанти її вирішення.

Наприклад, у нас в одному проєкті файл зі CSS-стилями був завеликим. Програма підказала розбити його на 3-5 частин. Так завантаження йде паралельно, що заощаджує час. Або, скажімо, маленьке за пікселями зображення важило 2 МБ. Інструмент запропонував зменшити файл, щоб виграти в швидкодії браузера. Сам звіт можна віддавати потім розробникам, щоб вони вирішили, що варто пофіксити в першу чергу.

Speedtest.io

Наступний інструмент — Speedtest.io. Є два варіанти його використання:

1. На офіційному сайті, де можна вставити URL та отримати звіт. Однак це не підходить, коли потрібно просканувати сторінку авторизованим користувачем.
2. Інший варіант — завантажити і запустити тулзу на локальній машині та написати скрипт подібно до UI-автоматизації на JavaScript. Цей скрипт буде відкривати браузер, проходити логін-етап і ходити по сторінках.

Цікаво, що Speedtest.io може заміряти цей час та аналізувати лише вказані сторінки або ж вимірювати весь час. Тобто замість того, щоб з Lighthouse перевіряти окремо кожну сторінку (яких може бути безліч), ліпше створити один скрипт та проганяти його по всіх сторінках для одного великого звіту.

Інструмент також передбачає логіку аналізу, яка підкаже проблемні місця. Хоча їх завжди можна подивитися по метриках.

Webpagetest.org

Webpagetest.org має певні відмінності від двох попередніх. Ця тулза виконує такі ж функції, що і Speedtest.io. Ви можете тестувати сторінки через URL або скрипти. Також є інтеграція з Google Lighthouse — через нього можна згенерувати звіт.

Однак цей інструмент є сервісним. Тому якщо ви хочете автоматизувати отримання звітів, вам треба відправляти запити на сервіс і запитами ж потім отримувати звіти. А це зазвичай не дуже зручно.

Де можна отримати більше знань про навантажувальне тестування

Я розділяю знання на дві категорії: загальні та проєктні:

• Загальні — це інструменти, мови, гайдлайни, теорія тестування.
• Проєктні — це ті знання та навички, які можна отримати під час роботи з конкретним застосунком. Тобто розібратися, який у нього функціонал та як він працює.

Загальні знання

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

Інше джерело загальних знань — це воркшопи. Тут вже навпаки: мінімум теорії та море практики. Вас навчать правильно писати тести, ви дізнаєтеся про нові інструменти і спробуєте з ними працювати, вам дадуть тестове середовище для старту тестів, вивчення звітів чи навіть спроб покласти сервер, щоб ви побачили, як це відбувається в реальності.

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

Серед прикладів подібних видань можу порекомендувати The Art of Application Performance Testing by Ian Molyneaux та The Hitchhiking Guide To Load Testing Projects – A Fun, Step-by-Step Walk-Through Guide by Leandro Melendez.

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

Можу навести наступні приклади таких книг: Performance Testing Guidance for Web Applications by J.D. Meier, C. Farre, P. Bansode, S. Barber, D. Rea або Systems Performance Enterprise and the Cloud by Brendan Gregg.

Проєктні знання

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

Цими ж знаннями з вами можуть поділитися люди, залучені до проєкту. Передусім це замовник або бізнес-аналітик, інколи — тестувальник. Вони можуть загалом розповісти, як працює застосунок, які основні та допоміжні функції в ньому, навіщо взагалі потрібен цей проєкт. Багато знань надасть і команда розробки. Девелопер детально пояснить, як працює щось конкретне.

Наприклад, якщо ви запитаєте бізнес-аналітика про відправку листа про реєстрацію на сайті, він відповість приблизно так: «Заходимо в застосунок, відкривається форма, ми її заповнюємо, тиснемо кнопку “Відправити” — і на email приходить лист “Вітаємо, ви зареєструвалися на сайті”».

Коли ж ви з таким питанням звернетеся до розробника, відповідь буде більш обширною, технічною: запит потрапляє на мікросервіс та зберігається в базу, генеруються дані, потім вони відправляються на email-сервер, який бере шаблон листа та формує його із заданими зображенням та текстом, відправляє їх на Gmail, де відбувається аналіз та перевірка на інфіковані файли, а після валідації зберігається лист — і в папці «Вхідні» з’являється позначка +1.

Раджу вам як тестувальнику балансувати між пошуком знань про проєкт від бізнес-аналітика та від девелопера.

Замість висновку

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