Vad är röktestning?

Vad är röktestning?

Rökprovning är en mjukvarutestprocess som avgör om den distribuerade mjukvarubyggnaden är stabil eller inte. Röktestning är en bekräftelse för QA-teamet att fortsätta med ytterligare mjukvarutestning. Den består av en minimal uppsättning tester som körs på varje build för att testa mjukvarufunktioner. Röktestning är också känd som "Build Verification Testing" eller "Confidence Testing".

Enkelt uttryckt innebär röktestning att verifiera att viktiga funktioner fungerar och att det inte finns några störande faktorer i den version som testas. Det är ett mini- och snabbt regressionstest av viktig funktionalitet. Detta hjälper till att avgöra om versionen har brister, vilket gör ytterligare tester till slöseri med tid och resurser.

Jämför Rök vs förnuftstestning

Varför utför vi röktester?

Röktestning spelar en viktig roll i mjukvaruutveckling eftersom det säkerställer systemets korrekthet i de inledande skedena. På så sätt kan vi spara testarbete. Först när röktestningen är klar börjar vi funktionstestning.

• Alla iögonfallande sevärdheter i byggnaden kommer att identifieras genom röktester.
• Med hjälp av rökprovning identifieras de flesta defekterna i ett tidigt skede av mjukvaruutveckling.
• Med rökprovning förenklar vi upptäckt och korrigering av större defekter.
• Genom röktestning kan QA-teamet hitta defekter i applikationens funktionalitet som kan ha dykt upp av den nya koden.
• Röktestning hittar de största allvarliga defekterna.

Exempel 1: Loggningsfönster: Kan gå till nästa fönster med giltigt användarnamn och lösenord när du klickar på knappen Skicka.

Exempel 2: Användaren kan inte logga ut från webbsidan.

När gör vi röktestning?

Dessa fördelar uppstår endast om kontrollen utlöses vid rätt tillfälle. Röktestning utförs när nya funktioner i programvaran utvecklas och integreras med en befintlig build som distribueras i en QA-/stagingmiljö. Det säkerställer att alla kritiska funktioner fungerar korrekt eller inte. Diagrammet nedan visar hur en build når QA-miljön innan röktestningen börjar.

I den här testmetoden driftsätter utvecklingsteamet builden i QA. En delmängd av testfall tas och körs av testare mot buildens kritiska funktioner. Dessa serier av testfall är utformade för att avslöja fel som finns i builden. Om dessa tester godkänns fortsätter QA-teamet med funktions~~POS=TRUNC.

Eventuella fel indikerar ett behov av att hantera systemet tillbaka till utvecklingsteamet. Närhelst det sker en förändring i konstruktionen utför vi röktestning för att säkerställa stabiliteten.

Exempelvis: -Ny registreringsknapp läggs till i inloggningsfönstret och build distribueras med den nya koden. Vi utför rökprovning på ett nybygge.

Röktesterna kvalificerar bygget för vidare formell testning och är utformade för att visa systemstabilitet och överensstämmelse med krav. Huvudsyftet är att upptäcka större problem tidigt. En byggprocess inkluderar alla datafiler, bibliotek, återanvändbara moduler och konstruerade komponenter som krävs för att implementera en eller flera produktfunktioner.

Vad händer om vi inte utför röktestning

Om vi ​​inte utför rökprovning i tidiga skeden kan fel uppstå i senare skeden vilket kan bli kostsamt. defekt som upptäcks i senare skeden kan vara en hinder som påverkar lanseringen av leveranser.

Vem ska utföra röktestning?

Efter att ha släppt den byggda till QA-miljön, utförs röktestning av QA-ingenjörer/QA-ledare. Närhelst det finns en ny konstruktion bestämmer QA-teamet den huvudsakliga funktionaliteten i applikationen för att utföra röktestning. QA-teamet söker efter showstoppers i applikationen som testas.

Hur gör man röktest?

Röktestning görs vanligtvis manuellt men det finns en möjlighet att åstadkomma detsamma genom automatisering. Det kan variera från organisation till organisation.

Manuell röktestning

Röktestning utförs för att säkerställa att navigeringen av kritiska vägar är som förväntat och inte hindrar funktionaliteten. Högprioriterade funktionstestfall tas och testas för att hitta kritiska defekter i systemet. Om testet godkänns fortsätter vi funktionstesterna. Om testet misslyckas avvisas bygget och skickas tillbaka till utvecklingsteamet för korrigering.

QA-teamet börjar återigen med röktestning med en ny version. Röktestning utförs på nya versioner och integreras med gamla versioner för att bibehålla systemets korrekthet. Innan röktestning utförs bör QA-teamet kontrollera om det finns korrekta versioner.

Röktestning med automation

Automationstestning används till RegressionstestningVi kan dock också använda en uppsättning automatiserade testfall för att köra mot Smoke Test. Med hjälp av automatiserade tester kan utvecklare kontrollera bygget omedelbart, närhelst det finns en ny build redo för driftsättning.

Istället för att upprepa testet manuellt när den nya mjukvarubyggnaden distribueras, utförs inspelade röktestfall mot byggnaden. Den verifierar om de viktigaste funktionerna fortfarande fungerar korrekt. Om testet misslyckas kan de korrigera byggnaden och distribuera om byggnaden omedelbart. Genom detta kan vi spara tid och säkerställa en kvalitetsuppbyggnad till QA-miljön.

Med hjälp av ett automatiserat verktyg registrerar testingenjören alla manuella steg som utförs i mjukvarubygget.

Röktestningscykel

Flödesschemat nedan visar hur röktestning utförs. När bygget har driftsatts i QA och röktesterna är godkända fortsätter vi med funktionstestning. Om röktestet misslyckas avslutar vi testningen tills problemet i bygget är åtgärdat.

Bästa praxis för att utforma röktestfall

Att känna cykeln är en sak;ping Den sviten som gör den pålitlig är en annan. En röksvit förtjänar sin plats bara när den förblir kompakt, snabb och repeterbar.

• Kartlägg de kritiska vägarna först: Lista de arbetsflöden som gör produkten kommersiellt användbar, såsom inloggning, sökning, datainmatning, betalning och utloggning. Om ett av dem går sönder har bygget inget värde för en testare.
• Håll sviten grund men bred: Berör varje större modul en gång istället för att utforska en modul på djupet. Randvärden, negativa data och formuleringar i felmeddelanden hör hemma i funktionell testning, inte här.
• Begränsa exekveringstiden: De flesta lag håller löptiden mellan tio och femton minuter och begränsar sviten till ungefär tjugo till trettio testfallEn körning som tar en timme slutar vara en grind och blir en flaskhals.
• Kör samma fall på varje build: Konsekvens låter dig tillskriva ett fel till koden snarare än till ett ändrat testval.
• Ta bort osäkra och beroendetunga fall: Ett fall som godkänns och misslyckas utan någon kodändring förstör förtroendet för grinden. Stubba eller simulera instabila tredjepartstjänster där ramverk för testautomatisering tillåter.
• Skriv ner ett otvetydigt domslut: Varje fall behöver ett enda förväntat resultat så att bygget kan accepteras eller avvisas utan debatt.
• Versionsversionen av sviten med build-filen: Lagra rökfallen i samma arkiv som applikationskoden så att grinden alltid matchar den utgåva som testas.

RevVisa sviten varje utgåva: ta bort ärenden för funktioner som inte längre är viktiga och lägg till nya kritiska arbetsflöden.

Röktestning i CI/CD-rörledningar

En svit utformad på detta sätt är billig nog att köras på varje commit, vilket är vad modern leverans kräver. kontinuerlig integration server som till exempel Jenkins kompilerar koden, distribuerar den till en staging-miljö och utlöser sedan smoke-sviten som det första automatiserade steget. En grön körning flyttar artefakten till funktions- och regressionsstegen, medan en röd körning misslyckas med pipelinen och meddelar den committande utvecklaren inom några minuter.

Två placeringar är vanliga. En körning före sammanslagning skyddar huvudgrenen genom att validera varje pull request, och en körning efter distribution bekräftar att den distributionsmiljön är nåbar och korrekt konfigurerad. Team som använder kontinuerlig distribution lägger ofta till en tredje, trimmad körning mot produktion direkt efter lanseringen.

Eftersom pipelinen kör sviten många gånger om dagen måste ärendena vara icke-interaktiva, självrensande och oberoende. Alla ärenden som väntar på ett mänskligt beslut eller lämnar testdata kvar kommer att stoppa pipelinen.

Fördelar med röktestning

Här är några fördelar listade för röktestning.

• Lätt att utföra och går snabbt
• Kritiska fel och defekter är lätta att upptäcka och korrigera i tidiga skeden.
• Förbättrar kvaliteten på systemet
• Minskar risken
• Framsteg är lättare att bedöma.
• Sparar testansträngning och tid
• Minimerar integrationsrisker

⚠ Begränsning att notera: En passerande rökkörning visar bara att bygget är testbart. Den berör huvudfunktionaliteten ytligt, så mindre defekter, kantfall och sällan använda funktioner förblir dolda tills funktions- och regressionstestning körs. Betrakta aldrig ett grönt rökresultat som tecken på att bygget är felfritt.

Röktestning kontra förnuftstestning kontra regressionstestning

Alla tre körs efter en kodändring, vilket är anledningen till att de ofta förväxlas. De skiljer sig åt i omfattning, djup och den fråga som var och en besvarar.

Testning utförs i en utvecklingsmiljö på koden för att säkerställa applikationens korrekthet innan build släpps för QA, detta kallas Sanity-testning. Det är en process som verifierar att applikationen under utveckling uppfyller dess grundläggande funktionella krav.

Sanitetstestning avgör slutförandet av utvecklingsfasen och fattar ett beslut om att godkänna eller inte godkänna mjukvaruprodukten för ytterligare testfas.

GRUND	RÖKTESTNING	SUNDHETSTESTNING	REGRESSIONSTESTNING
Omfattning	Bred och grund	Smalt och djupt	Bred och djup
Fråga besvarad	Är den här konstruktionen tillräckligt stabil för att testas?	Fungerar den här specifika lösningen?	Har något som brukade fungera gått sönder?
Sekvens	Först, på varje byggnation	Efter att rökprovningen har godkänts	Efter mentaltest
Typisk varaktighet	10 till 15 minuter	30 till 60 minuter	Hours till dagar
Automatiseringsanpassning	Mycket högt	Måttlig, ofta manuell	Mycket högt

I praktiken körs de i sekvens: röktestning för att acceptera bygget, sanitetstestning för att verifiera den levererade ändringen och regressionstestning när schemat tillåter.

Exempel på röktestfall

Tabellen nedan dokumenterar en kort röksvit, en rad per kritisk linje.

T.ID	TESTSCENARIER	BESKRIVNING	TESTSTEG	FÖRVÄNTAT RESULTAT	FAKTISKT RESULTAT	STATUS
1	Giltiga inloggningsuppgifter	Testa webbapplikationens inloggningsfunktion för att säkerställa att en registrerad användare tillåts logga in med användarnamn och lösenord	1.Starta programmet 2.Navigera på inloggningssidan 3. Ange ett giltigt användarnamn 4. Ange ett giltigt lösenord 5. Klicka på inloggningsknappen	Inloggning bör vara framgångsrik	som förväntat	Pass
2	Lägger till objektfunktionalitet	Kan lägga till föremål i varukorgen	1.Välj kategorilista 2. Lägg varan i varukorgen	Varan bör läggas till i kundvagnen	Varan läggs inte till i kundvagnen	Underkänd
3	Logga ut funktionalitet	Kontrollera utloggningsfunktionen	1. välj logga ut-knappen	Användaren ska kunna logga ut.	Användaren kan inte logga ut	Underkänd

Vanliga frågor