Шта је ХП ЛоадРуннер алат за тестирање? Архитектура, компоненте

Шта је ЛоадРуннер?

ЛоадРуннер је алат за тестирање перформанси који је Мерцури пионир 1999. године. ЛоадРуннер је касније купио ХПЕ 2006. године. ЛоадРуннер је купио МицроФоцус.

ЛоадРуннер подржава разне развојне алате, технологије и комуникационе протоколе. У ствари, ово је једини алат на тржишту који подржава тако велики број протокола за спровођење тестирања перформанси. Резултати тестова перформанси које производи софтвер ЛоадРуннер користе се као референтна вредност за друге алате

У овом упутству ћете научити-

• Зашто ЛоадРуннер?
• Зашто вам је потребно тестирање перформанси?
• Шта је ЛоадРуннер Арцхитецтуре?
• План за тестирање перформанси: детаљни кораци
• ФАК

Зашто ЛоадРуннер?

ЛоадРуннер није само пионирски алат у тестирању перформанси, већ је и даље тржишни лидер у парадигми тестирања перформанси. У недавној процени, ЛоадРуннер има око 85% тржишног удела у индустрији за тестирање перформанси.

Алат ЛоадРуннер широко подржава РИА (богате Интернет апликације), Веб 2.0 (ХТТП / ХТМЛ, Ајак, Флек и Силверлигхт итд.), Мобиле, САП, Орацле, МС СКЛ Сервер, Цитрик, РТЕ, Маил и, пре свега, Виндовс Соцкет. На тржишту не постоји конкурентски алат који би могао да понуди тако широку палету протокола који су повезани једним алатом.

Оно што је убедљивије одабрати ЛоадРуннер у тестирању софтвера је кредибилитет овог алата. Алат ЛоадРуннер одавно је стекао репутацију јер ћете често наћи клијенте како унакрсно верификују своје перформансе помоћу ЛоадРуннер-а. Олакшање ћете пронаћи ако већ користите ЛоадРуннер за потребе тестирања перформанси.

Софтвер ЛоадРуннер чврсто је интегрисан са другим ХП алаткама као што су Обједињени функционални тест (КТП) и АЛМ (управљање животним циклусом апликација), омогућавајући вам да извршите своје поступке тестирања од краја до краја.

ЛоадРуннер ради на принципу симулације виртуелних корисника на предметној апликацији. Ови виртуелни корисници се такође називају ВУсерс, реплицирају захтеве клијента и очекују одговарајући одговор на прослеђивање трансакције.

Зашто вам је потребно тестирање перформанси?

Процењени губитак прихода од 4,4 милијарде годишње бележи се због лоших веб перформанси.

У данашње доба Веба 2.0 корисници кликну ако веб локација не одговори у року од 8 секунди. Замислите да чекате 5 секунди док тражите Гоогле или захтевате пријатељство на Фацебоок-у. Последице застоја у раду су често поразније него што је икада замишљено. Имамо примере попут оних који су недавно погодили банкарство банке Банк оф Америца на мрежи, Амазон Веб Сервицес, Интуит или Блацкберри.

Према Дунн & Брадстреет-у, 59% компанија из Фортуне 500 сваке недеље има око 1,6 сати застоја. Узимајући у обзир да просечна компанија Фортуне 500 са најмање 10.000 запослених плаћа 56 долара на сат, део трошкова застоја у раду за такву организацију износио би 896.000 америчких долара недељно, што значи више од 46 милиона америчких долара годишње.

Процењује се да ће само петоминутни застој на Гоогле.цом (19. августа 13.) коштати претраживачког гиганта чак 545.000 америчких долара.

Процењује се да су компаније изгубиле продају у вредности од 1100 долара у секунди због недавног прекида рада Амазон Веб Сервице.

Када организација имплементира софтверски систем, она може наићи на много сценарија који могу довести до кашњења перформанси. Бројни фактори узрокују успоравање перформанси, неколико примера може садржати:

• Повећан број записа присутних у бази података
• Повећан број истовремених захтева упућених систему
• већи број корисника који истовремено приступају систему у поређењу са прошлошћу

Шта је ЛоадРуннер Арцхитецтуре?

Уопштено говорећи, архитектура ХП ЛоадРуннер је сложена, али је лако разумљива.

Претпоставимо да сте задужени за проверу перформанси Амазон.цом за 5000 корисника

У стварној ситуацији, свих ових 5000 корисника неће бити на почетној страници, већ у другом одељку веб локација. Како можемо другачије симулирати

ВУГен:

ВУГен или Виртуал Усер Генератор је ИДЕ (Интегрисано развојно окружење) или богати уређивач кодирања. ВУГен се користи за копирање понашања система под оптерећењем (СУЛ). ВУГен пружа функцију „снимања“ која снима комуникацију са клијента и сервера у облику кодиране скрипте - која се такође назива ВУсер скрипта.

Дакле, узимајући у обзир горњи пример, ВУГен може снимати да симулира следеће пословне процесе:

1. Сурфовање по страници производа Амазон.цом
2. Проверити
3. Обрада плаћања
4. Провера странице МиАццоунт

Контролер

Једном када је скрипта ВУсер финализована, Цонтроллер је једна од главних компонената ЛоадРуннер-а која управља симулацијом учитавања управљајући, на пример:

• Колико корисника да симулира против сваког пословног процеса или групе корисника
• Понашање корисника (појачавање, смањивање, истовремена или истовремена природа итд.)
• Природа сценарија оптерећења, нпр. Стварни живот или циљ или верификација СЛА
• Које млазнице користити, колико ВУсерс-а против сваке ињекторке
• Повремено сакупљајте резултате
• ИП споофинг
• Пријави грешку
• Извештавање о трансакцијама итд.

Узимајући аналогију из нашег примера контролера, додаће се следећи параметар ВУГен скрипти

1) 3500 корисника претражује страницу производа Амазон.цом

2) 750 корисника је на Цхецкоут-у

3) 500 корисника врши обраду плаћања

4) 250 корисника проверава страницу мог рачуна САМО након што 500 корисника изврши обраду плаћања

Могући су и сложенији сценарији

1. Покрените 5 корисника током 2 секунде док се не постигне оптерећење од 3500 корисника (сурфање Амазоновом страницом производа).
2. Итерајте 30 минута
3. Обуставите итерацију за 25 корисника
4. Поново покрените 20 корисника
5. Покрените 2 корисника (у Цхецкоут, Процессинг Паимент, МиАццоунтс Паге) сваке секунде.
6. 2500 корисника ће се генерисати на машини А.
7. 2500 корисника ће се генерисати на машини Б.

Агенти Машина / Генератори оптерећења / Ињектори

ХП ЛоадРуннер Цонтроллер одговоран је за симулацију хиљада ВУсер-а - ови ВУсерс троше хардверске ресурсе, на пример процесор и меморију - и тиме стављају ограничење на машину која их симулира. Поред тога, Цонтроллер симулира ове ВУсере са исте машине (где Цонтроллер борави), па резултати можда неће бити прецизни. Да би се позабавили овом забринутошћу, сви корисници ВУ-а расподељени су на различитим машинама, названим генераторима оптерећења или ињекторима оптерећења.

Као општа пракса, Цонтроллер се налази на другој машини и оптерећење се симулира од других машина. У зависности од протокола ВУсер скрипти и спецификација машине, за потпуну симулацију може бити потребан одређени број ињектора оптерећења. На пример, ВУсерс-у за ХТТП скрипту биће потребно 2-4МБ по ВУсер-у за симулацију, па ће зато бити потребне 4 машине са 4 ГБ РАМ-а за симулацију оптерећења од 10.000 ВУсерс-а.

Узимајући Аналогију из нашег Амазон примера, излаз ове компоненте ће бити

Анализа:

Једном када се изврше сценарији учитавања, долази до улоге компоненти „ Анализа “ у ЛоадРуннер-у.

Током извршавања, Цонтроллер креира депониј резултата у сировом облику и садржи информације попут тога која је верзија ЛоадРуннер креирала ову депонију резултата и које су биле конфигурације.

Све грешке и изузеци евидентирају се у Мицрософт приступној бази података, под називом оутпут.мдб. Компонента "Анализа" чита ову датотеку базе података за обављање различитих врста анализа и генерише графиконе.

Ови графикони приказују различите трендове да би се разумело образложење грешака и неуспеха под оптерећењем; на тај начин помажу да се утврди да ли је потребна оптимизација у СУЛ-у, серверу (нпр. ЈБосс, Орацле) или инфраструктури.

Испод је пример где пропусност може створити уско грло. Рецимо да веб сервер има капацитет од 1 ГБпс, док промет података премашује овај капацитет што узрокује патњу наредних корисника. Да би одредио систем који задовољава такве потребе, Перформанце Енгинеер мора да анализира понашање апликације са ненормалним оптерећењем. Испод је графикон који ЛоадРуннер генерише да би изазвао пропусност.

План за тестирање перформанси: детаљни кораци

План тестирања учинка може се у целини поделити у 5 корака:

• Планирање испитивања оптерећења
• Креирајте ВУГен скрипте
• Стварање сценарија
• Извршење сценарија
• Анализа резултата (праћено подешавањем система)

Сада када сте инсталирали ЛоадРуннер, хајде да разумемо кораке који су укључени у процес један по један.

Кораци укључени у процес тестирања перформанси

Планирање теста оптерећења

Планирање за испитивање перформанси разликује се од планирања СИТ (тестирање интеграције система) или УАТ (тестирање прихватљивости корисника). Планирање се даље може поделити на мале фазе како је описано у наставку:

Окупите свој тим

Када започнете са ЛоадРуннер тестирањем, најбоље је документовати ко ће учествовати у активности од сваког тима укљученог током процеса.

Вођа пројекта:

Номинирајте менаџера пројекта који ће бити власник ове активности и служити као тачка за ескалацију.

Стручњак за функције / пословни аналитичар:

Пружите анализу употребе СУЛ-а и пружате стручност у вези са пословном функционалношћу веб странице / СУЛ

Стручњак за испитивање перформанси:

Ствара аутоматизоване тестове перформанси и извршава сценарије учитавања

Системски архитекта:

Пружа нацрт СУЛ-а

Веб програмер и МСП:

• Одржава веб страницу и пружа аспекте праћења
• Развија веб страницу и отклања грешке

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

• Одржава укључене сервере током пројекта тестирања

Оквирне апликације и укључени пословни процеси:

Успешно тестирање оптерећења захтева да планирате да спроведете одређени пословни процес. Пословни процес се састоји од јасно дефинисаних корака у складу са жељеним пословним трансакцијама - како би се постигли ваши циљеви испитивања оптерећења.

Може се припремити метрика захтева како би се изазвало оптерећење корисника на систему. Испод је пример система похађања предузећа:

У горњем примеру, бројке помињу број корисника повезаних са апликацијом (СУЛ) у датом сату. У било који сат у дану можемо израчунати максималан број корисника повезаних са пословним процесом који се израчунава у најдеснијим колонама.

Слично томе, можемо закључити укупан број корисника повезаних са апликацијом (СУЛ) у било ком сату дана. Ово се израчунава у последњем реду.

Горе наведене 2 чињенице дају нам укупан број корисника са којима морамо да тестирамо перформансе система.

Дефинишите процедуре за управљање подацима о тестирању

На статистику и запажања изведена из испитивања учинка у великој мери утичу бројни фактори о којима је раније речено. Од пресудног је значаја припрема података о испитивању за испитивање перформанси. Понекад одређени пословни процес троши скуп података и производи другачији скуп података. Узмите доњи пример:

• Корисник „А“ креира финансијски уговор и подноси га на увид.
• Други корисник „Б“ одобрава 200 уговора дневно које креира корисник „А“
• Други корисник „Ц“ плаћа око 150 уговора дневно које одобрава корисник „Б“

У овој ситуацији, корисник Б треба да има 200 „креираних“ уговора у систему. Поред тога, кориснику Ц је потребно 150 уговора као „одобрених“ како би симулирао оптерећење од 150 корисника.

То имплицитно значи да морате створити најмање 200 + 150 = 350 уговора.

Након тога, одобрите 150 уговора који ће служити као тест подаци за корисника Ц - преосталих 200 уговора послужиће као тест подаци за корисника Б.

Оутлине Мониторс

Нагађајте сваки фактор који би могао утицати на перформансе система. На пример, смањење хардвера имаће потенцијални утицај на перформансе СУЛ (систем под оптерећењем).

Наведите све факторе и подесите мониторе како бисте их могли мерити. Ево неколико примера:

• Процесор (за веб сервер, сервер апликација, сервер базе података и ињекторе)
• РАМ (за веб сервер, сервер апликација, сервер базе података и ињекторе)
• Веб / Апп Сервер (на пример ИИС, ЈБосс, Јагуар Сервер, Томцат итд.)
• ДБ сервер (величина ПГА и СГА у случају Орацле и МССКЛ сервера, СП-ова итд.)
• Коришћење мрежног опсега
• Интерни и екстерни НИЦ у случају кластерисања
• Лоад Баланцер (и да равномерно распоређује оптерећење на свим чворовима кластера)
• Преток података (израчунајте колико се података премешта на и са клијента и сервера - а затим израчунајте да ли је капацитет НИЦ-а довољан да симулира Кс број корисника)

Креирајте ВУГен скрипте

Следећи корак након планирања је стварање ВУсер скрипти.

Стварање сценарија

Следећи корак је креирање вашег сценарија учитавања

Извршење сценарија

Извршење сценарија је место где опонашате оптерећење корисника на серверу упућујући више корисника да истовремено извршавају задатке.

Можете да подесите ниво оптерећења повећавањем и смањењем броја корисника који истовремено извршавају задатке.

Ово извршавање може довести до тога да сервер постане под стресом и понаша се необично. То је сама сврха тестирања перформанси. Извучени резултати се затим користе за детаљну анализу и идентификацију основног узрока.

Анализа резултата (праћено подешавањем система)

Током извршавања сценарија, ЛоадРуннер бележи перформансе апликације под различитим оптерећењима. Статистика извучена из извршавања теста се чува и врши се анализа детаља. Алатка „ХП анализа“ генерише различите графиконе који помажу у идентификовању основних узрока заостајања перформанси система, као и системског квара.

Неки од добијених графикона укључују:

• Време је за први бафер
• Време одзива трансакције
• Просечно време одзива трансакције
• Хитс пер Сецонд
• Виндовс ресурси
• Статистика грешака
• Резиме трансакције

ФАК

Које апликације треба тестирати?

Тестирање перформанси се увек врши само за системе засноване на клијент-серверу. То значи да било која апликација која није архитектура заснована на клијент-серверу не сме захтевати тестирање перформанси.

На пример, Мицрософт Калкулатор није заснован на клијент-серверу нити покреће више корисника; стога није кандидат за тестирање перформанси.

Која је разлика између тестирања перформанси и инжењерства перформанси

Значајно је разумети разлику између испитивања перформанси и инжењерства перформанси. У наставку се дели разумевање:

Тестирање перформанси је дисциплина која се бави тестирањем и извештавањем о тренутним перформансама софтверске апликације под различитим параметрима.

Инжењеринг перформанси је поступак којим се софтвер тестира и подешава са намером да оствари потребне перформансе. Овај процес има за циљ оптимизацију најважније особине перформанси апликације, односно корисничког искуства.

Историјски гледано, тестирање и подешавање били су изразито одвојени и често се надмећу. У последњих неколико година, међутим, неколико џепова тестера и програмера сарађивало је независно на стварању тимова за подешавање. Будући да су ови тимови наишли на значајан успех, концепт повезивања тестирања перформанси са подешавањем перформанси се ухватио, а сада то називамо инжењеринг перформанси.