stability testing software testing
Stabilitetstesting er en del av ytelsestesting. Denne opplæringen forklarer målene, viktigheten og behovet for stabilitetstesting med eksempler:
Stabilitetstesting er 'ikke-funksjonell' testing. Her tester ikke teamets funksjoner og grunnleggende funksjonalitet på nettstedet; men tester funksjonene til programvareproduktet som 'robusthet', 'feilhåndtering', 'pålitelighet' og produktstabilitet '.
La oss vurdere en person som kjøper et nytt produkt fra markedet ( For eksempel, en mobiltelefon). Kjøperen vil forvente at produktet skal yte jevnt i lang tid, uten feil. Tilsvarende vil brukere av nettstedet og mobilappen forvente at det tilhørende nettstedet eller mobilappene vil prestere med høy pålitelighet og stabilitet.
Ta nå saken om brukere som prøver å kjøpe varer fra e-handelsportaler. Hvis et stort antall brukere bruker samme portal samtidig, er sjansen for ytelsesforringelse for nettstedet stor. Brukerne kan også oppleve en treg responstid eller til og med minnelekkasje under økten.
Disse problemene gir trusler mot både utviklere og interessenter. Det er testteamets ansvar å finne disse problemene og rapportere til utviklingsteamet før det når sluttbrukerne. Denne typen testing vil bli testet. Stabilitetstesting er en del av ytelsestesting.
Hva du vil lære:
Oversikt over stabilitetstesting
Som nevnt tidligere er også stabilitetstesting definert som 'ikke-funksjonell' testing. Her kontrollerer testteamene robustheten, feilhåndteringen, påliteligheten og produktstabiliteten.
Denne testen kalles også 'Endurance Testing' eller 'Soak Testing'. Det er også kjent som 'Extreme Load Testing'.
I denne typen tester vil testere sjekke hvordan nettportalen reagerer når mange aktive brukere bruker nettstedet samtidig. Testere må også sjekke systemresponsen i et slikt miljø.
Ved mange anledninger må nettsteder kjøre kontinuerlig i flere uker (til og med måneder) uten muligheten til å starte serveren på nytt. Aktive brukere for slike nettsteder (brukere som bruker nettstedet for øyeblikket) kan være enorme, og hver bruker vil forvente en sømløs ytelse.
Testernes rolle er å gi tillit til utviklerne og sikre sluttbrukerne at de kan bruke et system som innrykket, uten feil eller minnelekkasje selv i høy trafikk. For dette formålet utsettes applikasjonen for maksimal belastning (til applikasjonens bruddpunkt) og systemets oppførsel blir sjekket under slike forhold.
Denne testingen blir vanligvis gjort før utgivelsen av programvaren. Testere må sørge for at applikasjonen er i stand til å håndtere den forventede belastningen til nettstedet. Noen ganger kan systemet krasje på grunn av tung belastning eller kan bli tregt eller til og med vise uventet oppførsel.
Programvarestabilitet avhenger i høy grad av sømløs ytelse til systemet under de ovennevnte stressende forholdene. Så, stabilitetstesting spiller en veldig viktig rolle.
Mål for stabilitetstesting
Målene er oppført nedenfor:
- For å finne holdbarheten til systemet.
- Finn stabiliteten i applikasjonen og øk dermed tilliten til utvikleren.
- Finn feilen i systemet i et stressende miljø.
- Samlet evaluering og effektivitet av produktet.
- For å sikre at systemet kan håndtere et stort program.
- For å teste responstiden for en søknad.
- For å sjekke databasetilkoblingen.
Fakta om stabilitetstesting
Noen nyttige fakta er vervet nedenfor:
- Stabilitetstesting krever et passende testmiljø.
- For å få bedre resultater, trenger stabilitetstesting en godt planlagt og strukturert tilnærming.
- Det er en tidkrevende prosess. Tiden det tar for testprosessen kan variere avhengig av kundens krav, type produkt og selskapets retningslinjer.
- Isolering av systemet er viktig i denne formen for testing. Mens du gjør stabilitetstesting av applikasjonen, er det sjanser for at data permanent går tapt eller blir ødelagt.
- Utholdenhetstesting kan forårsake feil på applikasjonskomponenter, slik at sluttbrukere kan observere unbehandlede unntak.
Forskjellen mellom stabilitet og pålitelighet i programvaresystemet
Det er en betydelig forskjell mellom pålitelighet og stabilitet i et program. Dette kan forklares ved hjelp av et eksempel.
Eksempel:
Tenk på at en bruker installerte en ny app på hans / hennes mobiltelefon og lanserte den. Hvis applikasjonen som er installert krasjer etter hvert 3. minutters bruk, vil det absolutt irritere brukeren. Men hvis brukeren kan gjenopprette dataene uten tap etter at appen er startet på nytt, mister ikke applikasjonen påliteligheten. En slik applikasjon kan betraktes som pålitelig, men kan ikke betraktes som stabil.
konvertere char * til int c ++
På den annen side, ta scenariet der applikasjonsdataene ikke blir lagret ordentlig. Her fungerer applikasjonen bra og krasjer ikke (som hvert 3. minutt). En slik applikasjon kan være eller kan ikke betraktes som pålitelig, men kan betraktes som 'stabil'.
Pålitelighet og stabilitet er som to sider av samme mynt. Så bare husk det faktum at både pålitelighet og stabilitet er viktig for et produkt fra et forretningsperspektiv.
Eksempler på stabilitetstesting:
Det er en vanlig tilnærming at når en bruker kjøper en ny mobiltelefon, utfører han / hun bevisst eller uvitende en stabilitetstest. Brukeren vil lagre mange bilder, bilder, videoer, dokumenter osv. I enhetens minne, og de vil sjekke om for mange lagrede data har påvirket ytelsen til enheten eller ikke. Dette er et spesielt eksempel på stabilitetstesting.
På grunn av enorme data som er lagret, kan enheten vår legge på noen ganger, da må brukeren slette noen data eller fjerne midlertidige filer for å få enheten til å gjenopprette ytelsen. Etter denne testingen vil brukeren ha en klar ide om kapasiteten til systemet.
Et annet sanntidseksempel er online-portaler. I løpet av en 'salg / festival' sesong kjøper mange varer fra denne typen nettportaler. Ytelsen til et nettsted må tilfredsstille brukerens forventninger.
Så testerne må teste nettstedet ved å huske på det forventede “rush” som sannsynligvis vil skje på disse nettstedene i løpet av de dagene.
Stabilitetstesting av en internettforbindelse
Her vil testsaken være å verifisere hvor stabil internettforbindelsen vår er. Mens brukerne oppretter en forbindelse og ber om websider, på grunn av pakketap, må brukerne lide inkonsekvent forsinkelse når de viser websider.
Noen ganger oppstår pakketap når det ikke når målet. Det er på grunn av pakketap at mange av oss kan ha kommet over lignende problemer mens vi bruker Skype-videosamtaler, spiller spill over internett eller blir tilfeldig koblet fra internett.
Forutsetninger for å teste internettforbindelse:
- For å teste internettstabiliteten, må vi ha en nettleser der brannmuren er deaktivert.
- Velg en nettadresse ( For eksempel, https://www.google.com/ ) som neppe vil mislykkes.
- Bruk Google Regneark eller Microsoft Excel til å registrere resultatet, siden det er lett å forstå og mer lesbart for brukerne.
- Dobbeltsjekk internettforbindelsen, enhetene og sjekk tilkoblingene igjen. Vi vil deretter utføre de nevnte testene.
Metoder som brukes for å teste internettforbindelse:
Den beste måten å teste tilkobling på er å besøke Fartstest (før du leser videre, besøk nettstedet). I SpeedTest.net har vi en bestemmelse for valg av servere. Velg og kjør serveren som er i nærheten av deg.
Etter det vil nettstedet utføre noen beregninger basert på noen forhåndsdefinerte algoritmer og vise rapporten som avgjør kvaliteten på internettforbindelsen vår umiddelbart. I rapporten er pakketapsprosenten inkludert. Det skal være '0%'.
'0%' pakketap bestemmer forbindelsens høye stabilitet. Ethvert tall som er større enn ‘0’ viser at tilkoblingen er ustabil.
Den andre måten er å bruke 'cmd' ledetekst og skriv inn kommandoen 'ping' (se figuren nedenfor). Her, ved å bruke ledeteksten, kan vi også teste internettets stabilitet og ventetid i sanntid.
I figuren, vennligst sjekk 'Ping Statistics' -delen.
Her,
Antall sendte pakker = 4
Antall pakker mottatt = 4
Antall tapte pakker = 0
Resultatet viser at forbindelsen er svært stabil.
Prosess brukt:
Trinn 1: Testere velger en av de to metodene som er forklart ovenfor.
Steg 2: Testere vil kjøre prosessen og registrere nødvendig informasjon som er innhentet som et svar på internettforbindelse, i et regneark.
Trinn 3: De vil gjenta prosessen tre eller fire ganger i uken.
(Siden stabilitetstesting utføres over en periode, må testere planlegge prosessen minst mer enn to ganger i uken.)
Trinn 4: Resultatene blir registrert i regneark.
Testere må notere datoen for kjøring av prosessen. Sammenlign resultatet oppnådd på hver dato for å få en ide om stabiliteten i vårt nåværende nettverk.
Merk: Brytpunkt er tilstanden til systemet der systemet vil kollapse når ytterligere belastning blir gitt til det. Den definerer systemets kapasitet.
Spesifikasjonsdokumentet er et dokument gitt til testerne av teamlederen og vil inneholde detaljer om forventet belastning i systemet. I stabilitetstesting vil testerne sjekke systemets brytpunkt basert på retningslinjene gitt i spesifikasjonsdokumentet.
Testteamet vil sjekke systemet ved å teste applikasjonen med belastningen over / under brytpunktet spesifisert i spesifikasjonsdokumentet. Dette er forskjellig fra tilfellet Load Testing.
hva er sikkerhetsnøkkelen på en ruter
I stabilitetstesting bruker vi bare forventet belastning for testing, men i belastningstesting blir applikasjonen gitt en uventet belastning, og testere sjekker kapasiteten til applikasjonen.
Programvaretesting av livssyklus basert på stabilitetstesting
De forskjellige fasene av Programvare Testing livssyklus er vervet nedenfor:
- Kravsanalyse
- Testplan
- Test Case Development
- Test miljøoppsett
- Test Saksutførelse
- Test lukking
La oss forstå alle ovennevnte faser i detalj.
# 1) Kravsanalyse
I denne fasen vil testteamet bestemme de forskjellige typene testing som skal utføres i applikasjonen. Det avhenger rent av klientkrav og type applikasjon. For eksempel, testerne tester en banksøknad, så er den mest prioriterte testen, i dette tilfellet, sikkerhetstesting. Hvis testerne tester en eiendomssøknad, vil de prioritere funksjonstesting.
# 2) Testplanlegging
I denne fasen blir testomfang diskutert. Testere vil diskutere behovet for automatisering. For stabilitetstesting er testprosessene kjedelige og må gjentas mange ganger over en viss varighet, automatisering vil være et godt valg. ‘LoadStrom’ er et godt verktøy for å utføre stabilitetstesting ved hjelp av automatisering.
I denne fasen vil vi diskutere budsjett og tidsfrist for testing med klienten. Siden testingen er tidkrevende, bør budsjettet og tidsfristen oppfylle testplanen.
# 3) Testutvikling
Test case for testing av applikasjonen er opprettet i denne fasen.
# 4) Testmiljø
Testmiljøet er en viktig faktor for å teste stabilitet. Vi trenger et skikkelig testmiljø som er kopien av vårt produksjonsmiljø. Det opprinnelige miljøet bør være ubrukt fordi nettstedet noen ganger kan krasje eller til og med datatap under testingen.
# 5) Testutførelse
I denne fasen blir testtilfeller utført og testresultatene bekreftet. Dette er en tidkrevende fase. De generelle problemene som testere står overfor i denne fasen er minnelekkasje, problemer med datatilkobling, treg responstid osv.
# 6) Testlukking
I denne fasen vil alle teammedlemmene møte og diskutere utgangskriteriene som brukes i prosjektet. Utgangskriterier avhenger av faktorer som antall funnet feil og tiden brukt i testingen.
Verktøy brukt i stabilitetstesting
Følgende verktøy brukes:
- LoadRunner
- OpenSTA
- LoadUI
- WebLOAD
- LoadComplete
- Fremgang
- LoadUI
- Rasjonell ytelsestester
Hvordan bruke Apache JMeter for utholdenhetstesting?
Apache JMeter er et godt verktøy for utholdenhetstesting. Før testene starter, må testere ha god kunnskap om forretningsmålene. Etter det vil testere lage testskripter. Deretter konfigurerer vi trådgruppinnstillingene i JMeter.
Mens vi gjør utholdenhetstesting med JMeter, må vi spesifisere følgende faktorer:
qa ingeniørintervju spørsmål og svar
- Antall tråder: Dette indikerer forventet antall brukere på nettstedet.
- Oppkjøringsperiode: Dette indikerer tiden det tar hver tråd å fullføre. Hvis vi har 5 tråder, er oppstartsperioden 50 sekunder.
- Loop-count: Dette indikerer antall ganger prosessen gjentas. For utholdenhetstesting er det satt til evig tid.
- Planlegger: I denne testen vil vi bruke planleggingsfunksjonalitet. Vi må spesifisere planleggerkonfigurasjonen i henhold til kravet.
Konklusjon
Mange applikasjoner er feil designet og frigjør ikke enhetsminnet etter bruk. Dette vil gradvis føre til hukommelsestap. Vi kan løse problemet med stabilitetstesting. Så stabilitetstesting er veldig viktig. Det er ikke-funksjonell testing. Det er bare opptatt av egenskapene til applikasjonen. Her handler ikke testing om oppførselen til systemet.
Håper du forsto viktigheten og behovet for stabilitetstesting.
Anbefalt lesing
- Programvaretesting QA Assistant Job
- Programvare Testing Course: Hvilket programvare Testing Institute skal jeg delta?
- Programvaretesting Teknisk innhold Writer Freelancer Jobb
- Velge programvaretesting som din karriere
- Råd om programvaretesting for nybegynnere
- Programvaretestkurs Tilbakemelding og anmeldelser
- Hvordan holder jeg motivasjonen levende i programvaretestere?
- Hva er Monkey Testing i Software Testing?