Повне керівництво з тестування продуктивності з прикладами

complete performance testing guide with examples

Що таке тестування продуктивності?

Тестування продуктивності також називають «Perf Testing» - це тип тестування, що проводиться для перевірки ефективності роботи програми чи програмного забезпечення під навантаженням з точки зору чуйності та стабільності. Метою тесту ефективності є виявлення та усунення вузьких місць продуктивності з програми.

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

завантажити високоякісне аудіо з YouTube

У цій серії підручників ми розглянемо повні деталі, такі як - Типи тестування, процес та написання стратегії тестування продуктивності з нуля.

Це детальна серія підручників, яку ви, можливо, захочете додати у закладки!

Давайте дослідимо!

Перелік ВСІХ підручників з тестування продуктивності в цій серії:

Підручник No1: Повне керівництво з тестування продуктивності (Цей підручник)
Підручник No2: Різниця між тестуванням продуктивності, навантаження та напруги
Підручник No3: Функціональне тестування проти тестування продуктивності
Підручник No4: План тестування продуктивності та стратегія тестування
Підручник No5: Способи перезарядити ваше тестування продуктивності
Підручник No6: Посібник з тестування хмарної продуктивності
Підручник No7: Посібник із тестування продуктивності мобільних додатків
Підручник No8: Як проводити ручне тестування продуктивності
Підручник No9: Підручник з тестування продуктивності веб-сайтів
Підручник No10: Компанії для тестування продуктивності
Підручник No11: Тестування продуктивності за допомогою LoadRunner (Серія)

Інструменти:

Підручник No12: Засоби тестування найвищої продуктивності
Підручник No 13: Підручник з тесту продуктивності Neoload
Підручник No14: Підручник з тестування продуктивності для мобільних пристроїв BlazeMeter
Підручник No15: Підручник з тестування навантаження, напруги та продуктивності WAPT
Підручник No16: Підручник з тестування продуктивності веб-сайту SmartMeter.io

Що ви дізнаєтесь:

• Види тестування продуктивності
  • Тестування навантаження
  • Стрес-тестування
  • Об'ємне тестування
  • Перевірка ємності
  • Тестування на надійність / відновлення
• Процес перевірки продуктивності
• Як написати документ про стратегію перевірки ефективності?
  • Зразок шаблону стратегії тестування продуктивності
  • #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) POC / Вибір інструменту

Як тільки ключова функціональність визначена, POC (Proof Of Concept - це свого роду демонстрація діяльності в режимі реального часу, але в обмеженому сенсі) виконується за допомогою доступних інструментів.

Список доступних інструментів залежить від вартості інструменту, протоколу, який використовує додаток, технологій, що використовуються для побудови програми, кількості користувачів, яких ми імітуємо для тесту тощо. Під час POC створюються сценарії для ідентифікованого ключа функціональність і виконується з 10-15 віртуальними користувачами.

# 3) План та дизайн тестування продуктивності

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

Планування тесту включає інформацію про те, як буде проходити тест продуктивності - середовище тесту, робоче навантаження, обладнання тощо.

Детальніше про документ Тестової стратегії нижче.

автоматизовані засоби тестування веб-додатків

# 4) Розробка тесту продуктивності

• Створюються випадки використання для функціональних можливостей, визначених у плані тесту як сфера дії ПТ.
• Ці випадки використання передаються клієнту для їх затвердження. Це робиться для того, щоб сценарій був записаний з правильними кроками.
• Після схвалення розробка сценарію починається із запису кроків у випадках використання за допомогою інструменту перевірки продуктивності, вибраного під час POC (Доказ концепцій) та посиленого за допомогою виконання Кореляції (для обробки динамічного значення), Параметризації (підміна значення) та користувацьких функцій як відповідно до ситуації або потреби. Детальніше про ці методи в наших відеоуроках.
• Потім сценарії перевіряються щодо різних користувачів.
• Паралельно зі створенням скриптів команда виконавців також продовжує працювати над налаштуванням тестового середовища (програмне та апаратне забезпечення).
• Команда виконавців також подбає про метадані (бек-енд) за допомогою сценаріїв, якщо клієнт не зайняться цією діяльністю.

# 5) Моделювання тесту продуктивності

Модель навантаження продуктивності створена для виконання тесту. Основною метою цього кроку є перевірити, чи досягнуті під час тестування задані показники ефективності (надані клієнтами) чи ні. Існують різні підходи до створення моделі навантаження. “ Закон Малого ”Використовується в більшості випадків.

# 6) Виконання тесту

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

Виконання тесту виконується поступово. Наприклад, Якщо максимальна кількість користувачів дорівнює 100, сценарії спочатку запускаються з 10, 25, 50 користувачами тощо, з часом переходячи до 100 користувачів.

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

Результати випробувань є найважливішими результатами тестування продуктивності. Тут ми можемо довести рентабельність інвестицій (ROI) та продуктивність праці, яку може забезпечити тестування продуктивності.

Деякі з найкращих практик, які допомагають процесу аналізу результатів:

1. Унікальна та значуща назва кожного результату тесту - це допомагає зрозуміти мету тесту.
2. Включіть наступну інформацію в підсумок результатів тесту:

• Причина несправності
• Зміна продуктивності програми порівняно з попереднім тестовим запуском
• Зміни, внесені в тесті з точки збірки додатків або тестового середовища.
• Це хороша практика робити підсумок результатів після кожного тестового запуску, щоб результати аналізу не збиралися щоразу, коли посилаються результати тесту.
• PT, як правило, вимагає багатьох тестових запусків, щоб дійти правильного висновку.
• У підсумку результатів добре мати такі пункти:
  • Мета тесту
  • Кількість віртуальних користувачів
  • Короткий зміст сценарію
  • Тривалість тесту
  • Пропускна здатність
  • Графіки
  • Порівняння графіків
  • Час реакції
  • Сталася помилка
  • Рекомендації

# 8) Звіт

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

Звіт про випробування вважається добрим, якщо він короткий, описовий та суттєвий.

Як написати документ про стратегію перевірки ефективності?

Цей підручник пояснить, як написати зразок стратегії перевірки продуктивності для програми обміну повідомленнями.

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

Зразок шаблону стратегії тестування продуктивності

Про програму чату ABC - Припустимо, що це робочий стіл чату, який використовується у компанії їхнім агентом підтримки клієнтів. Цей додаток для чату використовує протокол XMPP, тобто протокол розширених повідомлень та присутності та сервер Open fire для надсилання та отримання миттєвих повідомлень.

Деякі вдосконалення були внесені до цього існуючого клієнта чату, такі як віддалене керування ПК, діагностика ПК, інструменти ремонту, онлайн-чат тощо, тому ця стратегія тестування продуктивності є прикладом таких програм.

Для цього додатка припустимо, що команда проекту вирішила використати JMeter для тестування продуктивності та JIRA для відстеження дефектів.

Перша сторінка документа 'Стратегія перевірки ефективності' повинна містити заголовок документа та авторські права Компанії.

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

Третя сторінка повинна містити Зміст, а потім наступні теми.

#1. Вступ

Мета цього документа - визначити / пояснити, як буде проводитися тестування продуктивності в програмі чату ABC для поточного та майбутнього стану.

Додаток для чату ABC - це внутрішній робочий стіл агента з віддаленої підтримки. Цей робочий стіл буде використовуватися для виконання запитів клієнтів. Цей Workbench має такі можливості, як Інтернет-чат, Ідентифікація клієнта, Віддалене керування ПК, Діагностика ПК та інструменти ремонту.

Об’єктивна

Основними цілями тестування є такі:

• Щоб отримати впевненість, що зміни до існуючої програми чату відповідають визначеній Угоді про рівень обслуговування.
• Щоб гарантувати, що в результаті нових удосконалень не вплине на продуктивність програми, доступність послуги та стабільність програми.
• Час реакції транзакції залишається в межах допустимого допуску щодо зростаючого профілю навантаження.
• JVM демонструють стабільне використання пам'яті в порівнянні зі зростаючими профілями навантаження.

На малюнку нижче чітко пояснюється процес тестування та оптимізації продуктивності:

Архітектура

Вам потрібно включити архітектурну схему вашого проекту в цей сеанс.

# 2) Сфера дії

У сферу дії

Нижче наведено область тестування продуктивності для робочого середовища чату ABC:

• Отримання знань про ключові ділові операції та розподіл навантажень після детального вивчення системи.
• Визначте критичні сценарії тестування продуктивності за допомогою різних шляхів проекту.
• Використовуйте результати попереднього випуску як базову лінію для майбутніх випусків.
• Перевірка та перевірка середовища тестування продуктивності та інфраструктури інструменту тестування продуктивності / навантаження для будь-яких додаткових машин-агентів.
• Підготовка сценаріїв тесту продуктивності з використанням JMeter для виявлених сценаріїв, що імітують ідентифіковане пікове навантаження.
• Налаштуйте моніторинг продуктивності на серверах для моніторингу тесту з метою виявлення вузьких місць на етапі виконання тесту.
• Опублікуйте результати перевірки ефективності.
• Узгоджувати з різними зацікавленими сторонами для вирішення виявлених проблем ефективності.
• Базовий рівень продуктивності майбутніх випусків.

Виходить за рамки

• Функціональне тестування , UAT, тестування системи та тестування безпеки.
• Тестування / моніторинг будь-яких сторонніх інтерфейсів.
• Налаштування продуктивності. (Частіше за все налаштування виконується іншою командою, якщо у вас є інженери-виконавці, які налаштовують систему, ви можете додати це в Inscope).
• Профілювання коду / Розмір апаратного забезпечення / Планування потужності.
• Безпека / Тестування вразливості / UAT / Тестування білої скриньки .
• Генерування даних для тестування продуктивності.
• Нефункціональні тести ( Наприклад, збій, аварійне відновлення, резервне копіювання, зручність використання), крім тестів продуктивності.
• Тестування будь-якого мобільного рішення.
• Тестування та налаштування продуктивності сторонніх додатків.
• Реалізація рекомендацій щодо продуктивності, змін коду програми та змін продуктів / серверної конфігурації, що підтримуються постачальником, буде поза рамками з точки зору Performance Team.
• Підтримка інфраструктури / Розгортання збірки / Готовність до навколишнього середовища / Відновлення бази даних / Підтримка мережі тощо.

# 3) Підхід

Тестування продуктивності для чату ABC буде проводитись за допомогою Jmeter, створюючи власні плагіни XMPP, які використовують бібліотеку smack для з'єднань XMPP. Ці бібліотеки використовуються для встановлення з'єднань, входу в систему та надсилання повідомлень чату на сервер XMPP.

Ці бібліотеки об’єднуються у jar-файл, який розгортається в Jmeter і розроблений на основі сценаріїв, що перевіряються. Jmeter Work Bench встановлюється на локальній машині, яка підключається до сервера JMeter, який має генератори навантаження, щоб генерувати необхідне навантаження на систему сервера чату для моніторингу поведінки системи.

Тестовий сценарій буде написаний за допомогою інструмента JMeter. Сценарії будуть налаштовані відповідно до вимог. Графік буде створений з необхідним нарощуванням для моделювання реальних сценаріїв.

Тестовий сценарій буде розбитий та виміряний у наступних аспектах:

а) Базовий тест: Запустити кожен сценарій за допомогою 1 Vuser та декількох ітерацій, щоб визначити, чи відповідає продуктивність додатка Угоді про рівень обслуговування бізнесу чи ні.

b) Тест базового навантаження: Для того, щоб задовольнити Бізнес Бенчмарк під тестом на навантаження, команда з тестування продуктивності проведе тест базового навантаження, який допоможе виявити будь-які проблеми з продуктивністю системи із збільшенням навантаження та створить базовий рівень для наступного рівня тестування продуктивності.

в) Випробування на максимальне навантаження / масштабованість: Команда тестування продуктивності виконає кілька тестів із збільшенням кількості користувачів, щоб задовольнити очікуване навантаження, а також виміряти продуктивність програми, щоб встановити криву продуктивності та визначити, чи може розгортання підтримувати домовленості про рівень обслуговування під час пікового навантаження користувача.

найкраща системна утиліта для Windows 10

Це допомагає у налаштуванні або плануванні потужності окремих віртуальних машин Java (JVM), загальної кількості необхідних JVM та процесорів. Це буде досягнуто за рахунок збільшення кількості вузерів до 50%, 75%, 100% та 125% пікової потужності.

г) Тест на витривалість: Команда тестування продуктивності проводитиме цей тест протягом 8 годин / 16 годин / 24 годин для виявлення витоків пам'яті, проблем з продуктивністю з часом та загальної стабільності системи. Під час тестів на витривалість команда тестування продуктивності контролює ключові показники ефективності, такі як час реакції транзакцій та стабільність використання пам'яті.

Системні ресурси, такі як центральний процесор, пам’ять та введення-виведення, повинні контролюватися за допомогою команди проекту.

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

Сценарії перевірки продуктивності

Включіть Excel у набір сценаріїв.

Наприклад,

Сценарій 1: Для перевірки чату агента та клієнта для X №. паралельних сесій.

Типи тестів продуктивності

У наведеній нижче таблиці пояснюються різні типи тестів ефективності та їх цілі.

Показники ефективності

• Клієнтські метрики

• Показники продуктивності системи та мережі

Діяльність щодо тестування продуктивності та результати

# 4) Дані тесту

Передбачається, що дані про робоче середовище будуть копією виробничих даних, а необхідні дані випробувань будуть надані командою проекту.

# 5) Критерії в'їзду та виїзду

• Доступ до всіх програм у середовищі.
• Готовність до довкілля повна.
• Готовність даних тесту продуктивності.

# 6) Управління дефектами

• Модуль управління дефектами в JIRA буде використаний у проекті для реєстрації дефектів та відстеження до закриття.
• Виявлення дефектів, виявлених на етапі виконання тесту, буде зафіксовано в JIRA, і ці дефекти будуть усунені командою розробників відповідно до наведених нижче серйозностей.
• Щоденно проводяться зустрічі з огляду дефектів за участю тестувальників, розробників, аналітиків якості та бізнес-команд.
• Критерії виправлення дефектів будуть жорсткішими, коли проект наближається до дати Go Live. Вказівки щодо критеріїв виправлення дефектів, які будуть опубліковані на нарадах з розгляду дефектів.

Визначення тяжкості дефекту

Визначення кодів тяжкості такі:

# 7) Інструменти та методи тестування

№8) Критерії призупинення та відновлення

Нижче наведено критичні критерії призупинення та відновлення, які вплинуть на тестування:

# 9) Тестові результати

Результати тесту на продуктивність включають:

• Стратегія тестування продуктивності
• Документ про вимоги до виконання
• Документ сценарію перевірки продуктивності
• Сценарії перевірки продуктивності
• Результати перевірки ефективності

# 10) Ролі та обов'язки

Ролі та обов'язки чітко пояснюються в таблиці, наведеній нижче.

# 11) Потенційні ризики та план пом'якшення наслідків

# 12) Припущення

• Середовище тестування продуктивності буде копією архітектури продукту. (тобто правильне обладнання, програмне забезпечення, інтерфейси, рівні інтеграції тощо).
• Сценарії продуктивності розроблятимуться на основі критичних потоків, для яких використовується велике використання.
• Усі питання інфраструктури повинні бути вирішені до початку тестування продуктивності. Будь-які зміни конфігурації системи, зроблені пізніше, призведе до втрати результатів тесту.
• Додаток стабільний і готовий до використання в середовищі тестування продуктивності.
• Доступні необхідні апаратні та програмні ресурси (наприклад, машини / програмне забезпечення генератора навантаження, машини контролера / агента).
• Будь-які зміни в обсязі будуть проходити процес контролю змін, і команда тестування продуктивності оцінить вплив термінів та ресурсів.
• Очікується, що відповідні сервери будуть обробляти навантаження.
• Для цілей моніторингу слід підтримувати журнали трасування програм для підтримуючих систем.

# 13) Залежності

• Наявність тестового середовища продуктивності, яке є копією ландшафту архітектури продукту.
• Під час підготовки до тестування та етапів виконання необхідна підтримка різних команд з функціональних питань, розробки, баз даних та інфраструктури.
• Протягом усього етапу тестування продуктивності зміни коду не застосовуються, оскільки час дуже обмежений.
• У разі виникнення непередбачених проблем, що призводять до обмежень у терміни, якщо часові шкали не дозволяють виконувати всі тестові обсяги протягом вихідних дат, важливу підтримку можна отримати у Менеджерів випусків для надання рішення про визначення обсягу та встановлення пріоритетів.
• Бізнес-користувачі додатків / Експерти з предметних питань будуть доступні для функціональних уточнень та виходу з бізнес-операцій.
• Менеджер програми чату ABC перевірить і вийде з системи.

# 14) Скорочення

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

Найкращі практики для реалістичного тестування продуктивності

Для того, щоб успішно завершити проект перевірки ефективності, нам потрібно переконатися, що ми робимо це правильно з етапу планування, тобто планування, розробка, виконання та аналіз.

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

# 1) Планування

• Спробуйте визначити найпоширеніші робочі процеси, тобто бізнес-сценарії, які необхідно перевірити. Якщо програма є існуючою, перевірте журнали сервера, щоб зрозуміти найбільш часто використовувані сценарії. Якщо заявка нова, поговоріть з командою управління проектами, щоб зрозуміти основний бізнес-потік.
• Сплануйте тест навантаження таким чином, щоб ви охопили широкий спектр робочих процесів, таких як легке використання, середнє використання та пікові навантаження.
• Вам потрібно виконати багато циклів тесту навантаження, тому спробуйте створити фреймворк, щоб ви могли використовувати ті самі сценарії знову і знову. Крім того, спробуйте створити резервну копію сценаріїв.
• Спробуйте проаналізувати, скільки часу повинен проходити тест, це одна година? 8 годин? День чи тиждень? Зазвичай довготривалі тести виявляють багато основних дефектів, таких як помилки ОС, витоки пам'яті тощо.
• Якщо ваша організація використовує будь-який APM (Засіб моніторингу програм), тоді ви можете включити його під час тестових запусків, щоб можна було легко виявити проблеми з продуктивністю та легше виявити першопричину.

# 2) Розвиток

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

# 3) Виконання

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

# 4) Аналіз

• Спробуйте проаналізувати додаток, додавши спочатку кілька важливих лічильників, коли виявиться вузьке місце, потім спробуйте додати додаткові лічильники щодо вузького місця. Це, у свою чергу, допоможе легше знайти проблему.
• Додаток може вийти з ладу з багатьох причин, наприклад, не відповісти на запит, відповісти кодом помилки, провалити логіку перевірки або відповісти занадто повільно. Тож спробуйте вивчити все це, перш ніж дійти висновку.

Висновок

Я впевнений, що цей посібник дав би вам величезні знання з тестів продуктивності та того, як написати документ із стратегією тестування ефективності з докладними прикладами.

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

Також перевірте => Безкоштовна серія поглиблених тренувань LoadRunner

НАСТУПНИЙ підручник

Рекомендована література

• Тестування продуктивності проти тестування навантаження проти стрес-тестування (різниця)
• Тестування навантаження за допомогою підручників HP LoadRunner
• Хмарне тестування продуктивності: постачальники послуг на основі хмарного тестування навантаження
• Тестування навантаження, напруги та продуктивності веб-додатків за допомогою WAPT
• Інструменти та послуги для перевірки ефективності веб-сайтів
• Як виконати ручне тестування продуктивності?
• Тестування продуктивності мобільних додатків за допомогою BlazeMeter
• Тестування продуктивності веб-служб за допомогою сценаріїв LoadRunner VuGen