complete performance testing guide with examples
Какво е тестване на производителността?
Тестването на производителността също е известно като „Тестване на ефективността“ е вид тестване, което се провежда, за да се провери как приложението или софтуерът се изпълняват при натоварване по отношение на отзивчивост и стабилност. Целта на теста за ефективност е да се идентифицират и премахнат тесните места за изпълнение от приложението.
Този тест се извършва главно, за да се провери дали софтуерът отговаря на очакваните изисквания за скорост, мащабируемост и стабилност на приложението.
как да тествате клиентско сървърно приложение
В тази поредица от уроци ще разгледаме пълни подробности като - Perf Testing Types, Process и Writing Performance Test Strategy документ от нулата.
Това е подробна серия уроци, която може да искате да отбележите!
Нека да изследваме!
Списък на ВСИЧКИ уроци за тестване на производителността в тази серия:
Урок # 1: Пълно ръководство за тестване на производителността (Този урок)
Урок # 2: Разлика между тестване на производителност, натоварване и стрес
Урок № 3: Функционално тестване срещу тестване на производителността
Урок № 4: План за тестване на ефективността и тестова стратегия
Урок № 5: Начини за презареждане на вашето тестване на производителността
Урок № 6: Ръководство за тестване на производителността в облака
Урок # 7: Ръководство за тестване на производителността на мобилното приложение
Урок № 8: Как да извършите ръчно тестване на производителността
Урок № 9: Урок за тестване на ефективността на уебсайта
Урок № 10: Компании за тестване на производителността
Урок # 11: Тестване на производителността с LoadRunner (Серия)
Инструменти:
Урок # 12: Инструменти за тестване на най-добри резултати
Урок № 13: Урок за тест за изпълнение на Neoload
Урок # 14: Урок за BlazeMeter Mobile Performance Test
Урок # 15: Урок за тестване на натоварване, стрес и производителност на WAPT
Урок # 16: Урок за тестване на ефективността на уебсайта на SmartMeter.io
Какво ще научите:
- Видове тестване на производителността
- Процес на тестване на производителността
- Как да напиша документ за стратегия за тестване на ефективността?
- Примерен шаблон за стратегия за тестване на ефективността
- #1. Въведение
- # 2) Обхват
- # 3) Подход
- # 4) Тестови данни
- # 5) Критерии за влизане и излизане
- # 6) Управление на дефекти
- # 7) Инструменти и техники за тестване
- # 8) Критерии за спиране и възобновяване
- # 9) Тестови резултати
- # 10) Роли и отговорности
- # 11) Потенциални рискове и план за смекчаване
- # 12) Предположения
- # 13) Зависимости
- # 14) Съкращения
- Най-добри практики за реалистично тестване на ефективността
Видове тестване на производителността
Тестване на товара
Тестване на натоварването е вид тест за ефективност, при който приложението се тества за ефективността си при нормална и пикова употреба. Ефективността на дадено приложение се проверява по отношение на неговия отговор на потребителската заявка и способността му да реагира последователно в рамките на допустимото отклонение при различни потребителски товари.
Основните съображения са:
- Какво е максималното натоварване, което приложението може да задържи, преди приложението да започне да се държи неочаквано?
- С колко данни базата данни може да се справи, преди системата да се забави или да се наблюдава срив?
- Има ли проблеми, свързани с мрежата, които трябва да бъдат разгледани?
Стресиране
Тестът за стрес се използва за намиране на начини за разбиване на системата. Тестът също така осигурява обхвата на максимално натоварване, което системата може да побере.
Като цяло, стрес тестването има инкрементален подход, при който натоварването се увеличава постепенно. Тестът започва с товар, за който приложението вече е тествано. След това бавно се добавя повече натоварване, за да се натовари системата. Точката, в която започваме да виждаме сървъри, които не отговарят на заявките, се счита за точка на прекъсване.
Трябва да бъдат разгледани следните въпроси:
- Какво е максималното натоварване, което системата може да издържи, преди да се повреди?
- Как се разбива системата?
- Може ли системата да се възстанови, след като се срине?
- По колко начина системата може да се счупи и кои са слабите възли, докато се справят с неочакваното натоварване?
Тестване на обема
Обемното тестване е да се провери дали производителността на приложението не се влияе от обема данни, които се обработват от приложението. За да се извърши тест за обем, в базата данни се въвежда огромен обем данни. Този тест може да бъде допълнителен или постоянен тест. При допълнителния тест обемът на данните се увеличава постепенно.
Като цяло, с използването на приложението, размерът на базата данни нараства и е необходимо да тествате приложението срещу тежка база данни. Добър пример за това може да бъде уебсайт на ново училище или колеж с малки количества данни, които първоначално да се съхраняват, но след 5-10 години съхранението на данните в базата данни на уебсайта е много повече.
Тестване на капацитета
=> Способно ли е приложението да отговаря на обема на бизнеса както при нормално, така и при пиково натоварване?
Изпитването на капацитет обикновено се прави за бъдещи перспективи. Изпитването на капацитет се занимава със следното:
- Ще може ли приложението да поддържа бъдещото натоварване?
- Способна ли е средата да устои на предстоящото увеличено натоварване?
- Какви са допълнителните ресурси, необходими, за да се направи средата достатъчно способна?
Тестването на капацитет се използва, за да се определи колко потребители и / или транзакции дадено уеб приложение ще поддържа и пак ще отговаря на производителността. По време на това тестване се разглеждат и променят ресурси като капацитет на процесора, честотна лента на мрежата, използване на паметта, капацитет на диска и др., За да се постигне целта.
Онлайн банкирането е идеален пример за това къде тестването на капацитет би могло да играе важна роля.
Надеждност / възстановяване Тестване
Тестване на надеждността или тестване за възстановяване - е да се провери дали приложението е в състояние да се върне в нормалното си състояние след отказ или ненормално поведение и колко време е необходимо, за да го направи (с други думи, оценка на времето).
Ако сайт за онлайн търговия претърпи неуспех, при който потребителите не могат да купуват / продават акции в определен момент от деня (пикови часове), но са в състояние да го направят след час или два, можем да кажем, че приложението е надеждно или се възстанови от ненормалното поведение.
Процес на тестване на производителността
Ето всички дейности, извършени при това тестване:
# 1) Анализ на изискванията / Събиране
Екипът за изпълнение взаимодейства с клиента за идентифициране и събиране на изисквания - технически и бизнес. Това включва получаване на информация за използваната архитектура, технологии и база данни, предназначени потребители, функционалност, използване на приложението, изискване за изпитване , хардуерни и софтуерни изисквания и др.
# 2) POC / Избор на инструмент
След като ключовата функционалност бъде идентифицирана, POC (Proof Of Concept - нещо като демонстрация на активността в реално време, но в ограничен смисъл) се извършва с наличните инструменти.
qa въпроси и отговори за интервю за работа
Списъкът с наличните инструменти зависи от цената на инструмента, протокола, който приложението използва, технологиите, използвани за изграждане на приложението, броя потребители, които симулираме за теста и др. По време на POC се създават скриптове за идентифицирания ключ функционалност и изпълнена с 10-15 виртуални потребители.
# 3) План и дизайн на теста за ефективност
В зависимост от информацията, събрана в предходните етапи, се извършва планиране и проектиране на тестове.
Планирането на теста включва информация за това как ще се проведе тестът за работа - тестова среда, работно натоварване, хардуер и т.н.
Повече за документа за тестовата стратегия по-долу.
# 4) Разработване на тестове за ефективност
- Създават се случаи на употреба за функционалността, посочена в плана за тестване като обхват на PT.
- Тези случаи на употреба се споделят с клиента за тяхното одобрение. Това е, за да сте сигурни, че скриптът ще бъде записан с правилните стъпки.
- След като бъде одобрено, разработването на скриптове започва със запис на стъпките в случаи на употреба с инструмента за тестване на производителността, избран по време на POC (Proof of Concepts) и подобрен чрез извършване на Correlation (за обработка на динамична стойност), Parameterization (заместване на стойност) и потребителски функции като според ситуацията или нуждата. Повече за тези техники в нашите видео уроци.
- След това скриптовете се валидират срещу различни потребители.
- Успоредно със създаването на скриптове, екипът за изпълнение също продължава да работи по настройката на тестовата среда (Софтуер и хардуер).
- Екипът за изпълнение също ще се погрижи за метаданни (back-end) чрез скриптове, ако тази дейност не бъде поета от клиента.
# 5) Моделиране на тестове за ефективност
За изпълнение на теста е създаден Performance Load Model. Основната цел на тази стъпка е да провери дали дадените показатели за ефективност (предоставени от клиенти) са постигнати по време на теста или не. Има различни подходи за създаване на модел на натоварване. „ Little’s Law ”Се използва в повечето случаи.
# 6) Изпълнение на теста
Сценарият е проектиран в съответствие с модела за зареждане в контролер или център за ефективност, но първоначалните тестове не се изпълняват с максимален брой потребители, които са в модела за зареждане.
Изпълнението на теста се извършва постепенно. Например, Ако максималният брой потребители е 100, сценариите първо се изпълняват с 10, 25, 50 потребители и така нататък, като в крайна сметка преминават към 100 потребители.
# 7) Анализ на резултатите от теста
Резултатите от тестовете са най-важният резултат за тестването на производителността. Тук можем да докажем възвръщаемостта на инвестициите (ROI) и производителността, които усилията за тестване на производителността могат да осигурят.
Някои от най-добрите практики, които помагат на процеса на анализ на резултатите:
- Уникално и смислено име за всеки резултат от теста - това помага за разбирането на целта на теста.
- Включете следната информация в резюмето на резултатите от теста:
- Причина за неуспеха / ите
- Промяна в производителността на приложението в сравнение с предишното тестване
- Промени, направени в теста от гледна точка на компилация или среда на тестване.
- Добра практика е да правите обобщение на резултатите след всяко тестване, така че резултатите от анализа да не се компилират всеки път, когато се отнасят резултатите от теста.
- PT обикновено изисква много тестови писти, за да стигне до правилното заключение.
- Добре е да имате следните точки в обобщението на резултатите:
- Цел на теста
- Брой виртуални потребители
- Обобщение на сценария
- Продължителност на теста
- Пропускателна способност
- Графики
- Сравнение на графики
- Време за реакция
- Възникна грешка
- Препоръки
# 8) Доклад
Резултатите от тестовете трябва да бъдат опростени, така че заключението да е по-ясно и да не се нуждае от извеждане. Екипът за разработки се нуждае от повече информация за анализ, сравнение на резултатите и подробности за това как са получени резултатите.
Протоколът от изпитването се счита за добър, ако е кратък, описателен и точен.
Как да напиша документ за стратегия за тестване на ефективността?
Този урок ще обясни как да напишете примерна стратегия за тестване на производителността за приложение за съобщения.
Не забравяйте, че това е само пример и изискванията ще се различават при различните клиенти, ние също ще се запознаем с най-добрите практики за тестване на производителността в този урок.
Примерен шаблон за стратегия за тестване на ефективността
Всичко за приложението за чат ABC - Да приемем, че това е работна среда за чат, която се използва в компания от техния агент за поддръжка на клиенти, това приложение за чат използва протокол XMPP, т.е., протокол за разширяващи се съобщения и присъствие и сървър Open fire за изпращане и получаване на незабавни съобщения.
В този съществуващ клиент за чат са направени някои подобрения като дистанционно управление на компютър, диагностика на компютър, инструменти за ремонт, онлайн чат и т.н., така че тази стратегия за тестване на производителността е пример за такива приложения.
За това приложение нека приемем, че екипът на проекта е решил да използва JMeter за тестване на производителността и JIRA за проследяване на дефекти.
Първата страница на документа за стратегия за тестване на ефективността трябва да съдържа заглавие на документа и авторски права на компанията.
Втората страница трябва да съдържа Контрол на документи, който включва, История на версията на документа, Списък на рецензенти и одобряващи и Списък на сътрудници.
Третата страница трябва да съдържа съдържанието, последвано от долупосочените теми.
#1. Въведение
Целта на този документ е да дефинира / обясни как ще се извършва тестване на производителността на приложението за чат ABC за текущото и бъдещото състояние.
Приложението за чат ABC е вътрешна работна маса на агент за отдалечена поддръжка. Тази работна маса ще се използва за изпълнение на заявки на клиенти. Този Workbench има възможности като онлайн чат, идентификация на клиенти, дистанционно управление на компютър, диагностика на компютър и инструменти за ремонт.
Обективен
Основните цели на тестването са следните:
- За да придобиете увереност, че промените в съществуващото приложение за чат са в съответствие с определеното споразумение за ниво на услугата.
- За да се гарантира, че производителността на приложението, наличността на услугата и стабилността на приложението няма да бъдат засегнати в резултат на новите подобрения.
- Времената за реакция на транзакциите остават в рамките на допустимия толеранс спрямо нарастващия профил на натоварване.
- JVM показват стабилно използване на паметта при нарастващите профили на натоварване.
Долната снимка ясно обяснява процеса на тестване и оптимизиране на производителността:
Архитектура
Трябва да включите архитектурната схема на вашия проект в тази сесия.
# 2) Обхват
В обхвата
По-долу е обхватът на тестване на производителността за ABC чат:
- Придобиване на знания за ключовите бизнес транзакции и изграждане на разпределение на натоварването след подробно проучване на системата.
- Идентифицирайте критичните сценарии за тестване на производителността с помощта на различни писти на проекта.
- Използвайте резултатите от предишната версия като базова линия за бъдещи версии.
- Проверете и потвърдете средата за тестване на производителността и инфраструктурата на инструмента за тестване на производителността / натоварването за всички допълнителни Agent Machines.
- Подготовка на скриптове за тестване на производителността с помощта на JMeter за идентифицираните сценарии, които имитират идентифицираното пиково натоварване.
- Настройте мониторинг на производителността на сървърите за наблюдение на теста, за да идентифицирате тесните места по време на фазата на изпълнение на теста.
- Публикувайте резултатите от теста за ефективност.
- Координирайте се с различни заинтересовани страни за разрешаване на идентифицираните проблеми с изпълнението.
- Базово ниво на производителност за бъдещи версии.
Извън обхвата
- Функционално тестване , UAT, Тестване на системата и Тестване на сигурността.
- Тестване на производителността / мониторинг на интерфейси на трети страни.
- Настройка на производителността. (Повечето пъти настройката се извършва от различен екип, ако в случай че имате инженери за изпълнение, които да настройват системата, можете да добавите това в Inscope).
- Профилиране на код / Оразмеряване на хардуер / Планиране на капацитет.
- Сигурност / Тестване на уязвимост / UAT / Тестване на бяла кутия .
- Генериране на данни за тестване на производителността.
- Нефункционални тестове ( Например, отказоустойчивост, аварийно възстановяване, архивиране, използваемост), различни от тестовете за производителност.
- Тестване на всяко мобилно решение.
- Тестване и настройка на производителността на приложения на трети страни.
- Осъществяването на препоръки за ефективност, промени в кода на приложението и промени в продуктите / конфигурацията на сървъра, поддържани от доставчика, ще бъдат извън обхвата от гледна точка на екипа за изпълнение.
- Поддръжка на инфраструктурата / Внедряване на изграждане / Готовност за околна среда / Възстановяване на база данни / Поддръжка на мрежа и др.
# 3) Подход
Тестването на производителността за ABC чат ще се проведе с помощта на Jmeter чрез писане на потребителски приставки XMPP, които използват smack библиотека за XMPP връзки. Тези библиотеки се използват за настройка на връзки, влизане и изпращане на чат съобщения до XMPP сървъра.
Тези библиотеки са пакетирани в jar файл, който е разположен в Jmeter и е проектиран въз основа на сценариите, които ще бъдат тествани. Jmeter Work Bench е инсталиран в локалната машина, която се свързва със сървъра JMeter, който има генератори на натоварване, за да генерира необходимото натоварване в системата на сървъра за чат, за да следи поведението на системата.
най-добрият софтуер за възстановяване на данни windows 10
Тестовият сценарий ще бъде написан с помощта на инструмента JMeter. Сценариите ще бъдат персонализирани според изискванията. Графикът ще бъде създаден с необходимото нарастване, за да се симулират сценариите от реалния свят.
Тестовият сценарий ще бъде разделен и измерен в следните аспекти:
а) Изходен тест: За да стартирате всеки сценарий с 1 Vuser и множество итерации, за да идентифицирате дали изпълнението на приложението отговаря на споразумението за ниво на бизнес услуга или не.
б) Тест за основно натоварване: За да отговори на Business Benchmark при тест за натоварване, екипът за тестване на производителността ще извърши тест за базово натоварване, който ще помогне да се идентифицират всички проблеми с производителността на системата с нарастващо натоварване и създава базовата линия за следващото ниво на тестване на производителността.
в) Тест за максимално натоварване / мащабируемост: Екипът за тестване на производителността ще извърши множество тестове с нарастващи Vusers, за да отговори на очакваното натоварване, а също и да измери производителността на приложението, за да установи кривата на производителността и да идентифицира дали внедряването може да поддържа споразумения за ниво на услугата при пиково натоварване на потребителя.
Той помага за настройка или планиране на капацитета на отделните Java виртуални машини (JVM), общия брой необходими JVM и процесорите. Това ще бъде постигнато чрез увеличаване на броя на Vusers до 50%, 75%, 100% и 125% от върховия капацитет.
д) Тест за издръжливост: Екипът за тестване на производителността ще провежда този тест за период от 8 часа / 16 часа / 24 часа, за да идентифицира изтичане на памет, проблеми с производителността във времето и цялостна стабилност на системата. По време на тестовете за издръжливост екипът за тестване на производителността следи ключовите показатели за ефективност, като времената за реакция на транзакциите и стабилността на използването на паметта.
Системните ресурси като CPU, памет и IO трябва да бъдат наблюдавани с помощта на екипа на проекта.
Предполага се, че средата за тестване на производителността е копие на производствената среда. Тестовете ще се изпълняват с допълнително натоварване, за да се идентифицира къде приложението се провали.
Сценарии за тестване на производителността
Включете Excel с набора от сценарии.
Например,
Сценарий 1: За да проверите чата на агента и клиента за X не. на едновременни сесии.
Видове тестове за ефективност
Таблицата, дадена по-долу, обяснява различните видове тестове за ефективност заедно с техните цели.
Тип тест | Обективен |
---|---|
UAT | Тест за приемане от потребителя |
Изходен тест | Установете най-доброто представяне при определени обеми, които ще се използват като еталон за последващи измервания. |
Тест за натоварване | Измерете производителността на системата при очакваното пиково производствено натоварване. |
Тест за издръжливост | Измерване на стабилността на системата при голям обем за продължителен период. |
Стрес тест | Измерете производителността на системата при неблагоприятни условия. |
Показатели за ефективност
- Клиентски показатели
S.No | Метрична | Описание | Формат |
---|---|---|---|
1 | Време за реакция на транзакцията | Време за реакция на страниците по време на стабилно състояние на теста за производителност | Графика |
две | Пропускателна способност | Количеството данни, получени от потребителите от сървъра с течение на времето | Графика |
3 | Хитове / секунда | Броят на HTTP заявките, направени от VUsers към уеб сървъра по време на изпълнение на сценария | Графика |
4 | Брой преминати / неуспешни транзакции | Общ брой транзакции, преминали и неуспешни по време на изпълнението на теста | Excel |
5 | Честота на грешки в транзакциите | Процентът на транзакциите, които са неуспешни по време на изпълнението на теста | Графика |
- Показатели за ефективността на системата и мрежата
Дейности и резултати от тестване на ефективността
# 4) Тестови данни
Предполага се, че данните за работната среда ще бъдат копие на производствените данни и необходимите данни от теста ще бъдат предоставени от екипа на проекта.
# 5) Критерии за влизане и излизане
- Достъп до всички приложения в околната среда.
- Готовността за околната среда е завършена.
- Готовност на данните от теста за ефективност.
# 6) Управление на дефекти
- Модулът за управление на дефекти в JIRA ще се използва в проекта за регистриране на дефекти и за проследяване до затваряне.
- Идентифицирането на дефекти, открити по време на фазата на изпълнение на теста, ще бъде уловено в JIRA и тези дефекти ще бъдат отстранени от екипа на разработчиците в съответствие със сериозността по-долу.
- Ежедневно ще се провеждат срещи за преглед на дефекти с участието на екипи за тестване, разработка, анализ на качеството и бизнес екипи.
- Критериите за отстраняване на дефекти ще станат строги, когато проектът наближи датата на стартиране. Насоки за критерии за отстраняване на дефекти, които да бъдат публикувани на срещи за преглед на дефекти.
Определение на тежестта на дефекта
Определенията на кодовете за тежест са както следва:
Тежест | Описание на проблемите с развитието и подобрението |
---|---|
Блокиране | Системна грешка, показване на ограничител, проблеми с мрежата |
Критично | Системни грешки, без ясно решение, прекъсване или липсваща бизнес функционалност |
Майор | Открит е сериозен проблем, за който съществува решението, което може да не е ясно на всички потребители, но продуктът не трябва да се пуска без поправка |
Среден | Съществува проблем с лесна / проста работа, но този тип дефекти могат да бъдат отстранени след одобрение от бизнес и / или ръководител на проекти |
Ниска | Козметични проблеми, които не пречат на бизнес функционалността или други периодични проблеми, които не се възпроизвеждат всеки път |
# 7) Инструменти и техники за тестване
Инструменти | Предназначение |
---|---|
Jmeter | За да проверите натоварването и производителността на приложението ABC Chat. |
# 8) Критерии за спиране и възобновяване
По-долу са дадени критериите за критично спиране и възобновяване, които ще повлияят на тестовите дейности:
Окачване | Въздействие | Възобновяване |
---|---|---|
Околната среда не е настроена | Тестването не може да продължи | Готовност за околната среда. |
Установено е, че приложението е нестабилно | Тестването не може да продължи. | Проблемът е решен |
Данните от теста не са налични | Тестването не може да продължи. | Данните за теста са готови |
# 9) Тестови резултати
Резултатите от теста за производителност включват:
- Стратегия за тестване на ефективността
- Документ за изисквания за изпълнение
- Документ за сценарий на тест за ефективност
- Сценарии за тест за изпълнение
- Резултати от теста за ефективност
# 10) Роли и отговорности
Ролите и отговорностите са ясно обяснени в таблицата, дадена по-долу.
# 11) Потенциални рискове и план за смекчаване
S.No | Риск | Вероятност | Въздействие | План за смекчаване | Собственик |
---|---|---|---|---|---|
1 | Недостъпност на тестови данни за изпълнение на теста за натоварване на изпълнението | З. | З. | Очакваните дати за изпълнение на теста за изпълнение трябва да бъдат прегледани и актуализирани. За събиране на данни се изисква функционална / екипна поддръжка. | - |
две | Проблемите на околната среда | L | М | Повторно приоритизирайте резултатите | - |
3 | Промяна във функционалността / дизайна по време на изпълнение на теста за изпълнение | М | З. | Това изисква преработка на сценариите за тестване на производителността | - |
4 | Допълнителна производителност работи за отстраняване на проблеми с производителността | М | З. | Графиците за тестване на производителността ще бъдат модифицирани и актуализирани до продуктовия екип. | - |
5 | Оценките се изготвят въз основа на 1 корекция на грешки за изпълнение. Множеството компилации на корекции на грешки ще забавят тестовите цикли и в крайна сметка това зависи от това кога следващата компилация ще бъде достъпна за повторно изпълнение. | З. | З. | Приоритизирайте циклите за изпълнение на теста за изпълнение. | - |
6 | Наличност на хардуер | М | З. | Началната дата на графика ще бъде съответно преместена. | - |
# 12) Предположения
- Тестовата среда за изпълнение ще бъде копие на архитектурата на продукта. (т.е. правилен хардуер, софтуер, интерфейси, интеграционни слоеве и т.н.).
- Скриптовете за изпълнение ще бъдат проектирани въз основа на критичните потоци, за които употребата е висока.
- Всички проблеми с инфраструктурата трябва да бъдат разрешени преди началото на тестването на производителността. Всички промени в конфигурацията на системата, направени по-късно, ще обезсилят резултатите от теста.
- Приложението е стабилно и готово за използване в среда за тестване на производителността.
- Предлагат се необходимите хардуерни и софтуерни ресурси (като машини / софтуер за генератори на натоварване, машини за контрол / агент).
- Всички промени в обхвата ще преминат през процес на контрол на промените и екипът за тестване на производителността ще оцени въздействието на сроковете и ресурсите.
- Очаква се съответните сървъри да се справят с товара.
- За целите на наблюдението трябва да се активират регистрационните файлове за проследяване на поддържащите системи.
# 13) Зависимости
- Наличие на среда за тестване на производителността, която е копие на пейзажа на архитектурата на продукта.
- По време на етапите на подготовка и изпълнение на теста се изисква поддръжка от различни екипи за функционалност, разработка, база данни и инфраструктура.
- По време на цялата фаза на тестване на производителността не се прилагат промени в кода, тъй като времето е много ограничено.
- В случай на непредвидени проблеми, които водят до ограничения в рамките на сроковете, ако сроковете не позволяват всички тестови обхвати да бъдат изпълнени в рамките на първоначалните крайни дати, се предлага поддръжка от мениджърите на издания, за да се осигури решение за определяне на обхвата и приоритизиране.
- Приложните бизнес потребители / Експертите по предмет ще бъдат на разположение за функционални разяснения и изписване на бизнес транзакции.
- Мениджърът на програмата за чат на ABC ще прегледа и излезе.
# 14) Съкращения
Съкращение | Описание |
---|---|
DB | База данни |
Http | Протокол за прехвърляне на хипер текст |
JDBC | Свързване на база данни на Java |
QA | Осигуряване на качеството |
МАРУЛЯ | Споразумение за нивото на обслужване |
МСП | Експерт по предмета |
Досега трябва да сте разбрали ясно как да напишете ефективна стратегия за тестване на производителността за приложение за съобщения.
Най-добри практики за реалистично тестване на ефективността
За да завършим успешно проект за тест за ефективност, трябва да гарантираме, че го правим по правилния начин от етапа на планиране, т.е. планиране, разработване, изпълнение и анализ.
Нека разгледаме всеки етап в детайли, за да проведем ефективно тестване на ефективността.
# 1) Планиране
- Опитайте се да идентифицирате най-често срещаните работни процеси, т.е. бизнес сценариите, които трябва да бъдат тествани. Ако приложението е съществуващо, проверете регистрационните файлове на сървъра, за да разберете най-често използваните сценарии. Ако приложението е ново, говорете с екипа за управление на проекти, за да разберете основния бизнес поток.
- Планирайте теста за натоварване по такъв начин, че да обхващате широк спектър от работни потоци като използване на светлина, средно използване и пикови натоварвания.
- Трябва да извършите много цикли от теста за натоварване, така че се опитайте да създадете рамка, така че да можете да използвате едни и същи скриптове отново и отново. Също така, опитайте се да имате резервно копие на скриптовете.
- Опитайте се да анализирате колко време трябва да се изпълнява тест, един час ли е? 8 часа? Ден или седмица? Обикновено дългосрочните тестове ще разкрият много основни дефекти като грешки в ОС, изтичане на памет и т.н.
- Ако вашата организация използва какъвто и да е APM (Application Monitoring Tool), можете да го включите по време на тестовите пробези, за да можете лесно да идентифицирате проблемите с производителността и да идентифицирате по-лесно основната причина.
# 2) Развитие
- Докато разработвате скриптове, т.е. запис, опитайте се да дадете по-смислено име на транзакция въз основа на имената на бизнес потока, които са споменати в плана.
- Не записвайте приложения на трети страни и ако се запишат, опитайте се да го филтрирате, като същевременно подобрите скриптовете.
- Не всички динамични стойности могат да бъдат корелирани с помощта на функцията за автоматично корелация в инструмента, така че опитайте да направите ръчна корелация, за да избегнете грешки.
- Опитайте се да проектирате тестовете си за производителност по такъв начин, че да удряте бекенда на приложението, а не само кеш сървъра.
# 3) Изпълнение
- Уверете се, че сте изпълнили тестовете в производствена среда, включително фактори като SSL, Load Balancer и Firewall. Това е необходимо, за да се симулира реалистично натоварване на системата.
- Опитайте се да създадете работно натоварване, което е много реалистично, можете да го получите, като проверите регистрационните файлове на сървъра, ако това е съществуващо приложение и ако е ново приложение, трябва да получите тази информация от бизнес екипа. Не забравяйте, че натоварването е много важно за провеждането на успешни тестове за ефективност.
- Никога не стигайте до заключение, като провеждате тестове с половината от производствената среда, винаги се препоръчва да провеждате тестове в среда, която е точно същата като производствената.
- Докато изпълнявате дългосрочни тестове, опитайте се да наблюдавате изпълнението на чести интервали, за да сте сигурни, че тестът работи гладко.
# 4) Анализ
- Опитайте се да анализирате приложението, като първо добавите няколко важни брояча, когато се намери затруднение, след това опитайте да добавите допълнителни броячи по отношение на пречките. Това от своя страна ще помогне за по-лесното намиране на проблема.
- Приложението може да се провали по много причини, като може да не успее да отговори на заявка, да отговори с код за грешка, да провали вашата логика за проверка или да отговори твърде бавно. Затова се опитайте да разгледате всичко това, преди да стигнете до заключение.
Заключение
Сигурен съм, че този урок ще ви даде огромни познания за тестовете за ефективност и как да напишете документ за стратегия за тестване на ефективността с подробни примери.
В нашия предстоящ урок ще научим подробно разликите между тестване на производителност, натоварване и стрес.
Също така проверете => Безплатна серия за задълбочено обучение на LoadRunner
Препоръчително четене
- Тестване на ефективността срещу тестване на натоварване срещу тестване на стрес (разлика)
- Тестване на натоварване с уроци за HP LoadRunner
- Облачно тестване на производителността: Доставчици на услуги за тестване на натоварване в облак
- Тестване на натоварване, стрес и производителност на уеб приложения с помощта на WAPT
- Инструменти и услуги за тестване на ефективността на уебсайта
- Как да извършите ръчно тестване на производителността?
- Тестване на производителността на мобилните приложения с помощта на BlazeMeter
- Тестване на производителността на уеб услуги с помощта на LoadRunner VuGen Scripting