Testele sanitare și de fum încep imediat după lansarea următoarei versiuni a proiectului. Pentru mulți tineri testeri, acest proces pare a fi un haos absolut. Te-ai recunoscut? Atunci acest articol este pentru tine. Ne vom uita acum la definițiile testelor de fum și sanitare și vom arăta diferența dintre cele două folosind exemple ușor de înțeles.

Testarea fumului:

Testarea fumului se face pentru a se asigura că construcția rezultată este potrivită pentru testare. Se mai numește și un control zero-day.

Acest tip de testare vă va împiedica să pierdeți timpul. Este logic că testarea întregii aplicații nu are sens dacă există probleme cu caracteristicile cheie și erorile critice nu sunt remediate.

Teste sanitare:

Testele sanitare sunt efectuate în etapa de lansare pentru a verifica funcționalitatea principală a aplicației. De obicei nu merg mai departe. Această testare este uneori denumită o versiune prescurtată a testării de regresie.
Când termenul limită de lansare este strâns, este aproape imposibil să se efectueze teste de regresie riguroase. În acest caz, testarea sanitară face o treabă excelentă, care verifică funcționarea principalelor funcții ale aplicației.

Un exemplu pentru a înțelege mai bine diferența dintre testarea fumului și testarea sanitară:

Există un proiect pentru care este planificată o lansare inițială. Echipa de dezvoltare lansează versiunea pentru testare, echipa de testare începe să lucreze. Prima testare este testarea fitness-ului. Trebuie să aflați dacă puteți lucra cu această versiune sau nu. Acesta este testul de fum. Dacă echipa dă aprobarea pentru continuarea lucrărilor cu construcția, aceasta este trimisă la etape mai profunde de testare. Să ne imaginăm că versiunea are trei module: „Autentificare”, „Admin” și „Angajat”. Echipa de testare verifică performanța doar a funcțiilor de bază ale fiecăruia dintre module, fără a intra în profunzime în verificarea detaliilor. Acestea vor fi teste sanitare.

Încă câteva diferențe între testarea fumului și testarea sanitară:

  • Testarea fumului este efectuată atât de dezvoltatori, cât și de testeri;
  • Testele sanitare sunt efectuate numai de testeri.
  • Testarea fumului acoperă toate funcționalitățile principale ale aplicației de la început până la sfârșit;
  • Testarea sanitară testează doar o componentă specifică a unei aplicații.
  • Testarea fumului este supusă atât unor construcții stabile, cât și instabile;
  • O construcție relativ stabilă este supusă unor teste sanitare.

Kirill Flyagin, designer de jocuri, responsabil QA

Să facem o analogie de vară cu aceste tipuri de testare. Să presupunem că vrei să cumperi un pepene verde. Testarea fumului este atunci când îl verificați vizual, priviți benzile, stoarceți, ciocniți, ratați. Sunt maeștri care reușesc să cumpere astfel o boabă cu adevărat gustoasă. La testarea sanitară, decupezi o piramidă în vârf și îi verifici culoarea (ca una dintre componente) fără să știi deloc dacă tot pepenele este la fel. Dar ești complet sigur de partea tăiată.

  • Test de fum pe Jargon File

Fundația Wikimedia. 2010.

Vedeți ce este „Testul de fum” în alte dicționare:

    test de fum- substantiv O metodă de testare a scurgerilor în țevile de scurgere sau coșurile de fum prin introducerea de fum dens, adesea prin utilizarea unei bombe de fum Intrare principală: fum... Dicționar englez util

    test de fum- Test efectuat pentru a determina caracterul complet al arderii... Dicţionar de termeni auto

    test de fum- 1.substantiv a) Un test pentru scurgeri care implică suflarea fumului într-un tub sau conductă. b) Un test preliminar pe un echipament electronic nou construit, constând pur și simplu în aplicarea energiei electrice, pentru a se asigura că nu există cablaje flagrante…… Wikționar

    Testarea fumului- este un termen folosit în instalații sanitare, reparații de suflat, electronice, dezvoltare de software de calculator și industria divertismentului. Se referă la primul test efectuat după reparații sau prima asamblare pentru a oferi o anumită asigurare că sistemul testat va…… Wikipedia

    Testarea fumului- bzw. Rauchtest ist ein Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten ... ... Deutsch Wikipedia

    Fum- este colecția de particule și gaze solide și lichide în aer [SFPE Handbook of Fire Protection Engineering] emise atunci când un material este supus ... ... Wikipedia

    Suită de teste- În dezvoltarea de software, o suită de teste, mai puțin cunoscută ca suită de validare, este o colecție de cazuri de testare care sunt destinate să fie utilizate pentru a testa un program software pentru a arăta că are un anumit set de comportamente. O suită de teste adesea... Wikipedia

    Bombă de fum- O bombă fumigenă este un artificiu conceput pentru a produce fum la aprindere. Deși există dispozitive care generează fum care sunt aruncate din avioane, termenul de bombă fumigen este folosit pentru a descrie cele trei tipuri de dispozitive: # O minge de fum este o cireș goală, ... ... Wikipedia

Dacă doriți să creați un simplu program de calculator, care constă dintr-un singur fișier, trebuie doar să colectați și să legați tot codul pe care îl scrieți în acest fișier. Pe cel mai comun proiect pe care îl face o echipă de dezvoltare, există sute, chiar mii de fișiere. Acest lucru „contribuie” la faptul că procesul de creare a unui program executabil devine mai complex și consumator de timp: trebuie să „asamblezi” programul din diverse componente.

Practica folosită, de exemplu, în Microsoft și în alte companii de dezvoltare de software, constă în asamblarea (construirea) zilnică a programului, care este completată de testarea de fum. În fiecare zi, după ce fiecare fișier este asamblat (reconstruit, construit), legat (legat) și îmbinat într-un program executabil, programul în sine este supus unui set destul de simplu de teste, al căror scop este să vadă dacă programul " fumează” în timpul lucrului. Aceste teste se numesc smoke (din engleza smoke - smoke). De cele mai multe ori, acest proces este destul de bine automatizat (sau ar trebui să fie).

BENEFICII. Acest proces simplu oferă mai multe beneficii semnificative.

Minimizarea riscului în timpul integrării

Unul dintre cele mai semnificative riscuri cu care se confruntă echipa de dezvoltare este că dezvoltatorii înșiși lucrează cu codul separat, independent unul de celălalt, drept urmare un program complex nu funcționează așa cum era de așteptat la construirea codului generat. În funcție de momentul în care a fost găsită incompatibilitatea în proiect, depanarea programului poate dura mai mult decât în ​​cazul integrării anterioare, mai ales dacă interfața programului este schimbată sau după implementarea unor modificări majore în părțile principale ale programului.

Asamblarea și derularea zilnică a testelor de fum face posibilă reducerea riscului de erori de integrare, răspunsul la acestea în timp util și prevenirea acumulării lor.

Reducerea riscului de produs software de proastă calitate

Calitatea slabă a produsului depinde direct de eșecurile și problemele din timpul integrării. Executarea unui set minim de teste de fum în fiecare zi împiedică erorile și problemele să devină avantaje asupra proiectului. Dacă ați adus proiectul într-o stare stabilă o dată, acesta va rămâne întotdeauna stabil. Făcând acest lucru, nu veți permite niciodată ca calitatea să fie degradată până la punctul în care apar erori.

Ajutor la diagnosticarea erorilor

Dacă într-o zi produsul nu s-a asamblat (asamblat cu erori), atunci cu ajutorul asamblarii zilnice și rulând un set de teste de fum, este mult mai ușor să găsiți cauza problemei. Un produs care funcționează ieri și nu funcționează astăzi este un indiciu clar că ceva nu a mers prost între cele două versiuni.

Îmbunătățirea moralului

Dacă un produs funcționează și în fiecare zi capătă din ce în ce mai multe calități și funcții noi, moralul dezvoltatorilor, teoretic, ar trebui să crească și nu contează deloc ce anume ar trebui să facă acest produs. Este întotdeauna plăcut pentru dezvoltator să-și urmărească „crearea”, chiar dacă produsul afișează un dreptunghi :)

Folosind teste zilnice de construcție și de fum

Iată câteva detalii ale acestui principiu.

Crearea aplicației zilnic

O parte fundamentală a asamblarii zilnice este asamblarea ultimei piese. Jim McCarthy, în Dynamics of Software Development (Microsoft Press, 1995), a numit construirea zilnică a proiectului bataia lui. Dacă nu există bătăi ale inimii, nu există nici un proiect, este mort. Mai puțin figurat, clădirea zilnică a fost descrisă de Michael Cusumano și Richard W. Selby drept pulsul de sincronizare al proiectului (Microsoft Secrets, The Free Press, 1995). Fiecare dezvoltator scrie codul în felul său și el, codul, poate depăși cadrul general acceptat pentru proiect - acest lucru este normal, dar de fiecare dată când se aplică pulsul de ceas, codul revine la standard. Insistând să dezvoltați cu un puls de sincronizare tot timpul, veți menține proiectul complet desincronizat.

În unele companii, se obișnuiește să colectați un proiect nu în fiecare zi, ci o dată pe săptămână. Acest sistem este eronat deoarece în cazul unei „defecțiuni” a proiectului săptămâna aceasta, ar putea dura încă câteva săptămâni înainte de următoarea construcție reușită. În acest caz, compania pierde toate beneficiile sistemului zilnic de construire a proiectelor.

Se verifică o versiune eșuată

În cazul unei construiri zilnice a proiectului, se presupune că proiectul ar trebui să funcționeze. Cu toate acestea, dacă proiectul nu funcționează, repararea lui devine o sarcină cu prioritate 1.

Fiecare proiect are propriul său standard și un semn a ceea ce se numește „eșecul de asamblare”. Acest standard ar trebui să specifice un nivel de calitate care este suficient pentru a urmări defectele minore și pentru a nu trece cu vederea defectele care „blochează” proiectul.

O construcție bună este una care cel puțin:

  • toate fișierele, bibliotecile și celelalte componente sunt compilate cu succes;
  • link-urile către toate fișierele, bibliotecile și alte componente sunt valide;
  • nu conține niciun sistem stabil, excluzând posibilitatea funcționării corecte a programului aplicației, blocând erorile;
  • toate testele de fum trec.

Teste zilnice de fum

Testele de fum ar trebui efectuate pe întregul proiect de la început până la sfârșit. Ele nu trebuie să fie exhaustive și cuprinzătoare, dar ar trebui să includă o verificare a tuturor funcțiilor majore. Testarea fumului ar trebui să fie suficient de adâncă, astfel încât, dacă reușește, să fie posibil să se numească proiectul stabil și să-l numească astfel încât să poată fi supus unor teste mai profunde.

Semnificația construcției zilnice se pierde fără testarea fumului. Acest proces protejează calitatea produsului și nu permite nicio problemă de integrare. Fără aceasta, procesul zilnic de construire este o pierdere de timp, al cărui scop este verificarea compilației.

Testarea fumului ar trebui să evolueze în conformitate cu proiectul. La început, testele de fum vor verifica ceva simplu, cum ar fi dacă proiectul poate emite un mesaj „Hello, World!”. Pe măsură ce sistemul evoluează, testele de fum devin mai aprofundate. Timpul petrecut la primele teste de fum este calculat în câteva secunde, dar pe măsură ce sistemul crește, la fel crește și timpul necesar pentru testarea fumului. La sfârșitul unui proiect, testarea fumului poate dura ore întregi.

Definirea unui grup de asamblare

În majoritatea proiectelor, există o persoană specifică responsabilă de verificarea construcției zilnice a sistemului și de efectuarea testelor de fum. Această muncă face parte din îndatoririle acestui angajat, dar la proiectele mari pot exista mai mulți astfel de angajați și o astfel de muncă este responsabilitatea lor principală. De exemplu, erau patru oameni în echipa de construcție pentru un proiect Windows NT 3.0 (Pascal Zachary, Showstopper!, The Free Press, 1994).

Adăugați o revizuire la asamblare numai dacă are sens

În mod obișnuit, dezvoltatorii individuali scriu codul suficient de încet încât să poată fi adăugate în sistem modificări semnificative zilnic. Ei trebuie să lucreze la majoritatea codului și să îl integreze în sistem la fiecare câteva zile.

Introduceți un sistem de penalități pentru întreruperea lansării următoarei build (lansarea unei build care nu funcționează).

Majoritatea proiectelor au un sistem de penalități pentru întreruperea eliberării următoarei adunări. La începutul unui proiect, merită să precizăm că păstrarea unui proiect de lucru este cea mai mare prioritate. Eșecul lansării următoarei versiuni poate fi o excepție, dar nu o regulă. Insistați ca dezvoltatorii să lase totul până când sistemul funcționează din nou. În cazul unor eșecuri frecvente de construcție (lansarea unei versiuni care nu funcționează), poate fi dificil să readuceți proiectul pe drumul cel bun.

Amenzile minore evidențiază grad înalt necesitatea de a monitoriza calitatea construcției sistemului. În unele proiecte, dezvoltatorii care sunt responsabili pentru prăbușirea ansamblului primesc acadele pentru eliberarea unui ansamblu rupt. Un semn corespunzător atârnă pe ușa unui astfel de birou de dezvoltator până când acesta fixează montajul (cu condiția ca dezvoltatorii să aibă birouri separate :)). Pe alte proiecte, dezvoltatorii vinovați trebuie să poarte coarne artificiale de capră sau să contribuie cu o anumită sumă la „fondul de moral” (exemple sunt luate din istoria companiilor reale).

Dar pe unele proiecte se impun sancțiuni mai grave. De exemplu, dezvoltatorii Microsoft din proiecte cu prioritate înaltă (Windows NT, Windows 95, Excel) purtau pagere și, dacă se găsea un cec, trebuiau să se prezinte la serviciu. Chiar dacă a fost descoperită o defecțiune sau o eroare la ora 3 dimineața.

Asamblați sistemul și „fumați” chiar și sub presiune

Când presiunea programului de lansare al unui proiect crește, munca de verificare a construirii sistemului zilnic poate fi o pierdere de timp. Cu toate acestea, nu este. În situații stresante, dezvoltatorii fac adesea greșeli. Ei simt o asemenea presiune pentru a elibera implementări, care în condiții normale pur și simplu nu există. Își verifică codul cu teste unitare cu mult mai puțin atent decât o fac de obicei. În astfel de situații, codul tinde spre o stare de entropie mult mai rapid decât în ​​situații mai puțin stresante.

Cine beneficiază de pe urma acestui proces? Unii dezvoltatori protestează împotriva versiunilor zilnice, justificându-și protestele ca fiind impracticabile și consumatoare de timp. Dar toate sistemele complexe din ultima vreme au fost supuse asamblarilor zilnice si testelor de fum. La momentul lansării sale, Microsoft Windows NT 3.0 conținea 5,6 milioane de linii în 40.000 de fișiere. Construirea completă a durat 19 ore și a rulat pe mai multe computere. În ciuda acestui fapt, dezvoltatorii au reușit să asambleze sistemul zilnic. În calitate de echipă profesionistă, echipa de dezvoltare NT își datorează mare parte din succesul construcției zilnice. Dezvoltatorii care lucrează la proiecte mai puțin complexe și, prin urmare, nu profită de procesul zilnic de construire ar trebui să ia în considerare o explicație rezonabilă pentru ei înșiși.

Bună, Habr! Odată, la atelierul nostru intern, liderul meu - șeful departamentului de testare - și-a început discursul cu cuvintele „testarea nu este necesară”. Toată lumea din hol era tăcută, unii chiar au încercat să cadă de pe scaune. Și-a continuat gândul: fără testare, este foarte posibil să se creeze un proiect complex și costisitor. Și cel mai probabil va funcționa. Dar imaginați-vă cât de mult mai încrezător vă veți simți știind că produsul funcționează așa cum ar trebui.

Badoo lansează destul de des. De exemplu, partea de server, împreună cu web-ul desktop, este lansată de două ori pe zi. Așa că știm direct că testarea complexă și lentă este o piatră de poticnire pentru dezvoltare. Testarea rapidă este fericire. Așadar, astăzi voi vorbi despre cum se organizează testarea fumului la Badoo.

Ce este testarea fumului

Acest termen a fost folosit pentru prima dată de producătorii de sobe, care, după ce au asamblat soba, au închis toate dopurile, au inundat-o și au urmărit ca fumul să vină numai din locurile destinate. Wikipedia

În aplicația sa inițială, testarea fumului are scopul de a testa cele mai simple și mai evidente cazuri, fără de care orice alt tip de testare ar fi inutil inutil.

Să aruncăm o privire la un exemplu simplu. Preproducția aplicației noastre se află la bryak.com (orice coincidențe cu site-uri reale sunt accidentale). Am pregătit și am încărcat o nouă versiune acolo pentru testare. Ce ar trebui să verifici mai întâi? Aș începe prin a verifica dacă aplicația încă se deschide. Dacă serverul web răspunde „200”, atunci totul este în regulă și puteți începe să testați funcționalitatea.

Cum se automatizează o astfel de verificare? Practic, puteți scrie un test funcțional care va deschide browserul, va deschide pagina dorită și vă va asigura că se redă așa cum ar trebui. Cu toate acestea, această soluție are o serie de dezavantaje. În primul rând, este lung: procesul de lansare a browserului va dura mai mult decât verificarea în sine. În al doilea rând, necesită întreținerea unei infrastructuri suplimentare: de dragul acestora test simplu trebuie să găzduim undeva un server cu browsere. Concluzie: trebuie să rezolvăm problema altfel.

Primul nostru test de fum

La Badoo, partea de server este scrisă mai ales în PHP. Pe el sunt scrise teste unitare, din motive evidente. Deci avem deja PHPUnit. Pentru a nu produce tehnologii inutil, am decis să scriem teste de fum tot în PHP. Pe lângă PHPUnit, avem nevoie de o bibliotecă URL client (libcurl) și de o extensie PHP pentru a lucra cu ea - cURL.

Practic, testele fac doar cererile de care avem nevoie către server și verifică răspunsurile. Totul este legat de metoda getCurlResponse () și de mai multe tipuri de afirmații.

Metoda în sine arată cam așa:

Funcția publică getCurlResponse ($ url, array $ params = ['cookies' =>, 'post_data' =>, 'headers' =>, 'user_agent' =>, 'proxy' =>,], $ follow_location = true, $ wait_response = „200 OK”) ($ ch = curl_init (); curl_setopt ($ ch, CURLOPT_URL, $ url); curl_setopt ($ ch, CURLOPT_HEADER, 1); curl_setopt ($ ch, CURLOPT_RETURNTRANSFER, 1 $ params" ]) && $ params ['cookies']) ($ cookie_line = $ this-> prepareCookiesDataByArray ($ params ['cookies']); curl_setopt ($ ch, CURLOPT_COOKIE, $ cookie_line);) if ( isset ($ params [' headers']) && $ params ['headers']) (curl_setopt ($ ch, CURLOPT_HTTPHEADER, $ params ['headers']);) if (isset ($ params ['post_data']) && $ params ['post_data' ]) ($ post_line = $ this-> preparePostDataByArray ($ params ['post_data']); curl_setopt ($ ch, CURLOPT_POST, 1); curl_setopt ($ ch, CURLOPT_POSTFIELDS, $ post_line);) ($ follow_location) (curl_setopt ( $ ch, CURLOPT_FOLLOWLOCATION, 1);) if (isset ($ params ['proxy']) && $ params ['proxy']) (curl_setopt ($ c h, CURLOPT_PROXY, $ params [‘proxy’]); ) if (isset ($ params ['user_agent']) && $ params ['user_agent']) ($ user_agent = $ params ['user_agent'];) else ($ user_agent = USER_AGENT_DEFAULT;) curl_setopt ($ ch, CURLOPT_USERAGENT, $ user_agent); curl_setopt ($ ch, CURLOPT_AUTOREFERER, 1); $ răspuns = curl_exec ($ ch); $ this-> logActionToDB ($ url, $ user_agent, $ params); if ($ follow_location) ($ this-> assertTrue ((bool) $ răspuns, „S-a primit răspuns gol. Curl error:”. curl_error ($ ch). „, errno:”. curl_errno ($ ch)); $ this -> assertServerResponseCode ($ răspuns, $ așteptat_răspuns);) curl_close ($ ch); returnează răspunsul $; )
Metoda în sine este capabilă să returneze un răspuns server la o anumită adresă URL. Acceptă parametri precum cookie-uri, anteturi, agent de utilizator și alte date necesare pentru a forma o solicitare ca intrare. Când se primește un răspuns de la server, metoda verifică dacă codul de răspuns se potrivește cu cel așteptat. Dacă nu este, testul se blochează cu o eroare de raportare. Acest lucru se face pentru a facilita determinarea cauzei căderii. Dacă testul eșuează pe o anumită afirmație, spunându-ne că un element lipsește pe pagină, eroarea va fi mai puțin informativă decât mesajul că codul de răspuns este, de exemplu, „404” în loc de „200” așteptat.

Când cererea este trimisă și răspunsul este primit, înregistrăm cererea pentru ca pe viitor, dacă este necesar, să fie ușor de reprodus lanțul de evenimente dacă testul eșuează sau se întrerupe. Despre asta voi vorbi mai jos.

Cel mai simplu test arată cam așa:

Funcția publică testStartPage () ($ url = 'bryak.com'; $ răspuns = $ this-> getCurlResponse ($ url); $ this-> assertHTMLPresent ("
Acest test durează mai puțin de o secundă. În acest timp, am verificat că pagina de start răspunde cu „200” și că are un element body. Cu același succes, putem testa orice număr de elemente de pe pagină, durata testului nu se va schimba semnificativ.

Avantajele unor astfel de teste:

  • viteza - testul poate fi efectuat ori de cate ori este nevoie. De exemplu, pentru fiecare schimbare de cod;
  • nu necesită software și hardware special pentru lucru;
  • sunt ușor de scris și întreținut;
  • sunt stabili.
Referitor la ultimul punct. Adică - nu mai puțin stabil decât proiectul în sine.

Autorizare

Să presupunem că au trecut trei zile de când am scris primul nostru test de fum. Desigur, în acest timp am acoperit cu teste toate paginile neautorizate pe care le-am găsit. Am stat puțin, ne-am bucurat, dar apoi am realizat că cel mai important lucru din proiectul nostru se află în spatele autorizației. Cum ai putea sa testezi si asta?

Cea mai simplă opțiune este un cookie de autorizare. Dacă îl adăugăm la cerere, atunci serverul ne „recunoaște”. Un astfel de cookie poate fi codificat într-un test dacă durata sa de viață este destul de lungă, sau poate fi obținut automat prin trimiterea de solicitări către pagina de autorizare. Să aruncăm o privire mai atentă la a doua opțiune.

Suntem interesați de formularul în care trebuie să introduceți numele de utilizator și parola.

Deschideți această pagină în orice browser și deschideți inspectorul. Introduceți datele utilizatorului și trimiteți formularul.

La inspector a apărut o cerere, pe care trebuie să o simulăm în test. Puteți vedea ce date, pe lângă cele evidente (login și parolă), sunt trimise către server. Este diferit pentru fiecare proiect: poate fi un token de la distanță, datele oricăror cookie-uri primite mai devreme, un agent de utilizator și așa mai departe. Fiecare dintre acești parametri va trebui obținut în test înainte de a genera o cerere de autorizare.

În instrumentele de dezvoltare ale oricărui browser, puteți copia solicitarea selectând copiere ca cURL. În această formă, comanda poate fi introdusă în consolă și vizualizată acolo. De asemenea, puteți încerca acolo prin modificarea sau adăugarea de parametri.

Ca răspuns la o astfel de solicitare, serverul ne va returna cookie-uri, pe care le vom adăuga la solicitările ulterioare pentru a testa paginile autorizate.

Deoarece autorizarea este un proces destul de lung, vă sugerez să obțineți cookie-ul de autorizare o singură dată pentru fiecare utilizator și să îl salvați undeva. De exemplu, stocăm astfel de cookie-uri într-o matrice. Cheia este autentificarea utilizatorului, iar valoarea este informații despre acesta. Dacă nu există încă o cheie pentru următorul utilizator, conectați-vă. Dacă există, facem imediat cererea de interes pentru noi.

Funcția publică testAuthPage () ($ url = ‘bryak.com’; $ cookie-uri = $ this-> getAuthCookies (‘ [email protected]',' 12345 '); $ răspuns = $ this-> getCurlResponse ($ url, [‘cookies’ => $ cookie]); $ this-> assertHTMLPresent (" ", $ răspuns," Eroare: testul nu poate găsi elementul body pe pagină. ");)
După cum putem vedea, a fost adăugată o metodă care primește un cookie de autorizare și pur și simplu îl adaugă la o cerere ulterioară. Metoda în sine este destul de simplu de implementat:

Funcția publică getAuthCookies ($ email, $ parola) (// verifica dacă cookie-ul a fost deja primit If (array_key_exist ($ email, self :: $known_cookies)) (return self :: $known_cookies [$ email];) $ url = self :: DOMAIN_STAGING. '/ auth_page_adds'; $ post_data = ['email' => $ e-mail, 'parolă' => $ parolă]; $ răspuns = $ this-> getCurlResponse ($ url, ['post_data' => $ post_data]); $ cookie-uri = $ this-> parseCookiesFromResponse ($ răspuns); // salvează cookie-ul pentru utilizare ulterioară self :: $known_cookies [$ email] = $ cookie; returnează $ cookie-uri;)
Metoda verifică mai întâi dacă există un cookie de autorizare primit anterior pentru e-mailul dat (în cazul dvs. poate fi o autentificare sau altceva). Dacă există, îl returnează. Dacă nu, face o cerere pentru o pagină de autorizare (de exemplu, bryak.com/auth_page_adds) cu parametrii necesari: e-mail utilizator și parolă. Ca răspuns la această solicitare, serverul trimite anteturi, printre care se numără cookie-uri de interes pentru noi. Arata cam asa:

HTTP / 1.1 200 OK Server: nginx Tip de conținut: text / html; set de caractere = utf-8 Codare de transfer: fragmentat Conexiune: păstrare în viață Set-Cookie: nume = valoare; expiră = Miercuri, 30-Nov-2016 10:06:24 GMT; Max-Age = -86400; cale = /; domeniu = bryak.com
Din aceste anteturi, folosind o expresie regulată simplă, trebuie să obținem numele cookie-ului și valoarea acestuia (în exemplul nostru, acesta este nume = valoare). Avem o metodă care analizează răspunsul arată astfel:

$ this-> assertTrue ((bool) preg_match_all ("/ Set-Cookie: (([^ =] +) = ([^;] +);. *) \ n /", $ răspuns, $ mch1), " Nu se pot obține „cookie-uri” de la răspunsul serverului. Răspuns: „. $ Response);
După ce cookie-urile sunt primite, le putem adăuga în siguranță la orice solicitare de autorizare.

Analizarea testelor eșuate

Din cele de mai sus rezultă că un astfel de test este un set de solicitări către server. Facem o cerere, manipulăm răspunsul, facem următoarea cerere și așa mai departe. Un gând mi se strecoară în minte: dacă un astfel de test eșuează la a zecea cerere, poate fi dificil să-mi dau seama de motivul eșecului său. Cum să-ți simplific viața?

În primul rând, aș dori să vă sfătuiesc să vă atomizați cât mai mult testele. Nu ar trebui să verificați 50 de cazuri diferite într-un singur test. Cu cât testul este mai simplu, cu atât va fi mai ușor cu acesta în viitor.

De asemenea, este util să colectați artefacte. Când testul nostru eșuează, salvează ultimul răspuns de server într-un fișier HTML și îl încarcă în magazinul de artefacte, unde acest fișier poate fi deschis din browser specificând numele testului.

De exemplu, testul nostru a eșuat din cauza faptului că nu a putut găsi o bucată de HTML pe pagină:

Legătură
Mergem la colecționarul nostru și deschidem pagina corespunzătoare:

Puteți lucra cu această pagină în același mod ca și cu orice altă pagină HTML din browser. Puteți folosi un localizator CSS pentru a încerca să găsiți elementul lipsă și, dacă într-adevăr nu este acolo, să decideți că fie s-a schimbat, fie este pierdut. Poate că am găsit o eroare! Dacă elementul este la locul său, poate că am făcut o greșeală undeva în test, trebuie să ne uităm atent în această direcție.

Înregistrarea vă ajută să faceți viața și mai ușoară. Încercăm să înregistrăm toate solicitările făcute de testul eșuat, astfel încât să poată fi repetate cu ușurință. În primul rând, vă permite să efectuați rapid un set de acțiuni similare cu mâinile pentru a reproduce o eroare și, în al doilea rând, să identificați testele care eșuează frecvent, dacă avem.

Pe lângă faptul că ajută la analiza erorilor, jurnalele descrise mai sus ne ajută să construim o listă de pagini autorizate și neautorizate pe care le-am testat. Privind-o, este ușor să găsiți și să umpleți golurile.

Nu în ultimul rând, sfatul meu este ca testele să fie cât mai ușor de utilizat. Cu cât este mai ușor să le rulezi, cu atât vor fi folosite mai des. Cu cât este mai clar și mai concis raportul toamnei, cu atât va fi studiat mai atent. Cu cât arhitectura este mai simplă, cu atât vor fi scrise mai multe teste și cu atât va dura mai puțin timp pentru a scrie unul nou.

Dacă vi se pare că testele sunt incomod de utilizat, cel mai probabil nu vi se pare. Acest lucru trebuie rezolvat cât mai curând posibil. În caz contrar, riscați la un moment dat să începeți să acordați mai puțină atenție acestor teste, iar acest lucru poate duce deja la ratarea unei greșeli pentru producție.

În cuvinte, gândul pare evident, sunt de acord. Dar, de fapt, toți avem multe pentru care să ne străduim. Așa că simplificați și optimizați-vă creațiile și trăiți fără erori. :)

Rezultate

Pe acest moment noi * deschidem Timcity * wow, deja 605 teste. Toate testele, dacă nu rulează în paralel, trec în puțin mai puțin de patru minute.

În acest timp, ne asigurăm că:

  • proiectul nostru se deschide în toate limbile (dintre care avem peste 40 în producție);
  • pentru principalele țări, formele corecte de plată sunt afișate cu setul corespunzător de metode de plată;
  • Principalele solicitări către API funcționează corect;
  • Pagina de destinație pentru redirecționări funcționează corect (inclusiv către un site mobil cu un agent utilizator adecvat);
  • toate proiectele interne sunt afișate corect.
Testele pe Selenium WebDriver pentru toate acestea ar necesita de multe ori mai mult timp și resurse. Adaugă etichete

După efectuarea modificărilor necesare, cum ar fi remedierea unui bug/defect, software-ul trebuie re-testat pentru a confirma că problema a fost de fapt rezolvată. Următoarele sunt tipurile de testare care trebuie efectuate după instalare software, pentru a confirma funcționalitatea aplicației sau corectitudinea corectării defectelor implementate:

- Testarea fumului(testarea fumului)

- Testare de regresie(Test de regresie)

- Testarea construcției(Test de verificare a construirii)

- Testarea sanitară sau verificarea consistenței / funcționalității(Test de sănătate)

Concept testarea fumului provenit din mediul ingineresc. Când au fost puse în funcțiune echipamente noi („hardware”), s-a considerat că testarea a fost reușită dacă nu ieșea fum din instalație. În domeniul testării software-ului, se urmărește verificarea superficială a tuturor modulelor aplicației pentru funcționalitate și prezența defectelor critice și de blocare rapid găsite. Pe baza rezultatelor testelor de fum, se concluzionează dacă este acceptat sau nu. versiunea instalată software pentru testare, operare sau livrare către client. Pentru a facilita munca, a economisi timp și resurse umane, se recomandă implementarea automatizării cazului de testare pentru testarea fumului.

Testare de regresie Este un tip de testare care vizează verificarea modificărilor efectuate în aplicație sau mediu inconjurator(remedierea unui defect, fuzionarea codului, migrarea către un alt sistem de operare, bază de date, server web sau server de aplicații), pentru a confirma că funcționalitatea preexistentă funcționează ca înainte (vezi și Testare sanitară sau Consistență / Verificare de sănătate). Regresia poate fi după cum urmează funcţional, deci si nefuncțional teste.

De regulă, cazurile de testare scrise în etapele incipiente de dezvoltare și testare sunt folosite pentru testarea regresiei. Acest lucru asigură că modificările aduse noii versiuni a aplicației nu afectează funcționalitatea existentă. Se recomandă automatizarea testelor de regresie pentru a accelera procesul de testare ulterior și pentru a detecta defectele în stadiile incipiente ale dezvoltării software.

Termenul „Test de regresie” în sine, în funcție de contextul de utilizare, poate avea semnificații diferite. Sam Kaner, de exemplu, a descris-o 3 tipuri principale testare de regresie:

- Regresia erorilor- o încercare de a demonstra că o eroare remediată nu este de fapt remediată.

- Regresia bug-urilor vechi- o încercare de a demonstra că o modificare recentă a codului sau a datelor a rupt corectarea erorilor vechi, de ex. bug-urile vechi au început să se joace din nou.


- Regresia efect secundar- o încercare de a demonstra că o modificare recentă a codului sau a datelor a spart alte părți ale aplicației în curs de dezvoltare.

Testare de sănătate sau testare de sănătate - este o testare foarte țintită, suficientă pentru a dovedi că o anumită caracteristică funcționează așa cum este menționat în specificație. Este un subset al testelor de regresie. Este folosit pentru a determina starea de sănătate a unei anumite părți a aplicației după modificările aduse acesteia sau mediului. De obicei, se face manual.

Diferența dintre testarea sanitară și testarea fumului. Unele surse cred în mod eronat că testarea sanitară și testarea fumului sunt același lucru. Credem că aceste tipuri de testare au „vectori de mișcare”, direcții în direcții diferite. Spre deosebire de testarea fumului, testarea Sanity este direcționată adânc în funcția testată, în timp ce testarea fumului este direcționată în larg pentru a acoperi cât mai multă funcționalitate în cel mai scurt timp posibil.

Testarea construcției(Testul de verificare a build-ului) este o testare care urmărește să determine dacă versiunea lansată îndeplinește criteriile de calitate pentru începerea testării. Conform scopurilor sale, este analog cu Smoke Testing, care vizează acceptarea unei noi versiuni pentru testare sau operare ulterioară. Poate pătrunde mai adânc, în funcție de cerințele de calitate ale versiunii lansate.

Testarea instalării - care vizează verificarea instalării și configurării cu succes, precum și actualizarea sau eliminarea software-ului. V în prezent cea mai comună instalare de software folosind instalatori(programele speciale care necesită, de asemenea, testarea adecvată). În condiții reale, este posibil ca instalatorii să nu existe. În acest caz, va trebui să instalați independent software-ul folosind documentația sub formă de instrucțiuni sau fișiere readme, descriind pas cu pas toți pașii și verificările necesare. În sistemele distribuite, în care aplicația este implementată într-un mediu deja de lucru, un set simplu de instrucțiuni poate să nu fie suficient. Pentru aceasta, de multe ori, este scris un Plan de implementare, care include nu numai pași de instalare a aplicației, ci și pași de derulare versiunea anterioara, în caz de eșec. Planul de instalare în sine trebuie să treacă și printr-o procedură de testare pentru a evita problemele atunci când este pus în funcțiune reală. Acest lucru este valabil mai ales dacă instalarea este efectuată pe sisteme în care fiecare minut de nefuncționare reprezintă o pierdere a reputației și o sumă mare de fonduri, de exemplu: bănci, companii financiare sau chiar rețele de bannere. Prin urmare, testarea instalării poate fi numită una dintre cele mai importante sarcini în asigurarea calității software-ului.

Este o abordare atât de integrată cu scrierea planurilor, verificarea pas cu pas a instalării și rollback-ul instalării, care poate fi numită pe bună dreptate testarea instalării sau Testarea instalării.