De mange typer software testmetoder

Før software går offentligt, bruger programmører timer på at forsøge at stryge ud hver lille fejl. Indtil produktet opfylder alle interessenter, vil det ikke være tilgængeligt til kommerciel brug.

Store softwarefirmaer, som Google, lykkes på trods af lavprioriterede fejl i deres software, fordi de har tålmodige investorer og loyale brugere. Mindre virksomheder og startups har imidlertid ikke den luksus. Kunder forventer, at produkterne gør hvad de hævder på salgssiden eller i dokumentationen. Med så mange muligheder derude, tænker de ikke to gange om hoppeskib, hvis produktet spilder deres tid og penge. Derfor underkastes software stringente tests før udgivelse for at:

• fremhæve forskelle mellem det oprindelige koncept og den endelige produktion
• Kontroller, at softwaren fungerer som designere planlagt
• validere, at slutproduktet opfylder kundernes krav
• vurdere funktioner og kvalitet

Testning følger en streng plan for at optimere medarbejdernes færdigheder, tid og penge, samtidig med at interessenter får vigtige oplysninger til at tage produktet videre. Målet er at lette en god slutbrugeroplevelse gennem et stærkt kvalitetssikringsprogram.Med indsatsen så højt er QA-cheferne nogle af de bedste medarbejdere i teknologibranchen. Testning følger normalt disse trin:

1. Kravsanalyse, hvor ledere beskriver en plan for at sætte en passende teststrategi på plads.
2. Test begynder og resultater gennemgår analyse.
3. Eventuelle defekter rettes, og softwaren går gennem regressionstest-et system for at kontrollere, at programmet stadig virker efter ændringer.
4. En test lukningsrapport angiver derefter hele processen og resultaterne.

Enkeltpersoner kan blive certificerede software testere gennem organisationer som BCS, The Chartered Institute for IT, ISTQB® (International Software Testing Qualifications Board) og ASQ (tidligere American Society for Quality).

Software Testing Methods

Black box og white box test er de to grundlæggende metoder til at bedømme produktadfærd og ydeevne, men der er også andre metoder.

• Black box test: Også kaldet funktionel eller specifikationsbaseret test, fokuserer denne metode på output. Testere er ikke bekymrede over de interne mekanismer. De kontrollerer kun, at softwaren gør hvad den skal gøre. Kendskab til kodning er ikke nødvendig, og testere arbejder på brugergrænsefladeniveau.
• Hvid boks test: Denne metode bruger kodningsteknologi som en del af testproceduren. Når et produkt fejler, går testerne så dybt ind i koden som nødvendigt for at finde årsagen. Softwareudviklerne gør det selv, da de bestemmer, hvordan produktet skal fungere. Struktur-baserede og glas boks test er andre navne til denne metode.

• Statisk testning: Testere undersøger softwareens kode og dokumentation, men gennemfører ikke programmet. Statiske test begynder tidligt i produktets udvikling under verifikationsprocessen.
• Dynamisk test: Softwaren udføres med forskellige input, og testere sammenligner output med forventet adfærd med denne metode.
• Grafisk brugergrænseflade test: Dette tester GUI karakteristika som tekstformatering, tekstbokse, knapper, lister, layout, farver, skrifttyper, skriftstørrelser og så videre. GUI-test er tidskrævende, og tredjepartsvirksomheder tager ofte opgaven i stedet for udviklere.

Testniveauer

Forskellige niveauer af test bruges til at identificere områder af svaghed og overlapning i hver fase af softwarens udviklingslivscyklus.

• Enhedstestning: Udviklere teste de mest grundlæggende dele af kode som klasser, grænseflader og funktioner / procedurer. De ved, hvordan deres kode skal svare og kan foretage justeringer afhængigt af output.
• Komponent test: Andre navne er modul- eller programtest. Det ligner enhedsprøvning, men indeholder et højere integrationsniveau. Modulerne i softwaren testes for defekter for at verificere deres individuelle funktion.
• Integrationstest: Dette identificerer fejl, når moduler er integreret. Forskellige integrationstest er bottom up, top down og functional incremental.

• Systemtest: Komponenter af et projekt testes som helhed i forskellige miljøer med denne metode. Det falder under den sorte boks metode og er en af ​​de endelige prøver i processen. Det afgør, om systemet fungerer som det skal for at opfylde forretnings- og brugernes behov.
• Alpha testning: Internt personale tester softwaren på udviklerens websted i et simuleret eller faktisk miljø. Derefter korrigere udviklere fejl og andre problemer.
• Betatestning: Også kendt som feltprøvning, testes klienter produktet på deres egne websteder i reelle forhold. Kunderne kan tilbyde en gruppe af slutbrugere mulighed for at teste softwaren via prerelease- eller beta-versioner. Tilbagemelding om mulige forbedringer sendes derefter til udvikleren.

• Acceptanstest: Også under omfanget af sorte boks test, klienter test software for at finde ud af, om udvikleren har oprettet programmet til ønskede specifikationer.

Testtyper

Forskellige typer af software tests er designet til at fokusere på specifikke mål.

• Installationstest: Software testingeniør og konfigurationsleder udfører denne test for at sikre, at slutbrugeren kan installere og køre programmet. Det dækker områder som installationsfiler, installationssteder og administrative rettigheder.
• Udviklingstestning: Dette implementerer en række synkroniserede strategier til at opdage og forhindre fejl. Den omfatter statisk kodeanalyse, peer code reviews, sporbarhed og metrics analyse. Målet er at reducere risici og spare omkostninger.
• Usability test: Brugeroplevelsen kommer under fokus med denne test. Det måler, hvor godt GUI er designet og dets brugervenlighed. Testen kontrollerer nøjagtigheden og effektiviteten af ​​funktioner og de følelsesmæssige responser af forsøgspersoner.

• Sanity test: Dette indikerer, om softwaren er værden tid og omkostninger for at fortsætte yderligere test. Hvis der er for mange fejl, vil ikke mere aggressive tests følge.
• Røgtestning: Røgtest afslører grundlæggende fejl, der er alvorlige nok til at forhindre frigivelse. Når dette udføres på en ny bygning, kaldes det en build verifikationstest.
• Regressionstestning: Når systemet undergår ændring, overvåger regressionstesten uventet opførsel. Det påpeger bivirkninger på moduler eller komponenter.
• Destruktive test: Testere indtaster unormale indgange og skelner softwareens evne til at håndtere uventet input. Dette viser udviklere, hvor robuste programmet er ved fejlhåndtering.
• Recovery test: Når hardware eller andre funktioner fejler, viser denne test, hvor godt softwaren kan gendanne og fortsætte driften.
• Automatiseret test: Dette udfører funktioner, der er vanskelige at implementere manuelt. Det bruger specifik software til at køre testen og til at levere data om faktiske versus forventede resultater.
• Kompatibilitetstestning: Software skal køre i forskellige computermiljøer, så det kontrollerer kompatibilitet med forskellige systemer. For eksempel arbejder softwaren med forskellige operativsystemer og webbrowsere?
• Præstationsprøvning: Dette er en dybtgående test, der undersøger software ydeevne i forskellige scenarier. Oplysninger om lydhørhed, stabilitet, ressourceallokering og hastighed indsamles. Desuden spiller subtests som volumen, kapacitet og spike test en rolle i denne proces.
• Sikkerhedsprøvning: Dette måler softwareens evne til at beskytte brugernes sikkerhed. Dette betyder autorisationsfunktioner, autentificering, fortrolighed, integritet, tilgængelighed og nonrepudiation.
• Tilgængelighedstest: Dette er ikke det samme som brugervenlighedstest. Dette bestemmer i hvilket omfang brugere af forskellige evner-læring og fysiske handicap inkluderet kan bruge softwaren.
• Internationalisering og lokaliseringstestning: Resultaterne viser, hvordan softwaren kan tilpasse sig forskellige sprog og regionale krav. Dette omfatter at tilføje komponenter til bestemte steder og oversætte tekst.