Salut, Habr!
Mă numesc Maxim Ponomarenko și sunt dezvoltator la Sportmaster. Am 10 ani de experiență în domeniul IT. Mi-am început cariera în domeniul testării manuale, apoi m-am orientat spre dezvoltarea bazelor de date. În ultimii 4 ani, acumulând cunoștințele obținute în testare și dezvoltare, mă ocup de automatizarea testării la nivelul SGBD.
Fac parte din echipa Sportmaster de puțin peste un an și la unul dintre proiectele mari mă ocup de dezvoltarea testării automatizate. În aprilie, eu și colegii de la Sportmaster Lab am participat la o conferință în Krasnodar, unde prezentarea mea s-a intitulat „Unit-testele în SGBD”. Acum vreau să o împărtășesc cu voi. Vor fi multe texte, așa că am decis să împart prezentarea în două postări. În prima vom discuta despre testele automate și testarea în general, iar în a doua mă voi concentra mai în detaliu asupra sistemului nostru de unit-testare și rezultatele aplicării sale.
La început, puțină teorie plictisitoare. Ce este testarea automatizată? Este testarea care se realizează cu ajutorul mijloacelor software și, în domeniul IT modern, este din ce în ce mai utilizată în dezvoltarea software-ului. Acest lucru se datorează faptului că companiile cresc, sistemele lor informaționale se dezvoltă și, prin urmare, crește și volumul funcționalității care trebuie testată. A devenit din ce în ce mai costisitor să se realizeze testarea manuală.
Am lucrat într-o companie mare, ale cărei versiuni sunt lansate o dată la două luni. În acest timp, se cheltuia o lună întreagă pentru ca o echipă de zece testeri să verifice manual funcționalitatea. Datorită implementării automatizării, o echipă mică de dezvoltatori a reușit să reducă timpul de testare la 2 săptămâni în decurs de un an și jumătate. Nu doar că am crescut viteza de testare, dar am și îmbunătățit calitatea acesteia. Testele automate sunt rulate regulat și ele execută întotdeauna întregul set de verificări incorporate, ceea ce ne permite să excludem factorul uman.
Pentru IT-ul modern este caracteristic faptul că de la un dezvoltator se poate cere nu doar să scrie codul produsului, ci și să scrie unit-testele care verifică acest cod.
Dar ce să faci dacă sistemul tău se bazează în principal pe logica serverului? Nu există o soluție universală sau cele mai bune practici pe piață. În general, companiile abordează această problemă prin crearea unui sistem de testare personalizat. Un astfel de sistem de testare automatizat personalizat a fost creat în proiectul nostru și despre el voi vorbi în prezentarea mea.
Testăm loialitatea
Pentru început, să discutăm despre proiectul în care am implementat sistemul de testare automată. Proiectul nostru este sistemul de loialitate al Sportmaster (de altfel, am scris deja despre el în ).
Dacă compania ta este destul de mare, sistemul tău de loialitate va avea trei proprietăți standard:
- Sistemul tău va fi foarte solicitat
- Sistemul tău va conține procese de calcul complexe
- Sistemul tău va fi activ îmbunătățit.
Să le luăm pe rând… În total, dacă luăm în considerare toate brandurile Sportmaster, avem peste 1000 de magazine în Rusia, Ucraina, China, Kazahstan și Belarus. În aceste magazine se efectuează zilnic aproximativ 300 000 de cumpărături. Asta înseamnă că în fiecare secundă în sistemul nostru ajung 3-4 bonuri. Evident, sistemul nostru de loialitate este foarte solicitat. Și, deoarece este folosit activ, trebuie să oferim cele mai ridicate standarde de calitate, deoarece orice eroare în software se traduce în pierderi financiare, de reputație și altele.
În același timp, la Sportmaster funcționează peste o sută de promoții diferite. Promoțiile sunt foarte diverse: există promoții de produse, promoții în funcție de ziua săptămânii, promoții legate de magazine specifice, promoții pe suma bonului, promoții pe numărul de produse. În general, este destul de complex. Clienții au bonusuri, au coduri promoționale care sunt utilizate la cumpărături. Toate acestea conduc la faptul că calcularea oricărei comenzi este o sarcină destul de nontrivială.
Algoritmul care implementează procesarea comenzilor este cu adevărat terifiant și complicat. Orice modificare adusă acestui algoritm este o chestiune destul de riscantă. Se părea că cele mai neglijabile modificări pot duce la efecte destul de imprevizibile. Și anume, aceste procese de calcul complexe, mai ales cele care implementează funcționalități critice, sunt cei mai buni candidați pentru automatizare. Verificarea manuală a zecilor de cazuri similare consumă mult timp. Deoarece punctul de intrare în proces rămâne neschimbat, odată ce l-am descris, putem genera rapid teste automate și putem fi siguri de funcționarea funcționalității.
Având în vedere că sistemul nostru este folosit activ, afacerea va dori ceva nou de la voi, să țină pasul cu vremurile și să fie orientată spre client. În sistemul nostru de loialitate, lansările au loc o dată la două luni. Asta înseamnă că, la fiecare două luni, trebuie să facem un regres complet al întregului sistem. În același timp, în mod natural, ca în orice IT modern, dezvoltarea nu ajunge imediat de la dezvoltator la producție. Aceasta își face apariția pe conturul dezvoltatorului, apoi trece succesiv prin medii de testare, de lansare, de acceptare și abia apoi ajunge în producție. Cel puțin în mediile de testare și de lansare, trebuie să facem un regres complet al întregului sistem.
Proprietățile descrise sunt standard pentru aproape orice sistem de loialitate. Haideți să discutăm despre caracteristicile proiectului nostru.
Tehnologic, 90% din logica sistemului nostru de loialitate este server-side și este implementată pe Oracle. Există un client dezvoltat în Delphi, care îndeplinește funcția de administrator ARM. Există servicii web pentru aplicații externe (de exemplu, site-uri web). Prin urmare, este foarte logic că, dacă vom desfășura un sistem de testare automată, o vom face pe Oracle.
Sistemul de loialitate de la Sportmaster există de mai bine de 7 ani și a fost creat de către dezvoltatori individuali... Numărul mediu de dezvoltatori pe proiectul nostru în acești 7 ani a fost de 3-4 persoane. Însă, în ultimul an, echipa noastră s-a extins considerabil, iar acum la proiect lucrează 10 persoane. Asta înseamnă că în proiect vin oameni care nu sunt familiarizați cu sarcinile tipice, procesele și arhitectura. Există, astfel, un risc crescut de a dintr-o dată să actualizăm greșeli.
Proiectul se caracterizează prin lipsa testerilor dedicați ca unități de muncă. Testarea, fără îndoială, există, dar aceasta este realizată de analiști, pe lângă celelalte responsabilități principale: interacțiunea cu clienții de afaceri, utilizatorii, dezvoltarea cerințelor pentru sistem etc... Cu toate că testarea se desfășoară la un nivel foarte bun (în special având în vedere că acest raport ar putea ajunge la ochii unor analiști), eficiența specializării și concentrare pe un singur lucru nu a fost anulată.
Având în vedere cele spuse mai sus, pentru a îmbunătăți calitatea produsului livrat și a reduce termenii de dezvoltare, ideea de automatizare a testării în proiect pare destul de logică. În diferite etape ale existenței sistemului de loialitate, anumiți dezvoltatori au făcut eforturi pentru a acoperi codul lor cu teste unitare. Acesta a fost în general un proces destul de fragmentat, unde fiecare a folosit propria arhitectură și metode. Rezultatele finale pentru testele unitare erau comune: testele erau dezvoltate, utilizate pentru o vreme, stocate în depozitul de versiune a fișierelor, dar la un moment dat au încetat să mai fie rulate și au fost uitate. Acest lucru s-a întâmplat în special pentru că testele erau mai mult legate de un executant specific, nu de proiect.
utPLSQL vine în ajutor
Știți ceva despre Steven Feuerstein?
Acesta este un tip inteligent care și-a dedicat o mare parte din carieră lucrând cu Oracle și PL/SQL, scriind un număr considerabil de lucrări pe această temă. O carte cunoscută a sa se intitulează „Oracle PL/SQL. Pentru profesioniști”. Dezvoltarea soluției utPLSQL îi aparține, sau, așa cum este prescurtat, Unit Testing framework pentru Oracle PL/SQL. Soluția utPLSQL a fost creată în 2016, dar lucrările asupra ei continuă activ, fiind lansate versiuni noi. La momentul prezentării, ultima versiune este datată 24 martie 2019.
Ce este aceasta? Este un proiect open-source separat. Are câteva megabytes, incluzând exemplele și documentația. Se prezintă fizic ca un schelet separat în baza de date ORACLE, având un set de pachete și tabele pentru organizarea testării unităților. Instalarea durează câteva secunde. O caracteristică distinctivă a utPLSQL este simplitatea sa de utilizare.
În termeni generali, utPLSQL reprezintă un mecanism pentru desfășurarea testelor unității, unde un test unit este considerat a fi proceduri de pachet Oracle obișnuite, organizarea cărora respectă anumite reguli. În plus față de desfășurare, utPLSQL stochează un log al tuturor execuțiilor testelor tale și dispune de un sistem intern de raportare.
Hai să vedem un exemplu despre cum arată codul unui test unit, implementat conform acestei metodologii.
Așadar, pe ecran este prezentat codul unei specificații tipice a unui pachet cu teste unit. Care sunt cerințele obligatorii? Pachetul trebuie să aibă un prefix „utp_”. Același prefix trebuie să aibă toate procedurile cu teste. În pachet trebuie să existe două proceduri standard: „utp_setup” și „utp_teardown”. Prima procedură este apelată la repornirea fiecărui test unitar, iar a doua — după execuție.
„utp_setup”, de regulă, pregătește sistemul nostru pentru desfășurarea testului unitar, de exemplu, creând datele de test. „utp_teardown” — dimpotrivă, readuce totul la setările inițiale și resetează rezultatele execuției.
Iată un exemplu de cel mai simplu test unitar, care verifică normalizarea numărului de telefon introdus de client la forma standard pentru sistemul nostru de loialitate. Nu există standarde obligatorii pentru modul în care se scriu procedurile cu teste unitare. De obicei, se efectuează apelul unui anumit metod al sistemului testat, iar rezultatul returnat de aceasta se compară cu rezultatul de referință. Este important ca compararea rezultatului de referință și a celui obținut să se realizeze prin metode standard utPLSQL.
Într-un test unitar pot exista un număr nelimitat de verificări. Așa cum se poate vedea din exemplu, facem patru apeluri succesive la metoda testată pentru normalizarea numărului de telefon și evaluăm rezultatul după fiecare apel. Atunci când dezvoltăm un test unitar, trebuie să ținem cont de faptul că există verificări care nu influențează sistemul în niciun fel, iar după anumite verificări trebuie să revenim la starea inițială a sistemului.
De exemplu, în testul unitar prezentat, pur și simplu formatați numărul de telefon de intrare, ceea ce nu influențează sistemul de loialitate.
Dar dacă scriem teste unitare pentru metoda de creare a unui nou client, atunci după fiecare verificare un nou client va fi creat în sistem, ceea ce poate influența execuția ulterioară a testului.
Iată cum se efectuează testele unitare. Sunt acceptate două opțiuni de execuție: rularea tuturor testelor unitare dintr-un anumit pachet sau rularea unui anumit test unitar într-un anumit pachet.
Iată cum arată un exemplu de sistem intern de raportare. Pe baza rezultatelor lucrării teste unitare, utPLSQL generează un mic raport. În acesta vedem rezultatul pentru fiecare verificare specifică și rezultatul general al executării testului unitar.
6 reguli pentru teste automate
Înainte de a începe să creăm un nou sistem de testare automată a sistemului de loialitate, împreună cu conducerea, am stabilit principiile pe care viitoarele noastre teste automate ar trebui să le respecte.
- Testele automate trebuie să fie eficiente și să aducă beneficii. Avem dezvoltatori minunați, despre care trebuie neapărat să vorbim, deoarece cineva dintre ei va vedea cu siguranță această prezentare, iar ei scriu cod remarcabil. Dar chiar și codul lor remarcabil nu este perfect și a conținut, conține și va conține erori. Testele automate trebuie să identifice aceste erori. Dacă nu o fac, ori scriem teste automate slabe, ori am ajuns într-un domeniu mort, care în principiu nu mai este dezvoltat. În ambele cazuri, facem ceva greșit și abordarea noastră este pur și simplu lipsită de sens.
- Testele automate trebuie utilizate. Nu are rost să investești o mulțime de timp și efort în scrierea unui produs software, să-l pui într-un depozit și să-l uiți. Testele trebuie să fie rulate și să fie lansate cât mai regulat posibil.
- Testele automate trebuie să funcționeze stabil. Indiferent de ora din zi, de platforma de testare și de alte setări ale sistemului, rulările testelor ar trebui să conducă la același rezultat. De obicei, acest lucru este asigurat prin faptul că testele automate lucrează cu date de testare speciale cu setările sistemului fixate.
- Testele automate trebuie să funcționeze cu o viteză acceptabilă pentru proiectul vostru. Acest timp este determinat individual pentru fiecare sistem. Unii își permit să lucreze toată ziua, în timp ce pentru alții este critic să se încadreze în secunde. Ce norme de viteză am atins în proiectul nostru, voi povesti puțin mai târziu.
- Dezvoltarea testelor automate trebuie să fie flexibilă. Nu este de dorit să renunțăm la verificarea unei funcționalități doar pentru că nu am făcut-o înainte sau din alte motive. utPLSQL nu impune nicio restricție asupra dezvoltării, iar Oracle permite în principiu implementarea celor mai variate lucruri. Majoritatea problemelor au o soluție, întrebarea este doar de timp și eforturile investite.
- Dezvoltabilitatea. Avem mai multe platforme unde sunt necesare rulări de teste. Pe fiecare dintre platforme, oricând poate fi actualizat un dump cu date. Trebuie să gestionăm proiectul cu teste automate astfel încât să putem realiza, fără dureri, instalarea sa completă sau parțială.
Iar în al doilea post, în câteva zile, voi vorbi despre ce am realizat și ce rezultate am obținut.
Sursa: habr.com
