Articles

Røgtestning vs Sanity Testing vs regressionstest forklaret

introduktion

en KVALITETSTESTERS levetid betragtes som ufuldstændig, hvis udtrykkene ‘Røgtest’, ‘Sanity Testing’ og ‘regressionstest’ ikke tilføres det. Selvom dette er nogle regelmæssigt anvendte udtryk, der er også nogle almindelige misforståelser omkring dem.

før vi begynder i detaljerne i røg, sanity og regression test og hvad de rent faktisk betyder, Lad os gå gennem nogle almindelige misforståelser og myter omkring dem:

  1. Røgtest og sundhedstest er de samme og kan bruges om hverandre : dette er ikke sandt og bør aldrig gøres, hvorfor? det vil vi diskutere i denne artikel.
  2. sundhedstest svarer til accepttestning: accepttest udføres for at sikre, at bygningen opfylder alle de krav, som klienten specificerede før frigivelsen, mens sundhedstest udføres for at sikre, at produktet er sundt, rationelt til mere detaljeret test. Disse er ikke og bør ikke bruges om hverandre.
  3. hvis jeg laver Røgtest, kan jeg springe over sanity test: Røgtestning er en test på meget højt niveau, som i, denne test udføres for at sikre, at denne bygning er egnet til at starte enhver anden type test. For eksempel kan dette kun være en test for at sikre, at build-installationerne og derefter kan Sanity-testen begynde. Selvom nogle gange, røg test cases køres sammen med Sanity Test cases, disse bør ikke forveksles med at være den ene og den samme ting.
  4. regressionstest er ikke relateret til Røgtest eller sundhedstest: i teorien er sundhedstest en delmængde af regressionstest. Nogle regressionstestsager med høj prioritet udgør normalt sanity test case.
  5. hvis jeg har til hensigt at køre den fulde regressionstestpakke – behøver jeg ikke køre nogen røgtest eller sanity test: selvom dette kan være sandt i nogle tilfælde, da Sanity test alligevel er en delmængde af regressionstest, er det stadig tilrådeligt at udføre sanity test cases først og derefter følge dem med resten af regressionstesttilfældene.

i denne artikel vil vi forsøge at rydde over forvirringer for en gang for alle.

Hvis du vil læse mere om manuel test, henvises til linket her.

Bemærk: fordi vi vil bruge udtrykket ‘Programbygning’ mange gange i artiklen, lad os definere det her. “Versionskontrol, kodekvalitet & kompilering ” og programmelopbygning er også resultatet af denne byggeproces. I denne artikel vil en build blive omtalt som en testbar version af programmet.

Røgtestning

Røgtestning er en tilgang, der normalt udføres i de indledende udviklingsstadier af PROGRAMUDVIKLINGENS livscyklus(SDLC) for at sikre, at kernefunktionaliteterne i et program fungerer fint uden problemer. Det udføres, før der udføres detaljerede funktionelle tests på programmet.

hovedformålet med røgtest er ikke at udføre dyb test, men at kontrollere, at kernen eller hovedfunktionaliteterne i programmet eller programmet fungerer fint. Røgtest sigter mod at afvise en dårligt brudt opbygning i den indledende fase, så testteamet ikke spilder tid på at installere & test af programmet.

røg test kaldes også som Build verifikation Test.

lad os se et simpelt eksempel, hvor du får en e-mail-applikation til test. De vigtige funktioner ville være at logge ind på e-mail-applikationen, komponere en e-mail og sende den, ikke? Og, hvis e-mailen ikke sendes, giver det nogen mening at teste andre funktionaliteter som kladder, slettede meddelelser, arkiver, etc? Dette betyder, at du bliver nødt til at droppe bygningen uden yderligere validering. Dette kaldes Røgprøvning.

hovedfokus for røgtest er at teste de kritiske områder og ikke den komplette applikation.

Hvornår skal man udføre Røgtestning

  • når udviklere leverer en ny opbygning til KVALITETSSIKRINGSTEAMET. En frisk bygning her betyder, når bygningen har nye ændringer foretaget af udviklerne.
  • når et nyt modul føjes til den eksisterende funktionalitet.

automatisering & Røgprøvning:

normalt er dette den type test, der udføres, før faktiske automatiseringstestsager kan køre. For organisationer, der har indbygget kontinuerlig test, svarer røgprøvning til en vellykket installation af bygningen til kørsel af testcases eller udførelse af den første testcase. Så dette er ikke en type test, der bevidst automatiseres, men hvis testautomatisering sættes på plads, kan testautomatiseringen kun køre med succes, når programmet har bestået røgtest. Eller på anden måde kan den første testsag, der udføres, mislykkes.

Sanity Testing

Sanity testing er en slags test, der udføres for at kontrollere, om et programprodukt fungerer korrekt, når et nyt modul eller funktionalitet implementeres til et eksisterende produkt. Sanity testing er en testteknik, der gør en hurtig evaluering af kvaliteten af programudgivelsen for at afgøre, om den er berettiget til yderligere testrunder eller ej.

Sanity test udføres normalt efter at have modtaget en forholdsvis stabil programbygning eller nogle gange, når en programbygning muligvis har gennemgået mindre ændringer i koden eller funktionaliteten. Den afgør, om end-to-end-prøvning af et programmelprodukt skal udføres yderligere eller ej.

Sanity testing er også en Overfladeniveaustest, der hjælper med at afgøre, om programmelbygningen er god nok til at videregive den til det næste niveau af test.

hvorfor udføre Sanity test

  • for at verificere og validere overensstemmelsen af nyligt tilføjede funktionaliteter og funktioner i eksisterende kode.
  • for at sikre, at de indførte ændringer ikke påvirker andre eksisterende funktionaliteter af produktet.
  • for at beslutte yderligere test kan fremføres eller ej.

Hvornår skal man udføre Sanity test

  • Build modtages efter mange regressioner, eller hvis der er en mindre ændring i koden.
  • bygningen modtages efter fejlrettelse.
  • lige før implementeringen på produktionen.

automatisering& Sanity Testing:

overvejer, Sanity test betragtes som en delmængde af regressionstest, det er de testsager, der kan automatiseres. En anbefalet tilgang er at udføre disse testsager, før du kører den komplette regressionstestpakke. Fordelen er, at hvis der er fejl i sanity test cases, så kan fejl rapporteres før snarere end senere.

regressionstest

regressionstest er verifikationen af “fejlrettelser eller ændringer i kravet” og sørger for, at de ikke påvirker andre funktioner i applikationen. Regressionstest er effektiv på automatisering og udføres normalt, efter at der er foretaget nogle ændringer i programopbygningen efter kravændringer eller fejlrettelser.

Når sundhedstest af den ændrede funktionalitet er afsluttet, kræver alle de påvirkede funktioner i applikationen fuldstændig test. Dette kaldes regressionstest.

Når fejlrettelser udføres i det eksisterende program, skal nogle testscenarier udføres for at verificere fejlrettelserne. Ud over disse skal KVALITETSSIKRINGSTEAMET også kontrollere de berørte områder baseret på kodeændringerne. I regressionstest skal alle disse testscenarier udføres for at tage sig af relaterede funktionaliteter.

hvornår skal man udføre regressionstest

  • efter Kodemodifikation i henhold til de krævede ændringer
  • efter at nogle nye funktioner er føjet til applikationen
  • efter at nogle fejlrettelser er indarbejdet i build

automatisering & regressionstest:

Regressionstestsager er faktisk de ideelle testsager til automat. Normalt, når en organisation starter automatisering, er dette de testsager, der først automatiseres. Hvis regressionstest er en aktivitet, der tager meget tid for dine testere, og de samme testsager gentages flere gange, er det på tide, at du også begynder at tænke på automatisering.

Hvis du leder efter et værktøj, der kan hjælpe dig med at komme i gang på din automatiseringsrejse, skal du også sikre dig, at du vælger det rigtige værktøj. Et værktøj, der også kan give dig ROI på indsatsen investeret. Vi har den guide, der kan hjælpe dig der:

10 Points to Help You Choose the Right Test Automation Tool

Differences Between Smoke vs Sanity vs Regression Testing

Smoke Testing Sanity Testing Regression Testing
Performed on initial builds Performed on stable builds Performed on stable builds
To test the stability of new build for at teste stabiliteten af ny funktionalitet eller kodeændringer i den eksisterende build for at teste funktionaliteten af alle berørte områder efter ny funktionalitet/kodeændringer i den eksisterende build
dækker ende til ende grundlæggende funktionaliteter dækker visse moduler, hvor der er foretaget kodeændringer dækker detaljeret test målrettet mod alle de berørte områder, efter at nye funktionaliteter er tilføjet
udført af testere & nogle gange også af udviklere udført af testere udført af testere, for det meste via automatisering
en del af grundlæggende test en del af regressionstest regressionstest er et super sæt røg-og sanity-test
udført normalt hver gang der er en ny build planlagt, når der ikke er nok tid til dybdegående test normalt udført, når testere har tid nok

nøglepunkter

  • røg-og sundhedstest hjælper kvalitetssikringsteamet med at spare tid ved hurtigt at teste for at sikre, om et program fungerer korrekt eller ej. Det sikrer også, at produktet er berettiget til yderligere test. Mens regressionstest hjælper med at øge tilliden til programmelkvaliteten efter en bestemt ændring. Især, at kodeændringerne ikke påvirker relaterede områder.
  • Røgtest udføres af både dev-teamet eller af KVALITETSSTYRINGSHOLDET og kan tages som en delmængde af streng test. Mens begge Sanity & regressionstest kun udføres af KVALITETSSTYRINGSHOLDET. Også, Sanity test kan betragtes som en delmængde af accept test.
  • Røgtest udføres i den indledende fase af SDLC for at kontrollere kernefunktionaliteterne i en applikation. Mens Sanity & regressionstest udføres i den sidste fase af SDLC for at kontrollere de vigtigste funktioner i en applikation.
  • i henhold til kravet om test& tid tilgængelighed, kan KVALITETSSIKRINGSTEAMET muligvis udføre sundhed, røg& regressionstest på deres programopbygning. I sådanne tilfælde udføres Røgtest først efterfulgt af Sanity test & derefter er der planlagt regressionstest baseret på tidstilgængelighed.

i praksis skal alle kvalitetssikringshold udføre røg -, Sanity-og regressionstest. Alle disse testtyper har et foruddefineret antal testsager, der udføres flere gange. Denne gentagne udførelse gør dem også til en ideel kandidat til testautomatisering. Når du leder efter automatisering, anbefales det at bruge et værktøj, der giver dig ROI på automatisering fra de indledende faser. Testsigma er et sådant værktøj.

Vælg et værktøj, der lader dig automatisere fra dag 1