Инструмент за тестване на LoadRunner – Компоненти и Archiтекстура

Какво е LoadRunner?

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

LoadRunner поддържа различни инструменти за разработка, технологии и комуникационни протоколи. Всъщност това е единственият инструмент на пазара, който поддържа толкова голям брой протоколи за провеждане Тестване на производителността. Резултатите от теста за производителност, произведени от софтуера LoadRunner, се използват като еталон спрямо други инструменти

LoadRunner видео

Защо LoadRunner?

LoadRunner е не само пионерски инструмент в тестването на ефективността, но все още е лидер на пазара в парадигмата за тестване на ефективността. Според скорошна оценка LoadRunner има около 85% пазарен дял в индустрията за тестване на ефективността.

Като цяло инструментът LoadRunner поддържа RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex и Silverlight и др.), Mobile, SAP, Oracle, ГОСПОЖИЦА SQL Сървър, Citrix, RTE, Mail и най-вече, Windows Гнездо. Няма конкурентен инструмент на пазара, който би могъл да предложи толкова голямо разнообразие от протоколи, включени в един инструмент.

Това, което е по-убедително да изберете LoadRunner при тестване на софтуер, е надеждността на този инструмент. Инструментът LoadRunner отдавна си е изградил репутация, както често ще срещнете клиенти кръстосано проверяват показателите ви за ефективност с помощта на LoadRunner. Ще намерите облекчение, ако вече използвате LoadRunner за нуждите си от тестване на производителността.

Софтуерът LoadRunner е тясно интегриран с други инструменти на HP, като Unified Functional Test (QTP) и ALM (Application Lifecycle Management), като ви позволява да извършвате крайни процеси на тестване.

LoadRunner работи на принципа на симулиране на виртуални потребители в съответното приложение. Тези виртуални потребители, наричани още VUsers, репликират заявките на клиента и очакват съответен отговор за преминаване на транзакция.

Защо се нуждаете от тестване на ефективността?

Изчислено загуба на 4.4 милиарда приходи се записва всяка година поради лоша уеб производителност.

В днешната епоха на Web 2.0 потребителите щракват, ако уебсайтът не отговори в рамките на 8 секунди. Представете си, че чакате 5 секунди, когато търсите Google или правите покана за приятелство във Facebook. Последствията от прекъсване на производителността често са по-опустошителни, отколкото някога сте си представяли. Имаме примери като тези, които наскоро удариха онлайн банкирането на Bank of America, Amazon Уеб услуги, Intuit или Blackberry.

Според Dunn & Bradstreet, 59% от компаниите от Fortune 500 изпитват приблизително 1.6 часа престой всяка седмица. Като се има предвид, че средната компания от Fortune 500 с минимум 10,000 56 служители плаща 896,000 долара на час, частта от разходите за труд за престой за такава организация ще бъде 46 XNUMX долара седмично, което означава повече от XNUMX милиона долара годишно.

Смята се, че само 5-минутен престой на Google.com (19 август 13 г.) ще струва на гиганта за търсене цели $545,000 XNUMX.

Смята се, че компаниите са загубили продажби на стойност $1100 на секунда поради скорошно Amazon Прекъсване на уеб услугата.

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

• Увеличен брой записи в базата данни
• Увеличен брой едновременни заявки, направени към системата
• по-голям брой потребители, които имат достъп до системата наведнъж в сравнение с миналото

Какво е LoadRunner Archiтекстура?

Най-общо казано, архитектурата на HP LoadRunner е сложна, но лесна за разбиране.

Да предположим, че ви е възложено да проверите ефективността на Amazon.com за 5000 потребители

В реална ситуация всичките тези 5000 потребители няма да бъдат на началната страница, а в различен раздел на уебсайтовете. Как можем да симулираме по различен начин.

VUGen

VUGen или виртуален потребител Generator е IDE (интегрирана среда за разработка) или богат редактор на кодиране. VUGen се използва за репликиране на поведението на системата под натоварване (SUL). VUGen предоставя функция за „запис“, която записва комуникация към и от клиент и сървър под формата на кодиран скрипт – наричан още VUser скрипт.

Така че като се има предвид горният пример, VUGen може да записва, за да симулира следните бизнес процеси:

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

Регулатор

След като VUser скриптът е финализиран, Controller е един от основните компоненти на LoadRunner, който контролира симулацията на Load чрез управление, например:

• Колко VUsers да се симулират спрямо всеки бизнес процес или VUser група
• Поведение на VUsers (увеличаване, намаляване, едновременен или едновременен характер и т.н.)
• Естество на сценария на натоварване, напр. реален живот или целево ориентиран или потвърждаващ SLA
• Кои инжектори да използвате, колко VUsers срещу всеки инжектор
• Сравнявайте резултатите периодично
• IP спуфинг
• Отчитане на грешка
• Отчитане на транзакции и др.

Като вземем аналогия от нашия примерен контролер, ще добавим следния параметър към VUGen Script

1) 3500 потребители са Сърфиране в страницата с продукти на Amazon.com

2) 750 потребители са вътре Поръчка

3) 500 потребители са извършване на обработка на плащания

4) 250 потребители са Проверка на страницата MyAccount САМО след като 500 потребители са извършили обработка на плащанията

Възможни са дори по-сложни сценарии

1. Инициирайте 5 VUsers на всеки 2 секунди до натоварване от 3500 VUsers (сърфиране Amazon продуктова страница) се постига.
2. Повторете за 30 минути
3. Спиране на итерация за 25 VUsers
4. Рестартирайте 20 VUSers
5. Инициирайте 2 потребители (в Checkout, Payment Processing, MyAccounts Page) всяка секунда.
6. 2500 VUsers ще бъдат генерирани на машина A
7. 2500 VUsers ще бъдат генерирани на машина B

Машина/зареждане на агенти Generators/Инжектори

HP LoadRunner Controller е отговорен за симулирането на хиляди VUsers – тези VUsers консумират хардуерни ресурси, например процесор и памет – следователно поставят ограничение на машината, която ги симулира. Освен това Controller симулира тези VUsers от същата машина (където се намира Controller) и следователно резултатите може да не са точни. За да се отговори на това безпокойство, всички VUsers са разпределени в различни машини, наречени Натоварване Generators или инжектори за натоварване.

Като обща практика контролерът се намира на различна машина и натоварването се симулира от други машини. В зависимост от протокола на VUser скриптовете и спецификациите на машината, за пълна симулация може да са необходими няколко Load Injectors. Например VUsers за HTTP скрипт ще изискват 2-4MB на VUser за симулация, следователно ще са необходими 4 машини с 4 GB RAM всяка за симулиране на натоварване от 10,000 XNUMX VUsers.

Взимайки аналогия от нашия Amazon Например изходът на този компонент ще бъде

Анализ

След като сценариите за зареждане са изпълнени, ролята на „Анализ” идват компоненти на LoadRunner.

По време на изпълнението Controller създава дъмп на резултатите в сурова форма и съдържа информация като коя версия на LoadRunner е създала този дъмп на резултатите и какви са били конфигурациите.

Всички грешки и изключения се записват в a Microsoft достъп до база данни, именуван, output.mdb. Компонентът „Анализ“ чете този файл с база данни, за да извършва различни видове анализи и генерира графики.

Тези графики показват различни тенденции, за да се разбере причината за грешките и отказите при натоварване; по този начин помага да се разбере дали е необходима оптимизация в SUL, сървър (напр. JBoss, Oracle) или инфраструктура.

По-долу е даден пример, при който честотната лента може да създава пречка. Да кажем, че уеб сървърът има капацитет от 1 GBps, докато трафикът на данни надвишава този капацитет, причинявайки страдания на следващите потребители. За да определи, че системата отговаря на такива нужди, Performance Engineer трябва да анализира поведението на приложението с необичайно натоварване. По-долу е дадена графика, която LoadRunner генерира, за да извлече честотна лента.

Как да направите тестване на производителността

Пътната карта за тестване на ефективността може да бъде разделена най-общо на 5 стъпки:

• Планиране на тест за натоварване
• Създайте VUGen скриптове
• Създаване на сценарий
• Изпълнение на сценария
• Анализ на резултатите (последван от настройка на системата)

Сега, след като сте инсталирали LoadRunner, нека разберем стъпките, включени в процеса една по една.

Стъпки, включени в процеса на тестване на производителността

Стъпка 1) Планиране на теста за натоварване

Планирането за тестване на ефективността е различно от планирането на a SIT (тестване за системна интеграция) or UAT (User Acceptance Test). Планирането може да бъде допълнително разделено на малки етапи, както е описано по-долу:

Съберете своя екип

Когато започнете с тестването на LoadRunner, най-добре е да документирате кой ще участва в дейността от всеки екип, участващ по време на процеса.

Ръководител проект:

Номинирайте ръководителя на проекта, който ще притежава тази дейност и ще служи като точково лице за ескалация.

Функция експерт/ бизнес анализатор:

Осигурява анализ на използването на SUL и предоставя експертиза относно бизнес функционалността на уебсайта/SUL

Експерт по тестване на ефективността:

Създава автоматизирани тестове за производителност и изпълнява сценарии за натоварване

Система Archiтект:

Предоставя план на SUL

Уеб програмист и МСП:

• Поддържа уебсайт и предоставя аспекти на наблюдение
• Разработва уебсайт и коригира грешки

системен администратор:

• Поддържа включените сървъри по време на проект за тестване

Очертайте приложения и включени бизнес процеси:

Успешното Тестване на товара изисква да планирате да извършите определен бизнес процес. Бизнес процесът се състои от ясно дефинирани стъпки в съответствие с желаните бизнес транзакции – така че да постигнете целите си при тестване на натоварването.

Метриката на изискванията може да бъде изготвена, за да предизвика потребителско натоварване на системата. По-долу е даден пример за система за присъствие във фирма:

В горния пример цифрите споменават броя на потребителите, свързани с приложението (SUL) в даден час. Можем да извлечем максималния брой потребители, свързани с бизнес процес във всеки час от деня, който се изчислява в най-десните колони.

По същия начин можем да заключим общия брой потребители, свързани с приложението (SUL) във всеки час от деня. Това се изчислява в последния ред.

Комбинацията от горните 2 факта ни дава общия брой потребители, с които трябва да тестваме ефективността на системата.

Дефиниране на процедури за управление на тестови данни

Статистиката и наблюденията, извлечени от тестването на производителността, са силно повлияни от множество фактори, както беше споменато по-рано. От критично значение е да подготвите тестови данни за тестване на производителността. Понякога определен бизнес процес консумира набор от данни и произвежда различен набор от данни. Вземете примера по-долу:

• Потребител „А“ създава финансов договор и го изпраща за преглед.
• Друг потребител „B“ одобрява 200 договора на ден, създадени от потребител „A“
• Друг потребител „C“ плаща около 150 договора на ден, одобрени от потребител „B“

В тази ситуация потребител B трябва да има 200 „създадени“ договора в системата. Освен това потребител C се нуждае от 150 договора като „одобрени“, за да симулира натоварване от 150 потребители.

Това имплицитно означава, че трябва да създадете поне 200+150= 350 договора.

След това одобрете 150 договора, които да служат като тестови данни за потребител C – останалите 200 договора ще служат като тестови данни за потребител B.

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

Спекулирайте с всеки фактор, който евентуално би могъл да повлияе на работата на системата. Например, намаляването на хардуера ще има потенциално въздействие върху производителността на SUL (система под натоварване).

Включете всички фактори и настройте монитори, за да можете да ги прецените. Ето няколко примера:

• Процесор (за уеб сървър, сървър на приложения, сървър на база данни и инжектори)
• RAM (за уеб сървър, сървър на приложения, сървър на база данни и инжектори)
• Сървър за уеб/приложения (например IIS, JBoss, Jaguar Server, Tomcat и т.н.)
• DB сървър (PGA и SGA размер в случай на Oracle и MSSQL сървър, SPs и др.)
• Използване на честотната лента на мрежата
• Вътрешен и външен NIC в случай на групиране
• Load Balancer (и че той разпределя натоварването равномерно върху всички възли на клъстери)
• Поток от данни (изчислете колко данни се движат към и от клиент и сървър – след това изчислете дали капацитетът на NIC е достатъчен за симулиране на X брой потребители)

Стъпка 2) Създайте VUGen скриптове

Следващата стъпка след планирането е създаването VUser скриптове.

Стъпка 3) Създаване на сценарий

Следващата стъпка е да създадете своя сценарий за зареждане

Стъпка 4) Изпълнение на сценария

Изпълнението на сценарий е мястото, където емулирате потребителско натоварване на сървъра, като инструктирате множество VUsers да изпълняват задачи едновременно.

Можете да зададете нивото на натоварване, като увеличавате и намалявате броя на VUsers, които изпълняват задачи по едно и също време.

Това изпълнение може да доведе до стрес на сървъра и необичайно поведение. Това е самата цел на тестването на производителността. След това получените резултати се използват за подробен анализ и идентифициране на първопричината.

Стъпка 5) Анализ на резултатите (последван от настройка на системата)

По време на изпълнението на сценария LoadRunner записва производителността на приложението при различни натоварвания. Статистиката, извлечена от изпълнението на теста, се запазва и се извършва подробен анализ. Инструментът „HP Analysis“ генерира различни графики, които помагат при идентифицирането на първопричините зад изоставането в производителността на системата, както и системната повреда.

Някои от получените графики включват:

• Време до първия буфер
• Време за отговор на транзакцията
• Средно време за отговор на транзакция
• Посещения в секунда
• Windows Ресурси
• Статистика на грешките
• Резюме на транзакцията

ЧЗВ