Røyk Testing vs Sanity Testing vs Regresjon Testing Forklart
Introduksjon
livet TIL EN QA Tester vil bli vurdert ufullstendig hvis begrepene ‘Røyk Testing’, ‘Tilregnelighet Testing’ og ‘Regresjon Testing’ ikke er infundert i det. Selv om disse er noen regelmessig brukte termer, er det noen vanlige misoppfatninger rundt dem også.
Før vi begynner på detaljer om røyk, sunnhet og regresjonstesting og hva de egentlig mener, kan vi gå gjennom noen vanlige misforståelser og myter rundt dem:
- Røyktesting og Sunnhetstesting er de samme og kan brukes om hverandre : Dette er ikke sant og bør aldri gjøres, hvorfor? vi skal diskutere det i Denne Artikkelen.
- Sanity Testing tilsvarer aksept testing: Aksept Testing er gjort for å sikre at bygge oppfyller alle kravene som klienten spesifisert før utgivelsen mens Sanity Testing er gjort for å sikre at produktet er tilregnelig, rasjonell for mer detaljert testing. Disse er ikke og bør ikke brukes om hverandre.
- Hvis Jeg Gjør Røyktesting, kan jeg hoppe over sunnhetstesting: Røyk testing er et meget høyt nivå testing, som i, denne testingen er gjort for å sikre at denne bygningen er egnet til å starte noen annen type testing. For eksempel kan dette bare være en test for å sikre at bygginstallasjonene, og Deretter Kan Sunnhetstesten begynne. Selv om røyktesttilfellene noen ganger kjøres sammen Med Sunnhetstesttilfeller, bør disse ikke forveksles med å være det samme.Regresjonstesting er ikke relatert Til Røyktesting Eller Sunnhetstesting: I Teorien er Sunnhetstesting en delmengde av regresjonstesting. Noen høyt prioriterte regresjonstesttilfeller utgjør vanligvis sanity test case. Jeg trenger ikke å kjøre noen røyktest eller sanity test: selv om dette kan være sant i noen tilfeller, Da Sanity Testing uansett er en delmengde av regresjonstesting, er det fortsatt tilrådelig å utføre sanity test-tilfellene først og deretter følge dem med resten av regresjonstesttilfellene.
i denne artikkelen vil vi prøve å fjerne over forvirringer for en gang for alle.
i tilfelle du vil lese mer Om Manuell Testing, se lenken her.
Merk: Fordi vi skal bruke begrepet ‘Software Build’ mange ganger i artikkelen, kan definere det her. ‘Software Build’ er en prosess for å konvertere kildekode, til en brukerapplikasjon, etter flere revisjoner og kodeendringer og Programvarebygging innebærer flere prosesser som «Versjonskontroll, Kodekvalitet & Compilation» og programvarebygging er også resultatet av denne byggeprosessen. I denne artikkelen vil en bygge bli referert til som en testbar versjon av programvaren.
Røyktesting
Røyktesting er en tilnærming som vanligvis utføres under de første utviklingsstadiene I PROGRAMVAREUTVIKLINGENS Livssyklus(SDLC) for å sikre at kjernefunksjonene i et program fungerer fint uten problemer. Det er utført før noen detaljerte funksjonstester er gjort på programvaren.hovedformålet med røyktesting er ikke å utføre dyp testing, men å verifisere at kjernen eller hovedfunksjonene i programmet eller programvaren fungerer bra. Røyk testing tar sikte på å avvise en dårlig ødelagt bygge i den innledende fasen, slik at testteamet ikke kaste bort tid på å installere & testing av programmet.
Røyk testing kalles Også Som Bygge Verifisering Test.
La oss se et enkelt eksempel der du får et e-postprogram for å teste. De viktige funksjonene vil logge inn på e-postprogrammet, skrive en e-post og sende den, ikke sant? Og hvis e-posten ikke sendes, gir det mening å teste andre funksjoner som utkast, slettede meldinger, arkiver, etc? Dette betyr at du må slippe bygningen uten ytterligere validering. Dette kalles Røyktesting.
hovedfokus for røyk testing er å teste de kritiske områdene og ikke hele programmet.
Når Du skal utføre Røyk Testing
- når utviklere gi en frisk bygge TIL QA teamet. En frisk bygge her betyr når bygge har nye endringer gjort av utviklerne.
- når en ny modul legges til eksisterende funksjonalitet.
Automatisering & Røyktesting:
Vanligvis er dette typen testing som utføres før faktiske automatiseringstesttilfeller kan kjøre. For organisasjon som har kontinuerlig testing innebygd, er røyk testing tilsvarer vellykket installasjon av bygge for å kjøre testtilfeller eller gjennomføring av den første testtilfelle. Så dette er ikke en type testing som er bevisst automatisert, men hvis testautomatisering er satt på plass, kan testautomatiseringen bare kjøre vellykket når programvaren har bestått røyktesting. Eller på annen måte kan det første testtilfellet som utfører mislykkes.
Sanity Testing
Sanity testing er en form for testing som utføres for å sjekke om et programvareprodukt fungerer som det skal når en ny modul eller funksjonalitet blir implementert i et eksisterende produkt. Sanity testing er en programvare testing teknikk som gjør en rask evaluering av kvaliteten på programvareutgivelsen for å avgjøre om det er kvalifisert for ytterligere runder med testing eller ikke.Sunnhetstesting utføres vanligvis etter å ha mottatt en ganske stabil programvarebygging eller noen ganger når en programvarebygging kan ha gjennomgått mindre endringer i koden eller funksjonaliteten. Den bestemmer om ende-til-ende testing av et programvareprodukt skal utføres videre eller ikke.
Sanity testing er også En Overflate Nivå Testing som hjelper i å avgjøre om programvaren bygge er god nok til å passere den til neste nivå av testing.
hvorfor Utføre Sanity Testing
- for å verifisere og validere samsvar med nylig lagt funksjonalitet og funksjoner i eksisterende kode.
- for å sikre at de innførte endringene ikke påvirker andre eksisterende funksjoner i produktet.
- for å bestemme videre testing kan gjennomføres videre eller ikke.
Når man skal utføre Sanity Testing
- Build mottas etter mange regresjoner eller hvis det er en mindre endring i koden.
- bygningen er mottatt etter feilretting.
- Like Før distribusjon på produksjon.
Automation& Sanity Testing:
Tatt I Betraktning Er Sanity Testing betraktet som en delmengde av regresjonstesting, dette er testtilfellene som kan automatiseres. En anbefalt tilnærming er å utføre disse testtilfeller før du kjører komplett regresjon test suite. Fordelen er at hvis det er noen feil i sanity test tilfeller, så feil kan rapporteres før heller enn senere.
Regresjonstesting
Regresjonstesting er verifisering av «feilrettinger eller endringer i kravet» og sørger for at de ikke påvirker andre funksjoner i applikasjonen. Regresjonstesting er effektiv på automatisering og utføres vanligvis etter at noen modifikasjoner er gjort i programvarebyggingen etter kravendringer eller feilrettinger.
Når Sunn fornuft testing av den endrede funksjonaliteten er fullført, alle de berørte funksjonene i programmet krever fullstendig testing. Dette kalles regresjonstesting.
Når feilrettinger er gjort i den eksisterende programvaren, må noen testscenarier utføres for å bekrefte feilrettingene. I tillegg til disse MÅ QA-teamet også sjekke de berørte områdene, basert på kodeendringene. I regresjonstesting må alle disse testscenariene utføres for å ta vare på relaterte funksjoner.
Når man skal Utføre Regresjonstesting
- Etter Kodemodifisering i henhold til de nødvendige endringene
- etter at noen nye funksjoner er lagt til i programmet
- Etter at noen feilrettinger er innlemmet i bygningen
Automasjon& Regresjonstesting:
Regresjonstesttilfeller er faktisk de ideelle testtilfellene for automat. Vanligvis, når en organisasjon starter automatisering, er disse testtilfellene som er automatisert først. Hvis regresjonstesting er en aktivitet som tar mye tid for testerne dine, og de samme testtilfellene gjentas flere ganger, er det på tide at du begynner å tenke på automatisering også.
hvis du leter etter et verktøy som kan hjelpe deg med å komme i gang med automatiseringsreisen din, må du også sørge for at du velger riktig verktøy. Et verktøy som også kan gi DEG ROI på innsatsen investert. Vi har guiden som kan hjelpe deg der:
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 for å teste stabiliteten til ny funksjonalitet eller kodeendringer i eksisterende bygg | for å teste funksjonaliteten til alle berørte områder etter ny funksjonalitet/kodeendringer i eksisterende bygg | Dekker ende-til-ende grunnleggende funksjoner | dekker visse moduler, Der Kodeendringer er gjort | dekker detaljert testing rettet mot alle de berørte områdene etter At Nye funksjoner er lagt til |
Utført av testere & Noen ganger Også av utviklere | Utført av testere, for det meste via automatisering | |
en del av regresjonstesting | regresjonstesting er et super sett med røyk-og sunnhetstesting | gjøres vanligvis hver gang det er en nybygg | planlagt når det ikke er nok tid for grundig testing | utføres vanligvis når testere har nok tid |
Nøkkelpunkter
- røyk og sunnhetstesting Hjelper qa-teamet med å spare tid ved å raskt teste for å sikre at et program fungerer som det skal eller ikke. Det sikrer også at produktet er kvalifisert for videre testing. Mens Regresjonstesting bidrar til å øke tilliten til programvarekvaliteten etter en bestemt endring. Spesielt at kodeendringene ikke påvirker relaterte områder.
i praksis må ALLE QA-lag gjøre Røyk, Sunnhet og Regresjonstesting. Alle disse testtypene har et forhåndsdefinert antall testtilfeller som blir utført flere ganger. Denne repeterende utførelsen gjør dem også til en ideell kandidat for testautomatisering. Når du ser etter automatisering, anbefales det å bruke et verktøy som gir DEG AVKASTNING på automatisering fra begynnelsen. Testsigma er et slikt verktøy.
Velg et verktøy som lar deg automatisere fra dag 1
Leave a Reply