Какво е обемно тестване? Учете с примери
Томас Хамилтън
⚡ Умно обобщение
Тестването на обем подлага приложението на много голямо количество данни, за да види как се държат паметта, заявките и времето за реакция с нарастването на базата данни. Нарича се още тестване с наводнение и мащабира данните, а не броя на потребителите.
Какво е обемно тестване?
Тестване на обема е вид софтуерно тестване, при което софтуерът се подлага на огромен обем данни. Нарича се още като тестване на наводнения. Тестването на обема се извършва, за да се анализира производителността на системата чрез увеличаване на обема на данните в базата данни.
С помощта на Volume testing може да се проучи въздействието върху времето за реакция и поведението на системата, когато е изложена на голям обем данни.
Например, услуга за стрийминг на музика може да бъде тествана с каталог от 50 милиона tracks и таблица с история на слушане, съдържаща милиарди редове, за да се види дали заявките за търсене и препоръки все още се връщат в приемливо време.
Обърнете внимание на разграничението: обемното тестване увеличава количество данни системата е валидна. Увеличаването на брой едновременни потребители е тестване на натоварване, което е различен тест с различна цел.
Предимства на обемното тестване
- Ранното идентифициране на проблеми с капацитета избягва много по-високите разходи за отстраняването им в производството
- Помага за по-бърз старт на плановете за мащабируемост
- Ранно идентифициране на тесните места
- Той гарантира, че системата ви вече може да се използва в реалния свят
Защо се прави обемно тестване?
Целта на извършването на обемно тестване е да
- Проверете производителността на системата с нарастващи обеми данни в базата данни
- Идентифицирайте проблемите, които е вероятно да възникнат, след като наборът от данни стане голям
- За да разберете точката, в която стабилността на системата се влошава
- Volume Testing ще помогне да се идентифицира капацитетът на системата или приложението – нормален и голям обем
Как да се направи обемно тестване
При обемно тестване трябва да се тестват следните неща
- Тествайте, за да проверите дали има загуба на данни
- Проверете времето за реакция на системата
- Проверете дали данните се съхраняват правилно или не
- Проверете дали данните са презаписани без известие
- Проверете дали предупрежденията и съобщенията за грешки действително се появяват, когато е достигнат лимит на обема
- Проверете дали големият обем данни влияе върху скоростта на обработка
- Уверете се, че системата разполага с паметта и ресурсите за съхранение, необходими на тома
- Уверете се, че тестът за обем обхваща цялата система, а не само един компонент
- Има ли някакъв риск, ако обемът на данните е по-голям от посочения
- Установете дали съществува гаранция, че обемът на данните няма да надвиши определения максимум
Най-добри практики за тестване с голям обем
Няколко от практиките по-долу са споделени с тестовете за натоварване, тъй като двете обикновено се изпълняват в една и съща среда. Специфичните за обема практики се отнасят до самия набор от данни:
- Спрете всички сървъри и проверете всички регистрационни файлове
- Преди теста за натоварване изпълнете ръчно сценария на приложението
- За най-полезни резултати разпределете броя на потребителите
- За да преодолеете лицензионните ограничения, балансирайте времето за мислене
- Бъдете внимателни с новата конструкция
- Анализирайте случая на употреба за подобрение, след като бъде установена базова линия
- Повтарянето на определени части от обемното тестване става неизбежно в случай, че има пречки в производителността
Тестване на обем срещу тестване на натоварване
| Тестване на обема | Тестване на товара |
|---|---|
|
|
|
|
Предизвикателства при обемно тестване
- Трудно генериране на фрагментация на паметта
- Динамично генериране на ключове
- Релационна Integrity на генерираните данни
Как този тест се сравнява с други тестове за производителност
Тестването на производителността е семейство от тестове, които се различават по формата на приложеното натоварване, поради което те лесно се объркват.
| Тип на теста | Какво е увеличено | Въпрос, на който отговаря |
|---|---|---|
| Тестване на натоварването | Едновременни потребители, до очаквания пик | Постига ли целите при нормален пиков трафик? |
| Обемно тестване | Данните, съхранявани в базата данни | Справя ли се с нарастването на набора от данни? |
| Стрес тестове | Натоварване над капацитета, до повреда | Къде се чупи и как? |
| Спайк тестване | Зарежда се мигновено и изключително | Оцелява ли и възстановява ли се от шок? |
| Тест за издръжливост | Продължителност при нормално натоварване | Влошава ли се производителността с течение на времето? |
| Тестване с накисване | Продължителност, ресурси за гледане | Има ли течове на памет или дескриптори? |
| Тестване на стабилност | Различни условия | Остава ли надежден при промяна на условията? |
Разграничението, което е най-важно тук: Тестването на обем мащабира данните, тестването на натоварване мащабира потребителите. Доклад, който се изпълнява за две секунди върху десет хиляди реда и за две минути върху десет милиона реда, има проблем с обема, а не с натоварването, и никакъв допълнителен капацитет на сървъра няма да го реши.
Как да генерираме тестови данни за обемно тестване
В раздела за предизвикателствата се отбелязва, че генерирането на реалистични данни е трудната част от обемното тестване. На практика се използват четири подхода и всеки от тях е свързан с компромис.
| Подход | реализъм | Основен недостатък |
|---|---|---|
| Копие от производствени данни | Най-висока | Излагане на поверителност и съответствие |
| Маскирано производствено копие | Високо | Маскирането може да наруши референтната цялост |
| Синтетично поколение | Среден | Разпределенията може да не съответстват на реалността |
| Възпроизведен производствен трафик | Високо | Изисква инфраструктура за улавяне |
Независимо кой маршрут изберете, трябва да са налице три свойства, в противен случай тестът няма да измери нищо полезно.
- Референтна цялост. Всеки външен ключ трябва да бъде преобразуван. Милион осиротели редове упражняват механизма за съхранение, но никога пътищата за свързване, които приложението действително използва.
- Реалистична кардиналност. Ако производствената таблица има десет милиона реда за двеста клиенти, генерирането на десет милиона реда за десет милиона клиенти води до напълно различни планове за заявки.
- Реалистично разпределение. Реалните данни са изкривени. Равномерно произволните данни крият горещите дялове и споровете за индекси, които причиняват производствени инциденти.
Практическо предупреждение относно поверителността. Копирането на производствени данни в тестова среда е най-честата причина за нарушение на данните при тестване. Маскирайте личните полета преди копието да напусне производствената среда, а не след това.
