La difficoltà deriva dalla complessità del software: Non si potrà mai testare completamente un programma di una certa complessità.

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "La difficoltà deriva dalla complessità del software: Non si potrà mai testare completamente un programma di una certa complessità."

Transcript

1 Software Testing Dott. Ing. Michele Banci DSI Università degli Studi di Firenze 1

2 Introduzione Attività atta alla valutazione di un programma (sistema) determinando che esso verifichi un determinato risultato atteso. Sebbene sia cruciale per la qualità del software e sia largamente utilizzato, Il testing del software rimane ancora un arte, ciò deriva dalla ridotta comprensione dei principi del software. La difficoltà deriva dalla complessità del software: Non si potrà mai testare completamente un programma di una certa complessità. Testing non vuol dire solo debugging Scopo del Testing: assicurazione di qualità, V&V, stima dell affidabilità. Le più importanti: testing di correttezza e di affidabilità. trade-off fra budget, tempo e qualità. DSI Università degli Studi di Firenze 2

3 Introduzione È quel processo di esecuzione dei un programma (o sistema) con lo scopo di trovare errori. Il software è simile a altri sistemi fisici in cui si hanno ingressi e si producono risultati (uscite). La differenza del software consiste nel modo in cui esso fallisce. Sistemi fisici: falliscono in un fissato ( piccolo ) insieme di modi. Il software può fallire in molti modi BIZZARRI. Individuare tutti i diversi modi di fallimento di un software è impossibile in generale. DSI Università degli Studi di Firenze 3

4 Introduzione A differenza dei sistemi fisici il software contempla esclusivamente errori di design, non sono presenti errori di costruzione (di produzione). No Corrosione No Deterioramento Non si modifica nel tempo I difetti di design permangono indefinitamente e resteranno latenti fino a quando non saranno attivati. DSI Università degli Studi di Firenze 4

5 Introduzione I bugs esistono quasi sempre in qualsiasi programma di una certa dimensione: Poca cura NO Irresponsabilità NO Generalmente la complessità del software è intrattabile in generale la mente umana ha una ridotta abilità nel trattare la complessità. DSI Università degli Studi di Firenze 5

6 Introduzione Il software, e anche i sistemi digitali, sono sistemi non continui, pertanto testare i valori di soglia non è sufficiente per garantirne la correttezza. Devono essere testati TUTTI i possibili valori un test completo sarebbe irrealizzabile. E.g. Testare un programma che somma due numeri interi di 32 bit in ingresso. Produce 2 64 test cases distinti = secondi = 1 anno Inoltre per applicazioni che interagiscono con il mondo esterno: Timing unpredictable environmental effects human interactions DSI Università degli Studi di Firenze 6

7 Introduzione Se si verifica un fallimento durante il testing e a seguito il codice viene cambiato il programma potrebbe superare altri test eseguiti in precedenza e non superati. Il programma potrebbe non superare test fatti in precedenza e già superati. Il testing dovrebbe ricominciare. Il costo di una tale attività risulterebbe proibitivo. Pesticide Paradox: Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. DSI Università degli Studi di Firenze 7

8 Introduzione Il testing è parte integrante dello sviluppo del software. Esso viene distribuito in ogni fase del ciclo di sviluppo del software. In genere, più del 50% del tempo di sviluppo viene utilizzato per il testing. DSI Università degli Studi di Firenze 8

9 Lo scopo del testing 1. Migliorare la qualità; 2. Verifica e Validazione (V&V); 3. Stimare l affidabilità. DSI Università degli Studi di Firenze 9

10 Migliorare la qualità. Computer e software usati in applicazioni critiche possono causare danni a cose e persone a causa dei BUGS. airplane crashes, space shuttle missions to go awry, halted trading on the stock market, Bugs can kill. Bugs can cause disasters. la qualità e l affidabilità di un software = vita o di morte. Qualità = conformità con i requisiti specificati in fase di design. Il Debugging (~ testing) viene eseguito dai programmatori al fine di individuare difetti di progettazione. La natura imperfetta dell uomo rende impossibile creare un programma corretto fin da subito. Lo scopo del debugging consiste nel trovare i problemi e risolverli durante la fase di programmazione. DSI Università degli Studi di Firenze 10

11 Verification & Validation (V&V) V&V (Verification & Validation) è un altro scopo importante del testing. Il testing può essere utilizzato come metrica. Basandoci sul risultato dei medesimi test è possibile eseguire un confronto comparativo fra prodotti diversi ma basati sulle medesime specifiche. Non è possibile testare la qualità in modo diretto, ma è possibile testare quei fattori correlati con la qualità. La qualità è costituita da 3 insiemi di fattori functionality, engineering, e adaptability. Questi 3 insiemi di fattori si possono pensare come una dimensioni nello spazio della qualità del software. Ciascuna dimensione può inoltre essere scomposta nei sui singoli fattori. DSI Università degli Studi di Firenze 11

12 Software Quality Factors Functionality (exterior quality) Correctness Reliability Usability Integrity Engineering (interior quality) Efficiency Testability Documentation Structure Adaptability (future quality) Flexibility Reusability Maintainability DSI Università degli Studi di Firenze 12

13 Misura della qualità Un buon testing deve poter fornire delle misure per i fattori di qualità rilevanti. L importanza dei fattori varia dal tipo di applicazione in esame. I sistemi in cui è in gioco la vita umana: reliability e integrity. Sistemi gestionali: usability e maintainability. Per programmi usati una sola volta per scopo scientifico: nessun fattore. Il nostro testing deve essere efficace, creato in modo tale da misurare i fattori di qualità in modo tale da rendere tangibile e visibile la qualità. Clean tests, o positive tests : Test atti a validare se il prodotto fa quello che deve fare. In realtà si riesce ad affermare che il programma funziona correttamente per quello specifico caso di test. Un numero finito di test non può garantire che il programma funziona correttamente in tutte le possibili situazioni. Dirty tests, o negative tests: al contrario dei precedenti anche un solo test fallito è sufficiente per dimostrare che il programma non funziona. Alcune parti del programma devono avere una sufficiente gestione delle eccezioni in grado di superare un certo livello di test negativi. Design for testing: è una parte importante dello sviluppo del software il quale rende più semplice il testing del programma stesso (riduce tempi e costi). DSI Università degli Studi di Firenze 13

14 For reliability estimation L affidabilità del software è spesso in relazione con la struttura dello stesso e la quantità del testing a cui è stato sottoposto. Basandosi su un approccio operazionale (stima della frequenza di uso dei vari input), il testing può fungere da campionamento statistico in modo tale da creare i dati di fallimento per stimare l affidabilità. Si utilizzano le medesime tecniche di testing inventate anni fa. Il testing del sw può essere molto costoso, ma in certi casi catastrofici il non fare testing può esserlo molto di più. Risolvere il problema del testing del software può essere paragonabile al problema della terminazione di Turing (halting problem): data una macchina di Turing M ed una stringa x, stabilire se M termina la computazione avendo x come input. Non possiamo mai essere sicuri della correttezza di un programma. Non possiamo mai essere sicuri della correttezza delle specifiche Non possiamo mai essere sicuri della correttezza del sistema di verifica DSI Università degli Studi di Firenze 14

15 Classificazione di metodi di testing (Livelli di test) By purpose: correctness testing, performance testing, reliability testing security testing. By scope: unit testing, mirato alla correttezza degli algoritmi component testing, integration testing, mirato alla correttezza delle interfacce system testing. affidabilità, sicurezza e prestazioni By life-cycle phase: requirements phase testing, design phase testing, program phase testing, evaluating test results, installation phase testing, acceptance testing imposto dal cliente, verifica che il programma soddisfi le richieste del cliente stesso. maintenance testing. (Test di regressione) verifica che non si siano introdotti errori in versioni successive DSI Università degli Studi di Firenze 15

16 Correctness testing (for unit test) La correttezza è il requisito minimo per un programma, è lo scopo primario del testing. Necessita di un Oracolo per poter discriminare un comportamento corretto da uno non corretto. Tester e sua conoscenza del modulo sotto test: White box (Test Strutturale) e.g. control flow, data flow, etc. Black box (test funzionale) Variano per il principio su cui si basa il criterio di selezione dei test. L approccio black-box e white-box non si limitano solo al test di correttezza. DSI Università degli Studi di Firenze 16

17 Test Funzionale - Black-box testing È un metodo in cui i dati di test sono derivati dalle specifiche funzionali senza considerare la struttura finale del software. Viene chiamato: data-driven, input/output driven, or requirements-based testing. Infatti ci si interessa soltanto delle funzionalità del modulo. Test funzionale: enfatizza l esecuzione delle funzioni e l analisi dei loro dati di ingresso e uscita. Il tester considera il software come una scatola nera sono visibili solo gli ingressi, le uscite e le specifiche funzionali, la funzionalità viene determinata osservando le uscite prodotte da determinati ingressi (funzioni di trasferimento). Vengono inviati (esercitati) vari input e le corrispondenti uscite sono confrontate con le specifiche così da validarne la correttezza. Tutti i casi di test sono derivati dalle specifiche. Non sono considerati i dettagli implementativi del codice. DSI Università degli Studi di Firenze 17

18 Black-box testing specifiche funzionali Inoltre, non potremo mai essere sicuri della correttezza e completezza delle specifiche. Dovuto alle limitazioni del linguaggio usato per le specifiche (linguaggio naturale), si avranno sicuramente problemi di ambiguità. Anche se usassimo formalismi o linguaggi ristretti, si potrebbe ancora errare nello scrivere tutti i possibili casi nelle specifiche. Le specifiche in se stesse possono divenire un problema intrattabile: Non è possibile specificare precisamente ogni situazione che si può incontrare utilizzando un numero limitato di parole. Le persone sono in grado di specificare chiaramente quello che desiderano? Normalmente sono in grado di dire se un prototipo corrisponde o meno a ciò che si desiderava. Il problema delle specifiche contribuisce a circa il 30% dei bugs nel software. DSI Università degli Studi di Firenze 18

19 Black-box testing spazio degli ingressi Maggiore è lo spazio di ingresso coperto e maggiori saranno i bugs individuati, pertanto si avrà maggior confidenza sulla qualità del sw. Idealmente si potrebbe tentare di testare esaustivamente lo spazio degli ingressi. IMPOSSIBILE L esplosione combinatoria è il maggior problema del testing funzionale. DSI Università degli Studi di Firenze 19

20 Black-box testing research forse eliminare La ricerca nel campo del black-box testing si rivolge a massimizzare l efficacia del testing col minor costo possibile (minor numero di casi di test). Non è possibile esaustivamente usare tutto lo spazio degli stati degli ingressi, ma è possibile sollecitare esaustivamente un sottospazio di tale spazio. Equivalence Class Partitiong (ECPT) Il partitioning una tecnica molto comune. Se abbiamo partizionato lo spazio degli ingressi e assunto che tutti i valori in una partizione sono equivalenti, allora si può testare solo un solo valore rappresentativo di ciascuna partizione per coprire tutto lo spazio degli ingressi. Il domain testing partiziona il dominio di ingresso in regioni, e considera i valori di ingresso in ciascun dominio come una classe di equivalenza. I domini possono essere testati esaustivamente e coperti selezionando un valore rappresentativo per ciascun dominio. Ovviamente i valori di confine rivestono un certo interesse. I test cases che esplorano i valori di confine hanno maggior valore rispetto a test con valori contenuti all interno del dominio. BOUNDARY VALUE ANALYSIS (BVAN) richiede uno o più valori limite selezionato come rappresentativo. Il problema con questo tipo di analisi sta nella errata definizione dei domini, questa definizione non può essere scoperta correttamente solo sulla base delle specifiche. Un buon partizionamento richiede la conoscenza della struttura del software. DSI Università degli Studi di Firenze 20

21 Black-box testing research Random testing Utilizzato per valutare l affidabilità e le performance ma non per la ricerca degli errori. I metodi basati sulle specifiche si riassumono in: 1. EQUIVALENCE CLASS PARTITIONING (ECPT) Si divide il dominio di input del programma in classi con l'ipotesi che un caso di test per ciascuna classe sia rappresentativo di tutti i valori della classe. Per ciascuna condizione di input si associano almeno due classi di equivalenza, una valida ed una invalida. 2. BOUNDARY VALUE ANALYSIS (BVAN) Si scelgono i casi di test in prossimità della frontiera delle classi. 3. TEST CASE by ERROR GUESSING (TCEG) Tecnica ad-hoc basata sull' intuito e sull' esperienza di chi esegue il test. DSI Università degli Studi di Firenze 21

22 Random Testing I dati utilizzati per i test cases sono selezionati casualmente nel dominio di ingressso del programma. Random testing non vuol dire che si abbandona completamente la input/output analysis del programma o del modulo. Lo scopo della maggior parte delle applicazioni è di creare un profilo operazionale del programma o del modulo. Definizione 1: Operational Profile Il Profilo operazionale di un programma nel dominio dei dati di ingresso è la distribuzione di probabilità di selezionare ciascun punto del dominio dei dati di ingresso mentre il programma viene utilizzato in condizioni normali di lavoro. DSI Università degli Studi di Firenze 22

23 Random Testing Una delle maggiori applicazioni del random testing è il fornire dati per la stima dell affidabilità del software. I Test case sono generati casualmente in accordo con il proofilo operazionale, e i dati di fallimento vengono acquisiti. I dati ottenuti dal random testing posso essere usati per la stima dell affidabilità. Nessun altro metodo di testing può essere utilizzato per tale stima. Qualsiasi stima di affidabilità non è corretta se il profilo operazionale non è corretto. DSI Università degli Studi di Firenze 23

24 Svantaggi del Random Testing 1. Può essere necessario creare un gran numero (proibitivo) di tests per poter essere confidenti di avere sufficientemente coperto il dominio di ingresso; 2. La distribuzione casuale degli ingressi identifica soltanto i guasti del programma Principio di Pareto-Zipf ( legge 80/20 ): i valori 80% e 20% sono ottenuti mediante osservazioni empiriche di numerosi fenomeni e sono solo indicativi, in genere l'80% dei risultati dipende dal 20% delle cause. 3. È difficile stimare la copertura o determinare se abbiamo adeguatamente il dominio di ingresso. DSI Università degli Studi di Firenze 24

25 Random Testing - Testing Oracles Il gran numero di casi di test che sono tipicamente necessari per avere risultati statisticamente significativi impone la necessità di creare automaticamente i casi di test. Casi di test automaticamente generati (TVG) è corretto se abbiamo il profilo operazionale e un buon modo di generazione casuale; Inoltre occorre un metodo per decidere se il risultato del test è un risultato atteso oppure no. Un programma o un insieme di dati o un processo che decide se i risultati sono quelli attesi è chiamato: Testing Oracle! DSI Università degli Studi di Firenze 25

26 Random Testing - Testing Oracles Esempio: Consideriamo la specifica di una funzione tolower la quale prende una stringa dallo standard input e pone la stringa corrispondente sullo standard output, con tutte le lettere maiuscole sostituite nelle corrispondenti lettere minuscole (i.e. A to a, B to b, etc.). Le stringhe possono essere formate da tutti i caratteri ASCII fra 32 e 126 inclusi; i caratteri al di fuori da questo range sono caratteri di controllo e causeranno un messaggio di errore. Come possiamo determinare se l output della funzione tolower coincide con con il risultato atteso? DSI Università degli Studi di Firenze 26

27 Random Testing - Testing Oracles Specifications Specifica formale scritta in una forma matematica (pseudo) risultano migliori al fine di selezionare e creare testing oracles piuttosto che specifiche informali scritte in linguaggio naturale. Solved examples sono sviluppati a mano. Parametric oracles caratterizzano una vasta classe di soluzioni per l ingresso del test scegliendo parametri appropriati. Built in tests and checks sono asserzioni che vengono aggiunte al codice per specificare quando un risultato è valido oppure invalido. Alternativamente si possono sviluppare procedure di self test. Data and Databases - Dati in forma di tabelle, documenti, grafi o altro formato contenenti i risultati. Golden program Utilizza specifiche eseguibili, versioni precedenti del programma, oppure eseguire un test in parallelo con un altro sistema che fornisce le stesse funzionalità. DSI Università degli Studi di Firenze 27

28 Equivalence Partitioning Come si possono creare casi di test in modo tale da coprire i guasti del programma. La risposta adottata il molti metodi di partitioning consiste nel dividere il dominio di ingresso e di uscita in modo tale che: 1. Occorrono meno casi di test per coprire grandi domini di ingresso; 2. Si hanno maggiori chance di scoprire guasti del programma; 3. Si ha una buona idea di quanto del dominio di ingresso si è coperto con i casi di test. DSI Università degli Studi di Firenze 28

29 Equivalence Partitioning Lo scopo consiste nel dividere il dominio di ingresso in classi (insiemi!) di casi di test i quali abbiano un effetto simile sul programma. Tali classi sono denominate CLASSI DI EQUIVALENZA. Definizione: Equivalence Class (EC) È un insieme di inputs che il programma tratta in modo identico quando il programma viene testato. DSI Università degli Studi di Firenze 29

30 Equivalence Partitioning Ciascuna Classe di equivalenza viene utilizzata per rappresentare certe condizioni (o predicati) sul dominio dei dati di ingresso. Per il partitioning si è soliti considerare sia gli ingressi validi che invalidi. Definizione: Una condizione sugli input (Input Condition) è un predicato sui valori degli ingressi. Un ingresso valido (Valid input) al programma o modulo è un elemento del dominio che si attende sia correttamente gestito dal programma restituendo un valore di non-errore (non errato). Un ingresso invalido ci si aspetta restituisca un valore di errore (valore errato). DSI Università degli Studi di Firenze 30

31 Equivalence Partitioning Input Conditions Sono usate tipicamente per partizionare il dominio di ingressi in classi di equivalenza allo scopo di selezionare certi ingressi. Consideriamo una versione modificata della specifica del quadrato di un numero questo dovrà restituire un intero di 32 bit: x {0,., 65535} square(x) = x * x Il dominio di ingresso dedotto dalla (scarna) specifica è l insieme di integer; La condizione di input è: x {0,., 65535} DSI Università degli Studi di Firenze 31

32 Equivalence Partitioning 1. È un metodo sistematico per identificare gli insiemi di classi di interesse di condizioni di ingresso da testare. 2. Ciascuna classe è rappresentativa di (copre) un insieme di altri possibili test. Ci si aspetta che il programma si comporti nello stesso modo fer tutti gli elementi della classe di equivalenza. Anziché scrivere test per tutti gli elementi della classe, si prende un test case rappresentativo e inferire le proprietà della classe da questo test case. Occorre fare attenzione assicurarsi che tutti i membri della classe si comportino allo stesso modo. DSI Università degli Studi di Firenze 32

33 Equivalence Partitioning: metodologia Lo scopo è quello di minimizzare il numero di casi di test necessari per coprire il dominio degli ingressi. 1. Identificare le classi di equivalenza (ECs); 2. Identificare i casi di test. DSI Università degli Studi di Firenze 33

34 Identifying Equivalence Classes: Guidelines 1. Se una condizione di ingresso specifica un range di valori, identificare una classe di equivalenza valida e due invalide. Esempio: Se abbiamo l insieme di valori {1,...., 99} allora occorreranno le seguenti classi: Classe di equivalenza valida {1,..., 99}; Classi di equivalenza invalide {x x < 1} and {x x > 99}. DSI Università degli Studi di Firenze 34

35 Identifying Equivalence Classes: Guidelines 2. Se una condizione di ingresso specifica un insieme di valori di ingresso e ciascuno è gestito in modo diverso, identificare una classe di equivalenza per ciascun elemento dell insieme e una invalida EC. Esempio: Se l ingresso è selezionato da un insieme di N distinti elementi allora occorreranno N + 1 ECs: Una valida EC per ciascun elemento dell insieme {M 1 },..., {M N }; Una invalida EC per gli elementi fuori dall insieme {x x {M 1,..., M N }}. 3. Se si ritiene che il programma maneggia ciascun ingresso valido in modo distinto, allora occorre definire una valida EC per ciascun ingresso valido. Esempio: Se l ingresso viene da un menu allora si definisce una valida EC per ciascun item del menu. DSI Università degli Studi di Firenze 35

36 Identifying Equivalence Classes: Guidelines 4. Se le specifiche indicano N ingressi validi, si devono definire una valida EC e due invalide EC per ciascun valore N dell ingresso Una per zero valori, e una per valori > N. 5. Se un condizione di ingresso specifica una situazione del tipo must be, identificare una valida EC e una invalida EC. Esempio: Il primo carattere di un input deve essere numerico allora occorreranno due EC una valida EC {s il primo carattere di s è numerico} una invalida EC {s il primo carattere non è numerico} 6. Se gli elementi in una EC sono trattati in modi diversi dal programma, allora la EC deve essere splittata in EC più piccole. DSI Università degli Studi di Firenze 36

37 Identifying Test Cases 1. Assegnare un unico numero a ciascuna EC. 2. while Non tutte le valide ECs sono state coperte dai casi di test do 3. scrivere un nuovo caso di test che copra il maggior numero di ECs non coperte. 4. while Tutte le invalide ECs non sono state coperte dai casi di test do 5. Scrivere un caso di test che copra uno e solo uno delle non coperte invalide ECs. DSI Università degli Studi di Firenze 37

38 Equivalence Partitioning: Esempio 1 Consideriamo la seguente specifica informale per il problema seguente: Classificazione di triangoli. 1. Il programma legge i 3 valori positivi dallo standard input. 2. I 3 valori sono interpretati come rappresentativi delle lunghezze dei lati di un triangolo. 3. Il programma stampa un messaggio sullo standard output che indica se il triangolo, se può essere creato, è scaleno, isoscele, equilatero o rettangolo. DSI Università degli Studi di Firenze 38

39 Equivalence Partitioning: Esempio 1 Quale è il dominio di ingresso per il suddetto programma? Le possibilità includono: L insieme di tutte le possibili stringhe in ingresso siamo testando la robustezza e vogliamo sapere se stringhe non corrette vengono rigettare dal programma; L insieme di tutti i possibili interi, sia positivi che negativi; L insieme di tutti i possibili interi positivi. Quali sono le condizioni degli ingressi? Requirement Input Condition 3 interi in ingresso (x; y; z) int int int Gli interi devono essere positivi: x>0, y>0, z>0. Nota: si sta utilizzando la regola 6 per determinare le classi di equivalenza. DSI Università degli Studi di Firenze 39

40 Equivalence Partitioning: ECs Le classi di equivalenza sono: Equivalence class Test Case scalene triangle isosceles triangle right-angled triangle non-triangle non-positive input equilateral triangle {(3, 5, 7),... } {(2, 3, 3),... } {(3, 4, 5),... } {(1, 1, 3),... } {(-1, 0, 3), (-2,-3,-3),... } {(7, 7, 7),... } DSI Università degli Studi di Firenze 40

41 Boundary Value Analysis Lo scopo è l analisi delle frontiere delle ECs. Intuitivamente si ha che i difetti (faults o failures) sono più probabili al confine fra due ECs. Sceglie i test cases sulla frontiera o intorno ad essa. È un raffinamento e estensione del partizionamento in ECs. Il partizionamento richiede la scelta di un solo caso di test mentre la BVA ne richiede di più. DSI Università degli Studi di Firenze 41

42 Boundary Conditions Definizione: Boundary Conditions sono predicati applicati sui valori di frontiera e su intorni delle ECs degli input e output. Le due differenze introdotte dalla BVA sono: 1. Sia le condizioni di ingresso che di uscita vengono usate per selezionare i casi di test. 2. Anziché un solo caso di test da una EC, BVA consiglia di prendere più casi di test in un intorno della frontiera. DSI Università degli Studi di Firenze 42

43 Boundary Conditions Se una condizione sugli input specifica un range di valori, allora si devono creare test case validi per gli estremi del range, e invalidi per i punti oltre la frontiera. Se una condizione sugli input specifica un numero di valori, si devono creare test case per il valore minimo e massimo,minotre uno all interno dei valori e all esterno di questi. Analogamente deve essere fatto per le condizioni sugli output. Le condizioni di frontiera possono essere difficili da identificare soprattutto per quel che riguarda il dominio delle uscite. DSI Università degli Studi di Firenze 43

44 The Triangle Program Revisited Specifica del problema: Il programma legge valori floating dal std input. I 3 valori sno i 3 lati del triangolo. Il programma stampa a video il risultato del tipo di triangolo (se è un triangolo) Isoscele, scaleno, equilatero, rettangolo DSI Università degli Studi di Firenze 44

45 The Triangle Program Revisted 1. dati i lati (A, B, C) per essere scaleno la somma dei qualsiasi coppia di lati deve essere > del terzo lato boundary conditions A + B > C B + C > A A + C > B Per la condizione A + B > C possiamo esplorare la frontiera usando i seguenti casi di test (1, 2, 3), (1, 2, 2.999), (1, 2, 3.001). 2. dati i lati (A, B, C) per essere isoscele due lati devono essere uguali boundary conditions A = B B = C A = C Per la condizione A = C possiamo esplorare la frontiera usando i seguenti casi di test (2, 2, 3), (2, 1.999, 3), (2, 2.001, 3),.. DSI Università degli Studi di Firenze 45

46 The Triangle Program Revisted 3. dati i lati (A, B, C) per essere equilatero tutti i lati dovranno essere uguali boundary A = B = C possiamo esplorare la frontiera usando i seguenti casi di test (3, 3, 3), (3, 2.999, 3), (3, 3.001, 3),.. 4. dati i lati (A, B, C) per essere rettangolo si deve avere A2 + B2 = C2 possiamo esplorare la frontiera usando i seguenti casi di test (3, 4, 5), (3, 4, 4.999), (3, 4, 5.001),.. 5. dati i lati (A, B, C) per non essere un triangolo si deve avere Frontiere simili alle precedenti (1, 2, 3), (1, 2, 2.999), (1, 2, 3.001),.. 6. per dati di ingresso non positivi si avrà (0, 1, 2), (-0.001, 1, 2), (0.001, 1, 2),.. DSI Università degli Studi di Firenze 46

47 White-box testing Il software viene considerato come una white-box, le strutture e il flusso del sw sono visibili al tester. I piani di test sono creati in base ai dettagli implementativi del software: il tipo di linguaggio usato, la logica, lo stile,... I casi di test si deriveranno dalla struttura del programma. White-box testing = glass-box testing = logic-driven testing = design-based testing. Esistono molte tecniche disponibili per il white-box testing, L intrattabilità del problema viene facilitata dalla conoscenza specifica della struttura del programma da testare. Si possono ottenere gradi di esaustività : Si esegue ciascuna riga di codice almeno una volta (statement coverage), Ogni branch statements viene attraversato (branch coverage), Copre tutte le possibili combinazioni di condizioni booleane (Multiple condition coverage). DSI Università degli Studi di Firenze 47

48 When to stop testing? Il testing è potenzialmente senza fine. Quando fermiamo l attività di testing? È un compromesso fra budget, tempo e qualità. Sarà guidato da modelli di profitto. Uno dei più usati metodi (non corretto) consiste nel terminare l attività quando il budget o il tempo o i casi di test sono finiti. Un metodo sicuramente migliore consiste nel terminare l attività quando l affidabilità ha raggiunto il livello richiesto o quando i benefici nel continuare il testing sarebbero minimi. Questo richiede l uso di modelli di affidabilità per stimare l affidabilità del software sotto test. DSI Università degli Studi di Firenze 48

49 Alternatives to testing (1) Software testing è considerato un metodo problematico per migliorare la qualità. Usare il testing per individuare e correggere i difetti può essere un processo senza fine. I bugs non possono essere completamente eliminati. Testare e fissare i problemi può non necessariamente migliorare la qualità e l affidabilità. Talvolta risolvere un problema può introdurne altri più severi. Item: In the summer of 1991, telephone outages occurred in local telephone systems in California and along the Eastern seaboard. These breakdowns were all the fault of an error in signaling software. Right before the outages, DSC Communications (Plano, TX) introduced a bug when it changed three lines of code in the several-million-line signaling program. After this tiny change, nobody thought it necessary to retest the program. Coverage testing: si può considerare che code coverage e branch coverage siano collegati alla qualità del software? Non ne esiste la prova. Il così detto "human testing" -- ispezione del codice, walkthroughs, reviews sono suggerite come una possibile alternativa. Alcuni risultati sperimentali indicano che la rilettura del codice tramite astrazione è efficienteb tanto quanto functional and structural testing in termini di numero di guasti osservati. I formal methods per provare la correttezza sono un altra strada possibile. Cmq non sono in grado di superare la barriera della complessità. DSI Università degli Studi di Firenze 49

Il Testing. Ing. Emilio Spinicci 24/03/2002 1

Il Testing. Ing. Emilio Spinicci 24/03/2002 1 Il Testing Ing. Emilio Spinicci 24/03/2002 1 Introduzione Cenni sulla teoria del testing Unit Testing - test funzionale - test strutturale - misure di copertura IPL Cantata 3.3 - Descrizione e esempi di

Dettagli

Software testing. Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it. A.A. 2010-2011 Autori: A.Bei/F.Rabini/F.

Software testing. Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it. A.A. 2010-2011 Autori: A.Bei/F.Rabini/F. 1 Software testing Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it A.A. 2010-2011 Autori: A.Bei/F.Rabini/F.Spiga 2 Functional Testing Sotto la dicitura funzionale si raccolgono i criteri

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Testing. Definizioni. incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell uso di strumenti

Testing. Definizioni. incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell uso di strumenti Definizioni Problemi del testing:criterio di selezione dei casi di test Test Funzionale: suddivisione in classi di equivalenza e analisi dei valori limite Test Strutturale: basato sul flusso di controllo

Dettagli

Sistemi Informativi I Lezioni di Ingegneria del Software

Sistemi Informativi I Lezioni di Ingegneria del Software 4 Codifica, Test e Collaudo. Al termine della fase di progettazione, a volte anche in parallelo, si passa alla fase di codifica e successivamente alla fase di test e collaudo. In questa parte viene approfondita

Dettagli

Verifica e validazione della qualità del sw

Verifica e validazione della qualità del sw Verifica e validazione della qualità del sw Tecniche di Programmazione Lez. 07 Università di Firenze a.a. 2009/10, I semestre 1/40 contenuti Termini e definizioni Tecniche rispetto alle caratteristiche

Dettagli

Verifica del codice con Interpretazione Astratta

Verifica del codice con Interpretazione Astratta Verifica del codice con Interpretazione Astratta Daniele Grasso grasso@dsi.unifi.it grasso.dan@gmail.com Università di Firenze, D.S.I., Firenze, Italy December 15, 2009 D.Grasso (Università di Firenze)

Dettagli

Ingegneria del Software Testing. Corso di Ingegneria del Software Anno Accademico 2012/2013

Ingegneria del Software Testing. Corso di Ingegneria del Software Anno Accademico 2012/2013 Ingegneria del Software Testing Corso di Ingegneria del Software Anno Accademico 2012/2013 1 Definizione IEEE Software testing is the process of analyzing a software item to detect the differences between

Dettagli

Software Testing. Lezione 1 Introduzione al processo di testing. Federica Spiga. federica_spiga@yahoo.it. A.A. 2010-2011 Autori: A. Bei/F.

Software Testing. Lezione 1 Introduzione al processo di testing. Federica Spiga. federica_spiga@yahoo.it. A.A. 2010-2011 Autori: A. Bei/F. Software Testing Lezione 1 Introduzione al processo di testing Federica Spiga federica_spiga@yahoo.it A.A. 2010-2011 Autori: A. Bei/F.Spiga 1 2 Definizione di Software Testing Glen Myers -The Art of Software

Dettagli

13: Il test del software. 13Test.1

13: Il test del software. 13Test.1 13: Il test del software 13Test.1 Concetti fondamentali Costo estremamente elevato Filosofia distruttiva Eseguire un programma con l intento di trovare degli errori; Un caso di test e ben studiato se ha

Dettagli

Ingegneria del Software

Ingegneria del Software Ingegneria del Software Testing - Strategie di del Software Testing del Software Il testing è quell attivit attività di esercizio del software tesa all individuazione dei malfunzionamenti prima della messa

Dettagli

Noi siamo quello che facciamo ripetutamente. Perciò l'eccellenza non è un'azione, ma un'abitudine. Aristotele. Qualità del Software

Noi siamo quello che facciamo ripetutamente. Perciò l'eccellenza non è un'azione, ma un'abitudine. Aristotele. Qualità del Software Noi siamo quello che facciamo ripetutamente. Perciò l'eccellenza non è un'azione, ma un'abitudine. Aristotele Qualità del Software Quality Assurance per tutte le esigenze Web Site Testing Mobile Application

Dettagli

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al.

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al. Modello Code and fix Processo parte III Leggere Sez. 7.4 Ghezzi et al. Modello iniziale Iterazione di due passi scrittura del codice correzione degli errori Problemi: dopo una serie di cambiamenti, la

Dettagli

Collaudo e qualità del software Quali test eseguire

Collaudo e qualità del software Quali test eseguire Collaudo e qualità del software Relatore Ercole Colonese Roma, Tipologie di test Temi trattati nel libro Modello a V Livelli di testing Tipi di test Test funzionali Test delle funzionalità Test di gestione

Dettagli

03/11/2009. Circa equivalente al test di chip hardware. Il testing è effettuato, per ogni modulo, in modo isolato per verificarne il comportamento

03/11/2009. Circa equivalente al test di chip hardware. Il testing è effettuato, per ogni modulo, in modo isolato per verificarne il comportamento Introduzione al Testing Unit Testing Ingegneria del Software L-A Glossario Reliability / Affidabilità: la misura del successo con cui il comportamento osservato di un sistema si correla con le specifiche

Dettagli

Ingegneria del Software

Ingegneria del Software Ingegneria del Software Testing - Tecniche di Collaudo del Software Collaudabilità Un attributo di qualità del software E il grado di semplicità con cui il software può essere collaudato Si compone di

Dettagli

Finalità del ciclo di vita nel System Engineering

Finalità del ciclo di vita nel System Engineering Fasi del ciclo di vita overview Finalità del ciclo di vita nel System Engineering Modularità Individuazione più agevole delle componenti riutilizzabili Ciclo di vita Esaustività Certezza di coprire tutte

Dettagli

Esempi di errori/difetti. algoritmi sintassi calcolo e precisione documento stress capacità ricovery sistema hardware e software standard e procedure

Esempi di errori/difetti. algoritmi sintassi calcolo e precisione documento stress capacità ricovery sistema hardware e software standard e procedure COLLAUDO Esempi di errori/difetti algoritmi sintassi calcolo e precisione documento stress capacità ricovery sistema hardware e software standard e procedure Verifica e Validazione Validazione Requisiti

Dettagli

Verifica della Qualità del Software. Cosimo Laneve laneve@cs.unibo.it

Verifica della Qualità del Software. Cosimo Laneve laneve@cs.unibo.it Verifica della Qualità del Software Cosimo Laneve laneve@cs.unibo.it UNIVERSITÀ DEGLI STUDI DI BOLOGNA DIPARTIMENTO DI SCIENZE DELL'INFORMAZIONE Mura Anteo Zamboni 7, Bologna il processo di sviluppo del

Dettagli

Ingegneria del Software 21. Verifica e validazione. Dipartimento di Informatica Università di Pisa A.A. 2014/15

Ingegneria del Software 21. Verifica e validazione. Dipartimento di Informatica Università di Pisa A.A. 2014/15 Ingegneria del Software 21. Verifica e validazione Dipartimento di Informatica Università di Pisa A.A. 2014/15 roadmap Concetti e terminologia Verifica, validazione, integrazione e collaudo Verifica statica

Dettagli

Verifica e Convalida

Verifica e Convalida Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Verifica e Convalida E. TINELLI Definizioni Le attività di Verifica (Verification) e Convalida (Validation)

Dettagli

1. L Ingegneria del Software

1. L Ingegneria del Software 1. L Ingegneria del Software Obiettivi della lezione: Definire cosa si intende per Ingegneria del Software Discutere i concetti di prodotto software e di processo software Spiegare il concetto di visibilità

Dettagli

Survey sui Framework per Testing di Sistemi Basati su Web Services

Survey sui Framework per Testing di Sistemi Basati su Web Services Survey sui Framework per Testing di Sistemi Basati su Web Services Severoni Francesco Facoltà di Scienze Dipartimento di Informatica Università degli Studi - L Aquila 67100 L Aquila, Italia Argomenti Trattati

Dettagli

Definizione e sviluppo di un tool per la generazione automatica di documentazione di testing nel contesto di progetti software open source

Definizione e sviluppo di un tool per la generazione automatica di documentazione di testing nel contesto di progetti software open source Università degli Studi dell Insubria FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Specialistica in Informatica Definizione e sviluppo di un tool per la generazione automatica di documentazione

Dettagli

Il Processo di Testing

Il Processo di Testing Il Processo di Testing I deliverable del processo di testing Il testing è un processo; L'esigenza di definire modelli di riferimento a partire dai quali istanziare tali processi; Un modo per fissare riferimenti

Dettagli

Tecniche di Testing Black Box

Tecniche di Testing Black Box Tecniche di Testing Black Box 1 Riferimenti Ian Sommerville, Ingegneria del Software, capitoli 22-23-24 Pressman, Principi di Ingegneria del Software, 5 edizione, Capitoli 15-16 Ghezzi, Jazazeri, Mandrioli,

Dettagli

È prassi comune dividere l attività di progettazione di software in due:

È prassi comune dividere l attività di progettazione di software in due: Ingegneriia dell software: Generalliità Introduzione La soluzione di un generico problema mediante un sistema di elaborazione consiste nel passaggio dalla, descrizione dei problema di partenza al programma

Dettagli

Test del Software. Definizione SCOPO LIMITI DEL TEST

Test del Software. Definizione SCOPO LIMITI DEL TEST Definizione! Verifica dinamica del comportamento del software rispetto a quello atteso, utilizzando un insieme finito di casi di test, appropriatamente selezionati nel dominio di tutti i casi possibili

Dettagli

Chi, come e quando predispone il contenuto delle specifiche?

Chi, come e quando predispone il contenuto delle specifiche? Chi, come e quando predispone il contenuto delle specifiche? Giovanna Petrone Dipartimento di Informatica Università di Torino La Crisi del Software Problemi con il software: Spesso consegnato troppo tardi

Dettagli

Specifica dei requisiti

Specifica dei requisiti Specifica dei requisiti Contenuto: Cosa sono i requisiti Specifica col metodo classico Standard IEEE 830-1998 Cenni su altri standard 1 Cosa sono i requisiti Con la parola requisito si intende una caratteristica

Dettagli

Software solido e usabile: come integrare ingegneria dell usabilità e del software

Software solido e usabile: come integrare ingegneria dell usabilità e del software Software solido e usabile: come integrare ingegneria dell usabilità e del software Giorgio Brajnik e Andrea Baruzzo Dip. di Matematica e Informatica Università di Udine e Interaction Design Solutions srl

Dettagli

Ingegneria del Software T. 2. Analisi orientata agli oggetti

Ingegneria del Software T. 2. Analisi orientata agli oggetti Ingegneria del Software T 2. Analisi orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare

Dettagli

Verifica e Validazione del Simulatore

Verifica e Validazione del Simulatore Verifica e del Simulatore I 4 passi principali del processo simulativo Formulare ed analizzare il problema Sviluppare il Modello del Sistema Raccolta e/o Stima dati per caratterizzare l uso del Modello

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Ingegneria del Software L-A 2.1. 2. Analisi orientata agli oggetti Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2.

Analisi. Ingegneria del Software L-A. Analisi. Analisi. Analisi e gestione dei rischi. Analisi e gestione dei rischi. Ingegneria del Software L-A 2. Ingegneria del Software L-A 2. orientata agli oggetti Per effettuare correttamente l analisi, è necessario Comunicare con l utente Ottenere una buona conoscenza dell area applicativa Determinare in dettaglio

Dettagli

Giuseppe Santucci. Qualità nella Produzione del Software. 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System)

Giuseppe Santucci. Qualità nella Produzione del Software. 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System) Giuseppe Santucci Qualità nella Produzione del Software 02- Il sistema assicurazione qualità (SQAS: Sofware Quality Assurance System) 02SQAS.1 Peculiarità del SW XXX warrants that the media (!) on which

Dettagli

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

Metodologie di programmazione in Fortran 90

Metodologie di programmazione in Fortran 90 Metodologie di programmazione in Fortran 90 Ing. Luca De Santis DIS - Dipartimento di informatica e sistemistica Anno accademico 2007/2008 Fortran 90: Metodologie di programmazione DIS - Dipartimento di

Dettagli

Software Embedded Integration Testing. Ing. Matteo Maglio Milano, 17 Febbraio 2011

Software Embedded Integration Testing. Ing. Matteo Maglio Milano, 17 Febbraio 2011 Software Embedded Integration Testing Ing. Matteo Maglio Milano, 17 Febbraio 2011 Chi siamo Skytechnology è una società di ingegneria che opera nell area dei sistemi embedded aiutando i propri Clienti

Dettagli

Tecniche di Simulazione: Introduzione. N. Del Buono:

Tecniche di Simulazione: Introduzione. N. Del Buono: Tecniche di Simulazione: Introduzione N. Del Buono: 2 Che cosa è la simulazione La SIMULAZIONE dovrebbe essere considerata una forma di COGNIZIONE (COGNIZIONE qualunque azione o processo per acquisire

Dettagli

ITAlian Software Testing Qualifications Board Simulazione d Esame. Livello Foundation. Versione 2011

ITAlian Software Testing Qualifications Board Simulazione d Esame. Livello Foundation. Versione 2011 ITAlian Software Testing Qualifications Board Simulazione d Esame Livello Foundation Versione 2011 DATI IDENTIFICATIVI CODICE DOCUMENTO DATA DI EMISSIONE STATO ITASTQB-EXAMSIM-FOUND-01 15/01/2012 REDATTA

Dettagli

Modelli di Processo. www.vincenzocalabro.it

Modelli di Processo. www.vincenzocalabro.it Modelli di Processo Il Modello del Processo Il modello del processo stabilisce i principi di base su cui si fonda lo sviluppo del software (e a cui è dovuto il successo o l insuccesso) Non esiste un unico

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

Indice. Prefazione all edizione italiana

Indice. Prefazione all edizione italiana Indice Prefazione all edizione italiana XV Capitolo 1 Il software e l ingegneria del software 1 1.1 L evoluzione del ruolo del software 3 1.2 Il software 5 1.3 La natura mutevole del software 8 1.4 Il

Dettagli

Corso ISTQB Certified Tester Livello Foundation

Corso ISTQB Certified Tester Livello Foundation Fornitore della formazione accreditato da ITA-STQB Corso ISTQB Certified Tester Livello Foundation Conforme al Syllabus Foundation versione 2011 ALTEN ITALIA ACADEMY ALTEN ITALIA is: Certified by BMC for

Dettagli

Tecniche e strumenti per il testing di modelli software Matlab/Simulink

Tecniche e strumenti per il testing di modelli software Matlab/Simulink Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato Finale in Ingegneria del Software Tecniche e strumenti per il testing di modelli software Matlab/Simulink

Dettagli

Domenico Ercolani Come gestire la sicurezza delle applicazioni web

Domenico Ercolani Come gestire la sicurezza delle applicazioni web Domenico Ercolani Come gestire la sicurezza delle applicazioni web Agenda Concetti generali di sicurezza applicativa La soluzione IBM La spesa per la sicurezza non è bilanciata Sicurezza Spesa Buffer Overflow

Dettagli

Manutenzione del software

Manutenzione del software del software Generalità Leggi dell evoluzione del software Classi di manutenzione Legacy systems Modelli di processo per la manutenzione 1 Generalità La manutenzione del software è il processo di modifica

Dettagli

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale tesi di laurea inventario comunale Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo Ing. Luigi Pontillo candidato Michele Vitelli Matr. 534 2170 Redazione dell Inventario

Dettagli

Software Testing. Lezione 2 Livelli di test. Federica Spiga. federica_spiga@yahoo.it. A.A. 2010-2011 Autori: F.Rabini/F.Spiga

Software Testing. Lezione 2 Livelli di test. Federica Spiga. federica_spiga@yahoo.it. A.A. 2010-2011 Autori: F.Rabini/F.Spiga Software Testing Lezione 2 Livelli di test Federica Spiga federica_spiga@yahoo.it A.A. 2010-2011 Autori: F.Rabini/F.Spiga 1 2 Livelli di test Unit Testing Integration Testing System Testing Unit Testing

Dettagli

Introduzione ai Metodi Formali

Introduzione ai Metodi Formali Intruzione ai Meti Formali Sistemi software anche molto complessi regolano la vita quotidiana, anche in situazioni life-critical (e.g. avionica) e business-critical (e.g. operazioni bancarie). Esempi di

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA ROMA 18-20 GIUGNO 2012 ROMA 21-22 GIUGNO 2012 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37

LA TECHNOLOGY TRANSFER PRESENTA ROMA 18-20 GIUGNO 2012 ROMA 21-22 GIUGNO 2012 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 LA TECHNOLOGY TRANSFER PRESENTA RANDY RICE TESTING DI SISTEMI LEGACY COMPLESSI E NON DOCUMENTATI PRACTICAL SOFTWARE TEST AUTOMATION ROMA 18-20 GIUGNO 2012 ROMA 21-22 GIUGNO 2012 VISCONTI PALACE HOTEL -

Dettagli

Model Based Design per lo sviluppo e la verifica di moduli software in ambito Automotive

Model Based Design per lo sviluppo e la verifica di moduli software in ambito Automotive Model Based Design per lo sviluppo e la verifica di moduli software in ambito Automotive Automotive SPIN Italia - 4 Workshop on Automotive Software Roberto Sobrito, Software Engineer - FIAT Group Automobiles

Dettagli

υ Verifica della completezza di una definizione υ Identificazione dei requisiti del software υ Identificazione degli obiettivi del progetto

υ Verifica della completezza di una definizione υ Identificazione dei requisiti del software υ Identificazione degli obiettivi del progetto La Norma ISO/IEC 9126 Luigi Lavazza, 2001 ISO/IEC 9126 1 υ Standard di valutazione della qualità di prodotti software dell International Organisation for Standardisation e dell International Electrotechnical

Dettagli

Descrizione... 3 Comprensione del Processo Produttivo... 3. Definizione del Problema... 4. Selezione delle Caratteristiche... 5. Box Plot...

Descrizione... 3 Comprensione del Processo Produttivo... 3. Definizione del Problema... 4. Selezione delle Caratteristiche... 5. Box Plot... Pagina 2 Descrizione... 3 Comprensione del Processo Produttivo... 3 Definizione del Problema... 4 Selezione delle Caratteristiche... 5 Box Plot... 6 Scatterplot... 6 Box Plot... 7 Scatterplot... 7 Alberi

Dettagli

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Business white paper Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Indice 3 Sommario esecutivo 3 Introduzione 3 Best practice a livello aziendale 5 Best practice a

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA. a Software Improvement. Better, Faster, Cheaper ROMA 21-22 GIUGNO 2010 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37

LA TECHNOLOGY TRANSFER PRESENTA. a Software Improvement. Better, Faster, Cheaper ROMA 21-22 GIUGNO 2010 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 LA TECHNOLOGY TRANSFER PRESENTA GARY GACK MANAGING HIGH RISK PROJECTS a Software Improvement Workshop Better, Faster, Cheaper ROMA 21-22 GIUGNO 2010 VISCONTI PALACE HOTEL - VIA FEDERICO CESI, 37 info@technologytransfer.it

Dettagli

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard Quality gate Nei punti chiave del processo di sviluppo del software, viene integrato un insieme di quality gate per monitorare la qualità del prodotto intermedio prima che quest ultimo possa passare al

Dettagli

Simulazione di guasto

Simulazione di guasto Simulazione di guasto Problemi e applicazioni Algoritmi Seriale Parallelo Deduttivo Concorrente Random Fault Sampling Sommario Problemi e Applicazioni Problema, dati: Un circuito Una sequenza di vettori

Dettagli

Introduzione all Ingegneria del Software

Introduzione all Ingegneria del Software Introduzione all Ingegneria del Software Alessandro Martinelli alessandro.martinelli@unipv.it 10 Dicembre 2013 Introduzione all Ingegneria del Software Ingegneria del Software Modelli di Sviluppo del Software

Dettagli

Ingegneria del SW. Nathalie Morey. nmorey@unime.it. E-mail. 20-06-2013 Inizio. Indietro Avanti

Ingegneria del SW. Nathalie Morey. nmorey@unime.it. E-mail. 20-06-2013 Inizio. Indietro Avanti Ingegneria del SW Nathalie Morey E-mail nmorey@unime.it 20-06-2013 Programma Principi di ingegneria del software Processo software Ciclo di vita Definizione del problema Analisi dei requisiti e specifiche:

Dettagli

Rapporto tecnico contenente l analisi delle tecniche di verifica e convalida

Rapporto tecnico contenente l analisi delle tecniche di verifica e convalida Rapporto tecnico contenente l analisi delle tecniche di verifica e convalida Indice 1 Introduzione 3 2 Verification & Validation 3 3 Verifica del dimostratore 5 3.1 Strategie di test............................

Dettagli

I Modelli della Ricerca Operativa

I Modelli della Ricerca Operativa Capitolo 1 I Modelli della Ricerca Operativa 1.1 L approccio modellistico Il termine modello è di solito usato per indicare una costruzione artificiale realizzata per evidenziare proprietà specifiche di

Dettagli

Rappresentazione e Memorizzazione dei Dati

Rappresentazione e Memorizzazione dei Dati Rappresentazione e Memorizzazione dei Dati Giuseppe Nicosia CdL in Matematica (Laurea Triennale) Facoltà di Scienze MM.FF.NN. Università di Catania Bit e loro Memorizzazione Definizioni Algoritmo: una

Dettagli

Metodologie di progettazione

Metodologie di progettazione Metodologie di progettazione 1 Metodologie di progettazione Una procedura per progettare un sistema Il flusso di progettazione può essere parzialmente o totalmente automatizzato. Un insieme di tool possono

Dettagli

Scienze del computer. Cliente. Funzioni del computer. Problema. Teorie. Ingegneria del Software. Strumenti e Tecniche per Risolvere il problema

Scienze del computer. Cliente. Funzioni del computer. Problema. Teorie. Ingegneria del Software. Strumenti e Tecniche per Risolvere il problema L ingegneria del SW è un campo della scienze del computer che si occupa della costruzione di sistemi software complessi che vengono sviluppati da equipe di ingegneri. Sistemi che devono essere in servizio

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza. Roberto Ugolini roberto.ugolini@postecom.it

Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza. Roberto Ugolini roberto.ugolini@postecom.it Ciclo di vita del software: strumenti e procedure per migliorarne la sicurezza Roberto Ugolini 1 Il processo di sviluppo sicuro del codice (1/2) Il processo di sviluppo sicuro del codice () è composto

Dettagli

Project Management e Business Analysis: the dynamic duo. Firenze, 25 Maggio 2011

Project Management e Business Analysis: the dynamic duo. Firenze, 25 Maggio 2011 Project Management e Business Analysis: the dynamic duo Firenze, 25 Maggio 2011 Grazie! Firenze, 25 Maggio 2011 Ing. Michele Maritato, MBA, PMP, CBAP 2 E un grazie particolare a www.sanmarcoinformatica.it

Dettagli

3. SOFTWARE MANAGEMENT

3. SOFTWARE MANAGEMENT 3. SOFTWARE MANAGEMENT Introdurre caratteristiche e problematiche della direzione di progetto software (software management) Discutere la pianificazione di un progetto e la temporizzazione (scheduling)

Dettagli

VLSI Testing. Motivazioni

VLSI Testing. Motivazioni VLSI Testing Motivazioni Tipi di collaudo Specifiche e pianificazione Programmazione Analisi dei dati di collaudo Automatic Test Equipment Collaudo parametrico Sommario 1 Motivazioni Automatic Test Equipment

Dettagli

La Progettazione del Software

La Progettazione del Software del Software Definizioni IEEE Metodologie di progettazione Principi di progettazione Tecniche di progettazione (top down e bottom up) Moduli e criteri di modularizzazione: coesione ed accoppiamento, indipendenza

Dettagli

Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT. Paolo Salvaneschi A9_1 V1.3. Misura

Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT. Paolo Salvaneschi A9_1 V1.3. Misura Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi A9_1 V1.3 Misura Il contenuto del documento è liberamente utilizzabile dagli studenti, per studio personale e per

Dettagli

Analisi e Verifica di Programmi Laboratorio di AVP

Analisi e Verifica di Programmi Laboratorio di AVP Analisi e Verifica di Programmi Laboratorio di AVP Corso di Laurea in Informatica AA 2004-05 Tino Cortesi Analisi e Verifica Cosa Individuare proprietà interessanti dei nostri programmi: Valori prodotti,

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL C

Corso di Amministrazione di Sistema Parte I ITIL C Corso di Amministrazione di Sistema Parte I ITIL C Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici IT

Dettagli

SERVIZI DI ASSET MANAGEMENT

SERVIZI DI ASSET MANAGEMENT SERVIZI DI ASSET MANAGEMENT 1 6 SERVIZI DI ASSET MANAGEMENT Durante le diverse fasi del ciclo di vita di un Progetto, dalla fase di Concept, allo studio di fattibilità, fino alla progettazione di dettaglio,

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

Formazione Aziendale per la Qualità

Formazione Aziendale per la Qualità 4 Corsi e Formazione per la Qualità Formazione Aziendale per la Qualità Il nostro obiettivo L organizzazione, l analisi e l interpretazione dei dati aziendali all interno del proprio business, può rappresentare

Dettagli

Stima dell'effort. IT Project Management. Lezione 6 Stima dell effort Federica Spiga. Monitoring del progetto (Earned Value)

Stima dell'effort. IT Project Management. Lezione 6 Stima dell effort Federica Spiga. Monitoring del progetto (Earned Value) IT Project Management Lezione 6 Stima dell effort Federica Spiga A.A. 2009-2010 1 Check list del PM Identificare i requisiti del cliente Monitoring del progetto (Earned Value) Identificare i deliverable

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

Dettagli

7. La Qualità del Software

7. La Qualità del Software Cosa è la qualità 7. La del Software Diversi enti di standardizzazione (es. ISO) hanno cercato di integrare vari approcci alla definizione della qualita, partendo dalla consapevolezza che la qualità è

Dettagli

Informatica Industriale -- 2

Informatica Industriale -- 2 Informatica Industriale L. Mezzalira Informatica Industriale -- 2 prof. Lorenzo MEZZALIRA CIM - Automazione - Tempo reale Cap. 1 PROCESSI INDUSTRIALI FUNZIONI APPLICATIVE STRUMENTI INFORMATICI TEMPO REALE

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 2. Ciclo di Vita e Processi di

Dettagli

AUTOMI A STATI FINITI. G. Ciaschetti

AUTOMI A STATI FINITI. G. Ciaschetti AUTOMI A STATI FINITI G. Ciaschetti CONTENUTI Definizione di sistema Classificazione dei sistemi Definizione di modello Algebra degli schemi a blocchi Sistemi sequenziali Automi a stati finiti Macchina

Dettagli

INTRODUZIONE ALLA MODELLAZIONE ENERGETICA IN REGIME DINAMICO

INTRODUZIONE ALLA MODELLAZIONE ENERGETICA IN REGIME DINAMICO Dipartimento di Ingegneria Industriale MODELLAZIONE ENERGETICA IN REGIME DINAMICO La parola ai software Verona - 9 ottobre 2013 INTRODUZIONE ALLA MODELLAZIONE ENERGETICA IN REGIME DINAMICO Roberto Zecchin

Dettagli

Università degli studi di Roma Tor Vergata Ingegneria Medica Informatica I Programma del Corso

Università degli studi di Roma Tor Vergata Ingegneria Medica Informatica I Programma del Corso Obiettivi formativi Introdurre i principi del funzionamento di un elaboratore e della programmazione. Presentare gli approcci elementari alla soluzione di problemi (algoritmi)e al progetto di strutture

Dettagli

Stimare il WCET Metodo classico e applicazione di un algoritmo genetico

Stimare il WCET Metodo classico e applicazione di un algoritmo genetico Stimare il WCET Metodo classico e applicazione di un algoritmo genetico Sommario Introduzione Definizione di WCET Importanza del WCET Panoramica dei classici metodi per calcolare il WCET [1] Utilizzo di

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

Dettagli

Principi di Ingegneria del software 5/ed Roger S. Pressman. Glossario

Principi di Ingegneria del software 5/ed Roger S. Pressman. Glossario Principi di Ingegneria del software 5/ed Glossario Affidabilità il grado in cui un programma svolge la propria funzione con la precisione richiesta in un certo intervallo di tempo. Alfa testing testing

Dettagli

Test e validazione 1 La fase di test 1.1 Tecniche Ispezione: checklist Test white box: grafo di controllo complessità ciclomatica

Test e validazione 1 La fase di test 1.1 Tecniche Ispezione: checklist Test white box: grafo di controllo complessità ciclomatica Test e validazione 1 La fase di test Il test è il processo di verifica di un programma con lo scopo di individuare errori prima della consegna all utente finale. Tipicamente, correggere i difetti sul software

Dettagli

3. DOCUMENTO DI DEFINIZIONE DEI REQUISITI FORNITO DAL CLIENTE 3.1 Richieste del cliente

3. DOCUMENTO DI DEFINIZIONE DEI REQUISITI FORNITO DAL CLIENTE 3.1 Richieste del cliente T4 Contenuto di un analisi dei requisiti Presentate un indice di un documento di analisi dei requisiti e descrivete in modo sintetico contenuto e ruolo di ogni capitolo. INDICE 1. STORIA DELLE REVISIONI

Dettagli

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi

metodologie metodologia una serie di linee guida per raggiungere certi obiettivi metodologie a.a. 2003-2004 1 metodologia una serie di linee guida per raggiungere certi obiettivi più formalmente: un processo da seguire documenti o altri elaborati da produrre usando linguaggi più o

Dettagli

Valutazione sperimentale di tecniche di testing per software in relazione ai tipi di guasti

Valutazione sperimentale di tecniche di testing per software in relazione ai tipi di guasti tesi di laurea Valutazione sperimentale di tecniche di testing per software Anno Accademico 2008/2009 relatore Ch.mo prof. Stefano Russo correlatore Ing. Roberto Pietrantuono candidato Giuseppe Scafuti

Dettagli

Progettazione del Software. www.vincenzocalabro.it

Progettazione del Software. www.vincenzocalabro.it Progettazione del Software 1 Progettazione del Software Software Design = derivare soluzioni che soddisfino il documento dei requisiti Fasi del processo di progettazione Strategie di progettazione: approccio

Dettagli

Ciclo di vita del software

Ciclo di vita del software Ciclo di vita del software Da Wikipedia, l'enciclopedia libera. L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività

Dettagli

Il processo di certificazione del software MD

Il processo di certificazione del software MD Il processo di certificazione del software MD Ing. Maurizio Bianchi Responsabile Tecnico Dispositivi Medici - IMQ S.p.A. maurizio.bianchi@imq.it Vicenza, 5 ottobre 2007 Introduzione Moduli certificativi

Dettagli

1. Hard Real Time Linux (Laurea VO o specialistica)

1. Hard Real Time Linux (Laurea VO o specialistica) 20/9/06 Elenco Tesi Disponibili Applied Research & Technology Dept. La Società MBDA La MBDA Italia è un azienda leader nella realizzazione di sistemi di difesa che con i suoi prodotti è in grado di soddisfare

Dettagli

PMBOK Guide 5th Edition (2012) vs PMBOK Guide 4th Edition (2008)

PMBOK Guide 5th Edition (2012) vs PMBOK Guide 4th Edition (2008) Paolo Mazzoni 2013. E' ammessa la riproduzione per scopi di ricerca e didattici se viene citata la fonte completa nella seguente formula: "di Paolo Mazzoni, www.paolomazzoni.it, (c) 2013". Non sono ammesse

Dettagli

Titolo della tesi Testing Black Box di un Web Service : sperimentazione su di un servizio con stato

Titolo della tesi Testing Black Box di un Web Service : sperimentazione su di un servizio con stato tesi di laurea Titolo della tesi Testing Black Box di un Web Service : sperimentazione su di un servizio con stato Anno Accademico 2005/2006 relatore Ch.mo prof. Porfirio Tramontana candidato Giuseppe

Dettagli