Швидке створення навантажувальних тестів на JMeter для web-сайтів

    Для будь-якого програмного додатка, призначеного для масового обслуговування користувачів, необхідно проводити тестування навантаження на предмет його надійності та відмовостійкості. А так як будь-який web-сайт - це за своєю суттю система масового обслуговування, то перевірка його на відмовостійкість завжди є невід'ємною частиною розробки. Існують різні рішення для проведення навантажувального тестування веб-додатків. Я не буду зараз описувати їх детально, про деякі з них є згадки тут.

    У цій статті я хочу поділитися своїм досвідом використання такого засобу, як Apache JMeter. Після того як мною були перепробувано з десяток різних подібних інструментом, в підсумку я зупинився саме на JMeter, оскільки його можливості з лишком охоплювали мої цілі і завдання. І при цьому даний програмний засіб вельми швидкий і легковісний.

    Для тих хто жодного разу не використовував JMeter, рекомендую для початку почитати базові огляди, наприклад, Простий навантажувальний тест з Apache JMeter. Коли я перший раз запустив цю програму, перша думка була розібратися у всьому методом «тику», але як з'ясувалося це взагалі нереально, і метод «тику» непридатний до JMeter. Тому якщо хочете його використовувати, то відразу відкривайте мануал, повірте, вам доведеться заглядати туди дуже часто, поки повністю не розберетеся, що і як. Я ж тут зараз опишу саме очевидне і важливе, а саме: як власне створювати навантажувальні тести. Якби я свого часу відразу знайшов подібну статтю, то заощадив би без малого день на вивченні цієї софтини.

Отже, поїхали! Для інтересу уявімо, що у нас не просто сайт, а серйозний веб-додаток з авторизацією, різними пост-запитами і т.д.

1. Запускаємо JMeter.

2. Створюємо Thread group:

    Це у нас як основний workflow, в якому ми будемо записувати сценарії, додавати різну логіку і елементи управління.
    Тепер потрібно створити власне сценарій тесту, тобто набір різних дій для створення навантаження на сайт. Можна створювати сценарій вручну. Це дуже просто, для цього потрібно додати N-ну кількість елементів HTTP Request, які додаються так Thread Group -> Add -> Sampler -> HTTP Request. З'являється вікно налаштувань, представлене на малюнку нижче:

    У відповідні поля встановлюємо адресу сайту, порт (якщо потрібно), шлях до сторінки. Наприклад, так:

    Крім того можна додати параметри для запитів. І такий спосіб створення сценаріїв тесту цілком прийнятний для нескладних сайтів. Однак у нашому випадку прописувати параметри запитів для авторизації може бути стомлюючим заняттям. Крім того, потрібно створити послідовність дій для обходу сайту, скажімо, хоча б по 15-ти сторінок, то знову ж такий варіант вже не підходить. Звичайно ж ручна праця не для нас, і по-хорошому цю справу потрібно автоматизувати. У JMeter є така можливість, називається запис тестів через проксінг. Тобто ми будемо виконувати будь-які дії через браузер, і при цьому всі необхідні елементи HTTP Request будуть створюватися без нашої участі. Дивимося далі по пунктам, як це робиться.

3. Додаємо Recording Controller (Thread Group -> Add -> Logic Controller -> Recording Controller). В даний елемент зберігатимуться всі наші дії, які ми робитимемо в браузері.

4. Відразу додамо HTTP Cookie Manager (Thread Group -> Add -> Config Element -> HTTP Cookie Manager). За допомогою цього елемента буде реалізована робота з сесіями через cookie. У налаштуваннях даного елемента встановлюємо параметр Cookie Policy = compatibility. За описом в мануал. Отримали таку картину:

 

5. Додаємо елемент HTTP Proxy Server. Додавати його треба в розділ WorkBench (WorkBench -> Add -> Non-Test Elements -> HTTP Proxy Server), так як безпосередньо в ході тестування цей елемент не братиме участі. Він нам потрібен тільки, щоб створити сценарії тестів. Тут ми бачимо безліч налаштувань даного елемента:

 

    По суті тут достатньо тільки змінити номер порту проксі-сервера, якщо порт за замовчуванням 8080 у вас вже зайнятий, наприклад, можна поставити 8089. Якщо залишити графік Target Controller значення Use Recording Controller, то всі запити, що проходять через проксі, будуть записуватися в перший-ліпший Recording Controller в нашому тест-плані. Але так як на даний момент він там всього один, то нас цей варіант влаштує. Далі рекомендую звернути увагу на налаштування фільтрації. Ці налаштування надають широкі можливості по фільтрації запитів. Це можуть бути окремі сторінки, або наприклад все js-скрипти і т.д. і т.п. Знову ж таки в мануалі вони описані досить добре.

6. У налаштуваннях браузера потрібно вказати адресу проксі і порт. Переконатися, що браузер ходить в інтернет саме через неї, для цього перейти на будь-який сайт в інтернеті, при цьому сторінка не повинна завантажитися. Далі нам залишилося у вікні з настройками HTTP Proxy Server натиснути на кнопку Start, запустивши тим самим нашу проксі. Після цього через браузер, відкриваємо сторінку тестованого сайту, логіном, виконуємо різні дії, відвідуємо різні сторінки, при цьому сценарій вже почне зберігатися в елемент Recording Controller. Коли ви зрозумієте, що записаний вами сценарій вже досить суворий, для того щоб задати вашому сайту спеку, зупиняєте проксі.
Отримали, приблизно, наступну картину:

    Назви елементів мало про що говорять. Тому щоб надалі було просто спостерігати за ходом тесту, ці елементи є сенс перейменувати.

7. У налаштуваннях елемента Thread Group виберіть кількість потоків, число ітерацій, час прогріву. Наприклад, я встановив такі налаштування:

    Це означає, що тестування буде проходити в 10 потоків, триватиме нескінченно поки, його примусово не зупинять. Час прогріву я поставив 30 сек. Це означає, що потоки будуть рівномірно стартувати на протязі 30 секунд, тобто кожні три секунди, буде запускатися новий потік.

8. Щоб спостерігати результати тестів, а також стежити за ходом виконання, потрібно додати кілька елементів моніторингу. Я зазвичай додаю такі: View Results Tree, View Results in Table, Graph Results, Summary Report. Як і що вони показують, думаю, ви розберетеся самі. Єдине, що зазначу, дуже корисний елемент View Results Tree, в якому можна дивитися всі параметри і вміст запитів і відповідей:

Таким чином можна бачити, що все працює так як треба.

    Ось власне і все! Таким чином можна створити навантажувальний тест для вашого сайту за лічені хвилини.
    Наостанок, скажу ще пару корисних фіч, які реалізовані в Apach JMeter.

 

Налаштування за замовчуванням

    Якщо ви хочете здавати настройки для всіх елементів HTTP Request, то це можна зробити, додавши спеціальний набір налаштувань HTTP Request Defaults (Recording Controller -> Add -> Config Element -> HTTP Request Defaults). З вигляду це вікно дуже схоже на HTTP Request. Всі параметри, які ви в ньому задасте, будуть використовувати у всіх інших елементах даного набору. Це може бути зручно в багатьох ситуаціях, наприклад, коли у вас розгорнуто кілька вебов на різних портах, і вам періодично потрібно тестувати то один, то інший. Щоб не правити один порт для всіх запитів, міняємо його всього лише в одному місці в HTTP Request Defaults. Всі інші будуть використовувати його, якщо у них не заданий свій.

 

Завантаження списку користувачів з файлу

    Дане завдання також просте і очевидне. Якщо потрібно нацькувати на ваш багатостраждальний веб-ресурс відразу цілу зграю розлючених юзвірів, які будуть хаотично натискати на всі кнопки підряд, то робиться це за допомогою додавання елемента CSV Data Set Config (Thread Group -> Add -> Config Element -> CSV Data Set Config).

 

    У вікні вказуємо ім'я, шлях до файлу (якщо покласти його поруч з файлом проекту, то досить вказати одне ім'я), а також імена змінних. Ці імена ви задаєте самі, вони надалі будуть використовуватися при формуванні запиту. Наприклад, для зв'язки юзер \ пароль, я вказав два імені змінних: USER, PASS.
Сам файл з розширенням csv може виглядати так:
userName1, pass1
userName2, pass2
userName3, pass3

    Відмінно, юзерів ми подали на вхід джіметру. Тепер потрібно сказати йому, щоб він їх заюзав там, де це потрібно. Робиться це так, шукаємо той елемент HTTP Request, який відповідає за авторизацію. Як правило він у собі буде містити параметри запиту, а саме: той логін і пароль, які ви ввели, записуючи сценарій через браузер. Замість конкретних значень імені користувача і пароля підставляємо імена наших змінних в такому форматі $ {USER}, $ {PASS}.
    У мене це виглядає так:

    Після цього JMeter буде циклічно використовувати ці креденшели для різних потоків, забезпечуючи таким чином цілком реалістичну навантаження на сайт.

 

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: