QA Galaxy QA Academy

Рівень 17. Навантажувальне тестування

Рівень 17

Навантажувальне тестування за допомогою JMeter

Навантажувальне тестування

Навантажувальне тестування (або тестування продуктивності, Performance testing) — це автоматизоване тестування, що імітує роботу певної кількості користувачів у застосунку. Навантажувальне тестування має на меті з'ясувати граничні умови навантаження на систему, за яких вона продовжує працювати стабільно й з прийнятним часом відгуку, а також оцінити здатність системи правильно функціонувати у разі перевищення запланованих навантажень.

Види навантажень під час тестування

Конкретніше виділяють такі види навантажувального тестування:

1. Тестування продуктивності – вимірюється швидкість роботи системи за ідеальних умов і максимального навантаження.

2. Навантажувальне тестування – ті самі тести продуктивності, але в яких система зазнає різних навантажень.

3. Об'ємне тестування – застосунок навантажується великою кількістю даних, щоб визначити, коли досягаються умови, за яких система перестає працювати.

4. Стрес-тестування – поведінка системи за нестачі ресурсів (ресурсів процесора, дискового простору, обривів мережі тощо). Стресове тестування дає змогу перевірити, наскільки працездатні застосунок і система загалом в умовах стресу, а також оцінити здатність системи до регенерації, тобто до повернення в нормальний стан після припинення впливу стресу. Стресом у цьому контексті може бути підвищення інтенсивності виконання операцій до дуже високих значень або аварійна зміна конфігурації сервера.

5. Тестування стабільності або надійності (Stability / Reliability Testing).

Завдання тестування стабільності (надійності) — перевірити працездатність застосунку під час тривалої (24 години й більше) роботи із середнім рівнем навантаження. Час виконання операцій у цьому виді тестування відіграє другорядну роль, а на перше місце виходить стабільність роботи: відсутність витоків пам'яті, перезапусків серверів під навантаженням та інші аспекти, що впливають саме на стабільність роботи. Під час тестування стабільності терміни проведення зумовлені лише бізнес-логікою і можуть тривати тиждень, місяць і довше.

Види режимів роботи

Штатний режим роботи – прийнятні параметри режиму роботи застосунку, наприклад, кількість користувачів, що одночасно працюють із вебзастосунком.

Пікове навантаження – короткочасна робота сервера та вебзастосунку з перевищенням штатної кількості користувачів.

Тип підключення – рівномірне (протягом певного періоду) або пікове (одночасне, швидке) підключення користувачів до сервера вебзастосунку.

Профіль навантаження (Load Profile) – це набір операцій з різною інтенсивністю навантаження, визначений шляхом аналізу вимог до тестованої системи.

Навантажувальне тестування включає:

1. Тестування під робочим навантаженням

2. Тестування під підвищеним навантаженням

3. Тестування пікових навантажень

4. Тестування на великих обсягах даних

5. Тестування «правильного вмирання»

6. Тюнінг та ігри з налаштуваннями

7. «Залізні» питання

8. Оцінка живучості систем

9. Рекомендації пацієнту

Цілі та завдання навантажувального тестування

На стадії проєктування.

  • Яка з архітектур системи краща: трирівнева чи чотирирівнева? Де і як зберігати файли? Чи забезпечать обрані мова та БД потрібну продуктивність? Тощо.

На стадії програмування.

  • Яка схема БД краща? Чи варто відмовитися від нормалізації БД на користь продуктивності, чи навпаки? Як робити GUI? Що краще: тригери чи зовнішні ключі?
  • Яку ділянку коду слід оптимізувати насамперед?

На стадії тестування:

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

На стадії постачання:

  • Чи відповідають архітектура та налаштування мережі вимогам до продуктивності?

Класична помилка — проводити тестування продуктивності лише на стадії тестування.

Робота з вимогами, або катування колег

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

1. Беремо вимоги в замовника

2. Аналізуємо їх з аналітиком, беремо в нього статистичні дані

3. Опитуємо розробника, з'ясовуємо реальні параметри та можливі пороги системи. Погоджуємо з ним ТЗ навантаження

4. Опитуємо адмінів / devOps щодо актуальності зібраних вимог на сьогодні

5. Вмикаємо мізки й створюємо готовий документ

6. Обов'язково погоджуємо з адмінами розклад і технологію проведення навантажувальних тестів.

Види тестових серверів

У нашій практиці траплялося 4 основні категорії тестових серверів. Але ця класифікація не є жорсткою і значною мірою залежить від технології розробки. Здебільшого виділяють такі класи:

1. Локальний сервер. Розгортання вашого ПЗ на вашому комп'ютері. Зручно для функціонального тестування. Не застосовується для навантажувального тестування.

2. Тестовий сервер. Дуже широке поняття, зазвичай тестових серверів багато, може бути, що кожен програміст володіє власним тестовим сервером, на який викладає свій готовий код. Але може бути й лише один тестовий сервер, якщо компанія маленька. Може застосовуватися для навантажувального тестування.

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

4. Бойовий сервер (Production, Продакшен). Сервер, з яким безпосередньо працюють ваші клієнти чи користувачі. На нього викочується протестована версія (Pass QA). Вкрай не рекомендується проводити навантажувальне тестування на продакшені. Ви легко можете завалити його навантаженням, і буде лихо. Можна використати виділений кластер бойового сервера, якщо від нього буде відключено користувачів на час проведення тестів.

Тестовий стенд, або граблі, на які ми наступаємо

Від конфігурації тестового стенда в навантажувальному тестуванні залежить ДУУУЖЕ багато. У природі існує лише три співвідношення між тестовим і бойовим сервером:

a. Тестовий стенд дорівнює продакшену

b. Тестовий стенд архітектурно дорівнює продакшену

c. Тестовий стенд не дорівнює продакшену

Тестовий стенд дорівнює продакшену

Найпростіший і найзручніший випадок. Наші дії:

  • Встановлюємо версію, проводимо смоук-тестування
  • Навантажуємо відповідно до плану
  • Тюнимо й доводимо до розуму
  • Йдемо в продакшен
Тестовий стенд архітектурно дорівнює продакшену

У цьому випадку доведеться повозитися з налаштуваннями та обробкою результатів тестів. Наші дії:

  • Думаємо, як встановити версію, де що обрізати чи скоротити
  • Обрізаємо та/або скорочуємо бази даних, якщо потрібно
  • Встановлюємо, тестуємо версію
  • Навантажуємо відповідно до плану
  • Тюнимо й доводимо до розуму
  • Проводимо інтерпретацію результатів
  • Йдемо в продакшен
Тестовий стенд не дорівнює продакшену

Проблема архітектурної нерівності тестового та бойового серверів насправді дуже глибока і має свої підводні камені. Якщо ваш застосунок достатньо компактний, то купити окремий сервер, на якому можна розгортати

тестові версії — не проблема. Інша річ, якщо ви маєте справу з великими комплексними системами, як-от: поштові сервери, соцмережі, хмарні сховища, вебплатформи тощо... Тестування таких застосунків вимагає розгортання цілої мережі тестових машин. У підсумку це призводить до утворення тестового кластера. Спроба розгорнути такий кластер на машинах, що фізично стоять у центрі розробки, веде до створення власного дата-центру з усіма витратами такого рішення. Гарною альтернативою стало використання рішень на кшталт Amazon Web Services.

Природне бажання заощадити на оренді хостів чи купівлі обладнання призводить до вибору таких, характеристики яких занижені порівняно з production-інсталяцією. Занижені в рази. І тут у гру вступає коефіцієнт перерахунку між синтетичними індексами продуктивності. Тобто процесор у production буде вдвічі швидшим, ядер буде вчетверо більше, обсяг оперативної пам'яті буде вшестеро більшим, продуктивність дискової підсистеми буде в 3,5 раза кращою, а швидкість мережі — у 100 разів більшою. Складемо, поділимо на кількість показників, помножимо на якийсь поправковий коефіцієнт і отримаємо коефіцієнт перерахунку, на який множитимемо результати тестування продуктивності. Можна вигадати і складнішу формулу, наприклад, призначити кожному показнику певну вагу.

При ближчому розгляді такий підхід виявляється придатним лише для підготовки тестових наборів для майбутнього тестування на інсталяції, близькій до production, та для виявлення найочевидніших проблем продуктивності. (Що вже досить багато і важливо.) Чому? Та хоча б тому, що за такого підходу зовсім не враховується ефект bottlenecks.

Приклад із життя. Тести запускалися на одному хості, а тестований застосунок — на іншому. Тестова сюїта містила запити, що повертають різний обсяг даних у відповіді. Запити, які повертають відносно невелику кількість даних, дали задовільні результати, а запити з відповідями великого обсягу — незадовільні.

При цьому хост тестованого застосунку був далекий від перевантаження. Напрошується висновок: тестований застосунок погано справляється із запитами, що дають велику видачу, і при цьому не використовує всіх ресурсів машини, тобто потребує перепроєктування. А що ж насправді? А насправді з'ясувалося, що низька швидкість мережі призводила до довгої передачі відповідей, що особливо позначалося на відповідях великого обсягу і, таким чином, просто не давало створити велике навантаження на тестований застосунок.

Тестовий стенд не дорівнює продакшену — застосовуємо коефіцієнти

У випадку, коли важко порівняти залізо, а сервери підключені за однаковим мережевим каналом, можна застосувати коефіцієнт, визначений за яким-небудь стандартним запитом. У цьому разі ви робите N запитів на сервер і берете середній час для бойового T та для тестового сервера t. Потім розраховуєте коефіцієнт за формулою k = T/t (бойовий ÷ тестовий). Для коригування результату множите результат, отриманий на тестовому сервері, на цей коефіцієнт R = k * t.

Аналогічно застосовуємо коефіцієнти під час тестування різних версій

Якщо нова версія містить більше функціоналу, ніж попередня (стає «важчою»), або менше (стає «легшою»), то її не можна напряму порівнювати з попередницею. У такому разі також застосовуються коефіцієнти переходу.

Кому потрібні результати навантажувального тестування
  • Project або Release Manager
  • Capacity manager
  • Команді програмістів
  • Вашому тімліду
Це не дурні запитання
Інструмент навантажувального тестування — JMeter

Логічно припустити, що для проведення performance testing потрібне спеціально розроблене ПЗ. Звісно, Чубакка скаже, що можна збудувати зорельот, вивчити за методичкою мову програмування і написати власні навантажувальні скрипти. Але ми не будемо поринати в такий сум, а скористаємося готовим високоякісним програмним продуктом під назвою JMeter.

Чому саме ця програма, поцікавитесь ви?

Тому що вона:

а) Безкоштовна

б) Активно підтримується постачальником, з'являються нові, досконаліші версії

в) Чудово зарекомендувала себе серед тестувальників

г) JMeter — це Java-програма, що запускається на будь-якій ОС

д) Має серверну частину, здатну аналізувати стан сервера під час навантаження

Отже, вашій увазі пропонується Apache JMeter — інструмент для проведення навантажувального тестування, що розробляється Apache Software Foundation.

Хоча спочатку JMeter розроблявся як засіб тестування вебзастосунків, нині він здатен проводити навантажувальні тести для JDBC-з'єднань, FTP, LDAP, SOAP, JMS, POP3, IMAP, HTTP і TCP-протоколів.

Зрозуміло, що нас найбільше цікавить робота з HTTP і HTTPS протоколом. Також цікава можливість створення великої кількості запитів за допомогою кількох комп'ютерів із керуванням цим процесом з одного з них. Крім того, архітектура програми, що підтримує плагіни сторонніх розробників, дає змогу доповнювати інструмент новими функціями.

Планування роботи

Навантажувальне тестування насамперед починається з планування. План навантажувального тестування за допомогою програми JMeter складається з:

1. Визначення цілей тестування, розроблення профілів навантаження.

2. Встановлення та налаштування bot-net для розподіленого тестування (за потреби).

3. Запису CRUD-тесту Selenium як корисного навантаження для спрощення підготовки тест-плану.

4. Налаштування та налагодження навантажувальних тестів у JMeter.

5. Багаторазового відтворення навантажувальних тестів відповідно до профілів навантаження.

6. Аналізу результатів та формування звіту за розробленим шаблоном.

Встановлення та налаштування JMeter

1. Завантажити та встановити останню версію JDK (JDK 8)

2. Додати змінну середовища JAVA_HOME і встановити їй значення — каталог із JDK, наприклад, JAVA_HOME='c:\Program Files (x86)\Java\jdk1.6.0_27\'. Як це зробити.

3. Додати до значення змінної середовища Path рядок: ;%JAVA_HOME%bin

4. Завантажити Apache JMeter за посиланням і розпакувати. Небажано перейменовувати піддиректорії JMeter.

5. Додати змінну середовища JMETER_HOME і встановити їй значення — каталог із JMeter, наприклад, JMETER_HOME='c:\apache-jmeter-2.7\'

6. Додати до значення змінної середовища Path рядок: ;%JMETER_HOME%bin

7. Завантажити jp@gc-плагіни за посиланням, наприклад, JMeterPlugins-0.5.3, і розпакувати.

8. Скопіювати файл JMeterPlugins.jar з каталогу з розпакованим jp@gc-плагіном до каталогу %JMETER_HOME%lib\ext.

Зняття показників навантаження
Зняття показників навантаження із сервера

Налаштування jp@gc-плагіна для використання PerfMon Metrics Collectors

Щоб використовувати модулі PerfMon Metrics Collectors із jp@gc-плагіна, які знімають показники навантаження на боці сервера, необхідно також запустити сервер-агент JMeter на всіх серверах, що беруть участь у вимірюванні (сервери застосунку, БД та інші). Для цього потрібно:

1. Скопіювати каталог serverAgent із каталогу з jp@gc-плагінами на сервер, навантаження на який потрібно виміряти.

2. Для Windows-серверів запустити файл startAgent.bat. Для Linux-серверів запустити startAgent.sh, попередньо надавши права на запуск командою

3. chmod a+x startAgent.sh

Після запуску агента стануть доступні модулі PerfMon Metrics Collector Listener для підключення до агентів. У них можна додати кілька серверів для моніторингу. Один графік може відображати різні види метрик: завантаження процесорів, пам'яті, дискової підсистеми, мережевих адаптерів та інших.

Зняття показників навантаження із сервера

За замовчуванням JMeter не зберігає деякі дані, наприклад, кількість потоків і кількість запитів, у JTL-файли (у власному форматі JMeter). Якщо для підготовки звітів планується працювати з файлами JTL, потрібно у файлі з налаштуваннями %JMETER-HOME%bin\jmeter.properties зняти коментар із рядка, що містить змінну jmeter.save.saveservice.thread_counts, видаливши символ «#» на початку рядка, і встановити їй значення:

jmeter.save.saveservice.thread_counts=true

Це дасть змогу відображати правильні графіки з JTL-файлів, у яких використовується вказівка кількості потоків.

Потрібно зняти коментар із рядка, що містить змінну jmeter.save.saveservice.sample_count

і встановити її значення:

jmeter.save.saveservice.sample_count=true

Це дасть змогу відображати правильні графіки з JTL-файлів, у яких використовується вказівка кількості запитів.

Після виправлення файлу з налаштуваннями потрібно в JMeter GUI відкрити вікно конфігурації потрібного плагіна (кнопка Configure) і вибрати опцію Save Active Thread Counts.

Підготовка тест-плану JMeter

Для спрощення створення тест-плану JMeter потрібно використати комплект End-to-end-сценаріїв тестів у Selenium, дії в яких і використовуватимуться для запису навантажувальних тестів. Усі дії з тестами можна виконувати в гілці тест-плану Thread Group. Thread group перекладається як група потоків. Під час навантажувального тестування під кожну дію виділяється свій автономний потік, який виконується комп'ютером паралельно з іншими.

Щоб додати Thread Group, потрібно з контекстного меню елемента Test Plan вибрати Add - Thread Group. Елемент Thread Group дає змогу задавати параметри навантаження, що генерується на застосунок. Основними його параметрами є:

1. Number of threads - кількість потоків (імітованих користувачів, що одночасно працюють із сайтом);

2. Ramp-up period - проміжок часу, через який виконується запуск наступного процесу;

3. Loop count - кількість разів, яку виконуватиметься сценарій усередині Thread Group;

4. Forever - сценарій виконуватиметься постійно, доки його не буде явно перервано;

5. Scheduler - планувальник часу роботи сценарію;

6. Action to be taken after a Sample Error - дія, що виконується, якщо запит спричинить помилку.

Підготовчі дії перед записом: запис тест-кейсів

Поки що не додаватимемо HTTP Proxy Server до дерева тесту. Обговоримо, куди ми записуватимемо отримані «кроки». Пізніше, коли ми додамо елемент до дерева, побачимо, що є кілька можливостей, куди саме записувати результати. Їх можна записати прямо в «котушку» (Thread), на «верстак» (Workbench) або в елемент «Recording Controller». Раджу скористатися останнім способом. По-перше, це дасть змогу за потреби відключити (ctrl+t) весь лог одразу; по-друге, так краще відстежується та формується структура тесту.

Усі дії з додавання та редагування виконуються через контекстне меню за натисканням правої кнопки миші. Створені елементи можна просто перетягувати (drag and drop).

Отже: Test Plan -> Add -> Threads ->Thread Group; Thread Group -> Add -> Logic Controller -> Recording Controller.

Наполегливо раджу одразу дати всім елементам зрозумілі назви.

Налагодження скрипта

Налагодження скрипта полягає у видаленні різних .jpg, .png та посилань на сторонні ресурси. У мене в скрипті понад половина таких сторонніх ресурсів — це зв'язки з різними соцмережами та посилання на шрифти fonts.gstatic.com, а також сайт it school. Усе це можна вичищати (клавішею delete). Загалом можна вичистити й .js. Головне — знайти запит, який передає у своєму тілі облікові дані вашого користувача. Ну і для краси знайти запит, який веде вас на сторінку, на якій користувач логіниться. Таким чином, разом вони моделюють зв'язку в діях користувача «зайшов на сторінку — залогінився».

Припустімо, нам пощастило виокремити потрібні запити. Ну, або нам здається, що ми їх виокремили. Дамо їм читабельні назви! Щоб перевірити, чи те ми виокремили, скрипт треба запустити.

Авторизація

Якщо вам для тестування потрібно авторизуватися на сервері, додамо на верхівку дерева HTTP Autorization Manager (Thread Group – Add – Config Elements – HTTP Autorization Manager). Він інтуїтивно зрозумілий. Записуємо туди адресу нашого ресурсу, обов'язково з http://, ім'я користувача та пароль.

Якщо Менеджер авторизації потрібен для авторизації на сервері, то абсолютно точно під час авторизації на сайті використовуються куки. Додаємо Cookie Manager після Менеджера авторизації (TestPlan – Add – Config Elements — HTTP Cookie Manager). Цей елемент потрібно додавати, мабуть, завжди, коли йдеться про те, що користувачу потрібно залогінитися.

Запис звітів

Для візуалізації та логування результатів тестування в JMeter реалізовано Слухачі (Listeners). Слухачі бувають кількох типів:

  • Graph Full Results - відображення результатів тесту у вигляді графіка;
  • Graph Results - відображення основних (відхилення, середні величини) результатів тесту у вигляді графіка;
  • Spline Visualizer - відображення результатів тесту у вигляді графіка з усередненими (згладженими) значеннями.
  • А також Summary report , View results in Table

До групи потоків Thread Group необхідно додати елемент Listener. Для цього з контекстного меню Thread Group потрібно вибрати Add - Listener. Розкривається список слухачів. Серед них мають бути присутні як стандартні, так і додаткові графічні jp@gc-плагіни від Google для відмальовування графіків.

Рекомендований мінімальний набір модулів для тест-плану

Рекомендується включати в кожен новий тест-план такі модулі (по кожному з яких є система онлайн-допомоги, достатньо натиснути кнопку Help on this plugin):

1. До гілки WorkBench додати HTTP Test Script Recorder для первісного запису тестових сценаріїв, якщо застосунок працює з протоколом HTTP.

2. До гілки Test Plan додати рандомайзер Uniform Random Timer зі значенням 100-200 мс.

3. До гілки Test Plan додати HTTP Request Defaults для налаштування запитів за замовчуванням, якщо застосунок працює з протоколом HTTP.

4. До гілки Test Plan додати HTTP Cookie Manager, якщо застосунок використовує cookie.

5. До гілки Test Plan додати потрібну кількість Thread Group, які виступають як окремі тест-кейси, куди потрібно записувати дані від проксі-сервера.

6. До гілки Thread Group додати стандартні табличні звіти про результати тестування: Summary Report, View Results in Table, View Results Tree.

7. До гілки Thread Group додати стандартні графічні звіти про результати тестування: Graph Results, Spline Visualizer.

8. До гілки Thread Group додати графічні звіти jp@gc-плагіна: jp@gc - Response Times Percentiles (показує процентилі доступу до даних), jp@gc - Response Times vs Threads(показує зміну часу відгуку залежно від кількості запущених потоків), jp@gc - PerfMon Metrics Collector (для отримання даних щодо завантаження CPU, Memory, Swap, Disk I/O,Network I/O та інших з боку сервера від агентів JMeter).

9. У кінець гілки Test Plan додати Monitor Results для відстеження стану сервера під

час проведення тесту.

Альтернативи для JMeter

HP Loadrunner - потужна тулза, що користується визнанням у деяких компаніях. Її очевидний мінус у тому, що вона дорога.

Siege - альтернативна безкоштовна програма, аналогічна JMeter, можете прочитати її детальний опис

Load impact - програма для навантажувального тестування через вебінтерфейс. Сервер зробить усе за вас сам, але, як завжди в таких випадках, жодної гнучкості.

Loadstorm - також тестування через вебсервіс.

Практика та ДЗ

Ось інструкція для твого практичного завдання:

1. Перевірити, що на ПК встановлено Java, за наших часів вона водиться майже на будь-якій машині. Якщо ні, то мерщій встановлюйте.

2. Встановити собі програму JMeter

3. Створити access log сайту software-testing.ru/ Якщо access log поки порожній, нам ніщо не заважає трохи його поповнити, пройшовши сайт першим-ліпшим краулером, наприклад HTTrack або Xenu. Якщо вебсервер — IIS, то попередньо потрібно переключити формат логу на NCSA, який розуміє парсер JMeter. Брати лог із працюючого сервера (коли він туди пише) не варто, краще взяти вже закритий, скажімо, вчорашній, або призупинити вебсервер на час вилучення логу. Лог варто переглянути текстовим редактором на предмет коректності. Допомогу у виконанні завдання ти отримаєш від магістра далі.

Результатом роботи будуть скриншоти графіків, таблиць

і лог-файл із записами роботи JMeter. Усе потрібно

зібрати в архів, вивантажити й надіслати через форму.

Також необхідно провести базовий аналіз ваших

результатів:

в який момент часу і за якої кількості

користувачів зупиниться зростання продуктивності throughput, коли з'являться перші http-помилки і коли

вони перевищать поріг у 3%. Ось приклад звіту: скопіюй його собі.

І звісно, ти з нетерпінням чекаєш на тест рівня

Генеруємо лог-файл (список сторінок для тестування)

У цьому завданні, щоб спростити його, ми не користуватимемося жодним сценарієм, а просто навантажимо комплект доступних сторінок сайту. Для цього необхідно здобути список (мапу) URL сайту. Оскільки сучасні сайти почали використовувати захист від сканування, зручно користуватися сканерами через додаток до браузера. Наприклад, Link Klipper для Chrome. Цей застосунок просканує доменну адресу та видасть приблизно такий список:

http://software-testing.ru/user/forgot.php
http://software-testing.ru//user/user_add.php
https://top100.rambler.ru/top100/
http://software-testing.ru/app/
https://www.facebook.com/gorod.dp.ua/
...

Посилання на зовнішні сайти, аналогічні червоним, варто видалити, інакше вони зіпсують результат тестування недостовірними даними. Потім робимо глобальну заміну частини «http://test.local» на «" GET» (з лапкою й пробілом), отримуємо

"GET /index.php

"GET /news/event-12.php

...

Краще користуватися Notepad++ для подібної операції, оскільки Word додає спецсимволи.

Зверніть увагу, що доменне ім'я не вказується в посиланні, а лише адреса внутрішнього посилання. Сам же домен вказується в налаштуваннях JMeter. Кожне посилання має бути з нового рядка, документ — у звичайному текстовому форматі.

Редагуємо тест-план

1. Відкриваємо ApacheJMeter.jar

2. Ліворуч бачимо дерево з 2 вузлів: TestPlan і Workbench (про другий одразу забуваємо, він нам не знадобиться). На Test Plan клікаємо правим кліком і кажемо Add->Thread Group (в інтерфейсі можна побачити багато фішок різного ступеня корисності, але ми зараз не відволікаємося, а найкоротшим шляхом ідемо до нашого тесту, потім, якщо захочемо — вивчатимемо широкі можливості JMeter докладніше).

Додаємо файл логу
  1. Правим кліком на Thread Group додаємо Access Log Sampler (Thread Group->Add->Sampler->Access Log Sampler)
  2. Заповнюємо дані для access.log Вбиваємо адресу сервера (лише доменне ім'я) Вибираємо протокол: HTTP або HTTPS, вводиться великими літерами Порт ставимо 80 Вказуємо шлях до файлу access.log на вашому ПК
Додаємо генератори звітів

Тепер додаємо до тесту засоби відображення:

1. Thread Group->Add->Listener->View Results in Table

2. Thread Group->Add->Listener->Graph Results

3. Thread Group->Add->Listener->Aggregate Report

У View Results in Table треба заповнити поле Filename (якщо не вказувати шлях, лог-файл утвориться поруч із jmeter.bat). Створювати лог необхідно для налагодження, оскільки JMeter у своєму GUI не виводить толкової інформації про помилки.

Тест-план готовий, переходимо до його тестування :) і налагодження (нічого-нічого, він може й з першого разу запрацювати).

File->Save, і так щоразу після внесення змін до тест-плану. Це важливо, JMeter іноді зависає, і тест доводиться відновлювати по пам'яті.

Run->Clear All (вперше можна не робити, але потім усе одно знадобиться).

Run->Start.

І йдемо дивитися у View Results in Table. Якщо нам пощастило, там буде один рядок із зеленою галочкою в колонці Status.

Результат підготовки

Запускаємо (File->Save, Run->Clear All, Run->Start). Ідемо дивитися у View Results in Table. Має вийти якось так:

Нарешті запускаємо тест

Перш ніж почати тест, додамо на початок сценарію випадкову затримку (Uniform Random Timer) 0-1000 мілісекунд, вона зазвичай допомагає дещо згладити графіки. Сценарій у результаті працює так: чекає випадкову кількість мілісекунд, читає рядок із логу, робить HTTP-запит, передає результати лістенерам, знову чекає, читає наступний рядок і так далі.

Робимо перший, пристрілочний тест. У властивостях групи потоків поставимо: Number of Threads (users): 100, Ramp-Up Period (in seconds): 100. Ми збираємося нацькувати на сайт 100 віртуальних юзерів, вводячи їх у бій по одному протягом 100 секунд, тобто по юзеру за секунду. Цифри 100 і 100 я взяв звідкись зі стелі, але ж треба з чогось починати.

Ще раз нагадаємо собі, що ми маємо добрі шанси пригальмувати чи навіть завалити сайт (що може бути недобре, якщо йдеться про вже робочий проєкт). ОК, будучи при здоровому глузді та твердій пам'яті, усвідомлюючи відповідальність за свої дії, починаємо.

File->Save, Run->Clear All, Run->Start і йдемо дивитися Graph Results. Бачимо, скажімо, таку картинку

У правому верхньому куті можна спостерігати поточну кількість віртуальних користувачів.

Про що говорить нам цей графік? Середній час відгуку (Average) зростає, а швидкість обробки (Throughput) не змінюється. Це означає, що десь на сервері операції стають у чергу, і продуктивності не вистачає, щоб обслужити всі запити. Зайшовши браузером на сайт, переконаємося, що він ледве ворушиться або взагалі не респондить. Навіщо марно мучити бідолаху? Run->Stop. Ну ось, сайт знову ожив. Невдала ідея під час такого тесту — відволіктися ненадовго і, повернувшись через кілька годин (як це буває), виявити, що сайт півдня лежав.

Як змістовний результат ми отримали одне число — максимальне значення Throughput (183 запити на хвилину). Можна вважати його межею продуктивності. Для початку цього числа може бути достатньо, наприклад, уже ясно, що 100 000 хостів на добу наш сайт не потягне.

Аналіз результатів тесту

Проведемо аналогічні тести для іншого сайту. Зараз ми розберемося, як точно зрозуміти, коли настає момент перевантаження сервера. За допомогою лістенера View Table in Tree. Можна встановити, що перші збої та 503 помилки в системі відбулися за запущених 31-34 потоків. Отже, критична кількість активних користувачів для сервера — приблизно 35. Але при цьому потрібно розуміти, що активність тестових користувачів значно перевищує активність реальних людей. Навряд чи хтось переходитиме сайтом зі швидкістю 1 сторінка за 2 секунди.

Аналіз графіка навантаження

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

На Graph results можна подивитися графіки «відгуку» сервера

Значення надано в мілісекундах:

Data — час відгуку на кожен виконаний запит.

Average — середній час відгуку сервера, об'єктивний графік навантаження.

Throughput — швидкість виконання самого запиту.

Median — значення медіани (використовується в статистиці, цими даними можна не користуватися).

Deviation — похибка, стандартне відхилення.

До речі, поки JMeter «висить» — процес тестування зазвичай триває, що загрожує неприємними наслідками, якщо ви тестуєте робочий сервер.

Червоною стрілкою на графіку позначено ключовий момент — коли throughput (швидкість виконання запитів) перестала зростати. Чому це важливо? Тому що в міру того, як зростає кількість користувачів, для забезпечення коректної роботи для них усіх необхідно нарощувати швидкість обробки користувацьких запитів. Якщо кількість користувачів зростає, а швидкість обробки даних залишається колишньою, виходить, що з плином часу кожному користувачу приділяється дедалі менше операційного часу. Отже, він чекатиме на відповідь довше й довше. Це називається перевантаженням сервера.

Зі збільшенням навантаження час обробки не лише зростає, але в якийсь момент сервер узагалі перестане відповідати деяким користувачам. Дивимося наступний етап.

Аналіз результатів тесту

У Summary Report можна побачити узагальнені дані та частоту збоїв за певної кількості користувачів

Нас тут цікавлять такі метрики:

Samples - кількість поточних потоків. Визначить точку відліку перевантаження

Average - Середній час відгуку вкаже на час спрацювання сайту під час навантаження

Error% - ключовий параметр. Відсоток збійних запитів. За цим параметром ми обчислимо максимальну кількість користувачів, яку витримає система, за якої % помилок буде в межах, заданих вимогами.

Throughput - швидкість обробки запитів

На цьому графіку можна також побачити переломний момент і припинення зростання продуктивності, більше того, зрозуміти, яка саме кількість користувачів стала критичною. Критична кількість користувачів — та, за якої сервер почав відповідати помилкою на запит.

Підсумок. Ключові моменти в аналізі навантаження

1. Сигналом про настання перевантаженості сервера є те, що середній час відгуку (Average) зростає, а швидкість обробки (Throughput) не змінюється. Це означає, що десь на сервері операції стають у чергу і продуктивності не вистачає, щоб обслужити всі запити. Цей момент можна побачити на графіку Graph Results. У такому разі у висновках зазначаємо N-ну кількість користувачів.

2. Другою метрикою є поява серверних помилок — 503, 505, 404 тощо. Це означає, що сервер, крім того що ставить запити в чергу й не встигає їх обробляти, почав частину запитів просто відхиляти. Це вже критичне перевантаження. Його можна спостерігати в таблиці View Results. У звіті вказуємо цей момент.

3. Третьою метрикою є відсоток помилок за певної кількості користувачів. Цей параметр знаходиться в Summary Report. Його ми порівнюємо з вимогами та вносимо до звіту. У вимогах має бути вказано допустимий поріг помилок.

4. Позитивний результат. Тестувальнику не завжди лише знаходити баги, буває, що їх немає. Якщо система витримала заплановане навантаження і відсоток помилок був у межах норми вимог, то така система успішно проходить навантажувальне тестування, у нас PASS QA.

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

Акт виконаних робіт з навантажувального тестування

Результати навантажувального тестування узагальнюються в акті виконаних робіт. Якщо вам доведеться виконувати навантажувальне тестування на робочому місці — скористайтеся цим шаблоном. У практичному завданні заповнювати цей звіт не потрібно. Цей документ має таку структуру:

1. Титульний аркуш «Акт виконаних робіт з навантажувального тестування» із зазначенням:

Тестований застосунок: вказуємо офіційну назву застосунку.

Тестування проводив: вказуємо інженерів, які брали участь у тестуванні.

Дата й час тестування.

Етап тестування: наприклад, етапи 1, 2, 3 означають, який за рахунком раз проводиться тестування застосунку після внесення в нього чи в інфраструктуру змін або після зміни вимог до продуктивності.

Версія документа: наприклад, 1.0, яка вказує поточну модифікацію акта в межах одного етапу тестування;

Дата складання звіту: вказується дата складання поточної версії документа.

Відповідальна особа: вказується відповідальний за проведення тестування та складання звіту (РП або нач. відділу).

2. Зміст.

3. Вступ.

Зазначається, що являє собою документ, і дається короткий опис тестованого застосунку, який можна взяти, наприклад, із ТЗ.

Зазначається, які основні функції, підсистеми чи модулі застосунку тестувалися.

Використані інструменти тестування: перелічується весь інструментарій для проведення тестування, наприклад, apache-jmeter-2.7, JMeterPlugins-0.5.2, Selenium IDE-1.8.1.

Додатки: усі артефакти тестування, наприклад, тест-план JMeter, .jtl-файли з результатами, графіки результатів вимірювань, скриншоти тощо.

4. Цілі та завдання. Наприклад:

Визначити відповідність продуктивності системи висунутим вимогам для різних профілів навантаження, описаних далі.

Визначити критичні параметри навантаження, які призведуть до відмови Застосунку.

5. Терміни та визначення, що використовуються у звіті.

6. Інфраструктура Застосунку.

IP-адреса: вказується IP-адреса або адреси серверів, де розгорнуто тестовий стенд Застосунку.

Мережевий шлях до застосунку: вказується мережева адреса або адреси, за якими можна отримати доступ до інтерфейсу Застосунку.

Схематично, графічно описується мережева структура Застосунку, на якій перелічуються його основні ресурси, вузли та підсистеми.

Інвентаризація ресурсів Застосунку. У табличному вигляді описуються ресурси застосунку, наведені вище на схемі. Таблиця містить стовпці: № з/п, Ресурс, Hardware, Software.

7. Показники продуктивності. Вказуються показники, що вимірюються на цьому етапі, та метрики, які для цього використовуються. Наприклад, показники, наведені вище.

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

9. Вимоги до продуктивності. Описуються допустимі значення параметрів, що вимірюються, за яких навантажувальний тест вважається успішно пройденим.

10. Опис методики тестування. Коротко описуються підходи до проведення тестування, розповідається про підготовку тестового стенда, наприклад, опис структури bot-net, опис корисного навантаження, принцип підбору тестів.

11. Вимірювальна частина, що містить узагальнені результати тестування за кожним профілем із поясненнями. На початку можна вказати таблицю видів запитів, що використовуються під час тестування навантаження.

12. Аналіз результатів тестування, зведення результатів вимірювань в узагальнені таблиці, їх порівняння з результатами попереднього етапу тестування (за потреби). Порівняння результатів може бути наведено на графіках-гістограмах.

13. Загальні висновки та рекомендації. За результатами навантажувального тестування та аналізу даних робиться висновок про працездатність застосунку під навантаженням. Наприклад, за якої кількості потоків (підключень користувачів) і в якому режимі навантаження він демонструє стійку працездатність. Наводяться рекомендації щодо забезпечення прийнятної роботи користувачів. Висуваються пропозиції щодо підвищення продуктивності застосунку та забезпечення комфортної роботи потрібної кількості користувачів.

Додаткові налаштування, які можуть знадобитися

Можна налаштувати деякі параметри плагінів шляхом редагування файлу %JMETER_HOME%bin\user.properties і додати такі рядки в його кінці:

# Увімкнути або вимкнути градієнт фарби для графіків. Значення — істина або хиба, за замовчуванням це істина.

jmeterPlugin.drawGradient = True

# Глобально вимкнути остаточне обнулення ліній на всіх графіках. Значення — істина або хиба, за замовчуванням це хиба.

jmeterPlugin.neverDrawFinalZeroingLines = True

# Глобально вимкнути відображення осі абсцис X на всіх відповідних графіках. Значення — істина або хиба, за замовчуванням це хиба.

jmeterPlugin.neverDrawCurrentX = True

# Увімкнути або вимкнути масштабування осі Y для зручності читання. Значення — істина або хиба, за замовчуванням це істина.

jmeterPlugin.optimizeYAxis = True

# Використовувати відносний час у часі на основних графіках. Значення — істина або хиба, за замовчуванням це істина.

jmeterPlugin.useRelativeTime = True

# Виводити CSV-роздільник. За замовчуванням ',' якщо десятковий роздільник — '.' або ';'. В іншому разі вказати

Додаткові налаштування, які можуть знадобитися

JmeterPlugin.csvSeparator =;

# Виводити CSV-формат часу (див.http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html)

jmeterPlugin.csvTimeFormat=HH:mm:ss

# Додавати чи ні префікс до пунктів плагіна в меню JMeter. Значення — істина або хиба, за замовчуванням це істина.

jmeterPlugin.prefixPlugins = True

Ці налаштування не є обов'язковими, вони потрібні лише для зміни поведінки за замовчуванням. За потреби будь-які налаштування можна закоментувати символом #.

Опції drawGradient, neverDrawFinalZeroingLines, neverDrawCurrentX, useRelativeTime можуть бути динамічно змінені за допомогою панелі налаштувань (SettingsPanel) відповідного модуля.

Корисна література:

Як треба і як не треба проводити навантажувальне тестування