Ce este testarea

Dezvoltator full-stack (Symfony, Angular)

În general, wiki-ul poate fi pentru început, și apoi mergeți adânc în literatură. Iată o scurtă descriere, scopul căruia este de a oferi mai multe cuvinte cheie de căutare.







Modulare, acestea sunt teste unitare, concepute pentru a testa modulele / clasele individuale. Linia de fund este că vom testa comportamentul unei singure clase la un moment dat. Dacă clasa se referă la instanțe ale altor clase, îi batjocorim. Aceasta este palmat off pe ei feykovy de clasă care are aceeași interfață, dar nu și în punerea în aplicare a metodelor și a verifica dacă metoda este apelată cu ce argumente numărul de ori numit, etc. În mod similar, metodele de moka pot întoarce stub-uri (stubs), unele date greu codate pentru unele cazuri. Adică dacă scriem o clasă pentru a lucra cu o bază de date, un server socket etc. Avem nevoie de o conexiune la baza de date, prize, etc. înfășurat în clase, care ar putea fi apoi schimbat în moki este bun. Dacă la tine în teste unitare există o lucrare reală cu un sistem de fișiere sau ceva în acest spirit, deja miroase teste de integrare. Mai multe detalii găsiți în documentația pentru phpunit. Există, de asemenea, o metodologie de dezvoltare ca TDD, vă sfătuiesc să citiți în acest sens "Programarea Extremă" a lui Kent Beck.

Testarea integrării - testarea mai multor module într-un pachet. Asta este, ne testa componenta noastra sau bucata sa auto-suficienta in conditii reale. Dacă această componentă este pentru lucrul cu fișiere - îi permitem accesul la fișiere. În cazul în care baza de date - apoi da o conexiune reală la baza de date. Și putem să scoatem ceva. Aceasta, așa cum se spune, depinde de sarcină. Să spunem că apelul către apiskam în afara merită să se înmoaie și să se stabilizeze. Scopul principal al acestor teste este să se asigure că modulele funcționează bine împreună. Acest lucru este deosebit de important atunci când modulele sunt scrise de oameni diferiți.

Testarea funcțională este testarea întregului ansamblu de aplicații. Dacă acest API REST, atunci curbați prin metode reale sunt trimise smucitura mai puțin cererile reale și răspunsurile sunt validate. În cazul în care pagina web, Testete UI sileniumom / phantom.js / zombi.js sau dacă nu avem încă și js de testare, doar buclat + un browser virtual în același php. În general, testele funcționale bune nu permit nici un moks etc. dar din nou dacă vreți cu adevărat, puteți (din nou, accesați serviciile terților, pe care nu le controlam).







Dar realitatea este că testele UI acoperă proiectul nu este prea convenabil. În primul rând, UI se poate schimba, dar este, de asemenea, necesar să le susținem. În al doilea rând, este plictisitor. În al treilea test poate cădea pur și simplu. aici au luat-o și au căzut. Și apoi începe, așa că testele au căzut din nou. ce a căzut acolo? Ah, nu înfricoșător, poți elibera. De asemenea, pe proiectele mari, testele UI se desfășoară pentru o perioadă lungă, foarte lungă, unele dintre ele pur și simplu urmărite pe timp de noapte. Sentimentul de testare cu această abordare nu este prea mult, deoarece dezvoltatorul ar trebui să știe că ceva sa destrămat cât mai repede posibil. Și așa vine el, vede că testele sunt roșii din nou, fixează aceste teste roșii și lansează. de așteptare. trece de o jumătate de oră, de exemplu, și undeva în alt loc a căzut. Pe scurt, știi.

Testele de acceptare sunt, în esență, aceleași teste funcționale, dar sunt prezentate în contextul caracteristicilor caracteristicilor. Dacă ați lucrat într-o bună zi la departamentul de asigurare a calității, probabil ați auzit despre astfel de lucruri, cum ar fi criteriile de acceptare. Asta este, aceasta este lista de verificare, pe care testerul ar trebui să o verifice pentru a vă asigura că totul este în regulă. Pe baza acestei foi de verificare puteți scrie teste funcționale. Există, de asemenea, unelte cum ar fi Castraveți / Behat, care vă permit să scrieți caietul de sarcini sub formă de șuruburi. În acest caz, specificațiile pentru aceste instrumente pot scrie QA și le implementați doar pentru pași. Adică, stratul dintre "criteriile de acceptare" și testele pregătite pentru execuție scade. Mai mult, STEP poate reyuzat, masa combinată a STEP sa terminat, trebuie doar să ofere același sistem STEP podgotvallivayuschie (încărcare / generarea de program, etc.). Mai repede o șoaptă și este convenabil. Dar integrarea mai lentă, dar nu la fel de rigidă ca funcțională, datorită căreia acestea sunt mai ușor de întreținut. QA scrieți spec, implementați teste pentru acest spec, scrieți cod pentru teste, teste verde - funcțional gata.

Există tot felul de termeni, cum ar fi testele piramidale etc. Ei spun că există o mulțime de unități de teste, o integrare puțin mai puțină și puțin funcțională. Apoi, testele sunt efectuate mai repede, iar acoperirea tuturor testelor funcționale este, de obicei, depășită.

Ei bine, din nou, există un lucru ca bunul simț. Unele lucruri pe care le putem spune pot fi marcate și nu sunt acoperite de teste, altele merită acoperite. Unele nu sunt complet, unele cu cât mai mult acoperire posibil. Să spunem că pentru a testa interfața (exact cum arată, unde este elementul) în general nu are sens. Acest lucru necesită o mulțime de resurse. Deși pot exista proiecte în care acest lucru este justificat.

Pe scurt Citiți despre TDD și ATDD (poate și BDD afectate, dar nu este doar un programator depinde, manageri, client sau produs ouner ar trebui să fie, de asemenea, implicate, de fapt, această abordare funcționează bine, ca parte a produselor vizate de pe freelancing și externalizeze puteți întâlni rar). Integrare continuă și livrare continios.

@StrangeAttractor tesami acoperire de 100% înseamnă că codul în conformitate cu cazuri de testare se efectuează în fiecare linie de cod care îndeplinește fiecare ramură în cazul în care s-și așa mai departe. Pentru majoritatea sistemelor, acest lucru nu este deosebit de dificil, poate că este de prisos. Există lucruri care, în principiu, nu pot fi acoperite în teste cu 100%.

În ceea ce privește cazul dvs., cel mai probabil o problemă cu arhitectura. Dacă componenta este dificil de acoperit cu teste, atunci ceva a mers prost. Ei bine, sau acoperirea cu integrarea.

@ StrangeAttractor dacă sincer ar fi frumos să vedem doar un exemplu aproximativ, iar apoi acest "intermediar" este destul de vag. Puteți aranja? În orice caz, toată lumea este umedă și stabilă.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: