Hvad er Spike-test i softwaretest? Lær med eksempel

⚡ Smart opsummering

Spike Testing udsætter en applikation for en pludselig, ekstrem belastningsstigning og trækker den derefter tilbage lige så brat. Målet er at finde ud af, om systemet overlever stødet, og lige så vigtigt, om det genopretter sig bagefter.

⚡ Indlæsningsmønster: En kraftig stigning langt over normal trafik, holdt kortvarigt og derefter fjernet.
🎯 Primært mål: Fastslå, om systemet fejler, og om det fejler på en tilfredsstillende måde.
🔄 Genopretningsspørgsmål: Det er lige så vigtigt at vende tilbage til normale responstider efter en stigning, som det er at overleve den.
📈 Realistiske udløsere: Flash-salg, billetudgivelser, viral trafik og planlagte batchjob.
🛠️ Værktøj: JMeter og LoadRunner modellerer begge en øjeblikkelig opstigning i stedet for en gradvis.
📊 Hvad skal du se: Fejlrate, kødybde og den tid, det tager at vende tilbage til baseline.

Læs mere

Hvad er Spike Testing?

Spike test er en type softwaretest, hvor en softwareapplikation testes med ekstreme stigninger og fald i trafikbelastning. Hovedformålet med spidstest er at evaluere softwareapplikationens adfærd under pludselige stigninger eller fald i brugerbelastningen og bestemme genoprettelsestiden efter en stigning i brugerbelastningen.

Spike Testing udføres for at vurdere svaghederne ved softwareapplikationer.

Mål med spike-testning

Målet med Spike-testen er at se, hvordan systemet reagerer på uventet stigning og fald i brugerbelastningen. I Software Engineering hjælper Spike-test med at bestemme, at systemets ydeevne vil forringes, når der er en pludselig høj belastning.

Et andet mål med Spike Testing er at bestemme restitutionstiden. Mellem to på hinanden følgende spidser af brugerbelastning skal systemet bruge noget tid på at stabilisere sig. Denne restitutionstid bør være så lav som muligt.

Sådan laver du spidstest

Her er de enkle trin til at udføre Spike Testing:

Trin 1) Bestem belastningskapaciteten

Bestem den maksimale brugerbelastningskapacitet for dit softwareprogram.

Trin 2) Forbered testmiljøet

Forbered testmiljøet og konfigurer det til at registrere ydeevneparametre.

Trin 3) Definer forventet belastning

Påfør forventet maksimal belastning på din softwareapplikation ved hjælp af en Værktøj til præstationstest efter eget valg.

Trin 4) Øg belastningen

Øg belastningen til systemet hurtigt i en bestemt periode.

Trin 5) Indstil Load tilbage til Normal

Reducer gradvist belastningen tilbage til dets oprindelige niveau.

Trin 6) Analyser resultaterne

Analyser præstationsgrafer og målinger som fejl, tid, virtuelle brugere osv.

Eksempler på spidstestscenarier

Når en e-handelsbutik lancerer særlige tilbud med fantastiske rabatter, såsom på Black Friday.
Når en webapplikation livestreamer et yndlings-tv-program.
Når et flash-udsalg foregår på et websted med daglige tilbud.
Når et bestemt indhold på et websted går viralt over internettet.
Et nyt system er frigivet til produktion, og flere brugere ønsker at få adgang til systemet.
En strømafbrydelse kan medføre, at alle brugere mister adgangen til et system. Efter at fejlen er løst, logger alle brugere derefter på systemet igen samtidigt.

Gendannelsesscenarier på spidsbelastninger

Tre hovedgendannelsesscenarier, der kan konfigureres til at beskytte mod pigge, er:

Brug cloud-platforme som AWS, Azure til dynamisk at øge serverkapaciteten i takt med brugerbelastningen
Tillad ikke applikationsadgang til nogle brugere, så systemet ikke udsættes for stor belastning. Dette forhindrer personer over den maksimalt beregnede belastning i at komme ind i systemet. Beskytter således systemet mod truslen om en overdreven belastning.
Webstedets administrator giver brugere mulighed for at tilslutte sig systemet. Dog med advarsel om, at de kan blive udsat for langsom reaktion på grund af tung belastning. Dette kan resultere i en negativ indvirkning på systemets ydeevne. Brugeren vil dog være i stand til at arbejde med systemet.

Fordele og ulemper ved spike-testning

Nedenfor er fordele og ulemper ved Spike Testing:

Fordele	Ulemper
Softwarens ydeevne skal vedligeholdes for enhver pris. Men når der er en ekstrem stigning i belastningen af ethvert system, er der store chancer for problemerne. Spike Testing hjælper med at teste et sådant scenarie.	Den eneste ulempe ved Spike Testing er, at det er en dyr testproces. Så det var nødvendigt at opsætte særlige testbetingelser. Men over den længere varighed vil det helt sikkert give et positivt ROI.
I standardtestmetoden bliver de dårlige til worst-case scenarier muligvis ikke behandlet. At ignorere dem betyder dog ikke, at de aldrig vil forekomme. Derfor bør enhver software være klar til sådanne muligheder. Et sådant worst case-scenarie er belastning, som kan bedømmes og minimeres ved hjælp af spidstest.

Spike testværktøjer

1) JMeter

Apache JMeter er et java open source spike test værktøj. Den er specielt designet til at indlæse funktionel testadfærd og måle ydeevne. Dette præstationstestværktøj kan bruges til at analysere og måle ydeevnen af webapplikationer eller en række tjenester. I dag er det meget brugt til den funktionelle test, databaseservertest.

2) LoadRunner

LoadRunner er et belastningstestværktøj til Windows og Linux, som tillader spidstest af web og andre apps. Det hjælper med at bestemme ydelsen og resultatet af påføringen selv under den tunge belastning.

Hvordan denne test passer til præstationstestfamilien

Ydelsestest er en paraplybetegnelse. Varianterne nedenfor adskiller sig kun i formen af den påførte belastning og den varighed, den holdes i, hvilket er grunden til, at de så ofte forveksles med hinanden.

Testtype	Indlæsningsmønster	Spørgsmål det besvarer
Belastningstest	Forventet spidsbelastning, kort varighed	Opfylder systemet sine mål under normal spidsbelastning?
Stresstest	Øget ud over kapaciteten indtil fejl	Hvor knækker den, og fejler den yndefuldt?
Spike test	Pludselig ekstrem stigning, derefter tilbagetrækning	Overlever og kommer den sig efter et trafikchok?
Udholdenhedstest	Normal belastning holdt i mange timer	Forringes ydeevnen over tid?
Soak-test	Vedvarende belastning over en længere periode	Er der hukommelseslækager eller ressourceudtømning?
Stabilitetstest	Varierende belastning under forskellige forhold	Forbliver systemet pålideligt, når forholdene ændrer sig?
Volumentest	Normale brugere, meget stor datamængde	Klarer den sig, når databasen vokser?

Holdbarheds- og gennemvædningstestning behandles ofte som synonymer. I almindelig brug er de: begge holder en vedvarende belastning i en lang periode. Hvor teams adskiller dem, fokuserer udholdenhedstest på, om svartiderne stiger, mens soak-test fokuserer på ressourceforbrug såsom hukommelse, filhandles og forbindelsespuljer. At køre en giver dig normalt bevis for begge.

Nøglemålinger, der skal registreres under testen

En performancekørsel er kun så god som det, du optager, mens den udføres. Registrer disse seks på server- og klientsiden, og sammenlign dem derefter med baseline i stedet for med en mavefornemmelse.

metric	Hvad den fortæller dig	Advarselsskilt
Gennemsnitlig svartid	Typisk brugeroplevelse	Enhver opadgående drift på tværs af løbet
95. percentil responstid	Oplevelsen for de langsomste brugere	Langt over gennemsnittet, hvilket betyder inkonsekvens
gennemløb	Anmodninger behandlet pr. sekund	Fald mens belastningen forbliver konstant
Fejlrate	Andel af mislykkede eller timeout-forespørgsler	Enhver stigning over den aftalte tærskel
CPU- og hukommelsesforbrug	Serverressource headroom	Hukommelse der klatrer og aldrig vender tilbage
Databaseforbindelser og tråde	Udmattelse af poolen	Antal der vokser støt uden frigivelse

Læs gennemsnittet og percentilen sammen. Et gennemsnit på 800 ms med en 95. percentil på 900 ms beskriver et konsistent system. Det samme gennemsnit med en 95. percentil på 9 sekunder betyder, at én ud af tyve brugere har det dårligt, og gennemsnittet skjuler det.

Se på formen, ikke kun værdien. I enhver langvarig test er en flad ressourcelinje et bestået resultat, og en stigende er en lækage, selv når det absolutte tal stadig er komfortabelt inden for grænsen i det øjeblik, kørslen slutter.

Spike-testning: Vigtige konklusioner

software test er en type softwaretest, hvor en softwareapplikation testes med ekstreme stigninger og fald i trafikbelastning.
Den rigtige tilgang til at udføre spidstest er at øge antallet af brugere uventet efterfulgt af et øjeblikkeligt fald i belastningen.
Den uventede belastning er den vigtigste egenskab ved aftalen.
Eksempler på virkelige Spike-testscenarier er - når en e-handelsbutik lancerer særlige tilbud med fantastiske rabatter, såsom på Black Friday. Alternativt, når en webapplikation livestreamer et yndlings-tv-program.
JMeter er et sådant nyttigt værktøj til at udføre spidstest.

Ofte Stillede Spørgsmål

Stresstest øger belastningen gradvist, indtil systemet går i stykker, for at finde grænsen. Spiketestning anvender den ekstreme belastning øjeblikkeligt for at se, om et pludseligt stød forårsager en fejl, som en gradvis rampe ikke ville.

Et system, der holder sig kørende, men aldrig vender tilbage til normale svartider, har stadig svigtet de brugere, der ankommer efter toppen. Gendannelsestiden er den målestok, der afspejler den reelle forretningsmæssige effekt.

Basér det på en reel begivenhed i stedet for et rundt tal. Historisk trafik fra et tidligere salg eller en lancering, ganget med den forventede vækst siden, giver et forsvarligt mål.

AI-modeller trænet på historisk trafik, marketingkalendere og eksterne signaler forudsiger, hvornår stigninger vil forekomme, hvilket giver teams mulighed for at forudskalere infrastruktur i stedet for at reagere bagefter.

Ja. AI-værktøjer kan udlede profiler af stigninger fra produktionsadgangslogfiler og dermed gengive den sande form af tidligere stigninger i stedet for en kunstig trinvis ændring.