Пълно ръководство за тестване на зареждане за начинаещи

load testing complete guide

Пълно ръководство за тестване на натоварване за начинаещи:

В този урок ще научим защо извършваме тестване на натоварване, какво се постига от него, архитектура, какъв е подходът, който трябва да се следва, за да се изпълни успешно тест за натоварване, как да се създаде среда за тестване на натоварване, най-добрите практики, заедно с най-добрите инструменти за тестване на товара, налични на пазара.

Чували сме както за функционални, така и за нефункционални видове тестване. При нефункционалното тестване имаме различни видове тестове като тестване на производителността, тестване на сигурността, тестване на потребителския интерфейс и т.н.

Следователно тестването на натоварване е нефункционален тип тестване, което е подмножество на тестване на производителността.

По този начин, когато казваме, че тестваме приложение за ефективност, какво всички тестваме тук? Тестваме приложението за товар, обем, капацитет, стрес и т.н.

Какво ще научите:

• Какво е тестване на товара?
• Архитектура на тестовете за натоварване
• Защо тестване на товара?
• Заобикаляща среда
• Приближаване
• Най-добри практики
• Заключение
• Препоръчително четене

Какво е тестване на товара?

Load Testing е подмножество на Performance Testing, където тестваме реакцията на системата при различни условия на натоварване, като симулираме едновременния достъп на множество потребители до приложението. Това тестване обикновено измерва скоростта и капацитета на приложението.

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

Пример :Да приемем, че изискванията на нашите клиенти за страница за вход са 2-5 секунди и тези 2-5 секунди трябва да бъдат последователни през цялото време, докато зареждането е 5000 потребители. И така, какво трябва да наблюдаваме да чуем? Това ли е просто способността за работа с натоварването на системата или това е просто изискването за време за реакция?

Отговорът е и двете. Искаме системата, която може да се справи с товар от 5000 потребители с време за реакция 2-5 секунди за всички едновременни потребители.

И така, какво се разбира под едновременен потребител и виртуален потребител?

Едновременни потребители са тези, които влизат в приложението и в същото време изпълняват набор от дейности заедно и излизат от приложението едновременно. От друга страна, виртуалните потребители просто влизат и изскачат от системата, независимо от другите потребителски дейности.

Архитектура на тестовете за натоварване

На диаграмата по-долу можем да видим как различните потребители имат достъп до приложението. Тук всеки потребител прави заявка по интернет, която по-късно се предава през защитна стена.

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

Тестването на натоварването може да се извърши ръчно, както и с помощта на инструмент. Но ръчно тестване на натоварване не се препоръчва, тъй като не тестваме приложението за по-малко натоварване.

Пример: Да приемем, че искаме да тестваме приложение за онлайн пазаруване, за да видим времето за реакция на приложението за всеки клик на потребителя, т.е. Стъпка1 - URL за стартиране, времето за реакция, влизане в приложението и отбелязване на времето за реакция и т.н. продукт, добавяне в количката, извършване на плащане и излизане. Всичко това трябва да се направи за 10 потребители.

И така, сега, когато трябва да тестваме натоварването на приложението за 10 потребители, можем да постигнем това чрез ръчно натоварване от 10 физически потребители от различни машини, вместо да използваме инструмент. В този сценарий е препоръчително да отидете на тест за ръчно натоварване, вместо да инвестирате в инструмент и да създадете среда за инструмента.

Докато си представим, ако трябва да заредим тест за 1500 потребители, тогава трябва да автоматизираме теста за натоварване, използвайки някой от наличните инструменти, базиран на технологиите, в които е изградено приложението, а също и въз основа на бюджета, който имаме за проекта.

Ако имаме бюджет, тогава можем да се насочим към търговски инструменти като Load runner, но ако нямаме много бюджет, тогава можем да използваме инструменти с отворен код като JMeter и т.н.

разлика между b дърво и b дърво

Независимо дали става дума за търговски инструмент или инструмент с отворен код, подробностите трябва да бъдат споделени с клиента, преди да финализираме инструмента. Обикновено се изготвя доказателство за концепция, където ние генерираме примерен скрипт с помощта на инструмента и показваме примерните отчети на клиента за одобрение на инструмента, преди да го финализираме.

При автоматизирано тестване на натоварване ние заместваме потребителите с помощта на инструмент за автоматизация, който имитира действията на потребителя в реално време. Чрез автоматизиране на натоварването можем да спестим ресурси, както и времето.

По-долу е дадена диаграмата, която показва как потребителите се заменят с помощта на инструмент.

Защо тестване на товара?

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

Междувременно идва пиков ден, т.е. да кажем Деня на благодарността и има хиляди потребители, които са влезли в системата, системата изведнъж се срива и потребителите изпитват много бавен отговор, някои дори не могат влезте в сайта, няколко не успяха да добавят в количката, а някои не успяха да проверят.

Следователно в този голям ден компанията трябваше да се изправи пред огромна загуба, тъй като загуби много клиенти и много бизнес. Всичко това се е случило само защото те не са предвидили натоварването на потребителя за пиковите дни, дори ако биха предвидили, че на уебсайта на компанията не е направен тест за натоварване, следователно те не знаят с какъв товар ще може да се справи приложението в пиковите дни.

По този начин за справяне с подобни ситуации и за да се преодолеят огромни приходи, препоръчително е да се проведе тест за натоварване за такъв тип приложения.

• Тестването на товара помага за изграждането на здрави и надеждни системи.
• Тесното място в системата се идентифицира доста предварително, преди приложението да стартира активно.
• Помага при идентифицирането на капацитета на приложението.

Какво се постига по време на тест за натоварване?

С подходящ тест за натоварване можем да разберем точно следното:

1. Броят потребители, с които системата може да се справи или може да мащабира.
2. Времето за реакция на всяка транзакция.
3. Как се държи всеки компонент на цялата система при Load i.e компоненти на сървъра на приложения, компонентите на уеб сървъра, компонентите на базата данни и т.н.
4. Каква конфигурация на сървъра е най-подходяща за справяне с товара?
5. Дали съществуващият хардуер е достатъчен или има нужда от допълнителен хардуер.
6. Идентифицират се тесни места като използване на процесора, използване на паметта, закъснения в мрежата и т.н.

Заобикаляща среда

Имаме нужда от специална среда за тестване на натоварване, за да проведем нашите тестове. Тъй като през повечето време средата за тестване на натоварване ще бъде същата като производствената среда, а също така данните, налични в средата за тестване на натоварване, ще бъдат същите като производствената, въпреки че това не са същите данни.

Ще има множество тестови среди като SIT среда, QA среда и т.н., тези среди не са една и съща продукция, тъй като за разлика от тестването на натоварване, те не се нуждаят от толкова много сървъри или толкова много тестови данни за провеждане на функционално тестване или тестване за интеграция.

Пример:

В производствена среда имаме 3 сървъра за приложения, 2 уеб сървъра и 2 сървъра за бази данни. В QA имаме само 1 сървър за приложения, 1 уеб сървър и 1 сървър за бази данни. Следователно, ако провеждаме тест за натоварване на QA среда, който не е равен на производствения, тогава тестовете ни не са валидни и са също неправилни и по този начин не можем да се справим с тези резултати.

Затова винаги се опитвайте да имате специална среда за тестване на натоварване, която е подобна на тази на производствената среда.

Също така, понякога имаме приложения на трети страни, които нашата система ще извика, следователно в такива случаи можем да използваме заглушки, тъй като не винаги можем да работим с доставчици на трети страни за опресняване на данни или други проблеми или поддръжка.

Опитайте се да направите моментна снимка на средата, след като тя е готова, така че, когато искате да възстановите околната среда, можете да използвате тази снимка, която би помогнала за управлението на времето. Има някои инструменти, които се предлагат на пазара за създаване на среда като Puppet, Docker и др.

Приближаване

Преди да започнем теста за натоварване, трябва да разберем дали някакъв тест за натоварване вече е направен в системата или не. Ако е извършено някакво тестване на натоварване по-рано, тогава трябва да знаем какво е времето за реакция, събрани показатели за клиент и сървър, колко е капацитетът за натоварване на потребителя и т.н.

Също така се нуждаем от информация колко е текущата възможност за обработка на приложения. Ако е ново приложение, трябва да разберем изискванията, какъв е целевият товар, какво е очакваното време за реакция и дали наистина е постижимо или не.

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

След като имаме изискванията, трябва да определим как ще изпълним теста за натоварване. Прави ли се ръчно или с помощта на инструменти? Правенето на тест за натоварване ръчно се нуждае от много ресурси и също е много скъпо. Също така повтарянето на теста, отново и отново, също ще бъде трудно.

Следователно, за да преодолеем това, можем да използваме инструменти с отворен код или търговски инструменти. Инструментите с отворен код се предлагат безплатно, тези инструменти може да нямат всички функции като останалите търговски инструменти, но ако проектът има бюджетно ограничение, тогава можем да се насочим към инструменти с отворен код.

Докато търговските инструменти имат много функции, те поддържат много протоколи и са много лесни за употреба.

Нашият подход за тестване на натоварване ще бъде както следва:

# 1) Определете критериите за приемане на теста за натоварване

Например:

1. Времето за реакция на страницата за вход не трябва да бъде повече от 5 секунди дори при условията на максимално зареждане.
2. Използването на процесора не трябва да бъде повече от 80%.
3. Пропускателната способност на системата трябва да бъде 100 транзакции в секунда.

# 2) Определете бизнес сценариите, които трябва да бъдат тествани.

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

Ако това е новоизградено приложение, тогава трябва да работим с бизнес екипите, за да разберем моделите на потока, използването на приложения и др. Понякога екипът на проекта ще провежда работни срещи, за да даде общ преглед или подробности за всеки компонент на приложението.

Трябва да присъстваме на семинара по кандидатстване и да отбележим цялата необходима информация за провеждане на нашия тест за натоварване.

# 3) Моделиране на работното натоварване

След като имаме подробности за бизнес потоците, моделите за достъп на потребителите и броя на потребителите, трябва да проектираме работното натоварване по такъв начин, че да имитира действителната потребителска навигация в производството или както се очаква да бъде в бъдеще, след като приложението ще бъде в производство.

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

Моделът на работното натоварване обикновено е с Рампа нагоре, Рампа надолу и стабилно състояние. Трябва бавно да заредим системата и по този начин се използват рампа нагоре и надолу. Стационарното състояние обикновено е едночасов тест за натоварване с рампа до 15 минути и рама надолу от 15 минути.

Нека вземем пример за модела на натоварване:

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

За да видят подробностите за всеки продукт, те трябва да кликнат върху продукта. Ако им харесва цената и направата на продукта, те могат да добавят в количката и да купят продукта, като проверят и направят плащането.

Даден по-долу е списък със сценарии:

1. Преглед - Тук потребителят стартира приложението, влиза в приложението, разглежда различни категории и излиза от приложението.
2. Преглед, Изглед на продукта, Добавяне в кошницата - Тук потребителят влиза в приложението, разглежда различни категории, преглежда подробности за продукта, добавя продукта в количката и излиза.
3. Преглед, изглед на продукта, добавяне в кошницата и плащане - В този сценарий потребителят влиза в приложението, разглежда различни категории, преглежда подробности за продукта, добавя продукта в кошницата, проверява и излиза.
4. Преглед, Изглед на продукта, Добавяне в количката Плащане и извършване на плащане - Тук потребителят влиза в приложението, разглежда различни категории, преглежда подробности за продукта, добавя продукта в кошницата, проверява, извършва плащания и излиза.

Горните стойности бяха получени въз основа на следните изчисления:

• Транзакции на час = Брой потребители * Транзакции, извършени от един потребител за един час.
• Броят на потребителите = 1600.
• Общият брой транзакции в сценария за преглед = 17.
• Време за реакция за всяка транзакция = 3.
• Общо време за един потребител да извърши 17 транзакции = 17 * 3 = 51 закръглени до 60 секунди (1 минута).
• Транзакции на час = 1600 * 60 = 96000 транзакции.

# 4) Проектирайте тестовете за натоварване- Тестът за натоварване трябва да бъде проектиран с данните, които сме събрали досега, т.е. бизнес потоци, брой потребители, потребителски модели, показатели, които трябва да бъдат събрани и анализирани. Освен това тестовете трябва да бъдат проектирани по много реалистичен начин.

# 5) Изпълнете тест за натоварване - Преди да изпълним теста за зареждане, уверете се, че приложението работи и работи. Тестовата среда за зареждане е готова. Приложението е функционално тествано и е стабилно.

Проверете конфигурационните настройки на тестовата среда за зареждане. Тя трябва да бъде същата като производствената среда. Уверете се, че всички данни от теста са налични. Не забравяйте да добавите необходимите броячи, за да следите производителността на системата по време на изпълнението на теста.

Винаги започвайте с ниско натоварване и постепенно увеличавайте натоварването. Никога не започвайте с пълния товар и не разбивайте системата.

# 6) Анализирайте резултатите от теста за натоварване - Направете изходен тест, който винаги да сравнявате с останалите пробни тестове. Съберете метриките и регистрационните файлове на сървъра след тестовото изпълнение, за да намерите тесните места.

Някои проекти използват инструменти за мониторинг на ефективността на приложенията, за да наблюдават системата по време на тестовото изпълнение, тези инструменти на APM помагат за по-лесното идентифициране на основната причина и спестяват много време. Тези инструменти са много лесни за намиране на първопричината за пречките, тъй като имат широк поглед, за да определят къде е проблемът.

Някои от APM инструментите на пазара включват DynaTrace, Wily Introscope, App Dynamics и др.

# 7) Отчитане - След като приключи пробното изпълнение, съберете всички показатели и изпратете обобщения отчет на теста на съответния екип с вашите наблюдения и препоръки.

Най-добри практики

По-долу са изброени някои от най-добрите практики за тестване на товара:

# 1) Винаги проверявайте стабилността на приложението, преди да започнете тест за натоварване. Приложението трябва да бъде подписано функционално стабилно от екипа за функционално тестване и всички основни дефекти трябва да бъдат отстранени и тествани, преди компилацията да бъде копирана в средата за тестване на натоварване.

# две) Уверете се, че тестовата среда за зареждане е реплика или е близо до производствената среда, включително броя на сървърите, балансиращите товара, конфигурациите на сървъра и защитните стени.

# 3) Проверете дали тестовите данни са уникални и всички тестови данни са копирани в товарната среда, преди да проведете тестов товар.

# 4) Проектирайте тестовите сценарии по такъв начин, че да имитират действието на потребителя в реално време, случващо се в продукцията.

# 5) Проектирайте натоварването въз основа на производствените потребителски натоварвания и бизнес потоците, а в случай на старо приложение, вижте дали това е нов разговор с бизнес екипа относно бизнес потоците и потребителското натоварване.

# 6) Съберете всички важни показатели като време за реакция, посещения в секунда, пропускателна способност, процесор, памет, мрежа и работещи Vusers.

Препоръчително четене => Списък на инструментите за тестване на производителността, налични на пазара за провеждане на ексклузивно тестване на товара.

Заключение

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

Също така разбрахме как помага да се предскаже дали се изисква допълнителен хардуер, софтуер или настройка на дадено приложение.

Честито четене !!

Препоръчително четене

• Тестване на натоварване с уроци за HP LoadRunner
• Алфа тестване и бета тестване (Пълно ръководство)
• Ръководство за тестване на сигурността на уеб приложения
• Ръководство за стрес тестване за начинаещи
• Ръководство за начинаещи за тестване на проникване в уеб приложения
• Пълно ръководство за нефункционално тестване за начинаещи
• Пълно ръководство за тестване за проверка на компилация (BVT тестване)
• Тестване на ефективността срещу тестване на натоварване срещу тестване на стрес (разлика)