Što je ispitivanje dima?

Što je ispitivanje dima?

Ispitivanje dima je proces testiranja softvera koji utvrđuje je li implementirana verzija softvera stabilna ili ne. Testiranje dima je potvrda za QA tim da nastavi s daljnjim testiranjem softvera. Sastoji se od minimalnog skupa testova koji se izvode na svakoj verziji kako bi se testirale funkcionalnosti softvera. Testiranje dima poznato je i kao "Testiranje provjere izrade" ili "Testiranje povjerenja".

Jednostavno rečeno, testiranje dima znači provjeru da li važne značajke rade i da nema nikakvih nedostataka u testiranoj verziji. To je mini i brzi regresijski test glavnih funkcionalnosti. To pomaže u utvrđivanju je li verzija manjkava, tako da svako daljnje testiranje predstavlja gubljenje vremena i resursa.

Usporedi Testiranje dima protiv zdravog razuma

Zašto radimo testiranje dima?

Testiranje dima igra važnu ulogu u razvoju softvera jer osigurava ispravnost sustava u početnim fazama. Time možemo uštedjeti trud prilikom testiranja. Tek nakon što završimo s testiranjem dima, započinjemo s funkcionalnim testiranjem.

• Sve najvažnije značajke u gradnji bit će identificirane provođenjem testiranja dima.
• Uz pomoć testiranja dima, većina nedostataka se identificira u početnim fazama razvoj softvera.
• S ispitivanjem dima pojednostavljujemo otkrivanje i ispravljanje većih nedostataka.
• Testiranjem dima, QA tim može pronaći nedostatke u funkcionalnosti aplikacije koji su se mogli pojaviti zbog novog koda.
• Ispitivanje dima otkriva glavne nedostatke ozbiljnosti.

Primjer 1: Prozor za prijavu: mogućnost prelaska na sljedeći prozor s važećim korisničkim imenom i lozinkom nakon klika na gumb za slanje.

Primjer 2: Korisnik se ne može odjaviti s web stranice.

Kada provodimo testiranje dima?

Te se prednosti materijaliziraju samo ako se provjera pokrene u pravom trenutku. Testiranje dima provodi se kad god se nove funkcionalnosti softvera razvijaju i integriraju s postojećom izradom koja se implementira u QA/staging okruženju. Osigurava da sve kritične funkcionalnosti ispravno rade ili ne. Dijagram u nastavku prikazuje kako izrada dospijeva u QA okruženje prije početka testiranja dima.

U ovoj metodi testiranja, razvojni tim implementira izvedbu u QA. Testeri uzimaju podskup testnih slučajeva i pokreću ih u odnosu na kritične funkcionalnosti izvedbe. Ove serije testnih slučajeva osmišljene su kako bi otkrile pogreške koje se nalaze u izvedbi. Ako su ovi testovi uspješni, QA tim nastavlja s Funkcionalno ispitivanje.

Svaki kvar ukazuje na potrebu da se sustav vrati razvojnom timu. Kad god dođe do promjene u izradi, provodimo ispitivanje dima kako bismo osigurali stabilnost.

Primjer: -Novi gumb za registraciju dodan je u prozor za prijavu i izgradnja se postavlja s novim kodom. Provodimo ispitivanje dima na novogradnji.

Dimni testovi kvalificiraju verziju za daljnje formalno testiranje i osmišljeni su kako bi pokazali stabilnost sustava i usklađenost sa zahtjevima. Glavni cilj je rano otkrivanje glavnih problema. Verzija uključuje sve podatkovne datoteke, biblioteke, module za višekratnu upotrebu, projektirane komponente koje su potrebne za implementaciju jedne ili više funkcija proizvoda.

Što se događa ako ne provedemo testiranje dima

Ako ne provedemo testiranje dima u ranim fazama, nedostaci se mogu pojaviti u kasnijim fazama, što može biti skupo. Mana pronađeno u kasnijim fazama može biti prepreka koja utječe na objavu rezultata.

Tko će provoditi testiranje dima?

Nakon izdavanja međugradnje za QA okruženje, testiranje dima provode QA inženjeri/QA head. Kad god postoji nova verzija, QA tim određuje glavne funkcije u aplikaciji za izvođenje ispitivanja dima. QA tim provjerava ima li showstoppera u aplikaciji koja se testira.

Kako se provodi testiranje dima?

Ispitivanje dima obično se radi ručno iako postoji mogućnost da se isto postigne automatizacijom. Može se razlikovati od organizacije do organizacije.

Ručno testiranje dima

Testiranje dima provodi se kako bi se osiguralo da navigacija kritičnim putovima bude u skladu s očekivanjima i da ne ometa funkcionalnost. Uzimaju se i testiraju visokoprioritetni testni slučajevi funkcionalnosti kako bi se pronašli kritični nedostaci u sustavu. Ako test prođe, nastavljamo s funkcionalnim testiranjem. Ako test ne prođe, izrada se odbacuje i šalje natrag razvojnom timu na ispravak.

QA ponovno započinje testiranje dima s novom verzijom builda. Testiranje dima provodi se na novoj verziji i integrirat će se sa starim verzijama kako bi se održala ispravnost sustava. Prije izvođenja testiranja dima, QA tim treba provjeriti ispravne verzije builda.

Testiranje dima automatizacijom

Testiranje automatizacije koristi se za Ispitivanje regresijeMeđutim, možemo koristiti i skup automatiziranih testnih slučajeva za pokretanje protiv Smoke Testa. Uz pomoć automatiziranih testova, programeri mogu odmah provjeriti build, kad god postoji novi build spreman za implementaciju.

Umjesto ručnog ponovljenog testiranja kad god se nova verzija softvera postavi, snimljeni dimni testni slučajevi izvršavaju se u odnosu na verziju. Provjerava rade li glavne funkcije i dalje ispravno. Ako test ne uspije, oni mogu ispraviti međugradnju i odmah je ponovo rasporediti. Time možemo uštedjeti vrijeme i osigurati kvalitetnu izgradnju QA okruženja.

Koristeći automatizirani alat, testni inženjer bilježi sve ručne korake koji se izvode u izradi softvera.

Ciklus ispitivanja dima

Donji dijagram toka prikazuje kako se izvršava testiranje dima. Nakon što je izrada implementirana u QA i testovi dima su uspješni, nastavljamo s funkcionalnim testiranjem. Ako test dima ne uspije, izlazimo iz testiranja dok se problem u izradi ne riješi.

Najbolje prakse za dizajniranje testnih slučajeva dima

Poznavanje ciklusa je jedna stvar; zadržatiping Paket koji ga čini pouzdanim je nešto drugo. Paket za pušenje zaslužuje svoje mjesto samo kada ostane kompaktan, brz i ponovljiv.

• Prvo mapirajte kritične putove: Navedite tijekove rada koji čine proizvod komercijalno upotrebljivim, kao što su prijava, pretraživanje, unos podataka, plaćanje i odjava. Ako jedan od njih ne uspije, izrada nema vrijednost za testera.
• Neka apartman bude plitak, ali širok: Dotaknite se svakog glavnog modula jednom umjesto da ga detaljno istražujete. Granične vrijednosti, negativni podaci i tekstovi poruka o pogreškama pripadaju funkcionalnom testiranju, a ne ovdje.
• Ograničite vrijeme izvršenja: Većina timova drži trčanje između deset i petnaest minuta i ograničava se na otprilike dvadeset do trideset minuta. test slučajeviTrčanje koje traje sat vremena prestaje biti ulaz i postaje usko grlo.
• Pokreni iste slučajeve na svakoj izgradnji: Dosljednost vam omogućuje da neuspjeh pripišete kodu, a ne promijenjenom odabiru testa.
• Uklonite nestabilne i slučajeve s puno ovisnosti: Slučaj koji prolazi i ne uspijeva bez ikakve promjene koda uništava povjerenje u gate. Stub ili lažne nestabilne usluge trećih strana gdje okvir za automatizaciju testiranja dopušta.
• Zabilježite jednu nedvosmislenu presudu: Svaki slučaj zahtijeva jedan očekivani rezultat kako bi se izgradnja mogla prihvatiti ili odbaciti bez rasprave.
• Verzija paketa s izgradnjom: Pohranite slučajeve dima u isto spremište kao i kod aplikacije tako da se vrata uvijek podudaraju s testiranim izdanjem.

RevPregledajte paket za svako izdanje: ukinite slučajeve za značajke koje više nisu važne i dodajte nove kritične tijekove rada.

Ispitivanje dima u CI/CD cjevovodima

Ovako dizajniran paket je dovoljno jeftin da se izvršava na svakom commitu, što je ono što moderna isporuka zahtijeva. kontinuirana integracija poslužitelj kao što je Jenkins kompajlira kod, postavlja ga u okruženje za testiranje, a zatim pokreće smoke suite kao prvu automatiziranu fazu. Zeleno pokretanje promovira artefakt u funkcionalnu i regresijsku fazu, dok crveno pokretanje ne uspijeva u cjevovodu i obavještava programera koji ga je objavio u roku od nekoliko minuta.

Uobičajena su dva postavljanja. Pokretanje prije spajanja štiti glavnu granu provjerom svakog zahtjeva za povlačenjem, a pokretanje nakon implementacije potvrđuje da je implementirano okruženje dostupno i ispravno konfigurirano. Timovi koji prakticiraju kontinuirano implementiranje često dodaju treće, skraćeno pokretanje u produkciji odmah nakon objavljivanja.

Budući da cjevovod izvršava paket mnogo puta dnevno, slučajevi moraju biti neinteraktivni, samočisteći se i neovisni. Svaki slučaj koji čeka ljudsku odluku ili ostavlja testne podatke za sobom zaustavit će cjevovod.

Prednosti testiranja dima

Evo nekoliko navedenih prednosti za ispitivanje dima.

• Jednostavan za izvođenje i brzo radi
• Kritične pogreške i nedostatke lako je otkriti i ispraviti u ranim fazama.
• Poboljšava kvalitetu sustava
• Smanjuje rizik
• Napredak je lakše procijeniti.
• Štedi trud i vrijeme testiranja
• Minimizira rizik integracije

⚠ Napomena o ograničenju: Usputni trag zelenog dima samo pokazuje da je izrada testirana. Površno se dotiče glavnih funkcionalnosti, tako da manji nedostaci, rubni slučajevi i rijetko korištene značajke ostaju skriveni dok se ne pokrene funkcionalno i regresijsko testiranje. Nikada ne tretirajte zeleni rezultat dima kao znak da je izrada bez nedostataka.

Testiranje dima vs. testiranje razumnosti vs. regresijsko testiranje

Sva tri se pokreću nakon promjene koda, zbog čega se često brkaju. Razlikuju se po opsegu, dubini i pitanju na koje svaki od njih odgovara.

Testiranje koda provedeno u razvojnom okruženju kako bi se osigurala ispravnost aplikacije prije puštanja verzije na kontrolu kvalitete, poznato je kao testiranje ispravnosti. To je proces kojim se provjerava ispunjava li aplikacija u razvoju svoje osnovne funkcionalne zahtjeve.

Testiranje zdravog razuma utvrđuje završetak razvojne faze i donosi odluku o prolasku ili neprolasku softverskog proizvoda u daljnju fazu testiranja.

OSNOVA	ISPITIVANJE DIMA	TESTIRANJE RAČUNA	REGRESIONO TESTIRANJE
Djelokrug	Široko i plitko	Usko i duboko	Široko i duboko
Odgovoreno na pitanje	Je li ova konstrukcija dovoljno stabilna za testiranje?	Radi li ovo konkretno rješenje?	Je li se pokvarilo išta što je prije radilo?
Slijed	Prvo, na svakoj gradnji	Nakon što je testiranje dima uspješno	Nakon testiranja zdrave pameti
Tipično trajanje	10 do 15 minuta	30 do 60 minuta	Hours do dana
Automatizacija prilagođena	Vrlo visoko	Umjereno, često ručno	Vrlo visoko

U praksi se izvode u nizu: testiranje dima za prihvaćanje verzije, testiranje ispravnosti za provjeru isporučene promjene i regresijsko testiranje kada raspored dopušta.

Primjeri primjera ispitivanja dima

Donja tablica dokumentira kratki skup dima, jedan redak po kritičnom putu.

T.ID	TESTNI SCENARIJI	OPIS	TESTNI KORAK	OČEKIVANI REZULTAT	STVARNI REZULTAT	STATUS
1	Važeće vjerodajnice za prijavu	Testirajte funkcionalnost prijave web aplikacije kako biste bili sigurni da je registriranom korisniku dopuštena prijava s korisničkim imenom i lozinkom	1. Pokrenite aplikaciju 2. Krećite se stranicom za prijavu 3. Unesite važeće korisničko ime 4. Unesite valjanu lozinku 5. Kliknite na gumb za prijavu	Prijava bi trebala biti uspješna	kao što se očekuje	Proći
2	Dodavanje funkcionalnosti artikla	Mogućnost dodavanja artikla u košaricu	1. Odaberite popis kategorija 2.Dodajte artikl u košaricu	Artikal bi trebao biti dodan u košaricu	Artikl se ne dodaje u košaricu	Podbaciti
3	Funkcija odjave	Provjerite funkciju odjave	1. odaberite gumb za odjavu	Korisnik bi se trebao moći odjaviti.	Korisnik se ne može odjaviti	Podbaciti

Pitanja i odgovori