Tesi Magistrale

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

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


Conclusioni................................................................................................... 91

Appendice A ................................................................................................. 93

Bibliografia ................................................................................................... 97

3


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


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


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


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


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


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


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


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


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


(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


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


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


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


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


Figura 3: Fasi del test software all’interno del processo produttivo

18


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


.

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


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


(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


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


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


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


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


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


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


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


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


Figura 13: Architettura tipica di un sistema BasePOS

Figura 14: Insieme di prodotti GVR.

50


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


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


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


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

Tesi Magistrale

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (8)

Ähnlich wie Tesi Magistrale

Ähnlich wie Tesi Magistrale (20)

Tesi Magistrale