Tipuri de testare (tipuri de teste)

Tipuri de testare (Tipuri de testare)

În primul rând, este logic să se constate că mulți oameni se referă la lucruri diferite, în diferite moduri, voi descrie termenii pe care mă folosesc și aud cel mai des atunci când se ocupă cu colegii, bine, sau am găsit pe internet.

teste unitare. Sarcina lor - pentru a testa logica singur modul în izolare completă - atât din mediul înconjurător și de celelalte module. Nu trebuie să fie o singură clasă, poate fi aglomerarea lor mică - de exemplu, în cazul unei clase principale și mai multe clase auxiliare-pachet privat.
Pentru a separa modulul de testare (UST, sistem testat) de la alte module (DOC, dependente de la clasă) și de mediul extern, de obicei, vin în ajutorul mock cadre, care inlocuiesc orice altceva pe un manechin fictiv (lista bibliotecă poate fi găsit la partea de jos). De exemplu, dacă avem un interpretor pagini HTML, nu avem nevoie de el să urce pe un site reale, pagina de descărcare și de a da, putem salva undeva această pagină pentru a testa și utilizate în mod continuu în timpul testării. În acest caz, clasa de acces la resurse externe Moka și returnează conținutul dorit atunci când solicită SUT.
De ce sunt ele importante? Pentru că ei pot testa toate - fiecare condiție în clasă, fiecare ciclu al fiecărei metode. Astfel de teste sunt, de obicei cel mai mult.
Există un fel de clasificare descrise în modelele XUnit de testare (o scurtă explicație poate fi găsită în blog-ul lui Fowler). Părerea mea personală - aceste nume sunt aspirate din deget, și de a le folosi nu este necesar. Terminologie în testarea și atât de confuz, și apoi apar Dummy, fals, Mock, care sunt prea aproape în sens semantic pentru a le lua în considerare în mod serios ca instrument de comunicare. Iar nivelul de unitate de testare, și așa prea mică pentru a Moki a trebuit să fie împărțite în tipuri. In practica mea, acești termeni sunt necesare doar în timpul interviurilor.

Teste de componente. Termenul nu este folosit atât de des, dar mi-a placut. În acest caz, se referă la componentele sistemului. Nu aveți nevoie pentru a rula întreaga aplicație. De obicei, în aplicațiile noastre, noi avem totul în straturi. Componente astfel de teste pot inițializa toate straturile resurse externe Moka, și testa o bucată de logică. Pro acestor teste: a) Testul nu este o clasă, dar reale de fond logica b) foarte rapid în comparație cu testul de sistem. Testele componente Ideal - cele în care toate resursele externe sunt limitate, dar uneori este mai ușor să lase ceva, de exemplu, în cazul în care acest flux folosind JMS într-o singură aplicație, foarte JMS poate fi lăsat (înlocuindu-l cu ActiveMQ, de exemplu), în timp ce apelul la extern sistemele au deja Moka, altfel le vom testa și, în acest caz, prea mult timp vor fi cheltuite pe suport.
Uneori se face referire la testul ca o componentă modulară. Ei bine, adevărul este o componentă puteți apela ceva atât de frumos, cu acest termen.

Teste de integrare (Integrare sisteme de testare, SIT). Acest termen este cea mai aglomerată dintre toate testele de integrare pot fi numite în următoarele cazuri: atunci când doar o resursă externă; Atunci când clasele de aglomerare utilizate (în acest caz, Component); Când rulați toate aplicațiile, etc. Dă-le oamenilor un motiv ei numesc acest test integrarea. Încerc să nu utilizeze posibilitatea acestui termen, dar sunt cazuri adecvate semantic: aceasta este atunci când de fapt, testarea integrarea cu alte sisteme. Exemplu: Anexa A stay tuned în anexa B și anexa C. trage toate aceste sisteme pot comunica peste protocoale diferite: JAX-RS, JAX-WS, JMS, Protobuf, avem nevoie pentru a testa această comunicare, deoarece pe de o parte ar putea schimba protocolul în în timp ce, pe de altă parte, el a rămas același, și apoi cererea ca întreg nu este operațional. De fapt, acest lucru și de a face teste de integrare, testeaza puncte de sisteme de contact. Rețineți că acestea nu au nevoie pentru a testa logica de afaceri în sine, în caz contrar, din nou, va testa mai multe aplicații, și nu aveți nevoie de acest hemoroizi.

Teste de sistem. Se testează ilk lui trebuie să fie rulează aplicația. Ele pot fi atât testere manuale și automate pentru a oferi locul de muncă. Problema cu aceste teste: acestea sunt dificil de a scrie și de a automatiza, deoarece întregul mediu trebuie să fie ridicate; acestea sunt lente; acestea sunt dificil de întreținut, pentru că fiecare stranut le poate rupe. Astfel de teste trebuie să fie mici în comparație cu modulare și componente, acestea trebuie să testeze funcționalitatea de bază a aplicației și nu intră în detalii.
Aceste teste trebuie să fie independente una de cealaltă. De exemplu, dacă aveți un site web unde vă puteți înregistra, apoi în mod ideal, fiecare test ar trebui să se înregistreze un nou utilizator, este important să paraleliza executarea lor, atunci când se dovedește că acestea sunt de jumătate de zi.

La doar câțiva termeni, deși ortogonală de mai sus (deoarece ele pot fi în același timp și de sistem, de exemplu), dar este foarte utilizat:

Teste Sanity - Teste de sistem de bază pentru a stabili dacă cererea este operațional și toate. Convenabil de a utiliza la fiecare comandă deploe automat pentru a determina dacă o aplicație pentru a rula cu succes. Aceasta include verificarea doar cele mai funcțiile de bază ale sistemului. Aici este un exemplu de implementare scris în Python - ea pur și simplu interoghează pagina de start, în cazul în care îndeplinește HTTP 200/201, aplicație a început înseamnă dacă există coduri de eroare medie de livrare și asamblare site-ul a căzut în Jenkins'e trebuie să marcheze în roșu.

Teste Story acceptare. Când ai format cerințele, puteți determina testele (și, uneori, chiar și doar pentru a le scrie), care va stabili dacă îndeplinește funcționale cerințele depuse. Foarte misto cazul în care clientul se scrie el însuși, dar această oportunitate este rară. În cazul în care nu trece aceste teste, atunci când funcția nu este pusă în aplicare. Este foarte convenabil pentru a scrie astfel de teste sub forma Având în vedere unele de stat. atunci când faci ceva nou. atunci vom găsi un nou stat.

Testele de acceptare a utilizatorilor - este atunci când sadite utilizatori reali (care oferă acces la client) și cere poklikat, de așteptare pentru feedback. Aceasta este etapa în care puteți defini sau chiar dacă acesta este dorit de client.

Testarea de regresie (teste de regresie). Testele efectuate de acceptare, odată ce ea a servit, iar caracteristica livrat clientului va fi în măsură să continue să servească sub forma unor teste de regresie. Aceste teste stabilesc dacă vechi nu este rupt în timp ce funcționalitatea de punere în aplicare noi caracteristici sau după refactorizare. Importanța acestor teste nu pot fi overemphasized. Dacă le automatizeze, va fi capabil să facă comunicate de frecvente. Care nu au aceeași regresie automate, va trebui să manual re-testa o mulțime înainte de fiecare lansare. Automat Regresia vă permite să se simtă om încrezător :)

Teste de încărcare. Determina modul în care aplicația se comportă în condiții de stres și de fapt, ce fel de sarcină care le pot rezista. Destul de teste complexe, în special având în vedere că sarcina în sine - lucru pe mai multe fețe. Puteți testa capacitatea de încărcare maximă (în cazul în care cererea lasă permanent), dar cele mai multe dintre noi sunt interesați de capacitatea (da bomboane celor care-l traduc în limba română :)) (de exemplu, numărul de tranzacții pe secundă.) - numărul de tranzacții simultane în care o cerere se vor comporta în mod satisfăcător (ați pus inițial pragul, de exemplu, fiecare pagină nu ar trebui să dureze mai mult pentru a încărca 1 sec).

Teste de rezistență (testelor Longevitatea) - un subtip de teste de stres. Caracterizat prin faptul că ai pus doar aplicația sub constant reclame de sarcină medie, o lună sau reporniți-l. Aceste teste ajuta la determinarea, de exemplu, dacă aveți o scurgere de memorie.

Biblioteci Prezentare generală pentru testare:

JUnit. TestNG pentru a rula teste și rezultatele testelor. Este ca Groovy JUnit, puteți asculta-o la una dintre aceste sesiuni JTalks.

Mockito. EasyMock - cel mai popular bibliotecă pentru crearea mokov

PowerMock - vă permite să înlocuiască practicile statice, finale, private, astfel de ajutoare de bibliotecă în sistemele vechi, care sunt dificil de refactor

Awaitility - care permite convenabil să lucreze în cazurile în care nevoia de a aștepta un răspuns pentru un timp. Imediat am spus, că nu este foarte eficient, mult mai eficient de a utiliza unele callback.

Vă asigurăm. Restito - pentru testele de scris, de lucru cu API-ul REST. Primul este de a testa serverul REST, care este de a trimite cereri către serviciul; iar al doilea este de a rula mock-service si testa modul în care clientul REST trimite cereri către alte sisteme.

JBehave. Castravete (Ruby) - care permite cadrelor să descrie testele în formă Dată / Când / Apoi (așa numita Specificație Prin exemplul). În experiența primul care a spus că lucrul în practică, nu este atât de ușor, mai în detaliu într-o revizuire a JBehave.