Stabilitetstest i softwaretest

Hvad er stabilitetstest?

Stabilitetstest er en type ikke-funktionel softwaretest udført for at måle effektiviteten og evnen af ​​en softwareapplikation til kontinuerligt at fungere over en lang periode. Formålet med stabilitetstestning er at kontrollere, om softwareapplikationen går ned eller fejler ved normal brug på et hvilket som helst tidspunkt ved at udøve hele dets anvendelsesområde.

Stabilitetstest udføres for at kontrollere effektiviteten af ​​et udviklet produkt ud over normal driftskapacitet, ofte til et brudpunkt. Der er større betydning for fejlhåndtering, softwarepålidelighed, robusthed og skalerbarhed af et produkt under tung belastning frem for at kontrollere systemets adfærd under normale omstændigheder.

Stabilitetstest vurderer stabilitetsproblemer. Denne test er primært beregnet til at stresse softwarekomponenten maksimalt. Det er en ikke-funktionel teknik.

Stabilitetstest omtales også som en belastning eller udholdenhedstest.

Risici, hvis systemet under test ikke har gennemgået stabilitetstest

For en applikation under test, hvor et stort antal brugere introduceres, og applikationer, der skal køre i flere måneder uden at genstarte, vil der sandsynligvis opstå en række problemer:

Den mulige fejl kan konfronteres,

• systemet bremser
• systemet støder på funktionsproblemer
• systemet viser kablet adfærd
• systemet går helt ned

I Software Engineering, Stabilitetstest involverer typisk træning af systemet med tunge brugere (virtuel) og måling af ydeevneparametrene for at verificere, om systemet kan understøtte den forventede belastning.

Hvorfor udfører stabilitetstest

Denne form for test hjælper brugerne med at forstå, hvordan systemet vil fungere i virkelige situationer.

Derfor giver stabilitetstest dig mulighed for at kontrollere,

• Giv tillid til stabiliteten af ​​dit system, der testes.
• Sørg for, at dit system kan håndtere store programmer.
• Overvåg effektiviteten af ​​dit system.
• Test systemets stabilitet under stress.

Det spiller en vigtig rolle i produktudvikling, da det bruges til at bestemme begrænsningerne for et softwareprodukt, der testes, før det frigives, eller områder med flere forbedringer, før produktet går live eller i produktion.

Et meget almindeligt eksempel på stabilitetstestteknik er

Online SHopping Portals: Stabilitetstest vil kontrollere, hvordan hjemmesiden vil opføre sig, når –

• Høj mængde data indtastet på spidsbelastningstidspunktet
• Antal hits på et bestemt bestemt tidspunkt
• Problem med sideindlæsning på samme tid
• Systemets opførsel
• Systemets lydhørhed og mange flere kommer under Stabilitetstest

Et andet eksempel

A CPU test er en populær form for stabilitetstest under Test af ydeevne teknik. Denne test kontrollerer processorstabilitet og overvåger også dens ydeevne, når processorens arbejdsbyrde øges.

Sådan laver du stabilitetstest

• For at bestemme omfanget og formålet med testen skal vi sikre, at applikationsserveren(e) ikke går ned under belastningstesten.
• For at bestemme forretningsproblemerne skal du kontrollere systemets ydeevne og belastning i henhold til slutbrugerens perspektiv.
• For at tildele de forskellige ansvarsområder og roller som -Oprettelse af testplan, Test sag design, Test case review, Test udførelse mv.
• For at sikre, at testen leverer inden for den angivne tid
• For at sikre korrekt Load Testing værktøjer og erfaringsteam er til stede for det samme.
• At måle risikoen og omkostningerne ved testen. Dette vil bestemme omkostningerne ved hver udførelse i form af CPU-udnyttelse og hukommelse.
• Bestem Defekt trackonge og rapportering og deres rette kortping med kravene.

Testcase for stabilitetstest for CPU-ydelse

• For at verificere den øvre grænse for systemet.
• Hvordan systemet går ned eller genopretter.
• Et samlet antal gennemførte transaktioner pr. anmodning.
• Hvorvidt transaktionssvaret forbliver stabilt eller stiger over tid.
• Hvordan systemet opfører sig under hård belastning.
• Dens reaktion og adfærd under tung belastning.

Testrapporter til stabilitetstestning

Adskillige statistikker indsamles og måles under testudførelser; disse tal analyseres for at generere en rapport og identificere mulige præstationsproblemer.

Eksempler på statistik indsamlet under test er:

• Transaktionssvartider: Den gennemsnitlige tid det tager at udføre transaktioner under testen. Denne statistik vil evaluere, om serverens ydeevne er inden for de acceptable minimums- og maksimumsperioder for transaktionsydelse, der er defineret for systemet. Disse oplysninger vil evaluere den tid, det tager at behandle anmodningen af ​​webserveren og sendes til applikationsserveren, som i de fleste tilfælde vil fremsætte en anmodning til en databaseserver.
• Hits per sekund: Antallet af hits lavet på serveren af ​​brugere. Disse statistikker gavner til at bestemme antallet af belastning, som brugere genererer med hensyn til et antal hits.
• gennemløb: Mængden af ​​gennemløb på webserveren under testen, som måles i bytes. Gennemløb betyder mængden af ​​data, som brugerne modtog fra serveren på et givet tidspunkt. Denne statistik hjælper med at evaluere mængden af ​​belastning, som brugerne genererer.
• Transaktion pr. sekund: Disse er det samlede antal gennemførte transaktioner (både vellykkede og mislykkede) udført under en test. Denne statistik hjælper med at kontrollere den faktiske transaktionsbelastning på systemet.
• CPU: CPU procentudnyttelse brugt under en test.
• Hukommelse: Hukommelsesbrug under en test.
• Disk: udnyttelse af diskplads brugt under en test.

Grundlæggende om stabilitetstest

Stabilitetstest kommer under Performance Testing – en teknik, der udføres for at kontrollere nogle af softwarens kvalitetsegenskaber som stabilitet, pålidelighed og tilgængelighed.

Denne test bruges til at bestemme, hvor hurtigt et system eller undersystem klarer sig under en bestemt arbejdsbelastning.

Ydelsestest har mange typer, og stabilitetstest er en af ​​dem.

• Stresstest: Det er en testtype, som kontrollerer systemets robusthed ud over systemets kapacitet.
• Spike test: Det bruges til at kontrollere et systems adfærd ved at øge en belastning af et system øjeblikkeligt. Målet er at kontrollere, på hvilket tidspunkt systemet vil have problemer med ydeevnen, eller det vil bestå.
• Skalerbarhedstest: Det bruges til at kontrollere et systems muligheder. Hvor effektivt systemet vil opføre sig i stigende behov, ændring i størrelse og ændring i volumen.
• Volumen test: Det er en ikke-funktionel testteknik, hvor software, der testes, udsættes for en enorm mængde data, og et systems opførsel kontrolleres og verificeres i overensstemmelse hermed.
• Belastnings- eller stabilitetstest: (allerede diskuteret ovenfor)

Værktøjer til stabilitetstest

Nogle af værktøjerne til præstationstest er som –

• WebLOAD
• LoadRunner
• Apache JMeter
• NeoLoad
• CloudTest
• Laststorm
• LoadUI
• WAPT
• LoadImpact
• Læsser
• Httperf
• OpenSTA

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.

Ofte Stillede Spørgsmål