Wat is rooktesten?

Wat is rooktesten?

Rook testen is een softwaretestproces dat bepaalt of de geïmplementeerde softwarebuild stabiel is of niet. Smoke testing is een bevestiging voor het QA-team om door te gaan met verdere softwaretests. Het bestaat uit een minimale set tests die op elke build worden uitgevoerd om softwarefunctionaliteiten te testen. Smoke testing staat ook bekend als "Build Verification Testing" of "Confidence Testing".

Simpel gezegd betekent smoke testing dat je controleert of de belangrijkste functies werken en of er geen problemen zijn die de testversie blokkeren. Het is een snelle, mini-regressietest van de belangrijkste functionaliteit. Dit helpt om te bepalen of de versie gebreken vertoont, waardoor verdere tests geen tijd- en resourceverspilling meer zijn.

Vergelijk Rook versus gezond verstand testen

Waarom voeren we rookproeven uit?

Rooktesten spelen een belangrijke rol in softwareontwikkeling, omdat ze de correctheid van het systeem in de beginfase garanderen. Hierdoor kunnen we testtijd besparen. Pas na het voltooien van de rooktesten kunnen we beginnen met functionele testen.

• Alle potentiële problemen tijdens de bouw zullen worden vastgesteld door middel van rooktesten.
• Met behulp van rooktesten worden de meeste defecten in een vroeg stadium opgespoord. software development.
• Met rooktesten vereenvoudigen we de detectie en correctie van grote defecten.
• Door middel van rooktesten kan het QA-team gebreken in de applicatiefunctionaliteit vinden die mogelijk door de nieuwe code aan het licht zijn gekomen.
• Met rooktests worden de belangrijkste ernstige defecten gevonden.

Voorbeeld 1: Logvenster: Kan naar het volgende venster gaan met een geldige gebruikersnaam en wachtwoord door op de knop Verzenden te klikken.

Voorbeeld 2: Gebruiker kan zich niet afmelden van de webpagina.

Wanneer voeren we een rooktest uit?

Die voordelen komen pas tot uiting als de controle op het juiste moment wordt uitgevoerd. Smoketesten worden uitgevoerd telkens wanneer nieuwe functionaliteiten van software worden ontwikkeld en geïntegreerd met een bestaande build die in de QA/staging-omgeving is geïmplementeerd. Het zorgt ervoor dat alle kritieke functionaliteiten correct werken. Het onderstaande diagram laat zien hoe een build de QA-omgeving bereikt voordat de smoketest begint.

Bij deze testmethode implementeert het ontwikkelteam de build in de QA-omgeving. Een subset van testgevallen wordt door testers uitgevoerd op de kritieke functionaliteiten van de build. Deze reeks testgevallen is ontworpen om fouten in de build aan het licht te brengen. Als deze tests slagen, gaat het QA-team verder met de test. Functioneel testen.

Elke fout duidt op de noodzaak om het systeem terug te sturen naar het ontwikkelingsteam. Wanneer er een verandering in de constructie plaatsvindt, voeren we rooktesten uit om de stabiliteit te garanderen.

Voorbeeld: - Nieuwe registratieknop is toegevoegd in het inlogvenster en build is geïmplementeerd met de nieuwe code. We voeren smoke testing uit op een nieuwe build.

De rooktests kwalificeren de build voor verdere formele tests en zijn bedoeld om de systeemstabiliteit en conformiteit aan de eisen aan te tonen. Het belangrijkste doel is om grote problemen vroegtijdig te detecteren. Een build omvat alle databestanden, bibliotheken, herbruikbare modules en speciaal ontworpen componenten die nodig zijn om een ​​of meer productfuncties te implementeren.

Wat gebeurt er als we geen rooktest uitvoeren?

Als we in een vroeg stadium geen rooktest uitvoeren, kunnen er in een later stadium defecten aan het licht komen, wat kostbare gevolgen kan hebben. Defect Problemen die in een later stadium worden ontdekt, kunnen een enorme belemmering vormen voor de oplevering van de resultaten.

Wie zal de rooktest uitvoeren?

Na het vrijgeven van de build naar de QA-omgeving, worden rooktests uitgevoerd door QA-ingenieurs/QA-leider. Wanneer er een nieuwe build is, bepaalt het QA-team de belangrijkste functionaliteit in de applicatie om rooktests uit te voeren. QA-team controleert op showstoppers in de applicatie die wordt getest.

Hoe voer je een rooktest uit?

Rooktesten worden meestal handmatig uitgevoerd, maar er bestaat een mogelijkheid om hetzelfde te bereiken door middel van automatisering. Het kan van organisatie tot organisatie verschillen.

Handmatige rooktest

Rooktesten worden uitgevoerd om te garanderen dat de navigatie door kritieke paden naar verwachting verloopt en de functionaliteit niet belemmert. Functionele testgevallen met hoge prioriteit worden geselecteerd en getest om kritieke defecten in het systeem te vinden. Als de test slaagt, gaan we verder met de functionele testen. Als de test mislukt, wordt de build afgewezen en teruggestuurd naar het ontwikkelteam voor correctie.

De QA-afdeling start opnieuw met rooktesten met een nieuwe buildversie. Rooktesten worden uitgevoerd op de nieuwe build en de resultaten worden geïntegreerd met oudere builds om de correctheid van het systeem te waarborgen. Voordat de rooktesten worden uitgevoerd, moet het QA-team controleren of de juiste buildversies worden gebruikt.

Geautomatiseerde rooktesten

Automatisering testen is gebruikt voor Regressie TestingWe kunnen echter ook een reeks geautomatiseerde testcases gebruiken om een ​​rooktest uit te voeren. Met behulp van geautomatiseerde tests kunnen ontwikkelaars de build direct controleren zodra er een nieuwe build klaar is voor implementatie.

In plaats van handmatige herhaalde tests wanneer de nieuwe software-build wordt geïmplementeerd, worden geregistreerde smoke-testcases uitgevoerd tegen de build. Het controleert of de belangrijkste functionaliteiten nog steeds goed werken. Als de test mislukt, kunnen ze de build corrigeren en de build onmiddellijk opnieuw implementeren. Hierdoor kunnen we tijd besparen en een kwaliteitsbuild voor de QA-omgeving garanderen.

Met behulp van een geautomatiseerde tool registreert de testingenieur alle handmatige stappen die worden uitgevoerd in de softwareontwikkeling.

Rooktestcyclus

Het onderstaande stroomschema laat zien hoe rooktesten worden uitgevoerd. Zodra de build in QA is geïmplementeerd en de rooktesten zijn geslaagd, gaan we verder met functionele testen. Als de rooktest mislukt, stoppen we met testen totdat het probleem in de build is opgelost.

Beste werkwijzen voor het ontwerpen van rooktestgevallen

Het is één ding om de cyclus te kennen; het is belangrijk om de cyclus te blijven volgen.ping De suite die de betrouwbaarheid ervan garandeert, is een andere factor. Een rooksuite verdient zijn bestaansrecht pas als hij compact, snel en reproduceerbaar blijft.

• Breng eerst de kritieke paden in kaart: Geef een overzicht van de workflows die het product commercieel bruikbaar maken, zoals inloggen, zoeken, gegevensinvoer, betaling en uitloggen. Als een van deze workflows niet werkt, heeft de build geen waarde voor een tester.
• Houd de suite ondiep maar breed: Behandel elke belangrijke module één keer in plaats van één module grondig te onderzoeken. Grenswaarden, negatieve data en de formulering van foutmeldingen horen thuis in functionele tests, niet hier.
• Beperk de uitvoeringstijd: De meeste teams houden de wedstrijd tussen de tien en vijftien minuten en beperken de suite tot ongeveer twintig tot dertig minuten. testgevallenEen route die een uur duurt, is niet langer een toegangspoort, maar een knelpunt.
• Voer bij elke build dezelfde testcases uit: Consistentie zorgt ervoor dat je een fout kunt toeschrijven aan de code zelf, in plaats van aan een gewijzigde testselectie.
• Verwijder onbetrouwbare en sterk afhankelijke gevallen: Een testcase die slaagt en faalt zonder dat er code wordt gewijzigd, ondermijnt het vertrouwen in de gate. Gebruik stubs of mocks voor instabiele services van derden waar de testautomatiseringsframework toelaat.
• Noteer één ondubbelzinnig oordeel: Elk geval vereist één enkel verwacht resultaat, zodat de build zonder discussie kan worden goedgekeurd of afgewezen.
• Versiebeheer van de suite met de build: Bewaar de smoke-tests in dezelfde repository als de applicatiecode, zodat de testomgeving altijd overeenkomt met de release die wordt getest.

RevEvalueer de suite bij elke release: verwijder cases voor functies die niet langer relevant zijn en voeg nieuwe, essentiële workflows toe.

Rooktesten in CI/CD-pipelines

Een suite die op deze manier is ontworpen, is goedkoop genoeg om bij elke commit te draaien, wat moderne leveringsmethoden vereisen. continue integratie server zoals Jenkins Het compileert de code, implementeert deze in een stagingomgeving en activeert vervolgens de smoke-testsuite als eerste geautomatiseerde stap. Een succesvolle run (groen resultaat) zorgt ervoor dat het artefact doorgaat naar de functionele en regressietests, terwijl een mislukt resultaat (rood resultaat) de pipeline laat falen en de ontwikkelaar die de commit heeft gedaan binnen enkele minuten op de hoogte stelt.

Er zijn twee testruns gebruikelijk. Een run vóór de merge bewaakt de hoofdbranch door elke pull request te valideren, en een run na de implementatie bevestigt dat de geïmplementeerde omgeving bereikbaar en correct geconfigureerd is. Teams die continue implementatie toepassen, voegen vaak direct na de release een derde, verkorte testrun toe tegen de productieomgeving.

Omdat de pipeline de testsuite meerdere keren per dag uitvoert, moeten de testgevallen niet-interactief, zelfreinigend en onafhankelijk zijn. Elk testgeval dat wacht op een menselijke beslissing of testgegevens achterlaat, zal de pipeline blokkeren.

Voordelen van rooktesten

Hier zijn enkele voordelen vermeld voor rooktesten.

• Eenvoudig uit te voeren en werkt snel.
• Kritieke fouten en defecten zijn in een vroeg stadium gemakkelijk te detecteren en te corrigeren.
• Verbetert de kwaliteit van het systeem
• Vermindert het risico
• Vooruitgang is gemakkelijker te beoordelen.
• Bespaart testinspanning en tijd
• Minimaliseert integratierisico's

⚠ Let op de volgende beperking: Een geslaagde smoke run geeft alleen aan dat de build testbaar is. Het test slechts oppervlakkig de belangrijkste functionaliteit, waardoor kleine defecten, uitzonderlijke gevallen en zelden gebruikte functies verborgen blijven tot de functionele en regressietests zijn uitgevoerd. Beschouw een groene smoke run nooit als een teken dat de build defectvrij is.

Rooktesten versus sanitytesten versus regressietesten

Alle drie worden uitgevoerd na een codewijziging, vandaar dat ze vaak door elkaar worden gehaald. Ze verschillen in reikwijdte, diepgang en de vraag die elk beantwoordt.

Het testen van de code in een ontwikkelomgeving om de correctheid van de applicatie te garanderen voordat de build naar de QA-afdeling wordt vrijgegeven, wordt sanity testing genoemd. Het is een proces dat verifieert of de applicatie in ontwikkeling voldoet aan de basisfunctionaliteitseisen.

Sanity-tests bepalen de voltooiing van de ontwikkelingsfase en nemen een beslissing of het softwareproduct wel of niet wordt goedgekeurd voor de verdere testfase.

BASIS	ROOKTEST	GEZONDHEIDSTEST	REGRESSIETOETSING
strekking	Breed en ondiep	Smal en diep	Breed en diep
Vraag beantwoord	Is deze build stabiel genoeg om te testen?	Werkt deze specifieke oplossing?	Is er iets kapot gegaan dat vroeger wel werkte?
Volgorde	Ten eerste, bij elke build	Nadat de rooktest is geslaagd	Na een grondige controle
Typische duur	10 tot 15 minuten	30 tot 60 minuten	Hours tot dagen
Automatisering geschikt	Zeer hoog	Gemiddeld, vaak handmatig	Zeer hoog

In de praktijk worden ze in een bepaalde volgorde uitgevoerd: rooktesten om de build te accepteren, sanitytesten om de geleverde wijziging te verifiëren en regressietesten wanneer de planning dit toelaat.

Voorbeeld van voorbeeld van rooktestgevallen

De onderstaande tabel documenteert een korte rooktest, met één rij per kritiek pad.

T.ID	TESTSCENARIO'S	PRODUCTBESCHRIJVING	TEST STAP	VERWACHT RESULTAAT	WERKELIJKE RESULTAAT	STATUS
1	Geldige inloggegevens	Test de inlogfunctionaliteit van de webapplicatie om er zeker van te zijn dat een geregistreerde gebruiker mag inloggen met gebruikersnaam en wachtwoord	1.Start de applicatie 2. Navigeer naar de inlogpagina 3.Voer een geldige gebruikersnaam in 4.Voer een geldig wachtwoord in 5.Klik op de login-knop	Inloggen zou succesvol moeten zijn	zoals verwacht	Passeren
2	Artikelfunctionaliteit toevoegen	Mogelijkheid om artikel aan winkelwagen toe te voegen	1.Selecteer de categorielijst 2.Voeg het artikel toe aan de winkelwagen	Het artikel moet aan de winkelwagen worden toegevoegd	Artikel wordt niet aan de winkelwagen toegevoegd	Mislukken
3	Uitlogfunctie	Controleer de afmeldfunctionaliteit	1. Selecteer de knop Afmelden	De gebruiker moet zich kunnen afmelden.	Gebruiker kan zich niet afmelden	Mislukken

Veelgestelde vragen