Hva er Forskjellen Mellom Retesting Og Regresjonstesting:
elsker dere ikke alle sammenligne og kontrast tema artikler? Det vet jeg. Det er en fin måte å invitere tanker, kommentarer og kanskje til og med sterk uenighet.
Dagens tema Er Retesting Vs Regresjonstesting.
=> Klikk Her For Den Komplette Regresjonstestingsserien.
La oss begynne Med Retesting:
Retesting
Retest betyr å teste igjen. Årsaken spiller ingen rolle. Når du gjentar en test, prøver du på nytt. Du kan teste gjeldende versjon funksjonalitet. Eller en bug fix, tidligere versjon funksjonalitet, en test sak du nettopp kjørte, etc.
hvis du fortsatt tenker – hvorfor – så er følgende noen grunner som er like gode som noen:
- Du kjørte en test i går og kjørte inn i en feil. Du vil bekrefte trinnene og feilens reproduserbarhet. Så, du retest.
- du kjørte en test. Din oppmerksomhet var ikke på den(kanskje telefonen ringte, eller du snakket med en kollega, etc.). Du vil sjekke igjen, så du retest.
jeg er sikker på at du får det.
Retesting er Når du gjentar en test av en eller annen grunn. Det er en av de begrepene som holder seg til sin definisjon.
Regresjonstest
Programvaren utvikler seg. Det kommer til å være nye versjoner over eksisterende. Det er pæling på nye funksjoner, utvidelser, etc. Men over tid kan dette føre til ustabilitet i søknaden.
Forestill deg selv å lage et blokktårn, ved å legge en blokk over den andre. Du trenger ikke ta deg tid til å forsterke eller styrke basen. Det tar ikke lang tid før tårnet krasjer, ikke sant?
på samme måte må du teste programvarens base for styrke og stabilitet.
for å gjøre det, må vi teste programvaren på nytt. Det er den eneste måten.
Anbefalt les = > Hva Er Regresjonstesting? Verktøy Og Beste Praksis
Regresjon Er En Form For Retest. Spesifikasjonene Av «Hvorfor» Og » Når » er det som skiller det fra det tidligere.
1) Når tester vi på nytt? Når programvare gjennomgår en endring
2) Hvorfor tester vi på nytt? For å sikre at de nye tilleggene / endringene ikke har gjort før arbeidsfunksjonaliteten ustabil. Regresjon er vanlig og anbefales når:
- en ny versjon blir tilgjengelig. (Regress alle eller i det minste viktige av de eldre versjonsfunksjonene)
- Bug fix
Pek på merk: Uttømmende Regresjonstesting er umulig, men ønskelig.
Derfor Gjør Regresjonsanalyse før du hopper rett inn i testing. Dette trinnet innebærer å bestemme hvor mye regresjon jeg skal gjøre for søknaden min.
hva er omfanget av regresjon avhengig av?
- endringens Natur
- Forhold/påvirkning av endringen på dagens system/funksjon
- Tilgjengelig tid og ressurser
hvordan kan testere bestemme omfanget av regresjon?
1) gjennom erfaring og kjennskap til programmet
2) Diskutere med utviklerne
3) stedet der endringen er gjort. Eksempelvis: hvis det er på hjemmesiden, trenger det mer oppmerksomhet enn om det var i en av de mindre aksesserte sidene.
avhengig av faktorene som spilles, kan et testteam gå for ett av følgende:
- Unit Regresjon
- Delvis Regresjon
- Full Regresjon
Unit regresjon betyr at du bare tester den endrede modulen/området I programmet PÅ nytt.
Delvis regresjon betyr at du tester den endrede modulen på nytt. Pluss inkluderer de som samhandler med det.
Full regresjon er du teste hele programmet uavhengig av plasseringen av endringen.
det avhenger av situasjonen (tid & ressurs tilgjengelighet), alvoret av endringen( dens innvirkning), utviklerens innganger etc. Du vil bli mer effektiv når du velger riktig sett med tester vs. alle testene.
Regresjonsanalyse er den viktigste suksessfaktoren. Det trenger smart arbeid i stedet for hardt arbeid.
Misoppfatninger Om Regresjonstesting
Det er mange misoppfatninger om Regresjonstesting:
# 1) Regresjon gjøres alltid via automatisering: Nei. Regresjon gjøres også manuelt. Vi har en hel artikkel om dette => Hvordan Utføres Regresjonstesting? Kan Det Gjøres Manuelt?
merk at regresjon er en perfekt kandidat for automatisering. Omfanget av repetisjon er tidkrevende og kan føre til kjedsomhet. Også viktig validering kan bli savnet. Automatisering er et pålitelig, raskt og effektivt alternativ.
les også = > Utfordringer For Automatisert Regresjonstesting
#2) Regresjon er aldri fullført: Sant. Men ikke helt.
det jeg mener er, en uttømmende regresjonstest kan være umulig. Men uttømmende regresjonstesting kan også være unødvendig.
La oss si at du endret en feilstaving på hjemmesiden. Denne løsningen er mindre. Det er også isolert fra de andre områdene av søknaden. Så, en enkel retesting av funksjonen ville gjøre. Du trenger ikke å regress tidligere funksjonalitet rundt hjemmesiden.
# 3) det er unodvendig nar du har en knase for tiden: Ikke sant. Ikke nok regresjon fører til mangel på tillit til produktet. Du vil aldri vite hva du kan forvente fra sin reaksjon på ulike sluttbrukerscenarier.
#4) det kjører hvert eneste testfall av den forrige utgivelsen: igjen, å velge hvert testfall er ikke den riktige måten å gjøre dette på. Strategisk plukking av testtilfeller er nøkkelen. Forstå endringen og velge montering testtilfeller.
OK, Det Er Retesting og Regresjonstest i detalj.
nå, sammenligningen.
Retesting Vs Regresjonstesting
Hva er det samme med dem?
- de er begge repetisjonsbaserte
- Validerings-og Black box-testteknikker
- Automasjon eller Manuelle testtilfeller blir begge testet på nytt eller regressert
- «Man må verifisere eller utvise sine tvil, og konvertere dem Til vissheten Om Ja Eller NEI – Thomas Carlyle». Begge gjør dette.
hva er annerledes med dem?
- Retesting gjelder for alle test – Nåværende eller tidligere versjon funksjonalitet målrettet. Regresjon er tidligere versjon funksjonalitet sentrisk.
- Retesting er ikke avhengig av gjeldende endring. Regresjon er endringsorientert.
Til slutt, for å slå dette konseptet hjem:
la oss si at Du har Et Testfall XYZ som resulterte I EN feil MED ID 120. Denne feilen blir løst i neste versjon. DU vil teste XYZ test saken og regress funksjonaliteten rundt den. Regresjonen er å sørge for at alt fungerer intakt etter 120-tallet. Retesten er å bestemme feilens løsning.
så det er hverken det ene eller det andre, men kombinasjonen av regresjon og retesting som danner den dynamiske duoen.
Nå er det over til deg. Er du enig i definisjonene og analysene som er gitt her?
om forfatteren: denne artikkelen er skrevet Av sth teammedlem Swati S.