smoke testing vs sanity testing
Ontdek de verschillen tussen rooktesten en gezondheidstesten in detail met voorbeelden:
In deze tutorial zullen we leren wat Sanity Testing en Smoke Testing in Software Testing is. We zullen ook de belangrijkste verschillen tussen Sanity- en Smoke-testen leren met eenvoudige voorbeelden.
Meestal raken we in de war tussen de betekenis van Sanity Testing en Smoke Testing. Allereerst zijn deze twee tests ver ' anders ”En worden uitgevoerd tijdens verschillende fasen van een testcyclus.
Wat je leert:
- Sanity testen
- Mijn ervaring
- Sanity Testing Vs Regressie Testing
- Strategie voor het testen van mobiele apps
- Voorzorgsmaatregelen
- Rook testen
- Voorbeelden van rooktesten
- Belang in SCRUM-methodologie
- Rooktest versus bouwacceptatietesten
- Rook testcyclus
- Wie moet de rooktest uitvoeren?
- Waarom moeten we rooktesten automatiseren?
- Voor-en nadelen
- Verschil tussen testen op rook en gezond verstand
- Aanbevolen literatuur
Sanity testen
Sanity Testing wordt gedaan als we als QA niet voldoende tijd hebben om alle testcases uit te voeren, zij het Functioneel testen , UI, OS of Browser testen.
Daarom zou ik definiëren,
'Sanity Testing als een testuitvoering die wordt gedaan om elke implementatie en de impact ervan aan te raken, maar niet grondig of diepgaand, het kan functionele tests, UI-, versie-, enz. Testen omvatten, afhankelijk van de implementatie en de impact ervan.'
Vallen we niet allemaal in een situatie waarin we ons over een dag of twee moeten afmelden, maar de build voor testen nog steeds niet is vrijgegeven?
interviewvragen en antwoorden van hp kwaliteitscentrum
Ah ja, ik wed dat je deze situatie ook minstens één keer in je Software Testing-ervaring hebt meegemaakt. Nou, ik heb er veel mee te maken gehad omdat mijn project (en) meestal agile waren en soms werd ons gevraagd om het dezelfde dag op te leveren. Oeps, hoe kan ik de build binnen een paar uur testen en vrijgeven?
Ik werd soms gek, want zelfs als het een kleine functionaliteit was, kon de implicatie enorm zijn. En als kers op de taart weigeren klanten soms simpelweg extra tijd te besteden. Hoe kon ik de hele test in een paar uur voltooien, elke functionaliteit verifiëren, Bugs en laat het los?
Het antwoord op al deze problemen was heel simpel, namelijk niets anders dan gebruiken Strategie voor het testen van gezond verstand.
Wanneer we deze testen doen voor een module of functionaliteit of een compleet systeem, dan is de Testgevallen voor uitvoering worden zo geselecteerd dat ze alle belangrijke stukjes en beetjes van hetzelfde, d.w.z. brede maar oppervlakkige testen zullen raken.
Soms wordt het testen zelfs willekeurig gedaan zonder testgevallen. Maar onthoud, Sanity-test mag alleen worden gedaan als u weinig tijd heeft, gebruik dit nooit voor uw reguliere releases. Theoretisch is dit testen een subset van Regressietesten
Mijn ervaring
Van mijn 8+ jaar carrière in Software Testing, werkte ik gedurende 3 jaar in Agile methodoloog y en dat was de tijd dat ik meestal een geestelijke gezondheidstest gebruikte.
Alle grote releases werden op een systematische manier gepland en uitgevoerd, maar soms werd er gevraagd om kleine releases zo snel mogelijk te leveren. We kregen niet veel tijd om de testcases te documenteren, uit te voeren, de bug-documentatie te doen, de regressie uit te voeren en het hele proces te volgen.
Daarom zijn de volgende enkele van de belangrijkste aanwijzingen die ik in dergelijke situaties volgde:
# 1) Neem contact op met de manager en het ontwikkelteam wanneer ze de implementatie bespreken, omdat ze snel moeten werken en daarom kunnen we niet verwachten dat ze ons afzonderlijk uitleggen.
Dit zou je ook helpen om een idee te krijgen over wat ze gaan implementeren, op welk gebied het van invloed zal zijn enz., Dit is een heel belangrijk ding om te doen omdat we soms gewoon de implicaties niet beseffen en of er bestaande functionaliteit is wordt belemmerd (in het ergste geval).
#twee) Omdat je weinig tijd hebt, kun je tegen de tijd dat het ontwikkelteam aan de implementatie werkt de testcases globaal opschrijven in tools zoals Evernote, etc. Maar zorg ervoor dat je ze ergens schrijft, zodat je ze later kunt toevoegen aan de testcase-tool.
# 3) Houd uw testbed gereed volgens de implementatie en als u denkt dat er rode vlaggen zijn, zoals het maken van specifieke gegevens als een testbed tijd zal kosten (en het is een belangrijke test voor de release), steek die vlaggen dan onmiddellijk omhoog en informeer uw manager of PO over de wegversperring.
Alleen omdat de klant zo snel mogelijk wil, betekent dit niet dat een QA wordt vrijgegeven, zelfs als deze half is getest.
# 4) Maak een afspraak met uw team en manager dat u vanwege tijdgebrek de bugs alleen aan het ontwikkelingsteam communiceert en het formele proces van toevoegen, het markeren van de bugs voor verschillende fasen in de bug-trackingtool zal later worden gedaan om tijd te besparen. .
# 5) Wanneer het ontwikkelingsteam aan het einde van de test aan het testen is, probeer dan met hen te paren (genaamd dev-QA pairing) en doe een basisronde over hun setup zelf, dit zal helpen om heen en weer van de build te vermijden als de basisimplementatie mislukt .
# 6) Nu je de build hebt, test je eerst de business rules en alle use cases. U kunt tests zoals een validatie van een veld, navigatie, enz. Voor later bewaren.
# 7) Welke bugs je ook tegenkomt, noteer ze allemaal en probeer ze samen aan de ontwikkelaars te rapporteren in plaats van afzonderlijk te rapporteren, omdat het voor hen gemakkelijk zal zijn om aan een hoop te werken.
# 8) Als u een vereiste heeft voor de overall Prestatietests of stress- of belastingtests, zorg er dan voor dat u hiervoor een goed automatiseringsraamwerk hebt. Omdat het bijna onmogelijk is om deze handmatig te testen met een gezondheidstest.
# 9) Dit is het belangrijkste deel, en inderdaad de laatste stap van je strategie om gezond verstand te testen - “Wanneer je de release-e-mail of het document opstelt, vermeld dan alle testgevallen die je hebt uitgevoerd, de gevonden bugs met een statusmarkering en of er iets is achtergelaten ongetest vermeld het met de redenen Probeer een helder verhaal over uw tests te schrijven, dat iedereen vertelt wat er is getest, geverifieerd en wat niet is gebeurd.
Ik volgde dit religieus toen ik deze test gebruikte.
Laat me mijn eigen ervaring delen:
# 1) We werkten aan een website en deze maakte pop-upadvertenties op basis van de zoekwoorden. De adverteerders plaatsten het bod voor bepaalde zoekwoorden waarvoor een scherm was ontworpen. De standaard bodwaarde werd getoond als $ 0,25, wat de bieder zelfs kon veranderen.
Er was nog een plaats waar dit standaardbod werd weergegeven en het kon ook in een andere waarde worden gewijzigd. De klant kwam met een verzoek om de standaardwaarde te wijzigen van $ 0,25 in $ 0,5, maar hij noemde alleen het voor de hand liggende scherm.
Tijdens onze brainstormdiscussie zijn we dit andere scherm vergeten (?) Omdat het niet veel voor dat doel werd gebruikt. Maar tijdens het testen toen ik het basisscenario uitvoerde dat het bod $ 0,5 was en van begin tot eind controleerde, ontdekte ik dat de cronjob voor hetzelfde mislukte omdat het op één plaats $ 0,25 vond.
Ik heb dit aan mijn team gemeld en we hebben de wijziging aangebracht en deze dezelfde dag zelf succesvol opgeleverd.
#twee) Onder hetzelfde project (hierboven vermeld) werd ons gevraagd om een klein tekstveld toe te voegen voor notities / opmerkingen voor biedingen. Het was een heel eenvoudige implementatie en we hebben ons ertoe verbonden om het dezelfde dag op te leveren.
Daarom heb ik, zoals hierboven vermeld, alle bedrijfsregels en use-cases eromheen getest en toen ik wat validatietests deed, ontdekte ik dat wanneer ik een combinatie van speciale tekens invoerde, zoals de pagina crashte.
We dachten erover na en kwamen erachter dat de daadwerkelijke bieders dergelijke combinaties in geen geval zullen gebruiken. Daarom hebben we het uitgebracht met een goed opgestelde nota over de kwestie. De klant accepteerde dat als een bug, maar kwam met ons overeen om deze later te implementeren, omdat het een ernstige bug was, maar geen eerdere.
# 3) Onlangs werkte ik aan een mobiel app-project en we hadden een vereiste om het tijdstip van bezorging in de app bij te werken volgens de tijdzone. Het moest niet alleen in de app worden getest, maar ook voor de webservice.
Terwijl het ontwikkelteam aan de implementatie werkte, creëerde ik de automatiseringsscripts voor het testen van webservices en de DB-scripts voor het wijzigen van de tijdzone van het bezorgitem. Dit bespaarde mijn inspanningen en we konden in korte tijd betere resultaten behalen.
Sanity Testing Vs Regressie Testing
Hieronder zijn een paar verschillen tussen de twee:
S. Nee. | Regressietesten | Sanity testen |
---|---|---|
7 | Dit testen is soms gepland voor weken of zelfs maand (en). | Dit duurt meestal maximaal 2-3 dagen. |
1 | Regressietests worden uitgevoerd om te controleren of het volledige systeem en bugfixes goed werken. | Sanity-tests worden willekeurig uitgevoerd om te verifiëren dat elke functionaliteit werkt zoals verwacht. |
twee | Elk kleinste onderdeel wordt bij deze test teruggebracht. | Dit is geen geplande test en wordt alleen gedaan als er een tijdcrisis is. |
3 | Het is een goed uitgewerkte en geplande test. | Dit is geen geplande test en wordt alleen gedaan als er een tijdcrisis is. |
4 | Voor deze tests wordt een passend ontworpen suite van testcases gemaakt. | Het is misschien niet altijd mogelijk om de testcases te maken; meestal wordt een ruwe reeks testcases gemaakt. |
5 | Dit omvat een grondige verificatie van functionaliteit, gebruikersinterface, prestaties, browser / OS-testen enz., D.w.z. elk aspect van het systeem wordt teruggedraaid. | Dit omvat voornamelijk verificatie van bedrijfsregels, functionaliteit. |
6 | Dit is een brede en diepe test. | Dit is een brede en ondiepe test. |
Strategie voor het testen van mobiele apps
Je vraagt je vast af waarom ik het hier specifiek over mobiele apps heb?
De reden is dat OS en browserversie voor web- of desktop-apps niet veel verschillen en vooral de schermformaten zijn standaard. Maar bij mobiele apps hebben de schermgrootte, het mobiele netwerk, de OS-versies, enz. Invloed op de stabiliteit, het uiterlijk en kortom het succes van je mobiele app.
Daarom wordt een strategieformulering van cruciaal belang wanneer u deze tests uitvoert op een mobiele app, omdat één storing u in grote problemen kan brengen. Het testen moet ook slim en voorzichtig gebeuren.
Hieronder volgen enkele tips om u te helpen deze test met succes uit te voeren op een ‘mobiele app’:
# 1) Analyseer allereerst de impact van de OS-versie op de implementatie met je team.
Probeer antwoorden te vinden op vragen als: zal het gedrag in de verschillende versies verschillen? Werkt de implementatie op de laagst ondersteunde versie of niet? Zullen er prestatieproblemen zijn bij de implementatie van versies? Is er een specifiek kenmerk van het besturingssysteem dat het gedrag van de implementatie kan beïnvloeden? enz.
#twee) Op de bovenstaande opmerking, analyseer ook voor de telefoonmodellen, d.w.z. zijn er functies van de telefoon die van invloed zijn op de implementatie? Is de implementatie van gedragsverandering met GPS? Verandert het implementatiegedrag met de camera van de telefoon? enz. Als u merkt dat dit geen gevolgen heeft, moet u testen op verschillende telefoonmodellen vermijden.
# 3) Tenzij er enige UI-wijzigingen zijn voor de implementatie, zou ik aanraden om UI-testen op de minste prioriteit te houden, u kunt het team (als u dat wilt) laten weten dat de UI niet zal worden getest.
# 4) Om tijd te besparen, moet u testen op goede netwerken vermijden, omdat het duidelijk is dat de implementatie zal werken zoals verwacht op een sterk netwerk. Ik zou aanraden om te beginnen met testen op een 4G- of 3G-netwerk.
# 5) Deze test moet in minder tijd worden uitgevoerd, maar zorg ervoor dat u ten minste één veldtest uitvoert, tenzij het slechts een wijziging in de gebruikersinterface is.
# 6) Als je moet testen op een matrix van verschillende besturingssystemen en hun versie, raad ik je aan dit op een slimme manier te doen. Kies bijvoorbeeld de laagste, gemiddelde en nieuwste OS-versie-paren om te testen. U kunt in het vrijgavedocument vermelden dat niet elke combinatie wordt getest.
# 7) Op een vergelijkbare manier, gebruikt u voor de UI-implementatie-sanity-test kleine, middelgrote en grote schermformaten om tijd te besparen. U kunt ook een simulator en emulator gebruiken.
Voorzorgsmaatregelen
Sanity Testing wordt uitgevoerd wanneer u weinig tijd heeft en daarom is het niet mogelijk voor u om elke testcase uit te voeren en het belangrijkste is dat u niet genoeg tijd krijgt om uw testen te plannen. Om de schuldspellen te vermijden, is het beter om voorzorgsmaatregelen te nemen.
In dergelijke gevallen zijn gebrek aan schriftelijke communicatie, testdocumentatie en miss-outs vrij normaal.
Om ervoor te zorgen dat u hier niet aan ten prooi valt, moet u ervoor zorgen dat:
- Accepteer nooit een build om te testen totdat u geen schriftelijke vereiste hebt gekregen die door de klant wordt gedeeld. Het komt voor dat klanten wijzigingen of nieuwe implementaties mondeling of in chat of een simpele 1 liner in een e-mail communiceren en verwachten dat wij dat als een vereiste behandelen. Dwing uw klant om enkele basisfunctionaliteitspunten en acceptatiecriteria te geven.
- Maak altijd grove aantekeningen van uw testcases en bugs als u niet voldoende tijd heeft om ze netjes op te schrijven. Laat deze nooit ongedocumenteerd achter. Als er wat tijd is, deel deze dan met uw leidinggevende of team, zodat ze, als er iets ontbreekt, er gemakkelijk op kunnen wijzen.
- Als u en uw team weinig tijd hebben, zorg er dan voor dat de bugs in de juiste staat in een e-mail worden gemarkeerd. U kunt de volledige lijst met bugs naar het team e-mailen en de ontwikkelaars ze op de juiste manier laten markeren. Houd de bal altijd in het veld van de ander.
- Als je hebt Automatiseringsraamwerk klaar, gebruik dat en vermijd het te doen Handmatig testen , op die manier kunt u in minder tijd meer dekken.
- Vermijd het scenario van 'release in 1 uur', tenzij u er 100% zeker van bent dat u kunt leveren.
- Als laatste, maar niet de minste, zoals hierboven vermeld, stel een gedetailleerde release-e-mail op waarin u communiceert wat er wordt getest, wat is weggelaten, redenen, risico's, welke bugs zijn opgelost, wat wordt 'latered' etc.
Als QA moet u beoordelen wat het belangrijkste onderdeel van de implementatie is dat moet worden getest en welke onderdelen kunnen worden weggelaten of basistest kunnen worden uitgevoerd.
Plan zelfs in korte tijd een strategie over hoe u wilt doen en u zult in het gegeven tijdsbestek het beste kunnen bereiken.
Rook testen
Smoke Testing is geen uitputtende test, maar het is een groep tests die wordt uitgevoerd om te verifiëren of de basisfunctionaliteiten van die specifieke build goed werken zoals verwacht of niet. Dit is en zou altijd de eerste test moeten zijn die moet worden uitgevoerd op elke ‘nieuwe’ build.
Wanneer het ontwikkelteam een build vrijgeeft aan de QA om te testen, is het natuurlijk niet mogelijk om de volledige build te testen en onmiddellijk te verifiëren of een van de implementaties bugs bevat of dat een van de werkende functionaliteit kapot is.
Hoe zorgt een QA er in het licht hiervan voor dat de basisfunctionaliteiten goed werken?
Het antwoord hierop is het uitvoeren van een Rook testen
Zodra de tests zijn gemarkeerd als Smoke-tests (in de testsuite), pas dan wordt de build geaccepteerd door de QA voor diepgaande tests en / of regressie. Als een van de rooktests mislukt, wordt de build afgekeurd en moet het ontwikkelingsteam het probleem oplossen en een nieuwe build vrijgeven om te testen.
Theoretisch wordt de rooktest gedefinieerd als testen op oppervlakte-niveau om te certificeren dat de build die door het ontwikkelingsteam aan het QA-team is geleverd, klaar is voor verder testen. Deze test wordt ook uitgevoerd door het ontwikkelingsteam voordat de build wordt vrijgegeven aan het QA-team.
Deze tests worden normaal gesproken gebruikt bij integratietests, systeemtests en tests op acceptatieniveau. Behandel dit nooit als een vervanging voor de daadwerkelijke end-to-end complete tests Het bestaat uit zowel positieve als negatieve tests, afhankelijk van de build-implementatie.
Voorbeelden van rooktesten
Deze toetsing wordt normaal gesproken gebruikt voor Integratie, Acceptatie en Systeemtesten
In mijn carrière als QA accepteerde ik een build altijd pas nadat ik een rooktest had uitgevoerd. Laten we dus eens kijken wat een rooktest is vanuit het perspectief van al deze drie tests, met enkele voorbeelden.
# 1) Acceptatietesten
Telkens wanneer een build wordt vrijgegeven voor de QA, rooktest in de vorm van een Acceptatietesten zou gedaan moeten worden.
In deze test is de eerste en belangrijkste rooktest het verifiëren van de verwachte basisfunctionaliteit van de implementatie. Op deze manier moet u alle implementaties voor die specifieke build verifiëren.
Laten we de volgende voorbeelden nemen als implementaties die in een build zijn gedaan om de rooktests voor die te begrijpen:
- De inlogfunctionaliteit geïmplementeerd om de geregistreerde chauffeurs met succes te laten inloggen.
- De dashboardfunctionaliteit geïmplementeerd om de routes te tonen die een chauffeur vandaag moet afleggen.
- De functionaliteit geïmplementeerd om een passend bericht te tonen als er voor een bepaalde dag geen routes bestaan.
In de bovenstaande build, op acceptatieniveau, betekent de rooktest om te verifiëren dat de drie basisimplementaties goed werken. Als een van deze drie is verbroken, moet de QA de build afwijzen.
# 2) Integratietesten
Dit testen wordt meestal gedaan wanneer de individuele modules zijn geïmplementeerd en getest. In de Integratietesten niveau, wordt deze test uitgevoerd om ervoor te zorgen dat alle basisintegratie en end-to-end-functionaliteiten goed werken zoals verwacht.
Het kan de integratie zijn van twee modules of alle modules samen, dus de complexiteit van de rooktest zal variëren afhankelijk van het integratieniveau.
Laten we de volgende voorbeelden van integratie-implementatie voor deze test bekijken:
- Implementatie van de integratie van route- en stopmodules.
- De integratie van de update van de aankomststatus geïmplementeerd en hetzelfde weergeven op het stopscherm.
- Implementatie van de integratie van complete pick-up tot levering functionaliteit modules.
In deze build zal de rooktest niet alleen deze drie basisimplementaties verifiëren, maar voor de derde implementatie zullen enkele gevallen ook verifiëren voor volledige integratie. Het helpt veel om de problemen te achterhalen die tijdens de integratie worden geïntroduceerd en die onopgemerkt zijn gebleven door het ontwikkelingsteam.
# 3) Systeemtesten
Zoals de naam al suggereert, omvat de rooktest voor systeemniveau tests voor de belangrijkste en meest gebruikte workflows van het systeem. Dit wordt alleen gedaan nadat het complete systeem gereed en getest is, en dit testen op systeemniveau kan ook rooktesten worden genoemd vóór regressietesten.
Voordat met de regressie van het complete systeem wordt begonnen, worden de basisfuncties van begin tot eind getest als onderdeel van de rooktest. De rooktestsuite voor het complete systeem omvat de end-to-end testcases die de eindgebruikers zeer vaak zullen gebruiken.
Dit gebeurt meestal met behulp van automatiseringstools.
apk-bestandslocatie in Android-telefoon
Belang in SCRUM-methodologie
Tegenwoordig volgen de projecten nauwelijks de Waterfall-methodiek bij de projectimplementatie, meestal volgen alle projecten Agile en SCRUM enkel en alleen. Vergeleken met de traditionele watervalmethode heeft Smoke Testing hoge eisen aan SCRUM en Agile.
Ik heb 4 jaar in SCRUM gewerkt En zoals we weten zijn in SCRUM de sprints van kortere duur en daarom is het van extreem belang om deze test te doen, zodat de mislukte builds direct aan het ontwikkelteam kunnen worden gerapporteerd en ook kunnen worden verholpen.
Hieronder volgen enkele afhalen over het belang van deze tests in SCRUM:
- Van de sprint van twee weken wordt de rust toegewezen aan de QA, maar soms worden de builds naar de QA vertraagd.
- Bij sprints is het voor het team het beste dat de issues in een vroeg stadium worden gemeld.
- Elk verhaal heeft een reeks acceptatiecriteria, daarom is het testen van de eerste 2-3 acceptatiecriteria gelijk aan het rooktesten van die functionaliteit. Klanten weigeren de levering als een enkel criterium niet voldoet.
- Stelt u zich eens voor wat er zal gebeuren als het 2 dagen is dat het ontwikkelteam u de build heeft geleverd en er nog maar 3 dagen over zijn voor de demo en u een basisfunctionaliteitsfout tegenkomt.
- Gemiddeld heeft een sprint verhalen van 5-10, dus wanneer de build wordt gegeven, is het belangrijk om ervoor te zorgen dat elk verhaal wordt geïmplementeerd zoals verwacht voordat de build wordt geaccepteerd voor testen.
- Wanneer het volledige systeem moet worden getest en teruggedraaid, wordt er een sprint aan de activiteit gewijd. Twee weken misschien iets minder om het hele systeem te testen, daarom is het erg belangrijk om de meest elementaire functionaliteiten te verifiëren voordat u met de regressie begint.
Rooktest versus bouwacceptatietesten
Rooktesten is direct gerelateerd aan Build Acceptance Testing (BAT).
In BAT doen we dezelfde tests - om te controleren of de build niet is mislukt en of het systeem goed werkt of niet. Soms komt het voor dat wanneer een build wordt gemaakt, er een aantal problemen wordt geïntroduceerd en wanneer deze wordt opgeleverd, werkt de build niet voor de QA.
Ik zou zeggen dat BAT een onderdeel is van een rookcontrole, want als het systeem faalt, hoe kun je als QA de build dan accepteren om te testen? Niet alleen de functionaliteiten, het systeem zelf moet werken voordat de QA's verder gaan met diepgaande testen.
Rook testcyclus
In het volgende stroomschema wordt de rooktestcyclus uitgelegd.
Zodra een build is geïmplementeerd voor een QA, is de basiscyclus die wordt gevolgd dat als de rooktest slaagt, de build wordt geaccepteerd door het QA-team voor verder testen, maar als het mislukt, wordt de build afgewezen totdat de gemelde problemen zijn opgelost.
Testcyclus
Wie moet de rooktest uitvoeren?
Niet het hele team is bij dit soort tests betrokken om tijdverspilling van alle QA's te voorkomen.
Smoke Testing wordt idealiter uitgevoerd door de QA-lead, die op basis van het resultaat beslist of hij de build aan het team doorgeeft voor verder testen of afkeuren. Of bij afwezigheid van de lead kunnen de QA's deze test ook zelf uitvoeren.
Soms, wanneer het een grootschalig project is, kan een groep QA deze tests ook uitvoeren om te controleren of er showstoppers zijn. Maar dit is niet het geval in het geval van SCRUM, omdat SCRUM een platte structuur is zonder leads of managers en elke tester zijn eigen verantwoordelijkheden heeft ten opzichte van zijn verhalen.
Daarom voeren individuele QA's deze tests uit voor de verhalen die ze bezitten.
Waarom moeten we rooktesten automatiseren?
Deze test is de eerste test die moet worden gedaan op een build die is vrijgegeven door het ontwikkelteam (en). Op basis van de resultaten van deze tests wordt verder getest (of wordt de build afgekeurd).
De beste manier om deze tests uit te voeren, is door een automatiseringstool te gebruiken en de rooksuite zo te plannen dat deze wordt uitgevoerd wanneer er een nieuwe build wordt gemaakt. Je denkt misschien: waarom zou ik 'De rooktestsuite automatiseren'?
Laten we eens kijken naar het volgende geval:
Laten we zeggen dat u een week verwijderd bent van uw vrijlating en van de in totaal 500 testcases bestaat uw rooktestsuite uit 80-90. Als u al deze 80-90 testcases handmatig gaat uitvoeren, stelt u zich dan eens voor hoeveel tijd u hiervoor nodig heeft? Ik denk dat 4-5 dagen (minimum).
Maar als u automatisering gebruikt en scripts maakt om al deze 80-90 testcases uit te voeren, worden deze idealiter binnen 2-3 uur uitgevoerd en heeft u de resultaten onmiddellijk bij u. Heeft het u niet uw kostbare tijd bespaard en heeft u de resultaten over de inbouw veel minder tijd opgeleverd?
5 jaar geleden was ik een financiële projectie-app aan het testen, die input vergaarde over je salaris, besparingen, enz., En je belastingen, besparingen en winst voorspelde, afhankelijk van de financiële regels. Daarnaast hadden we maatwerk voor landen die afhankelijk zijn van het land en de belastingregels die werden gebruikt om te veranderen (in de code).
Voor dit project had ik 800 testcases en 250 rooktestcases. Met het gebruik van Selenium konden we gemakkelijk automatiseren en de resultaten van die 250 testcases in 3-4 uur krijgen. Het bespaarde niet alleen onze tijd, maar liet ons ook zo snel mogelijk zien over de showstoppers.
Neem daarom de hulp van automatisering voor deze tests, tenzij het onmogelijk is om te automatiseren.
Voor-en nadelen
Laten we eerst eens kijken naar de voordelen, want het heeft veel te bieden in vergelijking met de weinige nadelen.
Voordelen:
- Makkelijk uit te voeren.
- Vermindert het risico.
- Gebreken worden in een zeer vroeg stadium opgemerkt.
- Bespaart inspanningen, tijd en geld.
- Werkt snel indien geautomatiseerd.
- Minste integratierisico's en -problemen.
- Verbetert de algehele kwaliteit van het systeem.
Nadelen:
- Deze test is niet gelijk aan of een vervanging voor volledige functionele testen.
- Zelfs nadat de rooktest is geslaagd, kunt u showstopper-bugs vinden.
- Dit type testen is het meest geschikt als u kunt automatiseren, anders wordt er veel tijd besteed aan het handmatig uitvoeren van de testcases, vooral bij grootschalige projecten met ongeveer 700-800 testcases.
Smoke Testing moet zeker op elke build worden uitgevoerd, omdat het de belangrijkste fouten en showstoppers in een zeer vroeg stadium aan het licht brengt. Dit geldt niet alleen voor nieuwe functionaliteiten, maar ook voor de integratie van modules, het oplossen van problemen en improvisatie. Het is een heel eenvoudig proces om uit te voeren en het juiste resultaat te krijgen.
Dit testen kan worden beschouwd als het startpunt voor volledige functionele testen van functionaliteit of systeem (als geheel). Maar voor dat, het QA-team moet heel duidelijk zijn over welke tests moeten worden gedaan als rooktests Dit testen kan de inspanningen minimaliseren, tijd besparen en de kwaliteit van het systeem verbeteren. Het neemt een zeer belangrijke plaats in in sprints omdat de tijd in sprints korter is.
Dit testen kan zowel handmatig als ook met behulp van automatiseringstools worden gedaan. Maar de beste en geprefereerde manier is om automatiseringstools te gebruiken om tijd te besparen.
Verschil tussen testen op rook en gezond verstand
Meestal raken we in de war tussen de betekenis van Sanity Testing en Smoke Testing. Allereerst zijn deze twee tests ver ' anders ”En uitgevoerd tijdens verschillende fasen van een testcyclus.
S. Nee. | Rook testen | Sanity testen |
---|---|---|
1 | Rooktesten betekent om (basis) te verifiëren dat de implementaties die in een build zijn gedaan, goed werken. | Sanity testing betekent om te controleren of de nieuw toegevoegde functionaliteiten, bugs etc. goed werken. |
twee | Dit is de eerste test van de eerste build. | Gedaan als de build relatief stabiel is. |
3 | Gedaan bij elke build. | Gedaan op stabiele builds na regressie. |
Hieronder volgt een schematische weergave van hun verschillen:
ROOKTESTEN
- Dit testen is ontstaan in het hardware het testen van de praktijk om een nieuw stuk hardware voor het eerst aan te zetten en het als een succes te beschouwen als het geen vlam vat en rookt. In de software-industrie is dit testen een oppervlakkige en brede benadering waarbij alle toepassingsgebieden, zonder al te diep in te gaan, worden getest.
- Een rooktest wordt gescript, ofwel met behulp van een schriftelijke reeks tests of een geautomatiseerde test
- Een rooktest is ontworpen om elk onderdeel van de applicatie op een vluchtige manier aan te raken. Het is ondiep en breed.
- Deze test wordt uitgevoerd om te controleren of de meest cruciale functies van een programma werken, maar niet om de fijnere details. (Zoals build-verificatie).
- Deze test is een normale gezondheidscontrole tot aan het bouwen van een applicatie voordat deze grondig wordt getest.
GEZONDHEID TESTEN
- Een geestelijke gezondheidstest is een beperkte regressietest die zich richt op een of enkele functionele gebieden. Sanity Testing is meestal smal en diep.
- Deze test is meestal niet gescript.
- Deze test wordt gebruikt om te bepalen of een klein deel van de applicatie na een kleine wijziging nog werkt.
- Dit testen is een vluchtige test, het wordt uitgevoerd wanneer een vluchtige test voldoende is om te bewijzen dat de applicatie functioneert volgens de specificaties. Dit testniveau is een subset van regressietests.
- Dit is om te controleren of aan de vereisten is voldaan of niet, waarbij eerst alle functies worden gecontroleerd.
Ik hoop dat u duidelijk bent over de verschillen tussen deze twee uitgebreide en belangrijke typen softwaretests. Deel gerust je mening in de comments hieronder !!
Aanbevolen literatuur
- Beste softwaretesttools 2021 [QA Test Automation Tools]
- Verschil tussen Desktop, Client Server Testing en Web Testing
- Functioneel testen versus niet-functioneel testen
- Primer eBook downloaden testen
- Alfatesten en bètatesten (een complete gids)
- Gids voor het testen van draagbaarheid met praktische voorbeelden
- Soorten softwaretests: verschillende testtypen met details
- Functioneel testen versus prestatietesten: moet het tegelijkertijd worden uitgevoerd?