Тестування продуктивності (Performance testing)
Last updated
Last updated
Тестування продуктивності - це нефункціональний вид тестування програмного забезпечення, що використовується для перевірки швидкості, часу відгуку, стабільності, надійності, масштабованості та використання ресурсів програмної програми при певному робочому навантаженні, зазвичай регресійним чином, коли додаток щодня або щотижня вносяться невеликі зміни. Основна мета тестування продуктивності - виявити та усунути вузькі місця продуктивності у програмному додатку. Це підмножина performance engineering, також відоме як Perf Testing. Саме собою воно покликане знаходити дефекти, але допомагає у виявленні вузьких місць у системі.
Зазвичай тривалість тесту продуктивності становить 1 годину (стійкий стан) на середньому/очікуваному навантаженні; це може змінюватись в залежності від вашого SLA / вимог.
Примітка 1: всі підвиди тестування продуктивності відрізняються, грубо кажучи, лише параметрами (тип зростання навантаження, її кількість, тривалість і т.п.) і метриками, що збираються (без яких це тестування безглуздо). Точкою відліку всім підвидів прийнято брати результати Capacity testing.
Примітка 2: незважаючи на необхідність розуміння багатьох математичних та статистичних концепцій, багато тестувальників та менеджерів або не мають достатніх знань у галузі математики та статистики, або не користуються ними. Це призводить до значних спотворень та неправильної інтерпретації результатів тестування продуктивності (ті ж перцентілі).
Загальні проблеми з продуктивністю .
Більшість проблем з продуктивністю пов'язані зі швидкістю, часом відгуку, часом завантаження та поганою масштабованістю. Швидкість часто є одним із найважливіших атрибутів програми. Додаток, що повільно працює, втратить потенційних користувачів. Тестування продуктивності проводиться для того, щоб переконатися, що програма працює досить швидко, щоб утримувати увагу та інтерес користувача. Погляньте на наступний список поширених проблем з продуктивністю та зверніть увагу на те, що швидкість є загальним фактором у багатьох з них:
Тривалий час завантаження – зазвичай час завантаження – це початковий час, необхідний програмі для запуску. Зазвичай воно має бути зведене до мінімуму. Хоча деякі програми неможливо завантажити менш ніж за хвилину, час завантаження має бути менше кількох секунд, якщо це можливо;
Поганий час відгуку. Час відгуку - це час, який проходить з моменту введення користувачем даних до додатка до того, як програма видасть відповідь на це введення. Як правило, це має відбуватися дуже швидко. Знову ж таки, якщо користувачеві доводиться чекати занадто довго, він втрачає інтерес;
Погана масштабованість - програмний продукт страждає від поганої масштабованості, коли він не може обробляти очікувану кількість користувачів.
Вузькі місця (Bottlenecking) – це перешкоди у системі, які погіршують загальну продуктивність системи. Вузьке місце - це помилки в коді, або проблеми з обладнанням, які викликають зниження пропускної спроможності при певних навантаженнях. Вузькі місця зазвичай усуваються шляхом виправлення процесів, що погано працюють, або додавання додаткового обладнання. Деякі загальні вузькі місця продуктивності:
Завантаження ЦП;
використання пам'яті;
Використання мережі;
Обмеження операційної системи;
Використання диска;
Як проводити тестування продуктивності?
Визначте необхідне середовище тестування (testing environment): перед тим, як розпочати процес тестування, вивчіть деталі апаратного, програмного забезпечення та мережевих конфігурацій, які використовуються під час тестування. Це допоможе тестувальникам створювати ефективніші тести. Це також допоможе визначити можливі проблеми, з якими тестувальники можуть мати справу під час процедур тестування продуктивності;
Визначте критерії приймання: сюди входять цілі та обмеження щодо пропускної спроможності, часу відгуку та розподілу ресурсів. Також необхідно визначити критерії успіху проекту, що виходять за межі цих цілей та обмежень. Тестувальники повинні мати право встановлювати критерії та мету продуктивності, тому що часто специфікації проекту не включають досить широкий спектр тестів продуктивності. Іноді їх може зовсім не бути. Якщо можливо, знайти схожу програму для порівняння - це хороший спосіб встановити цілі продуктивності;
Планування та проектування тестів продуктивності: Визначте, як використання може змінюватись серед кінцевих користувачів, та визначте ключові сценарії для тестування всіх можливих варіантів використання. Необхідно змоделювати різних кінцевих користувачів, спланувати дані тестування продуктивності та намітити, які метрики будуть зібрані;
Налаштування тестового середовища: Підготуйте тестове середовище перед виконанням. Також підготуйте інструменти та інші ресурси;
Імплементування тест-дизайну: Створіть тести продуктивності відповідно до вашого тест-дизайну;
Запуск тестів: Виконати та промоніторити тести;
Аналіз, налаштування та повторне тестування: об'єднуйте, аналізуйте та ділитесь результатами тестування. Потім виконайте точне налаштування і перевірте, чи є поліпшення або зниження продуктивності. Оскільки покращення зазвичай стають меншими з кожним повторним тестом, зупиніться, коли вузьке місце викликане ЦП. Тоді можна розглянути варіант збільшення потужності процесора.
Метрики тестування продуктивності (Performance Testing Metrics):
Використання процесора (Processor Usage): час, що витрачається процесором виконання non-idle потоків;
Використання пам'яті (Memory use): обсяг фізичної пам'яті, доступної процесам на комп'ютері;
Час диска (Disk time): час, протягом якого диск зайнятий виконанням запиту читання чи запис;
Затримка (Latency): часовий інтервал між запитом та відповіддю;
Пропускна спроможність (Throughput): фактична кількість запитів (або користувачів), які може обробити система за певний час. У той час як час затримки говорить вам тільки про час, метрика пропускної спроможності інформує про обсяг даних, отриманих та опрацьованих в момент часу. Важливо не відокремлювати показники часу затримки від пропускну здатність, т.к. Високий показник часу затримки часто прямо пов'язаний із збільшенням показників метрики пропускної спроможності. Пропускна здатність зазвичай вимірюється в rps - (кількість) запитів на секунду (requests per second).
Ширина пропускання каналу (Bandwidth): максимальна кількість запитів (або користувачів), які система може обробити. На відміну від пропускної спроможності ширина пропускання каналу вимірює максимальний обсяг, який може обробити програму.
Приватні байти (Private bytes): кількість байтів, виділених процесом, які можуть використовуватися іншими процесами. Вони використовуються для вимірювання витоків та використання пам'яті;
Виділена пам'ять (Committed memory) – обсяг використовуваної віртуальної пам'яті;
Сторінок пам'яті в секунду (Memory pages/second) - кількість сторінок, які записуються на диск або зчитуються з диска для усунення апаратних помилок сторінок. Збої апаратної сторінки – це коли код не з поточного робочого набору викликається з іншого місця та витягується з диска;
Помилок сторінок за секунду (Page faults/second) - загальна швидкість, з якою сторінки помилок обробляються процесором. Це відбувається, коли процесу потрібен код з-за меж свого робочого набору;
Число переривань процесора в секунду (CPU interrupts per second): це середня кількість апаратних переривань, які процесор приймає та обробляє кожну секунду;
Довжина дискової черги (Disk queue length): середня кількість запитів на читання та запис, поставлених у чергу для обраного диска протягом інтервалу вибірки;
Довжина мережної вихідної черги (Network output queue length): довжина черги вихідних пакетів у пакетах. Значення більше двох означає, що необхідно прибрати затримку та виникнення вузьких місць;
Усього мережевих байтів на секунду (Network bytes total per second): швидкість, з якою байти відправляються і приймаються інтерфейсом, включаючи символи кадрування;
Кількість пулів з'єднань (Amount of connection pooling): кількість запитів користувачів, які задовольняються об'єднаними з'єднаннями. Чим більше запитів буде виконано підключеннями в пулі, тим вищою буде продуктивність;
Максимальна кількість активних сесій (Maximum active sessions): максимальна кількість сесій, які можуть бути активними одночасно;
Коефіцієнт хітів (Hit ratios): це з кількістю операторів SQL, які обробляються кешованими даними замість дорогих операцій вводу-вывода. Це гарний початок для вирішення проблем, пов'язаних із вузькими місцями;
Хітів за секунду (Hits per second): кількість хітів веб-сервера протягом кожної секунди тесту навантаження;
Сегмент відкату (Rollback segment): обсяг даних, який можна відкотити будь-якої миті часу;
Блокування баз даних (Database locks) - блокування таблиць та баз даних необхідно відстежувати та ретельно налаштовувати;
Максимальний час очікування (Top waits) - відстежуються, щоб визначити, який час очікування можна скоротити при роботі з тим, наскільки дані швидко виймаються з пам'яті;
Кількість потоків (Thread counts): стан програми можна виміряти за кількістю потоків, які працюють і зараз активні;
Складання сміття (Garbage collection): це пов'язане з поверненням пам'яті, що не використовується, назад у систему. Складання сміття необхідно відстежувати щодо ефективності;
*Відсоток помилок розраховується як відношення невалідних відповідей до валідних за проміжок часу. Про Average, медіани, перцентілі тощо. заглиблюватися в рамках цієї статті не буду, їсти в гугле.
Тестування продуктивності клієнтської частини та серверної, у чому різниця?
Оцінка швидкості роботи клієнтської та серверної частин веб-додатка здійснюється двома різними видами тестування: для Frontend застосовується тестування клієнтської частини, або Client-Side testing, а для Back-end – тестування серверної частини.
Основна мета тестування клієнтської частини полягає у вимірі часу, необхідного браузеру для завантаження HTML-сторінки. Найбільш важливими показниками тут є кількість даних, що завантажуються, їх обсяг, а також кількість виконаних запитів.
Зібрати цю статистику можна як з використанням вбудованих інструментів браузера (DevTools), так і за допомогою спеціалізованих інструментів та онлайн-сервісів, які дозволяють виміряти необхідні показники з урахуванням регіону, що цікавить.
Крім загальної ваги сторінки, інструменти надають детальну інформацію щодо кожного з компонентів. Вивчивши параметри запитів, можна знайти ряд проблем, що призводять до погіршення швидкості відображення сторінки. Наприклад, підвантажується занадто велика картинка, повільний Javascript, або надсилається значна кількість запитів.
Інша необхідна перевірка спрямована на аналіз заголовків кешування, оскільки коректність виконання при повторному відвідуванні сторінки дозволяє підвищити швидкість завантаження сторінки до 80%.
Тестування серверної частини спрямоване на аналіз виконання запитів та отримання відповідної відповіді від Back-end.
Цілі даного виду тестування:
Виміряти час відгуку найважливіших бізнес-транзакцій;
Визначити граничний рівень припустимого навантаження;
Виявити «вузькі» місця у продуктивності системи;
Скласти рекомендації щодо покращення продуктивності;
Знайти можливі дефекти, що виявляються лише за одночасної роботі великої кількості користувачів.
Приклади перевірок :
Час відгуку не перевищує 4 секунд при одночасному доступі до сайту 1000 користувачів;
Час відгуку програми під навантаженням знаходиться в допустимому діапазоні при повільному підключенні до мережі;
Перевірте максимальну кількість користувачів, з якими програма може впоратися, перш ніж вона вийде з ладу;
Перевірити час виконання бази даних при одночасному читанні/записі 500 записів;
Перевірте використання ЦП та пам'яті програмою та сервером бази даних в умовах пікового навантаження;
Перевірте час відгуку програми в умовах низького, нормального, середнього та високого навантаження;
Під час фактичного виконання тесту продуктивності розпливчасті терміни, такі як допустимий діапазон, велике навантаження і т.д., замінюються конкретними цифрами. Інженери з продуктивності встановлюють ці числа відповідно до бізнес-вимог і технічним ландшафтом програми.
Джерела:
Дод. матеріал:
**Час відгуку**(Response time): час з моменту введення користувачем запиту до отримання першого символу відповіді. Детальніше: , ;
“D.5 Підпроцес тестування продуктивності”