Stabilitetstesting i programvaretesting

Hva er stabilitetstesting?

Stabilitetstesting er en type ikke-funksjonell programvaretesting utført for å måle effektiviteten og evnen til en programvareapplikasjon til å fungere kontinuerlig over lang tid. Hensikten med stabilitetstesting er å sjekke om programvareapplikasjonen krasjer eller feiler ved normal bruk på et hvilket som helst tidspunkt ved å bruke hele bruksområdet.

Stabilitetstesting utføres for å sjekke effektiviteten til et utviklet produkt utover normal driftskapasitet, ofte til et bruddpunkt. Det er større betydning for feilhåndtering, programvarepålitelighet, robusthet og skalerbarhet til et produkt under stor belastning i stedet for å kontrollere systemets oppførsel under normale omstendigheter.

Stabilitetstesting vurderer stabilitetsproblemer. Denne testingen er først og fremst ment å stresse programvarekomponenten maksimalt. Det er en ikke-funksjonell teknikk.

Stabilitetstesting blir også referert til som en last eller utholdenhetstesting.

Risikoer hvis systemet som testes ikke har gjennomgått stabilitetstest

For en applikasjon som testes der et stort antall brukere introduseres og applikasjoner som må kjøre i flere måneder uten å starte på nytt, vil det sannsynligvis oppstå en rekke problemer:

Den mulige feilen kan møtes,

• systemet bremser ned
• systemet støter på funksjonsproblemer
• systemet viser kablet oppførsel
• systemet krasjer totalt

I programvareteknikk, Stabilitetstesting involverer vanligvis å trene systemet med tunge brukere (virtuelt) og måle ytelsesparametrene for å verifisere om systemet kan støtte den forventede belastningen.

Hvorfor gjøre stabilitetstesting

Denne typen testing hjelper brukere med å forstå hvordan systemet vil fungere i virkelige situasjoner.

Derfor lar stabilitetstesting deg sjekke,

• Gi tillit til stabiliteten til systemet ditt som testes.
• Sørg for at systemet ditt kan håndtere store programmer.
• Overvåk effektiviteten til systemet ditt.
• Test systemets stabilitet under stress.

Det spiller en viktig rolle i produktutvikling, da det brukes til å bestemme begrensningene til et programvareprodukt som testes før det utgis eller områdene med flere forbedringer før produktet går live eller på produksjon.

Et veldig vanlig eksempel på stabilitetstestteknikk er

Online Shopping Portals: Stabilitetstesting vil sjekke hvordan nettstedet vil oppføre seg når –

• Høy mengde data som legges inn på topptid
• Antall treff på et bestemt tidspunkt
• Problem med sideinnlasting samtidig
• Systemets oppførsel
• Responsen til systemet og mange flere kommer under Stabilitetstesting

Et annet eksempel

A prosessor test er en populær form for stabilitetstest under Ytelsestesting teknikk. Denne testen sjekker prosessorstabilitet og overvåker også ytelsen når prosessorens arbeidsmengde økes.

Hvordan gjøre stabilitetstesting

• For å bestemme omfanget og formålet med testingen, må vi sørge for at applikasjonsserveren(e) ikke krasjer under kjøringen av belastningstesten.
• For å fastslå forretningsproblemene, kontroller systemytelsen og belastningen i henhold til sluttbrukerperspektivet.
• For å tildele ulike ansvarsområder og roller som -Opprette testplan, Testsak design, Test case review, Test utførelse, etc.
• For å sikre at testen leverer innen den angitte tiden
• For å sikre riktig Load Testing verktøy og erfaringsteam er tilstede for det samme.
• Å måle risikoen og kostnadene som testingen innebærer. Dette vil bestemme kostnadene for hver utførelse i form av CPU-utnyttelse og minne.
• Bestem Defekt trackonge og rapportering og deres riktige kartping med kravene.

Testtilfelle for stabilitetstesting for CPU-ytelse

• For å verifisere øvre grense for systemet.
• Hvordan systemet krasjer eller gjenoppretter.
• Et totalt antall fullførte transaksjoner per forespørsel.
• Hvorvidt transaksjonsresponsen holder seg stabil eller øker over tid.
• Hvordan systemet oppfører seg under stor belastning.
• Dens respons og oppførsel under tung belastning.

Testrapporter for stabilitetstesting

Flere statistikker samles inn og måles under testutførelser; disse tallene analyseres for å generere en rapport og identifisere mulige ytelsesproblemer.

Eksempler på statistikk samlet inn under test er:

• Transaksjonsresponstider: Gjennomsnittlig tid det tar å utføre transaksjoner under testen. Denne statistikken vil evaluere om ytelsen til serveren er innenfor de akseptable minimums- og maksimumsperiodene for transaksjonsytelse som er definert for systemet. Denne informasjonen vil evaluere tiden det tar å behandle forespørselen av webserveren og sendes til applikasjonsserveren, som i de fleste tilfellene vil sende en forespørsel til en databaseserver.
• Treff per sekund: Antall treff gjort på serveren av brukere. Denne statistikken er nyttig for å bestemme antall belastninger som brukere genererer, med hensyn til et antall treff.
• gjennomløp: Mengden gjennomstrømning på webserveren under testen som måles i byte. Gjennomstrømming betyr mengden data som brukerne mottok fra serveren til enhver tid. Denne statistikken hjelper til med å evaluere mengden belastning brukerne genererer.
• Transaksjon per sekund: Dette er det totale antallet fullførte transaksjoner (både vellykkede og mislykkede) utført under en test. Denne statistikken hjelper til med å kontrollere den faktiske transaksjonsbelastningen på systemet.
• CPU: CPU prosentvis utnyttelse brukt under en test.
• Minne: Minnebruk under en test.
• Disk: utnyttelse av diskplass brukt under en test.

Grunnleggende om stabilitetstesting

Stabilitetstesting kommer under ytelsestesting – en teknikk som utføres for å sjekke noen av kvalitetsattributtene til programvare som stabilitet, pålitelighet og tilgjengelighet.

Denne testen brukes til å bestemme hvor raskt et system eller delsystem yter under en bestemt arbeidsbelastning.

Ytelsestesting har mange typer og stabilitetstesting er en av dem.

• Stresstesting: Det er en testtype som sjekker robustheten til systemet utover systemkapasiteten.
• Piggtesting: Den brukes til å sjekke oppførselen til et system ved å øke belastningen på et system umiddelbart. Målet er å sjekke på hvilket tidspunkt systemet vil ha ytelsesproblemer, eller det vil passere.
• Skalerbarhetstesting: Den brukes til å sjekke funksjonene til et system. Hvor effektivt systemet vil oppføre seg i økende behov, endring i størrelse og endring i volum.
• Volumtesting: Det er en ikke-funksjonell testteknikk der programvare som testes blir utsatt for et stort datavolum, og oppførselen til et system blir kontrollert og verifisert deretter.
• Last- eller stabilitetstesting: (allerede diskutert ovenfor)

Verktøy for stabilitetstesting

Noen av verktøyene for ytelsestesting er som –

• WebLOAD
• Loadrunner
• Apache JMeter
• NeoLaste
• CloudTest
• Laststorm
• LoadUI
• WAPT
• LoadImpact
• Lastemaskin
• Httperf
• OpenSTA

Hvordan denne testen passer inn i ytelsestestingfamilien

Ytelsestesting er en paraplybetegnelse. Variantene nedenfor skiller seg bare i formen på den påførte belastningen og varigheten den holdes i, og det er derfor de så ofte forveksles med hverandre.

Testtype	Lastemønster	Spørsmål den svarer
Lasttesting	Forventet toppbelastning, kort varighet	Oppfyller systemet målene sine under normal trafikktopp?
Stresstesting	Økte utover kapasiteten inntil feil	Hvor ryker den, og svikter den grasiøst?
Piggtesting	Plutselig ekstrem bølge, deretter tilbaketrekning	Overlever og kommer den seg etter et trafikksjokk?
Utholdenhetstesting	Normal belastning holdt i mange timer	Forringes ytelsen over tid?
Bløtleggingstesting	Vedvarende belastning over lengre tid	Er det minnelekkasjer eller ressursutmattelse?
Stabilitetstesting	Varierende belastning underveis	Forblir systemet pålitelig selv om forholdene endrer seg?
Volumtesting	Vanlige brukere, veldig stort datavolum	Takler den når databasen vokser?

Utholdenhetstesting og gjennomvåtningstesting blir ofte behandlet som synonymer. Vanligvis brukes de slik: begge holder en vedvarende belastning over lengre tid. Der team skiller dem fra hverandre, fokuserer utholdenhetstesting på om responstidene stiger, mens soak-testing fokuserer på ressursforbruk som minne, filhåndtak og tilkoblingspooler. Å kjøre én gir deg vanligvis bevis for begge.

Viktige målinger å fange opp under testen

En ytelsesbasert kjøring er bare så god som det du registrerer mens den kjører. Registrer disse seks på server- og klientsiden, og sammenlign dem deretter med grunnlinjen i stedet for mot en magefølelse.

Metric	Hva det forteller deg	Advarselsskilt
Gjennomsnittlig responstid	Typisk brukeropplevelse	Enhver oppadgående drift over løypa
95. persentil responstid	Opplevelsen til de tregeste brukerne	Langt over gjennomsnittet, noe som betyr inkonsekvens
gjennomstrømming	Forespørsler behandlet per sekund	Faller mens belastningen forblir konstant
Feilrate	Andel mislykkede eller tidsavbrutt forespørsler	Enhver økning over den avtalte terskelen
CPU- og minnebruk	Serverressurskapasitet	Minne som klatrer og aldri kommer tilbake
Databasetilkoblinger og tråder	Utmattelse av bassenget	Antall som vokser jevnt uten utgivelse

Les gjennomsnittet og persentilen sammen. Et gjennomsnitt på 800 ms med en 95. persentil på 900 ms beskriver et konsistent system. Det samme gjennomsnittet med en 95. persentil på 9 sekunder betyr at én av tjue brukere har det dårlig, og gjennomsnittet skjuler det.

Se på formen, ikke bare verdien. I enhver langvarig test er en flat ressurslinje et bestått resultat og en stigende en er en lekkasje, selv når det absolutte tallet fortsatt er komfortabelt innenfor grensen i det øyeblikket kjøringen avsluttes.

Spørsmål og svar