Ehi Habr!
Mi chiamo Maxim Ponomarenko e sono uno sviluppatore presso Sportmaster. Ho 10 anni di esperienza nel settore informatico. Ha iniziato la sua carriera nel testing manuale, per poi passare allo sviluppo di database. Negli ultimi 4 anni, accumulando le conoscenze acquisite nei test e nello sviluppo, ho automatizzato i test a livello DBMS.
Faccio parte del team Sportmaster da poco più di un anno e sto sviluppando test automatizzati su uno dei progetti più importanti. Ad aprile, io e i ragazzi di Sportmaster Lab abbiamo parlato a una conferenza a Krasnodar, il mio rapporto si chiamava "Test unitari in un DBMS" e ora voglio condividerlo con voi. Ci sarà molto testo, quindi ho deciso di dividere il rapporto in due post. Nella prima parleremo di autotest e test in generale, nella seconda mi soffermerò più in dettaglio sul nostro sistema di unit test e sui risultati della sua applicazione.
Innanzitutto, una piccola teoria noiosa. Cos'è il test automatizzato? Si tratta di test eseguiti utilizzando software e nell'IT moderno vengono sempre più utilizzati nello sviluppo di software. Ciò è dovuto al fatto che le aziende crescono, i loro sistemi informativi crescono e, di conseguenza, cresce la quantità di funzionalità da testare. L'esecuzione di test manuali sta diventando sempre più costosa.
Ho lavorato per una grande azienda le cui uscite escono ogni due mesi. Allo stesso tempo, è stato impiegato un mese intero per far verificare manualmente la funzionalità da una dozzina di tester. Grazie all'implementazione dell'automazione da parte di un piccolo team di sviluppatori, siamo riusciti a ridurre i tempi di test a 2 settimane in un anno e mezzo. Non solo abbiamo aumentato la velocità dei test, ma ne abbiamo anche migliorato la qualità. I test automatizzati vengono lanciati regolarmente ed eseguono sempre l'intero ciclo di controlli in essi previsto, ovvero escludiamo il fattore umano.
L'IT moderno è caratterizzato dal fatto che a uno sviluppatore può essere richiesto non solo di scrivere il codice del prodotto, ma anche di scrivere test unitari che controllano questo codice.
Ma cosa succede se il tuo sistema si basa principalmente sulla logica del server? Non esiste una soluzione universale o migliori pratiche sul mercato. Di norma, le aziende risolvono questo problema creando il proprio sistema di test autoscritto. Questo è il nostro sistema di test automatizzato autoprodotto che è stato creato sul nostro progetto e ne parlerò nel mio rapporto.
Testare la lealtà
Innanzitutto, parliamo del progetto in cui abbiamo implementato un sistema di test automatizzato. Il nostro progetto è il sistema fedeltà Sportmaster (a proposito, ne abbiamo già parlato in ).
Se la tua azienda è abbastanza grande, il tuo sistema fedeltà avrà tre proprietà standard:
- Il tuo sistema sarà molto caricato
- Il tuo sistema conterrà processi informatici complessi
- Il tuo sistema verrà migliorato attivamente.
Andiamo con ordine... In totale, se consideriamo tutti i marchi Sportmaster, abbiamo più di 1000 negozi in Russia, Ucraina, Cina, Kazakistan e Bielorussia. Ogni giorno in questi negozi vengono effettuati circa 300 acquisti. Cioè, ogni secondo 000-3 controlli entrano nel nostro sistema. Naturalmente, il nostro sistema fedeltà è molto carico. E poiché viene utilizzato attivamente, dobbiamo fornire i più alti standard di qualità, perché qualsiasi errore nel software significa grandi perdite monetarie, reputazionali e di altro tipo.
Allo stesso tempo, Sportmaster gestisce più di cento promozioni diverse. Le promozioni sono diverse: ci sono le promozioni sui prodotti, ci sono quelle dedicate al giorno della settimana, ci sono quelle legate ad un punto vendita specifico, ci sono le promozioni sull'importo dello scontrino, ci sono le promozioni sulla quantità di merce. In generale, non male. I clienti hanno bonus e codici promozionali che vengono utilizzati quando effettuano acquisti. Tutto ciò porta al fatto che il calcolo di qualsiasi ordine è un compito molto non banale.
L'algoritmo che implementa l'elaborazione degli ordini è davvero terribile e complicato. E qualsiasi modifica a questo algoritmo è piuttosto rischiosa. Sembrava che i cambiamenti apparentemente più insignificanti potessero portare a effetti del tutto imprevedibili. Ma sono proprio questi processi informatici complessi, soprattutto quelli che implementano funzionalità critiche, a essere i migliori candidati per l’automazione. Controllare manualmente decine di casi simili richiede molto tempo. E poiché il punto di ingresso nel processo è invariato, dopo averlo descritto una volta, puoi creare rapidamente test automatici ed essere sicuro che la funzionalità funzionerà.
Poiché il nostro sistema viene utilizzato attivamente, l'azienda vorrà qualcosa di nuovo da te, sarà al passo con i tempi e sarà orientata al cliente. Nel nostro sistema fedeltà, i comunicati escono ogni due mesi. Ciò significa che ogni due mesi dobbiamo effettuare una regressione completa dell’intero sistema. Allo stesso tempo, naturalmente, come in ogni IT moderno, lo sviluppo non passa immediatamente dallo sviluppatore alla produzione. Ha origine nel circuito dello sviluppatore, poi successivamente passa per il banco prova, il rilascio, l’accettazione e solo successivamente finisce in produzione. Come minimo, sui circuiti di test e rilascio, dobbiamo effettuare una regressione completa dell'intero sistema.
Le proprietà descritte sono standard per quasi tutti i sistemi fedeltà. Parliamo delle caratteristiche del nostro progetto.
Tecnologicamente il 90% della logica del nostro sistema di fidelizzazione è basata su server e implementata su Oracle. Esiste un client esposto in Delphi, che svolge la funzione di amministratore del posto di lavoro automatizzato. Sono presenti servizi web esposti per applicazioni esterne (ad esempio un sito web). Pertanto, è molto logico che se implementiamo un sistema di test automatizzato, lo faremo su Oracle.
Il sistema fedeltà in Sportmaster esiste da più di 7 anni ed è stato creato da singoli sviluppatori... Il numero medio di sviluppatori del nostro progetto durante questi 7 anni era di 3-4 persone. Ma nell’ultimo anno, il nostro team è cresciuto in modo significativo e ora ci sono 10 persone che lavorano al progetto. Cioè, le persone vengono al progetto che non hanno familiarità con le attività, i processi e l'architettura tipici. E aumenta il rischio di non commettere errori.
Il progetto è caratterizzato dall'assenza di tester dedicati come unità di staff. Naturalmente esistono dei test, ma i test vengono eseguiti dagli analisti, oltre alle loro altre responsabilità principali: comunicare con i clienti aziendali, gli utenti, sviluppare i requisiti di sistema, ecc. eccetera... Nonostante il fatto che i test vengano eseguiti di altissima qualità (questo è particolarmente opportuno menzionarlo, poiché alcuni analisti potrebbero attirare l'attenzione di questo rapporto), l'efficacia della specializzazione e della concentrazione su una cosa non è stata annullata .
Considerando tutto quanto sopra, per migliorare la qualità del prodotto consegnato e ridurre i tempi di sviluppo, l'idea di automatizzare i test su un progetto sembra molto logica. E nelle diverse fasi dell’esistenza del sistema fedeltà, i singoli sviluppatori si sono sforzati di coprire il proprio codice con test unitari. Nel complesso è stato un processo abbastanza sconnesso, in cui ognuno ha utilizzato la propria architettura e i propri metodi. I risultati finali erano comuni agli unit test: i test venivano sviluppati, utilizzati per un certo periodo, archiviati in un archivio di file con versione, ma a un certo punto smettevano di funzionare e venivano dimenticati. Ciò era dovuto innanzitutto al fatto che le prove erano legate più a un artista specifico e non al progetto.
utPLSQL viene in soccorso
Sai qualcosa di Stephen Feuerstein?
Si tratta di un ragazzo intelligente che ha dedicato gran parte della sua carriera a lavorare con Oracle e PL/SQL e ha scritto un gran numero di lavori su questo argomento. Uno dei suoi famosi libri si intitola: “Oracle PL/SQL. Per i professionisti." È stato Stephen a sviluppare la soluzione utPLSQL o, come sta per, framework Unit Testing per Oracle PL/SQL. La soluzione utPLSQL è stata creata nel 2016, ma si continua a lavorarci attivamente e vengono rilasciate nuove versioni. Al momento della segnalazione, l’ultima versione risale al 24 marzo 2019.
Che cos'è. Questo è un progetto open source separato. Pesa un paio di megabyte, inclusi esempi e documentazione. Fisicamente, è uno schema separato nel database ORACLE con una serie di pacchetti e tabelle per organizzare gli unit test. L'installazione richiede alcuni secondi. Una caratteristica distintiva di utPLSQL è la sua facilità d'uso.
Globalmente, utPLSQL è un meccanismo per l'esecuzione di unit test, dove per unit test si intendono le normali procedure batch Oracle, la cui organizzazione segue determinate regole. Oltre al lancio, utPLSQL memorizza un registro di tutte le esecuzioni dei test e dispone anche di un sistema di reporting interno.
Diamo un'occhiata ad un esempio di come appare il codice dello unit test, implementato utilizzando questa tecnica.
Quindi, lo schermo mostra il codice per una tipica specifica del pacchetto con test unitari. Quali sono i requisiti obbligatori? Il pacchetto deve avere il prefisso "utp_". Tutte le procedure con test devono avere esattamente lo stesso prefisso. Il pacchetto deve contenere due procedure standard: “utp_setup” e “utp_teardown”. La prima procedura viene richiamata riavviando ciascun test unitario, la seconda dopo il lancio.
"utp_setup", di norma, prepara il nostro sistema per eseguire un test unitario, ad esempio creando dati di test. "utp_teardown" - al contrario, tutto ritorna alle impostazioni originali e ripristina i risultati del lancio.
Ecco un esempio dello unit test più semplice che verifica la normalizzazione del numero di telefono del cliente inserito nel modulo standard per il nostro sistema fedeltà. Non esistono standard obbligatori su come scrivere procedure con test unitari. Di norma viene effettuata una chiamata ad un metodo del sistema in prova e il risultato restituito da questo metodo viene confrontato con quello di riferimento. È importante che il confronto tra il risultato di riferimento e quello ottenuto avvenga tramite metodi utPLSQL standard.
Un test unitario può avere un numero qualsiasi di controlli. Come si può vedere dall'esempio, effettuiamo quattro chiamate consecutive al metodo testato per normalizzare il numero di telefono e valutare il risultato dopo ogni chiamata. Quando si sviluppa uno unit test, è necessario tenere conto del fatto che esistono controlli che non influiscono in alcun modo sul sistema e dopo alcuni è necessario ripristinare lo stato originale del sistema.
Ad esempio, nello unit test presentato formattiamo semplicemente il numero di telefono immesso, il che non influisce in alcun modo sul sistema fedeltà.
E se scriviamo unit test utilizzando il metodo di creazione di un nuovo client, dopo ogni test verrà creato un nuovo client nel sistema, il che può influire sul successivo avvio del test.
Ecco come vengono eseguiti i test unitari. Sono disponibili due opzioni di avvio: eseguire tutti gli unit test da un pacchetto specifico o eseguire uno unit test specifico in un pacchetto specifico.
Ecco come appare un esempio di sistema di reporting interno. Sulla base dei risultati dello unit test, utPLSQL crea un piccolo report. In esso vediamo il risultato di ogni controllo specifico e il risultato complessivo del test unitario.
6 regole degli autotest
Prima di iniziare a creare un nuovo sistema per il test automatizzato del sistema fedeltà, insieme al management, abbiamo determinato i principi a cui dovranno conformarsi i nostri futuri test automatizzati.
- Gli autotest devono essere efficaci e devono essere utili. Abbiamo sviluppatori meravigliosi, che meritano sicuramente di essere menzionati, perché alcuni di loro probabilmente vedranno questo rapporto e scrivono codice meraviglioso. Ma anche il loro meraviglioso codice non è perfetto e contiene, contiene e continuerà a contenere errori. Per individuare questi errori sono necessari gli autotest. Se così non è, allora o stiamo scrivendo autotest errati o siamo arrivati a un'area morta che, in linea di principio, non è in fase di sviluppo. In entrambi i casi stiamo facendo qualcosa di sbagliato e il nostro approccio semplicemente non ha senso.
- Dovrebbero essere utilizzati gli autotest. Non ha senso dedicare molto tempo e sforzi alla scrittura di un prodotto software, inserirlo in un repository e dimenticarlo. I test dovrebbero essere eseguiti il più regolarmente possibile.
- Gli autotest dovrebbero funzionare stabilmente. Indipendentemente dall'ora del giorno, dalla posizione di lancio e da altre impostazioni di sistema, i test dovrebbero portare allo stesso risultato. Di norma, ciò è garantito dal fatto che gli autotest funzionano con dati di test speciali con impostazioni di sistema fisse.
- Gli autotest dovrebbero funzionare a una velocità accettabile per il tuo progetto. Questa volta è determinata individualmente per ciascun sistema. Alcune persone possono permettersi di lavorare tutto il giorno, mentre altri trovano fondamentale farlo in pochi secondi. Ti dirò poco dopo quali standard di velocità abbiamo raggiunto nel nostro progetto.
- Lo sviluppo degli autotest dovrebbe essere flessibile. Non è consigliabile rifiutarsi di testare qualsiasi funzionalità semplicemente perché non l'abbiamo fatto prima o per qualche altro motivo. utPLSQL non impone alcuna restrizione allo sviluppo e Oracle, in linea di principio, consente di implementare una varietà di cose. La maggior parte dei problemi ha una soluzione, è solo questione di tempo e impegno.
- Distribuibilità. Abbiamo diversi stand dove dobbiamo eseguire i test. Presso ogni stand è possibile aggiornare in ogni momento un data dump. È necessario condurre un progetto con test automatici in modo tale da poter eseguire senza problemi l'installazione totale o parziale.
E nel secondo post tra un paio di giorni vi racconterò cosa abbiamo fatto e quali risultati abbiamo ottenuto.
Fonte: habr.com