Hva er systemtesting - en Ultimate Beginner's Guide

what is system testing ultimate beginner s guide

Hva er systemtesting i programvaretesting?

Systemtesting betyr å teste systemet som helhet. Alle modulene / komponentene er integrert for å verifisere om systemet fungerer som forventet eller ikke.

Systemtesting gjøres etter integrasjonstesting. Dette spiller en viktig rolle i å levere et produkt av høy kvalitet.

Liste over opplæringsprogrammer:

• Hva er systemtesting
• System vs ende til slutt testing

Prosessen med å teste et integrert maskinvare- og programvaresystem for å verifisere at systemet oppfyller de spesifiserte kravene.

Bekreftelse : Bekreftelse ved undersøkelse og bestemmelse av objektiv bevis for at spesifiserte krav er oppfylt.

Hvis en applikasjon har tre moduler A, B og C, er testing utført ved å kombinere modulene A & B eller modul B & C eller modul A & C kjent som Integration testing. Å integrere alle de tre modulene og teste det som et komplett system kalles System testing.

Hva du vil lære:

• Min erfaring
  • Eksempel på systemtesting
• Nærme seg
• Hvorfor systemtesting?
• Er dette en test av hvit boks eller svart boks?
• Hvordan utføre systemtest?
  • Hva skal jeg teste?
• Fordeler
• Inngangs- / utgangskriterier
• Systemtestplan
• Fremgangsmåte for å skrive tilfeller til systemtest
• Systemtest tilfeller
• Typer av systemtesting
  • Flere typer systemtesting
• Hva er systemintegrasjonstesting?
• Forskjellen mellom system- og aksepttesting
• Tips for å utføre systemtesten
• Konklusjon
• Anbefalt lesing

Min erfaring

Så ... tror du virkelig det vil ta så stor tid å teste det du kaller Systemtesting , selv etter å ha brukt mye krefter på integrasjonstesting?

Kunden vi nylig kontaktet for prosjektet, var ikke overbevist om estimatet vi ga for hver testinnsats.

Jeg måtte ringe inn med et eksempel:

Mike, jeg vil gjerne utdype vår innsats og viktigheten av systemtesting med et eksempel.

Skyt, svarte han.

Eksempel på systemtesting

En bilprodusent produserer ikke bilen som en hel bil. Hver komponent i bilen er produsert separat, som seter, styring, speil, brudd, kabel, motor, bilramme, hjul etc.

Etter å ha produsert hver vare blir den testet uavhengig om den fungerer slik den skal fungere, og det kalles enhetstesting.

gratis programvare for å rippe DVD til MP4

Nå, når hver del er samlet med en annen del, blir den sammensatte kombinasjonen sjekket om montering ikke har gitt noen bivirkning til funksjonaliteten til hver komponent, og om begge komponentene fungerer sammen som forventet, og det kalles integrasjonstesting.

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

Hele bilen må sjekkes for forskjellige aspekter i henhold til kravene som er definert som om bilen kan kjøres jevnt, går i stykker, gir og annen funksjonalitet som fungerer som den skal, bilen viser ikke noe tretthet etter å ha blitt kjørt i 2500 miles kontinuerlig, farge av bil er generelt akseptert og likt, kan bilen kjøres på alle slags veier som glatt og grovt, slurvet og rett, etc, og hele forsøket på testing kalles System Testing, og det har ingenting å gjøre med integrasjonstesting.

Eksemplet fungerte slik det var forventet, og klienten var overbevist om innsatsen som kreves for systemtesten.

Jeg fortalte eksemplet her for å oppmuntre til viktigheten av denne testingen.

Nærme seg

Den utføres når integrasjonstesting er fullført.

Det er hovedsakelig en svart-boks testing. Denne testen evaluerer hvordan systemet fungerer fra et brukerperspektiv, ved hjelp av et spesifikasjonsdokument. Det krever ingen intern kunnskap om systemer som kodenes utforming eller struktur.

Den inneholder funksjonelle og ikke-funksjonelle bruksområder / produkt.

Fokuskriterier:

Det fokuserer hovedsakelig på følgende:

1. Eksterne grensesnitt
2. Multiprogram og komplekse funksjoner
3. Sikkerhet
4. Gjenoppretting
5. Opptreden
6. Operatørens og brukerens jevne samhandling med systemet
7. Installerbarhet
8. Dokumentasjon
9. Brukervennlighet
10. Last / stress

Hvorfor systemtesting?

#1) Det er veldig viktig å fullføre en full testsyklus, og ST er scenen der det gjøres.

#to) ST utføres i et miljø som ligner produksjonsmiljøet, og dermed kan interessenter få en god ide om brukerens reaksjon.

# 3) Det hjelper med å minimere feilsøking etter distribusjon og støtte samtaler.

# 4 ) I dette STLC-trinnet Application Architecture and Business krav blir begge testet.

Denne testen er veldig viktig, og den spiller en viktig rolle i å levere et kvalitetsprodukt til kunden.

La oss se viktigheten av denne testingen gjennom eksemplene nedenfor som inkluderer våre daglige oppgaver:

• Hva om en online transaksjon mislykkes etter bekreftelse?
• Hva om en vare plassert i en handlekurv på et nettsted ikke tillater å bestille?
• Hva om det i en Gmail-konto å opprette en ny etikett gir feil ved å klikke på fanen Opprett?
• Hva om systemet krasjer når belastningen økes på systemet?
• Hva om systemet krasjer og ikke klarer å gjenopprette dataene som ønsket?
• Hva om installering av programvare på systemet tar mye mer tid enn forventet og til slutt gir en feil?
• Hva om svartid på et nettsted øker mye mer enn forventet etter forbedring?
• Hva om et nettsted blir for sakte til at brukeren ikke klarer å bestille reisebilletten?

Ovenfor er bare noen få eksempler som viser hvordan systemtesting vil påvirke hvis det ikke gjøres på en skikkelig måte.

Alle eksemplene ovenfor er bare resultatet av enten systemtesting ikke utført eller ikke gjort riktig. Alle de integrerte modulene bør testes for å sikre at produktet fungerer i henhold til kravene.

Er dette en test av hvit boks eller svart boks?

Systemtesting kan betraktes som en svart boks testteknikk.

Black box Testing teknikk krever ikke intern kunnskap om koden, mens teknikk for hvit boks krever intern kunnskap om koden.

Mens du utfører systemtesting funksjonell og ikke-funksjonell, dekkes sikkerhet, ytelse og mange andre testtyper, og de testes ved hjelp av en svart bokseteknikk der inngangen leveres til systemet og utdataene bekreftes. Systemets interne kunnskap er ikke nødvendig.

Black Box-teknikk:

Hvordan utføre systemtest?

Det er i utgangspunktet en del av programvaretesting, og Testplanen skal alltid inneholde spesifikk plass for denne testen.

For å teste systemet som helhet, bør krav og forventninger være klare, og testeren må også forstå sanntidsbruken av applikasjonen.

Også de fleste brukte tredjepartsverktøy, versjoner av operativsystemer, smaker og arkitektur av operativsystemer kan påvirke systemets funksjonalitet, ytelse, sikkerhet, utvinnbarhet eller installerbarhet.

Derfor kan det være nyttig når du tester systemet, et klart bilde av hvordan applikasjonen skal brukes og hva slags problemer den kan møte i sanntid. I tillegg til det er et kravdokument like viktig som å forstå søknaden.

Tydelig og oppdatert kravdokument kan redde tester fra en rekke misforståelser, antakelser og spørsmål.

Kort sagt, et spiss og skarpt kravdokument med de siste oppdateringene sammen med en forståelse av sanntids applikasjonsbruk kan gjøre ST mer fruktbart.

Denne testingen gjøres på en planlagt og systematisk måte.

Nedenfor er de forskjellige trinnene involvert under utførelsen av denne testen:

• Det aller første trinnet er å lage en testplan.
• Lag systemtestsaker og testskript.
• Forbered testdataene som kreves for denne testen.
• Utfør systemtesttilfeller og skript.
• Rapporter feilene. Tester feilene på nytt når de er løst.
• Regresjonstesting for å verifisere virkningen av endringen i koden.
• Gjentakelse av testsyklusen til systemet er klart til å distribueres.
• Logg av fra testteamet.

Hva skal jeg teste?

Punktene som er oppgitt nedenfor er dekket i denne testen:

• Test til slutt til slutt som inkluderer å verifisere samspillet mellom alle komponentene og sammen med eksterne eksterne enheter for å sikre om systemet fungerer bra i noen av scenariene, blir dekket i denne testen.
• Den verifiserer at inngangen som leveres til systemet gir det forventede resultatet.
• Den verifiserer om alle funksjonelle og ikke-funksjonelle krav er testet, og om de fungerer som forventet eller ikke.
• Til dette og utforskende testing kan utføres i denne testingen etter at skriptetesting er fullført. Utforskende testing og ad-hoc-testing hjelper til med å utfolde feilene som ikke finnes i skripttesting, da det gir testere frihet til å teste, ettersom deres ønske er basert på deres erfaring og intuisjon.

Fordeler

Det er flere fordeler:

• Denne testen inkluderer end-to-end-scenarier for å teste systemet.
• Denne testingen utføres i samme miljø som i produksjonsmiljøet, som hjelper med å forstå brukerperspektivet og forhindrer problemene som kan oppstå når systemet blir satt i drift.
• Hvis denne testingen gjøres på en systematisk og riktig måte, vil det hjelpe til med å dempe problemene etter produksjonen.
• Denne testen tester både applikasjonsarkitektur og forretningskrav.

Inngangs- / utgangskriterier

La oss ta en detaljert titt på inngangs- / utgangskriteriene for systemtest.

Oppføringskriterier:

• Systemet burde ha bestått utgangskriteriene for integrasjonstesting, dvs. alle testtilfellene burde ha blitt utført, og det skal ikke være kritisk eller Priority P1, en P2-feil i åpen tilstand.
• Testplan for denne testen bør godkjennes og signeres.
• Test tilfeller / scenarier bør være klare til å kjøres.
• Testskripter skal være klare til å kjøres.
• Alle ikke-funksjonelle krav bør være tilgjengelige, og testtilfeller for det samme burde ha blitt opprettet.
• Testmiljøet skal være klart.

Utgangskriterier:

• Alle testsakene skal utføres.
• Ingen kritiske feil eller sikkerhetsrelaterte feil skal være i åpen tilstand.
• Hvis noen middels eller lavprioritetsfeil er i åpen tilstand, bør det implementeres med aksept fra kunden.
• Utgangsrapport skal sendes inn.

Systemtestplan

Testplan er et dokument som brukes til å beskrive formålet, målet og omfanget av et produkt som skal utvikles. Hva som må testes og hva som ikke skal testes, teststrategier, verktøy som skal brukes, miljøkrav og alle andre detaljer er dokumentert for å gå videre med testingen.

Testplanen hjelper deg med å fortsette testingen på en veldig systematisk og strategisk måte, og som hjelper til med å unngå risiko eller problemer mens testingen er ferdig.

Systemtestplan dekker følgende punkter:

• Formål og mål er definert for denne testen.
• Omfang (funksjoner som skal testes, funksjoner som ikke skal testes er oppført).
• Testakseptkriterier (kriterier som systemet vil bli akseptert på, dvs. nevnte punkter i akseptkriterier skal være i godkjent tilstand).
• Inn- / utgangskriterier (Definerer kriteriene når systemtesting skal starte og når det skal betraktes som komplett).
• Testplan (estimering av testing som skal fullføres på et bestemt tidspunkt).
• Teststrategi (Inkluderer testteknikker).
• Ressurser (Antall ressurser som kreves for testing, deres roller, ressurstilgjengelighet osv.).
• Testmiljø (operativsystem, nettleser, plattform).
• Test tilfeller (Liste over testsaker som skal utføres).
• Forutsetninger (hvis det er noen forutsetninger, bør de inkluderes i testplanen).

Fremgangsmåte for å skrive tilfeller til systemtest

Systemtestsaker dekker alle scenarier og brukssaker, og dekker også funksjonelle, ikke-funksjonelle, brukergrensesnitt, sikkerhetsrelaterte testsaker. Testtilfellene er skrevet på samme måte som de er skrevet for funksjonstesting.

Systemtesttilfeller inkluderer nedenstående felt i malen:

• Test saks-ID
• Test Suite-navn
• Beskrivelse - Beskriver testsaken som skal utføres.
• Trinn - trinnvis fremgangsmåte for å beskrive hvordan du utfører testing.
• Testdata - Dummy-data forberedes for å teste applikasjonen.
• Forventet resultat - Forventet resultat i henhold til kravdokumentet er gitt i denne kolonnen.
• Faktisk resultat - Resultat etter gjennomføring av testsaken er gitt i denne kolonnen.
• Bestått / ikke bestått - Sammenligning i faktisk og forventet resultat definerer bestått / ikke bestått-kriteriene.
• Merknader

Systemtest tilfeller

Her er noen eksempler på testscenarier for et e-handelssted:

1. Hvis nettstedet starter riktig med alle relevante sider, funksjoner og logo
2. Hvis brukeren kan registrere / logge inn på nettstedet
3. Hvis brukeren kan se tilgjengelige produkter, kan han legge til produkter i handlekurven sin, og kan motta bekreftelsen via e-post eller SMS eller ringe.
4. Hvis hovedfunksjonaliteten som å søke, filtrere, sortere, legge til, endre, ønskeliste osv. Fungerer som forventet
5. Hvis antall brukere (definert som i kravdokument) kan få tilgang til nettstedet samtidig
6. Hvis nettstedet starter riktig i alle større nettlesere og de nyeste versjonene
7. Hvis transaksjonene gjøres på nettstedet via en bestemt bruker, er de sikre nok
8. Hvis nettstedet starter riktig på alle støttede plattformer som Windows, Linux, Mobile, etc.
9. Hvis brukerveiledningen / retningslinjene for retur, personvernregler og vilkår for bruk av nettstedet er tilgjengelige som et eget dokument og nyttige for enhver nybegynner eller første gangs bruker.
10. Hvis innholdet på sidene er riktig justert, godt administrert og uten stavefeil.
11. Hvis økt-tidsavbrudd implementeres og fungerer som forventet
12. Hvis en bruker er fornøyd etter bruk av nettstedet, eller med andre ord, finner brukeren det ikke vanskelig å bruke nettstedet.

Typer av systemtesting

ST kalles et supersett av alle typer testing, da alle hovedtyper av testing er dekket av det. Selv om fokus på typer testing kan variere på grunnlag av produkt, organisasjonsprosesser, tidslinje og krav.

Samlet sett kan det defineres som nedenfor:

Funksjonstesting: For å sikre at funksjonaliteten til produktet fungerer i henhold til de definerte kravene, innenfor funksjonene til systemet.

Testing av utvinnbarhet: For å være sikker på hvor godt systemet gjenoppretter fra ulike inngangsfeil og andre feilsituasjoner.

Interoperabilitetstesting: For å være sikker på om systemet kan fungere godt med tredjepartsprodukter eller ikke.

Ytelsestesting: For å sikre at systemets ytelse under forskjellige forhold, når det gjelder ytelsesegenskaper.

Skalerbarhetstesting: For å sikre at systemets skaleringsevner i forskjellige termer, som brukerskalering, geografisk skalering og ressursskalering.

Pålitelighetstesting: For å sikre at systemet kan brukes over lengre tid uten å utvikle feil.

Regresjonstesting: For å sikre at systemets stabilitet når det går gjennom en integrering av forskjellige delsystemer og vedlikeholdsoppgaver.

Dokumentasjonstesting: For å være sikker på at systemets brukerhåndbok og andre dokumenter om hjelpemner er korrekte og brukbare.

Sikkerhetstesting: For å sikre at systemet ikke tillater uautorisert tilgang til data og ressurser.

Brukervennlighetstesting : For å sikre at systemet er enkelt å bruke, lær og bruk.

Flere typer systemtesting

# 1) Testing av grafisk brukergrensesnitt (GUI):

GUI-testing gjøres for å verifisere om GUI for et system fungerer som forventet eller ikke. GUI er i utgangspunktet det som er synlig for en bruker mens han bruker applikasjonen. GUI-testing innebærer testing av knapper, ikoner, avkrysningsbokser, Listeboks, Tekstboks, menyer, verktøylinjer, dialogbokser osv.

# 2) Testing av kompatibilitet:

Kompatibilitetstesting er gjort for å sikre at det utviklede produktet er kompatibelt med forskjellige nettlesere, maskinvareplattformer, operativsystem og databaser i henhold til kravdokumentet.

# 3) Unntakshåndtering:

Testing av unntakshåndtering utføres for å verifisere at selv om det oppstår en uventet feil i produktet, skal den vise riktig feilmelding og ikke la applikasjonen stoppe. Det håndterer unntaket på en slik måte at feilen vises mens produktet gjenoppretter og lar systemet behandle feil transaksjon.

# 4) Volumtesting:

Volumtesting er en type ikke-funksjonell testing hvor testingen utføres med en enorm mengde data. For eksempel, Volumet av data økes i databasen for å verifisere systemytelsen.

# 5) Stresstesting:

Stresstesting gjøres ved å øke antall brukere (samtidig) på en applikasjon i en grad som applikasjonen går i stykker. Dette gjøres for å bekrefte hvor søknaden brytes ned.

# 6) Sanity Testing:

Sanity Testing utføres når bygningen frigjøres med en endring i koden eller funksjonaliteten, eller hvis noen feil er løst. Det bekrefter at endringene som er gjort ikke har påvirket koden, og at det ikke har oppstått noe annet problem på grunn av det, og systemet fungerer som tidligere.

Hvis det oppstår problemer, blir ikke builden akseptert for videre testing.

I utgangspunktet blir det ikke gjort grundige tester for bygningen for å spare tid og kostnader ettersom den avviser byggingen for et problem som ble funnet. Sanity testing gjøres for endringen eller for det faste problemet, og ikke for hele systemet.

# 7) Røykprøving:

Røykprøving er en testing som utføres på build for å verifisere om build er ytterligere testbar eller ikke. Det verifiserer at bygningen er stabil å teste, og at alle de kritiske funksjonene fungerer bra. Røykprøving gjøres for hele systemet, dvs. test til slutt.

# 8) Utforskende testing:

Utforskende testing som navnet i seg selv handler om å utforske applikasjonen. Ingen skripttesting utføres under utforskende testing. Test tilfeller skrives sammen med testingen. Det fokuserer mer på utførelse enn planlegging.

Tester har friheten til å teste på egen hånd ved hjelp av sin intuisjon, erfaring og intellekt. En tester kan velge hvilken som helst funksjon for å teste først, dvs. tilfeldig kan han velge funksjonen for å teste, i motsetning til de andre teknikkene der den strukturelle måten brukes til å utføre testing.

# 9) Adhoc-testing:

Adhoc-testing er uformell testing der ingen dokumentasjon eller planlegging gjøres for å teste søknaden. Tester tester applikasjonen uten testtilfeller. Målet med en tester er å bryte søknaden. Testeren bruker sin erfaring, gjetning og intuisjon for å finne de kritiske problemene i applikasjonen.

# 10) Installasjonstesting:

Installasjonstesting er å verifisere om programvaren blir installert uten problemer.

Dette er den viktigste delen av testing, da installasjonen av programvaren er den aller første interaksjonen mellom brukeren og produktet. Type installasjonstesting avhenger av forskjellige faktorer som operativsystem, plattform, distribusjon av programvare, etc.

Test tilfeller som kan inkluderes hvis en installasjon gjøres via internett:

• Dårlig nettverkshastighet og ødelagt tilkobling.
• Brannmur og sikkerhetsrelatert.
• Størrelse og omtrentlig tid er tatt.
• Samtidig installasjon / nedlastinger.
• For lite minne
• Utilstrekkelig plass
• Avbrutt installasjon

# 11) Vedlikeholdstesting:

Når produktet er tatt i bruk, kan problemet oppstå i et levende miljø, eller det kan være nødvendig med en forbedring av produktet.

Produktet trenger vedlikehold når det blir satt i drift og det blir ivaretatt av vedlikeholdsteamet. Testingen utført for eventuelle problemer eller forbedring eller migrering til maskinvaren faller under vedlikeholdstesting.

Hva er systemintegrasjonstesting?

Det er en type testing der systemets evne til å opprettholde dataintegritet og drift i koordinering med andre systemer i samme miljø, blir sjekket.

Eksempel på systemintegrasjonstesting:

La oss ta et eksempel på et velkjent nettsted for billettbestilling på nettet - http://irctc.co.in.

Dette er et billettbestillingsanlegg; et online shoppinganlegg samhandler med PayPal. Totalt sett kan du betrakte det som A * B * C = R.

Nå på systemnivå, online billettbestillingsanlegg, online shoppinganlegg og online betalingsalternativ kan systemtestes uavhengig, etterfulgt av sjekk utføre integrasjonstester for hver av dem. Og så må hele systemet testes systematisk.

Så hvor kommer systemintegrasjonstesting inn i bildet?

Nettportalen http://Irctc.co.in er en kombinasjon av systemer. Du kan utføre tester på samme nivå (enkelt system, systemsystemet), men på hvert nivå vil du kanskje fokusere på forskjellige risikoer (integrasjonsproblemer, uavhengig funksjonalitet).

• Mens du tester online billettbestillingsanlegget, kan du bekrefte om du er i stand til å bestille billetter online. Du kan også vurdere integrasjonsproblemer For eksempel, Billettbestillingsanlegg integrerer back-end med front-end (UI). For eksempel, hvordan front-end oppfører seg når databaseserveren reagerer tregt?
• Testing av online billettbestillingsanlegg med online shoppinganlegg. Du kan bekrefte at online shopping er tilgjengelig for brukere som er logget inn i systemet for å bestille billetter online. Du kan også vurdere verifisering av integrering i online shopping anlegget. For eksempel, hvis brukeren er i stand til å velge og kjøpe et produkt uten problemer.
• Testing av online billettbestillingsanleggets integrering med PayPal. Du kan bekrefte om penger etter at du har bestilt billetter ble overført fra PayPal-kontoen din til den online billettbestillingskontoen. Du kan også vurdere verifisering av integrering i PayPal. For eksempel, hva om systemet setter to oppføringer i en database etter at du bare har belastet penger en gang?

Forskjellmellom systemtesting og systemintegrasjonstesting:

Hovedforskjellen er:

• Systemtesting ivaretar et enkelt systems integritet med relevant miljø
• Systemintegrasjonstesting ivaretar flere systems integritet med hverandre, i samme miljø.

Dermed er systemtesten begynnelsen på reell testing der du tester et produkt som en helhet og ikke en modul / funksjon.

Forskjellen mellom system- og aksepttesting

Nedenfor er de største forskjellene:

Tips for å utføre systemtesten

1. Gjenta sanntidsscenarier i stedet for å gjøre ideelle tester, ettersom systemet skal brukes av en sluttbruker og ikke av den trente testeren.
2. Bekreft systemets respons på forskjellige måter, ettersom mennesket ikke liker å vente eller se feil data.
3. Installer og konfigurer systemet i henhold til dokumentasjonen, fordi det er det sluttbrukeren skal gjøre.
4. Å involvere mennesker fra forskjellige områder som forretningsanalytikere, utviklere, testere, kunder kan sende inn et bedre system.
5. Regelmessig testing er den eneste måten å sikre at den minste endringen i koden for å fikse feilen ikke har satt inn enda en kritisk feil i systemet.

Konklusjon

Systemtesting er veldig viktig, og hvis ikke det gjøres riktig, kan kritiske problemer bli møtt i det levende miljøet.

Et system som helhet har forskjellige egenskaper som skal verifiseres. Et enkelt eksempel vil være ethvert nettsted. Hvis det ikke er testet som en helhet, kan brukeren oppleve at nettstedet er veldig tregt, ellers kan nettstedet krasjet når et stort antall brukere logger på samtidig.

Og disse egenskapene kan ikke testes før nettstedet er testet som en helhet.

Håper denne opplæringen var veldig nyttig for å forstå konseptet Systemtesting.

Anbefalt lesing

• Typer programvaretesting: Ulike testtyper med detaljer
• Alpha Testing og Beta Testing (En komplett guide)
• Hva er System Integration Testing (SIT): Lær med eksempler
• Funksjonstesting mot ikke-funksjonell testing
• Kontinuerlig integrasjonsprosess: Hvordan forbedre programvarekvaliteten og redusere risikoen
• Topp 10 integrasjonstestverktøy for å skrive integrasjonstester
• Hva er integrasjonstesting (opplæring med eksempel på integrasjonstesting)
• Hva er utholdenhetstesting i programvaretesting (eksempler)