Пропонуємо спочатку прочитати першу частину статті в блозі.
Рекомендуємо публікацію по темі
Що значить швидко?
Питанням сприйняття часу вчені задавалися з тих пір, як з'явилися перші термінальні комп'ютери, що мають інтерфейс між логічною частиною обробки даних і користувачем, в середині ХХ століття.
Проводячи експерименти з реакцією користувача, оцінюючи затримки сприйняття на різні активності: натискання на клавішу мишки, перегортання сторінки, перегляд сторінки і інші дії, вчені виділили кілька груп сприйняття людиною часу.
- до 0.1 секунд - миттєво;
- до 1 секунди - швидко;
- до 2 секунд - досить швидко;
- 2 - 4 секунди - прийнятно;
- 4 - 15 секунд - повільно;
- більше 15 секунд - дуже довго.
Що тестувати?
З огляду на швидкість сприйняття користувачів, ми все ж не можемо сказати, що єдиним вірним рішенням буде вимір швидкодії системи з боку кінцевого користувача.
Можна й потрібно оцінювати продуктивність окремих частин системи, а іноді і цілих алгоритмів. Для того, щоб оцінити, який внесок вони вносять в систему, і тому, щоб їх можна було налагодити. Наприклад, взяли і виміряли продуктивність якого-небудь алгоритму, внесли зміни для поліпшення, виміряли повторно і оцінили результат.
У зв'язку зі складністю емулювання поведінки системи з боку кінцевого користувача, ми можемо провести експертизу, вказати в звіті реально отримані результати поведінки системи і врахувати всі припущення, і уточнення в кінцевому звіті, для подальшої оцінки і вивчення.
Рекомендуємо курс по темі
Класифікація проблем
Якого типу проблема може бути виявлена під час проведення тестування продуктивності:
- Повільна підсистема / функція
Окрема підсистема або функція, яка працює повільно; якась сторінка, яка завантажується довше всіх; скрипт, який споживає багато ресурсів.
- Вузьке місце (bottleneck)
Досягнення межі будь-якої з частин системи, наприклад, межа пропускної спроможності мережевого з'єднання.
- Точка насичення
Це стан системи, при якому поведінка змінюється не кількісно, а якісно. Наприклад, при досягненні певної кількості користувачів починають з'являтися відмови. Таку ситуацію можна спостерігати в системах, де запити обробляються не відразу, а потрапляють в черзі, у цій черзі є певна довжина і, як тільки довжина вичерпана, починають з'являтися відмови в системі, так як система не може обслужити запит.
- Функціональний дефект
Як такі функціональні дефекти не типові для тестування продуктивності і частіше виявляються при проведенні функціонального тестування, де дії виконуються послідовно. Але для тестування продуктивності типово паралельне виконання операцій у великій кількості, де при конфлікті функциональностей, можна виявити функціональні дефекти.
Після виявлення будь-якої з перерахованих проблем нам необхідно передати інформацію розробнику і далі вже вивчати шляхи оптимізації роботи системи.
Цілі тестування
Повертаючись до цілей тестування, в кінцевому підсумку, ми як фахівці з тестування повинні надати реальну інформацію про стан продукту зацікавленим особам. Ці зацікавлені особи, можуть інтерпретувати питання про стан таким чином:
- Менеджера або розробника може цікавити, чи стала нова версія додатка працювати швидше. Але замовника не цікавить швидкість відгуку або споживання ресурсів, його цікавить демонстрація оцінки продуктивності на популярному мові, а не технічними термінами. І інтерпретація результатів — це буде завдання або аналітика, або тестувальника.
- Що саме уповільнює роботу: софт або залізо? Ця інформація необхідна для того, щоб вирішити: чи купувати нове серверне обладнання або ж оптимізувати програму. Завдяки оцінці можливості до розпаралелювання, оцінці запасу потужності і часу відгуку, ми можемо зробити висновок, на який зі сторін існує недолік.
- Чому користувачі не завершують замовлення? Може, користувачі не завершують замовлення тому, що не можуть дочекатися завершення операції? Або існує переповнення черги обробки замовлень і система віддає помилки.
Чи витримає сервер прийдешні розпродажі? Наприклад, після запуску реклами або в популярні дні розпродажів по всьому світу, ми повинні бути впевнені, що наша система зможе забезпечити коректне функціонування. - Нерідко замовники можуть поставити запитання: як поводиться система в цілому, чи все гаразд? Це питання типовий не тільки для тестування продуктивності, але і для інших видів тестування. Чи немає яких-небудь проблем? У тому числі і з продуктивністю. І на це питання так само необхідно вміти відповідати, переводячи на технічні терміни, де ми зможемо оцінити стан програми та на популярній мові сказати про стан програми.
Виходячи з перерахованих вище можливих питань від замовників, можна сформулювати список цілей для проведення тестування продуктивності:
- Порівняти дві версії додатка
- Знайти причину проблеми з продуктивністю
- Оцінити потенційні можливості
- Отримати підтвердження, що з системою все добре
Знаючи про потреби та цілі тестування продуктивності, ми можемо вибудувати план проектування тестів.
