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

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

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

Ing. Emilio Spinicci 07/04/2004 1

Ing. Emilio Spinicci 07/04/2004 1 Il Testing Ing. Emilio Spinicci 07/04/2004 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

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

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

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 elettronici per la sicurezza dei veicoli: presente e futuro. Il ruolo della norma ISO 26262 per la Sicurezza Funzionale

Sistemi elettronici per la sicurezza dei veicoli: presente e futuro. Il ruolo della norma ISO 26262 per la Sicurezza Funzionale La Sicurezza Funzionale del Software Prof. Riccardo Sisto Ordinario di Sistemi di Elaborazione delle Informazioni Dipartimento di Automatica e Informatica Sicurezza Funzionale del Vari Aspetti Sicurezza

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

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

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

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

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

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

Introduzione alla verifica automatica

Introduzione alla verifica automatica Sistemi digitali Introduzione alla verifica automatica Utilizzati in quasi tutte le attività umane Complessità elevata semplici sistemi hanno milioni di linee di codice Tempi di realizzazione sempre più

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

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software.

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Test Giulio Destri Ing. del Software: Test - 1 Scopo del modulo Definire

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

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

Testing: basato su analisi dinamica del codice. Metodi Formali: basato su analisi statica del codice.

Testing: basato su analisi dinamica del codice. Metodi Formali: basato su analisi statica del codice. Convalida: attività volta ad assicurare che il SW sia conforme ai requisiti dell utente. Verifica: attività volta ad assicurare che il SW sia conforme alle specifiche dell analista. Goal: determinare malfunzionamenti/anomalie/errori

Dettagli

Verifica parte IIA. Test (o analisi dinamica) Mancanza di continuità. Esempio

Verifica parte IIA. Test (o analisi dinamica) Mancanza di continuità. Esempio Test (o analisi dinamica) Verifica parte IIA Rif. Ghezzi et al. 6.3-6.3.3 Consiste nell osservare il comportamento del sistema in un certo numero di condizioni significative Non può (in generale) essere

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

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

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

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 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

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

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

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

SCD IS. Verifica e validazione: analisi dinamica. Verifica e validazione: analisi dinamica. Caratterizzazione. Definizione

SCD IS. Verifica e validazione: analisi dinamica. Verifica e validazione: analisi dinamica. Caratterizzazione. Definizione Caratterizzazione Verifica e validazione: analisi dinamica Anno accademico 2014/15 Ingegneria del Software mod. B Tullio Vardanega, tullio.vardanega@math.unipd.it SCD IS Parte essenziale del processo di

Dettagli

Test della libreria JSetL tramite JUnit

Test della libreria JSetL tramite JUnit UNIVERSITÀ DEGLI STUDI DI PARMA FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE e NATURALI Corso di Laurea in Informatica Tesi di Laurea Test della libreria JSetL tramite JUnit Relatore: Prof. Gianfranco Rossi

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 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

Correttezza. Corso di Laurea Ingegneria Informatica Fondamenti di Informatica 1. Dispensa 10. A. Miola Novembre 2007

Correttezza. Corso di Laurea Ingegneria Informatica Fondamenti di Informatica 1. Dispensa 10. A. Miola Novembre 2007 Corso di Laurea Ingegneria Informatica Fondamenti di Informatica 1 Dispensa 10 Correttezza A. Miola Novembre 2007 http://www.dia.uniroma3.it/~java/fondinf1/ Correttezza 1 Contenuti Introduzione alla correttezza

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

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

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

Programmazione in Java (I modulo) Lezione 3: Prime nozioni

Programmazione in Java (I modulo) Lezione 3: Prime nozioni Programmazione in Java (I modulo) Lezione 3: Prime nozioni La volta scorsa Abbiamo avuto un primo assaggio! Abbiamo visto come usare l editor per scrivere un programma Java. Abbiamo analizzato riga per

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

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

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

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

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

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

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

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

Qualità del software. Tecniche di Programmazione 2009/10. Giovanni A. Cignoni - http://www.di.unipi.it/~giovanni/ 1. contenuti. definizione di qualità

Qualità del software. Tecniche di Programmazione 2009/10. Giovanni A. Cignoni - http://www.di.unipi.it/~giovanni/ 1. contenuti. definizione di qualità Qualità del software Tecniche di Programmazione Lez. 05 Università di Firenze a.a. 2009/10, I semestre 1/33 contenuti Qualità? Definizioni Il prodotto software Modelli della qualità per il sw: ISO/IEC

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

È 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

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

ACRL Association of College and Research Libraries

ACRL Association of College and Research Libraries ACRL Association of College and Research Libraries Standard delle competenze per il possesso dell informazione (information literacy) nell educazione superiore Standard, indicatori di performance, obiettivi

Dettagli

Esercizi su. Funzioni

Esercizi su. Funzioni Esercizi su Funzioni ๒ Varie Tracce extra Sul sito del corso ๓ Esercizi funz_max.cc funz_fattoriale.cc ๔ Documentazione Il codice va documentato (commentato) Leggibilità Riduzione degli errori Manutenibilità

Dettagli

Dispense di Filosofia del Linguaggio

Dispense di Filosofia del Linguaggio Dispense di Filosofia del Linguaggio Vittorio Morato II settimana Gottlob Frege (1848 1925), un matematico e filosofo tedesco, è unanimemente considerato come il padre della filosofia del linguaggio contemporanea.

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

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

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

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

AREA MATEMATICO-SCIENTIFICO-TECNOLOGICA MATEMATICA

AREA MATEMATICO-SCIENTIFICO-TECNOLOGICA MATEMATICA AREA MATEMATICO-SCIENTIFICO-TECNOLOGICA MATEMATICA TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE AL TERMINE DELLA SCUOLA SECONDARIA DI PRIMO GRADO. L alunno ha rafforzato un atteggiamento positivo rispetto

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

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

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

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

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

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

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

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

4. Requisiti del Software

4. Requisiti del Software 4. Requisiti del Software Cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 4. Requisiti del Software 1 / 35 Sommario 1 Generalità 2 Categorizzazione

Dettagli

Piano di gestione della qualità

Piano di gestione della qualità Piano di gestione della qualità Pianificazione della qualità Politica ed obiettivi della qualità Riferimento ad un eventuale modello di qualità adottato Controllo della qualità Procedure di controllo.

Dettagli

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Fondamenti di Informatica Linguaggi di Programmazione Michele Tomaiuolo Linguaggi macchina I

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

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

Qualità del Software Qualità

Qualità del Software Qualità Qualità del Software In generale, con il termine Qualità si intende l insieme di attributi che caratterizzano un bene o un servizio, e che ne determinano la capacità di soddisfare i bisogni impliciti e

Dettagli

CONCETTI DI BASE PER LA QUALITA

CONCETTI DI BASE PER LA QUALITA CONCETTI DI BASE PER LA QUALITA Misura: è una funzione m: A -> B che associa ad ogni attributo A di un osservabile nel mondo reale o empirico (dominio) un oggetto formale B nel mondo matematico (range);

Dettagli

SIMCO E LA SIMULAZIONE

SIMCO E LA SIMULAZIONE SIMCO E LA SIMULAZIONE: Chi non vorrebbe avere la possibilità di sperimentare il differente comportamento di tutte le alternative di progetto prima di averle realizzate, per identificare la combinazione

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

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

TECNOLOGIE INFORMATICHE DELLA COMUNICAZIONE ORE SETTIMANALI 2 TIPO DI PROVA PER GIUDIZIO SOSPESO PROVA DI LABORATORIO

TECNOLOGIE INFORMATICHE DELLA COMUNICAZIONE ORE SETTIMANALI 2 TIPO DI PROVA PER GIUDIZIO SOSPESO PROVA DI LABORATORIO CLASSE DISCIPLINA MODULO Conoscenze Abilità e competenze Argomento 1 Concetti di base Argomento 2 Sistema di elaborazione Significato dei termini informazione, elaborazione, comunicazione, interfaccia,

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

Esercizi di programmazione in C

Esercizi di programmazione in C Esercizi di programmazione in C Esercizio 1 Scrivere un programma in linguaggio C che legga da tastiera una sequenza di lunghezza ignota a priori di numeri interi positivi. Il programma, a partire dal

Dettagli

Paradigma object-oriented

Paradigma object-oriented Paradigma object-oriented Dati & Comportamento Implementazione trasparente dei servizi Facile mantenimento Omogeneità nella gerarchia dati-funzioni Procedural approach OO approach Data hierarchy Replaced

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

(ETC) MATRICOLE DISPARI

(ETC) MATRICOLE DISPARI Elementi di Teoria della Computazione (ETC) MATRICOLE DISPARI Docente: Prof. Luisa Gargano BENVENUTI! Finalità: Fornire gli elementi di base delle teorie che sono di fondamento all'informatica 1. Computabilità

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

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

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

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

υ 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

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

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

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

Configuration Management

Configuration Management Configuration Management Obiettivi Obiettivo del Configuration Management è di fornire un modello logico dell infrastruttura informatica identificando, controllando, mantenendo e verificando le versioni

Dettagli

Lezione 1 Ingegneria del Software II- Introduzione e Motivazione. Ingegneria del Software 2 Introduzione e Richiami 1

Lezione 1 Ingegneria del Software II- Introduzione e Motivazione. Ingegneria del Software 2 Introduzione e Richiami 1 Lezione 1 Ingegneria del Software II- Introduzione e Motivazione Ingegneria del Software 2 Introduzione e Richiami 1 Riferimenti bibliografici I. Sommerville Ingegneria del Software 8a edizione Cap.1 R.

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

Ciclo di vita del software

Ciclo di vita del software Operatore Informatico Giuridico Informatica Giuridica A.A 2003/2004 I Semestre Ciclo di vita del software Lezione 2 prof. Monica Palmirani Hardware e Software - prima definizione Hardware: parte fisica

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

Design of Experiments

Design of Experiments Design of Experiments Luigi Amedeo Bianchi 1 Introduzione Cominciamo spiegando cosa intendiamo con esperimento, ossia l investigare un processo cambiando i dati in ingresso, osservando i cambiamenti che

Dettagli

Metodi Formali nell Ingegneria del Software (Laurea Specialistica Ing.Informatica) A.A. 2005-06 Marco Cadoli

Metodi Formali nell Ingegneria del Software (Laurea Specialistica Ing.Informatica) A.A. 2005-06 Marco Cadoli Metodi Formali nell Ingegneria del Software (Laurea Specialistica Ing.Informatica) A.A. 2005-06 Marco Cadoli Università di Roma La Sapienza Dipartimento di Informatica e Sistemistica PRIMA PARTE Il ruolo

Dettagli