Teste unitare într-un DBMS - cum o facem în Sportmaster, partea a doua

Prima parte - aici.

Imaginați-vă o situație. Vă confruntați cu sarcina de a dezvolta noi funcționalități. Ai experiență de la predecesorii tăi. Presupunând că nu aveți obligații morale, ce ați face?

Cel mai adesea, toate evoluțiile vechi sunt uitate și totul începe de la capăt. Nimănui nu-i place să sape în codul altcuiva și, dacă ai timp, de ce să nu începi să-ți creezi propriul sistem? Aceasta este o abordare tipică și, în multe privințe, este corectă. Dar în proiectul nostru, am acționat diferit. Ne-am bazat viitorul sistem de testare automatizată pe evoluțiile testelor unitare pe utPLSQL de la predecesorii noștri, apoi am început să lucrăm în mai multe direcții paralele.

1. Restaurarea vechilor teste unitare. Recuperare înseamnă adaptarea testelor la starea existentă a sistemului de loialitate și adaptarea testelor la standardele utPLSQL.
2. Rezolvând problema prin înțelegere și ce anume, ce metode și procese, am acoperit-o cu autotestele. Trebuie fie să păstrați aceste informații în cap, fie să trageți concluzii bazate direct pe codul autotestelor. Prin urmare, am decis să creăm un catalog. Am atribuit un cod mnemonic unic fiecărui autotest, am creat o descriere și am fixat setările (de exemplu, în ce condiții ar trebui să fie rulat sau ce ar trebui să se întâmple dacă rularea testului eșuează). În esență, am completat metadatele despre autotestări și am plasat aceste metadate în tabelele standard ale schemei utPLSQL.
3. Definiția strategiei de extindere, i.e. selectarea funcționalității care este supusă verificării prin autotestare. Am decis să acordăm atenție la trei lucruri: noi îmbunătățiri ale sistemului, incidente din producție și procese cheie ale sistemului. Astfel, dezvoltăm în paralel cu lansarea, asigurând o calitate superioară a acesteia, extinzând simultan sfera regresiei și asigurând fiabilitatea sistemului în locurile critice. Primul astfel de blocaj a fost procesul de distribuire a reducerilor și bonusurilor prin cec.
4. Desigur, am început să dezvoltăm noi autotestări. Una dintre primele sarcini de lansare a fost evaluarea performanței mostrelor predefinite ale sistemului de loialitate. Proiectul nostru are un bloc de interogări sql fixate rigid care selectează clienții în funcție de condiții. De exemplu, obțineți o listă cu toți clienții a căror ultima achiziție a fost într-un anumit oraș sau o listă cu clienții a căror valoare medie de achiziție este peste o anumită valoare. După ce au scris autotestele, am verificat mostre predefinite, parametri de performanță de referință fixați și, în plus, am primit și testarea sarcinii.
5. Lucrul cu autotestele ar trebui să fie convenabil. Cele mai frecvente două acțiuni sunt rularea autotestelor și generarea datelor de testare. Așa au apărut în sistemul nostru două module auxiliare: modulul de lansare și modulul de generare a datelor.

   Lansatorul este reprezentat ca o procedură generică cu un parametru text de intrare. Ca parametru, puteți trece un cod mnemonic de autotest, un nume de pachet, un nume de test, o setare de autotest sau un cuvânt cheie rezervat. Procedura selectează și rulează toate autotestele care îndeplinesc condițiile.

   Modulul de generare a datelor este prezentat ca un pachet, în care pentru fiecare obiect al sistemului testat (un tabel în baza de date), a fost creată o procedură specială care inserează datele acolo. În această procedură, valorile implicite sunt completate la maximum, ceea ce asigură crearea de obiecte literalmente la un clic de deget. Și pentru ușurință în utilizare, au fost create șabloane pentru datele generate. De exemplu, creați un client de o anumită vârstă cu un telefon de testare și o achiziție finalizată.

6. Autotestele ar trebui să ruleze și să ruleze într-un timp rezonabil pentru sistemul dvs. Așadar, a fost organizată o lansare de noapte zilnică, pe baza rezultatelor căreia se generează un raport de rezultate și se transmite întregii echipe de dezvoltare prin corespondență corporativă. După restaurarea autotestelor vechi și crearea altora noi, timpul total de rulare a fost de 30 de minute. O astfel de performanță s-a potrivit tuturor, deoarece lansarea a avut loc în afara orelor.

   Dar a trebuit să lucrăm la optimizarea vitezei de lucru. Sistemul de fidelizare a producției este actualizat noaptea. Ca parte a uneia dintre lansări, a trebuit să facem urgent modificări noaptea. O jumătate de oră de așteptare a rezultatelor autotestelor la trei dimineața nu a făcut-o fericită pe persoana responsabilă pentru eliberare (salutări ardente lui Alexei Vasyukov!), Și a doua zi dimineața au fost spuse o mulțime de cuvinte calde către sistemul nostru. Dar, ca urmare, a fost stabilit un standard de 5 minute pentru muncă.

   Pentru a accelera performanța, am folosit două metode: am început să rulăm autotestări în trei fire paralele, deoarece acest lucru este foarte convenabil datorită arhitecturii sistemului nostru de loialitate. Și am abandonat abordarea atunci când autotestul nu creează date de testare pentru el însuși, ci încearcă să găsească ceva potrivit în sistem. După efectuarea modificărilor, timpul total de funcționare a fost redus la 3-4 minute.

7. Un proiect cu autotestare ar trebui să poată fi implementat pe diverse standuri. La începutul călătoriei, au existat încercări de a ne scrie propriile fișiere batch, dar a devenit clar că o instalare automată scrisă de sine este o oroare completă și ne-am îndreptat către soluții industriale. Datorită faptului că proiectul are foarte mult cod direct (în primul rând, stocăm codul autotestelor) și foarte puține date (datele principale sunt metadate despre autotestări), s-a dovedit a fi foarte ușor de integrat în Proiect Liquibase.

   Este o bibliotecă independentă de baze de date open source pentru urmărirea, gestionarea și aplicarea modificărilor schemei bazei de date. Gestionat prin linie de comandă sau cadre precum Apache Maven. Principiul de funcționare al Liquibase este destul de simplu. Avem un proiect organizat într-un anumit mod, care constă în modificări sau script-uri care trebuie să fie rulate pe serverul țintă și fișiere de control care determină în ce ordine și cu ce parametri trebuie instalate aceste modificări.

   La nivel DBMS, este creat un tabel special în care Liquibase stochează jurnalul de rollback. Fiecare modificare are un hash calculat care este comparat de fiecare dată între proiect și starea din baza de date. Datorită Liquibase, putem implementa cu ușurință modificări ale sistemului nostru în orice circuit. Autotestele sunt acum rulate pe bucle de testare și lansare, precum și pe containere (bucle personale ale dezvoltatorilor).

Deci, să vorbim despre rezultatele aplicării sistemului nostru de testare unitară.

1. Desigur, în primul rând, suntem convinși că am început să dezvoltăm un software mai bun. Autotestele rulează zilnic și găsesc zeci de erori la fiecare lansare. Mai mult, unele dintre aceste erori sunt doar indirect legate de funcționalitatea pe care ne-am dorit cu adevărat să o schimbăm. Există îndoieli puternice că aceste erori au fost găsite prin testare manuală.
2. Echipa a câștigat încredere că funcționalitatea specifică funcționează corect... În primul rând, aceasta se referă la procesele noastre critice. De exemplu, în ultimele șase luni, nu am avut probleme cu distribuirea reducerilor și bonusurilor prin cec, în ciuda modificărilor aduse la fiecare lansare, deși în perioadele anterioare au apărut erori cu o oarecare frecvență.
3. Am reușit să reducem numărul de iterații de testare. Datorită faptului că autotestele sunt scrise pentru funcționalități noi, analiștii și testerii cu normă parțială primesc un cod de calitate superioară, deoarece a fost deja verificat.
4. O parte din evoluțiile testării automate este folosită de dezvoltatori. De exemplu, datele de testare pe containere sunt create folosind modulul de generare a obiectelor.
5. Este important să am dezvoltat o „acceptare” a sistemului de testare automată de către dezvoltatori. Există o înțelegere că acest lucru este important și util. Și din propria mea experiență pot spune că acest lucru este departe de a fi cazul. Autotestele trebuie scrise, trebuie menținute și dezvoltate, rezultatele analizate și, adesea, aceste costuri de timp pur și simplu nu merită. Este mult mai ușor să mergi la producție și să faci față problemelor acolo. În țara noastră, dezvoltatorii se aliniază și cer să-și acopere funcționalitatea cu autotestări.

Ce urmează

Să vorbim despre planurile de dezvoltare ale proiectului de testare automată.

Desigur, atâta timp cât sistemul de loialitate Sportmaster este în viață și continuă să se dezvolte, autotestele pot fi dezvoltate aproape la nesfârșit. Prin urmare, direcția principală de dezvoltare este extinderea ariei de acoperire.

Pe măsură ce numărul de autotestări crește, timpul total al muncii lor va crește constant și va trebui din nou să revenim la problema performanței. Cel mai probabil, soluția va fi creșterea numărului de fire paralele.

Dar acestea sunt moduri evidente de dezvoltare. Dacă vorbim despre ceva mai non-trivial, evidențiem următoarele:

1. Acum autotestele sunt gestionate la nivel DBMS, de exemplu. cunoștințele de PL/SQL sunt necesare pentru o muncă de succes. Dacă este necesar, gestionarea sistemului (de exemplu, lansarea sau crearea metadatelor) poate fi eliminată de un fel de panou de administrare folosind Jenkins sau ceva similar.
2. Toată lumea iubește indicatorii cantitativi și calitativi. Pentru testarea automată, un astfel de indicator universal este Acoperirea codului sau măsurarea acoperirii codului. Folosind acest indicator, putem determina ce procent din codul sistemului nostru testat este acoperit de autotestări. Începând cu versiunea 12.2, Oracle oferă posibilitatea de a calcula această măsură și sugerează utilizarea pachetului standard DBMS_PLSQL_CODE_COVERAGE.

   Sistemul nostru de autotest are puțin peste un an și ar putea fi timpul să evaluăm acoperirea. În ultimul meu proiect (un proiect nu al lui Sportmaster), s-a întâmplat asta. La un an după ce am lucrat la autotestări, conducerea a stabilit sarcina de a evalua ce procent din cod am acoperit. Cu o acoperire de peste 1%, conducerea ar fi fericită. Noi, dezvoltatorii, ne așteptam la un rezultat de aproximativ 10%. Am distrus acoperirea codului, am măsurat-o, am obținut 20%. Pentru a sărbători, am mers pentru premiu, dar cum am mers pentru el și unde am mers mai târziu este o cu totul altă poveste.

3. Autotestele pot testa serviciile web expuse. Oracle vă permite să faceți acest lucru și nu vom mai întâmpina o serie de probleme.
4. Și, desigur, sistemul nostru de testare automată poate fi aplicat unui alt proiect. Soluția pe care am primit-o este universală și necesită doar utilizarea Oracle. Am auzit că există un interes pentru testarea automată pe alte proiecte Sportmaster și, poate, vom merge la ele.

Constatări

Să recapitulăm. Pe proiectul de sistem de fidelizare din Sportmaster, am reușit să implementăm un sistem automat de testare. Baza sa este soluția utPLSQL de la Stephen Feuerstein. În jurul utPLSQL este codul pentru autotestări și module auxiliare auto-scrise: un lansator, un modul de generare de date și altele. Autotestele rulează zilnic și, cel mai important, funcționează și beneficiază. Suntem convinși că am început să lansăm software de calitate superioară. În același timp, soluția rezultată este universală și poate fi aplicată în mod liber oricărui proiect în care este necesară organizarea testării automate pe SGBD-ul Oracle.

PS Acest articol s-a dovedit a nu fi foarte specific: există mult text și practic nu există exemple tehnice. Dacă subiectul este interesant la nivel global, atunci suntem gata să-l continuăm și să revenim cu o continuare, unde vă vom spune ce s-a schimbat în ultimele șase luni și vă vom da exemple de cod.

Scrieți comentarii dacă există puncte care ar trebui subliniate în viitor sau întrebări care necesită dezvăluire.

Numai utilizatorii înregistrați pot participa la sondaj. Loghează-te, Vă rog.

Să scriem mai multe despre asta?

• da, desigur

• Nu multumesc

Au votat 12 utilizatori. 4 utilizatori s-au abținut.

Sursa: www.habr.com