Menu

Typer af softwaretest: Forskellige testtyper med detaljer

types software testing

Prøv Vores Instrument Til At Fjerne Problemer

Hvad er de forskellige typer softwaretest?

Vi, som testere, er opmærksomme på de forskellige typer softwaretest, såsom funktionstest, ikke-funktionel test, automatiseringstest, smidig test og deres undertyper osv.

Hver af os ville være stødt på flere typer test i vores testrejse. Vi har måske hørt nogle, og vi har muligvis arbejdet på nogle, men ikke alle har viden om alle testtyperne.

Forskellige typer softwaretest

Hver type test har også sine egne funktioner, fordele og ulemper. I denne artikel har jeg dog hovedsageligt dækket hver eneste type softwaretest, som vi normalt bruger i vores daglige testliv.

Lad os se på dem.

Hvad du vil lære:

Forskellige typer softwaretest

Nedenfor er listen over nogle almindelige typer softwaretest:

Funktionelle testtyper inkluderer:

  • Enhedstest
  • Integrationstest
  • Systemtest
  • Sanity Testing
  • Røgtest
  • Interface test
  • Regressionstest
  • Beta / accept test

Ikke-funktionelle testtyper inkluderer:

  • Test af ydeevne
  • Load Testing
  • Stresstest
  • Volumen test
  • Sikkerhedstest
  • Kompatibilitetstest
  • Installer test
  • Restitutionstest
  • Pålidelighedstest
  • Usability Testing
  • Test af overholdelse
  • Lokaliseringstest

Lad os se flere detaljer om disse testtyper.

Typer af softwaretest

# 1) Alpha Testing

Det er den mest almindelige type test, der anvendes i softwareindustrien. Formålet med denne test er at identificere alle mulige problemer eller mangler, inden de frigives på markedet eller til brugeren.

Alpha Testing udføres i slutningen af ​​softwareudviklingsfasen, men inden Beta Testing. Alligevel kan der foretages mindre designændringer som et resultat af en sådan test.

Alpha Testing foregår på udviklerens websted. Internt virtuelt brugermiljø kan oprettes til denne type test.

# 2) Acceptantestning

An Accept test udføres af klienten og verificerer, om slutningen til at afslutte strømmen af ​​systemet er i henhold til forretningskravene eller ej, og om det er efter slutbrugerens behov. Klienten accepterer kun softwaren, når alle funktionerne og funktionerne fungerer som forventet.

Det er den sidste fase af testen, hvorefter softwaren går i produktion. Dette kaldes også UAT (User Acceptance Testing).

# 3) Ad-hoc test

Selve navnet antyder, at denne test udføres den en ad-hoc basis, dvs. uden henvisning til testsagen og også uden nogen plan eller dokumentation til rådighed for en sådan type test.

Formålet med denne test er at finde manglerne og bryde applikationen ved at udføre en hvilken som helst strøm af applikationen eller tilfældig funktionalitet.

Ad hoc-test er en uformel måde at finde mangler på og kan udføres af alle i projektet. Det er vanskeligt at identificere mangler uden en testtilfælde, men nogle gange er det muligt, at mangler, der blev fundet under ad hoc-test, muligvis ikke blev identificeret ved hjælp af eksisterende testtilfælde.

# 4) Test af tilgængelighed

Målet med Test af tilgængelighed er at afgøre, om softwaren eller applikationen er tilgængelig for handicappede eller ej.

Her betyder handicap døve, farveblinde, mentalt handicappede, blinde, alderdom og andre handicappede grupper. Forskellige kontroller udføres, såsom skriftstørrelse for synshandicappede, farve og kontrast for farveblindhed osv.

# 5) Betatestning

Betatestning er en formel type softwaretest, der udføres af kunden. Det udføres i det virkelige miljø inden du frigiver produktet til markedet for de faktiske slutbrugere.

Betatestning udføres for at sikre, at der ikke er store fejl i softwaren eller produktet, og det opfylder forretningskravene ud fra et slutbrugerperspektiv. Betatestning er vellykket, når kunden accepterer softwaren.

Normalt udføres denne test typisk af slutbrugere eller andre. Det er den endelige test, der udføres, inden der frigives en ansøgning til kommercielt formål. Normalt er betaversionen af ​​den frigivne software eller det produkt begrænset til et bestemt antal brugere i et bestemt område.

Så slutbruger bruger faktisk softwaren og deler feedbacken til virksomheden. Virksomheden træffer derefter de nødvendige handlinger, inden de frigiver softwaren til hele verdenen.

# 6) Back-end-test

Hver gang et input eller data indtastes i front-end-applikationen, gemmes det i databasen, og afprøvningen af ​​en sådan database kaldes Database Testing eller Backend Testing.

Der er forskellige databaser som SQL Server, MySQL og Oracle osv. Databasetest involverer test af tabelstruktur, skema, lagret procedure, datastruktur og så videre.

I Back-end Testing GUI er ikke involveret, testere er direkte forbundet til databasen med korrekt adgang, og testere kan nemt verificere data ved at køre et par forespørgsler på databasen.

Der kan være problemer identificeret som datatab, deadlock, datakorruption osv under denne back-end-test, og disse problemer er kritiske for at rette, inden systemet går live ind i produktionsmiljøet

# 7) Test af browserkompatibilitet

Det er en undertype af kompatibilitetstest (som forklares nedenfor) og udføres af testteamet.

Test af browserkompatibilitet udføres til webapplikationer, og det sikrer, at softwaren kan køre med kombinationen af ​​forskellige browsere og operativsystemer. Denne type test validerer også, om webapplikation kører på alle versioner af alle browsere eller ej.

# 8) Test af bagudkompatibilitet

Det er en type test, der validerer, om den nyudviklede software eller opdaterede software fungerer godt sammen med den ældre version af miljøet eller ej.

Backward Compatibility Testing kontrollerer, om den nye version af softwaren fungerer korrekt med filformat oprettet af en ældre version af softwaren. det fungerer også godt med datatabeller, datafiler, datastruktur oprettet af den ældre version af denne software.

Hvis noget af softwaren opdateres, skal det fungere godt oven på den tidligere version af denne software.

# 9) Black Box Testing

Internt systemdesign tages ikke med i denne type test. Test er baseret på krav og funktionalitet.

Detaljeret information om fordele, ulemper og typer af Black Box Testing kan ses her .

# 10) Test af grænseværdi

Denne type test kontrollerer applikationens opførsel på grænseniveau.

Grænseværditest udføres til kontrol af, om der findes mangler ved grænseværdier. Grænseværditestning bruges til at teste et andet antal tal. Der er en øvre og nedre grænse for hvert område, og test udføres på disse grænseværdier.

Hvis test kræver et testinterval med tal fra 1 til 500, udføres test af grænseværdi på værdier ved 0, 1, 2, 499, 500 og 501.

# 11) Afdelingstest

Det er en type testning af hvid boks og udføres under enhedstestning. Branch Testing, navnet antyder, at koden testes grundigt ved at krydse i hver gren.

# 12) Sammenligningstest

Sammenligning af et produkts styrke og svagheder med dets tidligere versioner eller andre lignende produkter kaldes sammenligningstest.

# 13) Test af kompatibilitet

Det er en testtype, hvor den validerer, hvordan software opfører sig og kører i et andet miljø, webservere, hardware og netværksmiljø.

Kompatibilitetstest sikrer, at software kan køre i en anden konfiguration, anden database, forskellige browsere og deres versioner. Kompatibilitetstest udføres af testteamet.

# 14) Komponenttest

Det udføres for det meste af udviklere efter afslutningen af ​​enhedstesten. Komponenttest involverer test af flere funktionaliteter som en enkelt kode, og dets mål er at identificere, om der er en defekt efter at have forbundet disse flere funktioner med hinanden.

# 15) End-to-End-test

Svarende til systemtest, End-to-End-test involverer test af et komplet applikationsmiljø i en situation, der efterligner brug af den virkelige verden, såsom interaktion med en database, brug af netværkskommunikation eller interaktion med anden hardware, applikationer eller systemer, hvis det er relevant.

# 16) Ækvivalenspartitionering

Det er en testteknik og en type Black Box Testing. Under dette Ækvivalenspartitionering , vælges et sæt af gruppen, og nogle få værdier eller tal hentes til test. Det forstås, at alle værdier fra den gruppe genererer den samme output.

Målet med denne testning er at fjerne overflødige testsager inden for en bestemt gruppe, der genererer den samme output, men ikke nogen fejl.

Antag, at applikationen accepterer værdier mellem -10 og +10, så ved hjælp af ækvivalensopdeling er de værdier, der er hentet til test, nul, en positiv værdi, en negativ værdi. Så ækvivalenspartitionering for denne test er -10 til -1, 0 og 1 til 10.

# 17) Eksempel på testning

Det betyder test i realtid. Eksempel Test inkluderer realtids scenariet, det involverer også scenarierne baseret på testernes oplevelse.

# 18) Undersøgende test

Exploratory Testing er uformel test udført af testteamet. Formålet med denne test er at undersøge applikationen og lede efter mangler, der findes i applikationen.

Nogle gange kan det ske, at større opdagede defekter under denne test endda kan forårsage systemfejl.

Under sonderende test anbefales det at holde styr på, hvilket flow du har testet, og hvilken aktivitet du har foretaget inden starten af ​​det specifikke flow.

En sonderende testteknik udføres uden dokumentation og testsager.

# 20) Funktionstest

Denne type test ignorerer de interne dele og fokuserer kun på output for at kontrollere, om det er i henhold til kravet eller ej. Det er en sort-boks-test, der er tilpasset funktionens krav til en applikation. For detaljerede oplysninger om funktionstest, klik her .

# 21) Test af grafisk brugergrænseflade (GUI)

Formålet med denne GUI-test er at validere GUI'en i henhold til forretningskravet. Den forventede GUI for applikationen er nævnt i det detaljerede designdokument og GUI-mockup-skærme.

GUI-testen inkluderer størrelsen på knapperne og indtastningsfeltet, der findes på skærmen, justering af al tekst, tabeller og indhold i tabellerne.

Det validerer også programmets menu, efter at have valgt forskellige menu- og menupunkter, det validerer, at siden ikke svinger, og justeringen forbliver den samme, når du svæver med musen i menuen eller undermenuen.

# 22) Gorilla Testing

Gorilla Testing er en testtype, der udføres af en tester og undertiden også af udvikleren. I Gorilla Testing testes et modul eller funktionaliteten i modulet grundigt og kraftigt. Formålet med denne test er at kontrollere applikationens robusthed.

# 23) Happy Path Testing

Formålet med Happy Path Testing er at teste en applikation med succes på et positivt flow. Det ser ikke efter negative eller fejlforhold. Fokus er kun på de gyldige og positive input, gennem hvilke applikation genererer den forventede output.

# 24) Test af trinvis integration

Incremental Integration Testing er en bottom-up tilgang til test, dvs. kontinuerlig test af en applikation, når der tilføjes ny funktionalitet. Applikationsfunktionalitet og moduler skal være uafhængige nok til at teste separat. Dette gøres af programmører eller af testere.

# 25) Installation / afinstallation af test

Installation og afinstallationstest udføres på fulde, delvise eller opgraderende installations- / afinstallationsprocesser på forskellige operativsystemer under forskellige hardware- eller softwaremiljø.

# 26) Integrationstest

Test af alle integrerede moduler for at kontrollere den kombinerede funktionalitet efter integration betegnes som Integrationstest .

Moduler er typisk kodemoduler, individuelle applikationer, klient- og serverapplikationer på et netværk osv. Denne type test er især relevant for klient / server og distribuerede systemer.

# 27) Load Testing

Det er en type ikke-funktionel test, og formålet med Load Testing er at kontrollere, hvor meget belastning eller maksimal arbejdsbyrde et system kan håndtere uden nogen form for forringelse af ydeevnen.

Load Testing hjælper for at finde systemets maksimale kapacitet under specifik belastning og eventuelle problemer, der forårsager forringelse af softwareydelse. Belastningstest udføres ved hjælp af værktøjer som f.eks JMeter , LoadRunner, WebLoad, Silk performer osv.

# 28) Afprøvning af abe

Monkey Testing udføres af en tester, der antager, at hvis aben bruger applikationen, hvordan tilfældige input, vil værdier blive indtastet af aben uden nogen viden eller forståelse for applikationen.

Målet med Monkey Testing er at kontrollere, om et program eller et system går ned ved at levere tilfældige inputværdier / data. Monkey Testing udføres tilfældigt, og der testes ingen testcases, og det er ikke nødvendigt

Monkey Testing udføres tilfældigt, og der testes ingen testcases, og det er ikke nødvendigt at være opmærksom på systemets fulde funktionalitet.

# 29) Mutationstest

Mutationstest er en type test af hvidboks, hvor kildekoden til et af programmet ændres og verificerer, om de eksisterende testtilfælde kan identificere disse mangler i systemet.

Ændringen i programkildekoden er meget minimal, så den ikke påvirker hele applikationen, kun det specifikke område, der har indflydelse, og de relaterede testtilfælde skal kunne identificere disse fejl i systemet.

# 30) Negativ testning

Testere, der har tankegangen 'holdning til at bryde' og bruger negativ test, bekræfter, at hvis systemet eller applikationen går i stykker. En negativ testteknik udføres ved hjælp af forkerte data, ugyldige data eller input. Det validerer, at hvis systemet kaster en fejl med ugyldig input og opfører sig som forventet.

# 31) Ikke-funktionel test

Det er en type test, som hver organisation har et separat team, der normalt kaldes som NFT-team (Non-Functional Test) eller Performance-team.

Ikke-funktionel test indebærer test af ikke-funktionelle krav såsom belastningstest, stresstest, sikkerhed, volumen, gendannelsestest osv. Formålet med NFT-test er at sikre, om svartiden til software eller applikation er hurtig nok i henhold til forretningskravet.

Det bør ikke tage meget tid at indlæse nogen side eller system og skal opretholdes under spidsbelastning.

# 32) Test af ydeevne

Dette udtryk bruges ofte ombytteligt med test af 'stress' og 'belastning'. Test af ydeevne gøres for at kontrollere, om systemet opfylder ydelseskravene. Forskellige ydelses- og belastningsværktøjer bruges til at udføre denne test.

# 33) Restitutionstest

Det er en type test, der validerer, hvor godt applikationen eller systemet kommer sig efter nedbrud eller katastrofer.

Recovery Testing bestemmer, om systemet er i stand til at fortsætte operationen efter en katastrofe. Antag, at applikationen modtager data via netværkskablet, og at netværkskablet pludselig er frakoblet.

En gang senere skal du tilslutte netværkskablet. så skulle systemet begynde at modtage data, hvorfra det mistede forbindelsen på grund af netværkskablet frakoblet.

# 34) Regressionstest

Test af en applikation som helhed til ændring i ethvert modul eller funktionalitet kaldes Regression Testing. Det er svært at dække hele systemet ind Regressionstest , så typisk Værktøjer til automatiseringstest bruges til disse typer af test.

# 35) Risikobaseret test (RBT)

I Risikobaseret test , testes funktionaliteterne eller kravene ud fra deres prioritet. Risikobaseret test inkluderer test af meget kritisk funktionalitet, som har den største indvirkning på forretningen, og hvor sandsynligheden for fiasko er meget høj.

Prioritetsbeslutningen er baseret på forretningsbehovet, så når først prioritet er indstillet for alle funktionaliteter, udføres højprioritetsfunktionalitet eller testsager først efterfulgt af mellem- og derefter lavprioritetsfunktioner.

Funktionen med lav prioritet kan testes eller ikke testes baseret på den tilgængelige tid.

Den risikobaserede test udføres, hvis der ikke er tilstrækkelig tid til at teste hele software, og software skal implementeres til tiden uden nogen forsinkelse. Denne tilgang følges kun af diskussion og godkendelse af klienten og den øverste ledelse af organisationen.

# 36) Test af sundhed

Sanity Testing gøres for at afgøre, om en ny softwareversion klarer sig godt nok til at acceptere den til en større testindsats eller ej. Hvis en applikation går ned til den første brug, er systemet ikke stabilt nok til yderligere test. Derfor tildeles en build eller en applikation til at rette den.

# 37) Sikkerhedstest

Det er en type test udført af et specielt team af testere. Et system kan gennemtrænges af enhver hacking måde.

Sikkerhedstest gøres for at kontrollere, hvordan softwaren eller applikationen eller webstedet er beskyttet mod interne og eksterne trusler. Denne test inkluderer, hvor meget software der er sikkert fra det ondsindede program, vira, og hvor sikker og stærk autorisations- og godkendelsesprocesserne er.

Det kontrollerer også, hvordan software opfører sig for ethvert hackersangreb og ondsindede programmer, og hvordan software vedligeholdes for datasikkerhed efter et sådant hackerangreb.

# 38) Røgtest

Når en ny build leveres af udviklingsteamet, validerer softwaretestteamet buildet og sikrer, at der ikke er noget større problem.

Testteamet sikrer, at bygningen er stabil, og et detaljeret testniveau udføres yderligere. Røgtest kontrollerer, at der ikke findes nogen mangel på propper i bygningen, hvilket forhindrer testteamet i at teste applikationen detaljeret.

Hvis testere finder ud af, at den vigtigste kritiske funktionalitet er opdelt i selve den indledende fase, kan testteamet afvise bygningen og informere i overensstemmelse hermed til udviklingsteamet. Røgtest udføres til et detaljeret niveau af enhver funktionstest eller regressionstest.

# 39) Statisk test

Statisk testning er en type test, der udføres uden nogen kode. Eksekveringen udføres på dokumentationen under testfasen.

Det involverer gennemgange, gennemgang og inspektion af projektets leverancer. Statisk test udfører ikke koden i stedet for kodesyntaxen, navngivningskonventioner kontrolleres.

Statisk testning gælder også for testtilfælde, testplan, designdokument. Det er nødvendigt at udføre statisk test af testteamet, da de defekter, der er identificeret under denne type test, er omkostningseffektive set fra projektperspektivet.

# 40) Stresstest

Denne test udføres, når et system er stresset ud over dets specifikationer for at kontrollere, hvordan og hvornår det fejler. Dette udføres under tung belastning som at lægge et stort antal ud over lagerkapacitet, komplekse databaseforespørgsler, kontinuerlig input til systemet eller databasebelastning.

hvad er black box test og whitebox test med eksempel

# 41) Systemtest

Under Systemtestteknik , testes hele systemet efter kravene. Det er en sort-boks-test, der er baseret på overordnede kravspecifikationer og dækker alle de kombinerede dele i et system.

# 42) Enhedstest

Test af en individuel softwarekomponent eller et modul kaldes Enhedstest . Det gøres typisk af programmøren og ikke af testere, da det kræver detaljeret viden om det interne programdesign og kode. Det kan også kræve udvikling af testdrivermoduler eller testseler.

# 43) Test af brugervenlighed

Under Usability Testing , Brugervenlighedskontrol er udført. Applikationsflowet testes for at vide, om en ny bruger let kan forstå applikationen eller ej. Korrekt hjælp dokumenteret, hvis en bruger sidder fast på et hvilket som helst tidspunkt. Grundlæggende kontrolleres systemnavigation i denne test.

# 44) Test af sårbarhed

Testen, der involverer identifikation af svaghed i softwaren, hardware og netværket, er kendt som sårbarhedstest. Ondsindede programmer, hackeren kan tage kontrol over systemet, hvis det er sårbart over for en sådan slags angreb, vira og orme.

Så det er nødvendigt at kontrollere, om disse systemer gennemgår sårbarhedstest inden produktion. Det kan identificere kritiske mangler, fejl i sikkerheden.

# 45) Volume Testing

Volumen test er en type ikke-funktionel test udført af Performance Testing-teamet.

Softwaren eller applikationen gennemgår en enorm mængde data, og Volume Testing kontrollerer applikationens systemadfærd og responstid, når systemet stødte på en så stor datamængde. Denne store datamængde kan påvirke systemets ydelse og hastighed på behandlingstiden.

# 46) White Box Testing

Test af hvid boks er baseret på viden om den interne logik i en applikations kode.

Det er også kendt som test af glasboks. Intern software og kode fungerer skal være kendt for at udføre denne type test. Under disse tests er baseret på dækningen af ​​kodeudtalelser, grene, stier, forhold osv.

Konklusion

Ovennævnte softwaretesttyper er kun en del af testningen. Der er dog stadig en liste med mere end 100+ testtyper, men alle testtyper bruges ikke i alle typer projekter. Så jeg har dækket nogle almindelige typer softwaretest, der mest bruges i testets livscyklus.

Der er også alternative definitioner eller processer, der anvendes i forskellige organisationer, men det grundlæggende koncept er det samme overalt. Disse testtyper, processer og deres implementeringsmetoder ændrer sig, når og når projektet, kravene og omfanget ændres.

Anbefalet læsning

^