Какво представлява инструментът за тестване на HP LoadRunner? Архитектура, компоненти

Какво е LoadRunner?

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

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

В този урок ще научите -

• Защо LoadRunner?
• Защо се нуждаете от тестване на ефективността?
• Какво е LoadRunner Architecture?
• Пътна карта за тестване на ефективността: подробни стъпки
• ЧЗВ

Защо 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 Online Banking, 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 Web Service.

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

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

Какво е LoadRunner Architecture?

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

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

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

VUGen:

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

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

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

Контролер

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

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

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

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

2) 750 потребители са в Checkout

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

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

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

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

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

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

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

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

Анализ:

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

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

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

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

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

Пътна карта за тестване на ефективността: подробни стъпки

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

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

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

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

Планиране на теста за натоварване

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

Съберете екипа си

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

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

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

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

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

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

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

Архитект на системата:

Осигурява план на SUL

Уеб разработчик и МСП:

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

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

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

Контурни приложения и участващи бизнес процеси:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Създаване на сценарий

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

Изпълнение на сценарий

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

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

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

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

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

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

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

ЧЗВ

Кои приложения трябва да тестваме?

Тестването на производителността винаги се извършва само за системи, базирани на клиент-сървър. Това означава, че всяко приложение, което не е базирана на клиент-сървър архитектура, не трябва да изисква тестване на производителността.

Например, Microsoft Calculator не е нито клиент-сървър, нито работи с множество потребители; следователно не е кандидат за тестване на ефективността.

Каква е разликата между Тестване на ефективността и Инженеринг на ефективността

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

Тестване на производителността е дисциплина, занимаваща се с тестване и отчитане на текущата производителност на софтуерно приложение при различни параметри.

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

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