detail description jmeter components
Огляд компонентів Jmeter (Частина II):
=> Це частина навчальної серії JMeter. Перегляньте тут список усіх підручників із цієї серії .
Сподіваюся, ви всі, мабуть, пройшли через Введення та встановлення JMeter до тепер. Оскільки ми продовжуємо наступну з серії, настійно рекомендуємо всім вам встановити JMeter і тренуватися поруч.
У цьому посібнику читачі ознайомляться з ними всі компоненти JMeter та як їх використовувати в плані тестування охопити всі можливі сценарії тестування продуктивності для тестування AUT (Application Test Test).
в чому різниця між Linux та unix
Елементи Jmeter були перераховані в попередній статті.
Що ви дізнаєтесь:
- Компоненти JMeter
Компоненти JMeter
Знову підпишіться для довідки:
- План випробувань
- ThreadGroup
- Пробовідбірники
- Слухачі
- WorkBench
- Твердження
- Елемент налаштування
- Логічні контролери
- Таймер
Усі основні компоненти Jmeter, такі як Thread Group, Samplers, Listeners та Config Elements, детально пояснюються далі в статті.
Будь ласка, зверніться до наведеної нижче схеми, щоб зрозуміти кожен компонент та їх відношення до конкретних модулів JMeter.
Тепер ми б почали торкатися кожного компонента Jmeter разом із варіантами використання, щоб просто знати, як це працює, і як тестери можуть застосовувати їх у своєму тестуванні. Зверніть увагу, що в цій статті ми не будемо охоплювати всіх пробників, слухачів. Ми будемо працювати над найбільш використовуваними, а в наступній статті розпочнемо відпочинок під час створення тестових планів у реальному часі.
План випробувань
Подібно до того, як простий план тестування у тестуванні програмного забезпечення складається з усіх етапів, на яких виконується сценарій, план тесту JMeter має ту саму мету. Все, що входить до плану тесту, виконується в послідовності, яка знаходиться зверху вниз або відповідно до визначеної послідовності в плані тесту.
План тестування може бути настільки простим, наскільки це можливо, за допомогою функції просто ThreadGroup, Sampler та Listener, і він починає ускладнюватися, як тільки ви починаєте додавати більше елементів, таких як елементи конфігурації, препроцесори або контролери.
Як ми всі знаємо, що JMeter вимірює продуктивність, генеруючи віртуальних користувачів або потоки, які потрапляють на тестований сервер так, ніби справжні користувачі надсилають запити на сервер. Тому кожен план тестування повинен мати віртуальних користувачів або Thread Group, як ми їх називаємо в термінах JMeter.
Важливі моменти щодо плану випробувань:
- План тесту слід зберегти перед запуском
- Файли Jmeter або плани тестування зберігаються у формі. Файли розширення JMX
- Ви також можете зберегти частини Плану випробувань як різні варіанти. Наприклад, Якщо ви хочете зберегти HTTP Request Sampler за допомогою прослуховувача, ви можете зберегти його як Test Fragment, щоб він міг використовуватись і в інших сценаріях тестування
- Елементи WorkBench не зберігаються за допомогою плану тестування
Група ниток
Thread Group - це група користувачів, яка буде потрапляти на тестований сервер одночасно або в певній визначеній послідовності. Групу ниток можна додати до плану тестування, клацнувши план тесту правою кнопкою миші. JMeter - це все, що можна натиснути правою кнопкою миші, ви отримуєте всі параметри правою кнопкою миші.
Ви можете перейменувати назву групи потоків на своє. Просто змініть назву та клацніть де-небудь поза вікном плану тестування, і ви побачите, як ім'я змінюється.
Будь ласка, див. Знімок екрана для додавання груп ниток
(Примітка: Натисніть на будь-яке зображення для збільшення
Дуже важливо налаштувати свою групу потоків відповідно до умов тесту.
Наприклад, якщо ви хочете перевірити, як веб-сервер поводиться, коли 100 користувачів одночасно потрапляє на нього, ви можете встановити Thread Group, як показано нижче:
В основному, є три основні параметри, які необхідно налаштувати для генерування фактичного навантаження або віртуальних користувачів:
- Кількість ниток (користувачів) - Він визначає кількість віртуальних користувачів. Для тестування ми повинні генерувати лише обмежену кількість навантаження, оскільки генерування величезного обсягу одночасно означало б споживання великої кількості потоків, що в кінцевому підсумку може призвести до великої завантаженості процесора.
- Період нарощування - Це поле є дуже важливим для контролю генерації навантаження. Період нарощування визначає проміжок часу, протягом якого генерується загальне навантаження.
Приклад 1:
- Це означає, що всі 10 користувачів будуть вражати сервери одночасно, як тільки буде запущено тест
Приклад 2:
- Ви всі, напевно, помітили прапорець 'Планувальник' на скріншоті. Якщо ви хочете, щоб ваш тест запускався в певний час пізніше, тоді ви можете встановити таймінги, як ви також можете бачити на скріншоті нижче. Це означає, що кожні 1 секунду новий користувач потрапляє на сервер. Навантаження не буде одночасною, але буде зростати. До 10гопо-друге, усі користувачі мали б натиснути запит.
- Кількість петель - Він визначає кількість запусків Thread Group. Якщо ви встановите прапорець назавжди, ваш тест буде працювати вічно, якщо ви не зупините його вручну. Це можна використовувати для тестування на кшталт 'Якщо ваш сервер не виходить з ладу при постійному завантаженні протягом декількох хвилин'.
Пробовідбірники
Отже, звідки Jmeter знає, який тип запиту було надіслано на сервер ???
- Це через пробовідбірники. Пробовідбірники необхідно додати до плану тестування, оскільки лише він може повідомити Jmeter, який тип запиту потрібно перейти на який сервер і з будь-якими заздалегідь визначеними параметрами чи ні. Запити можуть бути HTTP, HTTP (s), FTP, TCP, SMTP, SOAP тощо.
Пробовідбірники можна додавати до групи потоків лише безпосередньо в рамках плану тестування, оскільки групи потоків повинні використовувати дискретизатор для надсилання запиту на URL-адресу сервера, що перевіряється. Пробовідбірник можна додати шляхом Група потоків -> Пробовідбірник -> Запит HTTP.
Запити HTTP
Це найпоширеніші запити, що надсилаються на сервери. Сказати, наприклад, ми хочемо, щоб потрапило 100 користувачів https://www.google.com одночасно це можна зробити, як описано на знімку екрана нижче:
масиви c ++ у функціях
- Шлях - це навігація всередині головного веб-сайту. Наприклад, якщо ми хочемо натиснути http://www.google.com/gmail, тоді ми можемо встановити “/ Gmail” у шляху, а відпочинок залишається незмінним
- Не потрібно вводити “www” в імені сервера
- Номер порту використовується, якщо ви використовуєте будь-який проксі-сервер
- Timeout Connect and Response можна встановити, якщо ви хочете мати контрольний показник часу підключення до сервера та часу відгуку. Ваш запит не вдасться, якщо серверу потрібно більше часу, щоб надіслати відповідь, ніж налаштований
- Ви також можете налаштувати параметри для надсилання з вашим запитом. Наприклад: У деяких випадках вам може знадобитися надіслати маркер авторизації разом із вашим запитом, тому ви зробили додавання їх у HTTP-запиті, як показано нижче:
Запити FTP
Шлях-> План тесту-> Група потоків-> Пробовідбірник-> Запит FTP
FTP розшифровується як Протокол передачі файлів, і він використовується для завантаження або завантаження файлу з сервера. Потоки JMeter надсилають запити на сервери FTP для завантаження або завантаження файлів звідти та вимірюють продуктивність.
- Локальний файл - це місце, де потрібно зберегти завантажений файл
- Використовуйте опцію GET, якщо ви завантажуєте з FTP-сервера
- Параметр POST користувача, якщо ви завантажуєте будь-який файл на FTP-сервер
У нас багато багато слухачів, які будуть охоплені, коли ми пройдемо деякі реальні тестові плани, що складаються з семплерів, слухачів, елементів конфігурації тощо.
Слухачі
Отже, до цього часу ми бачили декілька пробників, які відправляли запити на сервер, але ще не проаналізували відповідь. Тестування продуктивності полягає в тому, щоб проаналізувати відповіді сервера у різній формі, а потім представити їх клієнту.
Слухачі використовуються для відображення результатів виконання тесту, щоб тестувальники могли ознайомитися зі статистикою. У нас близько 15 слухачів у Jmeter, але в основному використовуються такі, як таблиця, дерево та графік.
Переглянути результати в таблиці:
Це найбільш часто використовувана і зрозуміла форма слухачів. Він відображає результат у вигляді таблиці з деякими важливими параметрами продуктивності.
Слухачів можна додати безпосередньо за планом випробувань або за допомогою пробовідбірника. Різниця полягає в тому, що коли ви додаєте слухач під семплер, він відображатиме результати лише цього семплера. Якщо ми додаємо пробовідбірник безпосередньо під план тесту, він відображає результат для всього пробовідбірника в ієрархії.
Знімок екрана нижче для довідки:
Результати ви бачите приблизно так, як показано нижче:
- Латентність : Це час отримання першої інформації, тобто отримання першого байта даних
- Підключити час : Це час, необхідний для встановлення зв’язку з сервером
- Час вибірки : Це час, необхідний для отримання повних даних
- Зразок - Послідовність номера вибірки
- Байти - Розмір отриманих даних.
Переглянути результати в дереві:
Це ще один найбільш часто використовуваний слухач, який надає детальну інформацію із запитом та відповіддю. Можна також переглянути HTML-сторінку, що відображається у відповідь, окрім перегляду Json, XML, Text, RegEx.
Це дуже корисно, оскільки тестувальники можуть висловити твердження щодо отриманої відповіді, щоб переконатися, що тест пройшов. Результати Jmeter все ще показують “Пройти”, навіть якщо відповідь не бажана.
Наприклад: Скажімо, ми потрапили на запит HTTP на будь-якому веб-сайті www.xyz.com і у відповідь ми очікуємо XYZ або простими словами, коли потрапляємо на цю сторінку, головна сторінка компанії відкривається з її назвою. Якщо ми не ставимо твердження, Jmeter все одно відображатиме результати, оскільки звернення перейшло на сервер.
Будь ласка, дивіться нижче, щоб дізнатися формат результатів:
Щоб переглянути сторінку HTML у відповідь, натисніть спадне меню на лівій панелі, а потім виберіть “HTML”, перейдіть на вкладку відповідей і перевірте сторінку, яка повертається як відповідь сервера.
Робоча лавка
Верстак - це місце, де ви можете зберігати ті елементи, які не використовуються у вашому поточному плані тестування, але які згодом можна скопіювати в нього. Коли ви зберігаєте файл JMeter, компоненти, які присутні в робочому середовищі, не зберігаються автоматично. Ви повинні зберегти їх окремо, клацнувши правою кнопкою миші та вибравши опцію «Зберегти як».
Тоді ви, можливо, замислюєтесь, у чому користь верстака, в будь-якому випадку легко додати будь-який компонент безпосередньо до плану випробувань Jmeter.
Причиною створення робочого середовища було те, що користувач міг провести деякі експерименти та випробувати нові сценарії. Як ми вже знаємо, елементи в робочому середовищі не зберігаються, тому користувач може буквально використати що завгодно, а потім викинути. Але є деякі 'Нетестові компоненти', які доступні лише в WorkBench.
Вони перелічені тут:
- Дзеркальний сервер HTTP
- Записувач тестових сценаріїв HTTP (s)
- Відображення властивостей
Записник тестових сценаріїв HTTP (s) - найважливіший нетестовий елемент, що використовується в JMeter. Це допомагає тестувальникам записати сценарій, а потім налаштувати навантаження для кожної транзакції.
Jmeter записує лише запит, надісланий на сервер. Не плутайте з функціональністю “Запис і відтворення” QTP / Selenium. Усі запити реєструються, і тестери можуть застосувати до них бажане навантаження, щоб побачити поведінку.
Цей елемент дуже важливий для сценаріїв, коли тестувальники не знають, що відбувається з усіма запитами їхньої програми. Вони можуть використовувати реєстратор сценаріїв Http (s) для запису програми, що тестується.
Тестування продуктивності мобільних додатків також можна зробити таким чином, налаштувавши проксі-сервер JMeter, а потім записавши запити, які наш мобільний додаток надсилає на сервер. Покрокова процедура тестування мобільних характеристик буде пояснена в наступній статті.
Твердження
До цього часу ми розглянули, як JMeter потрапляє на сервер і як відображаються відповіді через слухачі. Щоб переконатися, що отримана відповідь була правильною та відповідно до очікувань, нам потрібно додати твердження. Твердження - це просто валідації, на які нам потрібно поставити відповіді, щоб порівняти результати.
Нижче наведені типи тверджень, які зазвичай використовуються:
- Твердження відповіді
- Тривалість Ствердження
- Ствердження розміру
- Ствердження XML
- Ствердження HTML
Твердження відповіді
У твердженні відповіді ми можемо додати власні рядки зразків, а потім порівняти їх із відповідями, отриманими від сервера. Наприклад, всі ви знаєте код відповіді 200, коли будь-який запит успішно повертає деяку відповідь. Отже, якщо ми додаємо рядок шаблону “Код відповіді = 202”, тоді тестовий випадок повинен провалитися.
Будь ласка, зверніться до скріншотів нижче, щоб додати твердження коду відповіді.
Тепер, під час запуску тесту, він відображає результат із червоним кольором, що вказує на те, що результати твердження не вдалися.
Тривалість Ствердження
Твердження про тривалість є дуже важливим і підтверджує, що сервер відповів протягом заданого періоду часу. Це може бути використано у сценаріях, коли нам потрібно відібрати 100 запитів та переконатися, що кожен раз, коли відповідь надходить у межах контрольного обмеження.
Справа : 10 користувачів одночасно потрапляють на сервер 'google.com', а тривалість твердження встановлена на 1000 мс. Будь ласка, див. Скріншоти нижче:
XML Assertion перевіряє, чи є в даних відповідей правильний XML-документ, а HTML Assertion перевіряє синтаксис HTML відповіді, отриманої від сервера.
Налаштування елементів
Запити, надіслані на сервер, можуть бути додатково параметризовані за допомогою деяких елементів конфігурації, які виконуються до фактичного запиту. Простим прикладом цього може бути зчитування значень змінної з файлу CSV, для якого використовується конфігурація набору даних CSV.
Нижче наведено деякі важливі елементи конфігурації, що використовуються при тестуванні продуктивності Інтернету та мобільних додатків
- Конфігурація набору даних CSV.
- Користувацькі змінні
- HTTPS запитує за замовчуванням
- Менеджер кешу HTTPS
- Менеджер файлів cookie HTTPS
Конфігурація набору даних CSV
Конфігурація набору даних CSV допомагає Jmeter вибирати значення деяких параметрів із файлу CSV, а не передавати різні параметри в кожному окремому запиті. Наприклад, якщо нам потрібно протестувати функціональність входу з різним набором користувачів і паролів, тоді ми можемо створити два стовпці у файлі CSV і ввести туди значення, щоб JMeter міг вибрати по одному для кожного запиту, надісланого на сервер.
Нижче наведено потік використання конфігурації набору даних CSV для перевірки API погоди для різних міст Індії.
- Додавання елемента конфігурації набору даних CSV до плану тестування
- Створення файлу CSV
- Передача змінної в параметр запиту. Параметр APPID можна генерувати динамічно з http://openweathermap.org/appid
- Запуск тесту та перегляд результатів.
Користувацькі змінні
Це допомагає Jmeter вибирати значення із заздалегідь визначеної змінної. Наприклад, підтримка того, що вам потрібно створити план тестування, в якому вам потрібно додати багато запитів HTTP до однієї і тієї ж URL-адреси, і може бути сценарій, коли клієнт планує перенести його пізніше на інший URL-адрес. ми можемо сказати JMeter вибрати URL-адресу з UDV (користувацької змінної), яку згодом можна оновити для обробки всіх запитів на оновлену URL-адресу.
Отже, щоб уникнути оновлення URL-адреси в кожному запиті, ми можемо сказати JMeter вибрати URL-адресу з UDV (User Defined Variable), яку згодом можна оновити для обробки всіх запитів на оновлену URL-адресу.
За замовчуванням HTTP-запит
Цей елемент config дуже корисний для вказівки значень за замовчуванням для https-запитів. Щоб допомогти вам більше, візьміть приклад, коли нам потрібно отримати 50 різних запитів на сервері Google. У цьому випадку, якщо ми додаємо HTTP-запит за замовчуванням, нам не потрібно вказувати ім’я сервера, шлях або будь-які інші властивості, такі як номер порту, з’єднання. властивості тайм-ауту. Все, що вказано в елементі конфігурації запиту HTTP, успадковується усіма запитами HTTP.
У цьому випадку, якщо ми додаємо HTTP-запит за замовчуванням, тоді нам не потрібно вказувати ім’я сервера, шлях або будь-які інші властивості, такі як номер порту, властивості часу очікування. Все, що вказано в елементі конфігурації запиту HTTP, успадковується усіма запитами HTTP.
Будь ласка, дивіться нижче, як додати HTTP-запит за замовчуванням та вказати сервер та шлях.
Менеджер кешування HTTP і Менеджер файлів cookie HTTP використовуються для того, щоб JMeter поводився як браузер у режимі реального часу. Менеджер кешування HTTP може очищати кеш після кожного запиту, тоді як інший може керувати налаштуваннями файлів cookie.
Логічні контролери та таймери
Логічні контролери та таймери допомагають 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