UNIVERSITÀ DEGLI STUDI DI FIRENZE

                            FACOLTÀ DI INGEGNERIA

       ...
A Nonno Tonino
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Sommar...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Conclu...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Capito...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




1.2 Co...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




avvien...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




period...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




La red...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




modo d...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Le due...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Il rep...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




in mod...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




aspett...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




reali ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




di ri-...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




sottol...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Test  ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




ore [9...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




1.4 Pi...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




strate...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




essend...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




ed i c...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Tabell...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Il tra...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Capito...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




2.2 St...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




   .

...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




in un ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




L‟elet...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Pendin...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




     S...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




realiz...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




FDM: I...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Altri ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




vita. ...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




Capito...
Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante”




      ...
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Tesi Magistrale
Upcoming SlideShare
Loading in …5
×

Tesi Magistrale

2,367 views
2,265 views

Published on

Tesi Laurea Magistrale

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,367
On SlideShare
0
From Embeds
0
Number of Embeds
65
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tesi Magistrale

  1. 1.   UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGNERIA CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA ELETTRONICA Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Candidato: Alessandro Bacioccola Relatori: Relatori esterni: Prof. M. Catelani Ing. P. Pollastri Prof. A. Fantechi Ing. L. Samori Ing. L. Ciani Dott. A. Tagliati Ing. V. L. Scarano ANNO ACCADEMICO 2007-2008
  2. 2. A Nonno Tonino
  3. 3. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Sommario Capitolo 1 ....................................................................................................... 7 1.1 Affidabilità del Software ................................................................. 7 1.2 Concetti fondamentali .................................................................... 9 1.3 Verifica e Validazione .................................................................. 13 1.4 Pianificazione dell‟attività di test .................................................. 28 Capitolo 2 ..................................................................................................... 36 2.1 Azienda e prodotti ........................................................................ 36 2.2 Storia dell‟azienda ....................................................................... 37 2.3 I prodotti dell‟azienda ................................................................... 38 2.4 Prodotto software ........................................................................ 51 Capitolo 3 ..................................................................................................... 53 3.1 Applicazione dei test automatici alla non regressione ................. 53 3.2 Test automatici per la non regressione ........................................ 55 3.3 Test di non regressione sul prodotto BasePOS ........................... 57 3.4 Risultati ........................................................................................ 76 Capitolo 4 ..................................................................................................... 80 4.1 Applicazione dei test automatici allo studio dei memory leaks .... 80 4.2 Individuazione dei memory leaks ................................................. 82 4.3 Parametri per lo studio del fenomeno .......................................... 83 4.4 Studio dei memory leaks relativi al Passport Europe ................... 84 4.5 Risultati ........................................................................................ 85 2
  4. 4. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Conclusioni................................................................................................... 91 Appendice A ................................................................................................. 93 Bibliografia ................................................................................................... 97 3
  5. 5. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Le attività di verifica e validazione (V&V) del software consentono di evidenziare non conformità e potenziali errori generati nelle diverse fasi di realizzazione del prodotto. Fino a pochi anni fa gli sviluppatori consideravano il testing software come secondario rispetto allo sviluppo. Da alcuni anni si è verificata un’inversione di tendenza e spesso è l’attività di test ad essere il trampolino di lancio per lo sviluppo del prodotto; anche se essendo un’attività molto impegnativa, il suo costo è comparabile con quello dello sviluppo del prodotto. In questo caso è stato effettuato uno studio a priori delle criticità del software in funzione dell’uso a cui è destinato: i risultati saranno poi utilizzati per pianificare la stesura del codice. Lo standard di riferimento per lo studio dell’affidabilità e la qualità di un software è l’ISO 9126, dove vengono suggerite varie tipologie di approccio al problema. Il metodo più utilizzato consiste nel valutare la qualità in uso del prodotto ovvero 4
  6. 6. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” esprimere l’efficienza e l’efficacia del prodotto di soddisfare l’esigenze del cliente. Uno dei metodi per ottimizzare e contemporaneamente ridurre i costi del controllo di qualità del software è quello di adottare metodologie di test automatico. Le applicazioni maggiori del test automatico del software sono lo studio della non regressione dei guasti all’interno della fase di accettazione del prodotto e i test di occupazione di memoria. Dove si esegue la ripetizione continua di operazioni e sequenze per verificare che le nuove funzionalità introdotte non danneggino quelle consolidate. Contemporaneamente è possibile valutare l’occupazione di memoria dei vari moduli software. Il lavoro di tesi in esame, svolto in collaborazione con lo stabilimento Gilbarco Veeder – Root di Firenze, tratta l’applicazione dei test automatici software a questi due problemi canonici del testing 5
  7. 7. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” software: lo studio della non regressione e dell’occupazione di memoria, al fine di dimostrare che l’approccio proposto permette una riduzione dei costi del testing a fronte di un incremento dell’affidabilità del prodotto. 6
  8. 8. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Capitolo 1 1.1 Affidabilità del Software Lo studio dell’affidabilità software deriva dalla teoria su cui si basa l’affidabilità hardware. Lo studio dell’affidabilità di un software è una disciplina che risale alla metà degli anni ’70 e non ha ancora raggiunto uno stato di maturità consolidata. Si continuano a percorrere due diverse strade: la modellizzazione e la predizione a priori dei guasti software, meno utilizzata a causa dell’elevata variabilità di tutti parametri in gioco e la valutazione a posteriori dell’affidabilità del prodotto (verifica e validazione). Quest’ultima tecnica è attualmente la più utilizzata a livello industriale; pur chiamandosi valutazione a posteriori essa non si applica a termine del processo produttivo ma durante tutto il ciclo di produzione del software. L’attività di testing inizia infatti prima 7
  9. 9. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” dello sviluppo con l’analisi delle specifiche tecniche fornendo una guida al lavoro dello sviluppatore e prosegue nel ciclo di sviluppo e produzione, durante il quale ad intervalli predefiniti si verifica il raggiungimento degli obbiettivi prefissati. 8
  10. 10. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” 1.2 Concetti fondamentali Il concetto di affidabilità hardware e le tecniche ad esso relative sono da tempo consolidate, resta da chiarire quale possa essere l‟applicabilità nell‟affidabilità del software. In verità le differenze che contraddistinguono le due realtà sono spesso di carattere prevalentemente formale più che sostanziale; entrambe, infatti, dipendono dalle condizioni di impiego e possono essere definite nello stesso modo con la possibilità di ottenere l‟affidabilità complessiva del sistema attraverso una combinazione del affidabilità dei vari moduli che lo compongono [1]. La fonte principale dei malfunzionamenti in un programma è costituita dagli errori commessi Figura 1: Curva a vasca, tipico andamento del tasso di guasto di un durante la stesura del sistema elettronico. codice dallo sviluppatore, mentre, nel caso hardware, i malfunzionamenti non sono dovuti esclusivamente ad errori di progettazione ma anche all‟invecchiamento dei componenti ed alla scarsa manutenzione. La correzione di un errore in un software, solitamente, è definitiva; un malfunzionamento può verificarsi solo se il software è utilizzato in condizioni diverse da quelle per cui è stato sottoposto a verifica. L‟introduzione e l‟eliminazione degli errori di progetto 9
  11. 11. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” avviene durante la fase di sviluppo, quindi ci si attende che l‟affidabilità software vari durante tale periodo. La duplicazione di una scheda elettronica presenta inconvenienti legati alla possibilità di incorrere in componenti difettosi, mentre la duplicazione del software è un fatto banale dal punto di vista dell‟affidabilità ed è eseguita oggi con altissima qualità. Generalmente il tasso di guasto di un sistema elettronico segue il tipico andamento a vasca (fig.1), invece l‟andamento dell‟affidabilità di un software è difficilmente descrivibile, in quanto varia durante il processo di sviluppo ed è successivamente costante a meno di non introdurre o rimuovere errori mediante aggiornamenti dell‟applicativo già in uso. Alcune pubblicazioni [2] descrivono l‟andamento del tasso di guasto di un sistema software come riportato in figura 2. Figura 2: Andamento del tasso di guasto di un software Il tasso di guasto ha un andamento decrescente nel tempo, inizialmente esponenziale e poi con pendenza più lieve, rispecchiando rispettivamente il 10
  12. 12. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” periodo iniziale di sviluppo e i malfunzionamenti insorti dopo il rilascio. Il tasso di guasto software si discosta da quello hardware nel secondo periodo temporale (il periodo di vita del prodotto, useful life) e nel terzo (periodo dove il software è divenuto obsoleto e non sono effettuati aggiornamenti). Nella zona di vita utile il tasso di guasto varia ed in particolare aumenta ogni qual volta si ha un aggiornamento, dopo l‟aggiornamento il tasso di guasto decresce esponenzialmente e tende a restare costante fino al successivo aggiornamento o fino a che il software non è più manutenuto [3]. Nonostante queste differenze, è possibile sviluppare una teoria dell‟affidabilità del software che risulti compatibile con quella hardware, che ci permetta di calcolare i valori di affidabilità dell‟intero sistema con tecniche combinatorie [4]. Prima di approfondire le tematiche riguardanti l‟affidabilità ed il testing del software è necessario introdurre alcuni termini fondamentali: Malfunzionamento (defect): scostamento dei risultati reali ottenuti con l‟esecuzione di un programma da quelli attesi (risultati ideali o da specifica). Il malfunzionamento non è sempre un errore nel codice, può essere anche un‟intollerabile lentezza di esecuzione del programma; la definizione è volutamente generica [1]. Errore (bug): è un difetto a livello del programma, che al momento di un esecuzione in particolari condizioni può generare il manifestarsi di un malfunzionamento. Tempo d’esecuzione (o di CPU): tempo per il quale la CPU è effettivamente utilizzata per l‟esecuzione del programma. 11
  13. 13. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Tempo calendario: è il tempo al quale siamo abituati, quello che scandisce la vita quotidiana. Questo parametro sarà l‟unico riferimento per l‟utente. Tempo cronometrico (o clock time): tempo totale di esecuzione di un programma, comprese le fasi di attesa che possono essere dovute ad operazioni di I/O, a funzioni del sistema operativo o all‟esecuzione concorrente di altri programmi. L’affidabilità del software è la probabilità di funzionamento di un programma senza malfunzionamenti per un determinato tempo in un determinato ambiente esecutivo [1]. I parametri che caratterizzano l‟affidabilità software sono: MTTF: mean time to failure, tempo medio al malfunzionamento MTTR: mean time to repair (fixing), tempo medio alla riparazione (alla soluzione del malfunzionamento). MTBF: mean time between failure, tempo medio fra due malfunzionamenti. (1.1) Il test del software, con tutte le procedure di verifica e validazione attuate sul codice, rappresenta il primo passo verso la stima dell‟affidabilità del prodotto. L‟affidabilità del software R(t) sarà calcolata secondo il modello classico a partire da MTTF e dal tasso di guasto . 12
  14. 14. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” (1.2) La formula (1.2) si basa sull‟ipotesi semplificativa che il tasso di guasto sia costante; tale ipotesi è valida soltanto oltre il periodo iniziale dei guasti infantili ed in assenza di aggiornamenti (figura 2). Sotto questo ipotesi è possibile ricavare la funzione affidabilità di prodotto (1.3). (1.3) 1.3 Verifica e Validazione Lo standard ANSI/IEEE Std 729-1983 “Standard Glossary of Software Engineering Terminology” [5] definisce i termini: Verifica: Il processo che determina se il prodotto di una certa fase del processo di sviluppo software è conforme ai requisiti stabiliti nelle fasi precedenti. Validazione: Il processo di valutazione che ha quale prodotto di indagine il software al termine del processo di sviluppo per stabilirne la coerenza con tutte le fasi. Possiamo definire gli stessi due termini anche con le seguenti domande: Verifica: sto producendo il software in modo corretto, cioè riesco a valutare la coerenza di quanto prodotto da una fase o attività rispetto ai documenti ed elementi che sono in ingresso per quella fase? 13
  15. 15. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Validazione: sto producendo il prodotto che era stato richiesto dal mio Cliente? Al fine di verificare e garantire che le caratteristiche raggiungano il livello stabilito dalle specifiche del committente, occorre stabilire opportune prove per ricreare il contesto tipico di interazione software-utente. Per definire le situazioni d‟uso (Test Case) [5] devono essere note e definite le caratteristiche di sistema: configurazione, stato iniziale prima di eseguire il test, parametri di sistema, variabili in input ed in output, condizioni al contorno (condizioni operative) e stato finale del sistema atteso dopo aver eseguito il test. L‟attività di test deve sicuramente esser il frutto di un compromesso tra la necessità di massimizzare la copertura del prodotto in termini di verifica delle sue funzionalità e le esigenze in termini di costi e tempo. Questo significa definire delle priorità nelle funzioni da testare in base a criteri di frequenza di utilizzo, criticità e rischio, quindi redigere Piano di Test (PdT) [6]. L‟attività di testing dovrebbe seguire un processo parallelo al processo di sviluppo ed essere pianificata di conseguenza, in modo che ad ogni fase del “prodotto software” segua, sin dagli stadi iniziali del processo, una fase di verifica e validazione. Questo approccio consente di minimizzare gli effetti negativi perché da luogo ad un‟attività di verifica immediata nel corso di ciascuna fase realizzativa, all‟interno della quale gli errori che si possono generare o insorgere (malfunzionamenti latenti) siano corretti, riducendo così la probabilità che i loro effetti si propaghino alle fasi successive dello sviluppo, con conseguenze tanto più grandi quanto più il malfunzionamento è rilevato in ritardo. Il Piano di Test serve proprio per guidare l‟attività di testing in tutte le differenti fasi, permette di definire la strategia di test da utilizzare rivalutando criticamente i requisiti del prodotto, la loro implementazione ed infine la rispondenza del prodotto a tali requisiti. 14
  16. 16. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” La redazione del piano di test è effettuata, quando possibile, prima dell‟inizio degli sviluppi; i programmatori saranno guidati nello sviluppo e nell‟interpretazione delle specifiche dal PdT. In base al momento in cui viene eseguita ed alla metodologia utilizzata, l‟attività di test può essere suddivisa in due macro famiglie: Test di progetto o di basso livello. Test funzionale o di alto livello. Test di basso livello: è il test di progetto, un test white-box, che presuppone cioè una conoscenza sufficientemente approfondita della struttura hardware e software del sistema. E‟ tipicamente un test preventivo, che sollecita parti del sistema in modo da mettere in relazione diretta e biunivoca un malfunzionamento con l‟errore che ne è causa. L‟efficienza nominale, definita come la capacità del test di individuare malfunzionamenti riconducibili alle cause, è tanto più elevata se il test è eseguito immediatamente dopo la fase di progetto della parte di sistema interessata, in questo modo è più agevole mettere in relazione malfunzionamento ed errore, inoltre la correzione è decisamente più rapida. Questa famiglia di test è di fondamentale importanza per evitare la migrazione degli errori, che altrimenti si tradurrebbero in malfunzionamenti che, se intercettati in fasi successive del processo di sviluppo o peggio ancora sul campo, ne rendono difficilmente individuabili le cause, e la loro correzione può essere molto difficile ed onerosa. Il test di basso livello è per definizione un test eseguito su un prototipo anche molto grezzo del prodotto o su parti di esso; richiede quindi spesso la realizzazione di simulatori di parte del prodotto o del sistema da utilizzare in sostituzione delle parti ancora non sviluppate. Se ne conclude che il test di basso livello deve essere eseguito da personale specializzato di progettazione e deve essere eseguito parallelamente alla fase di sviluppo, in 15
  17. 17. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” modo da tenere sotto controllo l‟evoluzione del prodotto individuando prima possibile gli eventuali errori inseriti. E‟ un test principalmente mirato alla verifica di affidabilità del prodotto, demandando tipicamente al test di alto livello le verifiche di usabilità e manutenibilità [7]. Test di alto livello: è tipicamente un test black-box, cioè basato sull‟utilizzo del prodotto, sull‟esercizio delle sue funzionalità, per verificarne il corretto funzionamento o evidenziare eventuali malfunzionamenti, non conformità o comportamenti non user friendly. E‟ quindi un test a posteriori, con il quale si valuta il prodotto sulla base degli effetti di un eventuale errore od imperfezione. E‟ chiaro quindi che tale metodologia risulta estremamente poco efficiente se applicata su prodotti non ancora finiti o con un livello elevato di imperfezioni e malfunzionamenti. Dopo l‟individuazione del malfunzionamento infatti, deve essere ricercata la causa (errore) ed effettuata la relativa correzione da parte della progettazione ed eventualmente nuovamente testata per verificarne l‟eliminazione. Il test di alto livello è mirato a valutare le caratteristiche di usabilità, installabilità, manutenibilità e sicurezza del prodotto, essendo l‟affidabilità un obiettivo di secondo livello: se questa non è elevata in effetti l‟efficienza del test black-box si riduce drasticamente. Se da un lato questo tipo d‟approccio non richiede conoscenze approfondite della struttura del prodotto e quindi può essere affidato a personale con limitate conoscenze tecniche, dall‟altro è decisamente più efficace se eseguito da personale che conosce le esigenze dell‟utilizzatore e quindi il modo in cui il prodotto è effettivamente utilizzato; questo implica che il test deve essere condotto in condizioni le più simili possibile a quelle reali di utilizzo. Si parla di beta test quando la prova è condotta sul luogo effettivo di funzionamento (beta test), eventualmente in presenza del cliente. 16
  18. 18. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Le due macro famiglie raccolgono al proprio interno sei tipi di test: Alpha test Unit test Test di integrazione Test funzionale Test di accettazione Beta test A questi si aggiungono altri test con funzionalità specifiche (analisi critica dei requisiti di prodotto, test di usabilità, test sentinella, test progressivo o regressivo e test di occupazione di memoria). La figura 3 evidenzia le varie fasi di test all‟interno del processo produttivo del software partendo dall‟analisi dei requisiti fino al rilascio del prodotto sul mercato. Della famiglia dei test di basso livello fanno parte le prime due fasi di test: alpha-test e unit test, mentre della seconda famiglia fanno parte le restanti tipologie di test: integrazione, funzionale, accettazione e beta. Il test di basso livello è compito del team di sviluppo mentre il test di alto livello è eseguito e pianificato dal reparto di qualità in piena autonomia. Il reparto di sviluppo software dopo aver analizzato le specifiche funzionali fornite dal PM1 inizia lo sviluppo al termine del quale esegue l‟alpha test e lo unit test. Se durante queste prove il prodotto presenta problemi, non arriva alla fase successiva, altrimenti è rilasciato al reparto di qualità. Il team di verifica e validazione che riceve il prodotto per prima cosa prende visione della documentazione che accompagna il prodotto; dopo di che inizia le verifiche. 1 PM: Project Manager 17
  19. 19. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Figura 3: Fasi del test software all’interno del processo produttivo 18
  20. 20. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Il reparto esegue il test di integrazione e il test funzionale; se sono rilevati malfunzionamenti questi sono inseriti nel sistema di tracciamento bug ed il prodotto torna al reparto di sviluppo. Se invece si supera con esito positivo il test funzionale si passa alla fase di accettazione che se superata può portare al rilascio del prodotto al mercato o più comunemente alla realizzazione di un‟istallazione pilota in accordo con il cliente (Beta test). La realizzazione di un beta test (installazione dell‟applicativo sviluppato direttamente sul campo sotto controllo del reparto di QA2) consente di valutare il comportamento del software a fronte del reale stress a cui è sottoposto il prodotto una volta rilasciato. Osserviamo adesso ogni singola fase del test di sistema nel dettaglio evidenziandone i soggetti coinvolti e la modalità d‟esecuzione; le sessioni saranno analizzate secondo l‟ordine in cui le incontra il software che dal reparto di produzione procede verso il rilascio al mercato. Alpha test: è la prima sessione di test a cui è sottoposto il codice, tale fase come tutto il test di basso livello è esercitato in autonomia dal team di sviluppo e consiste in una rapida verifica del funzionamento dell‟applicativo realizzato. L‟alpha test mira a verificare macroscopicamente le funzionalità del software senza sollecitare il prodotto in maniera critica come invece verrà fatto nelle fasi successive. Unit test: L‟unit test è l‟attività di verifica delle singole componenti di un programma, cioè di moduli a se stanti, sotto-programmi e funzioni. E‟ eseguito sollecitando la logica interna del programma. Consente di associare 2 QA: Quality Assurance 19
  21. 21. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” in modo biunivoco malfunzionamento ed errore che ne è la causa. Deve essere eseguito in autonomia dal progettista, è infatti parte integrante della stesura del codice e per essere efficace richiede conoscenze inerenti lo specifico programma sotto test e il modo con cui è realizzato. Può richiedere la stesura di software di supporto che consentano di simulare parti di programma a cui il modulo sotto test si interfaccia. Di fatto lo unit test è l‟attività fondamentale necessaria a garantire un livello di qualità accettabile al software. Test di integrazione: consiste nel verificare il corretto funzionamento di una combinazione di componenti di un sistema. Tipicamente l‟obiettivo è l‟individuazione di eventuali errori nell‟interfaccia tra i moduli. L‟integrazione può ovviamente essere fatta a vari livelli: più moduli di un programma, più sottosistemi, più sistemi che devono operare congiuntamente. Anche le modalità con cui l‟integrazione è fatta sono diverse; anzitutto la scelta può essere tra integrazione in un‟unica soluzione (big bang) o in modo incrementale. E‟ indubbio che la soluzione incrementale è di gran lunga più efficace, perché consente di individuare in modo decisamente più semplice il componente in cui è presente un eventuale errore. Comunque il modo incrementale non e‟ univoco: top – down: a partire dai moduli più critici per funzionalità bottom – up: a partire da una struttura di base completa Non esiste in realtà una soluzione che a priori può essere considerata la migliore, tipicamente è opportuno decidere caso per caso adattandosi alle caratteristiche del sistema e al suo livello di evoluzione; tanto che in alcuni casi potrebbe essere più efficace seguire semplicemente il criterio dell‟ordine di disponibilità dei moduli. 20
  22. 22. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Tipicamente il criterio da utilizzare è quello che rende minimo il software di supporto da realizzare, per minimizzare i costi e l‟introduzione di malfunzionamenti collaterali. Il test di integrazione richiede, per essere efficiente, una decisione strategica su come affrontarlo e una ben definita pianificazione. Test funzionale o di sistema: è un test complessivo del sistema realizzato, che esercita le funzioni del prodotto sulla base dei requisiti definiti nella specifica funzionale. L‟ideale sarebbe poter disporre del manuale d‟uso dell‟apparecchiatura, che però raramente in questa fase del processo di sviluppo è disponibile anche a livello di bozza. In questa fase si tiene conto di tutti i potenziali utilizzatori del sistema e di conseguenza si va ad esercitare il sistema dal punto di vista di ciascuno di essi, comprendendo le funzioni di servizio: installabilità, usabilità, affidabilità, manutenibilità, sicurezza e rispondenza agli aspetti normativo-legali applicabili al prodotto. Il test deve essere naturalmente condotto esercitando le funzioni secondo le modalità di utilizzo previste; ma devono essere valutate anche condizioni di utilizzo improprio o comunque diverse da quelle progettate, ma comunque possibili e probabili. Laddove possibile ed applicabile è raccomandabile l‟analisi del sistema che utilizzi strumenti quali diagrammi degli stati (è molto diffusa la rappresentazione FSM, Macchina a Stati Finiti), che rendono più agevole una valutazione della copertura delle funzionalità e delle modalità di utilizzo. Altro aspetto importante è costituito dalla verifica di performance del sistema che deve essere posto sotto stress sia nelle condizioni operative e nei limiti previsti, che in condizioni estreme e quindi oltre i limiti massimi. La valutazione del prodotto non deve inoltre limitarsi alla ricerca di possibili malfunzionamenti ma anche all‟usabilità del sistema e quindi ad 21
  23. 23. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” aspetti relativi a facilità d‟uso, velocità di esecuzione e gradevolezza dell‟interfaccia. Test di accettazione: Serve per verificare la conformità del prodotto ai requisiti espressi dal cliente/mercato. E‟ tipicamente l‟ultima fase del processo di sviluppo prima dell‟installazione del prodotto su vasta scala. E‟ un test snello e rapido mirato a confermare il corretto funzionamento, effettuato al momento in cui, in base ai risultati delle fasi di test precedenti, si è confidenti sull‟assenza di malfunzionamenti significativi del prodotto. Si concentra su installabilità, usabilità, manutenibilità, sicurezza e rispondenza agli aspetti normativo-legali applicabili al prodotto. In questa fase sono messi sotto test anche i documenti che accompagnano il prodotto, quali ad esempio le istruzioni di uso, installazione e manutenzione, che costituiscono parte integrante del prodotto. Per sua natura il test di accettazione dovrebbe essere condotto alla presenza del cliente o quantomeno del cliente interno, cioè colui che ha commissionato (responsabile di prodotto/responsabile di progetto, PM) il lavoro e che può in questo modo rendersi conto se il prodotto risponde a quanto richiesto. Il test di accettazione potrebbe essere in effetti concordato con il cliente e l‟esito positivo sottoscritto per approvazione dalle parti. In pratica i test effettuati possono essere una selezione dei test funzionali e di sistema comprendono tipicamente test di non–regressione. Salvo accordi formali con il cliente, il test di accettazione è l‟occasione per una valutazione finale della conformità del prodotto a beneficio del cliente interno (PM): in questo caso il set minimo di test da eseguire è costituito da una sessione di test di non-regressione sui test falliti e risolti nelle fasi precedenti e una selezione dei test funzionali basata sulla priorità e criticità delle funzioni implementate. Le condizioni operative devono essere il più possibile quelle 22
  24. 24. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” reali e deve essere valutato il comportamento del sistema fino ai suoi limiti di funzionamento. Il test di accettazione si presta anche particolarmente a valutazioni comparative di prodotti similari, precedenti o concorrenti. Beta test: questa fase prevede il rilascio del prodotto verso alcuni clienti fidelizzati. Il software è costantemente monitorato dal reparto di qualità durante l‟utilizzo. Nella selezione dei siti prescelti per le prove di campo occorre molta attenzione per quanto riguarda configurazione; è necessario infatti poter contare su un campione significativo di casi per garantire in tempi ragionevoli la copertura del maggior numero di funzionalità del prodotto. Questa sessione di test rappresenta il primo impatto del prodotto sul campo, i clienti scelti devono essere opportunamente preparati al verificarsi di possibili malfunzionamenti. Quando il beta test è superato con esito positivo il software è rilasciato per la diffusione su larga scala. Le sei fasi di test elencate in queste pagine rappresentano le sessioni canoniche del test software a queste se ne possono aggiungere altre rispondenti ad esigenze specifiche; tali fasi possono essere incorporate nei test svolti durante il ciclo di produzione oppure esternamente al processo produttivo. Analisi critica dei requisiti di prodotto: è la prima forma di verifica relativa alla corretta e completa interpretazione dei bisogni del cliente ovvero dei requisiti del sistema: in termini di testing questo può tradursi in un esame critico della specifica funzionale. Per definire i test necessari alla verifica di conformità del prodotto è necessario approfondire l‟analisi dei requisiti e discutere il modo con cui sono implementati; in tal modo sarà possibile progettare i test il cui superamento consente di stabilire la conformità del prodotto ai requisiti. Questo consente 23
  25. 25. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” di ri-analizzare criticamente la specifica funzionale, quindi in definitiva i requisiti di progetto e anche di orientare il team di progettazione, fornendo i criteri in base ai quali il prodotto viene valutato/misurato. Il primo step di quest‟analisi è il rilievo delle funzionalità del prodotto e la definizione del funzionamento atteso. Tale forma di test è in pratica implicita nel lavoro di redazione del PdT. Test di usabilità: è concepito per verificare che il prodotto operi secondo i desideri del cliente/utilizzatore. E‟, come dice il nome stesso, improntato alla valutazione della facilità d‟uso e alla comprensione del suo impiego, delle sue potenzialità, dell‟accessibilità, delle caratteristiche di risposta, dell‟efficienza del sistema e dell‟interfaccia utente. Il test deve essere condotto con il diretto coinvolgimento del cliente/utilizzatore o del cliente interno (committente), che normalmente è rappresentato dal PM. Il test deve dare indicazioni sul gradimento del prodotto e la conferma operativa di aver centrato le richieste del cliente e/o fornire elementi per eventuali correzioni. Il test di usabilità dovrebbe essere effettuato non appena il prodotto ha le condizioni minime per poter essere utilizzato, pur con tutti i limiti di un prototipo ancora da sviluppare e testare in profondità, perché in caso di esito negativo gli aggiustamenti siano meno onerosi possibile. La prima sessione di questo tipo di test potrebbe essere programmata durante la sessione di integrazione, o addirittura nelle prime fasi dello sviluppo con prototipi realizzati ad hoc e tipicamente finalizzati alla verifica e validazione dell‟interfaccia utente. In relazione all‟entità del progetto, al contenuto innovativo del prodotto, al grado di fidelity del cliente può essere opportuno pianificare più sessioni di test di usabilità, in modo da mantenere sotto stretto controllo lo sviluppo del prodotto ed intervenire con tempestività in caso di deviazioni rispetto a quanto richiesto. E‟ importante 24
  26. 26. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” sottolineare ancora che il test non è improntato alla ricerca di malfunzionamenti, che anzi è prevedibile siano presenti in quantità significativa, particolarmente nelle prime sessioni, e quindi occorre porre molta cura nella sua preparazione ed in particolare nella preparazione del cliente. Test sentinella: A causa delle controindicazioni, in termini di ridotta efficienza del processo, del sottoporre ai test di alto livello un prodotto in una fase troppo prematura; ovvero in presenza di un livello qualitativo non adeguato, il processo di re-working è particolarmente oneroso in termini di costi e tempi, si rende quindi necessaria l‟individuazione di un indice che consenta di garantire l‟ingresso del prodotto alla fase di test funzionale al raggiungimento di un adeguato livello qualitativo. Il test sentinella è pensato a questo scopo. Si tratta di una sessione di test che dovrebbe fornire indicazioni sull‟indice di qualità del prodotto con un elevato livello di confidenza. La selezione dei test deve essere fatta con questo criterio. Il test deve essere eseguito con modalità simili ai test di alto livello, su esemplari dell‟apparecchiatura diversi da quelli impiegati nella fase di test di progetto e comprendere quindi una fase di installazione e configurazione del prodotto. Il test dovrebbe essere eseguito in collaborazione tra i team di sviluppo e di qualità e costituisce il momento di passaggio tra le due fasi del processo di sviluppo. Si ottimizza in tal modo il passaggio di consegne, sfruttando questa fase operativa per il necessario training agli addetti al testing. Il test deve essere snello e rapido e soltanto il suo superamento con esito positivo consentirà di procedere alla fase di prove di alto livello. Il test deve essere mirato all‟individuazione di possibili malfunzionamenti significativi; è importante che il test sia eseguito in un ambiente diverso da quello di progetto, ma su una apparecchiatura con una configurazione il più possibile vicina a quella di reale operatività del sistema. 25
  27. 27. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Test progressivo o regressivo: Per test progressivo si intende normalmente l‟attività di testing mirata alla verifica di nuove funzionalità di un prodotto; nel caso di un prodotto nuovo tutta l‟attività è tipicamente inquadrabile come progressive test. Per test regressivo o di non regressione si intende invece quell‟attività di testing mirata a verificare il corretto funzionamento del prodotto per le funzionalità già esistenti e consolidate, a seguito di nuovi sviluppi che hanno generato una nuova release o versione del prodotto. E‟ tipicamente un test in positivo, cioè di conferma, dal quale ci si aspetta in generale un esito favorevole, cioè che i requisiti di prodotto siano ancora rispettati, ma che mira ad individuare eventuali effetti collaterali sulle funzionalità consolidate del sistema per effetto delle modifiche eseguite. E‟ un attività che si presta bene come test di alto livello, ma può essere eseguita anche a livello di test di progetto. Si tratta di una fase di test molto onerosa e ripetitiva, che può risultare particolarmente efficace soltanto se automatizzata; in tale ottica questo lavoro si prefigge di individuare una procedura e delle metodologie per automatizzare in maniera snella i test di non regressione del software. Test di occupazione memoria: I problemi di memory leak ed accesso errato ad aree di memoria sono i malfunzionamenti software che hanno le conseguenze più gravi sulla sicurezza e sulla disponibilità del sistema che ospita l‟applicativo. I memory leak sono causati dall‟allocazione di memoria che non è poi successivamente de-allocata: questo comporta un aumento del file di paging compromettendo le prestazioni complessive del sistema. Nel caso peggiore può verificarsi l‟esaurimento delle risorse disponibili di memoria portando al crash dell‟applicativo [8]. Uno dei più famosi guasti software di questo tipo si è verificato a Londra nel 1992 quando l‟applicativo di gestione delle autoambulanze londinesi ebbe un crash dovuto a memory leaks alle 2 del mattino, che portò al blocco dei mezzi di soccorso per oltre 2 26
  28. 28. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” ore [9]. L‟allocazione della memoria di sistema da parte dei processi è gestita attraverso regole impostate sul compilatore utilizzato per compilare il singolo applicativo. Tutti i linguaggi di programmazione hanno delle regole di gestione della memoria predefinite che sono applicate salvo una diversa gestione definita dallo sviluppatore. Tali regole sono ottimizzate per molte applicazioni e rappresentano un compromesso fra le varie necessità che possono avere le diverse tipologie di programmi implementabili con il particolare linguaggio di programmazione preso in esame. Per individuare e correggere questi bachi si effettuano test specifici composti di poche azioni ripetute per un numero significativo di iterazioni che vanno a sollecitare un numero limitato di moduli di un applicativo, tipicamente anche un solo modulo. Durante le ripetizioni è tenuta sotto controllo l‟occupazione di memoria del modulo in test, per tracciarne l‟andamento. Se a termine prova è individuato un andamento monotono crescente della memoria allocata, il bug è comunicato al reparto di sviluppo per le opportune correzioni al termine delle quali sarà replicato il test. Per effettuare questo tipo di prove si deve obbligatoriamente ricorrere all‟automatizzazione delle sequenze, in quanto per ottenere risultati significativi si devono eseguire molte ripetizioni di un set limitato di operazioni. Per automatizzare le prove può essere necessario l‟utilizzo di simulatori che per non influenzare il risultato delle prove devono avere elevata affidabilità. 27
  29. 29. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” 1.4 Pianificazione dell’attività di test La redazione del PdT è attuata dal responsabile dell‟attività di testing, che sarà supportato dal project manager e dal team leader di sviluppo. Il PdT utilizza come documento di riferimento la specifica funzionale, ma terrà naturalmente conto di altri documenti ritenuti utili, quali ad esempio la specifica tecnica o report di fasi di test precedenti o di apparecchiature similari. A seguito di variazioni dei documenti di riferimento, che abbiano rilevanza sulla strategia di test, il PdT deve essere sottoposto a procedura di revisione. Prima di qualsiasi altra considerazione è necessario allinearsi su alcuni principi fondamentali legati all‟attività di testing. Il test di un prodotto non può essere, in generale, esaustivo. Non è infatti ipotizzabile che sia possibile pensare tutti i test case3 necessari alla verifica di un prodotto, né tanto meno progettarli ed eseguirli in tutte le possibili condizioni al contorno, con tempi e costi accettabili. L‟attività di test deve quindi esser il frutto di un compromesso tra la necessità di massima copertura del prodotto in termini di verifica delle sue funzionalità e le esigenze in termini di costi e tempo. Questo significa definire delle priorità delle funzioni da testare in base a criteri di frequenza di utilizzo, criticità e rischio. Fra gli scopi principali dell‟attività di test ci sono i seguenti requisiti: focalizzare la fase di test all‟effettivo utilizzo cui il prodotto è destinato e migliorare la condivisione della 3 Test case: situazione d‟uso, tipica sequenza operativa ipotizzata per il prodotto. 28
  30. 30. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” strategia di test cui il prodotto deve essere sottoposto per dichiararne la conformità ai requisiti, rendendo più oggettiva possibile la valutazione del prodotto. Test case: per individuare un test case devono essere note e definite le seguenti informazioni: La configurazione del sistema Lo Stato Iniziale (SI) del sistema prima di eseguire il test I parametri di sistema Le variabili in input Le variabili in output Le condizioni al contorno (condizioni operative) Lo Stato Finale (SF) del sistema atteso dopo aver eseguito il test Come abbiamo già detto non è possibile pensare tutti i test case, ovvero tutte le sequenze che possono essere attuate con quel determinato software. Si possono avere più sequenze che testano la medesima funzionalità. In questo caso si parla di classe di equivalenza ovvero di un insieme di test caratterizzati dalle seguenti proprietà: Sono pensati per la verifica della stessa funzionalità Lo stato finale atteso del sistema è lo stesso per tutti Se un test è in grado di rilevare un malfunzionamento allora qualsiasi altro test della stessa CdE (classe di equivalenza) ha la stessa probabilità di rilevarlo Se un test non è in grado di rilevare un malfunzionamento allora qualsiasi altro test della stessa CdE ha la stessa probabilità di non rilevarlo L‟individuazione di classi di equivalenza consente di sostituire più test case che appartengono alla stessa CdE con uno solo rappresentativo della stessa. Le classi di equivalenza così definite sono del tutto soggettive ed 29
  31. 31. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” essendo il numero di test pressoché infinito anche il numero di CdE è immenso. Occorre quindi selezionare prima le classi di equivalenza e poi selezionare i test rappresentativi delle CdE scelte [7]. Per capire qual è il principio di selezione attraverso le CdE, supponiamo di dover testare la funzione f(x) che accetta ingressi (x) tali che: x ≥ 1 e x ≤ 99 E‟ ragionevole pensare che esercitare la funzione con: x = - 15 consenta di valutare il comportamento della funzione per tutti i numeri negativi x = 175 consenta di valutare il comportamento della funzione per tutti i numeri con più di 2 cifre x = 50 consenta di valutare il comportamento della funzione per tutti i multipli di 10 x = 19, 28, 37, 46, 55, 64, 73, 82, 91 può essere un campione significativo del dominio a 2 cifre x = 0, 1, 99, 100 valori di frontiera x = 3, 4, 7, 8 può essere un campione significativo del dominio a 1 cifra Esercitando la funzione con 20 valori di ingresso ho una ragionevole probabilità di aver coperto tutto il range di valori di uscita della funzione. Il grafico di figura 4 [10] mostra l‟andamento di alcune grandezze caratteristiche al variare del numero di CdE. La probabilità di rilevare un bug 30
  32. 32. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” ed i costi crescono all‟aumentare del numero di classi di equivalenza, mentre la probabilità di reale utilizzo4 del sistema decresce esponenzialmente. 1 Robustezza P Ril. (Bug) 0,5 Costo P Reale Ut. 0 N. CdE Figura 4:Andamento della robustezza del sistema, probabilità di rilevare un malfunzionamento, costi e probabilità del reale utilizzo del sistema in funzione del numero di classi di equivalenza. L‟andamento della probabilità di reale utilizzo si spiega considerando che all‟aumentare delle CdE si va a considerare situazioni di utilizzo sempre più particolari con ingressi improbabili. A questo proposito è utile confrontare le classi di equivalenza attraverso la matrice delle ipotesi (tabella 1). La matrice delle ipotesi è realizzata per la singola funzionalità da testare e permette il confronto fra le classi di equivalenza per tale funzionalità evidenziando per ogni classe la probabilità di accadimento del test case considerato (p). 4 Probabilità di reale utilizzo del sistema: probabilità che la sequenza di test associata alla CdE in esame sia eseguita sul campo. 31
  33. 33. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Tabella 1: Matrice delle ipotesi relativa alla funzionalità di prevalida di carte petrolifere, nella matrice si considerano le carte petrolifere più comuni (EuroShell ed EssoCard); per ogni test case è riportata in grassetto la probabilità di accadimento calcolata mediante l’analisi di dati provenienti dall’archivio GVR. Card check CdE 1 CdE 2 CdE 3 Note Due carte Due carte (Carta A e Una sola carta (Carta A e Carta B)) da prevali Carte da prevali (Carta A) da Carta B) da dare, la Carta B è dare prevalidare prevalidare scaduta p=0,4 p=0,4 p=0,2 Server / client Stampa automatica ticket di prevalidazione Stampante off-line PPEU off-line Valutazione del rischio: uno dei più efficaci criteri di selezione dei test è quello basato sulla valutazione del rischio, inteso come prodotto della probabilità del manifestarsi di un malfunzionamento per la gravita dei suoi effetti. Per valutare il rischio di un malfunzionamento software si usano i seguenti criteri: Gravità degli effetti di malfunzionamento in termini di: danni prodotti, tempi di indisponibilità del sistema, sanzioni, frodi, etc. Criticità della funzione Importanza della funzione Frequenza d‟uso della funzione Ripetibilità della sequenza Evidenza e sensibilità al malfunzionamento 32
  34. 34. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Una selezione sul criterio della criticità è utile non solo per selezionare i test da effettuare ma anche per definire una strategia di priorità nell‟esecuzione del testing. Tipicamente i malfunzionamenti si concentrano sui punti notevoli di una funzione; punti notevoli sono i cosiddetti valori di frontiera o quelli caratterizzati da vincoli di qualsiasi natura. I valori di frontiera di una funzione sono tipicamente i valori estremi del suo dominio di ingresso o di uscita. I punti di vincolo sono quelli caratterizzati da un vincolo tra input ed output la cui natura può essere geometrica, fisica, legislativa, normativa, monetaria, legata all‟unita di misura. Considerazioni di questo tipo, che logicamente si prestano ad essere implementate più facilmente nel test di basso livello, consentono l‟individuazione di test con elevata probabilità di fallire. Il superamento con esito positivo di questi test è normalmente un indice di buona qualità. La criticità di un malfunzionamento è una classificazione del bug in funzione del sua gravità; in base a questa classificazione si decidono le priorità di intervento sul codice, agendo prima sui bachi più critici e successivamente sugli altri. Si possono verificare situazioni dove un software è rilasciato in presenza di malfunzionamenti dichiarati nella sua nota di rilascio (Release Note) purché la loro criticità sia ritenuta lieve. In seguito è riportata la classificazione della gravità di un bug adottata in GVR [11]. Cat. A Critici: possono causare perdite di dati e interruzione delle operazioni, per cui è necessario un intervento dell‟operatore per riattivare il processo. Cat.B Gravi: causano un notevole abbassamento delle prestazioni e/o producono risultati insignificanti costringendo l‟utente ad usare diversi approcci. 33
  35. 35. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Cat.C Medi: il software riesce ad attivarsi automaticamente, riesce ad aggirare il malfunzionamento; le prestazioni risultano leggermente inferiori e si riscontra una certa difficoltà ad interpretare il messaggio visualizzato dall‟elaboratore. Cat.D Bassi: non provocano alcuna diminuizione delle prestazioni del software in oggetto, sono per lo più errori di presentazione dell‟interfaccia che possono causare cattive interpretazioni. Cat.E Saltuari: malfunzionamenti di tipo non ripetitivo, l‟eliminazione del problema ha richiesto l‟implementazione di un nuovo algoritmo poichè non è stato possibile capire la causa SWR del malfunzionamento. Cat.F Incongruenti: il sistema pur funzionando correttamente ha un comportamento non conforme coi requisiti espressi nelle specifiche; in altre parole è stato realizzato un prodotto ben funzionante ma non era il prodotto che si voleva realizzare. Tracciamento dei malfunzionamenti: Quando si ha un ciclo di produzione del software organizzato, si ha una ben precisa definizione delle attività di sviluppo, di testing e di produzione. Il codice prodotto è sottoposto a varie fasi di verifica; tutti i malfunzionamenti trovati ad ogni controllo sono inseriti in un database che permette di tracciare tutti i bug rilevati per un determinato processo e tutte le azioni di correzione apportate al codice per la soluzione del problema. Ogni fault è annotato segnalando la funzionalità che presenta il problema, la sua frequenza di accadimento (se determinata), la sua criticità, la versione del prodotto su cui è stato riscontrato il problema, l‟esatta sequenza che riproduce il problema (se è stata individuata) e le condizioni al contorno nel quale si verifica l‟evidenza del malfunzionamento. 34
  36. 36. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Il tracciamento dei malfunzionamenti ha molteplici vantaggi: Associa al problema le relative azioni correttive Se la parte di codice dove è rilevato il problema è comune a più progetti, tutti i progetti hanno la disponibilità delle migliorie apportate al codice Possibilità di individuare le versioni contenenti le righe di codice malfunzionante Visione completa di tutti i bug relativi ad un progetto così da poter pianificare le azioni correttive secondo priorità Il tracciamento delle versioni (versioning) durante lo sviluppo di un prodotto software permette di tenere traccia di ogni modifica apportata al codice, garantendo la possibilità di poter regredire ad una versione precedente in ogni momento e di collegare l‟insorgere di un malfunzionamento ad una particolare versione e quindi alle modifiche ad essa relative. 35
  37. 37. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Capitolo 2 2.1 Azienda e prodotti In questo capitolo saranno presentati alcuni prodotti software ed hardware sui quali verranno implementate analisi sperimentali per l’incremento dell’affidabilità. Sui prodotti scelti in funzione di esigenze specifiche dell’azienda produttrice si vuole dimostrare i vantaggi del test software automatico rispetto a quello tradizionale. 36
  38. 38. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” 2.2 Storia dell’azienda La Gilbarco S.p.A Italia con sede a Firenze nasce nel 1969 con il nome di Logitron. La Logitron inizia la sua attività nel settore della distribuzione all‟utenza dei carburanti e si specializza nei sistemi di prepagamento con banconote. Nel 1974 sigla un accordo con la Gilbarco Ltd. per la vendita dei propri prodotti in tutta Europa ed estende la produzione agli erogatori con testata elettronica. Nel 1980 sviluppa e commercializza un sistema completo per la distribuzione dei carburanti e dieci anni dopo inizia a vendere i propri prodotti al di fuori dei confini europei. Nel 1999 la compagnia entra a far parte del gruppo Gilbarco e nel 2000 prende il nome Marconi Commerce Systems; nel 2002 la Gilbarco è acquisita dalla Danaher Corporation ed inizia una collaborazione strategica con la VeederRoot con la quale completa la sua offerta di prodotti specializzati alla distribuzione dei carburanti. L‟attuale nome dell‟azienda è Gilbarco Veeder- Root [12]. La Danaher Corporation è una multinazionale americana che raggruppa con il suo marchio oltre 50 compagnie per un fatturato annuo di 9 miliardi di dollari; la multinazionale opera principalmente in sei settori produttivi: Test elettronici Utensili meccanici Automazione Tecnologie mediche Soluzioni per l‟ambiente Identificazione dei prodotti 37
  39. 39. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Fra le tante aziende del gruppo spiccano i nomi di Fluke, Vision BioSystems, Red Jacket, Armstrong Tools e Raytek. Attualmente la Gilbarco Veeder-Root è l‟unica azienda che offre prodotti e servizi per le aree di amministrazione dei carburanti (dal punto di vista di normative a ambiente) di gestione dei piazzali delle stazioni di servizio (pompe e controllori) e di pagamenti automatici (POS5, BOS6) . 2.3 I prodotti dell’azienda Il prodotto di punta di Gilbarco è il sistema Passport che permette di implementare la totalità della gestione di un punto di distribuzione del carburante dal controllo delle pompe e quindi dell‟erogato (attraverso il controllore di piazzale) alla gestione delle cisterne (mediante centraline e sensori Veeder-Root) ai pagamenti elettronici (POS) al collegamento dei terminali di pagamento esterni (OPT7 e Crind8) o moduli di raccolta ed invio dati alle compagnie petrolifere (WISE9). 5 POS: Point Of Sale la traduzione letteraria è punto di pagamento, nella pratica l‟acronimo POS indica un sistema in grado di accettare pagamenti elettronici. 6 BOS: Back Office System indica la gestione di tutto ciò che non è vendita diretta al cliente come la gestione del magazzino, delle scorte, la gestione delle cisterne e dei modi operativi delle pompe e del piazzale. 7 OPT: Outdoor Payment Terminal, terminale di pagamento esterno; è un sistema che si interfaccia all‟utente permettendogli di accedere ai servizi offerti dal punto di distribuzione anche senza rivolgersi al gestore dell‟impianto. 38
  40. 40. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” . Figura 5: Sistema Passport Passport10: rappresenta sia un architettura hardware che software (figura 5 e 6); per quanto riguarda la parte hardware integra un elaboratore elettronico commerciale con una scheda SPU11 o CORE12. Tutto il sistema è racchiuso 8 Crind: Card reader in Dispenser, lettore di carte sull‟erogatore; sono particolari erogatori di carburante che integrano nella pompa stessa un sistema per effettuare pagamenti elettronici. 9 WISE: Wireless Internet Service Enabler, è un sistema che permette di interfacciare direttamente la stazione di servizio alla rete internet in modo tale da poter continuamente tenere sotto controllo l‟impianto ed intervenire nel caso di malfunzionamenti (19). 10 In questa trattazione con la parola Passport si intenderà il prodotto Passport Europe con personalizzazione Italia, versione del sistema installata sul territorio nazionale. 11 SPU: Site Processing Unit, è una scheda che offre sia un‟espansione della connettività del PC attraverso una multi seriare che un controllo di integrità sul software installato mediante la verifica dell‟informazioni contenute in una carta metrica collegata alla SPU. 39
  41. 41. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” in un robusto case che a termine dell‟assemblaggio è piombato in modo tale da evidenziare un‟eventuale tentativo di frode. Quando la macchina si avvia lancia automaticamente il software di gestione rendendo inaccessibile all‟utente tutta la macchina a meno del software GVR13. La SPU o la CORE hanno 10 (o 20) seriali attraverso le quali il passport è interfacciato alle periferiche di piazzale (SPOT14, OPT, Crind, centraline di livello e pompe), a stampanti fiscali e non, ai cassetti dei cassieri, a display utente ed a tutti i Figura 6: Passport Stand-Alone (Server) dispositivi che il gestore intende installare sulla stazione. Il Passport è collegato mediante rete ADSL15, PSTN16, ISDN17 o GPRS18 sia per effettuare transazioni elettroniche che per eseguire la manutenzione da remoto sull‟impianto; è infatti possibile effettuare l‟aggiornamento del software installato senza inviare un tecnico sul sito 12 CORE: è il cuore del sistema Passport Europe, permette di trasformare un comune PC in un sistema in grado di gestire un intera stazione di servizio espandendone la connettività seriale attraverso protocolli RS-232,422 e RS-485. 13 GVR: Gilbarco Vedeer-Root 14 SPOT: Secure Payment Outdoor Terminal, Terminale di pagamento esterno sicuro, è il terminale esterno di nuova generazione nato dall‟esperienza maturata con OPT. Tale sistema ha conseguito la certificazione EMV (Europay, Mastercard e Visa) di livello 2. 15 ADSL :Asymmetric Digital Subscriber Line, tecnologia che permette l‟accesso ad internet ad alta velocità. 16 PSTN: Pulse Switched Telephone Network rappresenta lo standard della linea telefonica analogica distribuita sul territorio nazionale. 17 ISDN: Integrated Services Digital Network, rete digitale a servizi integrati. 18 GPRS: General Packet Radio system, tecnologia per il trasferimento dati che sfrutta i i canali della rete GSM con tecnologia a divisione di tempo. La tariffazione di questo servizio è funzione dei pacchetti inviati e non della durata della connessione. 40
  42. 42. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” (tranne nei casi in cui sia necessaria una riconfigurazione hardware del sistema). Oltre il 75% degli impianti di distribuzione italiani sono gestiti mediante il sistema Passport Europe. Terminali di pagamento esterni: il sistema OPT è il primo sistema di pagamento esterno completo sviluppato da Gilbarco (figura 7). OPT offre un alto grado di efficienza della stazione di servizio accelerando le operazioni di rifornimento con particolare riguardo alla Figura 7:OPT installato su di una stazione di servizio. soddisfazione dei clienti. L‟operatività della stazione è estesa alla totalità delle 24 ore anche quando non è presente il personale. Il terminale viene posizionato sul piazzale della stazione ed è collegato (in genere) a tutte le pompe presenti sull‟impianto. L‟utente si trova ad interagire con un sistema che grazie alla presenza del display grafico risulta intuitivo e semplice; durante le normali operazioni di pagamento delle erogazioni possono essere inviate al cliente comunicazioni personalizzate e messaggi pubblicitari [13]. I metodi di pagamento previsti sono banconote (di diverso taglio), carte di debito e carte private, è sempre garantita la corrispondenza tra il carburante erogato e l‟ammontare del pagamento il tutto verificabile attraverso la ricevuta emessa dal terminale. L‟OPT non è solo un interfaccia attraverso cui il cliente si relaziona alla stazione di servizio ma permette anche lo scarico del carburante nelle cisterne in assenza del personale sulla stazione. Il sistema è disponibile in varie versioni: 41
  43. 43. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Stand-alone: che ha al suo interno tutta l‟intelligenza necessaria alla gestione della stazione di servizio. Slave: versione per l‟uso come terminale di piazzale asservito ad un‟unità centrale di stazione che controlla e gestisce tutte le operazioni. Entrambe le versioni sono dotate di colonna di sostegno che permette l‟ancoraggio al suolo e che contiene la cassetta di sicurezza per la raccolta delle banconote nel caso in cui il dispositivo sia equipaggiato con lettore di banconote oltre che con lettore di carte. In Italia ci sono oltre 10.000 OPT installati su impianti di varie compagnie petrolifere. Il sistema SPOT (figura 8) appartiene alla famiglia di terminali self service di ultima generazione prodotti dalla Gilbarco Veeder-Root; utilizza la PIN Pad SPOT M219 progettata per il pagamento sicuro con carte di debito/credito, sia a Figura 8:Testata SPOT nella schermata banda magnetica che chip. SPOT M2 è certificata: di IDLE. EMV20 Level 1 EMV Level 2 PCI PED21 19 SPOT M2 è l‟ultimo modello di terminale esterno che alla data di stesura di questo testo è stato rilasciato al mercato; il modello SPOT M3 ha già concluso la fase di sviluppo e sarà presto presentato. 20 EMV: Europay Mastercard Visa, standard nato nel 1993 dalla collaborazione dei principali circuiti di pagamento elettronico a livello mondiale. La piattaforma fondata (EMVCo) mira allo sviluppo dei pagamenti elettronici sicuri attraverso carte a microprocessore (smart card). 42
  44. 44. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” L‟elettronica di controllo e gestione della stazione di servizio è totalmente separata da quella che gestisce i pagamenti in modo da massimizzare prestazioni e sicurezza. Il Terminale SPOT consente il rifornimento di carburante self service in modo semplice, veloce e sicuro garantendo la completa gestione ed il controllo della stazione di servizio in modalità non presidiata. Grazie a queste caratteristiche rende possibile l‟apertura senza personale della stazione di servizio 24 ore su 24, 7 giorni su 7 [14]. Il terminale è dotato di ampio display a colori ad alta illuminazione che lo rende ben visibile in ogni condizione di luce, anche grazie ad un design studiato per evitare l‟incidenza dei raggi solari. E‟ possibile abilitare una voce guida che illustra all‟utente le varie opzioni disponibili nelle diverse fasi di vendita. SPOT è equipaggiato con soft key retro-illuminate per le scelte utente oltre a pulsanti dedicati alla selezione degli erogatori. SPOT offre un elevato standard di sicurezza sia al gestore che all‟utente, l‟accettatore di banconote è dotato dei più sofisticati sistemi antifrode e reiezione di falsi. Le banconote sono conservate in una colonna di sicurezza antieffrazione certificata, ancorata al sistema di fondazioni del terminale. La piattaforma di pagamento con carte, SPOT M2, offre la massima garanzia di sicurezza nelle operazioni di pagamento e nel trasferimento dei dati sensibili (PIN e dati carta). Il terminale è stato progettato utilizzando accorgimenti per la prevenzione dal rischio di clonazione della carta o il furto d‟identità (Dispositivo Anti-Skimming; Patent 21 PCI PED: Payment Card Industry – Pin Entry Device, è uno standard emergente nei pagamenti elettronici con carte magnetiche e chip, il suo scopo è quello di definire le caratteristiche di sicurezza dei POS nell‟accettare le carte e creare maggiore confidenza nel titolare della carta per un suo uso diffuso. 43
  45. 45. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Pending). Il design del terminale è stato studiato per garantire all‟utente la massima privacy nelle operazioni di pagamento. Il terminale è dotato di un potente sistema diagnostico in grado di rilevare anomalie ed eventi notevoli e gestirne la segnalazione e le eventuali contromisure. Il sistema controlla il piazzale, gestendo in modo completamente automatizzato l‟autorizzazione del pagamento e l‟abilitazione al rifornimento. Inoltre memorizza i dati relativi a tutte le transazioni eseguite ed è in grado di fornire report contabili strutturati; esportabili via protocollo seriale su PC e disponibili anche da remoto (opzione disponibile in combinazione con il servizio raccolta dati del sistema WISE). Come OPT, SPOT consente le attività di carico in cisterna del carburante, anche in assenza di personale (opzione disponibile in combinazione con il Sistema di gestione della stazione di servizio PPEU). SPOT è disponibile in due versioni: Master (Stand-alone): per il Figura 9:Crind nella schermata di IDLE. controllo integrale della stazione di servizio. Slave: terminale associato ad un server di gestione della stazione di servizio 44
  46. 46. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Sia i terminali SPOT che OPT sono disponibili anche in modalita Crind (o RID22, figura 9) ovvero integrati nella pompa. Questo sistema è dotato soltanto di lettore di carte magnetiche eo chip, pertanto non è prevista la modalità di pagamento con banconote23. Sono disponibili i kit di retrofit per l‟installazione di RID e Crind anche sulle pompe già presenti sulla stazione [15]. Oltre il 75% dei terminali esterni installati sul territorio nazionale sono prodotti da Gilbarco. BasePOS: è un prodotto nato quando un cliente di rilievo dell‟azienda ha manifestato la volontà di aggiornare i propri impianti attualmente equipaggiati con il sistema passport con un prodotto di nuova concezione che mantiene il backoffice24 del sistema Passport con il frontoffice25 di una azienda concorrente ed un hardware di un PC commerciale. Questa soluzione comporta un notevole risparmio economico nell‟acquisto delle due semi-parti da due software-house distinte e dal vantaggio di non essere vincolati ad una piattaforma hardware specifica. Il sistema così realizzato è installabile su qualsiasi PC commerciale senza dipendere da una particolare struttura. 22 RID: Reader In Dispenser, Lettore nell‟erogatore integrazione dell‟OPT nella pompa di distribuzione. 23 RID e CRIND sono equipaggiati soltanto con lettore di carte elettroniche, questo fa si che il sistema non abbia una ampia diffusione sul territorio italiano dove non c‟è ancora una cultura diffusa nell‟uso dei metodi di pagamenti elettronici. 24 Backoffice: parte del software relativo alla gestione dei pagamenti elettronici, del magazzino e delle cisterne. 25 Frontoffice: software relativo alla gestione del piazzale (modo operativo delle pompe, pagamento delle erogazioni e vendita diretta al cliente). 45
  47. 47. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” La configurazione hardware di un sistema BasePos prevede due installazioni di base: il server ed il client (o i client). La macchina client è un comune PC commerciale dotato di connessione di rete (necessaria per il collegamento al server) e di almeno una porta seriale per il collegamento del terminale POS (Point of sale). La macchina server è anch‟essa un PC commerciale con l‟aggiunta però di alcune periferiche che permettono di estendere la connettività dell‟elaboratore verso i dispositivi installati sulla stazione di servizio (pompe, terminali esterni, e centraline di livello). Le periferiche che realizzano questi collegamenti sono una multiseriale ed una scheda realizzata da ITL (partner di Gilbarco nel progetto BasePos) che prende il nome di Enabler. La prima permette il collegamento ai terminali esterni (OPT, SPOT e CRIND), ai terminali POS ed alle centraline di livello delle cisterne mentre attraverso la seconda si realizza il collegamento alle pompe. Il collegamento fra l‟enabler e le pompe non è diretto ma avviene attraverso un‟ulteriore scheda chiamata FDM (Forecourt Distribution Module, Modulo di distribuzione di piazzale). Vediamo nel dettaglio le tre periferiche collegate al server: La multiseriale: che permette di avere più porte seriali per il collegamento alle varie periferiche esterne all‟elaboratore che utilizzano il protocollo RS-232. L’enabler: che permette il collegamento alle pompe attraverso il modulo del controllore di piazzale (FDM). Forecourt Distribution Module (FDM): è il nodo intermedio fra pompe ed enabler. La prima scheda è una normale espansione seriale di tipo commerciale, mentre, l‟enabler ed il controllore di piazzale sono periferiche specifiche 46
  48. 48. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” realizzate da ITL per la gestione del proprio sistema e quindi interessante esaminarle in maniera approfondita. Enabler (figura 10): utilizza il bus standard PCI (Peripheral Component Interconnect) e permette di espandere la connettività dell‟elaboratore per quanto riguarda il collegamento ai dispositivi del piazzale. La tecnologia realizzativa della Figura 10: Scheda Enabler scheda è a montaggio superficiale (SMT, Surface Mount Tecnology) e permette di realizzare in unica scheda stampata l‟intero circuito contenendone le dimensioni L‟enabler dispone di 5 canali (uscite) indipendenti per la gestione delle varie periferiche del piazzale: 1 canale è dedicato alla gestione di IFSF LON (International Forecourt Standard Forum LON, protocollo standard per il collegamento agli erogatori), 3 canali configurabili per i dispositivi tradizionali del piazzale ed 1 dedicato alla gestione degli altri dispositivi del piazzale come ad esempio le centraline di livello. La scheda è in grado di gestire una grande quantità di protocolli proprietari e standard relativi al collegamento di periferiche di distribuzione del carburante (erogatori, terminali esterni e centraline di livello). La scheda é compatibile con tutti i sistemi operativi successivi a Windows NT, é dotata di controlli ActiveX e supporta l‟accesso e la gestione dei database attraverso ODBC (Open Database Connectivity). 47
  49. 49. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” FDM: Il modulo FDM realizza il collegamento fra l„enabler PCI e le pompe; il dispositivo è disponibile in due versioni, una passiva ed una attiva. La versione passiva (figura 11) è utilizzata per connettere le pompe che sfruttano il protocollo RS-485 o lo standard IFSF-LON. Il vantaggio di questo dispositivo è il rapporto qualità prezzo che lo rende un‟alternativa economica ed affidabile ai dispositivi di gestione delle pompe degli altri produttori. I protocolli non supportati dal nodo passivo sono stati implementati nel FDM attivo (figura 12). Figura 11: FDM passivo. Figura 12:FDM attivo. A bordo del dispositivo attivo è integrato un sistema di diagnostica che permette di monitorare in tempo reale lo stato dei canali. In tabella 2 è riportato il significato dei LED di diagnostica. 48
  50. 50. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Tabella 2: Led di diagnostica FDM attivo Led Colore Descrizione Indica la presenza di LD1 Arancio alimentazione LD2 Rosso Dati in ricezione LD3 Verde Dati trasmessi Il numero indica il canale e LDA1 LDA8 Verde questi led indicano il transito dei dati sul canale La tipica configurazione di base di un piazzale gestito dal sistema BasePOS è riportata in figura 13. Il sistema può avere fino ad un massimo di 4 FDM collegati al server e fino ad 8 pompe per ogni distributore di piazzale per complessive 32 pompe (bi-lato). Ad ogni server possono essere collegati più client ed ad ogni client può essere collegato un POS. Nello schema non è evidenziata la connessione ai terminali esterni; posso collegare fino ad otto terminali su ogni seriale del sistema (al massimo posso avere 32 terminali esterni, 8 terminali per seriale per un massimo di 4 seriali impegnate). La connessione al terminale esterno avviene mediante protocollo RS-422, la conversione dal seriale standard (RS-232) al 422 avviene mediante un convertitore di protocollo. 49
  51. 51. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Figura 13: Architettura tipica di un sistema BasePOS Figura 14: Insieme di prodotti GVR. 50
  52. 52. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Altri prodotti: oltre ai prodotti illustrati nei paragrafi precedenti, dispone di pompe, centraline di livello e sensoristica per le cisterne, moduli WISE e car wash (figura 14). Tutti i prodotti sono compatibili oltre che con gli altri dispositivi GVR anche con i prodotti concorrenti dei maggiori marchi presenti sul mercato; la compatibilità è garantita in parte direttamente a livello di prodotto ed in parte attraverso l‟interposizione di particolari controllori di piazzali progettati appositamente per questo scopo. 2.4 Prodotto software I prodotti che producono maggior volume di affari per l‟azienda sono i software di gestione delle stazioni di servizio; questi software sono soggetti a continue modifiche ed aggiornamenti con l‟obbiettivo di essere sempre in accordo con le normative che li riguardano, gli standard di accettazione dei pagamenti elettronici, le attese del cliente che si reca sull‟impianto per effettuare il rifornimento e le richieste del committente (la compagnia petrolifera). L‟insieme dell‟esigenze dei vari soggetti porta il ciclo vita medio del software una volta rilasciato ad essere di tre mesi. Vista la breve vita del prodotto è necessario che questo non presenti bug all‟interno del suo ciclo 51
  53. 53. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” vita. L‟azienda investe numerose risorse nel controllo di qualità del prodotto o meglio nella quality assurance26 (QA). Al momento che lo sviluppatore ha terminato di scrivere il codice relativo al programma esegue l‟alpha test dopo di che il prodotto arriva accompagnato dalla relativa release note27 al reparto del controllo di qualità. In questa fase il personale di verifica e validazione (V&V28) esegue i test funzionali. I problemi rilevati sono inseriti in un database per il tracciamento dei malfunzionamenti, e sono catalogati per personalizzazione, per versione del programma e per area funzionale. 26 QA: Quality assurance, significa assicurazione di qualità. E‟ il processo necessario perché il prodotto abbia un elevato grado di qualità in uso. 27 Release note: documento che accompagna il software e che ne descrive le caratteristiche e le novità rispetto ad eventuali versioni precedenti. 28 V&V agent: i ruoli di tutte le figure inerenti il processo di V&V saranno oggetto del capitoli successivi. 52
  54. 54. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” Capitolo 3 3.1 Applicazione dei test automatici alla non regressione In questo capitolo si presenta la prima delle applicazioni dei test automatici; quella relativa ai test di non regressione. La metodologia descritta in queste pagine è del tutto generale e può essere utilizzata per effettuare test di non regressione software su qualsiasi prodotto. Nello specifico l’applicazione interessa la non regressione di BasePOS prodotto in parte internamente ed in parte da un’azienda esterna. L’azienda esterna si è fatta carico del controllo di qualità dell’intero sistema. Questa soluzione richiede che il prodotto rilasciato verso l’azienda responsabile dell’integrazione del sistema abbia un elevato grado di affidabilità. Le funzionalità previste saranno tutte funzioni considerate 53
  55. 55. Analisi sperimentali per l’incremento dell’affidabilità del software per la “gestione distribuzione carburante” consolidate in quanto erano già presenti nelle ultime versioni di Passport Europe realizzate per il cliente e quindi tutti i test software eseguiti sulla versione sono test di non regressione e di verifica della corretta integrazione fra i moduli software. 54

×