Към съдържанието
wannacode

Производителност и натоварване

Накратко: Изискването за производителност казва кое действие, колко бързо, за какъв дял от заявките и при какво натоварване: „95 % от отварянията на количката са под 300 ms при 200 клиенти едновременно“. Тестът за натоварване проверява обещаното, стресът търси къде се чупи, а издръжливостта дали издържа часове.

Проблем

Бързо беше, докато пазарувах сам

Изискването е „Магазинът трябва да е бърз“. Тестерът отваря количката: 0,8 секунди. Бързо е. Изискването е изпълнено.

На Черния петък в магазина влизат 600 души едновременно. Количката се отваря за 14 секунди, плащанията изтичат, а клиентите пълнят количките отново и отново, което прави всичко още по-бавно. Магазинът губи най-добрия си ден в годината.

Тестът на тестера беше верен. Изискването не казваше нищо, което да падне.

Идеята

Петте части на изискването

Изискването за производителност казва пет неща:

  1. Кое действие: отварянето на количката, търсенето, плащането. Не „магазинът“.
  2. Каква мярка: време за отговор, поръчки в минута, процент грешки.
  3. Каква граница: под 300 ms, поне 50 поръчки в минута, под 1 % грешки.
  4. За какъв дял: 95 % от заявките, не средното.
  5. При какво натоварване и условия: 200 клиенти едновременно, на среда като истинската, с всичките 12 000 продукта.

Заедно: „95 % от отварянията на количката са под 300 ms при 200 клиенти едновременно“. Това изречение може да падне. „Да е бързо“ не може.

По-точно, за любопитните

В ISO/IEC 25010:2023 това е характеристиката производителност (performance efficiency), с три подхарактеристики: времево поведение (time behaviour), използване на ресурсите (resource utilization) и капацитет (capacity). Как се пише такова изискване като архитектурен сценарий и защо процентите на наличността се умножават по веригата от услуги, има в урока Нефункционални изисквания, които се мерят от курса по софтуерно инженерство.

Идеята

Защо не средното

Десет клиенти отварят количката. Девет чакат до 0,6 секунди, един чака 9,8. Средното е 1,3 секунди и изглежда добре. Но единият клиент е чакал почти 10 секунди, и средното го скрива.

Процентилът казва колко от заявките са под границата. p95 = 300 ms значи: 95 % от заявките са под 300 ms, а 5 % може да са по-бавни. Изискването казва точно колко бавни заявки са допустими и не позволява няколко много бързи да скрият бавните.

За плащането, където всеки бавен клиент е изгубена поръчка, екипите често искат и p99.

Пробвай

Сметни

1. Десет отваряния на количката: 0,2; 0,2; 0,3; 0,3; 0,3; 0,4; 0,4; 0,5; 0,6 и 9,8 секунди. Средното е 1,3 секунди. Колко от клиентите са чакали над 1,3 секунди?
2. Изискването е „95 % от отварянията под 2 секунди“. От 1 000 отваряния 970 са под 2 секунди. Минава ли?
3. Количката се отваря за 1,1 секунди, когато в магазина е само тестерът. Какво знаеш за разпродажбата?

Идеята

Три въпроса, три вида тестове

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

  • Тест за натоварване (load testing): издържа ли системата очакваното? 200 клиенти, колкото е пикът. Проверява изискването.
  • Стрес тест (stress testing): къде се чупи и как? Клиентите растат отвъд обещаното, докато нещо спре. После: връща ли се магазинът сам, губят ли се поръчки?
  • Тест за издръжливост (endurance, soak testing): издържа ли дълго? 48 часа при обичайното натоварване. Хваща това, което се трупа бавно: памет, отворени връзки.

Има и пикове (spike testing): от 80 на 600 клиенти за минута, когато пристигне имейлът за разпродажбата.

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

По-точно, за любопитните

Мащабируемостта (scalability) и капацитетът се проверяват с подобни тестове: колко клиенти поема системата и как расте това, когато се добави сървър. В ISO/IEC 25010:2023 мащабируемостта е част от гъвкавостта (flexibility), а капацитетът е част от производителността.

Пробвай

Какъв е тестът?

1. Магазинът се пуска 2 часа при 200 клиенти едновременно, колкото е очакваният пик на разпродажбата, и се мери времето за отговор.
2. Клиентите се увеличават от 200 до 2 000, докато магазинът спре да отговаря. Гледа се и дали се връща сам, когато натоварването падне.
3. Магазинът върви 48 часа при обичайните 80 клиенти. На 30-ия час заявките стават все по-бавни, после магазинът пада.

Идеята

Кой казва числата

Числата не са на програмистите („сървърът издържа 150“) и не са на тестера. Те са нужда на бизнеса: колко клиенти дойдоха на миналата разпродажба, колко ще дойдат с новата реклама, колко секунди чакане е загуба на поръчка.

Анализаторът ги пита така, както пита за правилата: с пример. „Миналия Черен петък в пика имаше 420 души за 10 минути. Тази година очакваме с 50 % повече. Колко чакане е приемливо при плащането?“

После изискването се приема като всяко друго: тест при договорените условия, а резултатът се сравнява с договорената граница. Ако мине, но клиентите пак се оплакват, изискването е грешно, а не програмата. Това е валидирането на нефункционалното.

По-точно, за любопитните

CT-AcT v1.0, глава 4, разглежда производителността като част от приемното тестване: мерилата се договарят с бизнеса предварително, а средата за теста трябва да е представителна. Тестовете за производителност са скъпи (среда, данни, време), затова са добър кандидат за подбор по риск: първо плащането и количката, после страницата „За нас“.

Упражнение

Изискване за разпродажбата

1. Черният петък. Рецензирай изискването на маркетинга.

Отбележи думите, които правят изискването непроверимо или двусмислено, и избери вида на всеки проблем.

Натисни думите, които са проблем; отново, за да махнеш отметката. Със стрелките се минава от дума на дума.

Тест

Провери се

1. Кое е добро изискване за производителност?
2. Откъде идва числото „200 клиенти едновременно“?
3. Тестът за натоварване минава на лаптопа на тестера с база от 50 продукта. Какво не е наред?
4. Коя характеристика на ISO/IEC 25010 е времето за отговор?

Създаден от Иво Гергов като част от кампанията на Evo Tech за достъпно обучение по програмиране ·