|
Categorie
Winzipedia Uso dell'wiki |
TestingInformatica3.Testing VersioniMostra le modifiche minori - Mostra le modifiche Modificate le linee 6-7: da:
->Questo articolo del testing e del tool emma per il testing del codice Java. Saranno riassunte le lezioni contenute nei pdf ''testing.pdf''. Non il pdf ''emma.pdf'' tutta pratica. a:
->[-Questo articolo del testing e del tool emma per il testing del codice Java. Saranno riassunte le lezioni contenute nei pdf ''testing.pdf''. Non il pdf ''emma.pdf'' tutta pratica.-] Modificate le linee 3-4: da:
''' a:
'''Hanno contribuito:''' - 24/05/2006 ore 20:12 CEST
di - Manca Emma 24/05/2006 ore 20:12 CEST
di - Manca Emma
Modificata la linea 60: da:
'''Ottimizzazioni nel testing delle decisioni''' a:
'''Ottimizzazioni nel testing delle decisioni'''\\ 24/05/2006 ore 20:12 CEST
di - Manca Emma
Aggiunte le linee 58-67:
Per far che tutti gli elementi di una copertura siano eseguiti, necessario approntare dei casi di test ben ideati: un metodo per scriverli consiste nella ''backward propagation'', ovvero partire dal fondo del grafo e risalire aggiornando il valore che le variabili avrebbero dovuto avere per eseguire quel ramo. '''Ottimizzazioni nel testing delle decisioni''' All'interno di molti compilatori previsto un meccanismo chiamato ''short circuit evaluation'', che permette una valutazione accelerata dei predicati logici basandosi su due semplici considerazioni: * Se due operandi sono uniti da un'operazione AND, basta che uno dei due valga ''false'' tutta l'espressione valga ''false'' * Se due operandi sono untit da un'operazione OR, basta che uno dei due valga ''true'' tutta l'espressione valga ''true'' Se una delle due condizioni si verifica, la valutazione classica dell'espressione viene interrotta e viene restituito il valore risultante. Per questo motivo, quando si programma, conviene mettere prima le condizioni veloci da valutare. Modificata la linea 47: da:
'''In quali modi si valuta la copertura?''' a:
'''In quali modi si valuta la copertura?'''\\ Modificate le linee 53-54: da:
Un'istruzione di selezione valuta un predicato logico detto '''decisione''', composto da tante '''condizioni''' atomiche. Ad esempio @@y>0 || x<9@@ una decisione formata da due condizioni, @@y>0@@ e @@x<9@@. a:
Un'istruzione di selezione valuta un predicato logico detto '''decisione''', composto da tante '''condizioni''' atomiche. Ad esempio @@y>0 || x<9@@ una decisione formata da due condizioni, @@y>0@@ e @@x<9@@. Abbiamo anche: Modificate le linee 56-59: da:
* Decision coverage: per ogni decisione vengono valutati entrambi i valori logici Il difetto a:
* Decision coverage: per ogni decisione vengono valutati entrambi i valori logici: questa tecnica corrisponde al ''branch coverage''. Il difetto del ''program based testing'' quello di non riuscire ad individuare gli '''errori di omissione''', ovvero specifiche non implementate, in quanto quello che non c' non essere eseguito. Il ''set'' di input selezionati presentare una scarsa all'interno del ''modello di business'', e potrebbe non esserci un '''oracolo''', ovvero una procedura meccanica in grado di stabilire se gli output sono corretti. Modificata la linea 29: da:
* del codice sorgente (white box, grey box, black box) a:
* del codice sorgente (disponibile->white box, grey box, non disponibile->black box) Modificate le linee 47-48: da:
a:
'''In quali modi si valuta la copertura?''' Esistono varie strategie per la valutazione della copertura del codice, a seconda del componente del programma di cui si tiene conto. Il programma viene schematizzato come un diagramma di flusso, dove le istruzioni sono i blocchi (rombi per le selezioni e rettangoli per tutte le altre) e gli archi corrispondono ai flussi di esecuzione possibili. I cicli ''for'', ''while'' e ''repeat... until'' sono trasformati in costrutti di selezione equivalenti. * Statement coverage: la copertura viene valutata sulle singole istruzioni. Un test con copertura del 100% delle istruzioni significa che ogni istruzione stata eseguita almeno una volta. * Branch coverage: la copertura viene valutata sul numero di archi percorsi: ogni selezione introduce almeno un fattore 2x sul numero di archi. Un test con copertura del 100% sugli archi significa che tutte le possibili combinazioni delle selezioni sono state valutate. Questa condizione stringente della precedente, in quanto possono esserci archi che non incontrano istruzioni (si pensi ad un salto). Un'istruzione di selezione valuta un predicato logico detto '''decisione''', composto da tante '''condizioni''' atomiche. Ad esempio @@y>0 || x<9@@ una decisione formata da due condizioni, @@y>0@@ e @@x<9@@. * Condition coverage: per ogni condizione vengono valutati entrambi i valori logici. Se condizioni compongono una decisione, non necessario che si considerino tutte le combinazioni, basta solo che per ogni condizione sia valutato il ''vero'' ed il ''falso''. Questa tecnica meno stringente della precedenti, in quanto non detto che tutti gli archi e tutte le istruzione del programma siano eseguite. * Decision coverage: per ogni decisione vengono valutati entrambi i valori logici e corrisponde al ''branch coverage''. Il difetto di questo metodo di testing quello di non riuscire ad individuare gli '''errori di omissione''', ovvero specifiche non implementate, in quanto quello che non c' non essere eseguito. Il ''set'' di input selezionati presentare una scarsa all'interno del ''modello di business'', e potrebbe non esserci un '''oracolo''', ovvero una procedura meccanica in grado di stabilire se gli output sono corretti. Modificata la linea 2: da:
'''Autore:''' [[Profiles.Andrea|Andrea]]\\ a:
'''Autore:''' [[Profiles.Andrea|Andrea Rota]]\\ Modificata la linea 2: da:
'''Autore:''' [[Profiles.Andrea|Andrea]] a:
'''Autore:''' [[Profiles.Andrea|Andrea]]\\ 24/05/2006 ore 18:44 CEST
di - Prima versione
Aggiunte le linee 2-4:
'''Autore:''' [[Profiles.Andrea|Andrea]] '''Contributori:''' - Aggiunte le linee 36-54:
!!Metodi di test !!!Program based testing Il ''program based testing'' un processo di testing il cui obiettivo raggiungere una copertura fissata (percentuale di programma testato) e si articola in quattro fasi: # Analisi della struttura del programma per estrapolare degli input in grado di assicurare la copertura richiesta. # Esecuzione del programma con gli input selezionati al passo precedente # Controllo degli output ottenuti # Controllo che la copertura ottenuta sia quella effettivamente richiesta (per questo esistono tool automatici come emma o coperdura) Nonostante questo approccio sia orientato al programma, l'esistenza di una specifica rimane basilare, in quanto rappresenta l'oggetto del confronto per dire che un test stato passato o no. Il difetto di questo metodo di testing quello di non riuscire ad individuare gli '''errori di omissione''', ovvero specifiche non implementate, in quanto quello che non c' non essere eseguito. Il ''set'' di input selezionati presentare una scarsa all'interno del ''modello di businnes'', e potrebbe non esserci un '''oracolo''' in grado di stabilire se gli output sono corretti. !!!Specification based testing Lo ''specification based testing'' un processo di testing che si basa sulle specifiche del software per selezionare un insieme di input da sottoporre al programma; il processo si articola in quattro : # Analisi della struttura delle specifiche per estrapolare un insieme di input ''significativo'' # Esecuzione del programma con gli input selezionati al passo precedente # Esecuzione delle specifiche (o di un oracolo) con gli stessi input # Confronto dei risultati 24/05/2006 ore 18:07 CEST
di - Prima versione
Aggiunte le linee 29-32:
!!!Limiti del testing Il testing ha vari limiti, dettati anche da limiti matematici (v. [[http://www.vincenzomanzoni.com/wiki/pmwiki.php/Informatica3/ | ]]): * Un test non garantire che il codice sia ''bug free'', ma solo dire se sotto alcune condizioni si verificano dei malfunzionamenti. * Non possibile testare tutti i possibili input e ci riduce quindi a creare delle classi di equivalenza e a testare quelli probabili. E' inutile cercare difetti che non provocano danno. 24/05/2006 ore 17:58 CEST
di - Prima versione
Modificate le linee 8-9: da:
Attraverso il testing si aumenta il ''grado di fiducia'' che si ripone nel software, verificando che il software si comporti come da specifica. Indichiamo con '''validazione''' il processo di confronto fra requisiti richiesti dal cliente e specifiche raccolte durante l'analisi e con '''verifica''' il processo di confronto fra specifiche raccolte e comportamento del software. a:
Attraverso il testing si aumenta il ''grado di fiducia'' che si ripone nel software, verificando che il software si comporti come da specifica, evidenziandone i difetti e correggen doli. Indichiamo con '''validazione''' il processo di confronto fra requisiti richiesti dal cliente e specifiche raccolte durante l'analisi e con '''verifica''' il processo di confronto fra specifiche raccolte e comportamento del software. Aggiunte le linee 21-28:
!!!Dimensioni del testing Il testing indagare sul grado di fiducia del software spaziando in varie dimensioni e a varie : * del processo di sviluppo (code->unit, design->integration, requirements->system, specifiche->acceptance) * del codice sorgente (white box, grey box, black box) * Aspetto da indagare (, prestazioni, robustezza, , ) 24/05/2006 ore 17:52 CEST
di - Prima versione
Modificate le linee 17-18: da:
!!! Contenuto della sottosezione a:
!!!Classificazione delle tecniche Distinguiamo fra le tecniche di testing tecnihe dinamiche e tecniche statiche: :Dinamiche: il software viene eseguito e il comportamento ottenuto viene confrontato con quello richiesto. Se il comportamento non corrisponde, si passa alla fase di ricerca dell'errore e alla sua correzione (''debugging''). :Statiche: il software viene ispezionato senza essere eseguito. Esempi di queste tecniche sono le analisi del codice (controllo di variabili non assegnate o assegnate volte, conflitti fra nomi, array ''out of bound'' ecc) o verifiche formali (si usa un modello matematico di riferimento). 24/05/2006 ore 17:48 CEST
di - Prima versione
Aggiunte le linee 1-18:
!Testing: metodi e strumenti ->'''Sommario''' ->Questo articolo del testing e del tool emma per il testing del codice Java. Saranno riassunte le lezioni contenute nei pdf ''testing.pdf'' ed ''emma.pdf''. !!Testing Il processo di testing una delle che compongono il processo di creazione del software: fra esse sicuramente quella onerosa in termini di tempo e di denaro. Attraverso il testing si aumenta il ''grado di fiducia'' che si ripone nel software, verificando che il software si comporti come da specifica. Indichiamo con '''validazione''' il processo di confronto fra requisiti richiesti dal cliente e specifiche raccolte durante l'analisi e con '''verifica''' il processo di confronto fra specifiche raccolte e comportamento del software. !!!Errori, difetti e malfunzionamenti Prima di addentrarci nel mondo del testing, conviene indagare su quali sono le cause che portano un software a comportarsi in modo diverso da quanto richiesto, ovvero a manifestare un '''malfunzionamento''' (o ''failure''). Un malfunzionamento si manifesta quando esiste un '''difetto''' (o ''fault'') e alcune condizioni d'attivazione che fanno che quest'ultimo possa verificarsi. Un difetto dovuto alla presenza di '''errori''' nel processo di sviluppo del software, come semplici errori di battitura, errori di analisi dei requisiti o errori nell'uso dei linguaggi. !!!Sottosezione Contenuto della sottosezione. |