Test unitari in un DBMS: come lo facciamo in Sportmaster, seconda parte

Prima parte - qui.

Immagina una situazione. Ti trovi di fronte al compito di sviluppare nuove funzionalità. Hai esperienza dai tuoi predecessori. Supponendo che tu non abbia obblighi morali, cosa faresti?

Molto spesso, tutti i vecchi sviluppi vengono dimenticati e tutto ricomincia da capo. A nessuno piace scavare nel codice di qualcun altro e, se hai tempo, perché non iniziare a creare il tuo sistema? Questo è un approccio tipico e sotto molti aspetti è corretto. Ma nel nostro progetto abbiamo agito diversamente. Abbiamo basato il futuro sistema di test automatizzato sugli sviluppi degli unit test su utPLSQL dei nostri predecessori, e poi abbiamo lavorato in diverse direzioni parallele.

1. Ripristino dei vecchi test unitari. Recupero significa adattamento dei test allo stato esistente del sistema fedeltà e adattamento dei test agli standard utPLSQL.
2. Risolvendo il problema con la comprensione e cosa esattamente, quali metodi e processi, abbiamo coperto con gli autotest. Devi tenere queste informazioni nella tua testa o trarre conclusioni basate direttamente sul codice degli autotest. Pertanto, abbiamo deciso di creare un catalogo. Abbiamo assegnato un codice mnemonico univoco a ciascun autotest, creato una descrizione e corretto le impostazioni (ad esempio, in quali condizioni dovrebbe essere eseguito o cosa dovrebbe accadere se l'esecuzione del test fallisce). In sostanza, abbiamo compilato i metadati sugli autotest e inserito questi metadati nelle tabelle standard dello schema utPLSQL.
3. Definizione della strategia di espansione, ad es. selezione di funzionalità soggetta a verifica tramite autotest. Abbiamo deciso di prestare attenzione a tre cose: nuovi miglioramenti al sistema, incidenti di produzione e processi chiave del sistema. Pertanto, sviluppiamo parallelamente al rilascio, garantendone la qualità superiore, ampliando contemporaneamente la portata della regressione e garantendo l'affidabilità del sistema nei luoghi critici. Il primo collo di bottiglia è stato il processo di distribuzione degli sconti e dei bonus tramite assegno.
4. Naturalmente abbiamo iniziato a sviluppare nuovi autotest. Uno dei primi compiti di rilascio è stato quello di valutare le prestazioni di campioni predefiniti del sistema fedeltà. Il nostro progetto ha un blocco di query SQL rigidamente fisse che selezionano i clienti in base alle condizioni. Ad esempio, ottieni un elenco di tutti i clienti il ​​cui ultimo acquisto è avvenuto in una determinata città o un elenco di clienti il ​​cui importo medio di acquisto è superiore a un determinato valore. Dopo aver scritto gli autotest, abbiamo controllato campioni predefiniti, fissato parametri prestazionali di benchmark e inoltre abbiamo eseguito test di carico.
5. Lavorare con gli autotest dovrebbe essere conveniente. Le due azioni più comuni sono l'esecuzione di test automatici e la generazione di dati di test. È così che sono comparsi nel nostro sistema due moduli ausiliari: il modulo di lancio e il modulo di generazione dei dati.

   Il programma di avvio è rappresentato come una procedura generica con un parametro di testo di input. Come parametro è possibile passare un codice mnemonico di autotest, un nome di pacchetto, un nome di test, un'impostazione di autotest o una parola chiave riservata. La procedura seleziona ed esegue tutti gli autotest che soddisfano le condizioni.

   Il modulo di generazione dati si presenta come un pacchetto, nel quale per ogni oggetto del sistema in prova (una tabella nel database), è stata creata un'apposita procedura che vi inserisce i dati. In questa procedura, i valori predefiniti vengono riempiti al massimo, il che garantisce la creazione di oggetti letteralmente con un clic di un dito. E per facilità d'uso, sono stati creati modelli per i dati generati. Ad esempio, crea un cliente di una certa età con un telefono di prova e un acquisto completato.

6. Gli autotest dovrebbero essere eseguiti entro un tempo ragionevole per il tuo sistema. Pertanto, è stato organizzato un lancio notturno quotidiano, sulla base dei cui risultati viene generato un rapporto sui risultati e inviato all'intero team di sviluppo tramite posta aziendale. Dopo aver ripristinato i vecchi test automatici e averne creati di nuovi, il tempo di esecuzione totale è stato di 30 minuti. Una performance del genere andava bene a tutti, dato che il lancio è avvenuto fuori orario.

   Ma dovevamo lavorare per ottimizzare la velocità del lavoro. Il sistema di fidelizzazione della produzione viene aggiornato di notte. Come parte di uno dei rilasci, abbiamo dovuto apportare urgentemente modifiche durante la notte. Una mezz'ora di attesa per i risultati degli autotest alle tre del mattino non ha reso felice il responsabile del rilascio (saluti ardenti ad Alexei Vasyukov!), E la mattina dopo sono state dette molte parole affettuose nei confronti del nostro sistema. Di conseguenza, è stato stabilito uno standard di lavoro di 5 minuti.

   Per accelerare le prestazioni, abbiamo utilizzato due metodi: abbiamo iniziato a eseguire gli autotest in tre thread paralleli, poiché questo è molto conveniente data l'architettura del nostro sistema fedeltà. E abbiamo abbandonato l'approccio quando l'autotest non crea dati di test per se stesso, ma cerca di trovare qualcosa di adatto nel sistema. Dopo aver apportato modifiche, il tempo operativo totale è stato ridotto a 3-4 minuti.

7. Un progetto con autotest dovrebbe poter essere distribuito su vari stand. All'inizio del viaggio, ci sono stati tentativi di scrivere i nostri file batch, ma è diventato chiaro che un'installazione automatizzata autoscritta è un completo orrore e ci siamo rivolti a soluzioni industriali. Dato che il progetto contiene molto codice direttamente (prima di tutto, memorizziamo il codice degli autotest) e pochissimi dati (i dati principali sono metadati sugli autotest), si è rivelato molto facile da integrare nel progetto Progetto Liquibase.

   È una libreria indipendente dal database open source per il monitoraggio, la gestione e l'applicazione delle modifiche allo schema del database. Gestito tramite riga di comando o framework come Apache Maven. Il principio di funzionamento di Liquibase è abbastanza semplice. Abbiamo un progetto organizzato in un certo modo, che consiste in modifiche o script che devono essere implementati sul server di destinazione e file di controllo che determinano in quale ordine e con quali parametri tali modifiche devono essere installate.

   A livello DBMS viene creata una tabella speciale in cui Liquibase memorizza il registro di rollback. Ogni modifica ha un hash calcolato che viene confrontato di volta in volta tra il progetto e lo stato nel database. Grazie a Liquibase possiamo facilmente apportare modifiche al nostro sistema a qualsiasi circuito. Gli autotest vengono ora eseguiti sui circuiti di test e rilascio, nonché sui contenitori (circuiti di sviluppo personale).

Quindi, parliamo dei risultati dell'applicazione del nostro sistema di test unitario.

1. Naturalmente, prima di tutto, siamo convinti di aver iniziato a sviluppare software migliore. Gli autotest vengono eseguiti quotidianamente e rilevano dozzine di bug ad ogni rilascio. Inoltre, alcuni di questi errori sono solo indirettamente legati alla funzionalità che volevamo veramente cambiare. Ci sono forti dubbi che questi errori siano stati rilevati mediante test manuali.
2. Il team ha acquisito la certezza che funzionalità specifiche funzionano correttamente... Innanzitutto, ciò riguarda i nostri processi critici. Ad esempio, negli ultimi sei mesi non abbiamo avuto problemi con la distribuzione di sconti e bonus tramite assegno, nonostante le modifiche apportate ad ogni rilascio, sebbene nei periodi precedenti si verificassero errori con una certa frequenza
3. Siamo riusciti a ridurre il numero di iterazioni di test. Dato che gli autotest sono scritti per nuove funzionalità, analisti e tester part-time ottengono un codice di qualità superiore, perché è già stato verificato.
4. Parte degli sviluppi dei test automatizzati viene utilizzata dagli sviluppatori. Ad esempio, i dati di test sui contenitori vengono creati utilizzando il modulo di generazione di oggetti.
5. È importante che abbiamo sviluppato una "accettazione" del sistema di test automatizzato da parte degli sviluppatori. C'è la consapevolezza che questo è importante e utile. E per esperienza personale posso dire che questo è tutt'altro che vero. Gli autotest devono essere scritti, mantenuti e sviluppati, i risultati analizzati e spesso questi costi di tempo semplicemente non valgono la pena. È molto più facile andare in produzione e affrontare i problemi lì. Nel nostro Paese gli sviluppatori si mettono in fila e chiedono di coprire le loro funzionalità con test automatici.

Cosa c'è Next

Parliamo dei piani di sviluppo del progetto di test automatizzati.

Naturalmente, finché il sistema fedeltà Sportmaster è vivo e continua a svilupparsi, anche gli autotest possono essere sviluppati quasi all'infinito. Pertanto, la direzione principale dello sviluppo è l'espansione dell'area di copertura.

Con l'aumento del numero di autotest, il tempo totale del loro lavoro aumenterà costantemente e dovremo tornare nuovamente alla questione delle prestazioni. Molto probabilmente, la soluzione sarà aumentare il numero di thread paralleli.

Ma questi sono modi ovvi di sviluppo. Se parliamo di qualcosa di più non banale, evidenziamo quanto segue:

1. Ora gli autotest sono gestiti a livello DBMS, ovvero per un lavoro di successo è richiesta la conoscenza di PL/SQL. Se necessario, la gestione del sistema (ad esempio, l'avvio o la creazione di metadati) può essere effettuata da una sorta di pannello di amministrazione utilizzando Jenkins o qualcosa di simile.
2. Tutti amano gli indicatori quantitativi e qualitativi. Per i test automatici, un indicatore universale è il Code Coverage o la metrica di copertura del codice. Utilizzando questo indicatore, possiamo determinare quale percentuale del codice del nostro sistema in prova è coperta da autotest. A partire dalla versione 12.2, Oracle offre la possibilità di calcolare questa metrica e suggerisce di utilizzare il pacchetto standard DBMS_PLSQL_CODE_COVERAGE.

   Il nostro sistema di autotest ha poco più di un anno e potrebbe essere il momento di valutare la copertura. Nel mio ultimo progetto (un progetto non di Sportmaster), è successo questo. Un anno dopo aver lavorato sugli autotest, la direzione si è posta il compito di valutare quale percentuale del codice abbiamo coperto. Con una copertura superiore all’1%, la direzione sarebbe felice. Noi sviluppatori ci aspettavamo un risultato di circa il 10%. Abbiamo sbagliato la copertura del codice, l'abbiamo misurata e abbiamo ottenuto il 20%. Per festeggiare, siamo andati a prendere il premio, ma il modo in cui lo abbiamo ottenuto e dove siamo andati dopo è una storia completamente diversa.

3. Gli autotest possono testare i servizi Web esposti. Oracle ti consente di farlo e non incontreremo più numerosi problemi.
4. E, naturalmente, il nostro sistema di test automatizzato può essere applicato a un altro progetto. La soluzione che abbiamo ricevuto è universale e richiede solo l'utilizzo di Oracle. Ho sentito che c'è interesse per i test automatizzati su altri progetti Sportmaster e, forse, ci rivolgeremo a loro.

risultati

Ricapitoliamo. Nel progetto del sistema fedeltà in Sportmaster, siamo riusciti a implementare un sistema di test automatizzato. La sua base è la soluzione utPLSQL di Stephen Feuerstein. Intorno a utPLSQL c'è il codice per gli autotest e i moduli ausiliari autoprodotti: un launcher, un modulo di generazione dati e altri. Gli autotest vengono eseguiti quotidianamente e, soprattutto, funzionano e apportano benefici. Siamo convinti di aver iniziato a rilasciare software di qualità superiore. Allo stesso tempo, la soluzione risultante è universale e può essere liberamente applicata a qualsiasi progetto in cui sia necessario organizzare test automatizzati sul DBMS Oracle.

PS Questo articolo si è rivelato poco specifico: c'è molto testo e praticamente nessun esempio tecnico. Se l'argomento è interessante a livello globale, siamo pronti a continuarlo e tornare con una continuazione, dove vi diremo cosa è cambiato negli ultimi sei mesi e forniremo esempi di codice.

Scrivi commenti se ci sono punti che dovrebbero essere enfatizzati in futuro o domande che richiedono divulgazione.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Vogliamo scrivere di più a riguardo?

• Sì, certo

• No grazie

12 utenti hanno votato. 4 utenti si sono astenuti.

Fonte: habr.com