Меню

Різниця між планом перевірки ефективності та стратегією перевірки ефективності

  • Головна
  • Інший
  • Різниця між планом перевірки ефективності та стратегією перевірки ефективності

difference between performance test plan

Спробуйте Наш Інструмент Для Усунення Проблем

У чому різниця між планом тестування ефективності та стратегією тестування?

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

=> Клацніть тут, щоб отримати повну серію навчальних посібників з тестування продуктивності

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

План тесту продуктивності проти стратегії тестування

Давайте зрозуміємо різницю між цими двома документами.

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

Стратегія перевірки ефективності

Документ 'Стратегія перевірки ефективності' - це документ високого рівня, який дає нам інформацію про те, як проводити тестування продуктивності на етапі тестування. Він розповідає нам, як перевірити вимоги бізнесу та який підхід необхідний для успішної доставки продукту кінцевому клієнту.

Це матиме всю інформацію про бізнес-процес на дуже високому рівні.

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

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

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

Стратегія перевірки ефективності

Наведена діаграма пояснює, що документ Стратегії тестування продуктивності створюється під час або після етапу аналізу вимог проекту.

План перевірки ефективності

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

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

План перевірки ефективності

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

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

Давайте тепер подивимося, що все повинно бути включено в документ Стратегії перевірки ефективності:

#1. Вступ: Дайте короткий огляд того, що буде містити документ Стратегії перевірки ефективності для цього конкретного проекту. Також згадайте команди, які використовуватимуть цей документ.

c та c ++ різниця

# 2) Сфера застосування: Визначення обсягу дуже важливо, оскільки воно говорить нам, що саме буде перевірено на ефективність. Нам потрібно бути дуже конкретними, визначаючи сферу дії або будь-який інший розділ.

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

# 3) Тест Підхід: Тут ми повинні згадати про підхід, який ми збираємось застосовувати для наших тестів продуктивності, оскільки кожен скрипт буде виконуватися одним користувачем для створення базової лінії, а потім ці базові тести будуть використані як посилання для Бенчмаркінгу пізніше час під час виконання тестів.

Крім того, кожен компонент буде протестовано окремо перед тим, як інтегрувати їх разом тощо.

# 4) Тест Типи: Тут ми згадуємо різні типи тестів, які потрібно охопити, такі як навантажувальний тест, стрес-тест, витривалість, об’ємний тест тощо.

# 5) Тест Результати: Згадайте, які всі результати будуть надані як частина тестування продуктивності для проекту, як звіт про пробіг, звітний звіт тощо.

# 6) Навколишнє середовище: Тут потрібно згадати деталі навколишнього середовища. Деталі навколишнього середовища дуже важливі, оскільки вони описують, які операційні системи будуть використовуватися для тестування продуктивності.

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

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

# 7) Інструменти: Тут ми повинні згадати всі Інструменти, які будуть використовуватися як інструменти відстеження дефектів, Інструменти управління , Інструменти тестування продуктивності та моніторингу. Дещо Приклади інструментів для відстеження дефектів JIRA , Для управління такими документами, як Confluence, для тестування продуктивності Jmeter і для моніторингу Нагіос .

# 8) Ресурси: Детальна інформація про ресурси, необхідні для команди з перевірки ефективності, задокументована в цьому розділі. Наприклад , Менеджер ефективності, керівник тесту продуктивності, тестери продуктивності тощо.

# 9) Запис & Вихід Критерії: Критерії входу та виходу будуть описані в цьому розділі.

Наприклад,

Критерії вступу - Програма повинна бути функціонально стабільною перед розгортанням збірки для тестування продуктивності.

Критерії виходу - Усі основні дефекти закриті, а більшість SLA досягнуто.

# 10) Ризики та пом'якшення: Будь-які ризики, які вплинуть на тестування продуктивності, повинні бути перелічені тут разом із планом пом'якшення наслідків для них. Це допоможе будь-яким ризикам, які можуть виникнути під час тестування продуктивності, або, принаймні, обхідне рішення щодо ризику планується заздалегідь. Це допоможе вчасно заповнити графіки тестування продуктивності, не впливаючи на результати.

# 11) Скорочення: Використовується для скорочень. Наприклад, PT - Тест продуктивності.

# 12) Історія документів: Тут міститься версія документа.

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

Давайте подивимось, що все повинно бути включено в документ плану тестування:

#1. Вступ: Це все те саме, що зазначено в документі Стратегії тестування ефективності, швидше ми просто згадуємо План тестування ефективності замість Стратегії тестування ефективності.

# 2) Завдання: Яка мета цього тестування продуктивності, чого досягається проведенням тестування продуктивності, тобто які переваги проведення тестування продуктивності слід чітко зазначити тут.

# 3) Сфера дії : Тут визначено обсяг тестування продуктивності як за обсягом, так і за межами обсягу бізнес-процесу.

# 4) Підхід: Тут описаний загальний підхід, як проводиться тестування продуктивності? Які передумови для створення навколишнього середовища? тощо включені.

# 5) Архітектура: Тут слід зазначити деталі архітектури додатків, як загальну кількість серверів додатків, веб-сервери, сервери БД, брандмауери, 3рдd сторонні додатки машини генераторів навантаження тощо

# 6) Залежності: Тут слід зазначити всі дії попереднього тестування, як-от компоненти, що підлягають тестуванню, функціонально стабільні, середовище масштабоване до виробничого типу, доступне чи ні, дата тесту доступна чи ні, інструменти тестування продуктивності доступні з ліцензіями якщо такі є тощо.

# 7) Навколишнє середовище: Потрібно згадати всі деталі системи, такі як IP-адреса, кількість серверів і т. Д. Слід також чітко зазначити, як слід налаштовувати Середовище, як передумови, будь-які виправлення та оновлення тощо.

# 8) Сценарії випробувань: Перелік сценаріїв для тестування згадано в цьому розділі.

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

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

# 10) Цикли виконання продуктивності: Детальна інформація про кількість тестових запусків буде описана в цьому розділі. Наприклад, Тест базової лінії, цикл 1 50 тест користувача тощо.

# 11) Метрики тесту продуктивності: Деталі зібраних показників будуть описані тут, ці показники мають бути в критерії приймання з узгодженими вимогами щодо продуктивності.

# 12) Результати тесту: Згадайте результати, а також включіть посилання на документи, де це можливо.

# 13) Управління дефектами: Тут ми повинні згадати, як обробляються дефекти, рівні тяжкості та рівні пріоритету також слід описати.

# 14) Управління ризиками: Згадайте про ризики, пов'язані з планом пом'якшення наслідків, наприклад, якщо програма не стабільна і якщо функціональні дефекти високого пріоритету все ще залишаються відкритими, чи вплине це на графік запуску тестів продуктивності, і, як вже було сказано раніше, це допоможе будь-яким ризикам, що виникають під час тестування продуктивності принаймні обхідний шлях для ризику буде спланований заздалегідь.

# 15) Ресурси: Згадайте деталі команди, а також їх ролі та обов'язки.

# 16) Історія версій: Веде відстеження історії документа.

# 17) Огляди та схвалення документів: Тут є список людей, які переглянуть та затвердять остаточний документ.

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

Поради щодо розробки цих документів

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

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

Висновок

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

перетворити char на int c ++

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

=> Завітайте сюди, щоб отримати повну серію навчальних посібників з тестування продуктивності

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

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

^