Performance testing: цілі та місце в QA-процесі

Що таке тестування продуктивності і навіщо воно, якщо функціонально все зелене?

Це тип тестування, завдання якого — визначити продуктивність компонента або системи, тобто перевірити не «що система робить», а якою швидкістю й ціною в ресурсах вона це робить. Функціональні перевірки відповідають на питання коректності: замовлення створилось, лист пішов, поле збереглося. Продуктивність — окремий, нефункціональний бік якості з моделі ISO 25010, і зелена регресія про нього не каже нічого. Термін збірний: під ним живе будь-яка перевірка швидкості відгуку (responsiveness) системи під різними обсягами навантаження, і предмет не обмежений вебом — так само працює в класичних клієнт-серверних, розподілених і вбудованих системах. Практичний наслідок: форма, яка зберігає запис за 200 мс на порожній базі й за сорок секунд у пікову годину, функціонально справна в обох випадках — зламалася саме продуктивність, і ловить це окремий клас перевірок.

З яких частин складається продуктивність як характеристика якості?

З трьох підхарактеристик, і плутати їх невигідно. Часова поведінка (time behavior) — чи вкладається система у відведений час відповіді за обумовлених умов; на неї націлена більшість перф-тестів. Утилізація ресурсів (resource utilization) — скільки ресурсів на цю відповідь витрачено; її досліджують, коли доступність ресурсів визнали ризиком. Ємність (capacity) — чи витримує архітектура межі за кількістю користувачів або обсягами даних. Розмах першої з них навмисно широкий: від наскрізного часу відповіді на дію користувача до кількості процесорних тактів на конкретну задачу. Разом усі три визначають, чи здатна система масштабуватися. Звідси й головний практичний висновок: вимога «має бути швидко» описує лише одну третину предмета, і сервіс, який віддає відповідь за 200 мс на процесорі, завантаженому на 99%, формально її задовольняє — хоча запасу під зростання навантаження там уже немає.

Чим ємність відрізняється від масштабованості?

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

Що таке віртуальний користувач і чи означає 1000 VU тисячу реальних людей?

Ні, і це один із найчастіших ляпів у звітах. Віртуальний користувач (virtual user, VU) — це симуляція активностей, що виконуються згідно з операційним профілем користувача; не людина, не браузер і не сесія реального клієнта. Конкурентність в інструментах навантаження зазвичай моделюють саме кількістю VU — тому число й потрапляє в розмову замість справжньої міри навантаження. Технічно за VU стоїть потік виконання інструмента: у JMeter один такий користувач — це потік, який проганяє план тесту цілком і незалежно від інших, а різні групи потоків семплюють різні функції. Є й межі, про які інструменти попереджають самі: у k6 немає гарантії, що саме цей VU візьме саме цю ітерацію, — тому дані в скрипті розкладають по віртуальних користувачах, а не по номерах ітерацій. Сильна відповідь на співбесіді додає головне: 1000 VU не описує навантаження, поки не сказано, що ці користувачі роблять і як часто.

Що таке транзакція в перф-тестуванні і як через неї рахують пропускну здатність?

Транзакція (transaction) тут — одиниця роботи, яку рахують і міряють: оформлене замовлення, платіж, HTTP-запит. Саме через неї означена пропускна здатність системи (system throughput): скільки транзакцій заданого типу система витягує за одиницю часу — замовлень за годину, запитів за секунду. Головна пастка — тезка з бази даних: там слово означає атомарність групи команд, а в перф-звіті це бізнес-операція, тривалість і кількість якої ми доповідаємо. Лічильники таких одиниць інструменти дають готовими — наприклад, кількість запитів у k6 видно в метриці http_reqs. Практичний наслідок: перш ніж міряти, команда має домовитися, що саме вважається транзакцією в цьому продукті — інакше «1000 транзакцій за хвилину» у звіті й у голові замовника означатимуть різні речі.

Чим операційний профіль відрізняється від сценарію?

Операційний профіль (operational profile) описує один тип користувача: фактичний або передбачений патерн використання — що людина робить і наскільки інтенсивно. Профіль навантаження (load profile) додає масштаб: скільки таких екземплярів і як вони розподілені в часі. Агрегування операційних профілів і дає профіль навантаження, який зазвичай називають сценарієм — тобто «сценарій» у перф-контексті це не крок-за-кроком тест-кейс, а розкладка «хто, скільки і коли». Ту саму ієрархію видно в інструментах: k6 дозволяє описати в одному скрипті кілька сценаріїв, кожному задати власний патерн планування віртуальних користувачів і пустити їх одночасно. На співбесіді ця пара розводить кандидата, який просто крутив ручки в інструменті, від того, хто розуміє, звідки беруться цифри на вході.

Чому кількість одночасних користувачів — погана міра навантаження?

Бо навантаження задає пропускна здатність системи, а не кількість голів. Число користувачів беруть тому, що його легше дістати й що інструменти приймають на вхід саме його — але без визначених операційних профілів воно навантаження не описує. Арифметика з канону наочна: 500 користувачів, кожен з яких робить короткий запит щохвилини, дають 30 000 запитів за годину; ті самі 500 користувачів із тим самим запитом раз на годину дають 500. Різниця в шістдесят разів, і щонайменше така сама різниця у вимогах до заліза. Практичний наслідок: рядок у ТЗ «має тримати 500 користувачів» вимогою не є, поки до нього не дописали профіль. І окремо варто памʼятати, що навіть «запитів за секунду» неявно усереднює за вікном виміру: система, що видає 200 запитів у парні секунди й нуль у решті, має те саме середнє, що й стала сотня, але миттєве навантаження вдвічі більше.

Що таке відтворюваність перф-тесту і чому без неї прогін не дає вердикту?

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

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

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

На якому етапі проєкту починається перф-тестування?

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

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

Канон ставить їх поруч, але не ототожнює: тестування продуктивності тісно інтегроване з інженерією продуктивності та юзабіліті-інженерією — це сусідні дисципліни, а не синоніми. Тестування визначає продуктивність компонента або системи, а гарна інженерія продуктивності допомагає уникнути пізнього виявлення критичних дефектів. Ключове твердження, заради якого це питання й ставлять: критичні дефекти продуктивності здебільшого вносяться в архітектуру й проєктування, а другим їх джерелом є вимоги, у яких не зафіксували цілей щодо часу відповіді, пропускної здатності системи, утилізації ресурсів, очікуваного навантаження й обмежень. Саме тому статичні активності для продуктивності часто важать більше, ніж для функціональної придатності. Що QA може зробити без жодного генератора навантаження: рецензувати вимоги з фокусом на продуктивності; рецензувати схеми БД, ER-діаграми, метадані, збережені процедури й запити; рецензувати архітектуру системи й мережі; рецензувати критичні ділянки коду. Жодна з цих активностей не потребує ні стенда, ні ліцензії на інструмент.

Яка головна мета перф-тестів у CI і чи достатньо їх самих?

Головна мета перф-тестів у пайплайні одна — переконатися, що зміна не погіршила продуктивність; це роль регресійна, а не дослідницька. Оскільки вікно в пайплайні коротке, до нього зазвичай потрапляє лише підмножина ширшого набору тестів, який спеціалізована команда ганяє в інший час. Тому фраза «перф у нас у пайплайні» і фраза «у нас налагоджене перф-тестування» описують різні обсяги роботи: перша каже лише про захист від деградації на кожній зміні. Практика додає обмеження з іншого боку: не всі перф-тести взагалі придатні для CI/CD-воркфлоу, а запуск виключно на зміну коду звужує цілі перф-тестування — лишаються cron-ранери, планування прогонів у хмарі й ручний запуск як пункт релізного чекліста. Сенс усього руху — змінити режим роботи команди: у багатьох організаціях продуктивність лишається невідчутною, і реагують на неї лише тоді, коли вже сталося погане.

«Нашому проєкту потрібне навантажувальне тестування?» — як відповісти?

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

Замовник каже «має працювати швидко». Ваші дії?

Перетворити побажання на вимірювану вимогу, бо в такому вигляді воно не перевіряється й вердикту не дає. Розмова починається з трьох питань до стейкхолдерів: які саме транзакції потраплять у тест і якого середнього часу відповіді від них чекають; які системні метрики збираємо й що вважаємо нормальним значенням; наскільки має покращитися картина проти попереднього циклу. Далі число вбирається у форму цілі рівня сервісу (service level objective, SLO), і головна вимога до неї — назвати спосіб виміру та умови, за яких ціль лишається чинною; канонічний приклад виглядає приблизно так: «99% викликів Get RPC, усереднено за одну хвилину, завершуються швидше за 100 мс, і вимір робиться на всіх бекенд-серверах». Машинною цю ціль робить поріг (threshold) в інструменті: «95% запитів швидші за 200 мс», «частка помилкових відповідей менша за 1%». Окремо варто розвести цілі користувацькі (задоволеність, бізнес-результат) і технічні (масштабування, умови деградації) — вони належать різним співрозмовникам і перевіряються по-різному.

Що станеться, якщо почати перф-тестування, не визначивши метрик?

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

Час відповіді в межах цілі. Чи означає це, що прогін пройдено?

Ні, і це класична пастка. Канон описує окремий режим відмови продуктивності, де час відповіді лишається прийнятним, а на високих і позамежних навантаженнях деградує саме обробка помилок — через недостатні пули ресурсів, замалі черги та стеки й надто агресивні таймаути. Інакше кажучи, система вчасно відповідає тим, кого обслужила, і при цьому негарно поводиться з тими, кого не витягнула: втрачає запити, віддає невиразні пʼятисоті, рве зʼєднання. Тому дивитися треба не лише на час, а й на те, що сталося із запитами, які не пройшли, — частку помилок, їхній тип, поведінку черг. Друга половина того самого сюжету — ресурси: 200 мс при процесорі на 99% формально проходять ціль, але запасу під наступного користувача там немає.

Графік показує, що утилізація CPU не піднімалася вище 80%. Чи є запас?

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

Продукт «повільний». Це автоматично задача для навантажувального тестування?

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

Ми запустили 50 браузерів через Playwright паралельно. Це навантажувальне тестування?

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

Як звітувати результат перф-тестування стейкхолдерам?

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

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

Кейс 1. «Має працювати швидко» перетворюємо на вимогу

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

Далі відповіді складають у вимірювану форму. Ціль рівня сервісу (service level objective, SLO) мусить сказати не лише число, а й як його міряють і за яких умов вона чинна:

Останній рядок — окремий сюжет, до нього повернемось у другому кейсі. А коли числа є, вони стають машинними: інструмент кодифікує SLO порогом і сам виносить вердикт.

// k6: пороги — це SLO, записане так, щоб прогін сам червонів
export const options = {
  thresholds: {
    http_req_duration: ['p(95)<800'], // 95% запитів швидші за 800 мс
    http_req_failed: ['rate<0.01'], // частка невдалих — менша за 1%
  },
};

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

• Порогів без умов виміру не буває. «Час відповіді 800 мс» нічого не варте, якщо не сказано, на якому навантаженні й у якій точці міряли: на клієнті з мобільною мережею й на боці API це різні числа для однієї системи.
• Перцентиль замість середнього — не формальність. Ціль формулюють як частку запитів, які вкладаються в поріг, бо саме так потім звітують залишковий ризик: скільки клієнтів імовірно зіткнеться із затримкою, рівною або більшою за поріг.
• Розводьте користувацькі цілі й технічні. «Клієнт не кидає оформлення» і «сервіс тримає горизонтальне масштабування без деградації» — вимоги різних співрозмовників; змішані в одному рядку, вони не перевіряються жодним прогоном.
• Немає вимоги — це нормальний стан, а не блокер. Перф-тестування часто живе без тест-оракула, а стейкхолдери погано формулюють такі вимоги. Робота QA тут починається саме з видобування чисел, і це і є перший внесок у якість.

Кейс 2. Арифметика профілю: чому «500 користувачів» не є навантаженням

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

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

Порядок дій, який знімає це питання:

1. Зібрати операційні профілі — що робить кожен тип користувача і наскільки інтенсивно. Джерело: аналітика проду, логи, розмова з власником продукту.
2. Агрегувати їх у профіль навантаження (він же сценарій): скільки екземплярів кожного типу і як вони розподілені в часі.
3. Перерахувати профіль у транзакції за одиницю часу — саме це число потім порівнюють із порогом і саме воно потрапляє у звіт.
4. Задати форму навантаження: наростання, плато, спадання. Складні «американські гірки» марнують ресурси й ускладнюють ізоляцію проблеми.

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

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

Кейс 3. Тікет «форма гальмує в понеділок вранці»

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

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

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

• «Відкрили тридцять вкладок автотестами» — не заміна прогону. Генерація через UI годиться, коли треба представити невелику кількість користувачів і є де взяти стільки клієнтських машин; вона найрепрезентативніша для наскрізних сценаріїв, але тримається на стабільності UI й дорого коштує в супроводі. Для тисяч користувачів взаємодію захоплюють на рівні протоколу.
• Графік утилізації читають з кінця — з вікна усереднення. Панель, яка показує «не більше 80%», може усереднювати за пʼять хвилин і ховати секундні сплески до стелі. Задокументований випадок саме такий, і без цього питання висновок «запас є» безпідставний.
• Прогін має лишатися відтворюваним. Повтор на незміненій системі має давати статистично ідентичний результат у межах допуску — інакше різницю між «до» і «після» однаково добре пояснює і фікс, і випадковість. На практиці це фіксований стан даних, ізольоване середовище й той самий профіль у кожному прогоні.
• Функціональні перевірки зі сценарію не викидають. Оцінка функціональної придатності під навантаженням може виявити проблеми, специфічні саме для навантаження, тож сценарій без асертів на відповіді втрачає частину знахідок і не доводить, що система під піком віддавала правильні дані.

Продуктивність як характеристика якості

• Розумію, що продуктивність (performance efficiency) — нефункціональна характеристика якості з ISO 25010, а не синонім слова «швидко».
• Назву три підхарактеристики — часова поведінка, утилізація ресурсів, ємність — і скажу, що саме міряє кожна.
• Знаю різницю між ємністю (де в системи наявна стеля щодо вимоги) і масштабованістю (чи можна ту стелю рухати), тому «система не масштабується» для мене симптом, а не діагноз.

Що таке перф-тестування і чим воно не є

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

Місце в життєвому циклі

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

Ризик, цілі й числа

• Назву три ключові цілі перф-тестування — виявити потенційні ризики, знайти можливості для поліпшення, визначити необхідні зміни — і поясню, чому питання «чи потрібне навантажувальне» вирішує оцінка ризику, а не кількість людей у команді й обсяг трафіку.
• Знаю шість наслідків старту без визначених вимірів і метрик, а також чому вимог зазвичай немає: перф-тестування часто без тест-оракула, а стейкхолдери погано їх формулюють.
• Знаю, що SLO мусить називати спосіб виміру й умови чинності, а поріг (threshold) — його машинна форма з вердиктом pass/fail.
• Можу звітувати залишковий ризик часткою користувачів і порогом, а не фразою «іноді ще довго чекають»; памʼятаю, що пізно знайдений дефект коштує перепроєктування, а не патча.

Базовий словник навантаження

• Знаю різницю між операційним профілем (що робить один тип користувача) і профілем навантаження, він же сценарій (скільки екземплярів і як розподілені в часі).
• Можу пояснити, що віртуальний користувач — симуляція за операційним профілем і потік інструмента, а не людина й не вкладка браузера.
• Знаю, що транзакція тут — бізнес-одиниця роботи, через яку означена пропускна здатність системи, і це не транзакція бази даних.
• Назву чотири способи генерації навантаження (UI, натовп тестувальників, API, захоплення протоколу) і поясню на числах, чому кількість користувачів без профілю не є мірою: ті самі 500 користувачів дають 500 або 30 000 запитів за годину.

Типові пастки

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