Що таке HP LoadRunner Testing Tool? Архітектура, компоненти

Що таке LoadRunner?

LoadRunner - це інструмент для тестування продуктивності, піонером якого стала компанія Mercury в 1999 році. LoadRunner пізніше був придбаний HPE у 2006 році. У 2016 році LoadRunner було придбано MicroFocus.

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

У цьому підручнику ви дізнаєтесь-

• Чому LoadRunner?
• Навіщо потрібно тестування продуктивності?
• Що таке архітектура LoadRunner?
• Дорожня карта тестування продуктивності: докладні кроки
• FAQ

Чому LoadRunner?

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

Загалом, інструмент LoadRunner підтримує RIA (Rich Internet Applications), Web 2.0 (HTTP / HTML, Ajax, Flex і Silverlight тощо), Mobile, SAP, Oracle, MS SQL Server, Citrix, RTE, Mail і, перш за все, Windows Socket. На ринку немає жодного інструмента-конкурента, який міг би запропонувати таку різноманітність протоколів, покладених на один інструмент.

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

Програмне забезпечення LoadRunner тісно інтегровано з іншими інструментами HP, такими як Уніфікований функціональний тест (QTP) та ALM (Управління життєвим циклом додатків), що дає змогу виконувати всі необхідні процеси тестування.

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

Навіщо потрібно тестування продуктивності?

За оцінками, щорічно фіксуються збитки в розмірі 4,4 млрд. Доходів через низьку продуктивність роботи в Інтернеті.

У сучасну епоху Web 2.0 користувачі клацають, якщо веб-сайт не реагує протягом 8 секунд. Уявіть, що ви чекаєте 5 секунд, коли шукаєте Google або подаєте запит на подругу у Facebook. Наслідки простою роботи часто є більш руйнівними, ніж будь-коли уявлялося. Ми маємо приклади, такі як нещодавно потрапили в Інтернет-банкінг Bank of America, Amazon Web Services, Intuit або Blackberry.

За даними Dunn & Bradstreet, 59% компаній Fortune 500 щотижня переживають 1,6 години простою. Враховуючи, що середня компанія Fortune 500, що має мінімум 10 000 співробітників, платить 56 доларів на годину, частина витрат робочої сили на простій для такої організації становила б 896 000 доларів на тиждень, що перевищувало б 46 мільйонів доларів на рік.

За оцінками, лише 5-хвилинний простой Google.com (19 серпня 13) обійдеться пошуковому гіганту в цілих 545 000 доларів.

За підрахунками, компанії втратили продажі на суму 1100 доларів за секунду через нещодавній збій у роботі веб-служби Amazon.

Коли система програмного забезпечення розгортається організацією, вона може зіткнутися з багатьма сценаріями, які можуть призвести до затримки продуктивності. Ряд факторів спричиняє уповільнення роботи, кілька прикладів можуть включати:

• Збільшена кількість записів, присутніх у базі даних
• Збільшена кількість одночасних запитів до системи
• більша кількість користувачів, які одночасно отримують доступ до системи порівняно з минулим

Що таке архітектура LoadRunner?

Взагалі кажучи, архітектура HP LoadRunner є складною, але легко зрозумілою.

Припустимо, вам призначено перевірити роботу Amazon.com для 5000 користувачів

У реальному житті всі ці 5000 користувачів будуть знаходитись не на домашній сторінці, а в іншому розділі веб-сайтів. Як ми можемо імітувати по-іншому

VUGen:

VUGen або віртуальний користувальницький генератор - це IDE (інтегроване середовище розробки) або розширений редактор кодування. VUGen використовується для відтворення поведінки системи під навантаженням (SUL). VUGen надає функцію "запису", яка реєструє зв'язок з клієнтом та сервером у формі кодованого сценарію, який також називається сценарієм VUser.

Отже, розглядаючи наведений вище приклад, VUGen може записувати, щоб імітувати такі бізнес-процеси:

1. Серфінг на сторінці продуктів Amazon.com
2. Перевірити
3. Обробка платежів
4. Перевірка сторінки MyAccount

Контролер

Після завершення роботи сценарію VUser Controller є одним з основних компонентів LoadRunner, який керує імітацією навантаження, керуючи, наприклад:

• Скільки користувачів, які моделюють для кожного бізнес-процесу або групи користувачів
• Поведінка Користувачів (нарощування, зниження, одночасний або одночасний характер тощо)
• Характер сценарію навантаження, наприклад, реальне життя чи орієнтована на ціль, або перевірка SLA
• Які форсунки використовувати, скільки користувачів проти кожного інжектора
• Періодично збирайте результати
• Підробка IP
• Повідомлення про помилку
• Звітність про операції тощо

Беручи аналогію з нашого прикладу контролера, ми додамо наступний параметр до сценарію VUGen

1) 3500 користувачів переглядають сторінку продуктів Amazon.com

2) 750 користувачів в Checkout

3) 500 користувачів виконують обробку платежів

4) 250 користувачів перевіряють сторінку MyAccount ТІЛЬКИ після того, як 500 користувачів здійснили обробку платежів

Можливі навіть більш складні сценарії

1. Ініціюйте 5 користувачів кожні 2 секунди, поки не буде завантажено 3500 користувачів (серфінг на сторінці продуктів Amazon).
2. Повторюйте протягом 30 хвилин
3. Призупиніть ітерацію для 25 користувачів
4. Повторно запустіть 20 користувачів
5. Ініціюйте 2 користувачів (у Checkout, Обробка платежів, Сторінка MyAccounts) щосекунди.
6. 2500 машин буде створено на машині A
7. 2500 машин буде створено на машині B

Агенти Машина / Генератори навантаження / Інжектори

Контролер HP LoadRunner відповідає за імітацію тисяч користувачів - ці користувачі споживають апаратні ресурси, наприклад процесор та пам’ять, - отже, обмежує машину, яка їх імітує. Крім того, контролер імітує ці користувачі з тієї ж машини (де знаходиться контролер), а отже, результати можуть бути неточними. Щоб вирішити цю проблему, усі користувачі VU розподілені між різними машинами, які називаються генераторами навантаження або інжекторами навантаження.

Як загальна практика, контролер знаходиться на іншій машині, а навантаження імітується з інших машин. Залежно від протоколу сценаріїв VUser та технічних характеристик машини, для повноцінного моделювання може знадобитися ряд інжекторів навантаження. Наприклад, для користування сценаріями HTTP для моделювання потрібно 2-4 МБ на кожного користувача, отже для імітації навантаження в 10000 користувачів будуть потрібні 4 машини з 4 ГБ оперативної пам'яті.

Беручи аналогію з нашого прикладу Amazon, результат цього компонента буде

Аналіз:

Після виконання сценаріїв завантаження входить роль компонентів " Аналіз " LoadRunner.

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

Усі помилки та винятки реєструються у базі даних доступу Microsoft із назвою output.mdb. Компонент "Аналіз" зчитує цей файл бази даних для виконання різних типів аналізу та генерує графіки.

Ці графіки показують різні тенденції для розуміння аргументів помилок та відмов під навантаженням; таким чином допоможе зрозуміти, чи потрібна оптимізація в SUL, сервері (наприклад, JBoss, Oracle) чи інфраструктурі.

Нижче наведено приклад, коли пропускна здатність може створювати вузьке місце. Скажімо, веб-сервер має ємність 1 Гбіт / с, тоді як обмін даними перевищує цю ємність, що спричиняє страждання наступних користувачів. Щоб визначити систему, яка відповідає таким потребам, Performance Engineer повинен проаналізувати поведінку додатків із ненормальним навантаженням. Нижче наведено графік, який створює LoadRunner для виявлення пропускної здатності.

Дорожня карта тестування продуктивності: докладні кроки

Дорожню карту тестування продуктивності можна розділити на 5 етапів:

• Планування випробування на навантаження
• Створіть сценарії VUGen
• Створення сценарію
• Виконання сценарію
• Аналіз результатів (з подальшим налаштуванням системи)

Тепер, коли ви встановили LoadRunner, давайте зрозуміємо кроки, що беруть участь у процесі, по черзі.

Етапи, що беруть участь у процесі перевірки ефективності

Планування випробування на навантаження

Планування тестування продуктивності відрізняється від планування SIT (тестування системної інтеграції) або UAT (тестування прийняття користувача). Планування можна розділити на невеликі етапи, як описано нижче:

Зберіть свою команду

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

Менеджер проекту:

Визначте керівника проекту, котрий буде власником цієї діяльності та виконуватиме функції ескалації.

Експерт з функцій / бізнес-аналітик:

Надайте аналіз використання SUL та надайте досвід щодо функціональних можливостей веб-сайту / SUL

Експерт з тестування продуктивності:

Створює автоматизовані тести продуктивності та виконує сценарії завантаження

Архітектор системи:

Надає проект SUL

Веб-розробник та МСП:

• Веде веб-сайт та надає аспекти моніторингу
• Розробляє веб-сайт та виправляє помилки

Системний адміністратор:

• Підтримує задіяні сервери протягом проекту тестування

Контурні програми та задіяні бізнес-процеси:

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

Показник вимог може бути підготовлений, щоб викликати навантаження користувача на систему. Нижче наведено приклад системи відвідуваності компанії:

У наведеному вище прикладі на рисунках згадується кількість користувачів, підключених до програми (SUL) на певну годину. Ми можемо виділити максимальну кількість користувачів, підключених до бізнес-процесу в будь-яку годину дня, яка обчислюється в крайніх правому стовпці.

Так само ми можемо зробити висновок про загальну кількість користувачів, підключених до програми (SUL) в будь-яку годину дня. Це обчислюється в останньому рядку.

Наведені вище два факти в сукупності дають нам загальну кількість користувачів, з якими нам потрібно протестувати систему на ефективність.

Визначте процедури управління тестовими даними

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

• Користувач "А" створює фінансовий контракт і подає його на перевірку.
• Інший користувач "Б" схвалює 200 контрактів на день, створених користувачем "А"
• Інший користувач "С" платить близько 150 контрактів на день, схвалений користувачем "Б"

У цій ситуації користувач В повинен мати 200 контрактів, «створених» в системі. Крім того, користувачеві С потрібно 150 контрактів як "затверджених", щоб імітувати навантаження 150 користувачів.

Це неявно означає, що ви повинні створити щонайменше 200 + 150 = 350 контрактів.

Після цього затвердьте 150 контрактів, які слугуватимуть тестовими даними для користувача C - решта 200 контрактів будуть служити тестовими даними для користувача B.

Контурні монітори

Обміркуйте кожен фактор, який може вплинути на продуктивність системи. Наприклад, зменшення апаратного забезпечення матиме потенційний вплив на продуктивність SUL (система під навантаженням).

Перелічіть усі фактори та налаштуйте монітори, щоб ви могли їх виміряти. Ось кілька прикладів:

• Процесор (для веб-сервера, сервера додатків, сервера баз даних та інжекторів)
• Оперативна пам'ять (для веб-сервера, сервера додатків, сервера баз даних та інжекторів)
• Веб-сервер / сервер додатків (наприклад, IIS, JBoss, Jaguar Server, Tomcat тощо)
• DB Server (розмір PGA та SGA у разі Oracle та MSSQL Server, SP тощо)
• Використання пропускної здатності мережі
• Внутрішня та зовнішня мережева карта в разі кластеризації
• Load Balancer (і що він розподіляє навантаження рівномірно по всіх вузлах кластерів)
• Потік даних (підрахуйте, скільки даних переміщується до клієнта та сервера, а потім підрахуйте, чи ємності NIC достатньо для імітації кількості користувачів X)

Створіть сценарії VUGen

Наступним кроком після планування є створення сценаріїв VUser.

Створення сценарію

Наступним кроком є ​​створення сценарію завантаження

Виконання сценарію

Виконання сценарію - це місце, коли ви імітуєте навантаження користувача на сервер, даючи вказівки декільком користувачам виконувати завдання одночасно.

Ви можете встановити рівень навантаження, збільшуючи та зменшуючи кількість користувачів, які виконують завдання одночасно.

Це може призвести до того, що сервер зазнає напруги та поводиться ненормально. Це сама мета тестування продуктивності. Потім отримані результати використовуються для детального аналізу та виявлення першопричини.

Аналіз результатів (з подальшим налаштуванням системи)

Під час виконання сценарію LoadRunner реєструє продуктивність програми під різними навантаженнями. Статистика, отримана в результаті виконання тесту, зберігається та проводиться детальний аналіз. Інструмент "Аналіз HP" генерує різні графіки, які допомагають виявити основні причини відставання продуктивності системи, а також системний збій.

Деякі отримані графіки включають:

• Час до першого буфера
• Час реакції транзакції
• Середній час реакції транзакції
• Хітів в секунду
• Ресурси Windows
• Статистика помилок
• Підсумок транзакцій

FAQ

Які програми слід перевірити?

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

Наприклад, Microsoft Calculator не базується ні на клієнт-сервері, ні в ньому працює декілька користувачів; отже, він не є кандидатом на тестування продуктивності.

Яка різниця між тестуванням продуктивності та інженерією продуктивності

Важливо розуміти різницю між тестуванням продуктивності та інженерними технологіями. Нижче наведено розуміння:

Тестування продуктивності - це дисципліна, що займається тестуванням та звітуванням про поточну ефективність програмного додатку за різних параметрів.

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

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