Attività: 3.d Test e sperimentazione

Transcript

1 UNIONE EUROPEA FONDO EUROPEO DI SVILUPPO REGIONALE. REGIONE PUGLIA AREA POLITICHE PER LO SVILUPPO, IL LAVORO E L INNOVAZIONE "Living Labs Smartpuglia 2020" P.O. FESR Puglia Asse I - Linea di Intervento Azione Dominio di riferimento: Economia creativa digitale Progetto: CUP Centro Urbano Potenziato Attività: 3.d Test e sperimentazione Deliverable: D3.d.2 Piano di test e relativo report Versione 1.0 Data 30/04/2015 Autore SOFTWARE DESIGN S.R.L. SVN D3.d.2 Piano di test e relativo report Pag. 1

2 Storico modifiche Data Versione Autore Descrizione 30/04/ SOFTWARE DESIGN S.R.L. Documenti correlati Nome Descrizione Versione Pag. 2

3 Sommario SCOPO DEL DOCUMENTO INTRODUZIONE TEST FUNZIONALE: ACQUISIZIONE DATI DI VENDITA DEI FIDELIZZATI Scenari di test Report dei test Raccomandazioni TEST DI INTEGRAZIONE CON IL SISTEMA DI RACCOMANDAZIONI Scenari di test Report dei test Raccomandazioni TEST DI INTEGRAZIONE CON IL SISTEMA DI BUSINESS INTELLIGENCE Scenari di test Report dei test Raccomandazioni BUSINESS INTELLIGENCE Scenari di test Report dei test Pag. 3

4 Scopo del documento Obiettivo di questo documento è quello di descrivere il piano di test ed il relativo report espresso in termini di raccomandazioni di miglioramento del prototipo. Introduzione Il test del prototipo funzionale ha avuto lo scopo di verificare e validare le funzionalità relative alla gestione delle Fidelity Card, alla gestione dei servizi turistici e alla Business Intelligence. Gli scenari di test sono stati sperimentati e validati sia in laboratorio, durante la fase di test funzionale, sia dal vivo, durante la vera e propria fase di sperimentazione. Di seguito sono indicati gli scenari nell ambito dei quali è stata condotta la sperimentazione e le relative raccomandazioni utente. 1 Test funzionale: acquisizione dati di vendita dei fidelizzati 1.1 Scenari di test Sono stati verificati i seguenti scenari d uso del sistema di acquisizione dei dati dei fidelizzati. I dati anagrafici delle fidelity sono censiti nel gestionale delle Fidelity Card centralizzato e sono e- sportati verso tutti i punti vendita di CARELLI coinvolti nella sperimentazione. Successivamente sono acquisiti dal gestore delle Fidelity Card di ogni singolo punto vendita ed esportati in cassa. Un possessore di Fidelity Card si presenta in cassa presso il supermercato CARELLI con la sua spesa: la barriera casse riconosce il numero di Fidelity Card mediante lettura tramite lo scanner di cui la cassa è dotata, e applica gli sconti previsti sui prodotti acquistati. Il software di barriera casse memorizza i dati inerenti la vendita dei prodotti registrando nel proprio database anche il riferimento al numero della Card. Il gestionale delle Fidelity Card, in un tempo preimpostato di polling, acquista il dato di vendita. I dati di vendita di test di diversi scontrini d acquisto emessi a diversi clienti fidelizzati sono ricercati e visualizzati nella console web (MMPos Server 4 Management Console). Sono applicati dei filtri di ricerca per giorno/ora/cassa e punto vendita e il dato è confrontato con le risultanze fiscali di cassa. Scenario D: Sono generati dei report riepilogativi dei dati di vendita ai fidelizzati e verificate le coerenze rispetto a quelli memorizzati dal dispositivo di stampa fiscale. Pag. 4

5 Scenario E: I dati di vendita dei fidelizzati sono acquisiti dal sistema centrale di gestione delle Fidelity Card e resi disponibili e consultabili al CED mediante la console web. 1.2 Report dei test Si riporta una lista di anomalie riscontrate su tutti o parte degli scenari di test e le relative correzioni apportate. Scenario D: Si è riscontrato un eccessivo traffico di rete sull Access Point di un punto vendita e si è constatato dai Log che l apertura verso l esterno della porta SQL Server (1433) è stata oggetto di attacchi di tipo brute force da parte di soggetti sconosciuti probabilmente software automatico utilizzato per l hacking di reti. Tali continui attacchi hanno degradato il tempo di distribuzione dei dati anagrafici delle Fidelity Card al punto vendita che si è prolungato oltre 5 minuti. Configurare le connessioni remote da e per SQL Server per sfruttare i tunnel della VPN esistente tra CED e punto vendita, chiudendo quindi la porta 1433 dall Access Point e veicolando tutto il traffico di rete dell infrastruttura CUP tramite un firewall. Si è riscontrato un tempo eccessivo di aggiornamento di MMPos Server dei dati di vendita provenienti dalla barriera casse. Tarare meglio il tempo di polling schedulando in tempi più brevi l esecuzione degli script di acquisizione dei dati da parte di MMPos Server. Il server predisposto per ospitare MMPos Server Management Console, non aveva risorse sufficienti per eseguire l applicazione mediante IIS. Poiché la memoria fisica a disposizione non era la minima consigliata, le risposte del browser sono risultate particolarmente lente. Reinstallare i componenti web su un altro server presente nel punto vendita che è stato dedicato solo a questo scopo, migliorando sensibilmente i tempi di rendering delle pagine web. Poiché i test sono stati effettuati durante la normale operatività del punto vendita, ovvero a giornata fiscale già iniziata, non è stato possibile confrontare i risultati dei report direttamente con una chiusura giornaliera delle vendite. Si è tuttavia constatato che quanto mostrato dai report coincideva con gli scontrini emessi ai fidelizzati fino a quel momento. Non è applicabile una correzione poiché non si tratta di una anomalia. Scenario E: Come per lo scenario A, gli attacchi sulla porta 1433 hanno causato rallentamenti considerevoli anche nell acquisizione dei dati da parte del server centrale delle Fidelity Card. Configurare le connessioni remote da e per SQL Server per sfruttare i tunnel della VPN esistente tra CED e punto vendita, chiudendo quindi la porta 1433 dall Access Point e veicolando tutto il traffico di rete dell infrastruttura CUP tramite un firewall. 1.3 Raccomandazioni Pag. 5

6 Si descrivono alcune raccomandazioni che si sono evidenziate durante gli scenari di test, per migliorare e/o arricchire le funzionalità descritte da questo capitolo. Sarebbe utile avere uno strumento di monitoraggio centralizzato che metta in evidenza eventuali anomalie ed errori inerenti le comunicazioni tra componente CED, componente punto vendita e barriera casse per verificare più facilmente che non ci siano stati problemi o rallentamenti nell invio dei dati anagrafici. Sarebbe utile poter consentire al possessore dell App di poter visualizzare i suoi acquisti direttamente dall App e poter eventualmente votare e commentare il negozio; questo sarebbe possibile se l esportazione dei dati provenienti dalla barriera casse fossero inviati anche al server dell App oltre che ad MMPos Server. Si raccomanda di utilizzare questa funzione solo se l installazione è stata eseguita su un server non sottodimensionato rispetto ai requisiti minimi richiesti di hardware. Tale funzione infatti può richiedere un eccessivo impegno delle risorse di RAM e disco e far rallentare il sistema se non opportunamente dimensionato. Scenario D: Il sistema di generazione dei report in modalità asincrona (si inserisce una richiesta di generazione di report e un alert avvisa quando il report è pronto), potrebbe essere arricchito con un alert via e/o con la funzione di invio tramite del report stesso. Scenario E: Si raccomanda di tarare in maniera adeguata i tempi di acquisizione dei dati di vendita nel server centrale delle Fidelity Card per raggiungere il giusto compromesso tra disponibilità di banda ADSL dei punti vendita e disponibilità in tempo reale dei dati: un tempo di polling troppo accelerato potrebbe garantire la disponibilità dei dati sul server centrale del CED in tempi brevi ma al contempo impegnare troppo l ADSL del punto vendita e degradare la normale attività lavorativa; un tempo troppo poco frequente potrebbe alleggerire il traffico dati tramite ADSL ma non consentirebbe la consultazione dei dati freschi provenienti dai punti vendita. 2 Test di integrazione con il sistema di raccomandazioni 2.1 Scenari di test Sono stati verificati i seguenti scenari d uso del sistema di esportazione dei dati verso il Recommender System. A fine giornata si esegue il job automatico di esportazione dei dati verso il RS. Il RS acquisisce i dati di vendita dei fidelizzati e esegue le sue elaborazioni Pag. 6

7 I dati di raccomandazione prodotti dal RS sono importati in MMPosServer e sono visualizzati tramite la Console Web. 2.2 Report dei test Il rallentamento nell acquisizione dei dati di vendita dal punto vendita (già descritto in precedenza) ha causato una sovrapposizione temporale tra l operazione di acquisizione dei dati provenienti dalle barriere casse con quella di esportazione verso il RS, causando un problema di deadlock sulle tabelle SQL Server. Per quanto il problema si è risolto automaticamente, riportando i tempi di acquisizioni dei dati dal punto vendita alla normalità (correzione su descritta tramite utilizzo di VPN), negli script di esportazione è stato garantita la gestione di un eventuale deadlock durante l esportazione, consentendo al sistema di annullarla e riprovarla dopo pochi minuti. Non sono sorte anomalie rispetto all operatività di import/export da e verso il RS Nessuna correzione necessaria Su una anagrafica estremamente ricca come quella del cliente l operazione di visualizzazione delle raccomandazioni è risultata poco performante. Sono stati aggiunti degli indici alle tabelle anagrafiche per consentire l esecuzione delle query da parte di MMPos Server 4 Management Console, in maniera molto più veloce. 2.3 Raccomandazioni Sarebbe utile avere uno strumento di monitoraggio via web dell operazione di export verso il RS. Sarebbe utile avere uno strumento di monitoraggio via web dello stato di avanzamento dell elaborazione del Recommender System. Sarebbe utile un sistema di configurazione del tracciato CSV in modo da poterlo esportare in base alle esigenze di ogni cliente. 3 Test di integrazione con il sistema di Business Intelligence 3.1 Scenari di test Sono stati verificati i seguenti scenari d uso del sistema di esportazione dei dati verso la Business Intelligence. Pag. 7

8 A fine giornata viene eseguito il job automatico di esportazione dei dati verso il software di Business Intelligence. La BI acquisisce i dati di vendita dei fidelizzati ed esegue le sue elaborazioni. 3.2 Report dei test Si riporta una lista di anomalie riscontrate su tutti o parte degli scenari di test e le relative correzioni apportate. Il rallentamento nell acquisizione dei dati di vendita dal punto vendita (già descritto in precedenza) ha causato una sovrapposizione temporale tra l operazione di acquisizione dei dati provenienti dalle barriere casse con quella di esportazione verso la BI, causando un problema di deadlock sulle tabelle SQL Server. Per quanto il problema si è risolto automaticamente riportando i tempi di acquisizioni dei dati dal punto vendita alla normalità (correzione su descritta tramite utilizzo di VPN), negli script di esportazione è stato garantita la gestione di un eventuale deadlock durante l esportazione, consentendo al sistema di annullarla e riprovarla dopo pochi minuti. Non sono sorte anomalie rispetto all operatività di import/export da e verso il RS Nessuna correzione necessaria 3.3 Raccomandazioni Si descrivono alcune raccomandazioni che si sono evidenziate durante gli scenari di test, per migliorare e/o arricchire le funzionalità descritte. Sarebbe utile avere uno strumento di monitoraggio via web dell operazione di export verso la BI. Sarebbe utile avere uno strumento di monitoraggio via web dello stato di avanzamento dell elaborazione da parte della BI. 4 Business Intelligence Per il sistema di Business Intelligence (BI) si è pensato di fare essenzialmente due gruppi di test: per verificare il sistema dal punto di vista tecnico (TC); per verificare il sistema dal punto di vista dei dati (DA). Infatti essendo il sistema di BI un oggetto che si collega ai sistemi alimentanti e che produce report e grafici per permettere all utente di verificare l efficacia delle proprie azioni, è necessario procedere a verifiche di tipo differente. 4.1 Scenari di test Pag. 8

9 Installazione e configurazione della macchina per la raccolta e la trasformazione dei dati con Pentaho Data Integration e DB PostgreSQL Verificare che il sottosistema di raccolta dei dati e quello di trasformazione dei dati siano correttamente installati e configurati. Il test consiste nel verificare che il sistema abbia le seguenti componenti installate: Sistema operativo: Ubuntu 10.4; DBMS: PosgreSQL; Sistema di raccolta: Pentaho Data Integration. e che un job minimale di lettura dei dati da file CSV riesca a scrivere correttamente sul DBMS indicato Installazione e configurazione della macchina per la presentazione dei dati con SpagoBI e DB PostgreSQL Verificare che il sottosistema di presentazione dei dati con l annesso db per ospitare il datawarehouse siano correttamente installati e configurati. Il test consiste nel verificare che il sistema abbia le seguenti componenti installate: Sistema operativo: Ubuntu 10.4; DBMS: PosgreSQL 9.4; Sistema di presentazione: SpagoBI 5.1; e che sia possibile definire una connessione da SpagoBI verso il DB del datawarehouse. Connessione del sottosistema di lettura dei dati ai sistemi alimentanti Verificare che il sottosistema di lettura dei dati sia in grado di accedere ai db dei sistemi alimentanti. Il test consiste nel creare una connessione dal sottosistema di lettura verso i sistemi alimentanti. Scenario D: Connessione del sottosistema di trasformazione dei dati al datawarehouse del sottosistema di presentazione Verificare che il sottosistema di trasformazione riesca ad accedere al datawarehouse ospitato nel DBMS PostgreSQL del sottosistema di presentazione dei dati. Occorre anche verificare che un job minimale riesca a leggere un file CSV e a scrivere correttamente sul DBMS del datawarehouse. Scenario E: Esecuzione dei job di raccolta dei dati Verificare che il sottosistema di raccolta dei dati esegua correttamente i job di raccolta dei dati. Il test consiste nell eseguire i job di raccolta dei dati sia in modalità on demand che in modalità schedulata. Scenario F: Esecuzione dei job di trasformazione dei dati Pag. 9

10 Verificare che il sottosistema di trasformazione dei dati esegua correttamente i job di trasformazione dei dati. Il test consiste nell eseguire i job di trasformazione dei dati sia in modalità on demand che in modalità schedulata. Scenario G: Accesso al sistema Verificare che da un browser sia possibile collegarsi al sistema di presentazione dei dati inserendo le credenziali di accesso al sistema di presentazione. Scenario H: Coerenza dei dati Verificare che campioni di dati su sottoinsiemi temporali o secondo altre dimensioni forniscano dati identici rispetto alle stesse selezioni effettuate sui sistemi alimentanti. Il test consiste nell eseguire il conteggio del numero di attivazioni e del numero di Coupon (offerte) in uno specifico lasso di tempo sia sui sistemi alimentanti che attraverso gli indicatori specifici del sistema di presentazione dei dati. Scenario I: Navigabilità dei dati Verificare che gli indicatori del sottosistema di presentazione siano navigabili attraverso le principali dimensioni temporali, anagrafiche e di classificazione. 4.2 Report dei test L installazione è stata effettuata su una macchina virtuale all interno di un infrastruttura VMware vsphere. L installazione è stata verificata ed è stato eseguito con successo un job all interno di Pentaho Data Integration che ha letto un file CSV e ha scritto i corrispondenti valori all interno di una tabella del DB della Staging Area. L installazione è stata effettuata su una macchina virtuale all interno di un infrastruttura VMware vsphere. L installazione è stata verificata ed è stata eseguita con successo una connessione da SpagoBI verso il DB del datawarehouse. Il test è stato eseguito con successo realizzando due connessioni: una verso il sistema SQL Server del gestionale, l altro verso il sistema MySql dell App. Scenario D: Pag. 10

11 Il test è stato eseguito con successo realizzando la connessione tra il sottosistema di trasformazione dei dati e il DB del datawarehouse ospitato nel sottosistema di presentazione dei dati. Scenario E: Il test è stato eseguito con successo effettuando l esecuzione dei job di lettura dei dati sia in modalità on-demand che in modalità schedulata. Scenario F: Il test è stato eseguito con successo effettuando l esecuzione dei job di trasformazione dei dati sia in modalità on-demand che in modalità schedulata. Scenario G: Il test è stato eseguito con successo approntando un login di test (cuptest/cuptest). L accesso al sottosistema di presentazione è stato verificato con i browser IE 11. Firefox 30, Chrome 41 Scenario H: Il test è stato eseguito con successo. A valle dell estrazione dei dati, le procedure di trasformazione e costruzione del datawarehouse hanno fornito un set di dati che è stato verificato su un set temporale di due settimane consecutive e su due sottoinsiemi di dati, dati dell App e dati del punto vendita. Tali dati sono stati poi confrontati con i report estratti via SQL dal primo sistema e con report dell applicazione del secondo sistema. Il confronto non ha rilevato differenze significative. Scenario I: Il test è stato eseguito con successo osservando gli indicatori di pressione di Coupon, di andamento di attivazioni e di correlazione Eventi/Coupon facendo delle selezioni di periodi temporali (mesi/settimane), di Tipologie di Prodotti/Eventi, di categorie di anagrafiche. Nelle figure successive sono riportati gli esiti dei test di esecuzione dei job. Pag. 11

12 Pag. 12

13 Pag. 13