Hva er røyktesting?

Hva er røyktesting?

Røykprøving er en programvaretestprosess som avgjør om den distribuerte programvarebyggingen er stabil eller ikke. Røyktesting er en bekreftelse for QA-teamet om å fortsette med ytterligere programvaretesting. Den består av et minimalt sett med tester som kjøres på hver bygg for å teste programvarefunksjonalitet. Røyktesting er også kjent som "Build Verification Testing" eller "Confidence Testing."

Enkelt sagt betyr røyktesting å bekrefte at de viktige funksjonene fungerer, og at det ikke er noen hindringer i bygget som testes. Det er en mini- og rask regresjonstest av hovedfunksjonaliteten. Dette bidrar til å avgjøre om bygget har feil, slik at videre testing blir bortkastet tid og ressurser.

Sammenligne Testing av røyk vs tilregnelighet

Hvorfor utfører vi røyktesting?

Røyktesting spiller en viktig rolle i programvareutvikling, ettersom det sikrer at systemet er korrekt i de innledende fasene. På denne måten kan vi spare testarbeid. Først når røyktestingen er fullført, starter vi funksjonstesting.

• Alle iøynefallende severdigheter i bygget vil bli identifisert ved å utføre røyktesting.
• Ved hjelp av røyktesting identifiseres de fleste feilene i de første stadiene av programvareutvikling.
• Med røyktesting forenkler vi oppdagelse og retting av større feil.
• Ved røyktesting kan QA-teamet finne defekter i applikasjonsfunksjonaliteten som kan ha dukket opp av den nye koden.
• Røyktesting finner de største alvorlighetsdefektene.

Eksempel 1: Loggvindu: Kan gå til neste vindu med gyldig brukernavn og passord ved å klikke på send-knappen.

Eksempel 2: Brukeren kan ikke logge av nettsiden.

Når utfører vi røyktesting?

Disse fordelene materialiserer seg bare hvis sjekken utløses i riktig øyeblikk. Røyktesting utføres når nye funksjoner i programvaren utvikles og integreres med eksisterende bygg som distribueres i QA-/staging-miljøet. Det sikrer at alle kritiske funksjoner fungerer som de skal eller ikke. Diagrammet nedenfor viser hvordan et bygg når QA-miljøet før røyktestingen begynner.

I denne testmetoden distribuerer utviklingsteamet build-en i QA. Et delsett av testtilfeller tas og kjøres av testere mot de kritiske funksjonene i build-en. Disse seriene med testtilfeller er utformet for å avdekke feil som er i build-en. Hvis disse testene bestås, fortsetter QA-teamet med Funksjonell testing.

Enhver feil indikerer et behov for å håndtere systemet tilbake til utviklingsteamet. Hver gang det er en endring i konstruksjonen, utfører vi røyktesting for å sikre stabiliteten.

Eksempel: -Ny registreringsknapp legges til i påloggingsvinduet og build implementeres med den nye koden. Vi utfører røyktesting på nybygg.

Røyktestene kvalifiserer bygget for videre formell testing og er utformet for å demonstrere systemstabilitet og samsvar med krav. Hovedmålet er å oppdage større problemer tidlig. Et byggeprosjekt inkluderer alle datafiler, biblioteker, gjenbrukbare moduler og konstruerte komponenter som kreves for å implementere en eller flere produktfunksjoner.

Hva skjer hvis vi ikke utfører røyktesting

Hvis vi ikke utfører røyktesting i tidlige stadier, kan det oppstå feil i senere stadier som kan bli kostbare. Defekt funnet i senere stadier kan være en hindring som påvirker utgivelsen av leveranser.

Hvem skal utføre røyktesting?

Etter å ha sluppet bygget til QA-miljøet, utføres røyktesting av QA-ingeniører/QA-leder. Når det er et nytt bygg, bestemmer QA-teamet hovedfunksjonaliteten i applikasjonen for å utføre røyktesting. QA-teamet ser etter showstoppere i applikasjonen som er under testing.

Hvordan utfører man røyktesting?

Røyktesting utføres vanligvis manuelt, selv om det er en mulighet for å oppnå det samme gjennom automatisering. Det kan variere fra organisasjon til organisasjon.

Manuell røyktesting

Røyktesting utføres for å sikre at navigeringen av kritiske stier er som forventet og ikke hindrer funksjonaliteten. Høyprioriterte funksjonstester tas og testes for å finne kritiske feil i systemet. Hvis testen består, fortsetter vi funksjonstestingen. Hvis testen mislykkes, avvises bygget og sendes tilbake til utviklingsteamet for korrigering.

QA starter røyktesting igjen med en ny build-versjon. Røyktesting utføres på nye builds og integreres med gamle builds for å opprettholde systemets korrekthet. Før røyktesting utføres, bør QA-teamet sjekke om det finnes riktige build-versjoner.

Røyktesting med automatisering

Automatiseringstesting brukes til RegresjonstestingVi kan imidlertid også bruke et sett med automatiserte testtilfeller for å kjøre mot Smoke Test. Ved hjelp av automatiseringstester kan utviklere sjekke byggingen umiddelbart, når det finnes en ny bygging klar for utrulling.

I stedet for å ha gjentatt test manuelt hver gang den nye programvarebygget er distribuert, utføres registrerte røyktestsaker mot bygget. Den verifiserer om hovedfunksjonene fortsatt fungerer som de skal. Hvis testen mislykkes, kan de korrigere bygningen og distribuere bygningen umiddelbart. På denne måten kan vi spare tid og sikre kvalitetsoppbygging til QA-miljøet.

Ved å bruke et automatisert verktøy registrerer testingeniøren alle manuelle trinn som utføres i programvarebyggingen.

Røyktestingssyklus

Flytskjemaet nedenfor viser hvordan røyktesting utføres. Når bygget er distribuert i QA og røyktestene er bestått, går vi videre til funksjonstesting. Hvis røyktesten mislykkes, avslutter vi testingen inntil problemet i bygget er løst.

Beste praksis for utforming av røyktesttilfeller

Å kjenne syklusen er én ting;ping Suiten som gjør den pålitelig er en annen. En røyksuite fortjener sin plass bare når den forblir kompakt, rask og repeterbar.

• Kartlegg de kritiske stiene først: List opp arbeidsflytene som gjør produktet kommersielt brukbart, som innlogging, søk, dataregistrering, betaling og utlogging. Hvis én av dem ikke fungerer, har bygget ingen verdi for en tester.
• Hold suiten grunn, men bred: Berør hver hovedmodul én gang i stedet for å utforske én modul i dybden. Grenseverdier, negative data og formuleringer i feilmeldinger hører hjemme i funksjonstesting, ikke her.
• Begrens utførelsestiden: De fleste lag holder løpet mellom ti og femten minutter og begrenser suiten til omtrent tjue til tretti test tilfellerEn løpetur som tar en time slutter å være en port og blir en flaskehals.
• Kjør de samme sakene på hver build: Konsistens lar deg tilskrive en feil til koden i stedet for et endret testvalg.
• Fjern ustabile og avhengighetstunge saker: En sak som består og mislykkes uten noen kodeendring ødelegger tilliten til porten. Stub eller simuler ustabile tredjepartstjenester der rammeverk for testautomatisering tillater.
• Skriv ned én utvetydig dom: Hvert tilfelle trenger et enkelt forventet resultat, slik at byggingen kan aksepteres eller avvises uten debatt.
• Versjon av suiten med build-filen: Lagre røyktilfellene i samme repository som applikasjonskoden, slik at porten alltid samsvarer med utgivelsen som testes.

RevSe pakken ved hver utgivelse: pensjoner saker for funksjoner som ikke lenger er viktige, og legg til nye kritiske arbeidsflyter.

Røyktesting i CI/CD-rørledninger

En pakke designet på denne måten er billig nok til å kjøre på hver eneste commit, noe som er det moderne levering krever. kontinuerlig integrering server som f.eks. Jenkins kompilerer koden, distribuerer den til et staging-miljø og utløser deretter smoke-suiten som det første automatiserte stadiet. En grønn kjøring flytter artefakten til funksjons- og regresjonsstadiene, mens en rød kjøring feiler pipelinen og varsler den forpliktende utvikleren innen få minutter.

To plasseringer er vanlige. En pre-merge-kjøring beskytter hovedgrenen ved å validere hver pull-forespørsel, og en post-distribusjonskjøring bekrefter at det distribuerte miljøet er tilgjengelig og riktig konfigurert. Team som praktiserer kontinuerlig distribusjon legger ofte til en tredje, trimmet kjøring mot produksjon umiddelbart etter utgivelse.

Fordi pipelinen kjører programpakken mange ganger om dagen, må sakene være ikke-interaktive, selvrensende og uavhengige. Enhver sak som venter på en menneskelig avgjørelse eller legger igjen testdata, vil stoppe pipelinen.

Fordeler med røyktesting

Her er noen fordeler oppført for røyktesting.

• Enkel å utføre og går raskt
• Kritiske feil og mangler er enkle å oppdage og korrigere i tidlige stadier.
• Forbedrer kvaliteten på systemet
• Reduserer risikoen
• Fremgang er lettere å vurdere.
• Sparer testinnsats og tid
• Minimerer integrasjonsrisiko

⚠ Begrensning å merke seg: En forbigående røyktest viser bare at bygget er testbart. Det berører hovedfunksjonaliteten overfladisk, så mindre defekter, kanttilfeller og sjelden brukte funksjoner forblir skjult inntil funksjonell testing og regresjonstesting kjøres. Behandle aldri et grønt røykresultat som tegn på at bygget er fritt for defekter.

Røyktesting vs. tilregnelighetstesting vs. regresjonstesting

Alle tre kjører etter en kodeendring, og det er derfor de ofte blir forvekslet. De varierer i omfang, dybde og spørsmålet hver enkelt besvarer.

Testing utført i et utviklingsmiljø på koden for å sikre at applikasjonen er korrekt før den slippes til QA, dette kalles Sanity-testing. Det er en prosess som verifiserer at applikasjonen under utvikling oppfyller de grunnleggende funksjonelle kravene.

Sanitetstesting bestemmer fullføringen av utviklingsfasen og tar en beslutning om å bestå eller ikke å bestå programvareprodukt for videre testfase.

UTGANGSPUNKT	RØYKPRØVE	TESTING AV FORSTAND	REGRESJONSTESTING
Omfang	Bred og grunn	Smal og dyp	Bred og dyp
Spørsmål besvart	Er denne konstruksjonen stabil nok til å testes?	Fungerer denne spesifikke løsningen?	Har noe som pleide å virke gått i stykker?
Sequence	Først, på hver bygging	Etter at røyktesten er bestått	Etter tilregnelighetstesting
Typisk varighet	10 til 15 minutter	30 til 60 minutter	Hours til dager
Automatiseringstilpasning	Veldig høy	Moderat, ofte manuelt	Veldig høy

I praksis kjøres de i rekkefølge: røyktesting for å godta byggingen, tilregnelighetstesting for å bekrefte den leverte endringen og regresjonstesting når tidsplanen tillater det.

Eksempel på røykprøver

Tabellen nedenfor dokumenterer en kort røykserie, én rad per kritisk bane.

T.ID	TESTSCENARIER	BESKRIVELSE	TESTTRINN	FORVENTET RESULTAT	FAKTISK RESULTAT	STATUS
1	Gyldig påloggingsinformasjon	Test innloggingsfunksjonaliteten til nettapplikasjonen for å sikre at en registrert bruker har lov til å logge på med brukernavn og passord	1. Start programmet 2. Naviger på påloggingssiden 3.Skriv inn gyldig brukernavn 4.Skriv inn gyldig passord 5. Klikk på påloggingsknappen	Innlogging skal være vellykket	som forventet	Pass
2	Legger til elementfunksjonalitet	Kan legge varen i handlekurven	1.Velg kategoriliste 2.Legg varen til handlekurven	Varen skal legges i handlekurven	Varen legges ikke i handlekurven	Fail
3	Logg ut funksjonalitet	Sjekk utloggingsfunksjonaliteten	1. velg Logg ut-knappen	Brukeren skal kunne logge av.	Brukeren kan ikke logge av	Fail

Spørsmål og svar