Ehi Habr!
Mi chjamu Maxim Ponomarenko è sò un sviluppatore in Sportmaster. Aghju 10 anni di sperienza in u campu di l'IT. Cuminciò a so carriera in a prova manuale, dopu hà cambiatu à u sviluppu di basa di dati. Per l'ultimi anni 4, accumulendu a cunniscenza acquistata in teste è sviluppu, aghju automatizatu e teste à u livellu DBMS.
Sò in a squadra di Sportmaster per pocu più di un annu è sò sviluppatu teste automatizati nantu à unu di i prughjetti maiò. In April, i ragazzi di Sportmaster Lab è aghju parlatu in una cunferenza in Krasnodar, u mo rapportu era chjamatu "Test di unità in un DBMS", è avà vogliu sparte cun voi. Ci sarà assai testu, cusì aghju decisu di sparte u rapportu in dui posti. In u primu, parlemu di l'autotests è di e teste in generale, è in u sicondu, vi aspittàvanu in più di dettu nantu à u nostru sistema di teste di unità è i risultati di a so applicazione.
Prima, una teoria pocu noiosa. Cosa hè a prova automatizata? Questa hè una prova chì hè realizata cù u software, è in l'informatica moderna hè sempre più utilizata in u sviluppu di software. Questu hè duvuta à u fattu chì l'imprese crescenu, i so sistemi d'informazioni sò in crescita è, per quessa, a quantità di funziunalità chì deve esse pruvata hè crescente. A realizazione di teste manuali diventa sempre più caru.
Aghju travagliatu per una grande sucietà chì e so liberazioni esce ogni dui mesi. À u listessu tempu, un mese sanu hè statu passatu per avè una decina di teste di verificazione manualmente a funziunalità. Grazie à l'implementazione di l'automatizazione da una piccula squadra di sviluppatori, pudemu riduce u tempu di prova à 2 settimane in un annu è mezu. Ùn avemu micca solu aumentatu a velocità di teste, ma ancu migliurà a so qualità. I testi automatizati sò lanciati regularmente è sempre realizanu tuttu u cursu di cuntrolli inclusi in elli, vale à dì, escludemu u fattore umanu.
L'IT mudernu hè carattarizatu da u fattu chì un sviluppatore pò esse dumandatu micca solu per scrive u codice di u produttu, ma ancu per scrive teste di unità chì verificanu stu codice.
Ma chì se u vostru sistema hè basatu principarmenti nantu à a logica di u servitore? Ùn ci hè micca una soluzione universale o pratiche megliu nantu à u mercatu. In regula, l'imprese risolve stu prublema creendu u so propiu sistema di test auto-scrittu. Questu hè u nostru propiu sistema di teste automatizatu chì hè statu creatu nantu à u nostru prughjettu è ne parleraghju in u mo rapportu.
Testa a fideltà
Prima, parlemu di u prugettu induve avemu implementatu un sistema di teste automatizatu. U nostru prughjettu hè u sistema di fidelizazione Sportmaster (per via, avemu digià scrittu annantu à questu ).
Se a vostra cumpagnia hè abbastanza grande, allora u vostru sistema di lealtà averà trè proprietà standard:
- U vostru sistema serà assai carica
- U vostru sistema cuntene prucessi di computing cumplessi
- U vostru sistema serà attivamente migliuratu.
Andemu in ordine... In tuttu, se cunsideremu tutte e marche Sportmaster, allora avemu più di 1000 magazzini in Russia, Ucraina, Cina, Kazakistan è Bielorussia. Circa 300 000 acquisti sò fatti in questi magazzini ogni ghjornu. Vale à dì, ogni secondu 3-4 cuntrolli entra in u nostru sistema. Naturalmente, u nostru sistema di fidelizazione hè assai carica. E postu chì hè attivamente utilizatu, avemu da furnisce i più alti standard di a so qualità, perchè ogni errore in u software significa grandi perditi monetari, reputazionali è altri.
À u listessu tempu, Sportmaster gestisce più di un centu di prumuzioni diffirenti. Ci hè una varietà di prumuzioni: ci sò prumuzioni di prudutti, ci sò quelli dedicati à u ghjornu di a settimana, ci sò quelli ligati à una tenda specifica, ci sò prumuzioni per a quantità di u ricivutu, ci sò per u numeru di merchenzie. In generale, micca male. I clienti anu bonus è codici promozionali chì sò usati quandu facenu compra. Tuttu chistu porta à u fattu chì u calculu di ogni ordine hè un compitu assai micca trivial.
L'algoritmu chì implementa a trasfurmazioni di l'ordine hè veramente terribili è complicatu. È ogni cambiamentu di stu algoritmu hè abbastanza risicatu. Paria chì i cambiamenti più apparentemente insignificanti puderanu purtà à effetti abbastanza imprevisible. Ma sò precisamente tali prucessi di computing cumplessi, in particulare quelli chì implementanu funziunalità critica, chì sò i migliori candidati per l'automatizazione. Cuntrollà decine di casi simili manualmente richiede assai tempu. E postu chì u puntu di entrata in u prucessu ùn hè micca cambiatu, avè descrittu una volta, pudete creà rapidamente teste automatiche è esse cunfidenti chì a funziunalità hà da travaglià.
Siccomu u nostru sistema hè attivamente utilizatu, l'affari vulerà qualcosa di novu da voi, vive cù i tempi è esse orientatu à u cliente. In u nostru sistema di lealtà, e versioni surtenu ogni dui mesi. Questu significa chì ogni dui mesi avemu bisognu di fà una regressione cumpleta di tuttu u sistema. À u listessu tempu, naturalmente, cum'è in ogni IT mudernu, u sviluppu ùn passa micca immediatamente da u sviluppatore à a produzzione. Hè urigginatu nantu à u circuitu di u sviluppatore, poi passa successivamente à u bancu di prova, liberazione, accettazione, è solu dopu finisce in a produzzione. À u minimu, nantu à i circuiti di prova è di liberazione, avemu bisognu di fà una regressione cumpleta di tuttu u sistema.
E proprietà descritte sò standard per quasi ogni sistema di fidelizazione. Parlemu di e caratteristiche di u nostru prughjettu.
Tecnologicamente, 90% di a logica di u nostru sistema di fidelizazione hè basatu in u servitore è implementatu in Oracle. Ci hè un cliente espostu in Delphi, chì eseguisce a funzione di un amministratore di u locu di travagliu automatizatu. Ci sò servizii web esposti per applicazioni esterne (per esempiu un situ web). Dunque, hè assai logicu chì se implementemu un sistema di teste automatizatu, a faremu nantu à Oracle.
U sistema di lealtà in Sportmaster esiste per più di 7 anni è hè statu creatu da sviluppatori unichi... U numaru mediu di sviluppatori nantu à u nostru prughjettu durante questi anni 7 era 3-4 persone. Ma annantu à l'annu passatu, a nostra squadra hà crisciutu significativamente, è avà ci sò 10 persone chì travaglianu in u prugettu. Vale à dì, e persone venenu à u prugettu chì ùn sò micca familiarizati cù i travaglii tipici, i prucessi è l'architettura. È ci hè un risicu aumentatu chì avemu mancatu i sbagli.
U prughjettu hè carattarizatu da l'absenza di teste dedicati cum'è unità di staff. Ci hè, sicuru, a prova, ma a prova hè realizata da l'analista, in più di e so altre rispunsabilità principali: cumunicazione cù i clienti di l'affari, l'utilizatori, u sviluppu di i bisogni di u sistema, etc. etc... Malgradu u fattu chì a prova hè realizata di qualità assai alta (questu hè soprattuttu apprupriatu à mencionà, postu chì certi analisti ponu catturà l'ochju di stu rapportu), l'efficacità di a specializazione è a cuncentrazione nantu à una cosa ùn hè micca stata annullata. .
In cunsiderà tuttu ciò chì sopra, per migliurà a qualità di u pruduttu furnitu è riduce u tempu di sviluppu, l'idea di automatizà a prova nantu à un prughjettu pare assai logica. È in diverse tappe di l'esistenza di u sistema di fideltà, i sviluppatori individuali anu fattu sforzi per copre u so codice cù teste di unità. In generale, era un prucessu abbastanza disjointed, cù tutti chì utilizanu a so propria architettura è metudi. I risultati finali eranu cumunu à e teste di unità: i testi sò stati sviluppati, utilizati per qualchì tempu, almacenati in un archiviu di file versioned, ma à un certu puntu anu cessatu di correre è sò stati scurdati. Prima di tuttu, questu era duvuta à u fattu chì e teste sò più ligati à un esecutore specificu, è micca à u prugettu.
utPLSQL vene in salvezza
Sapete qualcosa di Stephen Feuerstein ?
Questu hè un omu intelligente chì hà dedicatu una longa parte di a so carriera à travaglià cù Oracle è PL / SQL, è hà scrittu un gran numaru di travaglii nantu à questu tema. Unu di i so libri famosi hè chjamatu: "Oracle PL/SQL. Per i prufessiunali". Era Stephen chì hà sviluppatu a suluzione utPLSQL, o, cum'è significa, un framework di Testing Unitu per Oracle PL / SQL. A suluzione utPLSQL hè stata creata in 2016, ma cuntinueghja à esse attivamente travagliatu è novi versioni sò liberati. À u mumentu di a rappurtazione, l'ultima versione data di u 24 di marzu di u 2019.
Chi hè què. Questu hè un prughjettu open source separatu. Pesa un paru di megabytes, cumpresi esempi è documentazione. Fisicamente, hè un schema separatu in a basa di dati ORACLE cù un inseme di pacchetti è tavule per urganizà teste di unità. A stallazione dura uni pochi di seconde. Una caratteristica distintiva di utPLSQL hè a so facilità d'utilizazione.
In u mondu, utPLSQL hè un mecanismu per eseguisce teste di unità, induve una prova di unità hè intesa cum'è prucedure ordinarie di batch Oracle, l'urganizazione di quale seguita certu regule. In più di u lanciamentu, utPLSQL guarda un logu di tutti i vostri test runs, è hà ancu un sistema di rapportu internu.
Fighjemu un esempiu di ciò chì u codice di prova di unità pari, implementatu cù sta tecnica.
Dunque, a pantalla mostra u codice per una specificazione tipica di u pacchettu cù teste di unità. Chì sò i requisiti obligatorii? U pacchettu deve esse prefissatu cù "utp_". Tutte e prucedure cù testi deve avè esattamente u listessu prefissu. U pacchettu deve cuntene duie prucedure standard: "utp_setup" è "utp_teardown". A prima prucedura hè chjamata da riavvia ogni prova unità, u sicondu - dopu à u lanciu.
"utp_setup", in regula, prepara u nostru sistema per eseguisce una prova di unità, per esempiu, creendu dati di prova. "utp_teardown" - à u cuntrariu, tuttu torna à i paràmetri originali è resetta i risultati di lanciamentu.
Eccu un esempiu di a prova di unità più simplice chì verifica a normalizazione di u numeru di telefunu di u cliente inseritu à a forma standard per u nostru sistema di fidelizazione. Ùn ci hè micca standard obligatoriu nantu à cumu scrive prucedure cù teste di unità. Comu regula, una chjama hè fatta à un metudu di u sistema sottu à a prova, è u risultatu restituitu da stu metudu hè paragunatu cù u riferimentu. Hè impurtante chì a comparazione di u risultatu di riferimentu è l'ottenutu si faci cù i metudi standard utPLSQL.
Un test di unità pò avè qualchì numeru di cuntrolli. Comu pò esse vistu da l'esempiu, facemu quattru chjama consecutivi à u metudu pruvatu per nurmalizà u numeru di telefunu è evaluà u risultatu dopu ogni chjama. Quandu si sviluppa una prova di unità, deve piglià in contu chì ci sò cuntrolli chì ùn anu micca affettatu u sistema in ogni modu, è dopu à qualchì avete bisognu di rinvià à u statu originale di u sistema.
Per esempiu, in a prova di unità presentata, simpricimenti furmatemu u numeru di telefunu di input, chì ùn affetta micca u sistema di fideltà in ogni modu.
È s'è scrivimu testi unità cù u metudu di creà un novu cliente, dopu à ogni prova, un novu cliente serà creatu in u sistema, chì pò influenzà u prossimu lanciu di a prova.
Hè cusì chì e teste di unità sò eseguite. Ci hè duie opzioni di lanciamentu pussibuli: eseguisce tutte e teste di unità da un pacchettu specificu o esegue una prova di unità specifica in un pacchettu specificu.
Questu hè un esempiu di un sistema di rapportu internu. Basatu nantu à i risultati di a prova di unità, utPLSQL crea un picculu rapportu. In questu vedemu u risultatu per ogni cuntrollu specificu è u risultatu generale di a prova unità.
6 regule di l'autotest
Prima di cumincià à creà un novu sistema per a prova automatizata di u sistema di lealtà, inseme cù a gestione, avemu determinatu i principii chì i nostri futuri testi automatizati duveranu rispettà.
- L'autotest deve esse efficace è deve esse utile. Avemu sviluppatori meravigliosi, chì certamenti ci vole à esse citati, perchè alcuni di elli probabilmente vederanu stu rapportu, è scrivenu un codice maravigliu. Ma ancu u so codice maravigghiusu ùn hè micca perfettu è hà, hà, è continuarà à cuntene errori. L'autotest hè necessariu per truvà questi errori. S'ellu ùn hè micca u casu, allora o scrivimu cattivi autotests, o avemu ghjuntu à una zona morta chì, in principiu, ùn hè micca sviluppatu. In i dui casi, facemu qualcosa di male, è u nostru approcciu simpricimenti ùn hà micca sensu.
- L'autotest deve esse usatu. Ùn hà micca sensu di passà assai tempu è sforzu à scrive un pruduttu software, mette in un repository è scurdate. I testi duveranu esse eseguiti, è eseguite u più regularmente pussibule.
- L'autotest deve travaglià stabile. Indipendentemente da l'ora di u ghjornu, u stand di lanciamentu è l'altri paràmetri di u sistema, i prucessi di prova duveranu purtà à u listessu risultatu. In regula, questu hè assicuratu da u fattu chì l'autotests travaglianu cù dati di teste speciale cù paràmetri di sistema fissi.
- L'autotest deve travaglià à una velocità accettabile per u vostru prughjettu. Stu tempu hè determinatu individualmente per ogni sistema. Qualchidunu pò permette di travaglià tuttu u ghjornu, mentri àutri trovanu criticu per fà in seconde. Vi dicu un pocu dopu chì standard di velocità avemu ottinutu in u nostru prughjettu.
- U sviluppu di l'autotest deve esse flexible. Ùn hè cunsigliatu di ricusà di pruvà qualsiasi funziunalità solu perchè ùn avemu micca fattu prima o per qualchì altra ragione. utPLSQL ùn impone micca restrizioni à u sviluppu, è Oracle, in principiu, permette di implementà una varietà di cose. A maiò parte di i prublemi anu una suluzione, hè solu questione di tempu è sforzu.
- Impiegabilità. Avemu parechji stand induve avemu bisognu di eseguisce testi. In ogni stand, un dump di dati pò esse aghjurnatu in ogni mumentu. Hè necessariu di realizà un prughjettu cù teste automatiche in tale manera chì pudete fà senza dolore a so stallazione completa o parziale.
È in u sicondu postu in un paru di ghjorni vi dicu ciò chì avemu fattu è chì risultati avemu ottenutu.
Source: www.habr.com