Англійська для тестування навантаження k6

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

Ключовий словник

** Віртуальний користувач (ВК) ** Віртуальний користувач — це імітований користувач, який виконує тестовий скрипт одночасно з іншими віртуальними користувачами. Кількість віртуальних користувачів, які працюють одночасно, є основним показником навантаження. Приклад: “Ми підняли до 500 віртуальних користувачів за п’ять хвилин і утримували цей рівень протягом десяти хвилин.”

** Пропускна здатність ** Пропускна здатність в тестуванні навантаження відноситься до кількості запитів, виконаних за одиницю часу, зазвичай виражається як запити на секунду (RPS). Вищий рівень пропускної здатності означає, що система може обробляти більше даних. Приклад: “При 500 VU ми досягли пропускної здатності приблизно 1200 запитів за секунду.”

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

• Приклад: « Ми додали дві секунди часу для роздумів між кожним кроком, щоб зробити сценарій більш реалістичним. » *

** Перцентиль (p95, p99)** Значення перцентилю описують розподіл часу відповіді між всіма запитами. Значення p95, наприклад, означає, що 95% запитів було виконано за цей час. Вони більш значущі, ніж середні значення, тому що вони виявляють хвостову затримку.

• Приклад: “Наша затримка p99 була 780 мс під час пікової навантаження, що знаходиться в межах нашого прийнятного порогу.” *

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

• Приклад: « Завжди виконувати тест димування перед тестом повного завантаження, щоб виявити помилки скриптів на ранній стадії ». *

Поширені сценарії, де використовується ця мова

На зустрічі з планування спринту: Тести продуктивності часто плануються як частина спринту. Ви можете сказати: “Я напишу сценарій k6 для потоку оплати цього спринту і запустю базовий тест перед тим, як ми об’єднаємо нову інтеграцію оплати.”

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

** При піднесенні проблеми з продуктивністю: ** Якщо результати виявлять проблему, вам потрібно повідомити про це чітко і без тривоги. “Затримка p99 на кінцевій точці /api/products піднімається до 3,4 секунди при 300 VU, що втричі перевищує нашу ціль SLO. Я рекомендую нам дослідити запит бази даних перед наступним випуском»

Корисні фрази для обговорень щодо перевірки навантаження k6

• «Я написав тестовий сценарій, який імітує подорож користувача від входу до виходу»
• “Період підйому становить дві хвилини, після чого настає десятихвилинний стабільний стан.”
• Результати показують, що система починає деградувати при більш ніж 400 одночасних віртуальних користувачів
• «Ми бачимо високий рівень помилок при піковій нагрузкі — більшість помилок є 503-ми з верхнього рівня сервісу»
• «Затримка p95 прийнятна, але p99 є проблемою для наших користувачів з найбільшим трафіком»
• «Я запустив димовий тест і сценарій працює так, як очікувалося — ми готові до повного запуску»
• Чи можемо ми запланувати тест навантаження на непікові години, щоб уникнути впливу на виробництво?»
• «Період пориву був порушений на метриці частоти помилок, тому тест зазнав невдачі автоматично.»
• «Я поділюся HTML-звітом — ви можете просунутися в кожну метрику звідти»
• «Ми повинні встановити базу перед рефактором, щоб ми могли порівняти результати»

Читання і презентація результатів k6

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

Для технічної аудиторії: зосередьтеся на затримці p95/p99, частоті помилок і на тому, де в процесі зростання почалася деградація. Для нетехнічної аудиторії: перекладіть числа в вплив — «На нашому очікуваному піку 300 користувачів, середній чек займає 1,8 секунди, що в межах нашої мети»

Під час написання резюме результатів, структуруйте його так: мета тестування, налаштування тестування (ПЗ, тривалість, сценарій), основні висновки і рекомендації. Використовувати таблицю для показників заголовка, щоб полегшити порівняння.

Опис тестових сценаріїв англійською мовою

Сценарій тестування описує послідовність HTTP- запитів, які виконує віртуальний користувач. Під час написання документації для тесту, будьте конкретними щодо поведінки користувача, яку ви моделюєте.

“Цей сценарій імітує автентифікованого користувача, який переглядає каталог продуктів, додає три елементи до своєї корзини і завершує покупку. Сценарій включає в себе двосекундний час роздумів між кожним кроком і використовує параметризовані дані з CSV-файлу

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

Практичні рекомендації

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

Основні напрямки діяльності: підвищення ефективності та точності

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

Однією з найпоширеніших проблем є використання надто нечітких термінів, таких як « повільний » або « високий трафік ». Замість того, щоб стверджувати, що запит є « повільним », спробуйте кількісно оцінити затримку. Фрази на кшталт «Средний час реакції для цієї кінцевої точки збільшився на 25% під час пікової навантаження» є набагато більш дієвими і демонструють чітке розуміння впливу. Аналогічно, при описі обсягу трафіку, замініть «багато» конкретними числами – «Ми імітуємо 500 одночасних користувачів». Цей рівень деталізації є ключовим у перегляді коду і обговоренні стратегії тестування. Під час перегляду коду, ви можете отримати коментар на зразок: « Цей скрипт не визначає чітко очікуваний час відповіді для цієї кінцевої точки. Було б корисно додати конфігурацію vus, яка націлена на реалістичну завантаження на основі поведінки користувача. “Це не звинувачення; це конструктивний зворотній зв’язок, оформлений точним технічним мовою.

Інша область, де нюанс має значення, це в описах PR. Хороший опис PR повинен пояснити * чому * зміни були внесені, а не тільки * що * було змінено. Замість « Додано більше віртуальних користувачів », кращим описом буде: « Збільшено кількість віртуальних користувачів (ВК) до 200, щоб краще імітувати піковий трафік користувачів під час пікової напруги післяобіднього часу, визначений під час спостереження за даними тестового запуску минулого тижня. » Це показує, що ви врахували контекст і обґрунтування ваших дій. Крім того, використання точної термінології, наприклад, «період підйому» є набагато ефективнішим, ніж просто сказати «почати повільно».

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

k6 run --record --greps "responseTime" my_script.js

Ця проста команда підкреслює важливість розуміння виводу інструменту - зокрема, метрика responseTime, що записується і потенційно використовується в подальшому аналізі або звіті. Знання того, які дані доступні, дозволяє більш цілеспрямоване запитання і багатше обговорення про вузли продуктивності.