Какво е тестване за мащабируемост? Учете с пример
Томас Хамилтън
⚡ Умно обобщение
Тестването за мащабируемост измерва как се държи приложението, когато потребителското натоварване, обемът на данните или скоростта на транзакциите се повишат или спаднат, разкривайки точната точка, в която производителността спира да се мащабира, и идентифицирайки отговорното за това пречка.
Какво е тестване за мащабируемост?
Тестване на скалируемост е нефункционален метод за тестване, който измерва производителността на система или мрежа, когато броят на потребителските заявки се увеличава или намалява. Целта на тестването за мащабируемост е да се гарантира, че системата може да се справи с прогнозирано увеличение на потребителския трафик, обема на данните и честотата на транзакциите. То тества способността на системата да отговори на нарастващото търсене.
Тестването за мащабируемост е подвид на тестване на производителността, така че се концентрира върху поведението на приложението, когато то е разположено в по-голяма система или е под прекомерно натоварване. В Софтуерно инженерство, Тестването за мащабируемост измерва точката, в която приложението спира мащабирането и идентифицира причината за това.
Защо се прави тестване за мащабируемост?
Проблеми с капацитета рядко се появяват по време на функционално тестване. Те се появяват в най-натоварения търговски ден от годината, когато стартира маркетингова кампания или когато набор от данни, който е нараствал тихо в продължение на две години, най-накрая забави всяка заявка. Тестването за мащабируемост разкрива тези ограничения първо в контролирана среда. По-конкретно, то ви помага да:
- Определете как приложението се мащабира с увеличаване на работното натоварване и къде тази крива се изравнява.
- Определете лимита за едновременни потребители за уеб приложението, преди времето за реакция да стане неприемливо.
- Определете влошаването на качеството на работа от страна на клиента и потребителското изживяване при натоварване, като например бавно рендиране на екрана.
- Определете устойчивостта и деградацията от страна на сървъра, включително насищане на процесора, течове на памет и изчерпване на пула за връзки.
Най-лесно е да се представи връзката като крива: пропускателната способност се увеличава заедно с добавеното натоварване, докато даден ресурс се насити, след което допълнителните потребители само удължават опашката.
Видове тестове за мащабируемост
Мащабируемостта не е едно-единствено свойство, така че тестовият план обикновено обхваща повече от едно измерение. Четирите типа по-долу са тези, които повечето екипи измерват, а първите два определят формата на самата тестова среда.
| Тип | Какво е мащабирано | Какво доказва тестът |
|---|---|---|
| Вертикална мащабируемост (увеличаване на мащаба) | CPU, памет или място за съхранение, добавени към един сървър | Колко допълнително натоварване поема една обновена машина и къде се намира таванът на единичния възел |
| Хоризонтална мащабируемост (мащабиране) | Допълнителни сървъри, контейнери или възли зад балансьор на натоварването | Дали пропускателната способност се увеличава приблизително пропорционално на добавените възли или споделените ресурси я ограничават |
| Функционална мащабируемост | Нови функции, модули или услуги | Дали добавената функционалност може да бъде абсорбирана без да се влоши качеството на съществуващите транзакции |
| Административна мащабируемост | Потребители, наематели, екипи или среди за управление | Дали адаптацията, разрешенията и мониторингът остават работещи с разрастването на организацията |
Вертикалното мащабиране е по-лесно, защото архитектурата рядко се променя, но една машина винаги има таван. Хоризонталното мащабиране премахва този таван и подобрява отказоустойчивостта, за сметка на мрежовата латентност, съгласуваността на данните и режийните разходи за координация – всичко това тестът трябва да измерва, а не да предполага.
Какво да се тества при тестване за мащабируемост
Мащабируемостта се оценява по измервания, а не по импресии. Записвайте следните атрибути на всяка стъпка на зареждане, така че да се вижда тенденцията, а не само крайното число.
| Атрибут | Какво ви казва |
|---|---|
| Време за реакция | Време между потребителската заявка и системния отговор; то трябва да остане постоянно с нарастване на едновременността |
| Преход на екрана | Колко бързо една страница или изглед отстъпва място на следващата при натоварване |
| магистрала | Обем на обработваните заявки за единица време; плато маркира границата на мащабируемост |
| Измервания на времето | Време на сесия, време за рестартиране, време за печат, време за транзакция и време за изпълнение на задача |
| Производителност спрямо броя на потребителите | Как се движи всяка метрика, когато едновременните потребители се добавят на стъпки |
| Заявка за цени | Заявки в секунда, транзакции в секунда и посещения в секунда |
| Използване на мрежата | Консумирана честотна лента и латентност на пакетите между нивата |
| Използване на процесор и памет | Цена на ресурсите на транзакция; постоянно нарастващата цифра често сигнализира за изтичане |
| Броячи на уеб сървъра | Заявки и отговори в секунда, дълбочина на опашката и отхвърлени връзки |
| Производителност под товар | Комбинирано поведение, след като всички показатели се прочетат заедно в пиковите си стойности |
Тестова стратегия за тестване на мащабируемост
Стратегията за тестване на мащабируемост се различава в зависимост от типа на тестваното приложение. Ако дадено приложение осъществява достъп до база данни, параметрите за тестване ще включват размера на базата данни спрямо броя на потребителите и т.н.
Предпоставки за тестване на скалируемост
- Възможност за разпределение на товара — Проверете дали инструментът за тестване на натоварване позволява генерирането на натоварване от множество машини и управлението му от централна точка.
- Operaтинг система — Проверете какво операционна система агентите за генериране на натоварване и главният тест за натоварване се изпълняват под него.
- Процесор — Проверете какъв тип процесор е необходим за виртуалния потребителски агент и главния сървър за тестване на натоварването.
- памет — Проверете колко памет би била достатъчна за виртуалния потребителски агент и главния сървър за тестване на натоварването.
- Тестова среда — Проверете дали тестова среда отразява производството достатъчно точно, за да могат резултатите да се пренесат.
Как да направите тест за мащабируемост
- Дефинирайте повтаряем процес за изпълнение на тестове за мащабируемост през целия жизнен цикъл на приложението
- Определете критериите за мащабируемост
- Кратък списък на софтуерните инструменти, необходими за изпълнение на теста за натоварване
- Задайте средата за тестване и конфигурирайте хардуера, необходим за изпълнение на тестове за мащабируемост
- Планирайте тестовите сценарии, както и тестовете за мащабируемост
- Създайте и проверете скрипта за виртуален потребител
- Създайте и проверете сценариите за тестване на натоварване
- Изпълнете тестовете
- Оценете резултатите
- Генерирайте необходимите отчети
План за тестване на скалируемост
Преди да създадете тестовете, разработете подробен план за тестване. Важна стъпка е да се гарантира, че тестът отговаря на изискванията на приложението.
Следват атрибутите за създаване на добре дефиниран План за тестване за тестване на скалируемост.
- Стъпки за скриптовеТестовият скрипт трябва да има подробни стъпки, които определят точните действия, които потребителят би извършил.
- Данни по време на изпълнениеТестовият план трябва да определи всички данни по време на изпълнение, необходими за взаимодействие с приложението.
- Тестове, управлявани от данниАко скриптовете се нуждаят от различни данни по време на изпълнение, е необходимо да разбирате всички полета, които изискват тези данни.
Пример за тестване на мащабируемост
Да разгледаме онлайн магазин, който очаква 2,000 едновременни купувачи по време на сезонна разпродажба. Екипът първо се договаря за критерий за преминаване: транзакцията по плащане трябва да завърши за по-малко от три секунди за 95% от потребителите, с процент на грешки под един процент.
След това тестът изпълнява същия скрипт за преглед-търсене-количката-плащане при 250, 500, 1,000, 1,500 и 2,000 виртуални потребители. Времето за реакция е близо две секунди до 1,000 потребители, намалява до 2.8 секунди при 1,500 и достига девет секунди при 2,000, докато процесорът на базата данни е натоварен на 98 процента. Следователно, ограничението за мащабируемост е приблизително 1,500 потребители, а пречката е нивото на базата данни, а не сървърите на приложенията, които екипът е планирал да добави.
Инструменти за тестване на мащабируемост
Тестването за мащабируемост изисква инструмент, който може да генерира натоварване от няколко машини едновременно и да докладва резултатите централизирано. Изборът обикновено следва основния език на екипа и тестваните протоколи.
| Инструмент | Scripting | Най-подходящ за |
|---|---|---|
| Apache JMeter | GUI плюс XML тестови планове, Java основан | Широко покритие на протоколи, включително JDBC, JMS, LDAP и SOAP |
| Графана k6 | JavaСценарий или TypeScript | API и микросървисни тестове, свързани в CI/CD конвейер |
| Гатлинг | Java, Kotlin или Scala DSL | Висок брой виртуални потребители на инжектор с подробни HTML отчети |
| скакалец | обикновен Python | Python екипи, които трябва да разширят клиента отвъд HTTP |
| LoadRunner | C-подобни скриптове, записани във VuGen | Големи корпоративни комплекси със стари и пакетни приложения |
Облачно хоствани бегачи, като например BlazeMeter, LoadView и Gatling Enterprise са разположени върху няколко от тези двигатели и си струва да се обмислят, когато тестът изисква десетки хиляди виртуални потребители или трафик от множество географски региони. По-широк преглед на категорията е наличен в ръководството за инструменти за тестване на ефективността.
Предизвикателства и най-добри практики при тестване на мащабируемост
Най-разочароващите резултати за мащабируемост tracобратно към тестовата настройка, а не към приложението. Това са проблемите, които се повтарят, и навиците, които ги предотвратяват.
Общи предизвикателства
- Маломерни среди — Тестова платформа с наполовина по-малко производствена памет отчита пречка, която не съществува в производствения процес.
- Нереалистични модели на работно натоварване — Скриптове без време за обмисляне или вариации на данните попадат в кешове, които реалните потребители биха пропуснали.
- Шумни резултати — Автоматичното мащабиране, събирането на боклук и споделеният облачен хардуер правят два еднакви цикъла работа несъвместими.
- Тънка наблюдаемост — Без показатели от страна на сървъра, бавният резултат показва, че нещо се е счупило, но не и какво.
- цена — Генерирането на много висока паралелност изисква собствен парк от генератори на натоварване, което е лесно да се подценява.
Най-добри практики
- Съгласувайте критериите за преминаване, като например процентил на времето за реакция и таван на процента на грешки, преди първото изпълнение.
- Увеличете натоварването в планираните стъпки и задръжте всяка стъпка достатъчно дълго, за да се установи системата.
- Променяйте тестовите данни за всеки виртуален потребител, така че кеширането да не изкривява резултатите.
- Събирайте показатели за приложения, бази данни и инфраструктура, заедно с данните от страна на клиента.
- Съхранявайте тестовите скриптове в контрола на версиите и изпълнявайте кратка проверка за мащабируемост на всяка компилация, след което пълно изпълнение преди пускане.
- Сравнявайте тенденциите в различните версии, вместо да оценявате един единствен отчет изолирано.
Тестване за мащабируемост срещу тестване за натоварване
Двете често се бъркат, защото и двете прилагат натоварване. Разликата се състои във въпроса, на който отговаря всяка от тях: Тестването за мащабируемост пита докъде може да расте системата, докато тестване на товара пита дали се справя с вече очакваното натоварване.
| База | Тестване на скалируемост | Тестване на товара |
|---|---|---|
| Фокус | Фокусира се върху производителността на вашите уебсайтове, софтуер, хардуер и приложения, когато се правят промени в размера или обема на системата, за да се отговори на нарастваща нужда. | Тестването на натоварване се фокусира върху тестването на приложение при големи натоварвания, за да се определи в кой момент времето за реакция на системата се проваля. |
| Модел на натоварване | Натоварването се увеличава на стъпки, а ресурси могат да се добавят между стъпките. | Натоварването се поддържа на очакван пик за фиксиран период от време |
| Отговор на въпроса | Докъде може да се разрасне тази система и какво я ограничава? | Тази система постига ли договорените си цели днес? |
| Типична мощност | Ограничение на мащабируемостта, пречка и план за капацитет | Преминаване или неуспешно изпълнение спрямо целите за време за реакция и пропускателна способност |
И двамата седят под нефункционално тестване чадър до него стрес тестове, тестване с шипове, тест за издръжливост намлява обемно тестване, а една зряла стратегия за ефективност обикновено изпълнява няколко от тях срещу едни и същи скриптове.
