Види performance-тестів: load, stress, spike, soak

Що таке тестування продуктивності і які його види ви знаєте?

Це не окрема процедура, а збірний тип тестування: під ним живе будь-яка перевірка того, як система реагує (responsiveness) на різні обсяги навантаження. Канонічний перелік силабуса ISTQB CT-PT налічує сім підвидів — load, stress, spike, endurance, scalability, capacity, concurrency. Шпаргалка Grafana k6 дає шість, частину зве інакше (average-load замість load, soak замість endurance) і додає власні smoke та breakpoint, яких у каноні немає. Тобто перелічити «правильний» список неможливо: спільної домовленості щодо назв цих видів не існує, і дока k6 говорить про це прямо. Сильна відповідь тому не міряється довжиною списку — вона привʼязує до кожної назви питання, на яке цей вид відповідає. «Load — чи тримаємо очікуване, stress — що буде за межею» звучить як розуміння; шість слів поспіль — як вивчений перелік.

Чим load-тест відрізняється від stress-тесту?

Межа проходить по слову «очікуване». Load працює всередині діапазону, який ми самі прогнозуємо, — від низького через типове до пікового використання; щойно навантаження виходить за цей діапазон, вид уже інший. Друга відмінність тонша, і саме вона зазвичай губиться: у означенні стресу є ще одна вісь, зовсім не про кількість користувачів, — робота за зменшеної доступності ресурсів, і канон називає їх поіменно: обчислювальна ємність, пропускна здатність, памʼять. Тобто стрес можна поставити, не додавши жодного віртуального користувача: досить забрати частину памʼяті або звузити канал. Різні й цілі: load показує, чи виконуємо ми обіцянку в нормальному режимі, а стрес — як саме система розсипається, коли виконати її неможливо. Відповідь у стилі «стрес — це коли навантаження побільше» читається як половина означення, бо це буквально його половина.

Що таке spike-тест і за якої умови він вважається пройденим?

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

Що ловить soak-тест і чому цього не бачать інші види?

Soak (у ISTQB — endurance) шукає дефекти, які проявляються лише з часом: невіддані зʼєднання до бази даних, вичерпані пули потоків, витік памʼяті. Ширший перелік причин деградації з часом додає до цього фрагментацію диска, розростання бази понад очікуване, збільшення файлового сховища й наростання мережевого трафіку. Інші види їх не бачать з простої причини: цей клас проблем не залежить від висоти навантаження, він залежить від тривалості. Тому навантаження в soak — звичайне, середнє продове, а довгий тут прогін: години, а не хвилини. І висновок роблять не по значенню, а по нахилу: середній час відповіді за вісім годин може виглядати цілком пристойно, тоді як остання година вже провальна. Якщо в графіку памʼять і час відповіді повзуть угору й не вирівнюються — це і є знахідка, навіть коли жоден поріг ще формально не пробито.

Навіщо перф-смоук, якщо все одно буде повний прогін?

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

Чим capacity відрізняється від scalability?

Різниця в часі, на який дивиться тест. Ємність — це про «зараз і на цьому залізі»: скільки користувачів або транзакцій система підтримає, при цьому все ще виконуючи заявлені цілі продуктивності. Масштабованість — про майбутнє: чи зможемо ми вирости (більше користувачів, більші обсяги збережених даних), не порушивши чинних вимог і не почавши падати. Умова «і при цьому виконає цілі» в першому означенні несуча: максимум, на якому система ще вкладається у свої X мілісекунд, і максимум, на якому вона просто ще стоїть, — різні числа, і саме перше канон вважає ємністю. У масштабованості найцінніший побічний продукт: щойно межі відомі, вони перетворюються на пороги моніторингу на проді й дають попередження до інциденту. І ще одна деталь, яка додає ваги відповіді: масштабованість залежить одразу від трьох підхарактеристик — від часової поведінки, від утилізації ресурсів і від ємності, — тому діагноз «не масштабується» лишається неповним, доки не сказано, котра з них упирається першою.

Замовник питає «скільки користувачів ми тримаємо?». Що ви відповісте?

Сильна відповідь починається зі зустрічного питання: за якої цілі продуктивності? Без названої цілі число не визначене, бо «система ще відповідає за 500 мс» і «система ще не впала» дають різні максимуми. Тому коректна форма відповіді — не одне число, а пара: стільки-то конкурентних користувачів на такому-то операційному профілі з утриманням заявленої цілі. Якщо цілі немає взагалі, це не питання до тестувальника, а прогалина у вимогах, і чесніше повернути її замовнику, ніж вигадати цифру. Тут же корисно уточнити, чи питання насправді про сьогодні (ємність), чи про плани зростання на рік (масштабованість) — бо це різні прогони з різними критеріями.

Чому «ми подали 500 віртуальних користувачів» ще не описує навантаження?

Бо кількість користувачів сама собою мірою навантаження не є — канон каже це прямо й повʼязує з операційними профілями. Пʼятсот сесій, у яких люди читають одну сторінку, і пʼятсот, у яких вони проганяють чекаут із записом у базу, створюють навантаження, що відрізняється на порядок. Наслідок практичний: результат такого прогону ні з чим не можна порівняти, бо неможливо повторити ті самі умови наступного разу. Тому в звіті поруч із числом користувачів мають стояти сценарії, їхні частки й темп — тобто профіль. Без нього два прогони на одній системі можуть розійтися вдвічі, і жоден із них не буде «неправильним».

Що таке baseline і чому без нього прогін не має вердикту?

Базовий вимір — це зафіксований набір метрик, з яким порівнюють поточні результати. Канон відносить його до критеріїв приймання поруч із цілями перф-тесту й SLA, бо дозволяє показати конкретне поліпшення або підтвердити, що критерії досягнуто. Зворотний бік записаний серед ризиків: якщо прогін стартував без заздалегідь визначених метрик, які відділяють прийнятне від неприйнятного, оцінити його результати нічим. Тому «сімсот мілісекунд» — не результат; результатом воно стає у формі «сімсот проти чотирьохсот вісімдесяти минулого тижня, за незмінного стенда й того самого набору даних». Деталь, яку часто проґавлюють: базовий вимір не «беруть з проду», його готують — зокрема на знеособлених даних із бази, — і саме тому він відтворюваний. Поруч варто не плутати три різні цілі регулярних прогонів: порівняння з базовим виміром, спостереження за трендом метрик у часі й виловлювання регресій конкретного релізу.

Що таке volume testing і чи є він канонічним видом?

Це питання на чесність, і правильна відповідь починається з визнання: канонічного означення немає. У глосарії ISTQB такого терміна не знайти, у силабусі CT-PT він не зустрічається жодного разу, а єдине джерело, яке його означує, — стаття Вікіпедії, тобто вторинне джерело, до того ж із власним попередженням про брак посилань. Ужиткове значення таке: змінною тут виступає не кількість користувачів і не темп запитів, а розмір даних у сховищі — базу наповнюють до потрібного обсягу й міряють продуктивність уже на ній; окремий випадок — файл обміну потрібного розміру. Канон при цьому саме явище описує, але імені йому не дає: цілі ємності можуть формулюватися й щодо обсягів даних, а в прикладах є деградація на запитах великих обсягів із діагнозом «ємності обробити такі обсяги бракує». Практичний висновок: вимогу «система тримає базу на сто мільйонів рядків» надійніше оформити як ціль ємності з явно названим обсягом даних, ніж як «volume-тест», під який кожна команда розуміє своє.

Чим форма профілю Steps відрізняється від Ramp-ups і де кожна доречна?

Це дві канонічні форми зміни навантаження в часі, і вибір між ними задає, який саме вид ви насправді ставите. Ramp-ups — рівномірне наростання, скажімо по одному віртуальному користувачу за хвилину: система встигає прогрітися, пули розігнатися, кеші заповнитися, і саме на такій формі будують звичайний load-тест. Steps — миттєві зміни, наприклад плюс сто користувачів кожні пʼять хвилин: система отримує стрибок без часу на адаптацію, і це форма для сплеску. Помилка, яку легко зробити ненавмисно: назвати прогін сплесковим, а профіль зібрати з плавним ramp-up — тоді ви виміряли зовсім не те, бо весь сенс сплеску саме в раптовості. І навпаки, різкі сходинки в load-тесті дають артефакти прогріву, які потім читають як деградацію.

Що таке breakpoint-тест і як він співвідноситься зі stress і capacity?

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

Система повільна навіть під одним користувачем. Який вид тесту тут запускати?

Жодного — це не задача для перф-тестів. Канон виділяє такий режим окремо: повільно на будь-якому навантаженні, і типові причини лежать у площині реалізації — невдала схема бази чи запит до неї, мережева затримка, чужі фонові процеси на середовищі. Такі проблеми видно вже під час функціонального й юзабіліті-тестування, тож ганяти під них навантажувальний прогін означає витратити день і отримати той самий висновок дорожче. Правильний хід — профілювання конкретного запиту й перевірка середовища, а перф-тест лишити для випадків, коли повільність зʼявляється саме з ростом навантаження. Уміння сказати «цей симптом не про мій вид тестів» на співбесіді цінується не менше, ніж знання видів.

Часу вистачає лише на один довгий прогін: soak чи stress?

Відповідь визначає профіль ризику самої системи, а не смак тестувальника. Якщо система працює тривалими безперервними сесіями — бекенд, який місяцями не перезапускають, фонові обробники, довгі користувацькі сесії, — більший ризик у деградації з часом, і пріоритет за soak. Якщо система більше ризикує інтенсивним використанням — розпродажі, рекламні кампанії, пікові години, — першість за стрес-тестами. Універсальної відповіді тут немає навмисно: канон інструментів радить не мислити в абсолютах саме тому, що жодним одним видом усі ризики продуктивності не закриваються. Сильно звучить відповідь, яка називає критерій вибору, а не вид: «дивлюсь, який режим відмови для цього продукту дорожчий».

Моніторинг показує утилізацію процесора не вище 80%, а система захлинається. Як таке можливо?

Перше, що треба спитати про будь-який графік утилізації, — яке в нього вікно усереднення. Задокументований випадок саме такий: інструменти звітували пʼятихвилинними середніми й не показували більш ніж 80%, тоді як усередині цих інтервалів утилізація на секунди сягала 100% і давала реальне насичення. Середнє за пʼять хвилин фізично не може показати сплеск на дві секунди — воно його розмазує. Для перф-тестів наслідок простий: дрібніша гранулярність метрик або пряме спостереження за чергами й затримками, а не лише за відсотками завантаження. І дисципліна інтерпретації: «запас є» — це висновок, який має спиратися на відоме вікно усереднення, інакше він не доведений.

Чому один вид перф-тестів не закриває ризики продуктивності?

Бо кожен вид відповідає на власне питання й бачить власний режим відмови. Насичення ресурсу під зростальним навантаженням покаже load, а далі stress; деградацію з часом — тільки soak, бо на короткому прогоні витік памʼяті ще нічого не встиг зʼїсти; погану обробку помилок під перевантаженням — stress і spike, причому час відповіді там може бути ще прийнятним, а черги й таймаути вже сипатися. Тому дока інструментів прямо каже, що одним видом усіх ризиків продуктивності не зняти, а стратегія залежить від профілю ризику організації. Практично це означає набір, а не один прогін: смоук на кожну зміну коду, регулярний load із порівнянням до базового виміру, періодичні stress і spike та довгий soak перед великими релізами. І ще один нюанс, який відрізняє сильну відповідь: види ще й відносні — те, що для одного застосунку позамежний стрес, для іншого буденне середнє навантаження, тож без контексту конкретної системи назва виду майже нічого не означає.

Як ви побудуєте перф-стратегію для продукту з нуля?

Починати треба не з інструмента й не з видів, а з двох речей: цілей продуктивності й операційних профілів. Без цілі жоден прогін не має вердикту — немає межі між прийнятним і неприйнятним; без профілю навантаження не описане, і результати не порівнюються між прогонами. Далі — базовий вимір: зафіксована точка на конкретному середовищі й конкретних даних, підготовлена заздалегідь, за потреби на знеособлених даних. Потім вибудовується піраміда за вартістю: перф-смоук на кожну відповідну зміну коду, регулярний load-прогін із порівнянням до базового виміру в пайплайні, stress і spike під ризики пікових подій, soak перед релізами, які чіпають довгоживучі компоненти. Питання ємності й масштабованості вирішуються окремими прогонами, а їхні результати не лишаються у звіті — вони переїжджають у пороги моніторингу на проді. І окремим рядком у стратегії має стояти домовленість про те, що вважається регресією: скільки відсотків погіршення проти базового виміру валять збірку, бо без цього числа порівняння перетворюється на дискусію.

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

Кейс 1. Одна фраза в тікеті — шість різних прогонів

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

Що дивитися і чому:

• Провал у кожному рядку різний, і це головне. Один прогін не дає вердикту за всіма шістьма критеріями: профіль, зібраний під одне питання, для решти просто не створює умов — у ньому немає ні фази спаду, ні годин рівного навантаження. Тому «зробити один великий навантажувальний тест» — це відповісти на одне питання й видати відповідь за всі шість.
• Рядок про ємність не має слова «провалено». Capacity-прогін не проходить і не падає — він видає число. Але число має сенс лише разом із ціллю: максимум, на якому система ще вкладається у свої 500 мс, і максимум, на якому вона просто ще стоїть, — це два різні числа.
• Порядок у таблиці — це і є порядок запуску. Смоук коштує хвилини, load — до години, soak — ніч. Ганяти дорогі прогони до дешевих означає регулярно втрачати ніч через скрипт, що не встиг за новим шляхом ендпоінта.
• «Витримає» без операційного профілю не визначено. Пʼятсот користувачів, які читають головну, і пʼятсот, які проходять чекаут із записом у базу, — це різні навантаження. Тому в тікет треба повернути питання про профіль, а не вигадувати цифру.

Кейс 2. Сплеск «пройдено», а розпродаж утрачено

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

Що показав розбір, крок за кроком:

1. Прогін обірвали на піку. Профіль закінчувався верхньою полицею: фази спаду до початкового рівня в ньому не було взагалі, бо «далі й так усе зрозуміло». Саме там і живе половина критерію: вид вимагає не лише пережити сплеск, а й повернутися до усталеного стану.
2. Пул зʼєднань до бази не згорнувся. Під піком він розрісся до стелі, а після спаду залишився зайнятим, і кожен наступний звичайний запит чекав на вільне зʼєднання. На піку цього не видно: там усі чекають, і це очікувано.
3. Автоскейлінг спрацював — після того, як усе скінчилося. Нові інстанси піднялися за чотири хвилини сорок секунд, тобто майже на півтори хвилини пізніше, ніж закінчився сплеск. Формально механізм працює, практично — не рятує, і ця цифра мала стати вимогою до інфраструктури, а не сюрпризом у суботу.

Що дивитися і чому:

• Фаза спадання — не формальність, а половина тесту. Якщо в профілі немає повернення до початкового рівня і хвоста спостереження після нього, ви поставили не сплесковий тест, а короткий стрес.
• Метрику після спаду міряють проти усталеного стану ДО піку. Тому перед сплеском потрібен рівний відрізок звичайного навантаження: без нього немає з чим порівнювати «повернулися чи ні».
• Плавне наростання замість стрибка знецінює прогін. Ramp-up дає механізмам адаптації фору, якої в реальності не буде: у розпродажу трафік приходить сходинкою, а не похилою.

Кейс 3. Нічний soak: середнє зелене, тренд червоний

Вісім годин середнього продового навантаження, ціль — 95-й перцентиль часу відповіді не гірше 800 мс. Уранці зведений звіт показує 640 мс за прогін, і це в межах цілі. Але зведене число тут — найгірший спосіб дивитися на soak.

година   p95, мс   RSS процесу, МБ   активних зʼєднань до БД
1        480       310               22
2        495       360               24
3        510       415               27
4        545       470               31
5        600       540               35
6        690       615               41
7        820       690               46
8        980       765               50

Зведене за весь прогін число — ті самі 640 мс, тобто формально «пройдено». Насправді прогін провальний: до восьмої години система вже вдвічі повільніша за початок, памʼять зросла в 2,5 раза й на плато не вийшла, а кількість зʼєднань до бази монотонно повзе вгору — класична картина того, що їх беруть і не віддають. Ще дві-три години такого прогону — і пул упреться в максимум, після чого запити почнуть чекати або відвалюватися. Тобто дефект тут не в тому, що якесь значення перевищило поріг, а в тому, що жодна з трьох кривих не вирівнялася.

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

// baseline.json готують заздалегідь: незмінний стенд, той самий набір даних
import baseline from './baseline.json';

type RunSummary = { p95Ms: number; rssStartMb: number; rssEndMb: number };

const MAX_REGRESSION = 0.1; // 10% гірше за базовий вимір — уже регресія
const MAX_MEMORY_GROWTH = 0.2; // 20% росту RSS за прогін без виходу на плато

export function checkRun(run: RunSummary): string[] {
  const problems: string[] = [];

  const p95Limit = baseline.p95Ms * (1 + MAX_REGRESSION);
  if (run.p95Ms > p95Limit) {
    problems.push(`p95 ${run.p95Ms} мс проти базових ${baseline.p95Ms} мс`);
  }

  // нахил, а не значення: скільки памʼяті додалося за прогін
  const growth = (run.rssEndMb - run.rssStartMb) / run.rssStartMb;
  if (growth > MAX_MEMORY_GROWTH) {
    problems.push(`RSS виріс на ${Math.round(growth * 100)}% і не вийшов на плато`);
  }

  return problems;
}

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

import { test, expect } from '@playwright/test';

const SCENARIO = ['/api/catalog', '/api/cart', '/api/checkout/quote'];

test('перф-смоук: усі ендпоінти сценарію живі перед довгим прогоном', async ({ request }) => {
  for (const path of SCENARIO) {
    const res = await request.get(`https://staging.example.com${path}`);
    expect(res.status(), `ендпоінт ${path} відповів не 200`).toBe(200);
  }
});

Що дивитися і чому:

• У soak метрика — нахил, а не значення. Зведене середнє за прогін структурно ховає деградацію: чим довший прогін, тим сильніше хороший початок компенсує поганий кінець. Тому дивляться погодинний зріз і питають, чи вийшла крива на плато.
• Три криві поруч читаються краще за одну. Час відповіді сам собою каже «стало гірше», а памʼять і зʼєднання підказують, чому саме: витік у процесі й невіддані зʼєднання до бази — різні дефекти з різними власниками.
• Гейт порівнює з базовим виміром, а не з абсолютним порогом. Питання «980 мс — це погано?» без зафіксованої точки відповіді не має; «980 мс проти базових 480 мс на незмінному стенді» — уже готовий баг-репорт.
• Допустимий відсоток регресії має бути домовленістю, а не рішенням автора тесту. Число в константі — це і є те, що команда вважає регресією; поки воно не узгоджене, кожен червоний гейт перетворюється на дискусію замість дії.
• Смоук не міряє продуктивність. Його завдання інше: показати, що скрипт відповідає поточному API, а система тримає кількох користувачів. Плутати його з load-прогоном — типова помилка звітності: «смоук зелений» не означає «навантаження тримаємо».

Таксономія: чому єдиного списку немає

• Розумію, що performance testing — збірний тип тестування, а всі види нижче його підвиди, і памʼятаю обидва переліки: сім у силабусі ISTQB CT-PT проти шести у шпаргалці Grafana k6, з розбіжністю і в складі (capacity, scalability, concurrency проти smoke, breakpoint), і в назвах (load проти average-load, endurance проти soak).
• Можу пояснити, чому назва виду без контексту системи майже нічого не означає: позамежний стрес для одного застосунку — буденне середнє навантаження для іншого.
• Знаю, що одним видом усі ризики продуктивності не закриваються, тож набір підбирають під профіль ризику організації та системи, а не «беруть найповніший».

Load і stress

• Знаю різницю load vs stress: перший живе всередині очікуваного діапазону (низьке, типове, пікове), другий починається там, де очікуване закінчується.
• Памʼятаю, що в load-тесті кількість користувачів задається, а не спостерігається, і що сама по собі ця цифра навантаження не описує — без операційного профілю два прогони ні з чим не порівняти.
• Знаю другу вісь стресу — зменшену доступність ресурсів (обчислювальна ємність, пропускна здатність, памʼять): стресувати систему можна, не додавши жодного віртуального користувача.
• Можу пояснити, що мета стрес-тесту — побачити характер відмови, а не зламати систему; пошук самої координати межі в інструментах зветься breakpoint і в ISTQB відсутній.

Spike і soak

• Знаю, що сплесковий тест вважається пройденим лише за умови повернення до усталеного стану, тому фазу спадання не відрізають заради коротшого прогону.
• Розрізняю форми профілю: Steps — миттєві стрибки навантаження (сплеск), Ramp-ups — рівномірне наростання (звичайний load); підміна форми підміняє вид тесту.
• Знаю, що soak — це довго на середньому навантаженні, а не сильно, і який клас дефектів він ловить: невіддані зʼєднання до бази, вичерпані пули потоків, витік памʼяті, розростання сховища й самої БД.
• Розумію, що вердикт soak робиться по нахилу графіка, а не по середньому за прогін: пристойне середнє за вісім годин може ховати провальну останню годину.

Capacity, scalability і volume

• Знаю різницю capacity vs scalability: «скільки тримаємо зараз із дотриманням заявлених цілей» проти «наскільки виростемо, не порушивши чинних вимог».
• Памʼятаю, що ємність без названої цілі продуктивності не визначена: максимум «ще вкладаємось у ціль» і максимум «ще не впало» — різні числа.
• Можу пояснити, навіщо межі масштабованості потрібні після прогону — вони стають порогами моніторингу на проді, — і чому «не масштабується» неповний діагноз, поки не названо, що впирається першим: часова поведінка, утилізація ресурсів чи ємність.
• Даю чесну відповідь про volume testing: канонічного означення в ISTQB немає, термін ужитковий, а саме явище коректніше оформити як ціль ємності з явно названим обсягом даних.

Baseline, смоук і читання результатів

• Розумію, чому число без базового виміру не є результатом — без метрик, що відділяють прийнятне від неприйнятного, прогін нічим оцінювати, — і знаю, що baseline готують заздалегідь (за потреби на знеособлених даних) і порівнюють за незмінного стенда та того самого набору даних, а не «беруть з проду».
• Не плутаю три різні цілі регулярних прогонів: порівняння з базовим виміром, спостереження за трендом метрик у часі й виловлювання регресій конкретного релізу.
• Можу пояснити цінність перф-смоуку: за секунди переконатися, що скрипт живий і система тримає кількох користувачів, перш ніж витрачати ніч на довгий прогін.
• Знаю чотири режими відмови й куди веде кожен: повільно завжди — не до перф-тестів; повільно на середньому й високому — load, далі stress; деградація з часом — soak; погана обробка помилок під перевантаженням — stress і spike.
• Памʼятаю про вікно усереднення метрик: усереднення по пʼять хвилин розмиває секундні піки до 100%, тож «CPU не вище 80%» ще не доводить, що запас є.