Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Не баг, а фіча #1. Найбожевільніше тестування навантаження

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт друзі! QA подкаст на DOU отримав круту назву — «Питання якості»!

Але мені не хочеться просто так відкидати інші годні ідеї, тож я вирішив щомісяця писати статтю на DOU, розповідати якусь байку зі свого досвіду та які корисні уроки я вивчив. А також записувати її відео версію (кому як зручніше). І назвати все це вирішив «не баг, а фіча» («соплі тестувальника», чекайте, ваш час ще настане)

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

Історія така: я вже п’ятнадцятий (⚠️) рік працюю в компанії Інфопульс.

Ні, мені не набридло😁

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

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

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

  • Для комп’ютера, з якого проводиться тестування, немає потреби запускати повноцінний браузер для кількох http запитів, достатньо мати http клієнт, що економить багато оперативної пам’яті та процесорного часу
  • Якщо замовник очікує, що застосунком користуватиметься 10 000 користувачів одночасно, кожен з яких виконує 1 операцію на хвилину — немає сенсу створювати 10 000 клієнтів, що роблять 1 операцію на хвилину. Умовно, можна створити 100 клієнтів, що роблять по 100 операцій на хвилину — для додатку результат буде той самий 10000×1==100×100 !

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

А ще мені показали, що я маю тестувати — застосунок по повній використовував FaaS!

Це був другий дуже тривожний дзвіночок! Платформа, на якій він працював — сама гарантувала доступність 24/7 та автоматичне збільшення потужності у разі зростання навантаження. Тест функцій застосунку перетворювався в тест спроможності платформи (що навіть заборонено її правилами). Не впевнений, що такі штуки тестують в класичний спосіб інструментами типу Locust/JMeter.

Урок #1 мені і всім читачам на майбутнє — не ведіться на провокації, як я — робіть тестування навантаження так, як правильно, а не як хоче замовник. Навіть якщо замовник дуже хоче!

В той час я як раз активно вивчав Playwright (браузери), робив відео по Locust (тестування навантаження) і писав для нього плагіни. І звісно ж подумав, а чом би не поєднати ці два крутезні інструменти для вирішення поставленої задачі, тим паче — ресурси необмежені.

Доволі швидко я написав плагін, що створює Playwright Chrome браузери. Вже пізніше я дізнався, що такий є. Протестував, що концепція працює, запустивши локуст з 5 браузерами, і сфокусувався на написанні UI сценаріїв, в яких бачив найбільшу проблему — інтерфейс, що мав бути простестований, був складний і згенерований автоматично з C# коду, а єдиний спосіб аутентифікації був через Microsoft OAuth2.0, з купою додаткових перевірок на роботів (іронія😁) та наданням доступу в iframe’ах. Тому на покриття сценаріїв я витратив тижні півтора, не менше.

Паралельно, я замовив низку потужних серверів для розподіленого навантаження. Зараз не згадаю деталі, але щось типу Intel Xeon по 24 ядра і 128 Гб RAM. Бо проста математика казала — 1 браузер Chrome з однією вкладкою при старті використовує 50 Мб, під час виконання сценарію «віджирає» до 100-150 Мб. Тобто 10 браузерів — 1 гігабайт, 1000 — 100 Гб,а ще CPU активно використовується.

Урок #2 — якщо робите PoC інструменту для тестування навантаження, особливо з саморобними плагінами, перше, що треба перевірити, це навантаження! Банально запустити з 1000 клієнтів (а не 5, як я) і впевнитись, що вони працюють

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

Після не дуже приємної розмови, мене спитали — який план? І на щастя, план в мене був! Я й до цього грався з Playwright в асинхронному режимі, створюючи десятки одночасно працюючих автотестів, тож вирішив відмовитись від Locust і написати власний інструмент з навантаження!

Урок #3 — майте план Б, а краще ще й план В. Трохи пізніше я дізнався, що коли мій PoC провалився, мій керівник терміново знайшов іншу команду тестерів, що почала робити свій власний PoC на основі selenium. Отаке має бути керування ризиками!

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

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

  • Тест не йде нескінченно довго — за 30-40 хвилин пайтон видає Kernel error та вилітає (це я побороти не зміг)
  • Ключова проблема запуску великої кількості браузерів — не пам’ять, як я думав, а процесор. На конфігурації в 24 фізичних ядра більш менш нормально почувались до 300 браузерів (цифра дуже приблизна). Для боротьби з цією проблемою розгортається максимально доступна конфігурація серверу чи то на 64, чи то на 128 ядер та на 512 ГБ RAM. Спойлер ⚠️: на такій конфігурації «живе» до 800 браузерів

Додатково я отримав зауваження, що тести виконуються не згідно сценарію — якщо в вимогах сказано, що користувач 2 натискає кнопку 2 через 15 секунд після того, як користувач 1 натиснув кнопку 1, то тест має робити те саме. Не важливо, що сумарне навантаження на виході відповідає вимогам, тут все має бути як в житті сценарії! Тому довелось в свої тести докрутити додаткове гнучке очікування, як constant pacing в локуст — щоб кожна наступна операція сценарію виконувалась чітко за графіком.

Урок #4 — Наполягайте на об’єктивному тестуванні в контрольованих умовах

Перед фінальним демо, з усім керівництвом замовника, я відшліфував тести, команда підняла більше серверів на випадок збоїв а я отримав acceptance criteria замовника... і вже нічому не дивувався. Виглядали вони приблизно так:

Під час тесту навантаження, замовники проходять тестовий сценарій зі своїх комп’ютерів і секундоміром вимірюють час виконання своїх операцій.

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

  • мережевого підключення людини, що робить тест. Роздали собі 3g з телефону, отримали затримку в 1-2 секунди (наприклад), що робить результат заздалегідь гіршим
  • комп’ютера людини, що робить тест. Взяв робочий ноут 5-річної давнини, без апдейтів, де в браузері вже відкрито 30 вкладок — і потрібна сторінка просто не відкрилась ¯\_(ツ)_/¯ як ти докажеш, що це не провина застосунку?
  • рефлексів людини, що вимірює операції. Тут взагалі жодної об’єктивності. Інструмент може виміряти час з точністю до мілісекунд, а людина... відволікся чи почекав, поки анімації в інтерфейсі пройшли — вже +2-3 секунди

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

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

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

Напишіть, як вам історія? Що б ви робили на моєму місці?

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Прочитав на одному подиху. Історія вимагає продовження :-)

було цікаво, дякую!
але в кінці все ж таки надіявся на розвʼязку в фіналі, а тут тільки висновки(

Що б ви робили на моєму місці?

load-test.io

Scenario Builder — Coming soon
А треба «на вчора». Простий спамер точно не підійде.
Є варіант тесту навантаження з блейзметер, навіть з браузерами, але в необхідних об’ємах будо б задорого

Овва! Так швидко мої пости ще не публікували

Підписатись на коментарі