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

complete performance testing guide with examples

Шта је испитивање перформанси?

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

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

пл скл интервју питања и одговори за искусне пдф

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

Ово је детаљна серија туторијала коју бисте можда желели да додате у обележиваче!

Истражимо!

Листа СВИХ водича за испитивање перформанси у овој серији:

Туториал # 1: Комплетан водич за тестирање перформанси (Овај водич)
Туториал # 2: Разлика између испитивања перформанси, оптерећења и напрезања
Туториал # 3: Функционално тестирање против тестирања перформанси
Туториал # 4: План испитивања учинка и стратегија испитивања
Водич бр. 5: Начини за надопуњавање вашег тестирања перформанси
Лекција # 6: Водич за тестирање перформанси у облаку
Туториал # 7: Водич за тестирање перформанси мобилне апликације
Туториал # 8: Како извршити ручно тестирање перформанси
Туториал # 9: Водич за тестирање перформанси веб страница
Водич бр. 10: Компаније за тестирање перформанси
Туториал # 11: Тестирање перформанси помоћу ЛоадРуннера (Сериес)

Алати:

Водич бр. 12: Алати за тестирање врхунских перформанси
Водич бр. 13: Водич за тестирање перформанси Неолоад-а
Водич # 14: Водич за тест перформанси за мобилне уређаје БлазеМетер
Водич бр. 15: Водич за тестирање оптерећења, стреса и перформанси ВАПТ-а
Туториал # 16: Водич за тестирање перформанси веб странице СмартМетер.ио

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

• Врсте испитивања перформанси
  • Испитивање оптерећења
  • Тестирање напрезања
  • Тестирање запремине
  • Испитивање капацитета
  • Испитивање поузданости / опоравка
• Процес испитивања перформанси
• Како написати документ о стратегији испитивања перформанси?
  • Узорак предлошка стратегије испитивања перформанси
  • #1. Представљање
    • објективан
    • Архитектура
  • # 2) Обим
    • Ин Сцопе
    • Изван опсега
  • # 3) Приступ
    • Сценарији испитивања перформанси
    • Врсте тестова перформанси
    • Показатеље учинка
    • Активности и резултати тестирања перформанси
  • # 4) Подаци о тестирању
  • # 5) Критеријуми за улазак и излазак
  • # 6) Управљање недостацима
    • Дефиниција озбиљности недостатака
  • # 7) Алати и технике за тестирање
  • # 8) Критеријуми суспензије и поновног покретања
  • # 9) Резултати испоруке
  • # 10) Улоге и одговорности
  • # 11) Потенцијални ризици и план ублажавања
  • # 12) Претпоставке
  • # 13) Зависности
  • # 14) Скраћенице
• Најбоље праксе за реалистично тестирање перформанси
  • # 1) Планирање
  • # 2) Развој
  • # 3) Извршење
  • # 4) Анализа
  • Закључак
  • Препоручено читање

Врсте испитивања перформанси

Испитивање оптерећења

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

Кључна разматрања су:

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

Тестирање напрезања

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

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

Треба одговорити на следећа питања:

• Које је максимално оптерећење који систем може поднети пре него што се поквари?
• Како се систем квари?
• Да ли се систем може опоравити након пада?
• На колико начина се систем може сломити и који су слаби чвор при руковању неочекиваним оптерећењем?

Тестирање запремине

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

Генерално, са употребом апликације, величина базе података расте и неопходно је тестирати апликацију на тешкој бази података. Добар пример за то може бити веб локација нове школе или колеџа која у почетку има мале количине података, али након 5-10 година података у бази података веб локације је много више.

Испитивање капацитета

=> Да ли је апликација способна да испуни обим посла и под нормалним и под условима вршног оптерећења?

Испитивање капацитета се обично врши за будуће изгледе. Испитивање капацитета се односи на следеће:

1. Да ли ће апликација моћи да подржи будуће оптерећење?
2. Да ли је окружење способно да издржи предстојеће повећано оптерећење?
3. Који су додатни ресурси потребни да би животна средина била довољно способна?

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

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

Поузданост / опоравак Тестирање

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

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

Процес испитивања перформанси

Ево свих активности изведених у овом тестирању:

# 1) Анализа захтева / прикупљање

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

# 2) Избор ПОЦ / алата

Једном када је кључна функционалност идентификована, ПОЦ (Прооф Оф Цонцепт - што је врста демонстрације активности у реалном времену, али у ограниченом смислу) врши се помоћу доступних алата.

Листа доступних алата зависи од цене алата, протокола који апликација користи, технологија коришћених за изградњу апликације, броја корисника које симулирамо за тест итд. Током ПОЦ-а креирају се скрипте за идентификовани кључ функционалност и извршава се са 10-15 виртуелних корисника.

# 3) План и дизајн тестова перформанси

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

Планирање теста укључује информације о томе како ће се одвијати тест перформанси - тест окружење, радно оптерећење, хардвер итд.

Више о документу Стратегије тестирања у наставку.

# 4) Развој тестова перформанси

• Створени су случајеви употребе за функционалност која је у плану теста идентификована као опсег ПТ.
• Ови случајеви употребе се деле са клијентом ради њиховог одобрења. Ово омогућава да се скрипта забележи исправним корацима.
• Када се одобри, развој скрипте започиње снимањем корака у случајевима употребе помоћу алата за испитивање перформанси који је изабран током ПОЦ (Доказ концепата) и побољшан извођењем Корелације (за руковање динамичком вредношћу), Параметризације (замена вредности) и прилагођених функција као по ситуацији или потреби. Више о овим техникама у нашим видео упутствима.
• Скрипте се затим валидирају против различитих корисника.
• Паралелно са креирањем скрипти, тим за извођење такође наставља радити на подешавању тестног окружења (софтвера и хардвера).
• Тим за извођење ће се такође побринути за метаподатке (бацк-енд) кроз скрипте ако клијент не преузме ову активност.

# 5) Моделирање тестова перформанси

Модел извршења оптерећења је креиран за извршавање теста. Главни циљ овог корака је да потврди да ли су задате метрике учинка (које пружају клијенти) постигнуте током теста или не. Постоје различити приступи за стварање модела оптерећења. „ Литтле’с Лав ”Користи се у већини случајева.

# 6) Извршење теста

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

који је најбољи иоутубе видео претварач

Извршење теста се врши поступно. На пример, Ако је максималан број корисника 100, прво се покрећу сценарији са 10, 25, 50 корисника и тако даље, евентуално прелазећи на 100 корисника.

# 7) Анализа резултата испитивања

Резултати испитивања су најважнији резултат испитивача перформанси. Овде можемо доказати повраћај улагања (РОИ) и продуктивност коју напор тестирања перформанси може пружити.

Неке од најбољих пракси које помажу процесу анализе резултата:

1. Јединствено и смислено име за сваки резултат теста - ово помаже у разумевању сврхе теста.
2. У резиме резултата теста укључите следеће информације:

• Разлог за неуспех
• Промена перформанси апликације у поређењу са претходним пробним радом
• Промене извршене у тесту са становишта изградње апликације или тестног окружења.
• Добра је пракса сачињавати резиме резултата након сваке пробне вожње, тако да се резултати анализе не састављају сваки пут када се наводе резултати теста.
• ПТ обично захтева много пробних вожњи да би се дошло до тачног закључка.
• Добро је имати следеће тачке у резимеу резултата:
  • Сврха теста
  • Број виртуелних корисника
  • Резиме сценарија
  • Трајање теста
  • Пропусност
  • Графикони
  • Поређење графикона
  • Време одзива
  • Десила се грешка
  • Препоруке

# 8) Извештај

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

Извештај о испитивању се сматра добрим ако је кратак, описан и тачан.

Како написати документ о стратегији испитивања перформанси?

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

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

Узорак предлошка стратегије испитивања перформанси

О апликацији АБЦ цхат - Претпоставимо да је ово радна површина за ћаскање коју у компанији користи њихов агент за корисничку подршку, ова апликација за ћаскање користи КСМПП протокол, тј. Прошириви протокол за размену порука и присутност и Опен фире сервер за слање и примање тренутних порука.

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

За ову апликацију претпоставимо да је пројектни тим одлучио да је користи ЈМетер за испитивање перформанси и ЈИРА за праћење кварова.

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

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

Трећа страница треба да садржи садржај, а затим следе теме у наставку.

#1. Представљање

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

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

објективан

Кључни циљеви испитивања перформанси су следећи:

• Да бисте стекли уверење да су промене постојеће апликације за ћаскање у складу са дефинисаним Уговором о нивоу услуге.
• Да би се осигурало да резултат нових побољшања не утиче на перформансе апликације, доступност услуге и стабилност апликације.
• Времена одзива трансакције остају унутар прихватљиве толеранције у односу на растући профил оптерећења.
• ЈВМ-ови показују стабилну употребу меморије у све већим профилима оптерећења.

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

Архитектура

У ову сесију треба да уврстите дијаграм архитектуре вашег пројекта.

# 2) Обим

Ин Сцопе

Испод је опсег тестирања перформанси за АБЦ цхат радни сто:

• Стицање знања о кључним пословним трансакцијама и расподела оптерећења након детаљног проучавања система.
• Утврдите критичне сценарије за испитивање перформанси уз помоћ различитих стаза пројеката.
• Користите резултате претходних издања као основ за будућа издања.
• Проверите и потврдите окружење за тестирање перформанси и инфраструктуру алата за тестирање перформанси / оптерећења за било које додатне Агент машине.
• Припрема скрипти за тестирање перформанси помоћу ЈМетер-а за идентификоване сценарије који опонашају идентификовано вршно оптерећење.
• Подесите надзор перформанси на серверима за надгледање теста како бисте идентификовали уска грла током фазе извођења теста.
• Објави резултате теста перформанси.
• Координишите са различитим заинтересованим странама да бисте решили идентификована питања учинка.
• Основни ниво перформанси за будућа издања.

Изван опсега

• Функционално тестирање , УАТ, системско тестирање и сигурносно тестирање.
• Тестирање перформанси / надгледање било ког независног интерфејса.
• Подешавање перформанси. (Углавном подешавање врши други тим, ако у случају да имате инжењере перформанси да подесите систем, можете то додати у Инсцопе).
• Профилисање кода / Величина хардвера / Планирање капацитета.
• Безбедност / тестирање рањивости / УАТ / Испитивање беле кутије .
• Генерисање података за тестирање перформанси.
• Нефункционални тестови ( На пример, отказивање, опоравак од катастрофе, израда резервних копија, употребљивост) осим тестова перформанси.
• Тестирање било ког мобилног решења.
• Тестирање и подешавање перформанси независних апликација.
• Реализација препорука за перформансе, промена апликационог кода и промене производа / конфигурације сервера подржаних од стране добављача неће бити обухваћене перспективом тима за перформансе.
• Подршка инфраструктуре / примена грађевине / спремност околине / враћање базе података / мрежна подршка итд.

# 3) Приступ

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

Ове библиотеке су повезане у јар датотеку која је распоређена у Јметер и дизајнирана је на основу сценарија који ће се тестирати. Јметер Ворк Бенцх је инсталиран на локалној машини која се повезује са ЈМетер сервером који има генераторе учитавања за генерисање потребног оптерећења на систему цхат сервера за надгледање понашања система.

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

Тестни сценарио би био подељен и мерен у следећим аспектима:

а) Основни тест: Покретање сваког сценарија са 1 вусером и вишеструким итерацијама како би се утврдило да ли перформансе апликације испуњавају уговор о пословном нивоу услуге или не.

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

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

Помаже у подешавању или планирању капацитета појединачних Јава виртуелних машина (ЈВМ), укупног броја потребних ЈВМ-ова и процесора. То ће се постићи повећањем броја Вусера на 50%, 75%, 100% и 125% вршног капацитета.

д) Издржљивости тест: Тим за тестирање перформанси ће овај тест изводити у периоду од 8 сати / 16 сати / 24 сата како би идентификовао цурење меморије, проблеме са перформансама током времена и укупну стабилност система. Током тестова издржљивости, тим за тестирање перформанси надгледа кључне показатеље учинка, као што су време одзива трансакције и стабилност употребе меморије.

Системске ресурсе попут ЦПУ-а, меморије и ИО-а треба надгледати уз помоћ пројектног тима.

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

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

Укључите екцел у скуп сценарија.

питања за интервју за .нет програмера

На пример,

Сценарио 1: Да бисте потврдили цхат агента и купца за Кс бр. истовремених сесија.

Врсте тестова перформанси

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

Показатеље учинка

• Метрике на страни клијента

• Метрике перформанси система и мреже

Активности и резултати тестирања перформанси

# 4) Подаци о тестирању

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

# 5) Критеријуми за улазак и излазак

• Приступ свим апликацијама у окружењу.
• Спремност околине завршена.
• Спремност података о испитивању перформанси.

# 6) Управљање недостацима

• Модул за управљање недостацима у ЈИРА-и користиће се у пројекту за евидентирање кварова и за праћење до затварања.
• Идентификација дефеката који се пронађу током фазе извођења теста биће забележени у ЈИРА-и, а развојне екипе ће отклонити ове недостатке у складу са тежином испод.
• Састанци за преглед недостатака одржавали би се свакодневно уз учешће теста за испитивање, развој, аналитичара квалитета и пословних тимова.
• Критеријуми за отклањање недостатака постајали би строжи како се пројекат приближава датуму Го Ливе. Смернице за критеријуме за отклањање недостатака које треба објавити на састанцима за преглед недостатака.

Дефиниција озбиљности недостатака

Дефиниције кодова озбиљности су следеће:

# 7) Алати и технике за тестирање

# 8) Критеријуми суспензије и поновног покретања

Доље су дати критични критеријуми суспензије и поновног покретања који ће утицати на активности испитивања:

# 9) Резултати испоруке

Испоручени тестови перформанси укључују:

• Стратегија испитивања перформанси
• Документ о захтевима за перформансе
• Документ о сценарију испитивања перформанси
• Скрипте за испитивање перформанси
• Резултати испитивања перформанси

# 10) Улоге и одговорности

Улоге и одговорности су јасно објашњене у доњој табели.

# 11) Потенцијални ризици и план ублажавања

# 12) Претпоставке

• Окружење за тестирање перформанси биће реплика пејзажа архитектуре производа. (тј. исправан хардвер, софтвер, интерфејси, слојеви интеграције итд.).
• Скрипте за перформансе биће дизајниране на основу критичних токова код којих је употреба велика.
• Сва питања у вези са инфраструктуром треба решити пре почетка тестирања перформанси. Све касније извршене промене конфигурације система поништиће резултате теста.
• Апликација је стабилна и спремна за употребу у окружењу за тестирање перформанси.
• На располагању су неопходни хардверски и софтверски ресурси (попут машина за генерирање оптерећења / софтвера, машина за управљање / агент).
• Све промене у обиму проћи ће кроз процес контроле промена, а тим за тестирање учинка ће проценити утицај рокова и ресурса.
• Очекује се да ће одговарајући сервери поднети оптерећење.
• Евиденције праћења апликација морају бити омогућене за пратеће системе у сврху праћења.

# 13) Зависности

• Доступност окружења за тестирање перформанси које је реплика пејзажа архитектуре производа.
• Подршка потребна од различитих тимова за функционалне, развојне, базе података и инфраструктуру током фаза припреме и извршења теста.
• Током целе фазе тестирања перформанси не примењују се промене кода, јер је време врло ограничено.
• У случају непредвиђених проблема који доводе до ограничења унутар временских рокова, ако временски рокови не дозвољавају да се сви опсези тестова испуне у оквиру оригиналних датума прекретнице, подршка је доступна од стране Менаџера издања за пружање одлуке о опсегу и одређивању приоритета.
• Корисници апликација / стручњаци за предмет биће на располагању за функционална појашњења и одјаву пословних трансакција.
• Менаџер програма АБЦ цхат ће прегледати и одјавити се.

# 14) Скраћенице

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

Најбоље праксе за реалистично тестирање перформанси

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

Погледајмо детаљно сваку фазу како бисмо ефикасно спровели тестирање перформанси.

# 1) Планирање

• Покушајте да идентификујете најчешће токове посла, тј. Пословне сценарије који се морају тестирати. Ако је апликација већ постојећа, проверите евиденцију сервера да бисте разумели сценарије којима се најчешће приступа. Ако је апликација нова, разговарајте са тимом за управљање пројектом да бисте разумели главни пословни ток.
• Планирајте тест оптерећења на такав начин да покривате широк спектар токова посла, попут лагане потрошње, средње употребе и вршних оптерећења.
• Треба да извршите много циклуса Учитавања теста, па покушајте да направите оквир тако да можете поново и изнова да користите исте скрипте. Такође, покушајте да направите резервну копију скрипти.
• Покушајте да анализирате колико дуго тест треба да траје, да ли је то један сат? 8 сати? Дан или недеља? Обично ће дуготрајни тестови открити многе главне недостатке као што су грешке у ОС-у, цурење меморије итд.
• Ако ваша организација користи било који АПМ (Алат за надгледање апликација), тада га можете укључити током пробних трчања како бисте лакше препознали проблеме са перформансама и лакше идентификовали основни узрок.

# 2) Развој

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

# 3) Извршење

• Обавезно покрените тестове у производном окружењу, укључујући факторе попут ССЛ-а, Лоад Баланцера и Фиревалл-а. То је неопходно за симулацију реалног оптерећења система.
• Покушајте да створите радно оптерећење које је врло реално, то можете добити провером дневника сервера ако је реч о постојећој апликацији и ако је нова апликација потребне су вам информације од пословног тима. Запамтите да је радно оптерећење веома важно за спровођење успешних тестова перформанси.
• Никада не дођите до закључка извођењем тестова са половином околине величине производње, увек се саветује да се тестови спроводе у окружењу које је потпуно исто као и производња.
• Током извођења дугорочних тестова, покушајте да гледате трчање у честим интервалима како бисте били сигурни да тест ради глатко.

# 4) Анализа

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

Закључак

Сигуран сам да би вам овај водич пружио неизмерно знање о тестовима перформанси и како написати документ о стратегији тестирања перформанси са детаљним примерима.

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

Такође, Провери => Бесплатна серија дубинских тренинга ЛоадРуннер

СЛЕДЕЋА Лекција

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

• Испитивање перформанси вс испитивање оптерећења вс тестирање напрезања (разлика)
• Испитивање оптерећења помоћу ХП ЛоадРуннер водича
• Тестирање перформанси у облаку: добављачи услуга тестирања оптерећења заснованог на облаку
• Тестирање оптерећења, стреса и перформанси веб апликација помоћу ВАПТ-а
• Алати и услуге за тестирање перформанси веб локација
• Како извршити ручно тестирање перформанси?
• Тестирање перформанси мобилних апликација помоћу БлазеМетер-а
• Тестирање перформанси веб услуга помоћу ЛоадРуннер ВуГен скриптирања