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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

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

Види тестування продуктивності[ред.ред. код]

В тестуванні продуктивності розрізняють наступні напрямки: • навантажувальне (load) • стресове (stress) • тестування стабільності (endurance or soak or stability) • конфігураційне (configuration)

Навантажувальне тестування[ред.ред. код]

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

Стресове тестування[ред.ред. код]

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

Тестування стабільності[ред.ред. код]

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

Конфігураційне тестування[ред.ред. код]

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

Визначення цілей тестування продуктивності[ред.ред. код]

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

Паралелізм / Пропускна здатність[ред.ред. код]

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

Час відповіді сервера[ред.ред. код]

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

Час відображення[ред.ред. код]

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

Вимоги до продуктивності[ред.ред. код]

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

Дивіться також[ред.ред. код]

Посилання[ред.ред. код]