volume testing tutorial
Преглед на тестването на обема:
Картината по-долу съответства ли по някакъв начин на нашите приложения? Да, точно това се случва, когато претоварваме нашите сървъри, бази данни, уеб услуги и т.н.
Всички ние трябва да сме наясно с функционалното и нефункционалното тестване, но дали сте наясно с факта, че нефункционалното тестване е толкова важно, колкото и функционалното тестване? Понякога в краткотрайни версии сме склонни да игнорираме това нефункционално тестване, което в идеалния случай не би трябвало.
За нас няма значение дали собственикът на продукта е дал това изискване или не. Трябва да разгледаме това тестване като част от нашия пълен процес на тестване дори за малки версии.
Този урок за тестване на обем ви дава пълен преглед на неговото значение, нужда, важност, контролен списък и някои от неговите инструменти, за да ви позволи да го разберете по-добре.
Какво ще научите:
- Какво е тестване на обема?
- Кога е задължително това тестване?
- Защо трябва да се стремя към обемно тестване?
- Какъв е моят контролен списък за това тестване?
- Обемно тестване срещу тестване на натоварване
- Как да извършите това тестване?
- Инструменти за тестване на обем
- Заключение
- Препоръчително четене
Какво е тестване на обема?
Обемното тестване е вид нефункционално тестване. Това тестване се прави, за да се провери обемът на данните, обработвани от базата данни. Обемното тестване, наричано още тестване на наводнения, е нефункционално тестване, което се прави, за да се провери софтуерът или приложението за неговата ефективност спрямо огромни данни на базата данни.
Базата данни се разтяга до прагова точка чрез добавяне на голямо количество данни към нея и след това системата се тества за нейния отговор.
Това беше теоретичната част, позволете ми да ви обясня с няколко практически примера, които да ви помогнат да разберете 'кога' част от обемното тестване.
Кога е задължително това тестване?
В идеалния случай всеки софтуер или приложение трябва да бъде тестван за обем на данни, но в някои случаи, когато данните няма да са тежки, ние сме склонни да избягваме това тестване. Но в някои случаи, когато данните се обработват ежедневно в MB или GB, тогава определено трябва да се извърши тест за обем.
Следват няколко примера от моя собствен опит от 8 години, които обясняват частта „кога“:
Пример 1:
Едно от начинанията ми беше голяма система, която се състоеше както от уеб приложение, така и от мобилно приложение. Но самото уеб приложение имаше 3 модула, обработвани от 3 различни екипа.
Понякога дори при нас базата данни ставаше бавна, когато всички ‘заедно’ добавяхме данни за нашето тестване. Беше досадно и работата се затрудняваше поради огромния обем данни и за да улесним работата, трябваше да почистваме БД доста често.
Данните, които системата „на живо“ обработва, са около GB, поради което в сравнение с мобилното приложение уеб приложението е много често тествано за обема на данните. Екипите на QA за уеб приложения разполагат със собствени скриптове за автоматизация, които се изпълняват през нощта и извършват това тестване.
Пример 2:
Друг пример за моето начинание беше екосистема, която имаше не само уеб приложение, но и приложение на SharePoint и дори инсталатор. Всички тези системи комуникираха с една и съща база данни за прехвърляне на данни. Данните, обработвани от тази система, също бяха много големи и ако по някаква причина DB стане бавна, дори инсталаторът ще спре да работи.
Следователно, тестът за обем се правеше редовно и производителността на DB се наблюдаваше подробно за всякакви проблеми.
По същия начин, можем да вземемПримериот няколко приложения, които използваме ежедневно за пазаруване, резервиране на билети, финансови транзакции и т.н., които се занимават с тежки транзакции с данни и следователно се нуждаят от тест за обем.
От друга страна, не винаги може да се постигне идеално тестване на обема, тъй като има свои собствени ограничения и предизвикателства.
Малко от неговите ограничения и предизвикателства включват:
- Трудно е да се създаде точната фрагментация на паметта.
- Динамичното генериране на ключове е сложно.
- Създаването на идеална реална среда, т.е. репликата на сървъра на живо може да бъде сложно.
- Инструментите за автоматизация, мрежата и т.н. също влияят върху резултатите от теста.
Сега разбрахме кога трябва да направим този тип тестване. Нека също да разберем 'защо' ние трябва да направим това тестване, както в, целта или целта на извършването на това тестване.
Защо трябва да се стремя към обемно тестване?
Тестването на обема може да ви помогне да разберете доколко вашата система е подходяща за реалния свят, а също така помага да спестите парите си, които по-късно ще бъдат похарчени за целите на поддръжката.
Следват няколко възможни причини за извършване на това тестване:
- Най-основната необходимост е да се анализира производителността на вашата система спрямо увеличените данни. Създаването на огромен обем данни ще ви помогне да разберете ефективността на вашата система по отношение на времето за реакция, загубата на данни и т.н.
- Идентифицирайте проблемите, които ще възникнат при огромни данни и праговата точка.
- Отвъд устойчивата или праговата точка, поведението на системата, т.е.ако DB се срине, стане неотзивчива или изтече времето за изчакване.
- Внедряване на решения за претоварване на DB и дори тяхната проверка.
- Откриване на крайната точка на вашата DB (която не може да бъде поправена), след която системата ще се провали и по този начин трябва да се вземат предпазни мерки.
- В случай на повече от един DB сървъри, откриване на проблемите с DB комуникацията, т.е. най-склонните към отказ от тях и т.н.
Сега знаем значението и причината за извършване на това тестване.
ИЛИ Опитът, който бих искал да споделя тук, е, че по отношение на мобилните приложения може да не е необходимо тестване на обема, защото само един човек използва приложението наведнъж и мобилните приложения са проектирани да бъдат прости .
Така че, ако нямате много сложно приложение с много данни, тестването на обема може да бъде пропуснато.
След като разберете какво трябва да бъде проверено за вашата система или приложение, следващото нещо, което трябва да направите, е да направите контролен списък за приложението си, който да дефинирате 'Какво' трябва да се тества.
Какъв е моят контролен списък за това тестване?
Преди да влезем в някои примери за създаване на контролен списък за вашето приложение или система, нека първо разберем няколко указателя, които трябва да имате предвид, докато създавате контролен списък за обемно тестване или подход, преди да започнете тестването.
Точки, които трябва да се запомнят:
- Дръжте разработчиците в течение за вашия план за тестване, защото те знаят много за системата и могат да ви предоставят данни и дори затруднения.
- Разберете физическия аспект, както при конфигурациите на сървъра, RAM паметта, процесора и т.н., добре преди да създадете стратегия за тестване.
- Разберете сложността на DB, процедурите, DB скриптовете и т.н. до възможната степен, така че да можете да очертаете сложността на вашата система като цяло.
- Подгответе информатика, т.е. графики, лист с данни и т.н., ако е възможно за нормалния обем данни и колко добре е системата, това ще ви помогне да се уверите, че преди да натоварите DB, производителността е добра за нормално зареждане на данни. Това също ще ви помогне да се уверите, преди да преминете към стресиращата част, че няма проблеми, които да изискват корекция за вашия тест за обем.
Следват някои примери, които можете да добавите или използвате във вашия контролен списък:
- Проверете за коректността на методите за съхранение на данни.
- Проверете дали системата разполага с необходимите ресурси за памет или не.
- Проверете дали има риск обемът на данните да надвишава определената граница.
- Проверете и наблюдавайте реакцията на системата към обема на данните.
- Проверете дали данните се губят по време на тестване на обем.
- Проверете дали ако данните са презаписани, това се прави с предварителна информация.
- Идентифицирайте областите, които се простират извън нормалния диапазон като много атрибути (с възможност за търсене), огромен не. на справочни таблици, много картографиране на местоположение и т.н.
- Както споменахме по-рано, първо създайте базова линия, като получите резултати за нормалния обем и след това продължете със стреса.
Преди да преминем към другите примери, тестови случаи и инструменти, нека първо разберем как това тестване се различава от тестването на натоварване.
Обемно тестване срещу тестване на натоварване
По-долу са дадени някои от основните разлики между тестване на обема и натоварването:
| S.No. | Тестване на обема | Тестване на товара |
|---|---|---|
| 1 | Тестването на обема се извършва, за да се провери производителността на базата данни спрямо голям обем данни в БД. | Тестването на натоварването се извършва чрез промяна на потребителските натоварвания за ресурсите и проверка на ефективността на ресурсите. |
| две | Основният фокус на това тестване е върху „данни“. | Основният фокус на това тестване е върху „потребителите“. |
| 3 | Базата данни е подчертана до максимална граница. | Сървърът е стресиран до максималната граница. |
| 4 | Един прост пример може да бъде създаването на файл с голям размер. | Един прост пример може да бъде създаването на голям брой файлове. |
Как да извършите това тестване?
Това тестване може да се извърши както ръчно, така и с помощта на който и да е инструмент. Като цяло използването на инструменти ще спести времето и усилията ни, но в случай на тест за обем според моя опит използването на инструменти може да ви даде по-точни резултати в сравнение с ръчното тестване.
Преди да започнете изпълнението на тестовия случай, уверете се, че:
- Екипът се съгласи с плана за тестване за това тестване.
- Други екипи от вашия проект са добре информирани за промените в базата данни и нейното въздействие върху тяхната работа.
- Тестовите стендове са настроени за посочените конфигурации.
- Изготвена е базовата линия за тестване.
- Конкретните обеми данни за тестване (скриптове за данни или процедури и т.н.) са готови. Можете да прочетете за инструментите за създаване на данни на нашата страница за генериране на данни.
Нека да видим няколко примерни тестови случая, които можете да използвате при изпълнение:
Проверете това за всички избрани обеми данни за тестване на обем:
- Проверете дали добавянето на данни може да се извърши успешно и дали това се отразява в приложението или уебсайта.
- Проверете дали изтриването на данни може да се извърши успешно и дали това се отразява в приложението или уебсайта.
- Проверете дали актуализирането на данни може да се извърши успешно и дали това се отразява в приложението или уебсайта.
- Уверете се, че няма загуба на данни и цялата информация се показва според очакванията в приложението или уебсайта.
- Уверете се, че времето за приложение или уеб страниците не изтече поради голям обем данни.
- Уверете се, че грешките при срив не се показват поради голям обем данни.
- Уверете се, че данните не са презаписани и са показани правилни предупреждения.
- Уверете се, че други модули на вашия уебсайт или приложение не се сриват или изтичат с голям обем данни.
- Проверете дали времето за реакция на DB е в приемливия диапазон.
Инструменти за тестване на обем
Както беше обсъдено по-рано, че автоматизираното тестване спестява време и дори дава точни резултати в сравнение с ръчното тестване. Друго предимство от използването на инструменти за обемно тестване е, че можем да провеждаме тестовете през нощта и по този начин работата на останалите екипи или членове на екипа няма да бъде засегната от обема на данните в DB.
Можем да насрочим тестовете за сутринта и резултатите ще бъдат готови.
Следва списък с няколко инструмента за тестване на том с отворен код:
# 1) DbFit:
Това е инструмент с отворен код, който поддържа разработено от тестове.
DbFit тестовата рамка е написана върху Fitness, тестовете са написани с помощта на таблици и могат да бъдат изпълнени с помощта на всеки Java IDE или CI инструмент.
# 2) HammerDb:
HammerDb е също инструмент с отворен код, който може да бъде автоматизиран, с много нишки и дори позволява изпълнение на скриптове. Може да работи с SQL, Oracle, MYSQL и т.н.
# 3) JdbcSlim:
JdbcSlim командите могат лесно да бъдат интегрирани в Slim Fitness и той поддържа всички бази данни, които имат JDBC драйвер. Фокусът е върху запазването на конфигурацията, тестовите данни и SQL заявките отделно.
# 4) NoSQLMap:
Това е инструмент с отворен код Python, който е предназначен за автоматично инжектиране на атаки и нарушаване на конфигурациите на DB за анализ на заплахата. Работи само за MongoDB.
# 5) Ruby-PLSQL-спец:
PLSQL може да бъде тестван единично, използвайки Ruby, тъй като Oracle се предлага като инструмент с отворен код. Това основно използва две библиотеки: Ruby-PLSQL и Rspec.
Заключение
Обемното тестване е нефункционално тестване, което се прави, за да се анализира производителността на базата данни. Може да се направи ръчно, както и с помощта на някои инструменти.
Ако сте QA, който е нов в това тестване, бих препоръчал да играете с инструмента или първо да изпълните някои тестови случаи. Това ще ви помогне да разберете концепцията за тестване на обема, преди да преминете към тестване.
топ 10 компании за уеб разработка в Индия
Това тестване е доста сложно и има свои собствени предизвикателства, поради което е много важно да имате задълбочени познания за концепцията, създаването на тестовото поле и езика на DB, преди да го извършите.
Надявам се, че този урок ще увеличи обема на знанията ви по тази тема :)
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Учебник за тестване по двойки или за всички двойки с инструменти и примери
- Функционално тестване срещу нефункционално тестване
- Урок за тестване на конфигурация с примери
- Изтегляне на eBook за тестване на Primer
- Урок за деструктивно изпитване и безразрушително тестване
- 11 най-добри инструменти за автоматизация за тестване на приложения за Android (инструменти за тестване на приложения за Android)
- Най-добри инструменти за IVR тестване: Урок за тестване на CYARA и HAMMER