Røgtestning mod sundhedstest: Forskel med eksempler

smoke testing vs sanity testing

Udforsk forskellene mellem røgtest og sundhedstest i detaljer med eksempler:

I denne vejledning lærer vi, hvad der er Sanity Testing og Smoke Testing i Software Testing. Vi lærer også nøgleforskellene mellem sundhed og røgtest med enkle eksempler.

De fleste gange bliver vi forvirrede mellem betydningen af ​​Sanity Testing og Smoke Testing. Først og fremmest er disse to test langt ” forskellige ”Og udføres i forskellige faser af en testcyklus.

Hvad du vil lære:

• Sanity Testing
• Min erfaring
• Sanity Testing vs Regression Testing
• Strategi til mobilapptest
• Forebyggende foranstaltninger
• Røgtest
• Eksempler på røgtest
  • # 1) Acceptantestning
  • # 2) Integrationstest
  • # 3) Systemtest
• Vigtighed i SCRUM-metodologi
• Røgtest mod opbygning af accepttest
• Røgtestcyklus
• Hvem skal udføre røgprøven?
• Hvorfor skal vi automatisere røgtest?
• Fordele og ulemper
• Forskellen mellem røg og sundhedstest
  • RØGTESTING
  • SANITY TESTING
• Anbefalet læsning

Sanity Testing

Sanity Testing udføres, når vi som QA ikke har tilstrækkelig tid til at køre alle testsagerne, hvad enten det er Funktionel testning , UI, OS eller Browser Testing.

Derfor vil jeg definere,

'Sanity Testing som en testudførelse, der udføres for at røre ved hver implementering og dens virkning, men ikke grundigt eller dybtgående, det kan omfatte funktionel, UI, version osv. Test afhængigt af implementeringen og dens indvirkning.'

Faller vi ikke alle sammen i en situation, hvor vi skal logge af om en dag eller to, men build til test frigives stadig ikke?

mp3 gratis downloads til Android-telefoner

Ah ja, jeg vedder på dig, at du også skal have stået over for denne situation mindst en gang i din software test oplevelse. Nå, jeg stod meget over for det, fordi mine (e) projekt (er) for det meste var smidige, og til tider blev vi bedt om at levere det samme dag. Ups, hvordan kunne jeg teste og frigive bygningen inden for et stykke tid?

Jeg plejede at være nødder til tider, for selvom det var en lille funktionalitet, kunne implikationen være enorm. Og som en prikken over i'et nægter klienter nogle gange blot at give ekstra tid. Hvordan kunne jeg gennemføre hele testen om et par timer, kontrollere enhver funktionalitet, Bugs og frigive det?

Svaret på alle sådanne problemer var meget simpelt, dvs. intet andet end at bruge Strategi til sundhedstest.

Når vi udfører denne test for et modul eller en funktionalitet eller et komplet system, Test sager til eksekvering er valgt således, at de rører ved alle de vigtige bits og stykker af det samme, dvs. bred men lav test.

Til tider udføres testen endda tilfældigt uden testtilfælde. Men husk, Fornuftstest bør kun udføres, når du har kort tid, og brug den aldrig til dine regelmæssige udgivelser. Teoretisk set er denne test en delmængde af Regressionstest .

Min erfaring

I løbet af 3 år arbejdede jeg i min 8+ års karriere inden for softwaretest Agil metode y og det var den tid, hvor jeg for det meste brugte en fornuftstest.

Alle de store udgivelser blev planlagt og udført på en systematisk måde, men til tider blev små udgivelser bedt om at blive leveret så hurtigt som muligt. Vi fik ikke meget tid til at dokumentere testsagerne, udføre, lave fejldokumentationen, udføre regressionen og følge hele processen.

Derfor er følgende nogle af de vigtigste punkter, som jeg plejede at følge under sådanne situationer:

# 1) Sid med lederen og dev-teamet, når de diskuterer implementeringen, fordi de skal arbejde hurtigt, og derfor kan vi ikke forvente, at de forklarer os separat.

Dette vil også hjælpe dig med at få en idé om, hvad de skal implementere, hvilket område vil det påvirke osv., Dette er en meget vigtig ting at gøre, fordi vi til tider simpelthen ikke er klar over implikationerne, og hvis nogen eksisterende funktionalitet vil blive hæmmet (i værste fald).

#to) Da du har kort tid, når udviklingsholdet arbejder på implementeringen, kan du notere testsagerne groft i værktøjer som Evernote osv. Men sørg for at skrive dem et sted, så du kan tilføje dem senere til testcase-værktøjet.

# 3) Hold din testbed klar i henhold til implementeringen, og hvis du føler, at der er nogle røde flag som en bestemt datafremstilling, hvis en testbed vil tage tid (og det er en vigtig test for frigivelsen), skal du straks hæve disse flag og informere din manager eller PO om vejspærringen.

Bare fordi klienten ønsker asap, betyder det ikke, at en QA frigives, selvom den er halvtestet.

# 4) Lav en aftale med dit team og din manager om, at du på grund af tidsnød kun kommunikerer fejlene til udviklingsteamet, og den formelle proces med tilføjelse, markering af fejlene til forskellige faser i fejlsporingsværktøjet vil blive gjort senere for at spare tid .

# 5) Når udviklingsteamet tester ved deres afslutning, skal du prøve at parre dem (kaldet dev-QA-parring) og lave en grundlæggende runde på selve deres opsætning, dette hjælper med at undgå frem og tilbage af bygningen, hvis den grundlæggende implementering mislykkes .

# 6) Nu hvor du har bygningen, skal du teste forretningsreglerne og alle brugssager først. Du kan gemme tests som en validering af et felt, navigation osv. Til senere.

# 7) Uanset hvilke fejl du finder, skal du notere dem alle og prøve at rapportere dem sammen til udviklerne i stedet for at rapportere individuelt, fordi det vil være let for dem at arbejde på en flok.

# 8) Hvis du har et krav til den samlede Test af ydeevne eller stress- eller belastningstest, så sørg for at du har en ordentlig automatiseringsramme til det samme. Fordi det er næsten umuligt at manuelt teste disse med en fornuftstest.

# 9) Dette er den vigtigste del og faktisk det sidste trin i din tilregnelighedsteststrategi - “Når du udarbejder frigivelses-e-mailen eller dokumentet, skal du nævne alle de testsager, du udførte, bugs fundet med en statusmarkør, og hvis der var noget tilbage uprøvet nævne det med grundene ' Prøv at skrive en skarp historie om din test, som vil formidle alle om, hvad der er blevet testet, verificeret og hvad der ikke har været.

Jeg fulgte dette religiøst, da jeg brugte denne test.

Lad mig dele min egen oplevelse:

# 1) Vi arbejdede på et websted, og det plejede at pop op-annoncer baseret på nøgleordene. Annoncørerne brugte til at afgive bud på bestemte søgeord, der havde en skærm designet til det samme. Standardbudværdien blev tidligere vist som $ 0,25, som byderen endda kunne ændre.

Der var endnu et sted, hvor dette standardbud plejede at dukke op, og det kunne også ændres til en anden værdi. Klienten kom med en anmodning om at ændre standardværdien fra $ 0,25 til $ 0,5, men han nævnte kun den åbenlyse skærm.

Under vores brainstorming-diskussion glemte vi (?) Denne anden skærm, fordi den ikke blev brugt meget til det formål. Men mens jeg testede, da jeg kørte det grundlæggende tilfælde af, at budet var $ 0,5 og kontrolleret fra ende til anden, fandt jeg ud af, at cronjob for det samme mislykkedes, fordi det et sted fandt det $ 0,25.

Jeg rapporterede dette til mit team, og vi foretog ændringen og leverede den med succes samme dag selv.

#to) Under det samme projekt (nævnt ovenfor) blev vi bedt om at tilføje et lille tekstfelt til noter / kommentarer til budgivning. Det var en meget enkel implementering, og vi forpligtede os til at levere den samme dag.

Derfor, som nævnt ovenfor, testede jeg alle forretningsreglerne og brug sager omkring det, og da jeg foretog nogle valideringstest, fandt jeg ud af, at siden jeg kom ind i en kombination af specialtegn som, siden, styrtede siden.

Vi tænkte over det og fandt ud af, at de faktiske bydende under ingen omstændigheder vil bruge sådanne kombinationer. Derfor frigav vi det med en veludkastet note om problemet. Klienten accepterede det som en fejl, men aftalt med os at implementere det senere, fordi det var en alvorlig fejl, men ikke en tidligere.

# 3) For nylig arbejdede jeg på et mobilapp-projekt, og vi havde et krav om at opdatere leveringstidspunktet vist i appen i henhold til tidszonen. Det skulle ikke kun testes i appen, men også til webservicen.

Mens udviklingsteamet arbejdede på implementeringen, oprettede jeg automatiseringsscripts til webservicetest og DB-scripts til ændring af leveringsvarens tidszone. Dette reddede min indsats, og vi kunne opnå bedre resultater inden for kort varighed.

Sanity Testing vs Regression Testing

Nedenfor er et par forskelle mellem de to:

Strategi til mobilapptest

Du må undre dig over, hvorfor jeg specifikt nævner mobilapps her?

Årsagen er, at OS- og browserversionen til web- eller desktop-apps ikke varierer meget, og især skærmstørrelserne er standard. Men med mobilapps påvirker skærmstørrelsen, mobilnetværket, OS-versionerne osv. Stabiliteten, udseendet og kort sagt succesen med din mobilapp.

Derfor bliver en strategiformulering kritisk, når du udfører denne test på en mobilapp, fordi en fiasko kan give dig store problemer. Testen skal også udføres smart og med forsigtighed.

Følgende er nogle tip, der hjælper dig med at udføre denne test med succes i en 'mobilapp':

# 1) Først og fremmest skal du analysere OS-versionens indvirkning på implementeringen sammen med dit team.

Prøv at finde svar på spørgsmål som, vil adfærden være forskellig på tværs af versioner? Vil implementeringen fungere på den lavest understøttede version eller ej? Vil der være ydeevneproblemer til implementering af versioner? Er der nogen specifik funktion i operativsystemet, der kan påvirke implementeringen? etc.

#to) På ovenstående note, analyser også for telefonmodellerne, dvs. er der nogen funktioner i telefonen, der vil påvirke implementeringen? Er implementeringen af ​​adfærdsændring med GPS? Ændres implementeringsadfærden med telefonens kamera? osv. Hvis du finder ud af, at der ikke er nogen indvirkning, skal du undgå at teste på forskellige telefonmodeller.

# 3) Medmindre der er nogen UI-ændringer til implementeringen, vil jeg anbefale at holde UI-test på mindst mulig prioritet, kan du informere teamet (hvis du vil) om, at UI ikke vil blive testet.

# 4) For at spare tid skal du undgå at teste på gode netværk, fordi det er indlysende, at implementeringen fungerer som forventet på et stærkt netværk. Jeg vil anbefale at starte med test på et 4G- eller 3G-netværk.

# 5) Denne test skal udføres på kortere tid, men sørg for, at du foretager mindst en feltprøve, medmindre det kun er en ændring af brugergrænsefladen.

# 6) Hvis du skal teste for en matrix med forskellige operativsystemer og deres version, vil jeg foreslå, at du gør det på en smart måde. For eksempel skal du vælge de laveste, mellemstore og de nyeste OS-version par til test. Du kan nævne i udgivelsesdokumentet, at ikke alle kombinationer er testet.

# 7) Brug en lille, mellemstor og stor skærmstørrelse til at spare tid ved UI-implementeringstest. Du kan også bruge en simulator og en emulator.

Forebyggende foranstaltninger

Sanity Testing udføres, når du kører kort tid, og det er derfor ikke muligt for dig at køre hver testcase, og vigtigst af alt får du ikke tid nok til at planlægge din test. For at undgå skyldspilene er det bedre at tage forholdsregler.

I sådanne tilfælde er mangel på skriftlig kommunikation, testdokumentation og miss outs ret almindelige.

For at sikre, at du ikke bliver bytte for dette, skal du sørge for at:

• Accepter aldrig et build til test, før du ikke får et skriftligt krav, der deles af klienten. Det sker, at klienter kommunikerer ændringer eller nye implementeringer mundtligt eller i chat eller en simpel 1 liner i en e-mail og forventer, at vi behandler det som et krav. Tving din klient til at give nogle grundlæggende funktionalitetspunkter og acceptkriterier.
• Lav altid grove noter af dine testsager og fejl, hvis du ikke har tilstrækkelig tid til at skrive dem pænt. Efterlad aldrig disse udokumenterede. Hvis der er noget tid, så del det med din leder eller dit team, så hvis noget mangler, kan de let påpege det.
• Hvis du og dit team har kort tid, skal du sørge for, at fejlene er markeret i den rette tilstand i en e-mail? Du kan e-maile den komplette liste over fejl til teamet og få devs til at markere dem korrekt. Hold altid bolden i den andens bane.
• Hvis du har Automatiseringsramme klar, brug det og undgå at gøre Manuel testning , på den måde på kortere tid kan du dække mere.
• Undgå scenariet med 'frigivelse om 1 time', medmindre du er 100% sikker på, at du vil være i stand til at levere.
• Sidst men ikke mindst, som nævnt ovenfor, udkast til en detaljeret frigivelses-e-mail, der kommunikerer, hvad der er testet, hvad der er udeladt, årsager, risici, hvilke fejl der løses, hvad der er 'Latered' osv.

Som en kvalitetssikring skal du bedømme, hvad der er den vigtigste del af implementeringen, der skal testes, og hvad er de dele, der kan udelades eller basistestes.

Selv på kort tid skal du planlægge en strategi for, hvordan du vil gøre, og du vil være i stand til at opnå det bedste inden for den givne tidsramme.

Røgtest

Røgtestning er ikke udtømmende testning, men det er en gruppe tests, der udføres for at kontrollere, om de grundlæggende funktioner i den pågældende bygning fungerer fint som forventet eller ej. Dette er og bør altid være den første test, der skal udføres på enhver 'ny' build.

Når udviklingsteamet frigiver en build til QA til test, er det naturligvis ikke muligt at teste hele build og verificere med det samme, hvis nogen af ​​implementeringerne har fejl, eller hvis nogen af ​​funktionsfunktionerne er brudt.

På baggrund af dette, hvordan vil en kvalitetssikring sikre, at de grundlæggende funktioner fungerer fint?

Svaret på dette vil være at udføre en Røgtest .

Når testene først er markeret som røgtest (i testpakken), accepteres først build af QA til dybtgående test og / eller regression. Hvis nogen af ​​røgtestene mislykkes, afvises bygningen, og udviklingsteamet skal løse problemet og frigive et nyt build til test.

Teoretisk er røgtesten defineret som test på overfladeniveau for at certificere, at bygningen leveret af udviklingsholdet til QA-teamet er klar til yderligere test. Denne test udføres også af udviklingsteamet, inden buildet frigives til QA-teamet.

Denne test bruges normalt til integrationstest, systemtest og acceptniveaustest. Behandl aldrig dette som en erstatning for den faktiske afslutning til afslutning af fuldstændig test . Den består af både positive og negative tests afhængigt af buildimplementeringen.

Eksempler på røgtest

Denne test bruges normalt til integration, accept og Systemtest .

I min karriere som QA accepterede jeg altid kun et byggeri, efter at jeg havde udført en røgtest. Så lad os forstå, hvad der er en røgtest fra perspektivet af alle disse tre test, med nogle eksempler.

# 1) Acceptantestning

Hver gang en build frigives til QA, skal røgtest i form af en Accept test burde gøres.

I denne test er den første og vigtigste røgtest at kontrollere den grundlæggende forventede funktionalitet ved implementeringen. Som dette skal du kontrollere alle implementeringer til den pågældende build.

Lad os tage følgende eksempler som implementeringer udført i en build for at forstå røgtestene for dem:

• Implementerede loginfunktionen for at give de registrerede drivere mulighed for at logge ind med succes.
• Implementerede instrumentbrættets funktionalitet for at vise de ruter, som en chauffør skal udføre i dag.
• Implementerede funktionaliteten til at vise en passende besked, hvis der ikke findes nogen ruter for en given dag.

I ovenstående opbygning, på acceptniveauet, betyder røgtesten at verificere, at de grundlæggende tre implementeringer fungerer fint. Hvis nogen af ​​disse tre er brudt, skal QA afvise bygningen.

# 2) Integrationstest

Denne test udføres normalt, når de enkelte moduler implementeres og testes. I Integrationstest niveau, udføres denne test for at sikre, at al grundlæggende integration og ende til slut funktionalitet fungerer som forventet.

Det kan være integrationen af ​​to moduler eller alle moduler sammen, hvorfor kompleksiteten af ​​røgtesten vil variere afhængigt af integrationsniveauet.

Lad os overveje følgende eksempler på implementering af integration til denne test:

• Implementerede integrationen af ​​rute- og stopmoduler.
• Implementerede integrationen af ​​ankomststatusopdatering og afspejler det samme på stopskærmen.
• Implementerede integrationen af ​​komplet afhentning indtil leveringsfunktionalitetsmodulerne.

I denne build vil røgtesten ikke kun verificere disse tre grundlæggende implementeringer, men for den tredje implementering vil nogle få tilfælde også kontrollere for fuldstændig integration. Det hjælper meget med at finde ud af de problemer, der bliver introduceret i integration, og dem der gik ubemærket hen af ​​udviklingsteamet.

# 3) Systemtest

Som navnet selv antyder, for systemniveau inkluderer røgtesten test for de vigtigste og mest anvendte arbejdsgange i systemet. Dette gøres først, når det komplette system er klar og testet, og denne test for systemniveau kan også kaldes røgtest før regressionstest.

Inden regressionen af ​​det komplette system påbegyndes, testes de grundlæggende ende-til-slut-funktioner som en del af røgtesten. Røgtestpakken til det komplette system består af slut-til-slut-testtilfælde, som slutbrugerne vil bruge meget ofte.

Dette gøres normalt ved hjælp af automatiseringsværktøjer.

Vigtighed i SCRUM-metodologi

I dag følger projekterne næppe Waterfall-metoden i projektimplementeringen, for det meste følger alle projekterne Agile og SCRUM kun. Sammenlignet med den traditionelle vandfaldsmetode har Smoke Testing stor hilsen i SCRUM og Agile.

Jeg arbejdede i 4 år i SCRUM . Og som vi ved, at i SCRUM har sprints kortere varighed, og derfor er det ekstremt vigtigt at udføre denne test, så de mislykkede builds straks kan rapporteres til udviklingsteamet og også løses.

Følgende er nogle tag væk om vigtigheden af ​​denne test i SCRUM:

• Ud af den fjorten dage lange sprint tildeles halvdelen af ​​tiden til QA, men til tider er bygningerne til QA forsinket.
• I sprints er det bedst for holdet, at problemerne rapporteres på et tidligt tidspunkt.
• Hver historie har et sæt acceptkriterier, hvorfor test af de første 2-3 acceptkriterier er lig med røgtest af denne funktionalitet. Kunder afviser leveringen, hvis et enkelt kriterium ikke fungerer.
• Forestil dig, hvad der vil ske, hvis det er 2 dage, at udviklingsteamet leverede dig build, og der kun er 3 dage tilbage til demoen, og du støder på en grundlæggende funktionsfejl.
• I gennemsnit har en sprint historier, der spænder fra 5-10, og derfor er det vigtigt at sørge for, at hver historie implementeres som forventet, når buildet gives, før man accepterer buildet til testning.
• Når hele systemet skal testes og regresseres, er en sprint dedikeret til aktiviteten. To uger måske lidt mindre for at teste hele systemet, derfor er det meget vigtigt at kontrollere de mest basale funktionaliteter inden regressionen påbegyndes.

Røgtest mod opbygning af accepttest

Røgtest er direkte relateret til Build Acceptance Testing (BAT).

I BAT udfører vi den samme test - for at kontrollere, om build ikke har mislykkedes, og at systemet fungerer fint eller ej. Nogle gange sker det, at når en build oprettes, introduceres nogle problemer, og når den leveres, fungerer build ikke for QA.

Jeg vil sige, at BAT er en del af en røgkontrol, fordi hvis systemet svigter, hvordan kan du som QA acceptere build til test? Ikke kun funktionaliteterne, men selve systemet skal arbejde, før QA'erne fortsætter med dybtgående test.

Røgtestcyklus

Følgende rutediagram forklarer røgtestcyklussen.

Når først en build er implementeret i en QA, er den fulgte grundlæggende cyklus, at hvis røgtesten består, accepteres build af QA-teamet til yderligere test, men hvis det mislykkes, afvises buildet, indtil de rapporterede problemer er rettet.

Testcyklus

interview spørgsmål om resten webtjenester java

Hvem skal udføre røgprøven?

Ikke hele teamet er involveret i denne type test for at undgå spild af tid for alle QA'er.

Røgtest udføres ideelt af QA-lederen, der beslutter på baggrund af resultatet, om bygningen skal overføres til teamet til yderligere test eller afvises. Eller i mangel af bly, kan QA'erne selv også udføre denne test.

Til tider, når projektet er i stor skala, kan en gruppe QA også udføre denne test for at kontrollere, om der er showstoppere. Men dette er ikke tilfældet i tilfælde af SCRUM, fordi SCRUM er en flad struktur uden Leads eller Managers, og hver tester har deres eget ansvar over for deres historier.

Derfor udfører individuelle kvalitetssikringstest denne test for de historier, de ejer.

Hvorfor skal vi automatisere røgtest?

Denne testning er den første test, der udføres på en build frigivet af udviklingsteamet (-erne). Baseret på resultaterne af denne test udføres yderligere test (eller build afvises).

Den bedste måde at udføre denne test på er at bruge et automatiseringsværktøj og planlægge, at røgsuiten skal køre, når en ny build oprettes. Du tænker måske hvorfor skulle jeg “Automatisere røgtestpakken”?

Lad os se på følgende tilfælde:

Lad os sige, at du er en uge væk fra din løsladelse, og ud af de i alt 500 testtilfælde består din røgtestsuite af 80-90. Hvis du begynder at udføre alle disse 80-90 testsager manuelt, forestil dig hvor meget tid du vil tage? Jeg tror 4-5 dage (minimum).

Men hvis du bruger automatisering og opretter scripts til at køre alle disse 80-90 testtilfælde, køres disse ideelt set om 2-3 timer, og du vil have resultaterne med det samme. Sparede det ikke din dyrebare tid og gav dig resultaterne om indbygget meget kortere tid?

For 5 år tilbage testede jeg en app til finansiel projektion, der tog input om din løn, opsparing osv. Og projicerede dine skatter, besparelser, overskud afhængigt af de økonomiske regler. Sammen med dette havde vi tilpasning til lande, der er afhængige af landet og dets skatteregler, der blev brugt til at ændre (i koden).

Til dette projekt havde jeg 800 testtilfælde og 250 var røgtesttilfælde. Med brugen af ​​selen kunne vi let automatisere og få resultaterne af disse 250 testsager på 3-4 timer. Det sparede ikke kun vores tid, men viste os ASAP om showstoppere.

Derfor, medmindre det er umuligt at automatisere, skal du tage hjælp fra automatisering til denne test.

Fordele og ulemper

Lad os først se på fordelene, da det har meget at tilbyde sammenlignet med de få ulemper.

Fordele:

• Let at udføre.
• Reducerer risikoen.
• Mangler identificeres på et meget tidligt tidspunkt.
• Sparer indsats, tid og penge.
• Kører hurtigt, hvis det er automatiseret.
• Mindst integrationsrisici og problemer.
• Forbedrer systemets generelle kvalitet.

Ulemper:

• Denne test er ikke lig med eller erstatning for komplet funktionel test.
• Selv efter røgtesten er bestået, kan du finde showstopper-bugs.
• Denne type test er bedst egnet, hvis du kan automatisere andet, der bruges meget tid på manuel udførelse af testsagerne, især i store projekter, der har omkring 700-800 testsager.

Røgtestning bør bestemt udføres på hver bygning, da det påpeger de største fejl og showstoppere på et meget tidligt tidspunkt. Dette gælder ikke kun for nye funktioner, men også for integration af moduler, løsning af problemer og improvisation. Det er en meget enkel proces at udføre og få det korrekte resultat.

Denne test kan behandles som indgangspunktet for komplet funktionstest af funktionalitet eller system (som helhed). Men før det QA-teamet skal være meget tydeligt med, hvilke tests der skal udføres som røgtest . Denne test kan minimere indsatsen, spare tid og forbedre systemets kvalitet. Det har en meget vigtig plads i sprints, da tiden i sprints er mindre.

Denne test kan udføres både manuelt og også ved hjælp af automatiseringsværktøjer. Men den bedste og foretrukne måde er at bruge automatiseringsværktøjer til at spare tid.

Forskellen mellem røg og sundhedstest

De fleste gange bliver vi forvirrede mellem betydningen af ​​Sanity Testing og Smoke Testing. Først og fremmest er disse to test langt ” forskellige ”Og udføres i forskellige faser af en testcyklus.

Følgende er en diagrammatisk gengivelse af deres forskelle:

RØGTESTING

• Denne testning stammer fra hardware testpraksis for at tænde et nyt stykke hardware for første gang og betragte det som en succes, hvis det ikke tager fyr og røg. I softwareindustrien er denne test en lav og bred tilgang, hvor alle applikationsområderne testes uden at komme for dybt ind.
• En røgtest er scriptet, enten ved hjælp af et skriftligt sæt tests eller en automatiseret test
• En røgtest er designet til at berøre alle dele af applikationen på en overfladisk måde. Det er lavt og bredt.
• Denne test udføres for at sikre, om de mest vigtige funktioner i et program fungerer, men ikke gider med de finere detaljer. (Så som bygningsbekræftelse).
• Denne test er en normal helbredsundersøgelse af opbygningen af ​​en applikation, inden den tages for at teste dybtgående.

SANITY TESTING

• En tilregnelighedstest er en snæver regressionstest, der fokuserer på et eller et par funktionsområder. Sanity Testing er normalt smal og dyb.
• Denne test er normalt ikke skrevet.
• Denne test bruges til at bestemme, at en lille del af applikationen stadig fungerer efter en mindre ændring.
• Denne testning er kortvarig testning, den udføres, når en kortvarig testning er tilstrækkelig til at bevise, at applikationen fungerer i henhold til specifikationerne. Dette testniveau er en delmængde af regressionstest.
• Dette er for at kontrollere, om kravene er opfyldt eller ej, ved at kontrollere alle funktionerne bredt først.

Håber du er klar over forskellene mellem disse to store og vigtige softwaretesttyper. Del gerne dine tanker i kommentarfeltet nedenfor !!

Anbefalet læsning

• Bedste softwaretestværktøjer 2021 [QA Test Automation Tools]
• Forskel mellem Desktop, Client Server Testing og Web Testing
• Funktionel testning mod ikke-funktionel testning
• Test af Primer eBook Download
• Alpha Testing og Beta Testing (En komplet guide)
• Vejledning til bærbarhedstestning med praktiske eksempler
• Typer af softwaretest: Forskellige testtyper med detaljer
• Funktionstestning mod ydelsestestning: Skal det gøres samtidigt?