Testovanie dymu vs. Test príčetnosti: Rozdiel s príkladmi

smoke testing vs sanity testing

Preskúmajte rozdiely medzi testom dymu a testom príčetnosti podrobne na príkladoch:

V tomto tutoriále sa dozvieme, čo je Test zdravého rozumu a Testovanie dymu v Testovaní softvéru. Na jednoduchých príkladoch sa tiež dozvieme kľúčové rozdiely medzi testami Zdravý rozum a Dym.

Väčšinou sa mýlime medzi významom Testovania zdravého rozumu a Testovania dymu. V prvom rade sú tieto dve skúšky „ rôzne “A sú vykonávané v rôznych fázach testovacieho cyklu.

Čo sa dozviete:

• Testovanie príčetnosti
• Moje skúsenosti
• Test príčetnosti vs. Regresné testovanie
• Stratégia pre testovanie mobilných aplikácií
• Preventívne opatrenia
• Testovanie dymu
• Príklady testovania dymu
  • # 1) Testovanie prijatia
  • # 2) Testovanie integrácie
  • # 3) Testovanie systému
• Dôležitosť v metodike SCRUM
• Dymová skúška vs. Testovanie prijatia zostavy
• Cyklus skúšky dymu
• Kto by mal vykonať dymovú skúšku?
• Prečo by sme mali automatizovať dymové skúšky?
• Výhody a nevýhody
• Rozdiel medzi testovaním dymu a zdravým rozumom
  • TESTOVANIE DYMU
  • TESTOVANIE SANITY
• Odporúčané čítanie

Testovanie príčetnosti

Test príčetnosti sa robí, keď ako QA nemáme dostatok času na spustenie všetkých testovacích prípadov, či už Funkčné testovanie , UI, OS alebo testovanie prehliadača.

Preto by som definoval,

„Testovanie zdravého rozumu ako vykonávanie testu, ktorý sa dotýka každej implementácie a jej dopadu, ale nie dôkladne alebo do hĺbky, môže zahŕňať funkčné testovanie, testovanie používateľského rozhrania, verzie atď. V závislosti od implementácie a jej dopadu.“

Nepadli sme všetci do situácie, keď sa musíme o deň alebo dva prihlásiť, ale zostava na testovanie stále nie je vydaná?

nástroj na prevod videa z youtube na mp3

Ach áno, stavím sa s vami, že ste tiež museli čeliť tejto situácii aspoň raz počas testovania softvéru. No čelil som tomu dosť, pretože moje projekty boli väčšinou agilné a občas sme boli požiadaní, aby sme ich doručili v ten istý deň. Ojoj, ako by som mohol testovať a uvoľniť zostavu v priebehu niekoľkých hodín?

Občas som chodil na blázon, pretože aj keď to bola malá funkčnosť, implikácia mohla byť obrovská. A ako čerešničku na torte klienti niekedy jednoducho odmietnu dať čas navyše. Ako by som mohol absolvovať celé testovanie za pár hodín, overiť každú funkčnosť, Ploštice a pustit to?

Odpoveď na všetky tieto problémy bola veľmi jednoduchá, t. J. Nič iné ako použitie Stratégia testovania zdravého rozumu.

Keď robíme toto testovanie na modul alebo funkčnosť alebo kompletný systém, Testovacie prípady na vykonanie sú vybrané tak, aby sa dotýkali všetkých dôležitých častí rovnakého, t. j. širokého, ale plytkého testovania.

Testovanie sa niekedy robí náhodne bez testovacích prípadov. Ale pamätaj, Test príčetnosti by sa mal robiť iba v prípade, že vám chýba čas, nikdy ho nepoužívajte na bežné vydania. Teoreticky je toto testovanie podmnožinou Regresné testovanie .

Moje skúsenosti

Z mojej 8+ rokov kariéry v Testovaní softvéru som pracoval 3 roky Agilný metodik y a to bol čas, kedy som väčšinou používal test príčetnosti.

Všetky veľké vydania boli plánované a vykonávané systematickým spôsobom, ale občas bolo potrebné, aby boli malé vydania doručené čo najskôr. Nemali sme veľa času na zdokumentovanie testovacích prípadov, vykonanie, vykonanie dokumentácie o chybe, vykonanie regresie a sledovanie celého procesu.

Preto sú niektoré z kľúčových ukazovateľov, ktoré som v takýchto situáciách sledoval:

# 1) Sadnite si s manažérom a vývojovým tímom, keď diskutujú o implementácii, pretože musia pracovať rýchlo, a preto nemôžeme očakávať, že nám to vysvetlia osobitne.

To vám tiež pomôže získať predstavu o tom, čo sa chystajú implementovať, ktorej oblasti to ovplyvní atď., Čo je veľmi dôležité urobiť, pretože si občas jednoducho neuvedomujeme dôsledky a ak nejaká existujúca funkčnosť bude brzdené (v najhoršom prípade).

#dva) Pretože vám chýba čas, v čase, keď vývojový tím pracuje na implementácii, môžete testovacie prípady zaznamenať zhruba v nástrojoch ako Evernote atď. Nezabudnite ich však niekde napísať, aby ste ich mohli neskôr pridať do nástroj testovacieho prípadu.

# 3) Majte svoje testovacie lôžko pripravené podľa implementácie a ak máte pocit, že existujú nejaké červené príznaky, ako napríklad vytváranie konkrétnych údajov, ak testovacie centrum bude trvať určitý čas (a je to dôležitý test pre vydanie), okamžite tieto príznaky zdvihnite a informujte svojho manažéra alebo PO o zátarase.

Len preto, že klient chce čo najskôr, ešte to neznamená, že sa QA uvoľní, aj keď je napoly testované.

# 4) Dohodnite sa so svojím tímom a manažérom, že z dôvodu časovej tiesne budete chyby oznamovať iba vývojovému tímu a formálny proces pridávania, označovanie chýb pre rôzne fázy v nástroji na sledovanie chýb sa vykoná neskôr, aby sa ušetrila doba. .

# 5) Keď vývojový tím testuje na svojom konci, skúste sa s nimi spárovať (nazýva sa párovanie dev-QA) a urobte základné kolo ich samotného nastavenia. Pomôže to vyhnúť sa prípadným zmenám v zostave, ak zlyháva základná implementácia. .

# 6) Teraz, keď máte zostavenie, najskôr otestujte obchodné pravidlá a všetky prípady použitia. Testy ako overenie poľa, navigácia atď. Si môžete nechať na neskôr.

# 7) Nech už narazíte na akékoľvek chyby, poznačte si ich všetky a skúste ich nahlásiť vývojárom spoločne, než aby ste ich hlásili jednotlivo, pretože pre nich bude ľahké pracovať na hromadnej analýze.

# 8) Ak máte požiadavku na celkovú Testovanie výkonu alebo Záťažové alebo záťažové testovanie, potom sa uistite, či máte vhodný automatizačný rámec pre to isté. Pretože je takmer nemožné ich ručne otestovať testom zdravého rozumu.

# 9) Toto je najdôležitejšia časť a skutočne posledný krok vašej stratégie testovania zdravého rozumu - „Keď vypracujete e-mail s vydaním alebo dokument, uveďte všetky testovacie prípady, ktoré ste vykonali, chyby nájdené so značkou stavu a či niečo zostalo nevyskúšaný, uveďte to s dôvodmi „ Skúste o svojom testovaní napísať ostrý príbeh, ktorý každému priblíži, čo bolo testované, overené a čo ešte nebolo.

Pri testovaní som to nasledoval nábožensky.

Dovoľte mi podeliť sa o svoje vlastné skúsenosti:

# 1) Pracovali sme na webovej stránke, ktorá slúžila na vyskakovacie reklamy na základe kľúčových slov. Inzerenti zvykli umiestňovať ponuky pre konkrétne kľúčové slová, pre ktoré bola navrhnutá rovnaká obrazovka. Predvolená hodnota ponuky sa zvykla zobrazovať ako 0,25 USD, ktorú mohol uchádzač dokonca zmeniť.

Bolo tu ešte jedno miesto, kde sa predtým zobrazovala táto predvolená cenová ponuka, a tiež ju bolo možné zmeniť na inú hodnotu. Klient prišiel s požiadavkou na zmenu predvolenej hodnoty z 0,25 USD na 0,5 USD, spomenul však iba zrejmú obrazovku.

Počas našej diskusie o brainstormingu sme zabudli (?) Na túto druhú obrazovku, pretože sa na tento účel príliš nepoužívala. Ale pri testovaní, keď som spustil základný prípad ponuky s hodnotou 0,5 USD a skontroloval som koniec do konca, zistil som, že cronjob pre to isté zlyháva, pretože na jednom mieste nachádzal 0,25 USD.

Nahlásil som to svojmu tímu a my sme vykonali zmenu a úspešne sme ju doručili ešte v ten istý deň.

#dva) V rámci toho istého projektu (uvedeného vyššie) sme boli požiadaní, aby sme pridali malé textové pole pre poznámky / komentáre k ponukám. Bola to veľmi jednoduchá implementácia a zaviazali sme sa ju dodať v ten istý deň.

Preto, ako už bolo spomenuté vyššie, som testoval všetky obchodné pravidlá a prípady použitia okolo nich, a keď som urobil nejaké testovanie overenia, zistil som, že keď som zadal kombináciu špeciálnych znakov ako, stránka sa zrútila.

Rozmysleli sme si to a prišli sme na to, že skutoční uchádzači také kombinácie v žiadnom prípade nepoužívajú. Preto sme ho vydali s dobre vypracovanou poznámkou o tejto otázke. Klient to akceptoval ako chybu, ale súhlasil s nami, aby sme ju implementovali neskôr, pretože išlo o závažnú chybu, nie však predchádzajúcu.

# 3) Nedávno som pracoval na projekte mobilnej aplikácie a mali sme požiadavku aktualizovať čas doručenia zobrazený v aplikácii podľa časového pásma. Testovať sa to malo nielen v aplikácii, ale aj vo webovej službe.

Keď vývojový tím pracoval na implementácii, vytvoril som automatizačné skripty na testovanie webových služieb a skripty DB na zmenu časového pásma dodacej položky. To mi ušetrilo úsilie a v krátkom čase sme mohli dosiahnuť lepšie výsledky.

Test príčetnosti vs. Regresné testovanie

Ďalej je uvedených niekoľko rozdielov medzi týmito dvoma:

Stratégia pre testovanie mobilných aplikácií

Určite sa pýtate, prečo tu hovorím konkrétne o mobilných aplikáciách?

Dôvod je ten, že OS a verzia prehliadača pre webové alebo desktopové aplikácie sa príliš nelíšia a hlavne veľkosti obrazoviek sú štandardné. Ale s mobilnými aplikáciami ovplyvňuje veľkosť obrazovky, mobilná sieť, verzie operačného systému atď. Stabilitu, vzhľad a skrátka úspech vašej mobilnej aplikácie.

Z tohto dôvodu sa formulácia stratégie stáva kritickou, keď vykonávate toto testovanie v mobilnej aplikácii, pretože jedna porucha vás môže dostať do veľkých problémov. Testovanie musí byť vykonané inteligentne a opatrne.

Nasleduje niekoľko ukazovateľov, ktoré vám pomôžu úspešne vykonať toto testovanie v „mobilnej aplikácii“:

# 1) Najskôr so svojím tímom analyzujte vplyv verzie OS na implementáciu.

Skúste nájsť odpovede na otázky typu, bude sa chovanie líšiť vo všetkých verziách? Bude implementácia fungovať na najnižšej podporovanej verzii alebo nie? Vyskytnú sa problémy s výkonom pri implementácii verzií? Existuje nejaká špecifická vlastnosť OS, ktorá by mohla ovplyvniť správanie implementácie? atď.

#dva) Vo vyššie uvedenej poznámke vykonajte analýzu aj pre modely telefónov, t. J. Existujú nejaké vlastnosti telefónu, ktoré ovplyvnia implementáciu? Mení sa implementácia správania pomocou GPS? Mení sa implementačné správanie fotoaparátu fotoaparátu? atď. Ak zistíte, že to nemá žiadny vplyv, vyhnite sa testovaniu na rôznych modeloch telefónov.

# 3) Pokiaľ pri implementácii nedôjde k žiadnym zmenám používateľského rozhrania, odporúčal by som ponechať testovanie používateľského rozhrania s najmenšou prioritou, môžete informovať tím (ak chcete), že používateľské rozhranie nebude testované.

# 4) Z dôvodu úspory času sa vyhnite testovaniu na dobrých sieťach, pretože je zrejmé, že implementácia bude v silnej sieti fungovať podľa očakávaní. Odporučil by som začať testovaním na 4G alebo 3G sieti.

# 5) Toto testovanie je potrebné vykonať za kratší čas. Ak však nejde o obyčajnú zmenu používateľského rozhrania, musíte vykonať aspoň jeden test v teréne.

# 6) Ak musíte otestovať maticu rôznych OS a ich verzií, navrhol by som, aby ste to robili inteligentne. Napríklad na testovanie vyberte páry s najnižšou, strednou a najnovšou verziou OS. V dokumente k vydaniu môžete spomenúť, že nie každá kombinácia je testovaná.

# 7) Podobným spôsobom pri testovaní prípustnosti testu používateľského rozhrania používajte na šetrenie času malé, stredné a veľké veľkosti obrazovky. Môžete tiež použiť simulátor a emulátor.

Preventívne opatrenia

Test zdravého rozumu sa vykonáva, keď vám chýba čas, a preto nie je možné spustiť všetky testovacie prípady, a čo je najdôležitejšie, nemáte dostatok času na naplánovanie testovania. Aby ste sa vyhli hazardným hrám, je lepšie prijať preventívne opatrenia.

V takýchto prípadoch je dosť častý nedostatok písomnej komunikácie, dokumentácia k testom a zmeškanie.

Aby ste tomu nepodľahli, uistite sa, že:

• Nikdy neprijímajte zostavu na testovanie, kým nedostanete písomnú požiadavku zdieľanú klientom. Stáva sa, že klienti komunikujú zmeny alebo nové implementácie slovne alebo prostredníctvom chatu alebo jednoduchého linku 1 v e-maile a očakávajú, že to budeme považovať za požiadavku. Donútte svojho klienta, aby uviedol niektoré základné funkčné body a kritériá prijatia.
• Ak nemáte dostatok času na dôkladné napísanie testovacích prípadov a chýb, urobte si hrubé poznámky. Nikdy ich nenechávajte bez dokladov. Ak je čas, zdieľajte ho so svojím vedúcim alebo tímom, aby v prípade, že niečo chýba, mohli na to ľahko upozorniť.
• Ak vám a vášmu tímu chýba čas, uistite sa, že chyby sú v e-maile označené v príslušnom stave? Celý zoznam chýb môžete poslať e-mailom tímu a nechať ich vývojármi vhodne označiť. Vždy držte loptu na ihrisku toho druhého.
• Ak máte Automatizačný rámec pripravený, použite to a vyhnite sa tomu Ručné testovanie , tak za kratší čas pokryjete viac.
• Vyhýbajte sa scenáru „uvoľnenie do 1 hodiny“, pokiaľ si nie ste 100% istí, že budete schopní doručiť.
• V neposlednom rade, ako už bolo spomenuté vyššie, pripravte podrobný e-mail s oznámením, čo je testované, čo je vynechané, dôvody, riziká, ktoré chyby sú vyriešené, čo sú ‚Latered‘ atď.

Ako QA by ste mali posúdiť, ktorá je najdôležitejšia časť implementácie, ktorú je potrebné testovať, a ktoré sú časti, ktoré je možné vynechať alebo zásadne otestovať.

Aj v krátkom čase si naplánujte stratégiu, ako chcete robiť, a budete schopní dosiahnuť to najlepšie v danom časovom rámci.

Testovanie dymu

Testovanie dymu nie je vyčerpávajúcim testovaním, ale je to skupina testov, ktoré sa vykonávajú s cieľom overiť, či základné funkcie konkrétneho zostavenia fungujú podľa očakávania alebo nie. Toto je a vždy by mal byť prvý test, ktorý sa musí vykonať pri akomkoľvek „novom“ zostavení.

Keď vývojový tím vydá zostavu na QA na testovanie, nie je samozrejme možné otestovať celú zostavu a okamžite overiť, či niektorá z implementácií nemá chyby alebo či nie je porušená niektorá z funkčných funkcií.

Z tohto hľadiska, ako zabezpečí QA zabezpečenie dobrého fungovania základných funkcií?

Odpoveďou na to bude vykonať a Testovanie dymu .

Keď sú testy označené ako testy dymu (v testovacom balíku) vyhovejú, až potom QA prijme zostavenie na dôkladné testovanie a / alebo regresiu. Ak niektorý z testov dymu zlyhá, zostava je odmietnutá a vývojový tím musí problém vyriešiť a vydať novú zostavu na testovanie.

Teoreticky je Smoke test definovaný ako testovanie na povrchu, aby sa potvrdilo, že zostava poskytnutá vývojovým tímom tímu QA je pripravená na ďalšie testovanie. Toto testovanie vykonáva aj vývojový tím pred uvoľnením zostavy tímu QA.

Toto testovanie sa bežne používa pri testovaní integrácie, testovaní systému a testovaní úrovne prijatia. Nikdy to nepovažujte za náhradu skutočného úplného testovania . Pozostáva z pozitívnych aj negatívnych testov v závislosti od implementácie zostavenia.

Príklady testovania dymu

Toto testovanie sa zvyčajne používa na integráciu, prijatie a Testovanie systému .

Vo svojej kariére QA som vždy prijal zostavu až potom, čo som vykonal dymovú skúšku. Poďme si teda predstaviť, čo je to dymový test, z pohľadu všetkých týchto troch testov, na niekoľkých príkladoch.

# 1) Testovanie prijatia

Kedykoľvek sa uvoľní zostava pre QA, vykonajte dymovú skúšku vo forme Prijímacie skúšky malo by byť hotové.

V tomto teste je prvou a najdôležitejšou dymovou skúškou overenie základnej očakávanej funkčnosti implementácie. Takto by ste mali skontrolovať všetky implementácie pre dané zostavenie.

Vezmime si nasledujúce príklady ako implementácie vykonané v zostave, aby sme porozumeli testom dymu pre tieto skupiny:

• Implementovaná funkcia prihlásenia, ktorá umožňuje registrovaným vodičom úspešné prihlásenie.
• Implementovaná funkčnosť palubnej dosky s cieľom ukázať trasy, ktoré má vodič dnes vykonať.
• Implementovaná funkcia na zobrazovanie príslušnej správy, ak pre daný deň neexistujú žiadne trasy.

Vo vyššie uvedenom zostavení bude na úrovni prijatia dymová skúška znamenať overenie, či základné tri implementácie fungujú dobre. Ak je niektorý z týchto troch porušený, QA by mala zostavenie odmietnuť.

# 2) Testovanie integrácie

Toto testovanie sa zvyčajne vykonáva pri implementácii a testovaní jednotlivých modulov. V Testovanie integrácie úrovni sa toto testovanie vykonáva, aby sa zabezpečilo, že všetky základné funkcie integrácie a end-to-end fungujú podľa očakávania.

Môže to byť integrácia dvoch modulov alebo všetkých modulov dohromady, preto sa zložitosť dymovej skúšky bude líšiť v závislosti od úrovne integrácie.

Uvažujme o nasledujúcich príkladoch implementácie integrácie pre toto testovanie:

• Realizovaná integrácia modulov trasy a zastávok.
• Implementovaná integrácia aktualizácie stavu príchodu a odráža to isté na obrazovke zastávok.
• Implementovaná integrácia kompletného odberu až po moduly funkčnosti dodávky.

V tomto zostavení nebude dymová skúška overovať iba tieto tri základné implementácie, ale pri tretej implementácii bude niekoľko prípadov overovať aj úplnú integráciu. Veľmi pomáha pri hľadaní problémov, ktoré sa dostanú do integrácie, a problémov, ktoré si vývojový tím nevšimol.

# 3) Testovanie systému

Ako už samotný názov napovedá, na úrovni systému zahŕňa testovanie dymu testy najdôležitejších a najbežnejšie používaných pracovných tokov systému. To sa deje až potom, čo je hotový a otestovaný celý systém a toto testovanie na úrovni systému možno označiť ako testovanie dymu pred regresným testovaním.

Pred začatím regresie kompletného systému sú v rámci dymovej skúšky testované základné základné vlastnosti. Sada na testovanie dymu pre celý systém obsahuje testovacie prípady typu end-to-end, ktoré budú koncoví používatelia používať veľmi často.

To sa zvyčajne deje pomocou automatizačných nástrojov.

Dôležitosť v metodike SCRUM

V dnešnej dobe sa projekty pri realizácii projektov ťažko riadia metodikou Waterfall, väčšinou sa všetky riadia agilnými a SCRUM iba. V porovnaní s tradičnou vodopádovou metódou má Smoke Testing veľké uznanie v SCRUM a Agile.

Pracoval som 4 roky v SCRUM . A ako vieme, že v SCRUMe majú šprinty kratšie trvanie, a preto je mimoriadne dôležité vykonať toto testovanie, aby bolo možné neúspešné zostavenia okamžite hlásiť vývojovému tímu a opraviť ich tiež.

Nasledujú niektoré zobrať o dôležitosti tohto testovania v SCRUM:

• Z dvojtýždňového šprintu je polčas pridelený QA, ale niekedy sú zostavy QA oneskorené.
• V šprintoch je pre tím najlepšie, keď sa problémy hlásia už v počiatočnej fáze.
• Každý príbeh má súbor kritérií prijateľnosti, a preto sa testovanie prvých 2 až 3 kritérií prijatia rovná testovaniu dymu tejto funkčnosti. Zákazníci odmietnu dodávku, ak zlyháva jedno kritérium.
• Len si predstavte, čo sa stane, ak vám vývojový tím dodá zostavu dva dni a na ukážku zostávajú iba 3 dni a narazíte na zlyhanie základnej funkčnosti.
• Sprint má v priemere príbehy od 5 do 10, takže keď je dané zostavenie, je dôležité pred prijatím zostavenia do testovania zabezpečiť, aby bol každý príbeh implementovaný podľa očakávania.
• Keď sa má testovať a regresovať celý systém, tejto činnosti sa venuje šprint. O štrnásť dní možno o niečo menej na otestovanie celého systému, preto je veľmi dôležité pred začatím regresie overiť najzákladnejšie funkcie.

Dymová skúška vs. Testovanie prijatia zostavy

Testovanie dymu priamo súvisí s testom prijatia buildu (BAT).

V BAT robíme to isté testovanie - aby sme overili, či zostavenie zlyhalo a či systém funguje dobre alebo nie. Niekedy sa stáva, že keď sa vytvorí zostavenie, zavedú sa nejaké problémy a keď sa doručí, zostavenie nefunguje pre kontrolu kvality.

Povedal by som, že BAT je súčasťou kontroly dymu, pretože ak systém zlyháva, ako môžete ako QA prijať zostavenie na testovanie? Nielen funkcionality, ale samotný systém musí fungovať skôr, ako QA pristúpi k hĺbkovému testovaniu.

Cyklus skúšky dymu

Nasledujúci vývojový diagram vysvetľuje cyklus testovania dymu.

Akonáhle je zostavenie nasadené na QA, nasleduje základný cyklus je, že ak test dymu prejde, zostavenie je akceptované tímom QA na ďalšie testovanie, ale ak zlyhá, bude zostavenie odmietnuté, kým nebudú nahlásené problémy opravené.

aký je bezpečnostný kľúč na bezdrôtovom smerovači

Skúšobný cyklus

Kto by mal vykonať dymovú skúšku?

Do tohto typu testovania nie je zapojený celý tím, aby sa predišlo plytvaniu časom pri všetkých kontrolách kvality.

Testovanie dymu ideálne vykonáva vedúci QA, ktorý sa na základe výsledku rozhodne, či zostavu odovzdá tímu na ďalšie testovanie alebo ju odmietne. Alebo v prípade absencie prvenstva môžu toto testovanie vykonať aj samotní QA.

V čase, keď je projekt rozsiahly, môže skupina QA tiež vykonať toto testovanie a skontrolovať, či sa v ňom nenachádzajú nejaké showstoppery. Ale v prípade SCRUM to tak nie je, pretože SCRUM je plochá štruktúra bez vedúcich alebo manažérov a každý tester má svoje vlastné zodpovednosti za svoje príbehy.

Preto jednotlivé QA vykonávajú toto testovanie príbehov, ktoré vlastnia.

Prečo by sme mali automatizovať dymové skúšky?

Toto testovanie je prvým testom, ktorý sa má vykonať na zostavení vydanom vývojovým tímom. Na základe výsledkov tohto testovania sa vykonáva ďalšie testovanie (alebo je zostavenie odmietnuté).

Najlepším spôsobom, ako toto testovanie vykonať, je použiť automatizačný nástroj a naplánovať spustenie dymovej súpravy po vytvorení nového zostavenia. Možno si myslíte, prečo by som mal „Automatizovať sadu na testovanie dymu“?

Pozrime sa na nasledujúci prípad:

Povedzme, že ste týždeň od prepustenia a z celkového počtu 500 testovacích prípadov sa vaša sada na testovanie dymu skladá z 80–90. Ak začnete všetkých týchto 80 - 90 testovacích prípadov vykonávať ručne, predstavte si, koľko času vám zaberie? Myslím, že 4-5 dní (minimálne).

Ale ak na spustenie všetkých týchto 80-90 testovacích prípadov použijete automatizáciu a vytvoríte skripty, bude ideálne, ak sa spustia za 2 - 3 hodiny a výsledky budete mať okamžite pri sebe. Nešetrilo to váš drahocenný čas a výsledky zabudovania vám zostali oveľa kratšie?

Pred 5 rokmi som testoval aplikáciu pre finančnú projekciu, ktorá zisťovala údaje o vašom plate, úsporách atď. A premietala vaše dane, úspory, zisky v závislosti od finančných pravidiel. Spolu s tým sme mali prispôsobenie pre krajiny, ktoré závisia od krajiny, a jej daňové pravidlá, ktoré sa zvykli meniť (v kóde).

Pre tento projekt som mal 800 testovacích prípadov a 250 prípadov dymu. S použitím selénu by sme mohli ľahko automatizovať a získať výsledky z týchto 250 testovacích prípadov za 3-4 hodiny. Ušetrilo to nielen náš čas, ale ukázalo nám to čo najskôr o showstopperoch.

Preto, pokiaľ to nie je možné automatizovať, využite pri tomto testovaní automatizáciu.

Výhody a nevýhody

Najprv sa pozrime na výhody, ktoré má v porovnaní s niekoľkými nevýhodami čo ponúknuť.

Výhody:

• Ľahko sa vykonáva.
• Znižuje riziko.
• Poruchy sú identifikované vo veľmi skorom štádiu.
• Šetrí úsilie, čas a peniaze.
• Automaticky beží rýchlo.
• Najmenšie riziká a problémy integrácie.
• Zlepšuje celkovú kvalitu systému.

Nevýhody:

• Toto testovanie sa nerovná ani nenahrádza úplné funkčné testovanie.
• Aj po absolvovaní testu dymu môžete nájsť chyby Showstopper.
• Tento typ testovania je najvhodnejší, ak sa dá automatizovať, pretože veľa času sa venuje manuálnemu vykonávaniu testovacích prípadov, najmä vo veľkých projektoch, ktoré majú okolo 700 - 800 testovacích prípadov.

Test dymu by sa mal určite vykonať na každom zostavení, pretože poukazuje na veľké zlyhania a zastavovacie mechanizmy vo veľmi skorej fáze. To platí nielen pre nové funkcionality, ale aj pre integráciu modulov, riešenie problémov a improvizáciu. Vykonať a získať správny výsledok je veľmi jednoduchý proces.

Toto testovanie sa môže považovať za vstupný bod pre úplné funkčné testovanie funkčnosti alebo systému (ako celku). Ale predtým, tím QA by mal mať úplne jasno v tom, aké skúšky sa majú vykonať ako skúšky dymu . Toto testovanie môže minimalizovať úsilie, ušetriť čas a zlepšiť kvalitu systému. V šprintoch si drží veľmi dôležité miesto, pretože času v šprintoch je menej.

Toto testovanie je možné vykonať manuálne aj pomocou automatizačných nástrojov. Najlepším a preferovaným spôsobom je však použitie automatizačných nástrojov na úsporu času.

Rozdiel medzi testovaním dymu a zdravým rozumom

Väčšinou sa mýlime medzi významom Testovania zdravého rozumu a Testovania dymu. V prvom rade sú tieto dve skúšky „ rôzne “A vykonávané počas rôznych etáp testovacieho cyklu.

Nasleduje schematické znázornenie ich rozdielov:

TESTOVANIE DYMU

• Toto testovanie vzniklo v hardvér testovanie praxe pri prvom zapnutí nového hardvéru a považovanie za úspech, ak sa nezhorí a nefajčí. V softvérovom priemysle je toto testovanie povrchným a širokým prístupom, pri ktorom sa testujú všetky oblasti aplikácie bez toho, aby sme sa dostali príliš hlboko.
• Test dymu sa skriptuje, a to buď pomocou písomnej sady testov, alebo automatizovaného testu
• Dymový test je navrhnutý tak, aby sa zbežným spôsobom dotkol každej časti aplikácie. Je to plytké a široké.
• Toto testovanie sa vykonáva s cieľom zabezpečiť, či najdôležitejšie funkcie programu fungujú, ale netrápia ich jemnejšie podrobnosti. (Napríklad overenie zostavenia).
• Toto testovanie predstavuje bežnú kontrolu stavu zostavenia aplikácie pred vykonaním podrobného testovania.

TESTOVANIE SANITY

• Test zdravého rozumu je úzky regresný test zameraný na jednu alebo niekoľko oblastí funkčnosti. Test príčetnosti je zvyčajne úzky a hlboký.
• Tento test je zvyčajne skriptovaný.
• Tento test slúži na zistenie toho, že malá časť aplikácie funguje aj po menšej zmene.
• Toto testovanie je zbežné testovanie. Vykonáva sa vždy, keď zbežné testovanie postačuje na preukázanie fungovania aplikácie podľa špecifikácií. Táto úroveň testovania je podmnožinou regresného testovania.
• Týmto sa overuje, či sú požiadavky splnené alebo nie, a to najskôr kontrolou všetkých funkcií.

Dúfam, že máte jasno v rozdieloch medzi týmito dvoma obrovskými a dôležitými typmi testovania softvéru. Neváhajte a podeľte sa o svoje myšlienky v sekcii komentárov nižšie !!

Odporúčané čítanie

• Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
• Rozdiel medzi počítačom, klientskym serverom a webom
• Funkčné testovanie vs. Nefunkčné testovanie
• Stiahnutie e-knihy Testing Primer
• Alfa testovanie a beta testovanie (kompletný sprievodca)
• Príručka na testovanie prenosnosti s praktickými príkladmi
• Typy testovania softvéru: Rôzne typy testovania s podrobnosťami
• Funkčné testovanie vs. Testovanie výkonu: Malo by sa to robiť súčasne?