Hvad er systemtest - en ultimativ nybegyndervejledning

what is system testing ultimate beginner s guide

Hvad er systemtest i softwaretest?

Systemtest betyder at teste systemet som helhed. Alle moduler / komponenter er integreret for at kontrollere, om systemet fungerer som forventet eller ej.

Systemtest udføres efter integrationstest. Dette spiller en vigtig rolle i leveringen af ​​et produkt af høj kvalitet.

Liste over selvstudier:

• Hvad er systemtest
• System vs ende til slut test

Processen med at teste et integreret hardware- og softwaresystem for at kontrollere, at systemet opfylder de specificerede krav.

Verifikation : Bekræftelse ved undersøgelse og bestemmelse af objektiv dokumentation for, at specificerede krav er opfyldt.

Hvis en applikation har tre moduler A, B og C, kaldes test udført ved at kombinere modulerne A & B eller modul B & C eller modul A & C som Integration-test. Integration af alle de tre moduler og testning af det som et komplet system kaldes Systemtest.

Hvad du lærer:

• Min erfaring
  • Eksempel på systemtest
• Nærme sig
• Hvorfor systemtest?
• Er dette en hvid-boks eller sort-boks test?
• Sådan udføres systemtest?
  • Hvad skal jeg teste?
• Fordele
• Indgangs- / udgangskriterier
• Systemtestplan
• Fremgangsmåde til at skrive systemtesttilfælde
• Systemtest tilfælde
• Typer af systemtest
  • Flere systemtesttyper
• Hvad er systemintegrationstest?
• Forskellen mellem system- og accepttest
• Tip til at udføre systemtesten
• Konklusion
• Anbefalet læsning

Min erfaring

Så ... tror du virkelig, det vil tage den enorme tid at teste, hvad du kalder Systemtest , selv efter at have brugt en masse kræfter på Integration Testing?

Den klient, vi for nylig henvendte os til for projektet, var ikke overbevist om det skøn, vi gav for hver testindsats.

Jeg måtte chime ind med et eksempel:

Mike, jeg vil gerne uddybe vores indsats og vigtigheden af ​​systemtest med et eksempel.

Skyd, svarede han.

Eksempel på systemtest

En bilproducent producerer ikke bilen som en hel bil. Hver komponent i bilen er fremstillet separat, som sæder, styring, spejl, brud, kabel, motor, bilramme, hjul osv.

Efter fremstilling af hver vare testes den uafhængigt, om den fungerer, som den skal fungere, og det kaldes enhedstest.

selenium test interview spørgsmål og svar

Når hver del nu samles med en anden del, kontrolleres den samlede kombination, hvis samlingen ikke har produceret nogen bivirkning for hver komponents funktionalitet, og om begge komponenter arbejder sammen som forventet, og det kaldes integrationstest.

Når alle dele er samlet, og bilen er klar, er den faktisk ikke klar.

Hele bilen skal kontrolleres for forskellige aspekter i henhold til kravene defineret som hvis bilen kan køres jævnt, går i stykker, gear og anden funktionalitet fungerer korrekt, bilen viser ikke noget tegn på træthed efter at have været kørt i 2500 miles kontinuerligt, farve af bil er generelt accepteret og ønsket, bil kan køres på alle slags veje som glat og ru, sjusket og lige osv. og hele denne testindsats kaldes System Testing og det har intet at gøre med integrationstest.

Eksemplet fungerede som forventet, og klienten var overbevist om den krævede indsats for systemtesten.

Jeg fortæller eksemplet her for at tilskynde vigtigheden af ​​denne test.

Nærme sig

Det udføres, når Integration Testing er afsluttet.

Det er hovedsageligt en sort-boks type test. Denne test evaluerer systemets funktion ud fra et brugerperspektiv ved hjælp af et specifikationsdokument. Det kræver ingen intern viden om systemer som kodens design eller struktur.

Den indeholder funktionelle og ikke-funktionelle anvendelsesområder / produkt.

Fokuskriterier:

Det fokuserer primært på følgende:

1. Eksterne grænseflader
2. Multiprogram og komplekse funktionaliteter
3. Sikkerhed
4. Genopretning
5. Ydeevne
6. Operatør og brugerens glatte interaktion med systemet
7. Installationsevne
8. Dokumentation
9. Anvendelighed
10. Belastning / stress

Hvorfor systemtest?

# 1) Det er meget vigtigt at gennemføre en fuld testcyklus, og ST er det stadium, hvor det gøres.

#to) ST udføres i et miljø, der ligner produktionsmiljøet, og derfor kan interessenter få en god idé om brugerens reaktion.

# 3) Det hjælper med at minimere fejlfinding efter installation og supportopkald.

# 4 ) I dette STLC-trin er applikationsarkitektur og forretningskrav testet.

Denne test er meget vigtig, og den spiller en væsentlig rolle i leveringen af ​​et kvalitetsprodukt til kunden.

Lad os se vigtigheden af ​​denne test gennem nedenstående eksempler, der inkluderer vores daglige opgaver:

• Hvad hvis en onlinetransaktion mislykkes efter bekræftelse?
• Hvad hvis en vare placeret i en vogn på et online-websted ikke tillader at afgive en ordre?
• Hvad hvis der i en Gmail-konto oprettes en ny etiket, der giver en fejl ved at klikke på fanen Opret?
• Hvad hvis systemet går ned, når en belastning øges på systemet?
• Hvad hvis systemet går ned og ikke er i stand til at gendanne dataene som ønsket?
• Hvad hvis installation af software på systemet tager meget mere tid end forventet og i slutningen giver en fejl?
• Hvad hvis en websides responstid øges meget mere end forventet efter forbedring?
• Hvad hvis et websted bliver for langsomt til, at brugeren ikke er i stand til at booke sin rejsebillet?

Ovenstående er blot nogle få eksempler, der viser, hvordan systemtest vil påvirke, hvis det ikke udføres korrekt.

Alle ovenstående eksempler er kun resultatet af enten systemtest, der ikke er udført eller ikke udført korrekt. Alle de integrerede moduler skal testes for at sikre, at produktet fungerer efter kravene.

Er dette en hvid-boks eller sort-boks test?

Systemtest kan betragtes som en sort-boks testteknik.

Test af sort boks teknik kræver ikke intern viden om koden, mens den hvide boks-teknik kræver intern viden om koden.

Under udførelse af systemtest funktionel og ikke-funktionel dækkes sikkerhed, ydeevne og mange andre testtyper, og de testes ved hjælp af en sort boks-teknik, hvor input leveres til systemet, og output verificeres. Systemets interne viden er ikke påkrævet.

Black Box-teknik:

Sådan udføres systemtest?

Det er dybest set en del af softwaretest, og testplanen skal altid indeholde specifik plads til denne test.

For at teste systemet som helhed skal krav og forventninger være klare, og testeren skal også forstå applikationens realtidsbrug.

De mest anvendte tredjepartsværktøjer, versioner af operativsystemer, varianter og arkitektur af operativsystemer kan også påvirke systemets funktionalitet, ydeevne, sikkerhed, gendannelse eller installationsbarhed.

Derfor, mens du tester systemet, kan et klart billede af, hvordan applikationen skal bruges, og hvilken slags problemer det kan stå over for i realtid være nyttigt. Derudover er et kravsdokument lige så vigtigt som at forstå applikationen.

Et klart og opdateret kravsdokument kan gemme testeren fra en række misforståelser, antagelser og spørgsmål.

Kort sagt kan et spidst og skarpt kravsdokument med de nyeste opdateringer sammen med en forståelse af applikationsanvendelse i realtid gøre ST mere frugtbart.

Denne test udføres på en planlagt og systematisk måde.

Nedenfor er de forskellige trin involveret under udførelsen af ​​denne test:

• Det allerførste trin er at oprette en testplan.
• Opret systemtestsager og testskripter.
• Forbered de testdata, der kræves til denne test.
• Udfør systemtestsagerne og scriptet.
• Rapporter bugs. Gentest af fejlene, når de er rettet.
• Regressionstest for at kontrollere virkningen af ​​ændringen i koden.
• Gentagelse af testcyklussen, indtil systemet er klar til at blive implementeret.
• Log af fra testteamet.

Hvad skal jeg teste?

Nedenstående punkter er dækket af denne test:

• Test til ende til slut som inkluderer kontrol af interaktionen mellem alle komponenterne og sammen med de eksterne perifere enheder for at sikre, om systemet fungerer fint i et af scenarierne, er omfattet af denne test.
• Det verificerer, at den input, der leveres til systemet, giver det forventede resultat.
• Det verificerer, om alle funktionelle og ikke-funktionelle krav er testet, og om de fungerer som forventet eller ej.
• Til dette og udforskende test kan udføres i denne test, efter at script-test er afsluttet. Undersøgende test og ad-hoc-test hjælper med at udfolde de fejl, som ikke kan findes i script-test, da det giver testere frihed til at teste, da deres ønske er baseret på deres erfaring og intuition.

Fordele

Der er flere fordele:

• Denne test inkluderer slut-til-slut-scenarier for at teste systemet.
• Denne test udføres i samme miljø som i produktionsmiljøet, som hjælper med at forstå brugerperspektivet og forhindrer de problemer, der kan opstå, når systemet tændes.
• Hvis denne test udføres på en systematisk og korrekt måde, ville det hjælpe med at afbøde problemerne efter produktion.
• Denne test tester både applikationsarkitektur og forretningskrav.

Indgangs- / udgangskriterier

Lad os se nærmere på indgangs- / udgangskriterierne for systemtest.

Indgangskriterier:

• Systemet skulle have bestået udgangskriterierne for integrationstest, dvs. alle testsagerne skulle have været udført, og der skulle ikke være nogen kritisk prioritet eller P1, en P2-fejl i åben tilstand.
• Testplan til denne test skal godkendes og underskrives.
• Testcases / scenarier skal være klar til at blive udført.
• Testskripter skal være klar til at blive udført.
• Alle ikke-funktionelle krav skulle være tilgængelige, og der skulle være oprettet testcases for det samme.
• Testmiljøet skal være klar.

Udgangskriterier:

• Alle testsagerne skal udføres.
• Ingen kritiske eller prioriterede eller sikkerhedsrelaterede fejl skal være i åben tilstand.
• Hvis fejl i mellemstor eller lav prioritet er i åben tilstand, skal de implementeres med accept fra kunden.
• Afslutningsrapport skal indsendes.

Systemtestplan

Testplan er et dokument, der bruges til at beskrive formålet, målet og omfanget af et produkt, der skal udvikles. Hvad der skal testes, og hvad der ikke skal testes, teststrategier, værktøjer, der skal bruges, krævet miljø og alle andre detaljer er dokumenteret for at gå videre med testen.

Testplanen hjælper med at fortsætte med test på en meget systematisk og strategisk måde, og det hjælper med at undgå risici eller problemer, mens testen er færdig.

Systemtestplan dækker følgende punkter:

• Formål og mål defineres til denne test.
• Omfang (Funktioner, der skal testes, Funktioner, der ikke skal testes, er angivet).
• Testacceptkriterier (Kriterier, som systemet accepteres, dvs. nævnte punkter i acceptkriterier skal være i godkendt tilstand).
• Indgangs- / udgangskriterier (Definerer kriterierne, når systemtest skal starte, og hvornår det skal betragtes som komplet).
• Testplan (estimering af test, der skal udføres på et bestemt tidspunkt).
• Teststrategi (Inkluderer testteknikker).
• Ressourcer (antal krævede ressourcer til testning, deres roller, ressourcetilgængelighed osv.).
• Testmiljø (operativsystem, browser, platform).
• Test tilfælde (Liste over testsager, der skal udføres).
• Antagelser (hvis der er antagelser, skal de medtages i testplanen).

Fremgangsmåde til at skrive systemtesttilfælde

Systemtestsager dækker alle scenarier og brugssager, og det dækker også funktionelle, ikke-funktionelle, brugergrænseflade, sikkerhedsrelaterede testsager. Testcases er skrevet på samme måde som de er skrevet til funktionel test.

Systemtest tilfælde inkluderer nedenstående felter i skabelonen:

• Test sag-id
• Test Suite navn
• Beskrivelse - Beskriver den testsag, der skal udføres.
• Trin - Trin for trin procedure for at beskrive, hvordan man udfører test.
• Testdata - Dummy-data forberedes til at teste applikationen.
• Forventet resultat - Forventet resultat i henhold til kravdokumentet findes i denne kolonne.
• Faktisk resultat - Resultat efter udførelse af testsagen er angivet i denne kolonne.
• Bestået / ikke bestået - Sammenligning i faktisk og forventet resultat definerer bestået / ikke bestået kriterier.
• Bemærkninger

Systemtest tilfælde

Her er nogle eksempler på testscenarier for et e-handelswebsted:

1. Hvis webstedet starter korrekt med alle de relevante sider, funktioner og logo
2. Hvis brugeren kan registrere / logge ind på siden
3. Hvis brugeren kan se tilgængelige produkter, kan han tilføje produkter til sin indkøbskurv, kan betale og kan få bekræftelsen via e-mail eller SMS eller ringe.
4. Hvis de vigtigste funktioner som søgning, filtrering, sortering, tilføjelse, ændring, ønskeliste osv. Fungerer som forventet
5. Hvis antallet af brugere (defineret som i kravdokument) kan få adgang til webstedet samtidigt
6. Hvis webstedet starter korrekt i alle større browsere og deres nyeste versioner
7. Hvis transaktionerne udføres på webstedet via en bestemt bruger, er de sikre nok
8. Hvis webstedet starter korrekt på alle understøttede platforme som Windows, Linux, Mobile osv.
9. Hvis returvejledningen til brugervejledningen / vejledningen, fortrolighedspolitik og vilkår for brug af webstedet er tilgængelige som et separat dokument og nyttigt for enhver nybegynder eller første gangs bruger.
10. Hvis indholdet på siderne er korrekt justeret, styres godt og uden stavefejl.
11. Hvis sessionstimeout implementeres og fungerer som forventet
12. Hvis en bruger er tilfreds efter at have brugt webstedet eller med andre ord, finder brugeren det ikke vanskeligt at bruge webstedet.

Typer af systemtest

ST kaldes et supersæt af alle typer test, da alle hovedtyper af test er dækket af det. Selvom fokus på typer af test kan variere på basis af produkt, organisationsprocesser, tidslinje og krav.

Samlet set kan det defineres som nedenfor:

Funktionstest: For at sikre, at produktets funktionalitet fungerer i henhold til de definerede krav inden for systemets muligheder.

Test af gendannelsesevne: For at sikre, hvor godt systemet kommer sig fra forskellige inputfejl og andre fejlsituationer.

Interoperabilitetstest: For at sikre, om systemet kan fungere godt med tredjepartsprodukter eller ej.

Ydeevne test: For at sikre systemets ydeevne under forskellige forhold med hensyn til ydeevneegenskaber.

Test af skalerbarhed: For at sikre systemets skaleringsegenskaber i forskellige termer som bruger skalering, geografisk skalering og ressource skalering.

Pålidelighedstest: For at sikre, at systemet kan betjenes i længere tid uden at udvikle fejl.

Regressionstest: For at sikre systemets stabilitet, når det passerer gennem integration af forskellige undersystemer og vedligeholdelsesopgaver.

Dokumentationstest: For at sikre, at systemets brugervejledning og andre dokumenter om hjælpemner er korrekte og anvendelige.

Sikkerhedstest: For at sikre, at systemet ikke tillader uautoriseret adgang til data og ressourcer.

Brugervenlighedstest : For at sikre, at systemet er let at bruge, skal du lære og betjene det.

Flere systemtesttyper

# 1) Grafisk brugergrænseflatestestning (GUI):

GUI-test udføres for at kontrollere, om et systems GUI fungerer som forventet eller ej. GUI er dybest set det, der er synligt for en bruger, mens han bruger applikationen. GUI-test involverer testknapper, ikoner, afkrydsningsfelter, listefelt, tekstboks, menuer, værktøjslinjer, dialogbokse osv.

# 2) Kompatibilitetstest:

Kompatibilitetstest gøres for at sikre, at det udviklede produkt er kompatibelt med forskellige browsere, hardwareplatforme, operativsystem og databaser i henhold til kravdokumentet.

# 3) Undtagelseshåndtering:

Undtagelseshåndteringstest udføres for at kontrollere, at selvom der opstår en uventet fejl i produktet, skal den vise den korrekte fejlmeddelelse og ikke lade applikationen stoppe. Det håndterer undtagelsen på en måde, så fejlen vises, mens produktet gendannes og tillader systemet at behandle den forkerte transaktion.

# 4) Volumenprøvning:

Volume Testing er en type ikke-funktionel test, hvor test udføres ved hjælp af en enorm mængde data. For eksempel, datamængden øges i databasen for at kontrollere systemets ydeevne.

# 5) Stresstest:

Stresstest udføres ved at øge antallet af brugere (på samme tid) på en applikation i et omfang, som applikationen går i stykker. Dette gøres for at verificere det tidspunkt, hvor applikationen nedbrydes.

# 6) Sanity Testing:

Sanity Testing udføres, når build frigives med en ændring i kode eller funktionalitet, eller hvis der er rettet en fejl. Det verificerer, at de udførte ændringer ikke har påvirket koden, og at der ikke er noget andet problem på grund af det, og systemet fungerer som tidligere.

Hvis der opstår et problem, accepteres build ikke til yderligere test.

Grundlæggende udføres der ikke grundig testning af bygningen for at spare tid og omkostninger, da den afviser bygningen for et fundet problem. Sanity-test udføres for den ændrede udførelse eller for det faste problem og ikke for det komplette system.

# 7) Røgtest:

Røgtest er en test, der udføres på buildet for at kontrollere, om buildet kan testes yderligere eller ej. Det verificerer, at bygningen er stabil til at teste, og at alle de kritiske funktioner fungerer fint. Røgtest udføres for det komplette system, dvs. test til slut til slut udføres.

# 8) Undersøgende test:

Undersøgende test som navnet selv antyder, handler det om at udforske applikationen. Ingen scriptet test udføres i sonderende test. Testcases skrives sammen med testningen. Det fokuserer mere på udførelse end planlægning.

Tester har frihed til at teste alene ved hjælp af sin intuition, erfaring og intellekt. En tester kan vælge en hvilken som helst funktion til at teste først, dvs. tilfældigt kan han vælge funktionen til at teste, i modsætning til de andre teknikker, hvor den strukturelle måde bruges til at udføre test.

# 9) Adhoc-test:

Adhoc-test er uformel test, hvor der ikke foretages dokumentation eller planlægning for at teste applikationen. Tester tester applikationen uden testtilfælde. Målet med en tester er at bryde applikationen. Testeren bruger sin erfaring, gæt og intuition til at finde de kritiske problemer i applikationen.

# 10) Installationstest:

Installationstest er at kontrollere, om softwaren bliver installeret uden problemer.

Dette er den vigtigste del af testningen, da installationen af ​​softwaren er den allerførste interaktion mellem brugeren og produktet. Typen af ​​installationstest afhænger af forskellige faktorer som operativsystem, platform, distribution af software osv.

Test tilfælde, der kan medtages, hvis en installation udføres via internettet:

• Dårlig netværkshastighed og brudt forbindelse.
• Firewall og sikkerhedsrelateret.
• Størrelse og omtrentlig tid er taget.
• Samtidig installation / downloads.
• Utilstrækkelig hukommelse
• Utilstrækkelig plads
• Afbrudt installation

# 11) Vedligeholdelsestest:

Når produktet er taget i brug, kan problemet opstå i et levende miljø, eller det kan være nødvendigt med en forbedring af produktet.

Produktet har brug for vedligeholdelse, når det er sat i drift, og det er taget hånd om af vedligeholdelsesteamet. Testen udført for eventuelle problemer eller forbedring eller migration til hardwaren falder ind under vedligeholdelsestest.

Hvad er systemintegrationstest?

Det er en type test, hvor systemets evne til at opretholde dataintegritet og drift i koordination med andre systemer i samme miljø kontrolleres.

Eksempel på systemintegrationstest:

Lad os tage eksemplet på et velkendt online-billetreservationssite - http://irctc.co.in.

Dette er en billetbestillingsfacilitet; en online shoppingfacilitet interagerer med PayPal. Samlet set kan du betragte det som A * B * C = R.

Nu på systemniveau kan online billetreservationsfacilitet, online shoppingfacilitet og online betalingsmulighedsfacilitet testes system uafhængigt efterfulgt af check udføre Integrationstests for hver af dem. Og så skal hele systemet testes systematisk.

Så hvor kommer systemintegrationstest ind i billedet?

Webportalen http://Irctc.co.in er en kombination af systemer. Du kan udføre tests på samme niveau (enkelt system, system af systemer), men på hvert niveau vil du måske fokusere på forskellige risici (integrationsproblemer, uafhængig funktionalitet).

• Mens du tester online billetbestillingsfaciliteten, kan du kontrollere, om du er i stand til at bestille billetter online. Du kan også overveje integrationsproblemer For eksempel, Billetreservationsfacilitet integrerer back-end med front-end (UI). For eksempel, hvordan front-end opfører sig, når databaseserveren reagerer langsomt?
• Test af online billetbestillingsfacilitet med online shoppingfacilitet. Du kan bekræfte, at online-shoppingfaciliteten er tilgængelig for de brugere, der er logget ind i systemet, for at bestille billetter online. Du kan også overveje at verificere integrationen i online shoppingfaciliteten. For eksempel, hvis brugeren er i stand til at vælge og købe et produkt uden besvær.
• Test af online billetreservationsfacilitetens integration med PayPal. Du kan kontrollere, om der efter reservation af billetter blev overført penge fra din PayPal-konto til Online Ticket Booking-kontoen. Du kan også overveje verifikation af integration i PayPal. For eksempel, hvad hvis systemet lægger to poster i en database efter kun debitering af penge en gang?

Forskelmellem systemtest og systemintegrationstest:

Den største forskel er:

• Systemtest tager sig af et enkelt systems integritet med det relevante miljø
• Systemintegrationstest passer på flere systems integritet med hinanden, i det samme miljø.

Således er systemtesten begyndelsen på reel test, hvor du tester et produkt som en helhed og ikke et modul / funktion.

Forskellen mellem system- og accepttest

Nedenfor er de største forskelle:

Tip til at udføre systemtesten

1. Repliker realtidsscenarier snarere end at udføre ideel test, da systemet vil blive brugt af en slutbruger og ikke af den uddannede tester.
2. Bekræft systemets svar i forskellige termer, da mennesket ikke kan lide at vente eller se de forkerte data.
3. Installer og konfigurer systemet i henhold til dokumentationen, fordi det er hvad slutbrugeren skal gøre.
4. At involvere mennesker fra forskellige områder som forretningsanalytikere, udviklere, testere, kunder kan sende et bedre system.
5. Regelmæssig test er den eneste måde at sikre, at den mindste ændring i koden for at rette fejlen ikke har indsat endnu en kritisk fejl i systemet.

Konklusion

Systemtest er meget vigtigt, og hvis det ikke udføres ordentligt, kan kritiske problemer opleves i det levende miljø.

Et system som helhed har forskellige egenskaber, der skal verificeres. Et simpelt eksempel ville være ethvert websted. Hvis det ikke testes som en helhed, kan brugeren muligvis finde ud af, at webstedet er meget langsomt, ellers kan stedet blive styrtet, når et stort antal brugere logger ind på samme tid.

Og disse egenskaber kan ikke testes, før hjemmesiden er testet som en helhed.

Håber, at denne tutorial var meget nyttig til forståelse af begrebet Systemtest.

Anbefalet læsning

• Typer af softwaretest: Forskellige testtyper med detaljer
• Alpha-test og betatestning (En komplet guide)
• Hvad er System Integration Testing (SIT): Lær med eksempler
• Funktionel testning mod ikke-funktionel testning
• Kontinuerlig integrationsproces: Sådan forbedres softwarekvaliteten og reducerer risikoen
• Top 10 værktøjer til integrationstest til at skrive integrationstests
• Hvad er integrationstest (tutorial med integrationstesteksempel)
• Hvad er udholdenhedstest i softwaretest (eksempler)