Сергій Семенов Software Engineer у PrivatBank, Викладач Комп'ютерної школи Hillel.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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