7 principles software testing
Syv principper for softwaretest: Herunder flere detaljer om defektklynger, Pareto-princip og pesticidparadox.
Jeg er sikker på, at alle er opmærksomme på ' Syv principper for softwaretest ”.
Disse grundlæggende testprincipper hjælper testteamene med at udnytte deres tid og kræfter til at gøre testprocessen effektiv. I denne artikel vil vi lære detaljeret om to principper, dvs. Fejlklyngedannelse, Pareto-princip og pesticidparadox .
Hvad du lærer:
- Syv principper for softwaretest
Syv principper for softwaretest
Før vi får et dybtgående kig på disse to principper, lad os kort forstå de syv principper for softwaretest.
Lad os udforske !!
# 1) Test viser tilstedeværelsen af mangler
Hver applikation eller hvert produkt frigives i produktion efter en tilstrækkelig mængde test af forskellige teams eller passerer gennem forskellige faser som System Integration Testing, User Acceptance Testing og Beta Testing etc.
Så har du nogensinde set eller hørt fra nogen af testteamet, at de har testet softwaren fuldt ud, og at der ikke er nogen fejl i softwaren ? I stedet for det bekræfter hvert testteam, at softwaren opfylder alle forretningskrav, og at den fungerer efter slutbrugerens behov.
I softwaretestindustrien vil ingen sige, at det er der ingen fejl i softwaren, hvilket er ret sandt, da test ikke kan bevise, at softwaren er fejlfri eller fejlfri.
Formålet med test er imidlertid at finde flere og flere skjulte defekter ved hjælp af forskellige teknikker og metoder. Test kan afsløre uopdagede mangler, og hvis der ikke findes fejl, betyder det ikke, at softwaren er fejlfri.
Eksempel 1 :
Overvej en bankapplikation, denne applikation er grundigt testet og gennemgår forskellige testfaser som SIT, UAT osv., Og i øjeblikket identificeres der ingen mangler i systemet.
Der kan dog være en mulighed for, at den faktiske kunde i produktionsmiljøet prøver en funktionalitet, der sjældent bruges i banksystemet, og testerne overså den funktionalitet, og der blev derfor ikke fundet nogen fejl indtil dato, eller koden er aldrig blevet rørt af udviklere. .
Eksempel 2:
Vi har set adskillige reklamer for sæber, tandpasta, håndvask eller desinfektionsmiddel spray på mv.
Overvej en reklame for håndvask, der siger på fjernsynet, at 99% bakterier kan fjernes, hvis den specifikke håndvask bruges. Dette beviser tydeligt, at produktet ikke er 100% kimfrit. Således i vores testkoncept kan vi sige, at ingen software er fejlfri.
# 2) Tidlig testning
Testere er nødt til at blive involveret i et tidligt stadium af Software Development Life Cycle (SDLC). Således kan fejlene under fase-analysefasen eller eventuelle dokumentationsfejl identificeres. Omkostningerne ved afhjælpning af sådanne mangler er meget mindre sammenlignet med dem, der findes i de senere testfaser.
Overvej nedenstående billede, som viser, hvordan omkostningerne ved mangelfiksering øges, når test bevæger sig mod den levende produktion.
[billede kilde ]
Ovenstående billede viser, at omkostningerne, der kræves til at rette en fejl, der er fundet under kravanalysen, er mindre, og de fortsætter med at stige, når vi bevæger os mod test- eller vedligeholdelsesfasen.
Nu er spørgsmålet hvor tidligt skal testen starte ?
Når kravene er afsluttet, skal testerne involvere sig til testningen. Testning skal udføres på kravsdokumenter, specifikationer eller andre typer dokumenter, så hvis krav defineres forkert, kan det rettes med det samme i stedet for at rette dem i udviklingsfasen.
# 3) Udtømmende test er ikke mulig
Det er ikke muligt at teste alle funktionaliteter med alle gyldige og ugyldige kombinationer af inputdata under faktisk testning. I stedet for denne tilgang betragtes test af et par kombinationer baseret på prioritet ved hjælp af forskellige teknikker.
Udtømmende test kræver ubegrænset indsats, og de fleste af disse bestræbelser er ineffektive. Projektets tidslinjer tillader heller ikke test af så mange antal kombinationer. Derfor anbefales det at teste inputdata ved hjælp af forskellige metoder som Equivalence Partitioning og Boundary Value Analysis.
For eksempel ,Hvis vi antager, at vi kun har et indtastningsfelt, der accepterer alfabeter, specialtegn og tal fra 0 til 1000. Forestil dig, hvor mange kombinationer der vises til test, det er ikke muligt at teste alle kombinationer for hver inputtype.
Testindsatsen, der kræves for at teste, vil være enorm, og det vil også påvirke projektets tidslinje og omkostninger. Derfor siges det altid, at udtømmende test praktisk talt ikke er mulig.
# 4) Test er kontekstafhængig
Der er flere domæner til rådighed på markedet som bank, forsikring, medicinsk, rejse, reklame osv., Og hvert domæne har en række applikationer. Også for hvert domæne har deres applikationer forskellige krav, funktioner, forskellige testformål, risiko, teknikker osv.
Forskellige domæner testes forskelligt, og test er således udelukkende baseret på domænet eller applikationens kontekst.
hvordan man kan være programmør for begyndere
For eksempel ,at teste en bankapplikation er anderledes end at teste enhver e-handel eller reklameapplikation. Risikoen forbundet med hver type applikation er forskellig, så det er ikke effektivt at bruge den samme metode, teknik og testtype til at teste alle typer applikationer.
# 5) Fejlklyngedannelse
Under test kan det ske, at de fleste defekter er relateret til et lille antal moduler. Der kan være flere grunde til dette, da modulerne kan være komplekse, kodning relateret til sådanne moduler kan være kompliceret osv.
Dette er Pareto-princippet om softwaretest, hvor 80% af problemerne findes i 20% af modulerne. Vi lærer mere om defektklynger og Pareto-princip senere i denne artikel.
# 6) Pesticidparadoks
Pesticidparadoxprincippet siger, at hvis det samme sæt testsager udføres igen og igen i løbet af tidsperioden, er disse testsæt ikke i stand til at identificere nye defekter i systemet.
For at overvinde dette 'Pesticidparadox' skal testen af sager regelmæssigt gennemgås og revideret. Om nødvendigt kan et nyt sæt testsager tilføjes, og de eksisterende testsager kan slettes, hvis de ikke er i stand til at finde flere mangler fra systemet.
# 7) Fravær af fejl
Hvis softwaren testes fuldt ud, og hvis der ikke findes fejl inden frigivelsen, kan vi sige, at softwaren er 99% fejlfri. Men hvad nu hvis denne software testes mod forkerte krav? I sådanne tilfælde vil det endda ikke hjælpe at finde fejl og rette dem til tiden, da test udføres på forkerte krav, som ikke svarer til slutbrugerens behov.
For eksempel, Antag, at applikationen er relateret til et e-handelswebsted og kravene til funktionaliteten 'Indkøbskurv eller indkøbskurv', som fejlagtigt fortolkes og testes. Selv det at finde flere mangler hjælper ikke med at flytte applikationen til den næste fase eller i produktionsmiljøet.
Dette er de syv principper for softwaretest.
Lad os nu udforske Fejlklyngedannelse, Pareto-princip og pesticidparadoks i detalje .
Fejlklyngedannelse
Under testning af enhver software støder testerne hovedsagelig på en situation, hvor de fleste af de fundne mangler er relateret til en bestemt specifik funktionalitet, og resten af funktionaliteterne vil have et lavere antal defekter.
Fejlklynger betyder et lille antal moduler, der indeholder de fleste af manglerne. Dybest set er manglerne ikke fordelt ensartet på tværs af hele applikationen, snarere er defekter koncentreret eller centraliseret over to eller tre funktioner.
Til tider er det muligt på grund af applikationens kompleksitet, kodning kan være kompleks eller vanskelig, en udvikler kan begå en fejl, der kun kan påvirke en bestemt funktionalitet eller et modul.
Fejlklyngedannelse er baseret på “ Pareto-princip ”Som også er kendt som 80-20 regel . Det betyder, at 80% af de fundne mangler skyldes 20% af modulerne i applikationen. Begrebet Pareto Principle blev oprindeligt defineret af en italiensk økonom - Vilfrodo Pareto .
Hvis testere ser på 100 defekter, vil det ikke være klart, om der er nogen underliggende betydning mod disse 100 defekter. Men hvis disse 100 defekter er kategoriseret efter nogle specifikke kriterier, kan det være muligt for testerne at forstå, at et stort antal defekter kun hører til meget få specifikke moduler.
For eksempel ,lad os overveje nedenstående billede, som er testet for en af bankapplikationerne, og det viser, at de fleste af manglerne er relateret til 'Overtræk' -funktionaliteten. Resten af funktionerne som kontosammendrag, pengeoverførsel, stående instruktion osv. Har et begrænset antal mangler.
[billede kilde ]
Ovenstående billede angiver, at der er 18 defekter omkring Overdraft-funktionaliteten ud af de samlede 32 defekter, hvilket betyder, at 60% af manglerne findes i “Overtræk” -modulet.
Derfor koncentrerer testere sig mest om dette område under udførelsen for at finde flere og flere mangler. Det anbefales, at testerne også har samme fokus på de andre moduler under testningen.
Når en og samme kode eller modul testes igen og igen ved hjælp af et sæt testtilfælde end under de indledende iterationer, er antallet af mangler højt, men efter en vis iteration reduceres antallet af mangler betydeligt. Fejlklyngning indikerer, at det defekte udsatte område skal testes grundigt under regressionstest.
Pesticidparadoks
Når et af modulerne viser sig at have flere defekter, lægger testerne en ekstra indsats for at teste dette modul.
Efter et par gentagelser af test forbedres kodekvaliteten, og antallet af mangler begynder at falde, da de fleste af manglerne er rettet af udviklingsholdet, da udviklerne også er forsigtige med at kode et bestemt modul, hvor testerne fandt flere mangler.
Derfor på et tidspunkt opdages og repareres de fleste af manglerne, så der ikke findes nye fejl i modulet.
Imidlertid kan det til tider ske, at mens man er ekstra forsigtig under kodning på et bestemt modul (her i vores tilfælde ' Overtræk ”Modul), kan udvikleren forsømme de andre moduler til at kode det ordentligt, eller de ændringer, der er foretaget i det pågældende modul, kan have en negativ indvirkning på de andre funktioner som kontosammendrag, pengeoverførsel og stående instruktioner.
Når testerne bruger det samme sæt testtilfælde til at udføre modulet, hvor de fleste af manglerne findes (Overtræk-modul), så er testsagerne ikke meget effektive til at finde nye mangler efter at have rettet disse mangler af udviklerne. Som ende til slut-strømmen af Overdraft testes modulet grundigt, og udviklerne har også skrevet koden til dette modul med forsigtighed.
Det er nødvendigt at revidere og opdatere disse testsager. Det er også en god ide at tilføje nye testtilfælde, så nye og flere mangler kan findes i forskellige områder af software eller applikation.
Forebyggende metoder til pesticidparadoks
Der er to muligheder, hvorigennem vi kan forhindre pesticidparadoks som vist nedenfor:
til) Skriv et nyt sæt testsager, der fokuserer på forskellige områder eller moduler (andet end tidligere defekt udsat modul - Eksempel: “Overtræk”) af softwaren.
b) Forbered nye testsager, og tilføj til de eksisterende testsager.
I “ metode A ”, Kan testere finde flere defekter i de andre moduler, hvor de ikke var fokuseret under den tidligere test, eller udviklerne ikke var ekstra forsigtige under kodningen.
I vores ovenstående eksempel kan testere finde flere mangler i modulerne Kontosammendrag, Overførsel af penge eller Stående instruktioner ved hjælp af det nye sæt testsager.
Men det kan ske, at testere kan forsømme det tidligere modul ( Eksempel: “Overtræk”) hvor de fleste af manglerne blev fundet i den tidligere iteration, og dette kunne være en risiko, da dette modul (Overtræk) muligvis er blevet injiceret med de nye defekter efter kodning af de andre moduler.
I “ metode B ”, Nye testcases udarbejdes, så nye potentielle mangler kan findes i resten af modulerne.
Her i vores eksempel vil nyoprettede testsager være i stand til at hjælpe med at identificere mangler i modulerne som Kontosammendrag, Overførsel af penge og Stående instruktion. Testere kan dog ikke ignorere de tidligere defekte udsatte moduler ( Eksempel: ”Overtræk”), da disse nye testsager flettes sammen med de eksisterende testsager.
De eksisterende testsager var mere fokuseret på “Overtræk” -modulet, og de nye testsager var fokuseret på de andre moduler. Derfor udføres alle sæt testsager mindst én gang, selv en kodeændring sker på ethvert modul. Dette vil sikre, at korrekt regression bliver udført, og manglen kan identificeres på grund af denne kodeændring.
Ved hjælp af den anden tilgang går det samlede antal testsager markant højt og resulterer i mere indsats og tid, der kræves til udførelse. Dette vil naturligvis påvirke projektets tidslinjer og vigtigst af alt også på projektbudgettet.
For at overvinde dette problem kan de overflødige testsager gennemgås og derefter fjernes. Der er mange testsager, som bliver ubrugelige efter tilføjelse af nye testsager og ændring af de eksisterende testsager.
Det er nødvendigt at kontrollere, hvilke testsager der mislykkes for at identificere manglerne i de sidste 5 iterationer (lad os antage 5 iterationer), og hvilke testsager der ikke er meget vigtige. Det kan også være tilfældet, at den enkelte strømning, der er dækket i nogle få testtilfælde, kan dækkes i en anden ende til slutafgangssag, og de testtilfælde, der har en enkelt strømning, kan fjernes.
Dette vil igen reducere det samlede antal testsager.
For eksempel ,Vi har 50 testsager, der dækker et bestemt modul, og vi har set, at ud af disse 50 testsager 20 testsager ikke har fundet en ny defekt i de sidste par test-iterationer (lad os antage 5 iterationer). Så disse 20 testsager skal gennemgås grundigt, og vi er nødt til at kontrollere, hvor vigtige disse testsager er, og der kan træffes en beslutning i overensstemmelse hermed, om vi skal beholde de 20 testsager eller fjerne dem.
Inden du fjerner en testtilfælde, skal du kontrollere, at funktionalitetsstrømmen, der er dækket af disse testsager, er dækket af en anden testtilfælde. Denne proces skal følges på tværs af alle moduler, så det samlede antal testsager reduceres betydeligt. Dette vil sikre, at den samlede optælling af testsagerne reduceres, men der er stadig 100% kravsdækning.
Det betyder, at alle de resterende testsager dækker alle forretningskrav, og der er derfor ikke noget kompromis med kvaliteten.
Konklusion
Softwaretest er et vigtigt skridt i SDLC, da det verificerer, om softwaren fungerer efter den endelige brugers behov eller ej.
Test identificerer så meget defekt som muligt. Derfor, for at udføre test effektivt og effektivt, bør alle være opmærksomme på og forstå de syv principper for softwaretest tydeligt, og de er kendt som søjlerne til testning.
De fleste testere har implementeret og oplevet disse principper under faktisk testning.
Generelt betyder udtrykket princip de regler eller love, der skal følges. Derfor skal alle i softwaretestindustrien følge disse syv principper, og hvis nogen ignorerer nogen af disse principper, kan det koste enormt for projektet.
God læselyst!!
Anbefalet læsning
- Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
- Software Testning QA Assistant Job
- Software Testing Course: Hvilket Software Testing Institute skal jeg tilmelde mig?
- Valg af softwaretest som din karriere
- Softwaretest Teknisk indhold Writer Freelancer Job
- Hvad er defektbaseret testteknik?
- Nogle interessante spørgsmål om software-test Interview
- Software Testing Course Feedback og anmeldelser