{"id":37666,"date":"2019-10-31T22:18:55","date_gmt":"2019-10-31T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya\/"},"modified":"2019-10-31T22:18:55","modified_gmt":"2019-10-31T19:18:55","slug":"unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/unit-testy-v-subd-kak-my-delaem-eto-v-sportmastere-chast-vtoraya","title":{"rendered":"Unit test nei DBMS - come lo facciamo noi in Sportmaster, parte seconda","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Parte prima - qui<\/a><\/noindex>.<\/i><\/p>\n

\"Unit<\/a><\/noindex><\/p>\n

Immaginate la situazione. Avete il compito di sviluppare una nuova funzionalit\u00e0. Avete a disposizione lavori precedenti dai vostri predecessori. Se consideriamo che non avete alcun obbligo morale, come vi comportereste?<\/p>\n

Nella maggior parte dei casi, tutti i passati lavori vengono dimenticati e si riparte da zero. Nessuno ama spulciare il codice di qualcun altro, e se ci si trova davanti a del tempo, perch\u00e9 non dedicarsi alla creazione di un proprio sistema? Questo \u00e8 un approccio tipico, e in gran parte corretto. Ma nel nostro progetto non abbiamo proceduto in questo modo. Abbiamo basato il futuro sistema di test automatici sulle esperienze di unit test su utPLSQL dei nostri predecessori, per poi lavorare in diverse direzioni parallele.
\n<\/a><\/noindex><\/p>\n

    \n
  1. Ripristino dei vecchi unit test.<\/b> Per ripristino si intende l'adattamento dei test allo stato attuale del sistema di loyalty e l'adattamento dei test agli standard utPLSQL. <\/li>\n
  2. Risolvere il problema della comprensione di quali metodi e processi siano coperti dai test automatici. <\/b>Bisogna tenere queste informazioni a mente o trarre conclusioni direttamente dal codice dei test automatici. Pertanto, abbiamo deciso di formare un catalogo. Ad ogni test automatico abbiamo assegnato un codice mnemonico unico, abbiamo creato una descrizione e registrato le impostazioni (ad esempio, in quali condizioni deve essere eseguito o cosa deve succedere se il test fallisce). In sostanza, abbiamo riempito i metadati sui test automatici e inserito questi metadati nelle tabelle standard dello schema utPLSQL.<\/li>\n
  3. Definizione della strategia di ampliamento, ovvero selezione delle funzionalit\u00e0 da verificare con i test automatici.<\/b> Abbiamo deciso di prestare attenzione a tre aspetti: nuove implementazioni del sistema, incidenti dalla produzione e processi chiave del sistema. In questo modo ci sviluppiamo parallelamente al rilascio, garantendo una qualit\u00e0 superiore e ampliando nel contempo l'area di regressione, assicurando la stabilit\u00e0 del sistema nei punti critici. La prima di queste strozzature \u00e8 stata il processo di distribuzione di sconti e bonus nel pagamento.<\/li>\n
  4. Naturalmente, ci siamo messi al lavoro sulla creazione di nuovi test automatici. <\/b>Uno dei primi compiti di rilascio \u00e8 stata la valutazione delle prestazioni dei campioni predefiniti del sistema di fidelizzazione. Nel nostro progetto, abbiamo un blocco di query SQL fissate, che selezionano i clienti in base a determinati criteri. Ad esempio, ottenere un elenco di tutti i clienti la cui ultima acquisto \u00e8 avvenuto in una citt\u00e0 specifica, o un elenco di clienti la cui spesa media supera un valore definito. Scrivendo dei test automatici, abbiamo verificato i campioni predefiniti, registrato i parametri di riferimento delle prestazioni e, in aggiunta, abbiamo introdotto il testing di carico.<\/li>\n
  5. Lavorare con i test automatici deve essere comodo<\/b>. Le due azioni pi\u00f9 comuni sono: avvio dei test automatici e creazione di dati di test. Cos\u00ec, nel nostro sistema sono stati creati due moduli di supporto: un modulo di avvio e un modulo di generazione dati.\n

    Il modulo di avvio \u00e8 presentato come una singola procedura universale con un unico parametro di input testuale. Come parametro, si pu\u00f2 passare il mnemonico del test automatico, il nome del pacchetto, il nome del test, le impostazioni del test automatico o una parola chiave riservata. La procedura seleziona e avvia tutti i test automatici che soddisfano le condizioni.<\/p>\n

    Il modulo di generazione dati \u00e8 presentato come un pacchetto, in cui per ogni oggetto del sistema sottoposto a test (tabella nel DB), \u00e8 stata creata una procedura speciale che inserisce dati. In questa procedura, i valori predefiniti sono riempiti al massimo, garantendo la creazione di oggetti in un attimo. E per comodit\u00e0 d'uso sono stati creati modelli di dati da generare. Ad esempio, creare un cliente di una certa et\u00e0 con un telefono di prova e un acquisto effettuato.<\/li>\n

  6. I test automatici devono avviarsi e funzionare in un tempo accettabile per il tuo sistema. <\/b>Pertanto, \u00e8 stato organizzato un avvio notturno giornaliero, i cui risultati generano un rapporto sulle prestazioni e viene inviato a tutto il team di sviluppo via e-mail aziendale. Dopo il ripristino dei vecchi test automatici e la creazione di nuovi, il tempo totale di esecuzione era di 30 minuti. Questa prestazione soddisfaceva tutti, poich\u00e9 l'avvio avveniva al di fuori dell'orario lavorativo.\n

    Ma abbiamo dovuto lavorare sull'ottimizzazione della velocit\u00e0 di funzionamento. L'aggiornamento del sistema di fidelizzazione in produzione avviene durante la notte. Durante uno dei rilasci, \u00e8 stato necessario apportare modifiche urgenti nella notte. Una attesa di mezz'ora per i risultati dei test automatici alle tre di notte non ha reso felice il responsabile del rilascio (un caloroso saluto ad Aleksey Vasyukov!), e la mattina seguente sono state spese molte parole gentili verso il nostro sistema. Tuttavia, alla fine \u00e8 stato stabilito un limite di 5 minuti per il lavoro.<\/p>\n

    Per aumentare le prestazioni, abbiamo utilizzato due metodi: i test automatici sono stati avviati in tre flussi paralleli, il che \u00e8 stato molto conveniente grazie all'architettura del nostro sistema di fidelizzazione. Inoltre, abbiamo abbandonato l'approccio in cui il test automatico non crea dati di prova per s\u00e9 ma cerca di trovare nel sistema qualcosa di appropriato. Dopo le modifiche, il tempo totale di esecuzione \u00e8 stato ridotto a 3-4 minuti.<\/li>\n

  7. Il progetto con i test automatici deve poter essere distribuito su diversi stand.<\/b> All'inizio del percorso ci sono stati tentativi di scrivere i propri script batch, ma \u00e8 diventato chiaro che installazioni automatizzate scritte a mano sono un vero incubo, quindi ci siamo orientati verso soluzioni industriali. Poich\u00e9 nel progetto ci sono molto codice (in primo luogo, memorizziamo il codice dei test automatici) e pochi dati (i dati principali sono i metadati sui test automatici), l'introduzione di Liquibase nel progetto \u00e8 risultata molto semplice.\n

    \u00c8 una libreria indipendente dal database con codice sorgente aperto per monitorare, gestire e applicare modifiche agli schemi del database. Viene gestita tramite riga di comando o framework come Apache Maven. Il principio di funzionamento di Liquibase \u00e8 piuttosto semplice. Abbiamo un progetto organizzato in un certo modo, composto da modifiche o script che devono essere applicati sul server di destinazione, e file di controllo che definiscono in quale sequenza e con quali parametri devono essere installate queste modifiche. <\/p>\n

    A livello di DBMS viene creata una tabella speciale in cui Liquibase memorizza il log delle applicazioni. Ogni modifica ha un hash calcolato, che viene confrontato ogni volta tra il progetto e lo stato nel database. Grazie a Liquibase, possiamo facilmente applicare le modifiche al nostro sistema su qualsiasi ambiente. I test automatici vengono ora eseguiti sugli ambienti di test e di rilascio, cos\u00ec come sui container (ambienti personali degli sviluppatori).<\/li>\n<\/ol>\n

    \"Unit
    \n
    \nQuindi, parliamo dei risultati dell'applicazione del nostro sistema di unit testing. <\/p>\n

      \n
    1. Naturalmente, prima di tutto, siamo convinti di aver iniziato a sviluppare software di migliore qualit\u00e0. I test automatici vengono eseguiti quotidianamente e ogni rilascio trova decine di errori. Inoltre, una parte di questi errori \u00e8 solo indirettamente legata alla funzionalit\u00e0 che volevamo effettivamente cambiare. Ci sono grandi dubbi sul fatto che questi errori siano stati trovati tramite testing manuale. <\/li>\n
    2. Il team ha acquisito fiducia che una determinata funzionalit\u00e0 funzioni correttamente... Questo riguarda principalmente i nostri processi critici. Ad esempio, negli ultimi sei mesi non abbiamo avuto problemi con la distribuzione degli sconti e dei bonus sullo scontrino, nonostante le modifiche ad ogni rilascio, anche se nei periodi precedenti si verificavano periodicamente degli errori.<\/li>\n
    3. Siamo riusciti a ridurre il numero di iterazioni di test. Grazie al fatto che i test automatici vengono scritti su nuove funzionalit\u00e0, gli analisti e testatori, a tempo pieno e congiuntamente, ricevono un codice di qualit\u00e0 superiore, poich\u00e9 \u00e8 gi\u00e0 stato verificato.<\/li>\n
    4. Parte dei lavori di testing automatizzato viene utilizzata dagli sviluppatori. Ad esempio, i dati di test sui container vengono creati utilizzando un modulo di generazione di oggetti.<\/li>\n
    5. Non \u00e8 di poco conto che abbiamo sviluppato un \"accettazione\" del sistema di testing automatizzato da parte degli sviluppatori. C'\u00e8 consapevolezza che sia importante e utile. E dalla mia esperienza posso dire che non \u00e8 affatto cos\u00ec. I test automatici devono essere scritti, devono essere mantenuti e sviluppati, analizzati i risultati, e spesso questi investimenti di tempo non valgono la pena. \u00c8 molto pi\u00f9 semplice andare in produzione e affrontare i problemi l\u00ec. Tuttavia, i nostri sviluppatori si mettono in fila e chiedono di coprire le loro funzionalit\u00e0 con test automatici.<\/li>\n<\/ol>\n

      E ora?<\/h2>\n

      \n\"Unit
      \n
      \nParliamo dei piani di sviluppo del progetto di testing automatizzato.<\/p>\n

      Senza dubbio, finch\u00e9 il sistema di loyalty di Sportmaster \u00e8 attivo e continua a svilupparsi, possiamo anche sviluppare praticamente all'infinito i test automatici. Pertanto, la principale direzione di sviluppo \u00e8 l'espansione dell'area di copertura.<\/p>\n

      Con l'aumento del numero di test automatici, aumenter\u00e0 inesorabilmente anche il tempo totale di esecuzione, e dovremo nuovamente affrontare la questione delle prestazioni. Probabilmente, la soluzione consister\u00e0 nell'aumentare il numero di flussi paralleli.<\/p>\n

      Ma queste sono strade di sviluppo ovvie. Parlare di qualcosa di pi\u00f9 non banale, evidenziamo quanto segue:<\/p>\n

        \n
      1. Attualmente, la gestione dei test automatici viene effettuata a livello di database, cio\u00e8 sono necessarie conoscenze di PL\/SQL per lavorare con successo. Quando necessario, la gestione del sistema (ad esempio, avviare esecuzioni o creare metadati) pu\u00f2 essere realizzata tramite un'interfaccia di amministrazione, utilizzando Jenkins o qualcosa di simile.<\/li>\n
      2. Tutti amano indicatori quantitativi e qualitativi. Per i test automatici, un indicatore universale \u00e8 il Codice di Copertura o la metrica di copertura del codice. Con questo indicatore, possiamo determinare quale percentuale del codice del nostro sistema in fase di test \u00e8 coperta dai test automatici. A partire dalla versione 12.2, Oracle offre la possibilit\u00e0 di calcolare questa metrica e propone di utilizzare il pacchetto standard DBMS_PLSQL_CODE_COVERAGE.\n

        Il nostro sistema di test automatici ha poco pi\u00f9 di un anno e forse ora \u00e8 il momento giusto per valutare la copertura. Nel mio progetto precedente (un progetto diverso da Sportmaster) \u00e8 successo proprio cos\u00ec. Un anno dopo l'inizio del lavoro sui test automatici, la direzione ha richiesto di valutare quale percentuale di codice fossimo in grado di coprire. Con una copertura superiore all'1%, la direzione sarebbe stata felice. Noi sviluppatori ci aspettavamo un risultato attorno al 10%. Abbiamo implementato il codice di copertura, misurato, e abbiamo ottenuto il 20%. Con grande entusiasmo ci siamo recati a richiedere un premio, ma come ci siamo comportati in merito e dove siamo andati dopo, \u00e8 tutta un'altra storia.<\/li>\n

      3. I test automatici possono verificare i servizi web esposti. Oracle lo consente ampiamente, e noi non ci imbatteremo pi\u00f9 in tutta una serie di problemi. <\/li>\n
      4. E, naturalmente, il nostro sistema di test automatizzati pu\u00f2 essere applicato a un altro progetto. La soluzione che abbiamo ottenuto \u00e8 universale e richiede solo l'uso di Oracle. Ho sentito che ci sono interessi in progetti diversi di Sportmaster per il testing automatico e, forse, ci dirigeremo verso di loro.<\/li>\n<\/ol>\n

        <\/p>\n

        Conclusioni<\/h2>\n

        \nRicapitoliamo. Nel progetto del sistema di fidelizzazione di Sportmaster, siamo riusciti a implementare un sistema di test automatizzati. La base \u00e8 una soluzione utPLSQL di Steven Feuerstein. Attorno a utPLSQL si trova il codice dei test automatici e moduli ausiliari scritti da noi: modulo di avvio, modulo di generazione dei dati e altri. I test automatici vengono eseguiti quotidianamente e, cosa pi\u00f9 importante, funzionano e apportano benefici. Siamo convinti di aver iniziato a rilasciare software di qualit\u00e0 superiore. Inoltre, la soluzione ottenuta \u00e8 universale e pu\u00f2 essere liberamente applicata a qualsiasi progetto che richieda l'organizzazione del testing automatizzato su DBMS Oracle.<\/p>\n

        P.S. Questo articolo \u00e8 risultato non molto specifico: ci sono molte parole e quasi nessun esempio tecnico. Se in generale l'argomento \u00e8 interessante, siamo pronti a continuarlo e tornare con un seguito, in cui parleremo di cosa \u00e8 cambiato negli ultimi sei mesi e forniremo esempi di codice.<\/p>\n

        Scrivete nei commenti se ci sono aspetti su cui vale la pena concentrare l'attenzione in futuro, o domande che richiedono chiarimenti.<\/i><\/p>\n

        Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

        Continuiamo a scrivere su questo?<\/h2>\n