Hvad er røgtestning?

Hvad er røgtestning?

Røgtest er en softwaretestproces, der afgør, om den installerede softwarebuild er stabil eller ej. Røgtest er en bekræftelse på, at QA-teamet kan fortsætte med yderligere softwaretest. Den består af et minimalt sæt test, der køres på hver build for at teste softwarefunktionaliteter. Røgtest er også kendt som "Build Verification Testing" eller "Confidence Testing".

Kort sagt betyder røgtestning at verificere, at de vigtige funktioner fungerer, og at der ikke er nogen hæmsko i det build, der testes. Det er en mini- og hurtig regressionstest af den primære funktionalitet. Dette hjælper med at afgøre, om buildet er fejlbehæftet, så yderligere testning bliver spild af tid og ressourcer.

Sammenlign Røg vs sundhedstest

Hvorfor udfører vi røgtest?

Røgtestning spiller en vigtig rolle i softwareudvikling, da det sikrer systemets korrekthed i de indledende faser. På denne måde kan vi spare testindsatsen. Først når vi er færdige med røgtestningen, begynder vi funktionstesten.

• Alle iøjnefaldende seværdigheder i bygningen vil blive identificeret ved at udføre røgtest.
• Ved hjælp af røgtestning identificeres de fleste defekter i de indledende stadier af softwareudvikling.
• Med røgtest forenkler vi opdagelse og udbedring af større fejl.
• Ved røgtestning kan QA-teamet finde defekter i applikationsfunktionaliteten, som kan være dukket op af den nye kode.
• Røgtest finder de største alvorlige defekter.

Eksempel 1: Logningsvindue: Kan flytte til næste vindue med gyldigt brugernavn og adgangskode ved at klikke på send-knappen.

Eksempel 2: Brugeren kan ikke logge ud fra websiden.

Hvornår udfører vi røgtest?

Disse fordele realiseres kun, hvis kontrollen udløses på det rette tidspunkt. Røgtestning udføres, når nye softwarefunktioner udvikles og integreres med eksisterende build, der implementeres i QA-/staging-miljøet. Det sikrer, at alle kritiske funktioner fungerer korrekt eller ej. Diagrammet nedenfor viser, hvordan et build når QA-miljøet, før røgtestningen begynder.

I denne testmetode implementerer udviklingsteamet buildet i QA. En delmængde af testcases tages og køres af testere mod buildets kritiske funktioner. Disse serier af testcases er designet til at afsløre fejl, der er i buildet. Hvis disse tests bestås, fortsætter QA-teamet med Funktionstest.

Enhver fejl indikerer et behov for at håndtere systemet tilbage til udviklingsteamet. Når der er en ændring i bygningen, udfører vi røgtest for at sikre stabiliteten.

Eksempel: -Ny registreringsknap tilføjes i login-vinduet og build implementeres med den nye kode. Vi udfører røgtest på nybyggeri.

Røgtestene kvalificerer buildet til yderligere formel testning og er designet til at demonstrere systemstabilitet og overholdelse af krav. Hovedformålet er at opdage større problemer tidligt. Et build inkluderer alle datafiler, biblioteker, genanvendelige moduler og konstruerede komponenter, der er nødvendige for at implementere en eller flere produktfunktioner.

Hvad sker der, hvis vi ikke udfører røgtest

Hvis vi ikke udfører røgtest i de tidlige stadier, kan der opstå fejl i senere stadier, hvor det kan være dyrt. Defekt findes i senere stadier, kan være en hindring, der påvirker frigivelsen af ​​leverancer.

Hvem skal udføre røgtest?

Efter frigivelse af build til QA-miljø udføres røgtestning af QA-ingeniører/QA-leder. Når der er en ny build, bestemmer QA-teamet den vigtigste funktionalitet i applikationen for at udføre røgtest. QA-teamet tjekker for showstoppere i den applikation, der testes.

Hvordan udfører man en røgtest?

Røgtest udføres normalt manuelt, selvom der er mulighed for at opnå det samme gennem automatisering. Det kan variere fra organisation til organisation.

Manuel røgtestning

Røgtestning udføres for at sikre, at navigationen af ​​kritiske stier er som forventet og ikke hæmmer funktionaliteten. Der tages højprioriterede funktionstesttilfælde, som testes for at finde de kritiske defekter i systemet. Hvis testen består, fortsætter vi den funktionelle testning. Hvis testen fejler, afvises buildet og sendes tilbage til udviklingsteamet til korrektion.

QA starter igen røgtestning med en ny build-version. Røgtestning udføres på nye builds og integreres med gamle builds for at opretholde systemets korrekthed. Før røgtestning udføres, bør QA-teamet kontrollere, om build-versionerne er korrekte.

Røgtestning via automatisering

Test af automatisering bruges til RegressionstestVi kan dog også bruge et sæt automatiserede testcases til at køre mod Smoke Test. Ved hjælp af automatiseringstests kan udviklere tjekke build'et med det samme, når der er et nyt build klar til implementering.

I stedet for at have gentaget test manuelt, hver gang den nye software build er implementeret, udføres registrerede røgtestsager mod buildet. Det verificerer, om de vigtigste funktioner stadig fungerer korrekt. Hvis testen mislykkes, kan de rette bygningen og geninstallere bygningen med det samme. På den måde kan vi spare tid og sikre en kvalitetsopbygning til QA-miljøet.

Ved hjælp af et automatiseret værktøj registrerer testingeniøren alle manuelle trin, der udføres i softwarebuilden.

Røgtestcyklus

Nedenstående flowdiagram viser, hvordan røgtestning udføres. Når buildet er implementeret i QA, og røgtestene er bestået, fortsætter vi med funktionel testning. Hvis røgtesten fejler, afslutter vi testen, indtil problemet i buildet er løst.

Bedste Practices for Designing Smoke Test Cases

At kende cyklussen er én ting; keepping Suiten, der gør den troværdig, er en anden. En røgsuite fortjener kun sin plads, når den forbliver kompakt, hurtig og reproducerbar.

• Kortlæg først de kritiske stier: Angiv de arbejdsgange, der gør produktet kommercielt brugbart, såsom login, søgning, dataindtastning, betaling og logout. Hvis én af dem ikke fungerer, har buildet ingen værdi for en tester.
• Hold suiten lav, men bred: Berør hvert større modul én gang i stedet for at udforske ét modul i dybden. Grænseværdier, negative data og formuleringer i fejlmeddelelser hører hjemme i funktionel testning, ikke her.
• Sæt en grænse for udførelsestiden: De fleste hold holder løbet mellem ti og femten minutter og begrænser serien til cirka tyve til tredive test tilfældeEn tur, der tager en time, holder op med at være en port og bliver til en flaskehals.
• Kør de samme cases på hver build: Konsistens giver dig mulighed for at tilskrive en fejl til koden i stedet for et ændret testvalg.
• Fjern ustabile og afhængighedstunge sager: En sag, der består og fejler uden nogen kodeændring, ødelægger tilliden til gaten. Stub eller mock ustabile tredjepartstjenester, hvor testautomatiseringsramme tillader.
• Skriv én utvetydig dom: Hvert tilfælde kræver et enkelt forventet resultat, så buildet kan accepteres eller afvises uden debat.
• Versionsversion af suiten med build'et: Gem røgcasene i samme lager som applikationskoden, så gaten altid matcher den testede frigivelse.

RevSe pakken ved hver udgivelse: Udfas sager for funktioner, der ikke længere er vigtige, og tilføj nye kritiske arbejdsgange.

Røgtestning i CI/CD-rørledninger

En pakke designet på denne måde er billig nok til at køre på hver commit, hvilket er, hvad moderne levering kræver. kontinuerlig integration server som f.eks. Jenkins kompilerer koden, implementerer den i et staging-miljø og udløser derefter smoke-suiten som det første automatiserede trin. En grøn kørsel forfremmer artefakten til funktions- og regressionsfaserne, mens en rød kørsel fejler pipelinen og underretter den committende udvikler inden for få minutter.

To placeringer er almindelige. En kørsel før sammenflettet konfiguration beskytter hovedgrenen ved at validere hver pull-anmodning, og en kørsel efter implementering bekræfter, at det implementerede miljø er tilgængeligt og konfigureret korrekt. Teams, der praktiserer kontinuerlig implementering, tilføjer ofte en tredje, trimmet kørsel mod produktion umiddelbart efter udgivelsen.

Da pipelinen udfører pakken mange gange om dagen, skal sagerne være ikke-interaktive, selvrensende og uafhængige. Enhver sag, der venter på en menneskelig beslutning eller efterlader testdata, vil stoppe pipelinen.

Fordele ved røgtestning

Her er nogle få fordele anført for røgtestning.

• Nem at udføre og kører hurtigt
• Kritiske fejl og mangler er lette at opdage og rette i tidlige stadier.
• Forbedrer kvaliteten af ​​systemet
• Reducerer risikoen
• Fremskridt er lettere at vurdere.
• Sparer testindsats og tid
• Minimerer integrationsrisici

⚠ Bemærk venligst følgende: En forbigående røgtest viser kun, at buildet kan testes. Det berører overfladisk den primære funktionalitet, så mindre defekter, kanttilfælde og sjældent anvendte funktioner forbliver skjulte, indtil der køres funktionel test og regressionstest. Betragt aldrig et grønt røgresultat som tegn på, at buildet er fri for defekter.

Røgtest vs. tilregnelighedstest vs. regressionstest

Alle tre kører efter en kodeændring, hvilket er grunden til, at de ofte forveksles. De adskiller sig i omfang, dybde og det spørgsmål, som hver enkelt besvarer.

Test udført i et udviklingsmiljø på koden for at sikre applikationens korrekthed, før build frigives til QA, dette kaldes Sanity-testning. Det er en proces, der verificerer, at den applikation, der er under udvikling, opfylder dens grundlæggende funktionelle krav.

Sanitetstest bestemmer færdiggørelsen af ​​udviklingsfasen og træffer en beslutning om, hvorvidt softwareproduktet skal bestå eller ej til yderligere testfase.

GRUNDLAG	RØGTESTNING	TESTNING AF SKYLDIGHED	REGRESSIONSTESTNING
Anvendelsesområde	Bred og lav	Smal og dyb	Bred og dyb
Spørgsmål besvaret	Er denne build stabil nok til at blive testet?	Virker denne specifikke løsning?	Er noget, der plejede at virke, gået i stykker?
Sequence	Først, på hver build	Efter bestået røgtest	Efter tilregnelighedstest
Typisk varighed	10 til 15 minutter	30 til 60 minutter	Hours til dage
Automatiseringstilpasning	Meget høj	Moderat, ofte manuel	Meget høj

I praksis kører de i rækkefølge: røgtest for at acceptere buildet, sundhedstest for at verificere den leverede ændring og regressionstest, når tidsplanen tillader det.

Eksempel på røgprøver

Tabellen nedenfor dokumenterer en kort røgpakke, én række pr. kritisk sti.

T.ID	TESTSCENARIER	BESKRIVELSE	TEST TRIN	FORVENTET RESULTAT	FAKTISKE RESULTAT	STATUS
1	Gyldige login-legitimationsoplysninger	Test webapplikationens loginfunktionalitet for at sikre, at en registreret bruger har lov til at logge ind med brugernavn og adgangskode	1. Start applikationen 2. Naviger på login-siden 3. Indtast gyldigt brugernavn 4. Indtast gyldig adgangskode 5. Klik på login-knappen	Login skal være en succes	som forventet	Pass
2	Tilføjelse af elementfunktionalitet	Mulighed for at tilføje vare til indkøbskurven	1. Vælg kategoriliste 2. Læg varen i indkøbskurven	Varen skal tilføjes i indkøbskurven	Varen bliver ikke lagt i indkøbskurven	Fail
3	Log ud funktionalitet	Tjek log ud funktionalitet	1. vælg Log ud-knap	Brugeren skal kunne logge ud.	Brugeren kan ikke logge ud	Fail

Ofte Stillede Spørgsmål