Тестування продуктивності — Вікіпедія

Тестування продуктивності (performance testing) в програмній інженерії – це тестування, яке проводиться з ціллю визначення, як швидко працює програма або її частина під деяким навантаженням. Тестування продуктивності намагається враховувати продуктивність на стадії.

В тестуванні продуктивності розрізняють наступні напрямки: • навантажувальне (load) • стресове (stress) • тестування стабільності (endurance or soak or stability) • тестування на відмову та відновлення (Failover and Recovery Testing) • об'ємне тестування (Volume Testing) • шип тестування (Spike Testing)

Навантажувальне тестування (load testing) – це проста форма тестування продуктивності. Воно зазвичай проводиться для того, щоб оцінити поведінку програми (додатка) із заданим очікуваним навантаженням. Цим навантаженням може бути, наприклад, кількість користувачів, які будуть одночасно працювати з програмою. Такий вид тестування дозволяє отримати час відгуку всіх найважливіших бізнес-транзакцій.

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

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

Об’ємне тестування (Volume Testing) – тестування проводиться зі збільшенням не навантаження і часу роботи, а кількості використовуваних даних, які зберігаються і використовуються в додатку.

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

В загальних випадках тестування продуктивності може слугувати різним цілям: - з метою демонстрації того, що система задовольняє продуктивність; - з метою визначення продуктивність якої з двох або більше систем найкраща; - з метою визначення, який елемент навантаження або частина системи спричиняє зниження продуктивності. Багато тестів на продуктивність робляться без спроби осмислити їх реальні цілі. Перед початком тестування завжди задати бізнес-питання: «Яку мету ми переслідуємо, тестуючи продуктивність?». Відповіді на це питання є частиною техніко-економічного обґрунтування (або business case) тестування. Цілі можуть відрізнятися в залежності від технологій, що використовуються додатком, або його призначення, проте, вони завжди включають щось з нижченаведеного:

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

Ця концепція будується навколо часу відповіді одного вузла додатку на запит, надісланий іншим. Простим прикладом є HTTP 'GET' запит з браузера робочої станції на вебсервер. Практично всі програми, розроблені для навантажувального тестування працюють саме за цією схемою вимірювань. Іноді доцільно ставити завдання по досягненню продуктивності часу відповіді сервера серед всіх вузлів додатку.

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

Дуже важливо деталізувати вимоги до продуктивності і документувати їх в якому-небудь плані тестування продуктивності. В ідеальному випадку це робиться на стадії розробки вимог при розробці системи, до опрацювання деталей її дизайну. Проте тестування продуктивності часто не проводиться згідно зі специфікацією, так як немає зафіксованого розуміння про максимальний час відповіді для заданого числа користувачів. Тестування продуктивності часто використовується як частина процесу профайлингу продуктивності. Його ідея полягає в тому, щоб знайти «слабку ланку» - таку частину системи, збільшивши час реакції якої, можна поліпшити загальну продуктивність системи. Визначення конкретної частини системи, що стоїть на цьому критичному шляху, іноді дуже непросте завдання, тому деякі програми для тестування включають в себе (або можуть бути додані за допомогою add-on'ів) інструменти, запущені на сервері (агенти) і спостерігають за часом виконання транзакцій, часом доступу до бази даних. Тестування продуктивності може проводитися з використанням глобальної мережі і навіть у географічно віддалених місцях, якщо враховувати той факт, що швидкість роботи мережі Інтернет залежить від місця розташування. Воно також може проводитися і локально, але в цьому випадку необхідно налаштувати мережеві маршрутизатори таким чином, щоб з'явилася затримка, присутня в усіх публічних мережах. Навантаження, що додається до системи, повинне збігатися з реальним станом справ. Так наприклад, якщо 50% користувачів системи для доступу до системи використовують мережевий канал шириною 56К, а інша половина використовує оптичний канал, то комп'ютери, що створюють тестове навантаження на систему повинні використовувати ті ж з'єднання (ідеальний варіант) або емулювати затримки вищевказаних мережевих з'єднань.

• Тестування
• Тестування програмного забезпечення
• Якість програмного забезпечення
• Технологія розробки програмного забезпечення
• Зворотне семантичне трасування
• JUnit
• Багтрекер

• IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004 (англ.)
• The Test Management Guide — A to Z and FAQ Knowledgebase (англ.)
• Текст лекцій до курсу «Технології розробки і тестування програм» Дідковська М. В.
• Про Тестинг — Тестирование Программного Обеспечения (рос.)
• Портал специалистов по тестированию и обеспечению качества ПО(рос.)
• Портал об автоматизированном тестировании ПО(рос.)
• Качество программного обеспечения(рос.)
• Портал об автоматизированном тестировании ПО(рос.)
• Я — QA | Скажи багам нет!(рос.)
• QALight