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

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

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

Тестування. Якість

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

Тестування
— це оцінка поведінки системи з метою визначення відмінностей між реальним і очікуваним поведінкою системи.

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

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

Якщо з визначенням вимог справа йде трохи простіше: є прямі і непрямі вимоги, є різні шляхи вироблення вимог, то питання якості досить складне і неоднозначне.

Цитуючи Вільям Демінга, фахівця в галузі менеджменту якості; консультанта великих американських і японських компаній в галузі управління якістю: «Проблема, притаманна спробам визначити якість продукту, практично будь-якого продукту, була викладена майстром Уолтером Шухартом (всесвітньо відомий американський вчений і консультант з теорії управління якістю (прим. ред.)). Складність у визначенні якості полягає в тому, щоб перетворити майбутні потреби користувача в вимірні характеристики, щоб продукт міг бути спроектований і отриманий таким чином, щоб задовольняти за ціною, яку заплатить користувач. Це непросто, і як тільки людина відчуває себе досить успішною в цьому починанні, вона виявляє, що потреби споживача змінилися, з'явилися конкуренти і т. Д. »

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

Існують організації, які розробляють стандарти в різних сферах діяльності, в тому числі і в питаннях якості. Одними з таких є: ISO (Міжнародна організація по стандартизації) і IEC (Міжнародна електротехнічна комісія).

У далекому 1991 році, 19 грудня з'явився стандарт ISO / IEC 9126, який називається: «Розробка програмного забезпечення. Якість продукції". Метою даного стандарту була спроба визначити вимірні характеристики якості, для управління ними.

Було виділено 6 верхньорівневих характеристик якості з подхарактерістікамі на кожному рівні. Характеристики верхнього рівня за стандартом ISO / IEC 9126:

  • функціональність;
  • надійність;
  • ефективність;
  • зручність використання;
  • зручність супроводу;
  • портативність.

Через роки, стандарт ISO / IEC 9126 був оновлений в 2011 році і тепер має назву ISO / IEC 25010: «Розробка систем і програмного забезпечення. Вимоги та оцінка якості систем і програмного забезпечення (SQuaRE). Моделі якості систем і програмного забезпечення ».

В оновленій версії стандарту були виділені і доповнені характеристики якості, тепер їх 8:

  • функціональність;
  • надійність;
  • продуктивність;
  • захищеність;
  • переносимість;
  • супроводжуваність;
  • сумісність;
  • зручність використання.

Рекомендуємо курс по темі

Продуктивність

З усіх характеристик нас цікавить тільки одна характеристика якості верхнього рівня — це продуктивність. Продуктивність включає в себе ще кілька подхарактерістік:

  • Часові характеристики (час виконання операцій)
  • Характеристики використання ресурсів (фізичний софт)
  • Характеристики потенційних можливостей систем (запас потужності).

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

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

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

Сучасні веб-додатки можуть складатися з трьох частин: бази даних, сервера додатку і веб-сервера. Сервер програми зберігає в собі безпосередньо логіку програми. А веб-сервер займається функціями управління статичним контентом — css, js, зображення і іншими файлами. Ці три компоненти можуть перебувати на різних комп'ютерах або навіть на різних дата-центрах, розташованих в різних регіонах.

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

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

Рішення для такої ситуації два: або виконувати тест з точки зору кінцевого користувача, або забезпечити запас потужності на продуктивність нашого додатком для компенсації на проміжні ланки. Головне питання — чи буде дана складна система працювати швидко з точки зору кінцевого користувача?

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

Рекомендуємо публікацію по темі