Systemtestning Forskellige typer og nøglefokusområde for systemtestning

Introduktion til systemtest

Har du nogensinde hørt om systemtest? Ja, selvfølgelig har du hørt, men ved ikke hvad der testes. Hvordan det implementeres i det faktiske miljø. Dagens verden er fyldt med masser af enheder, nye teknologier kommer hver dag ud. For at opretholde kvaliteten og sikre, at vores produkt er fejlfrit og pålideligt, har hver udvikling sit parallelle testteam til side.

Testning er processen med krydskontrol af, om vi har den korrekte funktionalitet eller ej. Softwaretest er en fase, hvor software afsluttes. Nu testes den integrerede software. Ved test tjekker vi, at softwaren opfylder vores krav eller ej.

Testning, der udføres på hele systemet kendt som systemtest. Ved denne test afslører vi fejlene. Det sikrer, at alt systemet fungerer som forventet. Vi kontrollerer systemets ydelse og funktionalitet for at få et kvalitetsprodukt. Systemtest er intet andet end at teste systemet som helhed. Denne test kontrollerer komplet ende-til-ende-scenarie i henhold til kundens synspunkt.

Funktionelle og ikke-funktionelle tests udføres også ved systemtest. Alt gøres for at opretholde tillid inden for udviklingen af, at systemet er defektfrit og bugfrit. Systemtest er også beregnet til at teste specifikationer for hardware / software krav.

Systemtest er mere en begrænset type test; det søger at opdage begge defekter inden for "inter-assemblages".

Der er to typer tests:

Dette er specialiserede systemer og applikationer

Før jeg springer direkte ind i systemtesten, vil jeg have, at du kender teststrømmen. Så du får en klar idé. Se venligst følgende diagram.

Typer af systemtest

Nedenfor er de forskellige typer test, som er som følger:

1. Test af funktionalitet

• Denne test sikrer, at et produkts funktionalitet fungerer i henhold til kravspecifikationen inden for systemets funktioner.
• Funktionel test udføres manuelt eller med automatiserede værktøjer.

2. Test af genvindbarhed

• Denne test bestemmer, om operationer kan fortsættes efter en katastrofe eller efter, at systemets integritet er gået tabt.
• Det bedste eksempel på dette antager, at vi downloader en fil. Og pludselig går forbindelsen af. Efter genoptagelse af forbindelsen starter vores download det sted, hvor vi forlod. Det starter ikke med at starte igen.
• Dette bruges, hvor kontinuiteten i operationerne er væsentlig

3. Test af ydelse

• Denne test sørger for, at systemets ydeevne er under forskellige betingelser med hensyn til ydeevneegenskaber.
• Denne test kaldes også som compliance-test med hensyn til ydeevne.
• Denne test sikrer, at den opfylder systemkravene
• Den kontrollerer, når flere brugere bruger den samme app ad gangen, og hvordan den reagerer tilbage

Ydelsestest kan kategoriseres i tre hovedkategorier som hastighed, skalerbarhed, stabilitet.

4. Test af skalerbarhed

Denne test sikrer systemets skaleringsevner i forskellige udtryk som brugerskalering, geografisk skalering og ressourceskalering.

5. Test af pålidelighed

• Pålidelighedstest sikrer, at systemet er fejlfrit.
• Denne test sikrer, at systemet kan betjenes i en længere varighed uden at udvikle fejl.

6. Dokumentationstest

Denne test sikrer, at systemets brugervejledning og andre hjælpeemner dokumenter er korrekte og anvendelige.

7. Sikkerhedstest

• Test, som bekræfter, at programmet kan få adgang til autoriseret personale, og at autoriseret personale kan få adgang til de funktioner, der er tilgængelige til deres sikkerhedsniveau.
• Denne test sørger for, at systemet ikke tillader uautoriseret adgang til data og ressourcer.
• Formålet med sikkerhedstest er at bestemme, hvor godt et system beskytter mod uautoriseret intern eller ekstern adgang eller forsætlig skade.
• Der er følgende område, hvor vi generelt kan tjekke for sikkerhed:

1. Godkendelse
2. Bemyndigelse
3. Data validering
4. Transportsikkerhed
5. Data beskyttelse
6. Session ledelse

8. Test af brugervenlighed

For at sikre dig, at systemet er let at bruge, skal du lære og betjene

9. Test af krav

Hvert system er et testet krav.

• Direkte observationer af mennesker, der bruger systemet.
• Brugbarhedsundersøgelser er blevet udført under denne test.
• Brugertests under denne test. Kaldes også som betatest.
• Denne test tester systemet for, hvordan den virkelige bruger vil arbejde i miljøet.
• Brugbarhedstest bruges hovedsageligt til design af applikationen.
• I en brugbarhedstest forsøger faktiske brugere at få typiske mål og opgaver med et produkt under kontrollerede forhold.

Dette system bruges til at bestemme:

1. Hvor nemt det er at forstå anvendelsen af ​​applikationen.
2. Hvor nemt det er at udføre en ansøgningsproces.

10. Test af belastning

Denne test bestemmer, hvordan applikationen opfører sig, når flere brugere får adgang til den samtidig på tværs af flere placeringer.

• Denne test udføres for at bestemme, om systemets ydelse er acceptabel ved et forudbestemt belastningsniveau.
• Belastningstest evaluerer systemydelsen med de foruddefinerede belastningsniveauer.
• Det kontrollerer normale og foruddefinerede betingelser for applikationen.

11. Stresstest

Denne test kontrollerer generelt, at systemet fortsætter med at fungere, når det udsættes for den store datamængde end forventet.

• Stresstestning kan indeholde inputtransaktioner, interne tabeller, kommunikationskanaler, diskplads osv.
• Stresstest kontrollerer, at systemet skal køre som det ville i et produktionsmiljø.
• Det kontrollerer systemet under ekstreme forhold.
• Stresstestning er også kendt som udholdenhedstestning.

12. Konfigurationstest

• Konfigurationstest kontrollerer det med de flere kombinationer af applikationer med hardware.
• Denne test kontrollerer for et kompatibilitetsproblem.
• Bestem minimal og optimal H / W- og S / W-konfiguration.
• Denne test bestemmer virkningerne af tilføjelse eller ændring af ressourcer som hukommelse, diskplads, CPU, netværkskort.

13. Test af kompatibilitet

• Kompatibilitetstest, der bruges til at kontrollere, om din applikation er i stand til at køre på forskellige H / W, OS, applikationer, netværksmiljøer eller mobile enheder osv.
• Ligner multi-platform test.
• Kapacitetstest er mere nyttigt i webbaserede applikationer, hvor vi kan kontrollere, at applikationen skal være tilgængelig fra enhver browser.

Nøglefokusområde

• Under systemtest testes systemet inden for produktionsmiljøet. Før levering af produktet, skal systemet testes i et produktionsmiljø.
• Udviklings- og produktionsmiljøet kan være forskelligt i forhold til virksomheden.
• Det skal hovedsageligt få konfigurationsrelateret fejl.

Systemtestkoncept

Systemtest falder inden for rækkevidden af ​​Black-Box-test. Der er også test såsom sikkerhed, pålidelighed, ydelse, installation, funktionel test osv.

Vi har også test i hvid boks. Dette også, kendt som clear-box test. Test af hvid boks betyder testning, hvor testapparatets interne struktur er kendt af testeren. Men i denne artikel fokuserer vi på black box-test.

Hvad er Black-Box Testing?

• Denne test kaldes også adfærdstest.
• Black-box-testning fokuserer hovedsageligt på input og output, da den interne kode er skjult for testeren

Systemtest har også nogle specialiserede test som følger:

1. Regressionstest

Denne test afhænger af tiden. Faktoren er ikke altid nok til denne test. Denne test udføres på to måder:

• Manuel test :

Manuel test kan udføres for lille system. Projektet, hvor omkostningerne er spørgsmålet. Den automatiserede test er ikke praktisk.

Udviklere eller kvalitetssikringsteam manuelt tester hver eneste sti i softwarekoden kan tage. Og så er der sket sammenligning.

Denne test er meget tidskrævende og har brug for en masse ressourcer til at arbejde på den.

Denne test er ikke effektiv, så automatiseringstesten kommer ind i billedet

• Automatisk test:

Denne test er meget god. Masser af virksomheder, der prøver at få automatiserede testværktøjer.

Hvis vi har masser af versionændringer til en applikation, er det meget nyttigt. En klasse af disse værktøjer kaldes fanget afspilningsværktøjer.

2. Test af fejlhåndtering

• At bestemme systemets evne til at behandle forkerte transaktioner korrekt.
• Alle rimelige fejl antages at blive registreret af applikationssystemet.
• Kontrol over fejlen under fejlkorrektion er et must.
• Procedurer garanterer for det meste, at fejlen bliver rettet korrekt.
• Denne test skal ske i hele SDLC.
• Fejl omfatter alle uventede forhold.
• Det kontrollerer softwarens evne til at udføre alle transaktioner korrekt.
• For eksempel: Bare sæt nogle forkerte værdier i applikationen for at kontrollere, om systemet er nok i stand til at finde disse problemer. Denne proces kan være iterativ.

3. Test mellem systemet

• Denne test udføres, når en applikation placeres i et distribueret område. Og al placeret integration sker. Denne test udføres hovedsageligt for at kontrollere strømmen af ​​data fra det hostede hovedsystem til andre systemer.
• Kort sagt kan vi sige, at "Testingen af ​​en grænseflade mellem to eller flere applikationssystemer."
• Dette bestemmer:

1. Dokumentation for systemet er komplet og nøjagtig.
2. Parametre og data sendes korrekt mellem de to applikationer.

• Der er bunker af testsæt, som transaktionen fra et system til et andet system udfører, og vice versa udføres korrekt. krydstjek er sket, og hvis der opstår en fejl, bliver den rettet på det tidspunkt.
• Denne test sikrer dataflyt mellem applikationen.
• Denne test er kedelig, hvis automatisering ikke udføres.
• Omkostninger er mere, hvis iterationer er mere.

4. Sanitetstest

• Sanitetstest betyder kontrol af systemets opførsel. Denne test kaldes også som snæver regressionstest.
• Sanitetstest er nyttige til både indledende miljøvalidering og fremtidige interaktive trin.
• Sanitetstest er fokuseret.
• Denne test betragtes også som en undergruppe af regressionstest.
• Eksempel på Sanity-test er, at vi kan sige, at vi har brug for systemets oppetid. Hvordan skal tidssystemet tage for at komme op?
• Sanitetstestning blev oprindeligt designet til at teste kernemoduler.
• Sanitetstest kan kontrollere forbindelsen med applikationsservere og med perifere enheder.

5. Røgprøvning

• Generelt er røgprøvning også kendt som "Build Verification Testing".
• Dette udtryk kommer fra hardwaretest. Ved hardwaretestning bestod enheden testen, hvis den ikke fik fyr eller ryger første gang den blev tændt.
• Røgprøvning kontrollerer softwarens testbarhed kaldes Røgetestning.
• Røgprøvning afgør, om testning er nok til applikationen. Er det stabilt?
• Røgprøvning hjælper med at bestemme, hvor man skal stoppe.
• Røgprøver kan udføres manuelt eller automatiserede værktøjer.
• Røgtestscenarierne understreger bredden mere end dybden.
• Røgprøvning er også kendt som Verifikationstest / Link-test / Grundlæggende funktionel test.
• Dette er en ”lav og bred” tilgang til applikationen.
• Røgprøvning hjælper med at eksponere problemer tidligt.
• Røgprøvning hjælper også med at finde integrationstest.
• Ved røgprøvning skal alle komponenter berøres, og enhver vigtig funktion skal testes kort.
• Hvis en test mislykkes, returneres build til udviklere, der ikke er testet.
• Røgprøvning bruges generelt til systemtest, acceptacitetstest og integrationstest.

6. Parallel test

• Parallel test betyder, at man tester flere applikationer eller undersystemer ad gangen samtidigt.
• Vi kan sige, at en sammenligning mellem to forskellige systemer.

• Parallel test er at bestemme - Ny version af en applikation eller nye systemer fungerer korrekt med henvisning til det eksisterende system, der fungerer korrekt.
• Parallel testning kan bruges, når du accepterer et nyt system.
• Mens der udføres parallel test, bruges de samme data på begge system.
• Paralleltest bruges nyt system med et eksisterende system i et vist tidsrum.
• Gennem krydskontrol af o / p og sammenligning med o / p fra det eksisterende system. Paralleltest udføres for at sikre, at det nye system fungerer op til mærket, som det tidligere system, der plejede at gøre.

Konklusion

Hver softwareudviklingsproces har en testdel. Hvis software besidder alle testene og opfylder alle betingelserne, er den klar til overdragelse til kunden. Testning er en vigtig del og skal udføres meget alvorligt.

Anbefalede artikler

Dette har været en guide til systemtest. Her har vi drøftet introduktionen, forskellige typer systemtest og dets centrale fokusområde. kan du også se på de følgende artikler for at lære mere -

1. Karrierer inden for softwaretestning
2. Interviewspørgsmål til penetrationstest
3. Hvad er neurale netværk?
4. Defekter livscyklus i softwaretest
5. Forskellige værktøjer til performance-test