Good Mood

explorați diferențele dintre testarea fumului și testarea sănătății mintale în detaliu cu exemple:

în acest tutorial, vom afla ce este testarea sănătății mintale și testarea fumului în testarea Software-ului. Vom învăța, de asemenea, diferențele cheie dintre sănătatea mintală și testarea fumului cu exemple simple.de cele mai multe ori ne confundăm între sensul testării sănătății mintale și testarea fumului. În primul rând, aceste două teste sunt mod „diferite” și sunt efectuate în diferite etape ale unui ciclu de testare.,

testarea Sanity

testarea Sanity se face atunci când ca un QA nu avem suficient timp pentru a rula toate cazurile de testare, fie că este vorba de testare funcțională, UI, OS sau testare Browser.

prin urmare, aș defini

„testarea Sanității ca o execuție de testare care se face pentru a atinge fiecare implementare și impactul acesteia, dar nu în profunzime sau în profunzime, poate include funcțional, UI, versiune etc. testarea în funcție de implementare și impactul acesteia.”

nu cădem cu toții într-o situație în care trebuie să semnăm într-o zi sau două, dar construirea pentru testare nu este încă lansată?,

Ah da, pun pariu că, de asemenea, trebuie să fi confruntat cu această situație cel puțin o dată în experiența de Testare Software. Ei bine, m-am confruntat mult pentru că proiectele mele erau în mare parte agile și uneori ni s-a cerut să le livrăm în aceeași zi. Oops, cum aș putea testa și elibera construi într-un interval de ore?

obișnuiam să înnebunesc uneori pentru că, chiar dacă era o funcționalitate mică, implicația ar putea fi extraordinară. Și ca o glazură pe tort, clienții uneori refuză pur și simplu să acorde timp suplimentar., Cum aș putea finaliza întreaga testare în câteva ore, să verific fiecare funcționalitate, bug-uri și să o eliberez?răspunsul la toate aceste probleme a fost foarte simplu, adică nimic, dar folosind strategia de testare bun-simț.

când facem această testare pentru un modul sau o funcționalitate sau un sistem complet, cazurile de testare pentru execuție sunt selectate astfel încât să atingă toți biții și piesele importante ale aceluiași, adică testarea largă, dar superficială.uneori, testarea se face chiar la întâmplare, fără cazuri de testare., Dar amintiți-vă, Test de bun-simț ar trebui să se facă numai atunci când se execută scurt de timp, nu utilizați acest lucru pentru versiunile regulate. Teoretic, această testare este un subset de testare de regresie.

experiența mea

Din cei peste 8 ani de carieră în testarea Software-ului, timp de 3 ani am lucrat în metodologia Agile și atunci am folosit mai ales un test de sănătate.

Toate marile lansări au fost planificate și executate într-o manieră sistematică, dar, uneori, mici versiuni au cerut să fie livrate cât mai curând posibil., Nu am avut prea mult timp să documentăm cazurile de testare, să executăm, să facem documentația de eroare, să facem regresia și să urmăm întregul proces.prin urmare, următoarele sunt câteva dintre indicii cheie pe care am folosit pentru a urmări în astfel de situații:

#1) Stai cu managerul și echipa dev atunci când discută implementarea, deoarece trebuie să lucreze rapid și, prin urmare, nu ne putem aștepta ca ei să ne explice separat.acest lucru vă va ajuta, de asemenea, să vă faceți o idee despre ce vor implementa, ce zonă va afecta etc.,, acesta este un lucru foarte important de făcut, deoarece uneori pur și simplu nu realizăm implicațiile și dacă orice funcționalitate existentă va fi împiedicată (în cel mai rău caz).

#2) Pe măsură ce nu aveți timp, până când echipa de dezvoltare lucrează la implementare, puteți nota cazurile de testare aproximativ în instrumente precum Evernote etc. Dar asigurați-vă că le scrieți undeva, astfel încât să le puteți adăuga mai târziu la instrumentul test case.,

#3) Păstrați testbed gata ca pe punerea în aplicare și dacă vă simțiți că nu există nici steaguri roșii ca niște specifice de creare a datelor dacă un testbed va lua timp (și e un test important pentru eliberare), apoi ridica steagurile alea imediat și informează managerul sau PO despre blocaj.

doar pentru că clientul vrea asap, aceasta nu înseamnă că un QA va elibera, chiar dacă este pe jumătate testat.,

#4) Faceți un acord cu echipa și managerul dvs. că, din cauza timpului de criză, veți comunica doar bug-urile echipei de dezvoltare, iar procesul formal de adăugare, marcarea bug-urilor pentru diferite etape din instrumentul de urmărire a erorilor se va face mai târziu pentru a economisi timp.

#5) atunci când echipa de dezvoltare testează la sfârșitul lor, încercați să asociați cu ei (numit dev-QA pairing) și de a face o rundă de bază pe configurarea lor în sine, acest lucru va ajuta pentru a evita încoace și încolo a construi în cazul în care implementarea de bază eșuează.,

#6) acum că ați construit, testați mai întâi regulile de afaceri și toate cazurile de utilizare. Puteți păstra teste ca o validare a unui câmp, navigare, etc pentru mai târziu.

#7) oricare ar fi bug-urile pe care le găsiți, notați-le pe toate și încercați să le raportați împreună dezvoltatorilor, mai degrabă decât să raportați individual, deoarece le va fi ușor să lucreze la o grămadă.

#8) dacă aveți o cerință pentru testarea generală a performanței sau testarea stresului sau a încărcării, asigurați-vă că aveți un cadru de automatizare adecvat pentru același lucru., Pentru că este aproape imposibil să le testați manual cu un test de sănătate.

#9) Aceasta este cea mai importantă parte, și într-adevăr, ultimul pas de sanatatea ta strategie de testare – „atunci Când proiectul de eliberarea de e-mail sau documentul menționa toate cazurile de test care le-a executat, bug-uri găsite cu un marker de stare și dacă a mai rămas ceva netestat-l menționez cu motive” să Încerce să scrie o poveste clară despre testare, care va transmite tuturor despre ce a fost testat, verificat și ceea ce nu a fost.

am urmat acest lucru religios când am fost folosind acest test.,

permiteți-mi să împărtășesc propria mea experiență:

#1) lucram la un site web și obișnuia să apară reclame pe baza cuvintelor cheie. Agenții de publicitate obișnuiau să plaseze oferta pentru anumite cuvinte cheie care aveau un ecran proiectat pentru același lucru. Valoarea implicită a ofertei a fost afișată ca 0,25 USD, pe care ofertantul ar putea chiar să o schimbe.

a existat încă un loc în care această sumă licitată implicită obișnuia să apară și putea fi schimbată și cu altă valoare. Clientul a venit cu o solicitare de a schimba valoarea implicită de la $0.25 la $0.5, dar a menționat doar ecranul evident.,

în timpul discuției noastre de brainstorming, am uitat (?) despre acest alt ecran, deoarece nu a fost folosit prea mult în acest scop. Dar, în timp ce testam când am rulat cazul de bază al ofertei fiind $0.5 și verificat de la capăt la capăt, am constatat că cronjob-ul pentru același lucru nu reușea, deoarece la un loc găsea $0.25.

am raportat acest lucru Echipei Mele și am făcut schimbarea și am livrat-o cu succes în aceeași zi.

#2) în cadrul aceluiași proiect (menționat mai sus), ni s-a cerut să adăugăm un câmp text mic pentru note/comentarii pentru licitare., A fost o implementare foarte simplă și ne-am angajat să o Livrăm în aceeași zi.

prin Urmare, așa cum sa menționat mai sus, am testat toate regulile de afaceri și cazuri de utilizare în jurul valorii de ea și când am făcut niște teste de validare, am constatat că, atunci când am intrat într-o combinație de caractere speciale cum ar fi </>, pe pagina sa prăbușit.

ne-am gândit și ne-am dat seama că ofertanții reali nu vor folosi în niciun caz astfel de combinații. Prin urmare, am lansat-o cu o notă bine redactată despre această problemă., Clientul a acceptat ca o eroare, dar a fost de acord cu noi să o implementăm mai târziu, deoarece a fost o eroare severă, dar nu una anterioară.

#3) Recent, am fost de lucru pe un proiect de aplicații mobile, și am avut o cerință de a actualiza ora de livrare indicat în aplicația ca pe fusul orar. Nu a fost doar testat în aplicație, ci și pentru serviciul web.

în timp ce echipa de dezvoltare lucra la implementare, am creat scripturile de automatizare pentru testarea serviciului web și scripturile DB pentru schimbarea fusului orar al elementului de livrare., Acest lucru mi-a salvat eforturile și am putut obține rezultate mai bune într-o perioadă scurtă de timp.

bun-simț Testarea Vs Testarea de Regresie

Având în vedere de mai jos sunt câteva diferențe între cele două:

Strategie Pentru Mobile App de Testare

trebuie să Vă întrebați de ce am menționat în mod special despre aplicații mobile aici?

motivul este că versiunea sistemului de operare și a browserului pentru aplicațiile web sau desktop nu variază mult și mai ales dimensiunile ecranului sunt standard. Dar cu aplicațiile mobile, dimensiunea ecranului, rețeaua mobilă, versiunile sistemului de operare etc. afectează stabilitatea, aspectul și, pe scurt, succesul aplicației dvs. mobile.,prin urmare, o formulare de strategie devine critică atunci când efectuați această testare pe o aplicație mobilă, deoarece un eșec vă poate ateriza în probleme mari. Testarea trebuie făcută inteligent și cu prudență.

următoarele sunt câteva indicii pentru a vă ajuta să efectuați această testare cu succes pe o „aplicație mobilă”:

#1) în primul rând, analizați impactul versiunii sistemului de operare asupra implementării cu echipa dvs.

încercați să găsiți răspunsuri la întrebări precum, comportamentul va fi diferit în versiuni? Implementarea va funcționa pe cea mai mică versiune acceptată sau nu?, Vor exista probleme de performanță pentru implementarea versiunilor? Există vreo caracteristică specifică a sistemului de operare care ar putea afecta comportamentul implementării? etc.

#2) în nota de mai sus, analizați și modelele de telefon, adică există caracteristici ale telefonului care vor afecta implementarea? Implementarea comportamentului se schimbă cu GPS? Comportamentul de implementare se schimbă cu camera telefonului? etc. Dacă descoperiți că nu există niciun impact, evitați testarea pe diferite modele de telefoane.,

#3) cu excepția cazului în care există modificări UI pentru implementare, aș recomanda păstrarea testării UI pe cea mai mică prioritate, puteți informa echipa (dacă doriți) că UI nu va fi testată.

#4) pentru a vă economisi timpul, evitați testarea pe rețele bune, deoarece este evident că implementarea va funcționa așa cum era de așteptat într-o rețea puternică. Aș recomanda să începeți cu testarea pe o rețea 4G sau 3G.

#5) această testare trebuie făcută în mai puțin timp, dar asigurați-vă că faceți cel puțin un test pe teren, cu excepția cazului în care este o simplă schimbare UI.,

#6) dacă trebuie să testați pentru o matrice de diferite sisteme de operare și versiunea lor, aș sugera să o faceți într-un mod inteligent. De exemplu, alegeți cele mai mici, medii și cele mai recente perechi de versiuni de sistem de operare pentru testare. Puteți menționa în documentul de lansare că nu toate combinațiile sunt testate.

#7) pe o linie similară, pentru testul de implementare a UI-ului, utilizați dimensiuni de ecran mici, medii și mari pentru a economisi timp. De asemenea, puteți utiliza un simulator și un emulator.,

măsuri de precauție

testarea Sanității se efectuează atunci când nu aveți timp suficient și, prin urmare, nu este posibil să rulați fiecare caz de testare și, cel mai important, nu vi se acordă suficient timp pentru a vă planifica testarea. Pentru a evita jocurile de vina, este mai bine să ia măsuri de precauție.în astfel de cazuri, lipsa comunicării scrise, a documentației de testare și a ratărilor sunt destul de frecvente.,pentru a vă asigura că nu cădeți pradă acestui lucru, asigurați-vă că:

• nu acceptați niciodată o construcție pentru testare până când nu vi se oferă o cerință scrisă împărtășită de client. Se întâmplă ca clienții să comunice modificări sau implementări noi verbal sau în chat sau un simplu liner 1 într-un e-mail și se așteaptă ca noi să tratăm acest lucru ca o cerință. Obligă clientul să furnizeze câteva puncte de funcționalitate de bază și criterii de acceptare.
• întotdeauna face note brute de cazuri de testare și bug-uri, dacă nu aveți suficient timp pentru a le scrie frumos. Nu lăsați niciodată aceste documente., Dacă există ceva timp, împărtășiți-l cu conducerea sau echipa dvs., astfel încât, dacă lipsește ceva, să-l poată indica cu ușurință.
• dacă tu și echipa ta nu aveți timp, asigurați-vă că erorile sunt marcate în starea corespunzătoare într-un e-mail? Puteți trimite prin e-mail lista completă de bug-uri echipei și puteți face ca devs să le marcheze în mod corespunzător. Păstrați întotdeauna mingea în terenul celuilalt.
• dacă aveți cadru de automatizare gata, utilizați că și pentru a evita a face ManualTesting, în acest fel în mai puțin timp puteți acoperi mai mult.,
• evitați scenariul „eliberare în 1 oră” dacă nu sunteți 100% sigur că veți putea livra.
• Ultimul, dar nu cel mai puțin, după cum sa menționat mai sus, proiectul detaliat de presă e-mail comunica ceea ce este testat, ceea ce este lăsat afară, motive, riscuri, care bug-uri sunt rezolvate, ce ‘Latered’ etc.ca o asigurare a calității, ar trebui să evaluați care este cea mai importantă parte a implementării care trebuie testată și care sunt părțile care pot fi lăsate afară sau testate de bază.,chiar și într-un timp scurt, planificați o strategie despre modul în care doriți să faceți și veți putea obține cele mai bune rezultate în intervalul de timp dat.testarea fumului nu este o testare exhaustivă, dar este un grup de teste care sunt executate pentru a verifica dacă funcționalitățile de bază ale acelei construcții funcționează bine așa cum era de așteptat sau nu. Acesta este și ar trebui să fie întotdeauna primul test care trebuie făcut pe orice construcție „nouă”.,

  când echipa de dezvoltare lansează o construcție la QA pentru testare, este evident că nu este posibil să testați întreaga construcție și să verificați imediat dacă oricare dintre implementări are erori sau dacă oricare dintre funcționalitățile de lucru este întreruptă.având în vedere acest lucru, cum se va asigura o asigurare a calității că funcționalitățile de bază funcționează bine?răspunsul la aceasta va fi efectuarea unui test de fum.odată ce testele sunt marcate ca teste de fum (în suita de testare) trec, numai atunci construirea este acceptată de QA pentru testare în profunzime și/sau regresie., Dacă oricare dintre testele de fum eșuează, construcția este respinsă, iar echipa de dezvoltare trebuie să remedieze problema și să elibereze o nouă construcție pentru testare.Teoretic, testul de fum este definit ca testarea la nivel de suprafață pentru a certifica faptul că construcția furnizată de echipa de dezvoltare echipei de asigurare a Calității este pregătită pentru teste suplimentare. Această testare este, de asemenea, efectuată de echipa de dezvoltare înainte de a elibera construirea echipei de asigurare a calității.

  această testare este utilizată în mod normal în testarea integrării, testarea sistemului și testarea nivelului de acceptare. Nu tratați niciodată acest lucru ca un substitut pentru testarea completă de la capăt la capăt., Acesta cuprinde atât teste pozitive, cât și negative, în funcție de implementarea construirii.

  Exemple de testare a fumului

  această testare este utilizată în mod normal pentru integrarea, acceptarea și testarea sistemului.în cariera mea de ac, am acceptat întotdeauna o construcție numai după ce am efectuat un test de fum. Deci, să înțelegem ce este un test de fum din perspectiva tuturor acestor trei teste, cu câteva exemple.

  #1) testarea de acceptare

  ori de câte ori o construcție este eliberată la QA, testul de fum sub forma unei teste de acceptare ar trebui să fie făcut.,în acest test, primul și cel mai important test de fum este de a verifica funcționalitatea de bază preconizată a implementării. Astfel, ar trebui să verificați toate implementările pentru acea construcție particulară.

  Să luăm următoarele Exemple de implementări făcut într-o construiască pentru a înțelege teste de fum pentru cei:

  • Implementată funcționalitatea de autentificare, pentru a permite înregistrat șoferii să vă conectați cu succes.
  • a implementat funcționalitatea tabloului de bord pentru a afișa rutele pe care un driver trebuie să le execute astăzi.,
  • a implementat funcționalitatea pentru a afișa un mesaj adecvat dacă nu există rute pentru o anumită zi.

  în construcția de mai sus, la nivelul de acceptare, testul de fum va însemna să verifice dacă cele trei implementări de bază funcționează bine. În cazul în care oricare dintre aceste trei este rupt, atunci ac ar trebui să respingă construi.

  # 2) testarea integrării

  această testare se face de obicei atunci când modulele individuale sunt implementate și testate., La nivelul de testare a integrării, această testare este efectuată pentru a vă asigura că toate funcționalitățile de integrare de bază și de la capăt la capăt funcționează bine așa cum era de așteptat.poate fi integrarea a două module sau a tuturor modulelor împreună, prin urmare complexitatea testului de fum va varia în funcție de nivelul de integrare.să luăm în considerare următoarele exemple de implementare a integrării pentru această testare:

  • a implementat integrarea modulelor de rute și opriri.
  • a implementat integrarea actualizării stării sosirii și reflectă același lucru pe ecranul opriri.,
  • a implementat integrarea complet pick up până la modulele de funcționalitate de livrare.

  în această construcție, testul de fum nu numai că va verifica aceste trei implementări de bază, ci și pentru a treia implementare, câteva cazuri vor verifica și integrarea completă. Ajută foarte mult la aflarea problemelor care se introduc în integrare și a celor care au trecut neobservate de echipa de dezvoltare.

  #3) testarea sistemului

  după cum sugerează și numele, pentru nivelul sistemului, testarea fumului include teste pentru cele mai importante și utilizate frecvent fluxuri de lucru ale sistemului., Acest lucru se face numai după ce sistemul complet este gata & testat, iar această testare la nivel de sistem poate fi denumită și testare la fum înainte de testarea regresivă.înainte de a începe regresia sistemului complet, caracteristicile de bază de la capăt la capăt sunt testate ca parte a testului de fum. Suita de testare a fumului pentru sistemul complet cuprinde cazurile de testare de la capăt la capăt pe care utilizatorii finali le vor folosi foarte frecvent.acest lucru se face de obicei cu ajutorul instrumentelor de automatizare.,în prezent, proiectele urmăresc cu greu metodologia cascadă în implementarea proiectului, în mare parte toate proiectele urmează doar Agile și SCRUM. În comparație cu metoda tradițională de cascadă, testarea fumului ține cont de SCRUM și Agile.

  am lucrat timp de 4 ani în SCRUM. Și după cum știm că în SCRUM, sprinturile au o durată mai scurtă și, prin urmare, este extrem de important să facem această testare, astfel încât construcțiile eșuate să poată fi imediat raportate echipei de dezvoltare și fixate.,

  următoarele sunt unele takeaway cu privire la importanța acestei teste în SCRUM:

  • din sprint de două săptămâni, pauza este alocată QA, dar uneori se bazează la QA sunt întârziate.
  • în sprinturi, este mai bine pentru echipă ca problemele să fie raportate într-un stadiu incipient.
  • fiecare poveste are un set de criterii de acceptare, prin urmare testarea primelor 2-3 criterii de acceptare este egală cu testarea fumului din acea funcționalitate. Clienții resping livrarea în cazul în care un singur criteriu eșuează.,
  • imaginați-vă ce se va întâmpla dacă sunt 2 zile în care echipa de dezvoltare ți-a livrat construirea și doar 3 zile rămân pentru demo și întâlnești un eșec de funcționalitate de bază.
  • în medie, un sprint are povești variind de la 5-10, prin urmare, atunci când construirea este dată, este important să vă asigurați că fiecare poveste este implementată așa cum era de așteptat înainte de a accepta construirea în testare.
  • când sistemul complet urmează să fie testat și regresat, un sprint este dedicat activității., O săptămână poate puțin mai puțin pentru a testa întregul sistem, de aceea este foarte important să verificați funcționalitățile cele mai de bază înainte de a începe regresia.

  Smoke Test Vs Build Acceptance Testing

  Smoke Testing este direct legată de Build Acceptance Testing (BAT).

  în BAT, facem aceeași testare-pentru a verifica dacă construirea nu a eșuat și că sistemul funcționează bine sau nu. Uneori, se întâmplă ca atunci când este creat un build, unele probleme se introduce și atunci când este livrat, construi nu funcționează pentru QA.,

  aș spune că BAT face parte dintr-o verificare a fumului, deoarece dacă sistemul eșuează, cum puteți accepta ca QA construirea pentru testare? Nu doar funcționalitățile, sistemul în sine trebuie să funcționeze înainte ca QA să continue testarea în profunzime.

  ciclul de testare a fumului

  următoarea diagramă explică ciclul de testare a fumului.

  odată ce o construcție este implementată într-o asigurare a calității, ciclul de bază urmat este că, dacă testul de fum trece, construirea este acceptată de echipa de asigurare a calității pentru teste suplimentare, dar dacă nu reușește, construirea este respinsă până când problemele raportate sunt rezolvate.,

  ciclul de testare

  cine ar trebui să efectueze testul de fum?

  Nu întreaga echipă este implicată în acest tip de testare, pentru a evita irosirea de timp de toate QA.

  Fum de Testare este ideal efectuate de către QA lead care decide pe baza rezultatelor în ceea ce privește dacă să treacă pentru a construi echipa pentru teste suplimentare sau să-l respingă. Sau în absența plumbului, QA-urile pot efectua, de asemenea, această testare.

  uneori, atunci când proiectul este unul la scară largă, un grup de ac poate efectua, de asemenea, această testare pentru a verifica pentru orice showstoppers., Dar acest lucru nu este valabil în cazul SCRUM, deoarece SCRUM este o structură plană fără Clienți sau manageri și fiecare tester are propriile responsabilități față de poveștile lor.prin urmare, QA-urile individuale efectuează această testare pentru poveștile pe care le dețin.

  de ce ar trebui să automatizăm testele de fum?

  această testare este primul test care trebuie făcut pe o construcție lansată de echipa(echipele) de dezvoltare. Pe baza rezultatelor acestei teste, se efectuează teste suplimentare (sau construirea este respinsă).,

  cel mai bun mod de a face această testare este de a utiliza un instrument de automatizare și programa suita de fum pentru a rula atunci când este creat un nou build. S-ar putea să vă gândiți de ce ar trebui să „automatizez suita de testare a fumului”?să ne uităm la următorul caz:

  să spunem că sunteți la o săptămână distanță de la eliberarea dvs. și din totalul cazurilor de testare 500, suita dvs. de testare a fumului cuprinde 80-90. Dacă începeți să executați manual toate aceste 80-90 de cazuri de testare, imaginați-vă cât timp veți lua? Cred că 4-5 zile (minim).,dar dacă utilizați automatizarea și creați scripturi pentru a rula toate aceste 80-90 de cazuri de testare, atunci în mod ideal, acestea vor fi rulate în 2-3 ore și veți avea rezultatele cu dvs. instantaneu. Nu ți-a salvat timpul prețios și ți-a dat rezultatele despre timpul de construcție mult mai puțin?5 ani în urmă, am fost de testare o aplicație de proiecție financiară, care a luat intrări despre salariu, economii, etc., și proiectat impozitele, economiile, profiturile în funcție de regulile financiare. Odată cu aceasta, am avut personalizare pentru țările care depind de țară și regulile sale fiscale folosite pentru a schimba (în cod).,pentru acest proiect, am avut 800 de cazuri de testare și 250 au fost cazuri de testare a fumului. Cu ajutorul seleniului, am putea automatiza și obține cu ușurință rezultatele celor 250 de cazuri de testare în 3-4 ore. Nu numai că ne-a salvat timpul, dar ne-a arătat cât mai repede despre showstoppers.prin urmare, dacă nu este imposibil să automatizați, luați ajutorul automatizării pentru această testare.

  avantaje și dezavantaje

  Să aruncăm mai întâi o privire asupra avantajelor, deoarece are multe de oferit în comparație cu puținele dezavantaje.

  avantaje:

  • ușor de realizat.
  • reduce riscul.,
  • defectele sunt identificate într-un stadiu foarte timpuriu.
  • economisește eforturi, timp și bani.
  • rulează rapid dacă este automatizat.
  • cel mai puțin riscurile de integrare și probleme.
  • îmbunătățește calitatea generală a sistemului.

  dezavantaje:

  • această testare nu este egală sau un substitut pentru testarea funcțională completă.chiar și după ce testul de fum trece, puteți găsi bug-uri showstopper.,
  • acest tip de testare este cel mai potrivit dacă puteți automatiza altfel o mulțime de timp este cheltuit pe executarea manuală a cazurilor de testare, în special în proiecte la scară largă având în jur de 700-800 de cazuri de testare.testarea fumului ar trebui să se facă cu siguranță la fiecare construcție, deoarece subliniază eșecurile majore și opririle într-un stadiu foarte timpuriu. Acest lucru se aplică nu numai noilor funcționalități, ci și Integrării modulelor, rezolvării problemelor și improvizării. Este un proces foarte simplu pentru a efectua și a obține rezultatul corect.,această testare poate fi tratată ca punct de intrare pentru testarea funcțională completă a funcționalității sau a sistemului (în ansamblu). Dar înainte de aceasta, echipa QA ar trebui să fie foarte clară cu privire la ce teste trebuie făcute ca teste de fum. Această testare poate minimiza eforturile, economisi timp și de a îmbunătăți calitatea sistemului. Deține un loc foarte important în sprinturi, deoarece timpul în sprinturi este mai mic.această testare se poate face atât manual, cât și cu ajutorul instrumentelor de automatizare. Dar cel mai bun și preferat MOD este să folosiți instrumente de automatizare pentru a economisi timp.,
    

    diferența dintre testarea fumului și testarea sănătății mintale

    de cele mai multe ori ne confundăm între semnificația testării sănătății mintale și testarea fumului. În primul rând, aceste două teste sunt mod „diferite” și efectuate în diferite etape ale unui ciclu de testare.

    S. Nr.	Fum de Testare	bun-simț Testare
    1	Fum de testare mijloace pentru a verifica (de bază) că implementări făcut într-o construi sunt de lucru bine.,	bun-simț de testare înseamnă a verifica funcționalitățile nou adăugate, bug-uri etc. sunt de lucru bine.
    2	aceasta este prima testare la construirea inițială.	făcut atunci când construirea este relativ stabilă.
    3	făcut pe fiecare construi.	făcut pe stabil construiește regresie post.,

    în Urma este o reprezentare grafic de diferențele lor:

    FUM de TESTARE

    • Această testare are originea în hardware-ul de testare practică de a porni o nouă piesă de hardware pentru prima dată și având în vedere că este un succes dacă nu se prinde foc și fum. În industria software, această testare este o abordare superficială și largă, prin care toate domeniile aplicației, fără a intra prea adânc, sunt testate.,
    • un test de fum este scriptat, fie folosind un set scris de teste sau un test automat
    • un test de fum este proiectat pentru a atinge fiecare parte a aplicației într-un mod sumar. Este superficial și larg.
    • această testare este efectuată pentru a se asigura dacă funcțiile cele mai importante ale unui program sunt de lucru, dar nu deranjează cu detalii mai fine. (Cum ar fi verificarea construirii).
    • această testare este un control normal de sănătate la construirea unei aplicații înainte de ao lua pentru a testa în profunzime.,

    testarea sănătății

    • un test de sănătate este un test de regresie îngust care se concentrează pe una sau câteva domenii de funcționalitate. Testarea sănătății este de obicei îngustă și profundă.
    • acest test este de obicei nescris.
    • acest test este utilizat pentru a determina că o mică secțiune a aplicației este încă de lucru după o modificare minoră.
    • această testare este de testare sumară, se efectuează ori de câte ori o testare sumară este suficientă pentru a dovedi că aplicația funcționează în conformitate cu specificațiile. Acest nivel de testare este un subset de testare de regresie.,
    • acest lucru este pentru a verifica dacă cerințele sunt îndeplinite sau nu, verificând mai întâi toate caracteristicile.