A5 2 Controllo Qualità V25 · ARCHIV1 Caso prova 1 - Caricamento iniziale e successivo recupero SI...

A5_2 V2.5

Controllo QualitàTesting

Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio personale e per supporto a lezioni universitarie.Ogni altro uso è riservato, e deve essere preventivamente autorizzato dall’ autore.

Sono graditi commenti o suggerimenti per il miglioramento del materiale

INGEGNERIA DEL SOFTWARE

Paolo Salvaneschi

Università di BergamoFacoltà di Ingegneria

A5 - Controllo Paolo Salvaneschi 2

• Note di teoria• Costi• Piano, specifiche e rapporto di test• Test funzionali / strutturali e copertura• Struttura di un caso di test• Test funzionale• Test strutturale• Test di modulo, integrazione, sistema• Test di sistemi ad oggetti

INDICE


• Test di accettazione / collaudo• Test di non regressione• Test di caratteristiche non funzionali• Strategia di test• Processo di test• Documenti• Debugging• Analisi dei malfunzionamenti e difetti

INDICE


• Il test del software è– la verifica dinamica del comportamento di un

programma

– con un numero finito di casi di test

– selezionati da un dominio di ingresso (nella pratica infinito)

– rispetto ad un comportamento atteso specificato

Note di teoria


• Programma P : funzione da un dominio D (input) a un codominio R (output)

• P(d), d ∈ D è corretto se il risultato soddisfa le specifiche

• P è corretto se ∀ d ∈ D, P(d) è corretto

• Eseguire un Test di P significa eseguire P per tutti i dati di un sottoinsieme di D

• Test ideale: Test esaustivo di D la cui esecuzione soddisfa le specifiche.

• L’esecuzione del Test ideale permette di dedurre la correttezza di P

Note di teoria


• Test ideale: Test esaustivo di D la cui esecuzione soddisfa le specifiche.

• Esempio: il programma ha 5 parametri di ingresso, e ciascuno può assumere 10 valori: – 105 casi di input.

• Il Test esaustivo è infinito o in pratica infattibile

Note di teoria


• Esiste un criterio C di selezione di un test finito equivalente al test esaustivo?

• Il problema di generare un criterio di selezione C èindecidibile (non esiste alcun algoritmo finito che lo possa risolvere)

Note di teoria


• Inoltre:– Le specifiche sono soggette a incertezza e

incompletezza

– Le risorse a disposizione (tempo e costo) per il testingsono finite (e spesso piccole)

– Il testing è utilizzabile non solo per la funzionalità e non tutte le caratteristiche non funzionali (parte della specifica) possono essere verificate con il test (es. manutenibilità)

Conclusione?

Note di teoria


Test come strumento per accrescere livello di fiducia nel programma

(Il mondo è conosciuto in modo incompleto ed ha tutte le sfumature del grigio)

Test come valutazione della correttezza del programma

(Il mondo è tutto conosciuto ed è o bianco o nero)

Note di teoria


• Un programma affidabile è un programma di cui l’utilizzatore si fida (depends on) rispetto agli utilizzi che ne fa (definizione diversa da MTBF-Mean Time Between Failure)

• Un programma affidabile può contenere difetti ed essere usato con soddisfazione

• Il punto di vista dell’utilizzo:– I difetti nelle parti poco usate importano poco

– Esistono difetti con effetti gravi (perdita di dati ) e difetti con effetti poco significativi (dettagli di impaginazione di un report)

Programma corretto Programma affidabile

Note di teoria


• Un programma affidabile è un programma di cui l’utilizzatore si fida (depends on) rispetto agli utilizzi che ne fa (definizione diversa da MTBF-Mean Time Between Failure)

• E’ una definizione situata nel contesto

– La percezione del cliente (e della società) può variare nel tempo (affidabilità di una centrale nucleare)


Note di teoria


• Safety– Definisce non ciò che un programma deve fare (fornire

una dose di raggi X al paziente, raccogliere i dati, stampare un record) ma ciò che non deve fare (non uccidere il paziente a causa di una dose errata)

Questo aspetto non è di seguito trattato

Comportamenti desiderati

Comportamenti non desiderati

Note di teoria


Note di teoria


• Costo tipico del testing: 30% del costo di progetto

• Costo reale: estremamente variabile

• Budget del testing:– A carico del fornitore (difficile convincere il cliente a

pagarlo esplicitamente – “E’ ovvio che pago un software che funziona (corretto)”

– Piccolo

– Post Scriptum: quale è l’atteggiamento del cliente quando compera Windows XX o Microsoft Word ?


Costi


• Esigenze conflittuali:• 1) Il testing costa

• 2) Il testing è sulla linea critica del processo di sviluppo. Allungare il periodo di test significa ritardare il momento della consegna

• 3) Un testing carente è pericoloso: il cliente non èsoddisfatto (il programma “non funziona”) e si avvia un lungo processo di contenzioso. Bisogna eseguire ulteriori test; intanto il cliente non paga


Costi


• E’ necessario definire una strategia adeguata di test che definisca le risorse disponibili e le utilizzi in modo ottimo rispetto a:– I costi

– La soddisfazione del cliente

– La tipologia di prodotto

– La tipologia di cliente

– I profili di utilizzo

– La criticità delle varie parti del prodotto

– …

• Il testing deve essere pianificato ed eseguito attraverso un adeguato processo di testing


Costi


• Problemi per cui non esiste una risposta definita:– Dati costi e/o tempi definiti, quale è la strategia di test

più conveniente ?

– Quale è la tecnica migliore di test in uno specifico caso?

– Noti i risultati del test di un componente software in un dato contesto di utilizzo, che cosa si può dire del comportamento del componente in un contesto di utilizzo diverso ?

– ……………


Costi


• Soluzione:– Un insieme di tecniche applicabili

– Euristiche

– Casi analoghi (pattern di controllo qualità)

– Esperienza


Costi


• Piano di test: elenco strutturato dei casi di test da eseguire in accordo con una definita strategia di test

• Specifica di test: definizione delle caratteristiche di ogni caso di test

• Rapporto di test: descrizione dei risultati dell’esecuzione del piano di test

Piano, specifiche e rapporto di test


Elemento SI / NO Note e identificazione allegati

DBGEN PROBLEM Si fa notare che la maschera frmOverture non viene aggiornata alla selezione di una differente versione linguistica dell'applicativo. Le maschere a seguire non presentano tale problema.

Caso prova 1 - Apertura database SI Nessun problema riscontrato. Si precisa che tale modulo non compare gestibile una volta effettuato il collegamento all'applicativo.

Caso prova 2 - Riorganizzazione database SI Nessun problema riscontratoARCHIV1Caso prova 1 - Caricamento iniziale e successivo recupero

SI Prove di confonto su file .PRT: sono stati raccolti esempi dei file .PRT caricati durante la prova; è stato effettuato un confronto tra questi e i file poi recuperati che ha fornito risultati positivi. Riferimenti da 1a-1b a 6a-6b.

Caso prova 2 - Modifica e aggiornamento SI Durante il confronto sono comparse differenze sostanziali tra ilfile FILE025.ME3 e CAR10205.me3: report file ARCHIV1_caso2_5.TXT.Allegato il file ARCHIV1_caso2_5.TXT (rif.7) del confronto dei file suddetti.Rif. 7RISOLTO

Caso prova 3 - Cancellazione SI Nessun problema riscontrato. Rif.8

Caso prova 4 - Ripristino database SI Nessun problema riscontrato. Rif.9

Caso prova 5 - Caricamento da terminale ed elaborazione batch

SI Riscontrati problemi dovuti banali errori di modifica.Rif.10RISOLTO

Caso prova 6 - Compatibilità anno 2000 SI Errori incontrati durante la procedura.Riferimenti da Arch2000/1 a Arch2000/9RISOLTO

ARCHIV2Caso prova 5 - Archiviazione dei modelli sospesoCaso prova 6 - Stampa dei modelli sospeso

Verifica funzionalità del prodotto

Esempio


Componente CodiceFunzione

CodiceTest

TipoTest

Esito Test

Boot e spegnimenti macchina con chiave inserita

A1 Effettuare boot macchina con chiave inserita.La macchina deve riconoscere la chiave durante il boot (senza necessita’ di repluggarla).

A2 Effettuare spegnimenti macchina con chiave inserita.Lo spegnimento deve avvenire senza hang.

Speedt.exe per scrittura e lettura chiaveProgramma consolle per l’esecuzione del test di stress sul token. Scrittura e lettura di file. Il test prevede la scrittura o la lettura ripetitiva di due file di dimensione 2048 byte ciascuno. In caso di errore

B1 lunghi cicli di lettura (per esempio speedt 1000)Per effettuare il test di lettura lanciare speedt con argomento n dove n e’ il numero di cicli di letture da effettuare.Es:speedt 10esegue 10 cicli di lettura.U i l di itt i lB2 lunghi cicli di scrittura (per esempio speedt 1000)Per effettuare il test di scritture lanciare speedt con argomento –n dove n e’ il numero di cicli di scritture da effettuare.Es:speedt –10esegue 10 cicli di scrittura.

B3 estrazione durante esecuzione di Speedt.exe(da ripetere molte volte e con verie scelte di tempo dal momento della

partenza del test: immediatamente, un secondo dopo, qualche secondo dopo, piu’di 10 secondi dopo).

B4 come al test B3 ma con rapido reinserimento della chiave dopo l'estrazione

Esempio


• Test funzionale (black box)– Sono provate le funzioni del programma,

indipendentemente da come il programma è costruito– Si considera il programma come una scatola nera con

ingressi e uscite

• Test strutturale (white box)– Sono provate strutture del programma (es. percorsi

all’interno del programma)– Si utilizza la conoscenza della struttura interna del

programma

Test funzionali / strutturali e copertura


• Copertura del testing: misura della quantità di controllo effettuata

• Copertura funzionale: misura della quantità di funzionalità (definite dalla specifica) esercitate dal testing

• Aspetti soggettivi. Cosa è una funzionalità ?

n. funzioni esercitate almeno una volta dal test

copertura funzionale n. totale funzioni



• Copertura topologica: misura della tipologia e della quantità di strutture esercitate

– Esempio:

n. istruzioni esercitate almeno una volta dal test

copertura delle istruzioni n. totale istruzioni



• Atteggiamento di base : copertura funzionale– E’ il punto di vista del cliente– Una funzione non implementata per errore non è

rilevata da un test strutturale per quanto accurato– Non necessariamente sono disponibili i sorgenti del

software da testare

• Il test strutturale può migliorare il test funzionale– Una struttura di dati è trattata da parti separate di codice

in modi diversi– Si può misurare la copertura topologica ottenuta dal test

funzionale e, se il caso intensificare il test funzionale



• Caso di test– Dati di ingresso– Azioni– Dati di uscita– Criterio per verificare che i dati di uscita

corrispondano alla specifica (Criterio di successo o Oracolo)

Struttura di un caso di test


test 5_1 – Filtraggio passa banda del segnale1. ObiettiviIl filtraggio passa-banda è effettuato nel dominio del tempo.Per un accelerogramma qualsiasi di input, il rapporto tra la trasformata di Fourierdei dati filtrati e quella dei dati non filtrati deve essere confrontabile, a meno deglierrori intrinseci agli algoritmi implementati, con la risposta in frequenza teorica H(f)del filtro utilizzato.La funzione di trasferimento dai dati non filtrati ai dati filtrativiene ottenuta come rapporto tra la trasformata di Fourier FC1 dei dati corretti e la trasformata di Fourier FNC dei dati non corretti; a tal fine la correzione del dato vieneeseguita senza effettuare la correzione strumentale.2. Modalità di esecuzioneE’ stata utilizzata la traccia E-W della registrazione di Procisa Nuova del 26/11/80, nella versione digitalizzata in automatico, partendo con i dati non corretti.Della traccia originale viene considerato solo il tratto compreso tra i 20 e 40 sec, ai cui estremi viene applicato un filtro ………………..La traccia accelerometrica prescelta viene processata mediante la funzione Elaborazione accelerogramma con i seguenti accorgimenti:………………..……………………………

Esempio


3. Dati in ingressoI dati in ingresso sono costituiti dai valori assegnati ai campi delle varie videate.La copia delle videate è contenuta nel file <Area test>/Accel/Ciclo_05/Input.ppt.

4. Dati in uscitaI dati in uscita sono costituiti dai file di export (tabulati e disegni) prodotti dalle funzioni di elaborazione e di export.Questi file sono archiviati nella directory <Area test>/Accel/Ciclo_05.

5. Verifica dei risultatiLa verifica viene effettuata confrontando i risultati con quelli ottenuti dalla precedenteversione del sistema installata su Workstation RISC, che sono stati copiati nella directory <Area test>/Accel/Ciclo_05/Risc.

Esempio


• Un caso di test può essere una struttura complessa– Raggiungimento dello stato iniziale del sistema prima

di iniziare il test– Predisposizione dei dati di prova– Definizione precisa della procedura da seguire– Definizione del criterio di verifica del successo

(oracolo)• Estrazione dei risultati attesi dalla specifica• Calcolo a mano• Utilizzo di un programma indipendente di riferimento

considerato affidabile• …….

– Preparazione di software dedicato per eseguire il test



• Test positivo– Test che controlla il corretto comportamento del programma a

fronte di un uso corretto (a specifica) da parte dell’utenteInserisco due numeri interi il programma calcola la somma

• Test negativo– Test che controlla il comportamento del programma a fronte di

un uso scorretto (non a specifica) da parte dell’utenteInserisco un numero intero e il mio nome

il programma non abortisce; è generata una segnalazione

• I test negativi verificano la “Robustezza” del programma(ISO 9126- Reliability- Fault tolerance)



• Cicli o catene di test• Un insieme di test può essere raggruppato in

modo da verificare un’area funzionale• La catena incorpora regole di propedeuticità:

1. Caricamento di un dato2. Verifica di corretto caricamento3. Stampa4. Verifica di corretta stampa5. Cancellazione6. Verifica di corretta cancellazione



Ciclo di test 1 - Verifica funzioni di gestione1. ObiettiviVerificare il corretto funzionamento delle principali attività svolte dalle funzionidi gestione ed in particolare le seguenti attività:

• Inserimento• Modifica• Visualizzazione• Stampa singola• Stampa multipla• Cancellazione

2. Casi di test eseguitiI casi di test eseguiti sono riepilogati nella seguente tabella:

…………………….

ID Funzione Dati specifici

1 Zone con poligonale Zona di tipo cerchio2 Zone con poligonale Zona di tipo rettangolo3 Zone con poligonale Zona di tipo linea4 Zone con poligonale Zona di tipo poligonale5 Criteri acc.mma Dati accelerogrammi6 Criteri acc.mma Dati registrazioni

Esempio


3. Modalità di esecuzionePer ogni funzione di gestione sono state svolte le seguenti attività:• Inserimento di un nuovo oggetto

Sono definite mediante le maschere della funzione le informazioni identificative e descrittive di uno o più oggetti;

• Modifica dei dati dell’oggetto inseritoSono modificati i dati degli oggetti inseriti con la precedente attività;

• Visualizzazione dei dati dell’oggetto e di altri già presenti in banca dati• Stampa singola dell’oggetto• Stampa di multipla di più oggetti• Cancellazione degli oggetti creati

Esempio


4. Dati in ingressoI dati in ingresso sono costituiti dai valori assegnati ai campi delle varie videate nelle attività di inserimento e modifica.La copia delle videate è contenuta nel file <Area test>/Generali/Ciclo_01/Input.ppt.5. Dati in uscitaI dati in uscita sono costituiti dai valori visualizzati nei campi delle varie videatenella attività di visualizzazione e i file di export prodotti dalla attività di stampa.La copia delle videate è contenuta nel file <Area test>/Generali/Ciclo_01/Output.ppt;

in questa directory sono presenti anche i file di export in formato xml e html, con nome uguale a nn.xml e nn.html (nn – progressivo Caso di Test).6. Verifica dei risultatiOltre al corretto svolgimento della attività, viene verificato che i valori visualizzatie stampati corrispondano a quelli inseriti e modificati.Inoltre viene verificato, utilizzando Access, che dopo l’inserimento e modifica i dati siano stati correttamente inseriti nelle corrispondenti tabelle, e che dopo la cancellazione siano effettivamente eliminati.……………

Esempio


7. Risultati del testLa seguente tabella elenca le esecuzioni e le verifiche effettuate (OK Esecuzione corretta, KO Esecuzione terminata per errore, N.E non eseguita).

……………

ID Funzione Inserimento

Modifica Visual Stampsing

Stampmultip

Cancel

1 Zone con poligonale OK OK OK OK N.E. OK



4 Zone con poligonale KO OK

5 Criteri acc.mma OK OK OK OK N.E. OK

Esempio


• Casi di test da specifiche testuali

• Casi di test da modelli

• Classi di equivalenza del dominio di ingresso

• Valori limite

• Test negativi

• Grafi causa- effetto

• Stima dei punti critici

• Casi di test da scenari

Test funzionale


• Casi di test da specifiche testuali• La specifica è suddivisa in aree funzionali

omogenee

• Per ogni area sono estratte le funzioni elementari

• Per ogni funzione elementare è definito un caso di test

Test funzionale


……………I valori di misura di temperatura sono inseriti da terminale nella banca dati e possono essere modificati in alfanumerico o presentati in modalità grafica sia suterminale che su report a stampa.……………

Modifica valori di misuraT2PRESENTAZIONE

Inserimento valori di misura da terminaleT1

Stampa reportT4Visualizzazione graficaT3

GESTIONE VALORI DI MISURA

Esempio


• Casi di test da modelli• La specifica è un modello formale o semiformale

da cui è possibile estrarre casi di test applicando un definito criterio

• Es Automa a stati finiti– Il passaggio per ciascuno stato almeno una volta

– L’esercizio di ciascuna transizione almeno una volta

Test funzionale


Allarme inserito. Set interruttore OFFT3Allarme inserito. Set interruttore ONT4

Allarme disinserito. Set interruttore OFFT2Allarme disinserito. Set interruttore ONT1

Allarmedisinserito

Allarmeinserito

Set interruttore ON / luce rossa accesa

Set interruttore OFF/ luce rossa spenta

Set interruttore OFF /

Set interruttore ON /

Esempio


• Classi di equivalenza del dominio di ingresso– I dati di ingresso sono suddivisi in classi

– Si suppone che il programma si comporti allo stesso modo per ogni elemento della stessa classe

– E’ scelto un caso di test per ogni classe

Test funzionale


……………I valori di misura di temperatura sono inseriti da terminale nella banca dati e possono essere modificati in alfanumerico o presentati in modalità grafica sia suterminale che su report a stampa.Ogni valore di misura deve essere un intero compreso tra -30 e +50……………

Inserimento valore di misura da terminale -20Inserimento valore di misura da terminale +20

T1.1T1.2


Esempio


• Valori limite– I valori limite delle classi di equivalenza sono possibili

fonti di errori

– I programmatore tratta i casi normali; i casi di confine possono essere dimenticati o sono trattati da porzioni di codice specifiche non esercitate da casi di test associati alle classi di equivalenza

– Es: lettura record da file• File vuoto

• EndOfFile

Test funzionale




Inserimento valore di misura da terminale -30Inserimento valore di misura da terminale 0Inserimento valore di misura da terminale +50

T1.1T1.2

T1.3T1.4T1.5


Esempio


• Test negativi– Definire i dati di input provenienti da un uso scorretto

(non a specifica) da parte dell’utente

– Identificare classi di equivalenza di questi dati di input (classi non valide)

Test funzionale




Inserimento valore di misura da terminale -30Inserimento valore di misura da terminale 0Inserimento valore di misura da terminale +50


T1.1T1.2

T1.3T1.4T1.5

T1.6T1.7


Esempio


• Euristiche per identificare le classi di equivalenza (Myers, The art of software testing)

Suddividere in più classiClasse composta da elementi trattati diversamente dal programma

Una classe valida (maiuscolo) e una non valida (non maiuscolo)

Condizione (il primo carattere deve essere maiuscolo)

Una classe valida per ogni elemento e una non valida (rosso)

Insieme di valori (giallo, verde, blu) ognuno trattato diversamente dal programma

Una classe valida e due non valide (0 clienti e >6)

Numero di valori (elencare i nomi da 1 a 6 clienti)

Una classe valida e due non valide (<1 e >999)

Range di valori (il valore di misura ècompreso tra 1 e 999)

Test funzionale


• Grafi causa- effetto• Selezionano casi di test significativi per verificare

combinazioni di dati di ingresso che causano definite uscite – (Le tecniche precedenti non considerano possibili

combinazioni di dati di ingresso)

Test funzionale


• Grafi causa- effetto• 1) Si identificano i fatti di ingresso e di uscita

(cause ed effetti)

• 2) La specifica è tradotta in una rete combinatoria che lega cause ad effetti

• La rete è anche uno strumento per validare la specifica– Mettere in luce contraddizioni

– Evidenziare parti mancanti di logica

Test funzionale


Controllo degli accessiSe l’utente è di tipo A o B e la password fornita è corretta, permetti l’accesso.Se la password non è corretta segnala ERROR2Se l’utente non è di tipo A o B segnala ERROR1

tipo A

tipo B

Passw OK

ERROR1

ERROR2

accesso

Esempio


• Grafi causa- effetto• 3) Si seleziona un effetto

• 4) Si ritorna indietro nel grafo trovando tutte le combinazioni di cause che determinano l’effetto.

• 5)Per ogni combinazione si crea una colonna in una tavola di decisione

• Si procede così per tutti gli effetti

Test funzionale


Controllo degli accessiSe l’utente è di tipo A o B e la password fornita è corretta, permetti l’accesso.Se la password non è corretta segnala ERROR2Se l’utente non è di tipo A o B segnala ERROR1

tipo A

tipo B

Passw OK

ERROR1

ERROR2

accesso

11

11

011100010

Testtipo A

tipo B

Passw OK

ERROR1

ERROR2

accesso

T1 T2 T3 T4

}}

Input

Output10

Falso Vero Non interessa

Esempio


• Grafi causa- effetto• Tener conto di combinazioni di ingresso non

possibili

• Applicare criteri di semplificazione nel percorrere all’indietro il grafo – Nodo OR con uscita 1: non più di un input a 1 alla volta

– Nodo AND con uscita a 0: si include il caso di tutti gli input a 0; se un input è a 0 e uno o più degli altri sono a 1, non esaminare tutte le situazioni in cui gli altri input possono essere a 1

Test funzionale


• Stima dei punti critici• Sulla base dell’esperienza di programmazione e

dello specifico settore applicativo un esperto nel testing può identificare possibili situazioni potenzialmente causa di difetti e scrivere specifici casi di test

Test funzionale


• Casi di test da scenari• E’ definito un insieme di scenari di utilizzo.

• Per ogni scenario sono identificate le varianti considerate più significative o critiche

• Gli scenari sono derivati dall’analisi dei requisiti o sono scritti ad hoc per il testing

• Per ogni scenario/variante è definito un caso di test

Test funzionale


• Sono definiti i casi di test sufficienti per rispettare un criterio di copertura di definiti elementi strutturali del programma

• Copertura delle istruzioni

• Copertura delle decisioni

• Copertura delle condizioni

• Copertura dei cammini (N-copertura dei cicli)

Test strutturale


• Grafo di controllo

1 Read (x)2 Read (y)

If (x>y)3 then x=x+14 else x=x-15 Write (x)6 Write (y)

1

2

3 4

5

6

Test strutturale


• Copertura delle istruzioni (statement test)

• Ogni istruzione deve essere percorsa almeno una volta

C0 = n. istruzioni eseguite / n. istruzioni

Test strutturale


• Copertura delle decisioni (branch test)

1

2

3 4

5

6

• Ogni arco del grafo di controllo deve essere percorso almeno una volta

C1 = n. archi percorsi / n. archi percorribili

Test strutturale


• Copertura delle condizioni (condition test)

• Ogni singola condizione che compare nelle decisioni del programma è coperta sia per lo stato di vero che per lo stato di falso almeno una volta

• Non esistono relazioni di inclusione tra il criterio di copertura delle decisioni e delle condizioni

1

2

3 4

If (x=0 or y>0)

Test strutturale


1

2

3 4

If (A and B)

Test strutturale

If (A or B)

condition testTest1 A true B falseTest2 A false B trueA e B sono coperte per true e falsealmeno una volta

branch testLe decisioninon sono coperte

1

2

3 4

branch testTest1 A true B falseTest2 A false B falseLe decisionisono coperte

condition testA e B non sono coperteper true e falsealmeno una volta


• Copertura dei cammini (path test)• Ogni cammino del grafo di controllo deve essere

percorso almeno una volta

Test strutturale


• Copertura dei cammini (path test)• Numero massimo di percorrenze di ciascun ciclo

(N-copertura dei cicli)

• Ogni cammino contenente un numerodi iterazioni di ogni ciclo non superioread N deve essere percorso almeno una volta

CN = n. cammini percorsi / n. tot cammini percorribili

Test strutturale


• Copertura del grafo di chiamata tra i moduli

• Criterio di copertura “a grana più grossa”

• Ogni arco che connette due moduli (chiamata di modulo) deve essere percorso almeno una volta

Test strutturale


• Un sistema software può essere costituito da più componenti interconnessi

• Big bang test– Il sistema e integrato e poi verificato

globalmente• Integration test

– Il sistema è verificato per parti e progressivamente integrato

– Più agevole identificare i difetti

Test di modulo, integrazione, sistema


Jensen, Tonies 1979Il modello a V



• Top-down testing– Inizia con il livello più alto del sistema– integra progressivamente i componenti– verificandoli di volta in volta

• Utilizza, se il caso componenti fittizi che simulano i componenti di basso livello non ancora integrati (stub)



• Bottom-up testing– Inizia con il livello più basso del sistema– verifica i singoli componenti– li integra progressivamente– verificando i livelli via via più alti

• Utilizza, se il caso componenti fittizi che simulano i componenti di alto livello non ancora integrati (driver, skeleton)

• In pratica, l’integrazione dei sistemi può utilizzare una combinazione dei due approcci



• Driver e stub: componenti software sviluppati ad hoc per permettere il test di integrazione

Driver Stub



Sistema di raccolta dati



Sistema di raccolta dati…..

Dati di consumo

Acquisizione dati

Banca dati

Gestione

Dati di consumo

Dati di consumo

Dati di consumo

GSM GSMGSMGSM

Esempio


Test separato del corretto funzionamento dei sistemi di raccolta dati tramite l’utilizzo di un “banco di test” che implementa il protocollo di comunicazione ed un insieme di casi di prova.Quando i sistemi periferici sono verificati si integrano nel restante sistema




Sistema di raccolta dati…..

Dati di consumo

Protocollo di comunicazione

Stampe di controllo

Dati di consumo

Dati di consumo

Dati di consumoGSM GSMGSMGSM

Stub

Esempio


• Nota: test di un software con architettura a strati

• Test gerarchico a partire dallo strato più interno

• Ogni strato deve essere provato dal punto di vista delle funzionalità attese dal suo utente (lo strato esterno)



• Test delle interfacce• Sono realizzati insiemi di test specificatamente

progettati per verificare l’interfaccia tra due componenti (es. sottosistema acquisito in versione eseguibile)– Il componente chiamante non usa in modo corretto l’interfaccia del

chiamato (es. parametri in ordine errato)– Il chiamato include assunzioni non corrette relative al

comportamento del chiamante (es. assume che il chiamante controlli la correttezza applicativa dei dati passati)

– Errori di sincronismo (Il componente che riceve dati legge a frequenza troppo elevata i dati scritti dal componente che trasmette dati e legge più volte gli stessi valori)

– ………………



• Non si testano procedure ma classi e oggetti che incorporano procedure e dati (un oggetto ha una relazione di ingresso / uscita e stato interno)

• E’ necessario tenere conto dell’ereditarietà e del polimorfismo

• I sistemi ad oggetti non sono una struttura gerarchica ma una rete

Test di sistemi ad oggetti


• Non si testano procedure ma classi e oggetti che incorporano procedure e dati

• Il test di una classe:– Test delle operazioni associate con un oggetto– Definizione e interrogazione degli attributi– Test dell’oggetto nei suoi possibili stati



• Ereditarietà e polimorfismo• L’informazione da testare non è localizzata (nelle

sottoclassi alcune operazioni restano invariate, altre sono ridefinite)– Le operazioni ereditate devono essere ri-testate?

• Rifare tutti i test per ogni sottoclasse• Testare solo le differenze

• Un oggetto può riferirsi a più implementazioni della stessa operazione selezionate a run time



• I sistemi ad oggetti non sono una struttura gerarchica ma una rete

• I livelli di integrazione sono meno distinti in un sistema ad oggetti

• Livelli di test– Test delle operazioni associate all’oggetto– Test delle classi– Test di gruppi di oggetti che collaborano– Test del sistema completo



• La fase di rilascio di un prodotto software èuna fase specifica importante che deve essere gestita

• Dopo il test del prodotto in casa del produttore, possono essere eseguite più fasi diverse di verifica il cui termine èl’accettazione formale del prodotto da parte del cliente.

Test di accettazione / collaudo


Test

Esercizio

α-Test

β-Test

Avviamento

Collaudo

All’interno del produttore che simula l’utente finale

Presso il cliente in utilizzo controllato (es. numero limitato

di utenti)

Presso il cliente in utilizzo normale ma con affiancamento

del produttore

Prove il cui esito positivo comporta l’accettazione del

prodotto



• Tecniche di test di accettazione / collaudo• Utilizzo degli scenari

• Il piano di collaudo identifica un insieme di scenari di utilizzo concordati con il cliente i quali esercitano il prodotto– Nell’ambiente del cliente

– Con gli utenti tipici

– Nei casi tipici

– E in casi considerati critici

• Gli scenari di test includono anche caratteristiche non funzionali



• Test di non regressione• Un insieme di casi di test T è eseguito senza

evidenziare malfunzionamenti.

• Un test manifesta un malfunzionamento

• E’ identificato il difetto e il programma è corretto

• La modifica può avere introdotto altri difetti

• T è ri-eseguito per assicurarsi della non introduzione di effetti laterali non desiderati

• Importanza della rieseguibilità automatica del test

Test di non regressione


• Si possono costruire test relativi non solo a specifiche funzionali ma anche a specifiche non funzionali

• Funzionalità– Es. Sicurezza. Simulare un insieme di possibili attacchi

• Affidabilità– Simulare possibili guasti (caduta di linee di trasmissione, fuori

servizio di un server,…)• Usabilità

– Definire condizioni sperimentali opportune (insieme di utenti ditest significativi, registrazione delle attività) e raccogliere misure (errori di comprensione, tempi, valutazioni…)

Test di caratteristiche non funzionali


• Efficienza– Misurare le prestazioni in condizioni definite (es. carico di utenti

definito, dimensione dei messaggi ricevuti): tempi di risposta medi, tempo massimo, …

• Manutenibilità• Portabilità

– Non si eseguono test ma misure di caratteristiche allo scopo di stimare la propensione del prodotto ad essere modificato o portato

Test di caratteristiche non funzionali


Ambiente per il testIn base alla struttura del programma di elaborazione, le variabili principali sono il numero di clienti ed il numero di chiamate da elaborare; sono stati quindi creati i seguenti programmi:Programma per la generazione ed archiviazione di clienti fittiziGenera un numero assegnato di clienti fittizi con il relativo contratto telefonico. Ad ogni cliente è associato un contratto telefonico con 20 numeri e il centralino passante con 100 interni; sono inoltre creati 10 centri di costo a cui vengono associati i vari numeri.Sono anche create, sempre per ogni cliente, 7 condizioni di allarme: una per ognuno ….Per non alterare i dati reali presenti nel sistema informativo, ed al tempo stesso per avere una situazione il più possibile simile alla realtà, è stata duplicata all’interno del database la tabella Utente,……….Si sottolinea che il contratto simulato rappresenta una stima conservativa, in quanto……Programma per la generazione del file delle chiamate…………………..Traccia dei tempi e delle attivitàNel programma di elaborazione è stata aggiunta la creazione di un file di log in cui èstampata la traccia delle varie attività svolte e dei relativi tempi di esecuzione.

Telecomunicazioni. Applicazione di gestione e fatturazione di telefonate

Test di efficienza

Esempio


Numero clienti

Numero telefonate

Passo 1 –Caricamento

Passo 2 –Elaborazione

Passo 3 –Riepilogo

Totale

50 10.000 5 31 308 344

50 50.000 5 175 418 598

100 50.000 10 182 802 994

100 100.000 9 438 1019 1466

200 100.000 16 511 1772 2299

200 500.000 39 2994 2634 5667

Sono state effettuate le prove indicate nel successivo schema, in cui per ogni prova è indicato il numero di clienti, il numero di chiamate archiviate e i tempi di elaborazione (in secondi) per i tre passi di elaborazione, descritti precedentemente.Ogni prova è stata eseguita con il database telefonia che contiene i dati della prove precedente.

Prove eseguite

Esempio


Costi TempiCaratteristiche del prodottoe dell’ambiente di utilizzo

Caratteristiche del cliente

Scelta di •cosa verificare•come verificare

•quanto verificare

Strategia di test

Strategia di test


• Definire / negoziare le risorse disponibili

– Costi

– Tempi

• Analizzare le criticità

– Non tutti gli scenari di uso, i componenti del prodotto,…sono egualmente critici

• Scegliere le tecniche ed i criteri di copertura

• Scrivere un documento che definisca le scelte, ne renda ragione e pianifichi le azioni

Strategia di test


Test di apparati a microprocessori per il conteggio del consumo di energia elettrica

4.1 Strategia di testE' stato adottato per il prodotto XXXX un testing di tipo funzionale la cui

strategia è descritta schematicamente nei seguenti passi:

• Suddivisione del piano di test nelle aree funzionali del modello funzionale

• Estrazione delle funzionalità componenti ogni area funzionale

• Generazione di uno o più casi di test associati ad una funzionalità secondoi seguenti criteri:

1. Definizione di un sotto-caso di test (positivo o negativo) per ogni classe di equivalenza dei dati in ingresso della funzionalità

2. Definizione di un sotto-caso di test (positivo o negativo) per ogni condizione di confine tra classi di equivalenza dei dati in ingresso della funzionalità

Esempio


3. Per specifiche funzionalità: Esame delle condizioni (stati ed eventi) che possono influenzare l’ esecuzione della funzione(ad esempio la contabilizzazione di un consumo può avvenire durante un periodo di fatturazione (stato) o durante il cambio del periodo di fatturazione (evento) che può coincidere con un cambio di contratto (eventi simultanei). Vengono considerate tutte le combinazioni possibili di condizioni ed i casi di test vengono organizzati per livelli successivi di approfondimento ( 1 evento alla volta, 2 eventi coincidenti, 3……)Al fine di identificare tutte le possibili combinazioni di eventi di interesse è stato utilizzato lo strumento delle “tavole di combinazione di eventi” che sono allegate al piano di test.

4. All’ insieme delle combinazioni di possibili condizioni è sovrapposta la presenza di un power fail e vengono generati i corrispondenti casi di test.

Esempio


4.2 Criteri di copertura del testingSono stati adottati i seguenti criteri di copertura minima dell' attività di test:

• Ogni funzione deve essere coperta da almeno un caso di test (copertura funzionale esaustiva)• La distribuzione dell’intensità di test relativa alle aree funzionali (intensità di test = n. medio di test per ogni funzione dell’area funzionale) deve essere coerente con l' analisi di rischio effettuata.

L' analisi di rischio, identifica (e fornisce le ragioni della scelta) per ogni area funzionale un indice di rischio nella scala:

1 = rischio basso 2 = rischio medio 3 = rischio alto.Ad ogni valore dell' indice di rischio viene associato un valore di intensità di test che deve essere soddisfatto (eventualmente in eccesso) dal piano di test, secondo il seguente criterio:

Livello di rischio 1: intensità di test = 1Livello di rischio 2: intensità di test = 1.5Livello di rischio 3: intensità di test = 2

Esempio


Area Funzionale Indice di

rischio

Motivazioni

A Base dei tempi 3 Funzione di base combinatorialmente complessa

B Programmazione tariffaria

1 Nota: area funzionale quasi vuota. Le funzioni sono state spostate nell’ area F

C Conteggio dei “ QUANTI ” di energia

3 Produce il conteggio del consumo gestendo le tariffe ed e’ combinatorialmente complessa

D Elaborazione dei quanti di energia

3 Produce il conteggio del consumo gestendo le tariffe ed e’ combinatorialmente complessa

E Gestione delle interruzioni 3 Interviene durante l’ esecuzione di ogni funzione di UEPM ed e’ combinatorialmente complessa

F Programmazione dell’UEPB

3 Funzione di base che influenza tutte le altre funzioni

G Gestione del Display 2

H Elaborazioni ausiliarie sulla qualita` del servizio

1

I Identificazione della fase 1

……..

ANALISIDI RISCHIO

Esempio


1 . B T = A B a s e d e i T e m p i

C o d . T e s t

M A D e sc r iz io n e

T P B T 0 0 0 1 1 L 'U E P B d e v e g e s t ir e c o r re t t a m e n te la fu n z io n e d i o ro lo g io in m o d o d a c o n te g g ia re i

s e g u e n t i d a t i t e m p o ra li: s e c o n d i, m in u t i, o r e , g io r n i, s e t t im a n a . M o d a lit à d i e se c u z io n e d e l t e s t :

T P B T 0 0 0 2 1 L 'U E P B d e v e g e s t ir e c o r re t t a m e n te il c a m b io d i t u t t i i m e s i d e ll’ a n n o M o d a lit à d i e se c u z io n e d e l t e s t :

T P B T 0 0 0 3 1 L 'U E P B d e v e g e s t ir e c o r re t t a m e n te il c ic lo q u a d r ie n n a le b ise s t ile e d il c a m b io d e l m e se a l g io rn o 2 8 /2 – 2 9 /2 d i u n a n n o b ise s t ile . M o d a lit à d i e se c u z io n e d e l t e s t :

T P B T 0 0 0 4 1 L 'U E P B d e v e g e s t ir e c o r re t t a m e n te l’ in iz io e la fin e d e ll’ o ra le g a le su lla b a se d e l r e la t iv o m e ssa g g io d i p ro g ra m m a z io n e

M o d a lit à d i e se c u z io n e d e l t e s t :

T P B T 0 0 0 5 1 I n a s se n z a d i p ro g ra m m a z io n e d e ll’ o ra le g a le ( c o n d iz io n e d i d e fa u lt ) l' U E P B d e v e g e s t ir e c o r re t t a m e n te l’ in iz io e la fin e d e ll’ o ra le g a le a t t u a n d o la n o rm a t iv a e u ro p e a c h e p re v e d e l’ in iz io n e ll’u lt im a d o m e n ic a d i m a rz o e la fin e n e ll’u lt im a d o m e n ic a d i o t t o b re .

M o d a lit à d i e se c u z io n e d e l t e s t :

Esempio

PIANO DI TEST 220 funzioni, 700 casi di test, 4 anni/uomo di sforzo di test


MATRICE DI COPERTURA

Area funzionale Cod Codice molte test test n. n. n. n.tot n.tot intenFunz Test test plicita pos neg test pos neg funz test sità

Area Area AreaGestione base dei tempi A 7 19 2,714* 1 TPBT0001 1 1 7 7

TPBT0002 1 1TPBT0003 1 1TPBT0004 1 1TPBT0005 1 * 1TPBT0013 1 * 1TPBT0014 1 * 1

2 TPBT0006 1 1 1 13 TPBT0007 1 1 3 3

TPBT0008 1 1TPBT0015 1 * 1

4 TPBT0009 1 1 2 2TPBT0016 1 * 1

5 TPBT0010 1 1 3 3TPBT0011 1 * 1TPBT0017 1 * 1

6 TPBT0011 1 * 1 2 2TPBT0018 1 * 1

7 TPBT0012 1 * 1 1 1Programmazione tariffaria B 4 4 1* 1 TPPT0001 1 1 1 1

2 TPPT0002 1 1 1 13 TPPT0003 1 1 1 14 TPPT0004 1 * 1 1 1

Esempio


DIAGRAMMA 2Intensita' di test per Area funzionale

0123456789

1011121314151617181920212223242526

A B C D E F G H I L M N O P

Area

Inte

nsita

'

Intensità test

Intensità media

Esempio


DIAGRAMMA 3 Intensita' di test ed intensita' attesa sulla base dell' indice

di rischio

0123456789

1011121314151617181920212223242526

A B C D E F G H I L M N O P

Area

Inte

nsita

' Intensità test

Intensita' attesa

Esempio


Specificazione

Progettazionearchitetturale

Codifica

Progettazionedi dettaglio

Definizione della strategia

Preparazione test black box

Preparazione test white box

Esecuzione

Processo di test


• Automazione del test• Il test è realizzato da un programma che

automatizza una o più fasi:– Raggiungimento dello stato iniziale del sistema– Predisposizione dei dati di prova– Lancio del programma sotto test– Verifica del successo (oracolo)

• Possono essere utilizzati strumenti e ambienti di test che facilitano l’automazione

Processo di test


• Adattamento del processo• I processi di test devono essere adattati alle

specifiche necessità e vincoli– Dell’organizzazione di sviluppo– Dello specifico progetto

Processo di test


• Aspetti organizzativi• L’attività di test è una specifica competenza• E’ utile e conveniente che il test sia eseguito da

persone diverse dagli sviluppatori– Indipendenza di giudizio– Specifiche competenze– Utilizzo efficiente delle risorse (si liberano le risorse di

progettazione e programmazione

• Conviene anche per piccole organizzazioni (5 sviluppatori)

Processo di test


• Il processo di test rilascia dei documenti:– Piano di Test– Specifiche dei casi di Test– Rapporti di esecuzione dei casi di Test– Rapporto di qualificazione (rapporto sull’esito

complessivo dell’attività di test)

Documenti


Caso semplice

Esempio


Esempio


Casocomplesso

1. SCOPO

2. PRODOTTO DI RIFERIMENTO

3. DOCUMENTAZIONE DI RIFERIMENTO

4. CRITERI DI DEFINIZIONE / ESECUZIONE DEL PIANO DI TEST4.1 STRATEGIA DI TEST4.2 CRITERI DI COPERTURA DEL TESTING4.3 ORGANIZZAZIONE DEL PIANO DI TEST4.4 STRUMENTI A SUPPORTO DELL’ ATTIVITA’ DI TEST

5. RAPPORTO DI TEST

ALLEGATI

A1. PIANO DI TESTA3. ANALISI DI RISCHIOA5. MATRICE DI COPERTURA

Esempio


• Debugging• Avviato dal manifestarsi di un malfunzionamento causato

da un difetto del programma (esito di un test)

• Identifica il difetto che ha causato il malfunzionamento

• Corregge il difetto

• Rilevanza della manutenibilità del prodotto– Comprensibilità

– Riduzione del rischio di generare effetti laterali non desiderati

– …..

Debugging


• Analisi malfunzionamenti e difetti• I malfunzionamenti e difetti trovati possono essere

utilizzati – Come indicatore dell’affidabilità del prodotto

– Per diagnosticare le cause e migliorare

• Raccolta dei malfunzionamenti e difetti

• Analisi dei malfunzionamenti con modelli di affidabilità(reliability growth models)

• Analisi e spiegazione causale dei difetti

Analisi dei malfunzionamenti e dei difetti


• Raccolta dei malfunzionamenti e difetti• Processo ordinato di raccolta dei malfunzionamenti

• Classificazione dei difetti– Classi di gravità

– Tipologia

• Allocazione dei difetti– Ai componenti software

– Alle fasi

– Ai gruppi di sviluppo



• Analisi dei malfunzionamenti con modelli di affidabilità (reliability growth models)

• E’ considerato il prodotto software che funziona in un definito (e stabile) contesto di utilizzo.

• Il prodotto è modellato come un processo casuale che genera malfunzionamenti nel tempo

• E’ misurato il tempo di utilizzo ed i malfunzionamenti manifestati

• I difetti causa dei malfunzionamenti sono di volta in volta corretti



Mean time between failuresNumero malfunzionamenti rilevati

Intensità dimalfunzionamento (n.malfunzionamenti /intervallo di tempo)

Dopo avere rilevato x malfunzionamentie rimosso le cause

Quale è il tempo atteso di funzionamento corretto tra un malfunzionamento ed il successivo ?



Assegnazione dellesegnalazioni ai componenti(segnalazioni cumulatedal 1983 al 1993)Prodotto di gestioneed elaborazione datida monitoraggioMIDAS

Nota:Misura di difettosità(Type C)Misura di stabilità dei requisiti(Type M+I)

M. Catelani, P. Salvaneschi, A. Zanobini, M. MugnainiUse of software reliability models for the maintenanceof information systems: a case studyIEEE Instrumentation and Measurement TechnologyConf. IMTC 94, Hamamatsu, Shizuoka, Japan, 1994

Esempio


• Predizione dell’affidabilità– Misura del tempo di esecuzione e dei

malfunzionamenti– Modelli di affidabilità– Es. Modello Logaritmico di Poisson a tempo di

esecuzione

λ(μ) = λ0 e- θ μλ Intensità di malfunzionamento (malfunz/ora)

μ Numero di malfunzionamenti

λ0θ parametri

Esempio


• Predizione dell’affidabilità– Predizione del numero di errori da correggere

per ottenere un livello definito (SLA) di affidabilità

Esempio


Distribuzione delle segnalazioninel tempo

Prodotto di gestioneed elaborazione datida monitoraggioMIDAS

M. Catelani, P. Salvaneschi, A. Zanobini, M. MugnainiUse of software reliability models for the maintenanceof information systems: a case studyIEEE Instrumentation and Measurement TechnologyConf. IMTC 94, Hamamatsu, Shizuoka, Japan, 1994

Esempio


Esempio


• Analisi e spiegazione causale dei difetti• Il data base dei difetti è analizzato per fornire possibili

spiegazioni delle cause

• Valutare la rete delle possibili cause– Complessità di un componente

– Risorse non adeguate

– Tempo ridotto

– Progettazione carente

– ……..

• Intervenire sul processo


A5 2 Controllo Qualità V25 · ARCHIV1 Caso prova 1 - Caricamento iniziale e successivo recupero SI...

Documents

Transcript of A5 2 Controllo Qualità V25 · ARCHIV1 Caso prova 1 - Caricamento iniziale e successivo recupero SI...