Ce este testarea fumului?

Ce este testarea fumului?

Testarea fumului este un proces de testare a software-ului care determină dacă versiunea software implementată este stabilă sau nu. Testarea fumului este o confirmare pentru echipa QA de a continua cu teste software ulterioare. Constă dintr-un set minim de teste rulate pe fiecare build pentru a testa funcționalitățile software. Testarea de fum este cunoscută și sub denumirea de „Test de verificare a construcției” sau „Test de încredere”.

În termeni simpli, testarea automată înseamnă verificarea faptului că funcțiile importante funcționează și că nu există obstacole în versiunea testată. Este un mini-test de regresie rapid al funcționalităților majore. Acest lucru ajută la determinarea dacă versiunea are defecte, astfel încât orice testare ulterioară să fie o pierdere de timp și resurse.

Comparaţie Test de fum vs sanitate

De ce facem teste de fum?

Testarea cu fum joacă un rol important în dezvoltarea de software, deoarece asigură corectitudinea sistemului în etapele inițiale. Prin aceasta, putem economisi efort de testare. Abia după ce finalizăm testarea cu fum, începem testarea funcțională.

• Toate aspectele spectaculoase ale construcției vor fi identificate prin efectuarea testelor de fum.
• Cu ajutorul testării cu fum, majoritatea defectelor sunt identificate în stadiile inițiale ale de dezvoltare de software.
• Prin testarea fumului, simplificăm detectarea și corectarea defectelor majore.
• Prin testarea de fum, echipa QA poate găsi defecte ale funcționalității aplicației care ar fi putut să fi apărut de noul cod.
• Testarea fumului descoperă defecte majore de severitate.

Exemplu 1: Fereastra de înregistrare: se poate trece la următoarea fereastră cu nume de utilizator și parolă valide făcând clic pe butonul de trimitere.

Exemplu 2: Utilizatorul nu se poate deconecta de la pagina web.

Când facem testarea fumului?

Aceste beneficii se materializează doar dacă verificarea este declanșată la momentul potrivit. Testarea fumului (Smoke Testing) se efectuează ori de câte ori noile funcționalități ale software-ului sunt dezvoltate și integrate cu versiunea existentă implementată în mediul QA/staging. Aceasta asigură că toate funcționalitățile critice funcționează corect sau nu. Diagrama de mai jos arată cum o versiune ajunge în mediul QA înainte de începerea testării fumului.

În această metodă de testare, echipa de dezvoltare implementează versiunea construită în cadrul QA. Un subset de cazuri de testare este luat și rulat de testeri pe baza funcționalităților critice ale versiunii. Aceste serii de cazuri de testare sunt concepute pentru a expune erorile existente în versiune. Dacă aceste teste sunt trecute, echipa QA continuă cu... Functional Testing.

Orice defecțiune indică necesitatea de a gestiona sistemul înapoi către echipa de dezvoltare. Ori de câte ori există o schimbare în construcție, efectuăm testarea fumului pentru a asigura stabilitatea.

Exemplu: -Butonul de înregistrare nou este adăugat în fereastra de autentificare și versiunea este implementată cu noul cod. Efectuăm teste de fum pe o construcție nouă.

Testele de fum califică versiunea pentru teste formale ulterioare și sunt concepute pentru a demonstra stabilitatea sistemului și conformitatea cu cerințele. Scopul principal este de a detecta din timp problemele majore. O versiune include toate fișierele de date, bibliotecile, modulele reutilizabile și componentele proiectate necesare pentru implementarea uneia sau mai multor funcții ale produsului.

Ce se întâmplă dacă nu efectuăm testarea fumului

Dacă nu efectuăm teste de fum în stadiile incipiente, pot apărea defecte în stadiile ulterioare, unde acest lucru poate fi costisitor. Defect descoperite în etapele ulterioare pot fi un obstacol care afectează lansarea rezultatelor.

Cine va face testarea fumului?

După lansarea build-ului în mediul QA, Smoke Testing este efectuat de către inginerii QA/responsabilul QA. Ori de câte ori există o nouă construcție, echipa QA determină funcționalitatea majoră a aplicației pentru a efectua testarea fumului. Echipa QA verifică dacă există showstoppers în aplicația care este în curs de testare.

Cum se face testarea fumului?

Testarea fumului se face de obicei manual, deși există posibilitatea de a realiza același lucru prin automatizare. Poate varia de la organizație la organizație.

Testarea manuală a fumului

Testarea funcțională este efectuată pentru a se asigura că navigarea pe căile critice este conform așteptărilor și nu împiedică funcționalitatea. Se iau cazuri de testare a funcționalității cu prioritate ridicată și se testează pentru a găsi defectele critice din sistem. Dacă testul este valid, continuăm testarea funcțională. Dacă testul eșuează, versiunea este respinsă și trimisă înapoi echipei de dezvoltare pentru corectare.

Asigurarea calității reia testarea fumului cu o nouă versiune de compilare. Testarea fumului se efectuează pe compilarea nouă și va fi integrată cu compilațiile vechi pentru a menține corectitudinea sistemului. Înainte de a efectua testarea fumului, echipa de asigurare calității ar trebui să verifice dacă versiunile de compilare sunt corecte.

Testarea fumului prin automatizare

Testarea automatizării este folosit pentru Testarea regresieiTotuși, putem folosi și un set de cazuri de testare automate pentru a rula împotriva Smoke Test. Cu ajutorul testelor de automatizare, dezvoltatorii pot verifica imediat versiunea, ori de câte ori există o versiune nouă gata de implementare.

În loc să se repete manual testul de fiecare dată când noua versiune de software este implementată, cazurile de testare de fum înregistrate sunt executate împotriva versiunii. Acesta verifică dacă funcționalitățile majore funcționează în continuare corect. Dacă testul eșuează, atunci ei pot corecta construcția și redistribui construirea imediat. Prin aceasta, putem economisi timp și putem asigura o construcție de calitate a mediului QA.

Folosind un instrument automat, inginerul de testare înregistrează toți pașii manuali care sunt executați în versiunea software.

Ciclul de testare a fumului

Diagrama de mai jos arată cum se execută testarea fumului. După ce versiunea de construcție este implementată în cadrul QA și testele de fum sunt trecute, se trece la testarea funcțională. Dacă testul de fum eșuează, închidem testarea până când problema din versiune este remediată.

Cele mai bune practici pentru proiectarea cazurilor de testare a fumului

A cunoaște ciclul e un lucru; keeping Suita care o face demnă de încredere este o altă opțiune. O suită pentru fumători își câștigă locul doar atunci când rămâne compactă, rapidă și repetabilă.

• Mai întâi, cartografiați căile critice: Enumerați fluxurile de lucru care fac produsul utilizabil comercial, cum ar fi autentificarea, căutarea, introducerea datelor, plata și deconectarea. Dacă unul dintre ele se defectează, versiunea nu are nicio valoare pentru un tester.
• Păstrați suita puțin adâncă, dar largă: Atingeți fiecare modul major o dată, în loc să explorați un singur modul în profunzime. Valorile limită, datele negative și formularea mesajelor de eroare aparțin testării funcționale, nu aici.
• Limitați timpul de execuție: Majoritatea echipelor țin alergarea între zece și cincisprezece minute și limitează suita la aproximativ douăzeci până la treizeci. cazuri de testareO alergare care durează o oră încetează să mai fie o poartă și devine un blocaj.
• Rulați aceleași cazuri la fiecare compilare: Consistența vă permite să atribuiți o eroare codului, mai degrabă decât unei selecții de test modificate.
• Eliminați cazurile instabile și cele cu dependențe mari: Un caz care trece și eșuează fără nicio modificare a codului distruge încrederea în poartă. Servicii terțe instabile de tip stub sau mock în care cadru de automatizare a testelor permite.
• Înregistrați un verdict fără echivoc: Fiecare caz are nevoie de un singur rezultat așteptat, astfel încât construcția să poată fi acceptată sau respinsă fără dezbatere.
• Versionează suita cu compilarea: Stocați cazurile de fum în același depozit ca și codul aplicației, astfel încât poarta să se potrivească întotdeauna cu versiunea testată.

RevVizualizați suita la fiecare lansare: retrageți cazurile pentru funcțiile care nu mai contează și adăugați fluxuri de lucru noi și critice.

Testarea fumului în conductele CI/CD

O suită proiectată în acest fel este suficient de ieftină pentru a rula la fiecare commit, ceea ce necesită livrarea modernă. integrare continuă server, cum ar fi Jenkins compilează codul, îl implementează într-un mediu de staging și apoi declanșează suita de procese fumat (smoke suit) ca primă etapă automată. O rulare verde promovează artefactul la etapele funcționale și de regresie, în timp ce o rulare roșie eșuează pipeline-ul și notifică dezvoltatorul care a efectuat comiterea în câteva minute.

Două plasări sunt comune. O rulare pre-merge protejează ramura principală prin validarea fiecărei solicitări de extragere, iar o rulare post-implementare confirmă că mediul implementat este accesibil și configurat corect. Echipele care practică implementarea continuă adaugă adesea o a treia rulare, ajustată, în producție imediat după lansare.

Deoarece pipeline-ul execută suita de mai multe ori pe zi, cazurile trebuie să fie neinteractive, autocurățabile și independente. Orice caz care așteaptă o decizie umană sau lasă în urmă date de testare va bloca pipeline-ul.

Avantajele testării fumului

Iată câteva avantaje enumerate pentru testarea fumului.

• Ușor de executat și rulează rapid
• Erorile și defectele critice sunt ușor de detectat și corectat în stadii incipiente.
• Îmbunătățește calitatea sistemului
• Reduce riscul
• Progresul este mai ușor de evaluat.
• Economisește timp și efort de testare
• Minimizează riscurile de integrare

⚠ Limitare de reținut: O testare superficială a unui test indică doar că versiunea este testabilă. Atinge superficial funcționalitățile majore, așa că defectele minore, cazurile limită și caracteristicile rareori utilizate rămân ascunse până la efectuarea testelor funcționale și de regresie. Nu considerați niciodată un test verde ca un semn că versiunea nu are defecte.

Testarea fumului vs. testarea sănătății mentale vs. testarea regresiei

Toate trei rulează după o modificare a codului, motiv pentru care sunt adesea confundate. Ele diferă în ceea ce privește domeniul de aplicare, profunzimea și întrebarea la care răspunde fiecare.

Testarea efectuată într-un mediu de dezvoltare asupra codului pentru a asigura corectitudinea aplicației înainte de lansarea versiunii pentru QA, aceasta fiind cunoscută sub numele de testare de conformitate. Este un proces care verifică dacă aplicația în curs de dezvoltare îndeplinește cerințele funcționale de bază.

Testarea corectă determină finalizarea fazei de dezvoltare și ia decizia dacă trece sau nu produsul software pentru faza de testare ulterioară.

BAZA	TESTAREA FUMULUI	TESTARE DE SANITATE	TESTAREA REGRESIEI
domeniu	Lat și superficial	Îngust și adânc	Lat și adânc
Întrebare răspunsă	Este această construcție suficient de stabilă pentru a fi testată?	Funcționează această soluție specifică?	S-a stricat ceva ce funcționa înainte?
Secvenţă	În primul rând, la fiecare construcție	După ce testul cu fum este trecut	După testarea sănătății mintale
Durată tipică	10 până la 15 minute	30 până la 60 minute	Hours până la zile
Potrivirea automatizării	Foarte inalt	Moderat, adesea manual	Foarte inalt

În practică, acestea rulează în secvență: testarea automată pentru acceptarea construcției, testarea integrității funcționale pentru verificarea modificărilor livrate și testarea de regresie atunci când programul permite.

Exemplu de cazuri de test de fum Exemplu

Tabelul de mai jos documentează o suită scurtă de fum, câte un rând per cale critică.

T.ID	SCENARIILE DE TESTARE	DESCRIERE	PASUL DE TESTARE	REZULTAT ASTEPTAT	REZULTAT ACTUAL	STAREA
1	Date de conectare valide	Testați funcționalitatea de conectare a aplicației web pentru a vă asigura că unui utilizator înregistrat îi este permis să se autentifice cu numele de utilizator și parola	1. Lansați aplicația 2.Navigați pe pagina de conectare 3.Introduceți un nume de utilizator valid 4.Introduceți parola validă 5. Faceți clic pe butonul de conectare	Conectarea ar trebui să aibă succes	cum era de așteptat	Trece
2	Adăugarea funcționalității articolului	Posibilitatea de a adăuga un articol în coș	1.Selectați lista de categorii 2.Adăugați articolul în coș	Articolul ar trebui adăugat în coș	Articolul nu este adăugat în coș	Eșua
3	Funcționalitatea de deconectare	Verificați funcționalitatea de deconectare	1. selectați butonul de deconectare	Utilizatorul ar trebui să se poată deconecta.	Utilizatorul nu se poate deconecta	Eșua

Întrebări frecvente