Testing del sistema

Nei capitoli precedenti sono state svolte le fasi di analisi dei requisiti, progetta-zione ed implementaprogetta-zione del sistema Ąnale che rappresenter‘a la base del progetto Forestry Analyzer dellŠazienda Hesplora. A questo punto, seguendo gli step del ciclo di vita di un progetto dettati dallŠingegneria del software, mancherebbe da effettua-re il testing del sistema effettua-realizzato. La fase di test del sistema Ąnale ‘e un passo fondamentale della progettazione in ambito IT poich´e precede lŠeffettivo rilascio del sistema ed ha lo scopo di individuare eventuali anomalie ed errori; questi ultimi, una volta individuati (se presenti), dovranno essere corretti in modo da rilasciare un prodotto privo di errori o imperfezioni.

Attualmente, esistono vari modi per testare un sistema software; fra questi, i principali sono il testing manuale ed il testing automatico. Le caratteristiche di questi due tipi di approcci al testing sono le seguenti:

• Il testing manuale prevede che ci sia un tester (o un team) che controlla ma-nualmente che tutte le funzionalit‘a del sistema realizzato si comportino come previsto (reliability).

• Nei test automatici, invece, i tester codiĄcano uno script per testare e convalidare il sistema in modo automatico. LŠautomatizzazione di questa fase porta ad uno sforzo maggiore nella parte iniziale, data la necessit‘a di produzione di uno script;

in seguito, per‘o, il test pu‘o essere eseguito agevolmente, facendo risparmiare tempo di esecuzione. Fra i migliori e pi‘u comuni strumenti di test automatici troviamo Selenium, Appium e Test Studio.

Nel nostro lavoro, i test che sono stati effettuati sul sistema realizzato e sulla pipeline di ETL sono test manuali effettuati dal team interno allŠazienda. Come gi‘a detto pi‘u volte, nonostante il sistema realizzato sia il fulcro del progetto Forestry Analyzer, non rappresenta il vero e proprio prodotto Ąnale che dovr‘a essere rilascia-to; per questo motivo, ci si ‘e affidati ad un test manuale interno che sar‘a intenso nella suddetta fase, ma che continuer‘a Ąno alla Ąne del progetto in maniera Şvela-taŤ, dal momento che il sistema verr‘a utilizzato per costruirci sopra le successive implementazioni.

5.1.1 Testing del sistema sul cloud

Entrando pi‘u approfonditamente nellŠambito del sistema messo in piedi sul cloud, esso ‘e stato testato in tutte le sue componenti, ovvero Web UI, Jupyter Notebook e PostgreSQL. In questa fase, per ciascuna componente, verr‘a eseguito un test di tipo manuale per provare lŠeffettivo stato di attivit‘a del servizio controllando se il sistema risponde correttamente ai tentativi di interazione.

Essendo un sistema su cloud, i principali test che sono stati effettuati riguarda-no un aspetto prettamente strutturale e, in particolare, di corretta conĄgurazione della rete e delle comunicazioni fra le VM. Questi test, che ricordiamo rientravano anche tra i requisiti del sistema, riguardano i due vettori di interazione tra questŠul-timo e gli utenti Ąnali (lŠinterfaccia utente di ODC e lŠinterfaccia di JupyterLab).

Descriviamo, in maniera separata, le due interfacce:

• ODC Web UI : per quanto riguarda lŠinterfaccia utente di ODC abbiamo gi‘a mostrato che il servizio ‘e funzionante ed ‘e raggiungibile tramite il Web. Tra i vari test effettuati, per‘o, una prova che pu‘o esser effettuata parallelamente a quella sul browser consiste in una connessione alla VM tramite il protocollo SSH (Secure Shell). Per farlo, ‘e stato utilizzato un terminale ed ‘e stato lanciato il comando Şssh -p 22 hesploraforestry@18.159.98.100Ť dove la porta Ş22Ť

‘e quella dedicata alle connessioni SSH, ŞhesploraforestryŤ ‘e lo username della macchina e Ş18.159.98.100Ť ‘e lŠindirizzo IP. Dopo aver inserito la chiave segreta della VM, ci siamo riusciti a connettere alla VM ed il risultato viene visualizzato in Figura 5.1.

Figura 5.1.Connessione alla Virtual Machine della UI di ODC tramite protocollo SSH

E importante sottolineare che, nel momento in cui abbiamo testato che la Web UI‘ di ODC ‘e funzionante, ‘e come se avessimo appurato la corretta conĄgurazione della comunicazione tra il servizio PostgreSQL e la UI di ODC. Infatti, nel database PostgreSQL relativo a Django, sono contenuti tutti i dati degli utenti nonch´e altri dati utili alla strutturazione del sito; riĆettendoci, la UI sarebbe andata in crash se la connessione fra questŠultima ed il relativo database non fosse andata a buon Ąne.

• JupyterLab: analogamente a quanto appena fatto con la Virtual Machine de-dicata alla UI di ODC, ‘e stata testata la connessione anche per la VM che ospita il servizio JupyterLab. Dunque, ‘e stato lanciato sul terminale il coman-do duale a quello precedente, coman-dove ŞubuntuŤ ‘e lo username della VM, mentre Ş18.198.132.132Ť ‘e il suo indirizzo IP. Dopo aver inserito anche qui la chiave segreta della VM, ci siamo riusciti a connettere alla VM ed il risultato viene visualizzato in Figura 5.2.

Figura 5.2.Connessione alla Virtual Machine che implementa il servizio di JupyterLab

5.1.2 Testing della pipeline di ETL

Di seguito presenteremo varie situazioni risultanti da una fase di stress test dellŠu-tilizzo dello script che implementa la pipeline di ETL. Fra i vari test effettuati su questa pipeline, quelli che che sono stati individuati come pi‘u rilevanti e meritevoli di essere presi in considerazione sono i seguenti:

• Esecuzione dello script senza speciĄcare i parametri (Figura 5.3): questo primo test era banale ma mostra una delle funzionalit‘a dello script, ovvero quella di evidenziare il corretto ordine e range dei parametri. ‘E stato considerato, infatti, che lŠutente possa non ricordare di speciĄcare i parametri e, di conseguenza, lanciare lo script senza indicarli.

• Esecuzione dello script dove viene speciĄcato un dato gi‘a presente nel bucket S3 aziendale (Figura 5.4): in questo caso si ‘e ipotizzato un possibile scenario nel quale vengono estratti periodicamente i dati e potrebbe succedere che venga richiesto un dato che sia gi‘a presente nel nostro bucket S3 aziendale. Il sistema non genera unŠeccezione perch´e nello script ‘e stato previsto un controllo che

prevede questa situazione; in particolare, la migrazione non parte proprio e non viene sprecato tempo prezioso a sovrascrivere inutilmente il dato.

• Esecuzione dello script con parametri mancanti (Figura 5.5): nel momento in cui non vengono speciĄcati tutti i parametri, lo script comporr‘a un URI che non corrisponder‘a a nessun dato del repository open source di Copernicus e, dunque, verr‘a ritornato un errore con 404 (elemento non trovato).

• Esecuzione dello script con parametri errati (Figura 5.6): in questo caso sono stati esplicitati parametri errati e abbiamo testato che il sistema non va in crash;

in particolare, ‘e stata data in input una stringa quando il sistema si aspettava delle cifre numeriche. Un altro test simile che ‘e stato effettuato (ma che si ‘e scelto di non riportare per non creare duplicazioni) ‘e quello che prevede lŠinserimento di caratteri speciali che, generalmente, possono essere fonte di errori nei sistemi IT;

anche di fronte a questo tipo di input lo script ha mostrato resilienza rispondendo sempre e solo con un errore di tipo 404.

E doveroso notare come le casistiche di parametri mancanti (esempio preceden-‘ te), errati (esempio attuale), o giusti ma che non si riferiscono a nessuno dei dati presenti nella sorgente, ritornano sempre la stessa risposta (cio‘e un errore con codice 404), dal momento che lo script si basa sulla ricostruzione di un URI che, se non composto in maniera adeguata, effettua una richiesta ad un oggetto inesistente.

Figura 5.3.Esecuzione dello script senza speciĄcare parametri

Figura 5.4.Esecuzione dello script con dato gi‘a presente nel bucket S3 aziendale

Figura 5.5.Esecuzione dello script con parametri mancanti

Figura 5.6.Esecuzione dello script con parametri errati