7 Principper for softwaretest med eksempler

Denne vejledning introducerer de syv grundlæggende softwaretestprincipper, som enhver softwaretester og kvalitetsekspert bør kende.

Lad os lære testprincipperne med følgende video eksempel-

Klik link. hvis videoen ikke er tilgængelig

Baggrund

Det er vigtigt, at du opnår optimale testresultater, mens du udfører softwaretest uden at afvige fra målet. Men hvordan afgør du, at du følger den rigtige teststrategi? Til det skal du holde dig til nogle grundlæggende testprincipper. Her er de almindelige syv testprincipper, der praktiseres bredt i softwareindustrien.

For at forstå dette, overvej et scenario, hvor du flytter en fil fra mappe A til mappe B.

Tænk på alle de mulige måder, du kan teste dette på.

Udover de sædvanlige scenarier kan du også teste følgende forhold

• Forsøger at flytte filen, når den er åben
• Du har ikke sikkerhedsrettighederne til at indsætte filen i mappe B
• Mappe B er på et fællesdrev, og lagerkapaciteten er fuld.
• Mappe B har allerede en fil med samme navn, faktisk er listen uendelig
• Eller antag, at du har 15 inputfelter at teste, hver med 5 mulige værdier, vil antallet af kombinationer, der skal testes, være 5^15

Hvis du skulle teste hele de mulige kombinationer, ville UDFØRELSESTID & OMKOSTNINGER stige eksponentielt. Vi har brug for visse principper og strategier for at optimere testindsatsen

Her er de 7 principper:

1) Udtømmende test er ikke mulig

Ja! Udtømmende test er ikke mulig. I stedet har vi brug for den optimale mængde af test baseret på risikovurderingen af ​​ansøgningen.

Og million dollar spørgsmålet er, hvordan bestemmer du denne risiko?

For at besvare dette lad os lave en øvelse

Efter din mening, Hvilken operation vil sandsynligvis forårsage din Operasvigter systemet?

Jeg er sikker på, at de fleste af jer ville have gættet, at åbne 10 forskellige applikationer på samme tid.

Så hvis du testede dette Operasystem, ville du indse, at defekter sandsynligvis vil blive fundet i multi-tasking aktivitet og skal testes grundigt, hvilket bringer os til vores næste princip Defekt ClusterING

2) Defekt ClusterING

Defekt Clustering, som angiver, at et lille antal moduler indeholder de fleste af de opdagede defekter. Dette er anvendelsen af ​​Pareto-princippet til softwaretest: ca. 80 % af problemerne findes i 20 % af modulerne.

Af erfaring kan du identificere sådanne risikable moduler. Men denne tilgang har sine egne problemer

Hvis de samme tests gentages igen og igen, vil de samme testcases til sidst ikke længere finde nye fejl.

3) Pesticidparadoks

Gentagen brug af den samme pesticidblanding til at udrydde insekter under opdræt vil over tid føre til, at insekterne udvikler resistens over for pesticidet. Derved ineffektive af pesticider på insekter. Det samme gælder softwaretest. Hvis det samme sæt gentagne tests udføres, vil metoden være ubrugelig til at opdage nye defekter.

For at overvinde dette skal testcaserne regelmæssigt gennemgås og revideres, og der skal tilføjes nye og anderledes testcases for at hjælpe med at finde flere defekter.

Testere kan ikke blot stole på eksisterende testteknikker. Han skal hele tiden se ud for at forbedre de eksisterende metoder for at gøre testen mere effektiv. Men selv efter alt dette sved og hårde arbejde i test, kan du aldrig hævde, at dit produkt er fejlfrit. For at køre hjem dette punkt, lad os se denne video af den offentlige lancering af Windows 98

Du tror, ​​at en virksomhed som MICROSOFT ikke ville have testet deres OS grundigt og ville risikere deres omdømme bare for at se deres OS gå ned under dets offentlige lancering!

4) Test viser tilstedeværelse af defekter

Derfor siger testprincippet, at - Test taler om tilstedeværelsen af ​​defekter og taler ikke om fravær af defekter. dvs Software Testing reducerer sandsynligheden for, at uopdagede defekter forbliver i softwaren, men selvom der ikke findes nogen defekter, er det ikke et bevis for rigtigheden.

Men hvad nu hvis du arbejder ekstra hårdt, tager alle forholdsregler og gør dit softwareprodukt 99 % fejlfrit. Og softwaren opfylder ikke kundernes behov og krav.

Dette fører os til vores næste princip, som siger, at - Fravær af fejl

5) Fravær af fejl – fejlslutning

Det er muligt, at software, som er 99 % fejlfri, stadig er ubrugelig. Dette kan være tilfældet, hvis systemet testes grundigt for det forkerte krav. Softwaretest er ikke blot at finde defekter, men også at kontrollere, at software imødekommer virksomhedens behov. Fraværet af fejl er en fejl, dvs. at finde og rette defekter hjælper ikke, hvis systembygningen er ubrugelig og ikke opfylder brugerens behov og krav.

For at løse dette problem siger det næste testprincip, at tidlig testning

6) Tidlig testning

Tidlig testning – Testning bør starte så tidligt som muligt i softwareudviklingens livscyklus. Således at eventuelle mangler i krav- eller designfasen fanges i tidlige faser. Det er meget billigere at rette en Defekt i de tidlige stadier af testen. Men hvor tidligt skal man begynde at teste? Det anbefales, at du begynder at finde fejlen i det øjeblik, kravene er defineret. Mere om dette princip i en senere træningsvejledning.

7) Test er kontekstafhængig

Test er kontekstafhængig, hvilket dybest set betyder, at den måde, du tester et e-handelswebsted på, vil være anderledes end den måde, du tester en reklame fra hyldeapplikationen. Alle de udviklede software er ikke identiske. Du kan bruge en anden tilgang, metoder, teknikker og typer af test afhængigt af applikationstypen. For eksempel vil ethvert POS-system i en detailbutik være anderledes end at teste en pengeautomat.

Myte: "Principper er kun til reference. Jeg vil ikke bruge dem i praksis."

Dette er så meget usandt. Testprincipper vil hjælpe dig med at skabe en effektiv Test strategi og udkast til fejlfangende testsager.

Men at lære testprincipper er ligesom at lære at køre for første gang.

I første omgang, mens du lærer at køre, er du opmærksom på alt, såsom gearskift, hastighed, koblingshåndtering osv. Men med erfaring fokuserer du bare på at køre resten kommer naturligt. Sådan at du endda fører samtaler med andre passagerer i bilen.

Det samme gælder for testprincipper. Erfarne testere har internaliseret disse principper til et niveau, så de anvender dem selv uden at tænke. Derfor er myten om, at principperne ikke bruges i praksis, simpelthen ikke sand.