Комплетан водич за тестирање оптерећења за почетнике

load testing complete guide

Комплетан водич за испитивање оптерећења за почетнике:

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

Чули смо и за функционално и за нефункционално испитивање. У нефункционалном тестирању имамо различите врсте тестирања као што су испитивање перформанси, тестирање сигурности, тестирање корисничког интерфејса итд.

Стога је испитивање оптерећења нефункционална врста испитивања која је подскуп испитивања перформанси.

Дакле, када кажемо да тестирамо апликацију за перформансе, шта све овде тестирамо? Тестирамо апликацију за оптерећење, запремину, капацитет, стрес итд.

Шта ћете научити:

• Шта је испитивање оптерећења?
• Архитектура теста оптерећења
• Зашто тестирање оптерећења?
• Животна средина
• Приступ
• Најбоље праксе
• Закључак
• Препоручено читање

Шта је испитивање оптерећења?

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

Стога, кад год модификујемо оптерећење, надгледамо понашање система под различитим условима.

Пример :Претпоставимо да је захтев нашег клијента за страницу за пријављивање 2-5 секунди и да би ових 2-5 секунди требало да буде доследно све док учитавање не достигне 5000 корисника. Па шта треба да посматрамо да чујемо? Да ли је то само способност управљања оптерећењем система или је то само захтев времена одзива?

Одговор је оба. Желимо систем који може да поднесе оптерећење од 5000 корисника са временом одзива 2-5 секунди за све истовремене кориснике.

Дакле, шта се подразумева под истовременим и виртуелним корисником?

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

Архитектура теста оптерећења

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

Након заштитног зида имамо Лоад баланцер који дистрибуира оптерећење на било који од веб сервера, а затим прелази на сервер апликација, а касније и на сервер базе података, где узима потребне информације на основу корисничког захтева.

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

Пример: Претпоставимо да желимо да тестирамо апликацију за куповину на мрежи како бисмо видели време одзива апликације за сваки клик корисника, тј. Степ1 –Лаунцх УРЛ, време одзива, пријава у апликацију и бележење времена одзива итд., Попут одабира производа, додавање у корпу, плаћање и одјава. Све ово мора да се уради за 10 корисника.

Дакле, сада када треба да тестирамо оптерећење апликације за 10 корисника, то можемо постићи ручним стављањем оптерећења од 10 физичких корисника са различитих машина уместо да користимо алат. У овом сценарију, препоручљиво је ићи на ручно испитивање оптерећења, уместо да улажете у алат и постављате окружење за алат.

Док замислимо да ако требамо учитати тест за 1500 корисника, онда морамо аутоматизовати тест оптерећења користећи било који од доступних алата заснован на технологијама у којима је апликација изграђена и такође на основу буџета који имамо за пројекат.

Ако имамо буџет, онда можемо да користимо комерцијалне алате попут Лоад руннер, али ако немамо пуно буџета, онда можемо да користимо алате отвореног кода попут ЈМетер итд.

како отворити јар датотеке на прозорима

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

У аутоматизованом тестирању оптерећења, замењујемо кориснике помоћу алата за аутоматизацију, који опонаша радње корисника у стварном времену. Аутоматизацијом оптерећења можемо уштедети ресурсе као и време.

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

Зашто тестирање оптерећења?

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

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

Стога је овог великог дана компанија морала да се суочи са великим губицима јер је изгубила много купаца и много посла. Све се ово догодило само зато што нису предвидели оптерећење корисника за вршне дане, чак и ако би предвидели да на веб локацији компаније није извршен тест учитавања, па стога не знају са колико оптерећења ће апликација моћи да поднесе у дане шпица.

Стога, за решавање таквих ситуација и за превазилажење огромног прихода, препоручљиво је извршити тест оптерећења за такву врсту апликација.

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

Шта се постиже током теста оптерећења?

Правилним тестом оптерећења можемо тачно разумети следеће:

1. Број корисника којима систем може приступити или их може прилагодити.
2. Време одзива сваке трансакције.
3. Како се понаша свака компонента читавог система под Лоад и.е компоненте апликационог сервера, компоненте веб сервера, компоненте базе података итд.
4. Која је конфигурација сервера најбоља за руковање оптерећењем?
5. Да ли је постојећи хардвер довољан или постоји потреба за додатним хардвером.
6. Утврђена су уска грла попут коришћења ЦПУ-а, употребе меморије, мрежних кашњења итд.

Животна средина

За спровођење тестова потребно нам је наменско окружење за испитивање оптерећења. Будући да ће окружење за тестирање оптерећења већином бити исто као и производно окружење, а такође ће и подаци доступни у окружењу за тестирање оптерећења бити исти као и производни, иако то нису исти подаци.

Биће више тестних окружења попут СИТ окружења, КА окружења итд., Ова окружења нису иста продукција, јер за разлику од тестирања оптерећења, њима није потребно толико сервера или толико података о тестирању за спровођење функционалног тестирања или интеграционог тестирања.

Пример:

У производном окружењу имамо 3 апликациона сервера, 2 веб сервера и 2 сервера базе података. У КА имамо само 1 сервер апликација, 1 веб сервер и 1 сервер базе података. Дакле, ако спроведемо тест оптерећења на КА окружењу који није једнак производном, онда наши тестови нису важећи, а такође су нетачни и самим тим не можемо да се придржавамо ових резултата.

Стога увек покушајте да имате наменско окружење за испитивање оптерећења које је слично окружењу производног окружења.

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

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

Приступ

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

Такође су нам потребне информације о томе колика је тренутна способност руковања апликацијама. Ако се ради о новој апликацији, морамо да разумемо захтеве, које је циљно оптерећење, које је очекивано време одзива и да ли је то заиста могуће или не.

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

Једном када имамо захтеве, морамо да утврдимо како ћемо извршити тест оптерећења. Да ли се то ради ручно или помоћу алата? Ручно обављање теста оптерећења захтева пуно ресурса и такође је веома скупо. Такође ће бити тешко понављати тест, изнова и изнова.

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

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

Наш приступ испитивању оптерећења биће следећи:

# 1) Идентификујте критеријуме прихватања теста оптерећења

На пример:

1. Време одзива странице за пријаву не би требало да буде дуже од 5 секунди, чак и током услова максималног учитавања.
2. Коришћење процесора не би требало да буде веће од 80%.
3. Пропусност система треба да буде 100 трансакција у секунди.

# 2) Утврдите пословне сценарије које треба тестирати.

Не тестирајте све токове, покушајте да разумете главне пословне токове који се очекују у производњи. Ако се ради о постојећој апликацији, његове податке можемо добити из дневника сервера производног окружења.

Ако је реч о новоизграђеној апликацији, тада морамо сарађивати са пословним тимовима да бисмо разумели обрасце тока, употребу апликација итд. Понекад ће пројектни тим водити радионице како би дао преглед или детаље о свакој компоненти апликације.

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

# 3) Моделовање радног оптерећења

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

Кључне тачке које треба имати на уму приликом дизајнирања модела радног оптерећења је видети колико ће времена требати одређеном пословном току. Овде треба да доделимо време за размишљање на такав начин да ће се корисник кретати кроз апликацију на реалнији начин.

Узорак радног оптерећења обично ће бити са Рампом према горе, Рампом према доле и у стабилном стању. Требали бисмо полако учитавати систем и тако се користе појачавање и смањивање. Стабилно стање ће обично бити једносатни тест оптерећења са рампом до 15 минута и рамом до 15 минута.

Узмимо пример модела оптерећења:

Преглед апликације - Претпоставимо онлајн куповину, где ће се корисници пријавити у апликацију и имати широку палету хаљина за куповину, а могу се кретати кроз сваки производ.

Да би видели детаље о сваком производу, треба да кликну на производ. Ако им се свиђа цена и начин израде производа, онда могу да додају у корпу и купе производ тако што ће се одјавити и извршити уплату.

Доље је дата листа сценарија:

1. Прегледајте - Овде корисник покреће апликацију, пријављује се у апликацију, прегледава различите категорије и одјављује се из апликације.
2. Прегледајте, погледајте производ, додајте у корпу - Овде се корисник пријављује у апликацију, прегледава различите категорије, прегледава детаље о производу, додаје производ у корпу и одјављује се.
3. Прегледајте, погледајте производ, додајте у корпу и одјавите се - У овом сценарију, корисник се пријављује у апликацију, прегледава различите категорије, прегледава детаље о производу, додаје производ у корпу, врши одјаву и одјаву.
4. Прегледајте, Преглед производа, Додајте у корпу Одјави се и врши плаћање - Овде се корисник пријављује у апликацију, прегледава различите категорије, прегледава детаље о производу, додаје производ у корпу, врши одјаву, врши плаћање и одјави се.

Горе наведене вредности изведене су на основу следећих прорачуна:

• Трансакције по сату = Број корисника * Трансакције које је извршио један корисник у једном сату.
• Број корисника = 1600.
• Укупан број трансакција у сценарију Прегледај = 17.
• Време одзива за сваку трансакцију = 3.
• Укупно време за једног корисника да изврши 17 трансакција = 17 * 3 = 51 заокружено на 60 секунди (1 мин).
• Трансакције по сату = 1600 * 60 = 96000 трансакција.

# 4) Дизајнирајте тестове оптерећења- Тест оптерећења треба да буде дизајниран са подацима које смо до сада прикупили, тј. Токовима пословања, бројем корисника, обрасцима корисника, метрикама које треба прикупити и анализирати. Штавише, тестови треба да буду дизајнирани на много реалнији начин.

# 5) Извршите тест оптерећења - Пре него што извршимо тест учитавања, уверите се да је апликација покренута и покренута. Окружење за тестирање оптерећења је спремно. Апликација је функционално тестирана и стабилна је.

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

Увек започните са малим оптерећењем и постепено повећавајте оптерећење. Никада немојте започети са пуним оптерећењем и сломити систем.

# 6) Анализирајте резултате теста оптерећења - Имајте основни тест који ћете увек упоређивати са осталим пробама. Прикупите метрику и евиденције сервера након пробног рада да бисте пронашли уска грла.

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

Неки од АПМ алата на тржишту укључују ДинаТраце, Вили Интросцопе, Апп Динамицс итд.

# 7) Извештавање - Када се пробно тестирање заврши, сакупите све показатеље и пошаљите извештај са резимеом теста одговарајућем тиму са својим запажањима и препорукама.

Најбоље праксе

У наставку су наведене неке од најбољих пракси испитивања оптерећења:

# 1) Увек проверите стабилност апликације пре почетка теста оптерећења. Тим за функционално тестирање треба да функционално стабилно потпише апликацију, а све главне недостатке треба отклонити и тестирати пре него што се израда копира у окружење за тестирање учитавања.

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

# 3) Проверите да ли су подаци о тестирању јединствени и да ли имамо све податке о тестирању копиране у окружење оптерећења пре извођења теста оптерећења.

# 4) Дизајнирајте тест сценарије на такав начин да опонашају радњу корисника у стварном времену која се дешава у производњи.

# 5) Дизајнирајте оптерећење на основу оптерећења производних корисника и пословних токова, а у случају старе апликације погледајте да ли је то нови разговор са пословним тимом у вези са пословним токовима и оптерећењем корисника.

# 6) Прикупите све важне метрике као што су време одзива, погоци у секунди, проток, процесор, меморија, мрежа и покретање корисника.

Препоручено читање => Листа алата за испитивање перформанси доступних на тржишту за спровођење ексклузивног испитивања оптерећења.

Закључак

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

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

Срећно читање !!

Препоручено читање

• Испитивање оптерећења помоћу ХП ЛоадРуннер водича
• Алфа тестирање и бета тестирање (потпун водич)
• Водич за тестирање безбедности веб апликација
• Водич за тестирање напрезања за почетнике
• Водич за почетнике за тестирање продора веб апликација
• Комплетан нефункционални водич за тестирање за почетнике
• Комплетни водич за тестирање верификације израде (БВТ тестирање)
• Испитивање перформанси вс испитивање оптерећења вс тестирање напрезања (разлика)