Hei Habr!
Numele meu este Maxim Ponomarenko și sunt dezvoltator la Sportmaster. Am 10 ani de experiență în domeniul IT. Și-a început cariera în testarea manuală, apoi a trecut la dezvoltarea bazelor de date. În ultimii 4 ani, acumulând cunoștințele acumulate în testare și dezvoltare, am automatizat testarea la nivel DBMS.
Sunt în echipa Sportmaster de puțin peste un an și dezvolt testarea automată pentru unul dintre proiectele majore. În aprilie, băieții de la Sportmaster Lab și cu mine am vorbit la o conferință la Krasnodar, raportul meu s-a numit „Teste unitare într-un DBMS”, iar acum vreau să-l împărtășesc cu voi. Va fi mult text, așa că am decis să împart raportul în două postări. În primul, vom vorbi despre autotestări și testare în general, iar în al doilea, mă voi opri mai detaliat asupra sistemului nostru de testare unitară și a rezultatelor aplicării acestuia.
În primul rând, o teorie puțin plictisitoare. Ce este testarea automatizată? Aceasta este testarea care se realizează folosind software, iar în IT-ul modern este din ce în ce mai folosit în dezvoltarea de software. Acest lucru se datorează faptului că companiile cresc, sistemele lor informaționale cresc și, în consecință, cantitatea de funcționalitate care trebuie testată crește. Efectuarea testelor manuale devine din ce în ce mai costisitoare.
Am lucrat pentru o companie mare ale cărei lansări apar o dată la două luni. În același timp, a fost petrecută o lună întreagă pentru ca o duzină de testeri să verifice manual funcționalitatea. Datorită implementării automatizării de către o echipă mică de dezvoltatori, am reușit să reducem timpul de testare la 2 săptămâni într-un an și jumătate. Nu numai că am crescut viteza de testare, dar am îmbunătățit și calitatea acesteia. Testele automate sunt lansate în mod regulat și realizează întotdeauna întregul curs de verificări incluse în ele, adică excludem factorul uman.
IT-ul modern se caracterizează prin faptul că unui dezvoltator i se poate cere nu numai să scrie codul produsului, ci și să scrie teste unitare care verifică acest cod.
Dar ce se întâmplă dacă sistemul tău se bazează în principal pe logica serverului? Nu există o soluție universală sau cele mai bune practici pe piață. De regulă, companiile rezolvă această problemă prin crearea propriului sistem de testare auto-scris. Acesta este propriul nostru sistem de testare automatizat, care a fost creat pe proiectul nostru și voi vorbi despre asta în raportul meu.
Testarea loialității
Mai întâi, să vorbim despre proiectul în care am implementat un sistem automat de testare. Proiectul nostru este sistemul de loialitate Sportmaster (apropo, am scris deja despre el în ).
Dacă compania dvs. este suficient de mare, atunci sistemul dvs. de loialitate va avea trei proprietăți standard:
- Sistemul dvs. va fi foarte încărcat
- Sistemul dumneavoastră va conține procese de calcul complexe
- Sistemul dumneavoastră va fi îmbunătățit în mod activ.
Să mergem în ordine... În total, dacă luăm în considerare toate mărcile Sportmaster, atunci avem peste 1000 de magazine în Rusia, Ucraina, China, Kazahstan și Belarus. În aceste magazine se fac zilnic aproximativ 300 de achiziții. Adică în fiecare secundă 000-3 verificări intră în sistemul nostru. Desigur, sistemul nostru de loialitate este foarte încărcat. Și deoarece este utilizat în mod activ, trebuie să oferim cele mai înalte standarde de calitate, deoarece orice eroare a software-ului înseamnă pierderi mari monetare, reputaționale și de altă natură.
În același timp, Sportmaster derulează peste o sută de promoții diferite. Există o varietate de promoții: sunt promoții de produse, sunt cele dedicate zilei din săptămână, sunt cele legate de un anume magazin, sunt promoții pentru valoarea bonului, sunt pentru numărul de mărfuri. În general, nu e rău. Clienții au bonusuri și coduri promoționale care sunt folosite atunci când fac achiziții. Toate acestea duc la faptul că calcularea oricărei comenzi este o sarcină foarte netrivială.
Algoritmul care implementează procesarea comenzilor este cu adevărat teribil și complicat. Și orice modificare a acestui algoritm este destul de riscantă. Se părea că schimbările cele mai aparent nesemnificative ar putea duce la efecte destul de imprevizibile. Dar tocmai procesele de calcul atât de complexe, în special cele care implementează funcționalități critice, sunt cei mai buni candidați pentru automatizare. Verificarea manuală a zeci de cazuri similare necesită foarte mult timp. Și, deoarece punctul de intrare în proces este neschimbat, după ce l-a descris o dată, puteți crea rapid teste automate și puteți fi sigur că funcționalitatea va funcționa.
Deoarece sistemul nostru este utilizat în mod activ, afacerea va dori ceva nou de la tine, va trăi cu vremurile și va fi orientată către client. În sistemul nostru de loialitate, lansările apar la fiecare două luni. Aceasta înseamnă că la fiecare două luni trebuie să efectuăm o regresie completă a întregului sistem. În același timp, firește, ca în orice IT modern, dezvoltarea nu trece imediat de la dezvoltator la producție. Acesta își are originea pe circuitul dezvoltatorului, apoi trece succesiv prin bancul de testare, lansare, acceptare și abia apoi ajunge în producție. Cel puțin, pe circuitele de testare și de eliberare, trebuie să efectuăm o regresie completă a întregului sistem.
Proprietățile descrise sunt standard pentru aproape orice sistem de loialitate. Să vorbim despre caracteristicile proiectului nostru.
Din punct de vedere tehnologic, 90% din logica sistemului nostru de loialitate este bazată pe server și implementată pe Oracle. Există un client expus în Delphi, care îndeplinește funcția de administrator automat la locul de muncă. Există servicii web expuse pentru aplicații externe (de exemplu un site web). Prin urmare, este foarte logic că, dacă implementăm un sistem de testare automatizat, o vom face pe Oracle.
Sistemul de loialitate în Sportmaster există de mai bine de 7 ani și a fost creat de uni dezvoltatori... Numărul mediu de dezvoltatori pe proiectul nostru în acești 7 ani a fost de 3-4 persoane. Dar în ultimul an, echipa noastră a crescut semnificativ, iar acum sunt 10 oameni care lucrează la proiect. Adică vin la proiect oameni care nu sunt familiarizați cu sarcinile, procesele și arhitectura tipice. Și există un risc crescut ca să pierdem greșeli.
Proiectul se caracterizează prin absența unor testeri dedicați ca unități de personal. Există, desigur, testare, dar testarea este efectuată de analiști, pe lângă celelalte responsabilități principale ale acestora: comunicarea cu clienții de afaceri, utilizatorii, dezvoltarea cerințelor de sistem etc. etc... În ciuda faptului că testarea se desfășoară de foarte înaltă calitate (acest lucru este deosebit de potrivit să menționăm, deoarece unii dintre analiști pot atrage atenția acestui raport), eficiența specializării și concentrării asupra unui singur lucru nu a fost anulată. .
Având în vedere toate cele de mai sus, pentru a îmbunătăți calitatea produsului livrat și a reduce timpul de dezvoltare, ideea de a automatiza testarea pe un proiect pare foarte logică. Și în diferite etape ale existenței sistemului de loialitate, dezvoltatorii individuali au făcut eforturi pentru a-și acoperi codul cu teste unitare. În general, a fost un proces destul de dezarticulat, fiecare folosind propria arhitectură și metode. Rezultatele finale au fost comune testelor unitare: testele au fost dezvoltate, folosite de ceva timp, stocate într-o stocare de fișiere versionată, dar la un moment dat au încetat să ruleze și au fost uitate. În primul rând, acest lucru s-a datorat faptului că testele erau legate mai mult de un anumit performer, și nu de proiect.
utPLSQL vine în ajutor
Știi ceva despre Stephen Feuerstein?
Acesta este un tip inteligent care și-a dedicat o mare parte a carierei lucrului cu Oracle și PL/SQL și a scris un număr destul de mare de lucrări pe acest subiect. Una dintre cărțile sale celebre se numește: „Oracle PL/SQL. Pentru profesioniști.” Stephen a fost cel care a dezvoltat soluția utPLSQL sau, așa cum înseamnă, cadrul de testare unitară pentru Oracle PL/SQL. Soluția utPLSQL a fost creată în 2016, dar continuă să se lucreze activ la ea și sunt lansate versiuni noi. La momentul raportării, cea mai recentă versiune datează din 24 martie 2019.
Ce este. Acesta este un proiect open source separat. Cântărește câțiva megaocteți, inclusiv exemple și documentație. Din punct de vedere fizic, este o schemă separată în baza de date ORACLE cu un set de pachete și tabele pentru organizarea testării unitare. Instalarea durează câteva secunde. O caracteristică distinctivă a utPLSQL este ușurința în utilizare.
La nivel global, utPLSQL este un mecanism pentru rularea testelor unitare, în care un test unitar este înțeles ca proceduri obișnuite de lot Oracle, a căror organizare urmează anumite reguli. Pe lângă lansare, utPLSQL stochează un jurnal al tuturor testelor și are, de asemenea, un sistem intern de raportare.
Să ne uităm la un exemplu despre cum arată codul de test unitar, implementat folosind această tehnică.
Deci, ecranul arată codul pentru o specificație tipică a pachetului cu teste unitare. Care sunt cerințele obligatorii? Pachetul trebuie să aibă prefixul „utp_”. Toate procedurile cu teste trebuie să aibă exact același prefix. Pachetul trebuie să conțină două proceduri standard: „utp_setup” și „utp_teardown”. Prima procedură este apelată prin repornirea fiecărui test unitar, a doua - după lansare.
„utp_setup”, de regulă, pregătește sistemul nostru pentru a rula un test unitar, de exemplu, creând date de testare. „utp_teardown” - dimpotrivă, totul revine la setările inițiale și resetează rezultatele lansării.
Iată un exemplu de cel mai simplu test unitar care verifică normalizarea numărului de telefon introdus al clientului la formularul standard pentru sistemul nostru de loialitate. Nu există standarde obligatorii privind modul de scriere a procedurilor cu teste unitare. De regulă, se face apel la o metodă a sistemului testat, iar rezultatul returnat de această metodă este comparat cu cel de referință. Este important ca compararea rezultatului de referință și a celui obținut să aibă loc prin metode utPLSQL standard.
Un test unitar poate avea orice număr de verificări. După cum se poate vedea din exemplu, facem patru apeluri consecutive la metoda testată pentru a normaliza numărul de telefon și a evalua rezultatul după fiecare apel. Când dezvoltați un test unitar, trebuie să țineți cont de faptul că există verificări care nu afectează în niciun fel sistemul, iar după unele trebuie să reveniți la starea inițială a sistemului.
De exemplu, în testul unitar prezentat pur și simplu formatăm numărul de telefon introdus, ceea ce nu afectează în niciun fel sistemul de loialitate.
Și dacă scriem teste unitare folosind metoda creării unui nou client, atunci după fiecare test va fi creat un nou client în sistem, ceea ce poate afecta lansarea ulterioară a testului.
Acesta este modul în care se rulează testele unitare. Există două opțiuni de lansare posibile: rularea tuturor testelor unitare dintr-un anumit pachet sau rularea unui test unitar specific într-un anumit pachet.
Așa arată un exemplu de sistem intern de raportare. Pe baza rezultatelor testului unitar, utPLSQL construiește un mic raport. În el vedem rezultatul fiecărei verificări specifice și rezultatul general al testului unitar.
6 reguli de autotestare
Înainte de a începe crearea unui nou sistem de testare automată a sistemului de loialitate, împreună cu managementul, am stabilit principiile pe care ar trebui să le respecte viitoarele noastre teste automatizate.
- Autotestele trebuie să fie eficiente și trebuie să fie utile. Avem dezvoltatori minunați, care cu siguranță trebuie menționați, pentru că unii dintre ei probabil vor vedea acest raport și scriu cod minunat. Dar chiar și codul lor minunat nu este perfect și are, are și va continua să conțină erori. Sunt necesare teste automate pentru a găsi aceste erori. Dacă nu este cazul, atunci fie scriem autotestări proaste, fie am ajuns într-o zonă moartă care, în principiu, nu este în curs de dezvoltare. În ambele cazuri, facem ceva greșit, iar abordarea noastră pur și simplu nu are sens.
- Ar trebui folosite autotestele. Nu are sens să cheltuiți mult timp și efort pentru a scrie un produs software, să îl puneți într-un depozit și să-l uitați. Testele ar trebui să fie efectuate și efectuate cât mai regulat posibil.
- Autotestele ar trebui să funcționeze stabil. Indiferent de ora din zi, standul de lansare și alte setări ale sistemului, testele ar trebui să conducă la același rezultat. De regulă, acest lucru este asigurat de faptul că autotestele funcționează cu date speciale de testare cu setări fixe ale sistemului.
- Autotestele ar trebui să funcționeze la o viteză acceptabilă pentru proiectul dvs. Acest timp este determinat individual pentru fiecare sistem. Unii oameni își permit să lucreze toată ziua, în timp ce alții consideră că este esențial să o facă în câteva secunde. Vă voi spune puțin mai târziu ce standarde de viteză am atins în proiectul nostru.
- Dezvoltarea autotestului ar trebui să fie flexibilă. Nu este recomandabil să refuzăm să testăm orice funcționalitate pur și simplu pentru că nu am făcut-o înainte sau din alt motiv. utPLSQL nu impune nicio restricție asupra dezvoltării, iar Oracle, în principiu, vă permite să implementați o varietate de lucruri. Majoritatea problemelor au o soluție, este doar o chestiune de timp și efort.
- Posibilitate de implementare. Avem mai multe standuri unde trebuie să facem teste. La fiecare stand, un dump de date poate fi actualizat în orice moment. Este necesar să efectuați un proiect cu teste automate astfel încât să puteți realiza fără durere instalarea completă sau parțială.
Și în a doua postare peste câteva zile vă voi spune ce am făcut și ce rezultate am obținut.
Sursa: www.habr.com