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

Пропонуємо спочатку прочитати першу частину статті в блозі.

Що значить швидко?

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

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

• до 0.1 секунд - миттєво;
  
• до 1 секунди - швидко;
• до 2 секунд - досить швидко;
• 2 - 4 секунди - прийнятно;
• 4 - 15 секунд - повільно;
• більше 15 секунд - дуже довго.

Що тестувати?

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

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

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

Класифікація проблем

Якого типу проблема може бути виявлена ​​під час проведення тестування продуктивності:

• Повільна підсистема / функція

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

• Вузьке місце (bottleneck)

Досягнення межі будь-якої з частин системи, наприклад, межа пропускної спроможності мережевого з'єднання.

• Точка насичення

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

• Функціональний дефект
  

Як такі функціональні дефекти не типові для тестування продуктивності і частіше виявляються при проведенні функціонального тестування, де дії виконуються послідовно. Але для тестування продуктивності типово паралельне виконання операцій у великій кількості, де при конфлікті функциональностей, можна виявити функціональні дефекти.

Після виявлення будь-якої з перерахованих проблем нам необхідно передати інформацію розробнику і далі вже вивчати шляхи оптимізації роботи системи.

Цілі тестування

Повертаючись до цілей тестування, в кінцевому підсумку, ми як фахівці з тестування повинні надати реальну інформацію про стан продукту зацікавленим особам. Ці зацікавлені особи, можуть інтерпретувати питання про стан таким чином:

• Менеджера або розробника може цікавити, чи стала нова версія додатка працювати швидше. Але замовника не цікавить швидкість відгуку або споживання ресурсів, його цікавить демонстрація оцінки продуктивності на популярному мові, а не технічними термінами. І інтерпретація результатів — це буде завдання або аналітика, або тестувальника.
• Що саме уповільнює роботу: софт або залізо? Ця інформація необхідна для того, щоб вирішити: чи купувати нове серверне обладнання або ж оптимізувати програму. Завдяки оцінці можливості до розпаралелювання, оцінці запасу потужності і часу відгуку, ми можемо зробити висновок, на який зі сторін існує недолік.
• Чому користувачі не завершують замовлення? Може, користувачі не завершують замовлення тому, що не можуть дочекатися завершення операції? Або існує переповнення черги обробки замовлень і система віддає помилки.
  Чи витримає сервер прийдешні розпродажі? Наприклад, після запуску реклами або в популярні дні розпродажів по всьому світу, ми повинні бути впевнені, що наша система зможе забезпечити коректне функціонування.
• Нерідко замовники можуть поставити запитання: як поводиться система в цілому, чи все гаразд? Це питання типовий не тільки для тестування продуктивності, але і для інших видів тестування. Чи немає яких-небудь проблем? У тому числі і з продуктивністю. І на це питання так само необхідно вміти відповідати, переводячи на технічні терміни, де ми зможемо оцінити стан програми та на популярній мові сказати про стан програми.

Виходячи з перерахованих вище можливих питань від замовників, можна сформулювати список цілей для проведення тестування продуктивності:

• Порівняти дві версії додатка
• Знайти причину проблеми з продуктивністю
• Оцінити потенційні можливості
• Отримати підтвердження, що з системою все добре

Знаючи про потреби та цілі тестування продуктивності, ми можемо вибудувати план проектування тестів.