Мій «Шлях джедая» у навантажувальному тестуванні

Привіт, мене звати Олена Швець — QA Tech Lead Engineer у MobiDev, із загальним досвідом роботи у 6 років. Тривалий час працювала в ігровій індустрії, а також маю значний досвід роботи на проєктах, які стосуються соціальних мереж. Під час роботи над одним із них виникла необхідність у проведенні тестування навантаження. Це був цікавий досвід, яким я ділюся у цій статті.

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

Welcome у світ тестування навантаження!

Новини від клієнта

«3000. Ні, краще 5000 користувачів!» — Якось почули ми від клієнта разом із новиною, що він планує залучати до нашого додатка активних користувачів.

Що спадає перше вам на думку, коли ви чуєте про збільшення кількості користувачів у додатку від 170 до 5000? Які фічі зацікавлять цих користувачів або з яких платформ буде більше завантажень? Безумовно, це — важливі моменти. Але першою думкою має бути те, аби не впав сервер.

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

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

Через 8 місяців роботи над поліпшенням програми з боку клієнта було прийнято рішення провести велику маркетингову кампанію, яка полягала у збільшенні користувачів до 20 000. І це була не єдина цифра, яка бентежила нашу команду — на все було виділено 1-1,5 місяця.

Планування

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

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

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

План був таким:

1. Вибрати фічі для навантажувального тестування та пріоритезувати їх.
2. Визначитися з інструментами для проведення навантажувального тестування.
3. Скласти план та провести естімації.
4. Створити окреме оточення для тестування.
5. Провести мануальне тестування, щоб перевірити, чи все добре з фронтовою частиною програми під час роботи з великою кількістю користувачів. І пофіксити баги.
6. Скласти тест-план і перевірити навантаження на невеликій кількості користувачів (10-20). Пофіксити баги, що виникли.
7. Провести перевірки для більшої кількості користувачів, поступово збільшуючи навантаження на сервер і пофіксити баги, що виникли.
8. Зрозуміти, яка максимальна кількість активних користувачів може «витримати» нашу програму.
9. Надати звіт клієнту.

Інструментом для навантажувального тестування був обраний Apache JMeter. Його функції дозволяють провести перевірки у стислі терміни та й тестові сценарії досить легко підтримуються в актуальному стані, що стане нам у пригоді якщо знадобиться тестувати повторно.

Налаштування перед початком

6 тижнів до дедлайну. Наша команда працювала паралельно — з боку QA склали план перевірок та естімації, а команда бекенду спільно з девопсом розгорнули нове оточення. За замовчанням тестове оточення не розраховане на роботу з великим об’ємом даних, що відправляються на сервер.

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

А також додали 20 000 користувачів, які стали нашими віртуальними піддослідними.

5 тижнів до дедлайну. Тест-план готовий та узгоджений, оточення розгорнуте. І ми почали проводити мануальні перевірки.

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

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

Настав час фіксувати перші баги, а мені — прописувати тест-план у JMeter для перших навантажень.

Пам’ятка № 1: Завжди перевіряй пейджинацію на списках. Іноді невелике непорозуміння у вигляді її відсутності може «покласти» програму і дуже засмутити користувача.

Перші перевірки при низькому навантаженні

4 тижні до дедлайну. Поки перші баги фіксилися на стороні додатка, в JMeter розгорнувся тест-план узгоджених фіч. Руки «свербіли» виконати перші перевірки для невеликої кількості користувачів.

Тест-план складався з 6 груп.

• Login.
• Follow/Unfollow сутності 1.
• Create/Delete сутності 2.
• Join/Left сутності 3.
• CRUD з даними сутності 4.
• Discussion (робота з чатами — найпідступніше і найцікавіше для тестування).

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

Але для першопрохідця все найцікавіше було попереду — як сюрпризи з боку сервера, так і зі сторони JMeter.

Збільшення навантаження, кількості помилок та пошуки їхнього вирішення

4 тижні до дедлайну. Ми почали збільшувати потужності та кількість користувачів. Для початку проводили перевірки щодо кожного треду окремо. Тести 10, 25, 50, 100, 200 користувачів — все працювало досить непогано. Логін відпрацьовував «як годинник», але «дива» почалися під час навантаження інших сутностей — частина перевірок просто видавали 500-ті помилки на 300 користувачах. Перед тим, як бити на сполох, я вирішила, що варто подивитися налаштування тред-груп.

Увага на скриншот, шановні знавці. Припустимо, що в тред-групі послідовно виконуються 5 запитів, за умови роботи 300 користувачів із затримкою в 1 секунду. Чи будуть запити працювати як слід?

Відповідь — ні, сервер повертатиме помилки.

Пам’ятка № 2: Якщо збільшується кількість користувачів, потрібно звертати увагу на Ramp-up period і давати можливість серверу встигати все в межах допустимого часу. Тобто поганим і малореалістичним буде сценарій, де ми даємо для одного користувача одну секунду на виконання, припустимо, 5 запитів, які містять у собі різний набір даних (за кількістю параметрів, що відправляються) в межах однієї тред-групи.

Перевірки стали фейлитися менше після того, як було збільшено ramp-up period. Його величина була визначена за допомогою вимірів часу на виконання сценаріїв, що перевіряються мануально — середнє значення між часом на виконання запитів з обов’язковими і всіма параметрами.

Після збільшення ramp-up period помилок стало менше, але вони все ще виникали. Якщо звернути увагу на треди, які були виписані вище та подумати, що могло піти не так, то загалом помилка може стати очевидною.

Візьмемо за приклад усім відому соціальну мережу — Instagram.

➖ Зосередимо у межах однієї тред-групи послідовні перевірки:

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

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

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

У нашому випадку для 300 користувачів був прийнятний і реалістичний Ramp-up period у 30 секунд, тобто для подальших перевірок мінімальне співвідношення кількості користувачів до Ramp-up period було — 10 до 1.

Настав час підключати кілька тредів до роботи одночасно.

3 тижні до дедлайну. Навантаження з 300 користувачів у кожному з тредів, одночасно запущених для перевірок, дало свій результат — посипалися 500-ті помилки. Сервер не витримав навантаження з одночасною роботою 1800 користувачів. Розпочалася робота на боці бекенд-команди з оптимізації запитів.

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

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

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

Наша пісня гарна й нова — починаймо її знову. Бекенд-команда заново взялася за роботу з усунення помилок. Водночас я почала шукати треди, які можна покращити.

Пам’ятка № 5: Якщо в перевірках є параметри, які можуть генеруватися або вибиратися рандомно, користуємося цією можливістю і підключаємо рандом. Це може бути: надсилання текстових повідомлень, генерація назв сутностей, робота з надсиланням медіа і т.д.

Повернімося до прикладу Instagram і флоу створення посту. Пост складається базово з медіа та тексту. Для таких випадків і можна використовувати рандом:

• Попередньо підготуємо медіа і текст, з якими працюватимемо в майбутньому.
• Для медіа потрібно вибрати кілька фото і відео різних форматів і розмірів, що підтримуються. Вони можуть зберігатися локально на ПК або в хмарному сховищі проєкту (другий варіант краще з огляду на роботу з тестами для всіх членів команди). Потім необхідно вказати шлях до зберігання цих файлів у HTTP Request та зазначити ім’я параметра, вказуючи його умовний id (media_id):

• Для тексту відмінно підійде словник або власний текст, який можна покласти в змінну (але пам’ятайте про цензуру — не варто забувати, що все, що потрапляє на сервер, а потім і до самої програми, може бути доступне іншим членам вашої або клієнтської команди).
• Під час виконання запиту замість дефолтних параметрів для кожного користувача з допомогою прописаного скрипта в PreProcessor ми будемо відправляти рандомно обране медіа чи набір слів/ фраз з масиву тексту.

У випадку з текстом — достатньо в скрипті використовувати функцію, яка розбиватиме рядок (наш текст) на підрядки та, застосовуючи функцію рандому, обиратиме будь-яку з них і надсилатиме, як параметр у тілі запиту.

У випадку з медіа — використовуємо функцію рандому, що генеруватиме число від нуля до загальної кількості медіа, які ми використовуємо в тестуванні. Після цього підставляємо згенероване число як id в ім’я змінної медіа (media_randomId), та передаємо її як параметр у тілі запиту.

Отже, ми використовуємо для кожного нового користувача рандомний текст або медіа, не засмічуємо сервер однаковими за «вагою» запитами та отримуємо різноманітність контенту.

Пам’ятка № 6: При роботі з рандомом варто звернути увагу як на реалізацію через мову скрипта, якою ви пишете, так і на стандартну функцію рандому в JMeter:
$ {__ Random (p1, p2, p3)}, де P1 і р2 — нижня і верхня межа випадкового числа відповідно, а р3 — ім’я змінної, де буде зберігатися випадково обране число.

2 тижні до дедлайну. Терміни підтискають, команда намагається вивести роботу програми на новий рівень.

З боку бекенда проведене дослідження, оптимізовані запити для роботи чатів, а також переглянуто налаштування сервера та тарифних планів.

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

На скрині приклад тарифів AWS, з якими працює багато проєктів

При зростанні навантаження на сервер, збільшується обсяг оперативної пам’яті, CPU і т.п. Таким чином, зі збільшенням навантаження з’являється потреба в підключенні додаткових потужностей і відбувається перехід на наступний тарифний план (m10, M20, т. д.), а також підключаються додаткові сервери.

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

Після узгодження цього з клієнтом (адже тарифи — не безплатні), ми продовжили наші перевірки.

Єдине «але» — для того, щоб виконати перехід на новий тариф та під’єднати додаткові потужності, потрібно виконувати навантаження на сервер безперервно з поступовим збільшенням протягом певного часу. І тут на допомогу приходить наступна пам’ятка.

Пам’ятка № 7: Подумав про сервер — не забудь подумати про свою робочу станцію. Щоб не перевантажувати CPU свого комп’ютера, слід запускати тести не з JMeter GUI, а з консолі, не забуваючи зберігати результати тестів у файл для проведення аналізу.

Протягом 3 днів ми безперервно навантажували сервер, запускаючи всі треди одночасно. У кожному з них було від 500 до 1500 користувачів. Помилки могли виникати тільки в той час, коли додаткові сервери підключалися для допомоги. І після закінчення 5 тижнів тестування та оптимізації ми вийшли на стабільність у роботі з 3000-9000 користувачів.

Результат зробленої роботи

1 тиждень до дедлайну. Протягом останнього тижня саме тестування припинилося. Ми надали звіти щодо виконаної роботи клієнту і зійшлися на тому, що навантаження в 9000 активних користувачів при запланованому зростанні до 20 000 зареєстрованих — дуже хороший результат, якого ми змогли досягти в стислий термін. Для підсумкових звітів ми використовували ті, що генерувалися протягом останнього дня тестування.

Для більш наочного результату можна було б додатково під’єднати Grafana, яка б надала інтерактивну візуалізацію для аналітики. Але нашому клієнту було достатньо побачити текстові звіти.

Пам’ятка № 8: Якщо хочеться наочніше надати звіти клієнту, слід поєднувати графічні звіти, які можна генерувати в самому JMeter, візуалізацію звітів у Grafana і табличні звіти від JMeter.

Взято з офіційного сайту Grafana.com

У результаті ми впоралися з поставленим завданням за 6 тижнів і показали досить добрі результати роботи програми. Реліз пройшов, після завершення першої маркетингової кампанії кількість активних користувачів зросла до 8000. Програма працювала як годинник, а клієнт і наша команда були задоволені роботою.

Ми виконали гарну роботу, зловили та пофіксили цікаві помилки. Мною був пройдений невеликий, але справжній «шлях джедая». Звичайно, якби ми мали більше часу на підготовку та проведення навантажувального тестування, багато труднощів, які виникли, могли б не статися. Проте тоді я не зібрала б таку колекцію корисних пам’яток.

Зрештою, ми стали тими нестандартними самураями, для яких був важливим не лише шлях, а й мета. А мети, як ви вже зрозуміли, було досягнуто.