Подробно описание на компонентите на JMeter

detail description jmeter components

Преглед на компонентите на Jmeter (част II):

=> Това е част от поредицата за обучение на JMeter. Вижте списъка с всички уроци от тази поредица тук .

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

В този урок читателите ще се запознаят всички компоненти на JMeter и как да ги използвате в плана за тестване за да обхване всички възможни сценарии за тестване на производителността за тестване на AUT (Application Under Test).

Елементите на Jmeter бяха изброени в предишната статия.

Какво ще научите:

• Компоненти на JMeter
  • План за тестване
  • Група нишки
  • Пробоотборници
  • HTTP заявки
  • FTP заявки
  • Слушатели
  • Работна маса
  • Твърдения
    • Твърдение за отговор
    • Утвърждаване на продължителността
  • Конфигуриране на елементи
    • Конфигурация на CSV набор от данни
    • Потребителски променливи
    • По подразбиране HTTP заявка
  • Логически контролери и таймери
  • Заключение
  • Препоръчително четене

Компоненти на JMeter

Запишете отново за справка:

• План за тестване
• ThreadGroup
• Пробоотборници
• Слушатели
• Работна маса
• Твърдения
• Елемент за конфигуриране
• Логически контролери
• Таймер

Всички основни компоненти на Jmeter като Thread Group, Samplers, Listeners и Config Elements са обяснени подробно по-нататък в статията.

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

Сега бихме започнали да докосваме всеки компонент на Jmeter заедно със случаите на употреба, само за да знаем как работи и как тестерите могат да ги приложат в своето тестване. Моля, обърнете внимание, че в тази статия няма да обхващаме всички Samplers, слушатели. Ще работим по най-използваните и ще поемем почивка в следващата статия, когато създаваме планове за тестове в реално време.

План за тестване

Точно както простият план за тестване в софтуерното тестване се състои от всички стъпки, които изпълняват скрипта, планът за тестване на JMeter има същата цел. Всичко, което е включено в тестовия план, се изпълнява в последователност, която е отгоре надолу или според определената последователност в тестовия план.

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

Както всички знаем, че JMeter измерва производителността, като генерира виртуални потребители или нишки, които удрят тествания сървър, сякаш реални потребители изпращат заявки към сървър. Следователно, всеки Тестов план трябва да има виртуални потребители или Thread Group, както ги наричаме в термините на JMeter.

Важни точки относно плана за изпитване:

• Тестовият план трябва да бъде запазен преди стартиране
• Jmeter файловете или тестовите планове се запазват под формата на. JMX файлове с разширения
• Можете също така да запазите части от Тестовия план като различен избор. Например, Ако искате да запазите HTTP Request Sampler с Listener, можете да го запишете като Test Fragment, така че да може да се използва и в други тестови сценарии
• Елементите на WorkBench не се записват с тестов план

Група нишки

Thread Group е група потребители, които ще удрят тествания сървър едновременно или в някаква предварително дефинирана последователност. Thread Group може да се добави към тестовия план, като щракнете с десния бутон върху тестовия план. JMeter е всичко „неща с десен бутон“, вие получавате всички опции с десния бутон.

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

Моля, вижте скрийншота по-долу за добавяне на нишки

(Забележка: Щракнете върху всяко изображение за увеличен изглед)

Много е важно да конфигурирате вашата група нишки според условията на теста.

Например, ако искате да тествате как се държи уеб сървър, когато 100 потребители го удрят едновременно, можете да зададете Thread Group както по-долу:

По принцип има три основни параметъра, които трябва да бъдат конфигурирани да генерират действително натоварване или виртуални потребители:

• Брой нишки (потребители) - Определя броя на виртуалните потребители. За целите на тестването трябва да генерираме само ограничено количество товар, тъй като генерирането на огромен обем наведнъж би означавало да консумираме много много нишки, което в крайна сметка може да доведе до високо използване на процесора.
• Период на нарастване - Това поле е много важно при контрола на генерирането на товара. Периодът на нарастване определя времето, през което ще се генерира общото натоварване.

Пример 1:

• Това означава, че всички 10 потребители ще удрят сървъри едновременно, веднага щом се изпълни тест

Пример 2:

• Всички вие трябва да сте забелязали квадратчето „Scheduler“ в горната екранна снимка. В случай, че искате тестът ви да се стартира в точно определено време по-късно, можете да зададете времето, както можете да видите и на екрана по-долу. Това означава, че на всеки 1 сек нов потребител ще удря сървъра. Натоварването няма да бъде едновременно, но ще се увеличава. До 10^тивторо, всички потребители биха ударили заявката.
• Брой цикли - Той определя броя на изпълненията на Thread Group. Ако поставите отметка в квадратчето завинаги, тестът ви ще работи завинаги, освен ако не го спрете ръчно. Това може да се използва за тестване на нещо като „Ако вашият сървър не се срине при непрекъснато зареждане за няколко минути“.

Пробоотборници

И така, откъде Jmeter знае какъв тип заявка е изпратена до сървъра ???

• Това е чрез Samplers. Пробниците са задължителни за добавяне към тестовия план, тъй като само той може да информира Jmeter какъв тип заявка трябва да премине към кой сървър и с предварително определени параметри или не. Исканията могат да бъдат HTTP, HTTP (s), FTP, TCP, SMTP, SOAP и др.

Пробниците могат да се добавят само към Thread Group, а не директно под Тестовия план, тъй като Thread Groups трябва да използват семплер, за да изпратят заявка до URL адреса на сървъра под тест. Пробникът може да бъде добавен по път Група нишки -> Sampler -> HTTP заявка.

HTTP заявки

Това са най-често срещаните заявки, изпратени до сървърите. Казвам, например, искаме 100 потребители да ударят https://www.google.com едновременно с това може да се направи, както е описано на екрана по-долу:

• Пътят е навигацията в основния уебсайт. Например, ако искаме да натиснем http://www.google.com/gmail, тогава можем да зададем „/ Gmail“ в пътя и почивката остава същата
• Не е необходимо да пишете „www“ в името на сървъра
• Номер на порта се използва, ако използвате прокси сървър
• Timeout Connect и Response могат да бъдат зададени, ако искате да имате еталон за времето за връзка на сървъра и времето за реакция. Заявката ви ще се провали, ако сървърът ви отнема повече време за изпращане на отговор от конфигурирания
• Можете също така да конфигурирате параметри, които да се изпращат с вашата заявка. Например: В някои случаи може да се наложи да изпратите авторизационен токен с вашата заявка, така че сте направили да ги добавите в HTTP заявка, както е показано по-долу:

FTP заявки

Път-> План за тестване-> Група нишки-> Пробоотборник-> FTP заявка

FTP означава протокол за прехвърляне на файлове и се използва за качване или изтегляне на файл от сървъра. Конците на JMeter изпращат заявки до FTP сървъри за качване или изтегляне на файлове от там и измерват производителността.

• Local File е мястото, където трябва да запазите изтегления файл
• Използвайте опцията GET, ако изтегляте от FTP сървър
• Потребителска опция POST, ако качвате който и да е файл на FTP сървър

Имаме много много слушатели, които ще бъдат обхванати, когато преминем през някои реални тестови планове, състоящи се от семплери, слушатели, конфигурационни елементи и т.н.

Слушатели

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

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

Преглед на резултатите в таблица:

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

Слушателите могат да се добавят директно под тестовия план или под семплер. Разликата е, че когато добавите слушател под семплер, той ще покаже резултатите само от този семплер. Ако добавим семплер директно под тестовия план, той показва резултата за всички семплери в йерархията.

Екранната снимка по-долу за справка:

Виждате резултатите, както е показано по-долу:

въпроси и отговори за интервю за тестване на селен

• Латентност : Това е времето, когато е получена първата информация, т.е.получава се първият байт данни
• Време за свързване : Времето е необходимо за установяване на връзка със сървъра
• Примерно време : Времето, необходимо за получаване на пълни данни
• Проба - Последователност на номера на пробата
• Байтове - Размер на получените данни.

Преглед на резултатите в дърво:

Това е друг най-често използван слушател и предоставя подробна информация с искане и отговор. Можете също така да видите HTML страницата, изобразена в отговор, освен Json, XML, Text, RegEx.

Много е полезно, тъй като тестерите могат да поставят твърдения относно получения отговор, за да се гарантира, че тестът е преминал. Резултатите от Jmeter пак показват „Pass“, дори ако отговорът не е желан.

Например: Да кажем, ударихме HTTP заявка на всеки уебсайт www.xyz.com и в отговор очакваме XYZ или с прости думи, когато ударим тази страница, началната страница на компанията се отваря с нейното име. Ако не сме поставили твърдение, Jmeter пак ще показва резултати, тъй като посещението е отишло на сървъра.

Моля, вижте по-долу, за да знаете формата на резултатите:

За да видите HTML страница в отговор, щракнете върху падащото меню в левия прозорец и след това изберете „HTML“, отворете раздела за отговор и проверете страницата, която се връща като отговор на сървъра.

Работна маса

Работната маса е място, където можете да съхранявате онези елементи, които не се използват в текущия ви план за изпитване, но които по-късно могат да бъдат копирани, поставени в него. Когато запишете файла JMeter, компонентите, които присъстват в работната среда, не се записват автоматично. Трябва да ги запазите отделно, като щракнете с десния бутон и изберете опцията „Запазване като“.

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

Причината за наличието на работна среда беше, че потребителят може да направи някои експерименти и да изпробва нови сценарии. Както вече знаем, елементите в Workbench не се записват, така че потребителят може буквално да използва каквото и да е и след това да го изхвърли. Но има някои „Нетестови компоненти“, които се предлагат само в WorkBench.

Те са изброени тук:

• HTTP Mirror Server
• HTTP (s) Record Script Recorder
• Показване на свойства

HTTP (s) Record Script Recorder е най-важният нетестов елемент, използван в JMeter. Той помага на тестерите при запис на скрипта и след това конфигуриране на товара за всяка транзакция.

Jmeter записва само заявката, изпратена до сървъра. Не се бъркайте с функционалността „Запис и възпроизвеждане“ на QTP / Селен. Всички заявки се записват и тестерите могат да приложат желаното натоварване върху тях, за да видят поведението.

Този елемент е много важен за сценарии, при които тестерите не знаят какви са всички заявки от тяхното приложение. Те могат да използват Http (s) записващ скрипт, за да запишат приложението, което се тества.

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

Твърдения

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

По-долу са видовете твърдения, които често се използват:

• Твърдение за отговор
• Утвърждаване на продължителността
• Утвърждаване на размера
• XML твърдение
• HTML твърдение

Твърдение за отговор

В Твърдението за отговор можем да добавим собствени низове на шаблони и след това да ги сравним с отговорите, получени от сървър. Например, всички знаете, че кодът за отговор е 200, когато всяка заявка връща някакъв отговор успешно. Така че, ако добавим низ от шаблон „Код за отговор = 202“, тогава тестовият случай трябва да се провали.

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

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

Утвърждаване на продължителността

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

Дело : 10 потребители едновременно удрят сървъра „google.com“ и Утвърждаването на продължителността е настроено на 1000ms.Моля, вижте скрийншота по-долу:

XML Assertion проверява дали данните за отговорите съдържат правилен XML документ и HTML Assertion проверява HTML синтаксиса на отговора, получен от сървър.

Конфигуриране на елементи

Заявките, изпратени до сървъра, могат да бъдат допълнително параметризирани с помощта на някои конфигурационни елементи, които се изпълняват преди действителната заявка. Един прост пример за това може да бъде четене на стойности на променлива от CSV файл, за който се използва CSV Data Config.

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

• Конфигурация на CSV набор от данни.
• Потребителски променливи
• HTTPS заявки по подразбиране
• HTTPS кеш мениджър
• HTTPS мениджър на бисквитки

Конфигурация на CSV набор от данни

Конфигурацията на CSV набор от данни помага на Jmeter да избира стойности на някои параметри от CSV файл, вместо да предава различен параметър във всяка отделна заявка. Например, ако трябва да тестваме функционалността за вход с различен набор от потребители и пароли, тогава можем да създадем две колони в CSV файл и да въведем стойностите там, така че JMeter да може да избере по една за всяка заявка, изпратена до сървъра.

По-долу е даден потокът от използване на CSV набор от данни за конфигуриране за тестване на API за времето за различни градове в Индия.

• Добавяне на конфигурационен елемент на CSV набор от данни към план за тестване

• Създаване на CSV файл
• Предаване на променлива в параметъра на заявката. Параметърът APPID може да се генерира динамично от http://openweathermap.org/appid

• Изпълнение на теста и преглед на резултатите.

Потребителски променливи

Помага на Jmeter да избира стойности от предварително дефинирана променлива. Например, поддръжка, че трябва да създадете тестов план, в който трябва да добавите много HTTP заявки към един и същ URL адрес и може да има сценарий, при който клиентът планира да го мигрира по-късно към различен URL. Така че, за да се избегне актуализиране на URL във всяка заявка можем да кажем на JMeter да избере URL адреса от UDV (Потребителска променлива), която по-късно може да бъде актуализирана, за да обработва всички заявки към актуализиран URL адрес.

Така че, за да избегнем актуализирането на URL във всяка заявка, можем да кажем на JMeter да избере URL от UDV (User Defined Variable), който по-късно може да бъде актуализиран, за да обработва всички заявки към актуализиран URL адрес.

По подразбиране HTTP заявка

Този конфигурационен елемент е много полезен за определяне на стойностите по подразбиране на https заявките. За да ви насочим повече, вземете пример, когато трябва да ударим 50 различни заявки на google сървър. В този сценарий, ако добавим HTTP заявка по подразбиране, не е необходимо да посочваме име на сървър, път или други свойства като номер на порт, връзка свойства за изчакване. Каквото и да е посочено в конфигурационния елемент по подразбиране HTTP Request се наследява от всички HTTP заявки.

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

Моля, вижте по-долу как да добавите HTTP Request Default и да посочите сървър и път.

HTTP кеш мениджър и HTTP диспечер на бисквитки се използват, за да накарат JMeter да се държи като браузър в реално време. Мениджърът на HTTP кеша може да изчиства кеша след всяка заявка, докато другият може да управлява настройките на бисквитките.

Логически контролери и таймери

Логическите контролери и таймери помагат на Jmeter да контролира потока от транзакции. Таймерите осигуряват закъснението във всяка нишка, ако е необходимо да тествате сървър. Например, ако се нуждаем от FTP заявка, за да изчакаме 5 секунди след завършване на HTTP заявката, можем да добавим таймер там.

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

Заключение

Досега всички вие трябва да сте се запознали с компонентите на JMeter и сте се опитали да го използвате и трябва да сте изправени пред някои проблеми. В следващата статия ще разгледаме някои сценарии за тестване на производителността в реално време, обхващащи домейн за мобилност, така че всички да получите повече практически знания за JMeter.

Останете на линия! Следващата статия ще ви помогне да управлявате вашите заявки, както и да анализирате резултатите и да сравнявате с критериите за тестване на производителността.

=>Продължете да четете част III: JMeter процесори и контролери

етапи от жизнения цикъл на разработката на софтуер

=> Щракнете тук за уроци за JMeter: Пълното безплатно обучение за JMeter (20+ видеоклипа)

Препоръчително четене

• Как да постигнем JMeter корелация с пример
• План за изпитване на Jmeter и WorkBench
• Работа с FTP заявка в JMeter
• Топ 5 приставки за JMeter и как да ги използвате (с примери)
• Таймери JMeter: постоянен таймер, BeanShell и Guassian
• Работа с HTTP заявки в JMeter
• Контролери на Jmeter Част 1
• Контролери на Jmeter Част 2