1
5

Оцінити

Статті читати 6 хв. 5 1 голос 280

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Схожі матеріали

Подпишитесь на рассылку
Компьютерной школы Hillel

Ви отримаєте:

  • Інформацію про корисні галузеві заходи
  • Цікаві статті IT-сфери
  • Новини Комп'ютерної школи Hillel