Software testing

1,962 views
1,806 views

Published on

1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total views
1,962
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
51
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Software testing

  1. 1. Software Quality Assurance & Control
  2. 2. Software Quality Assurance & Control SQA - Insieme di procedure per assicurare che i processi, metodologie e standard siano appropriate e correttamente implementate per lo sviluppo di un prodotto sw  Orientato al Processo SQC - Insieme di procedure per assicurare che un prodotto sw raggiunga i propri obiettivi di qualità  Orientato al Prodotto Software Testing - Principale attività di SQC Il Testing non assicura la qualità…la controlla!
  3. 3. Software Quality Assurance & Control SQA  Modello di sviluppo (es: Waterfall) • Raccolta dei requisiti completata  Analisi Funzionale  Sviluppo  Standard • ISO 9001 SQC  Requisiti Funzionali  Requisiti NON-Funzionali  Verifica - Corretto funzionamento (Requisiti di Sistema)  Validazione - Corretta implementazione (Requisiti Utente)
  4. 4. Software TestingIndagine condotta per fornire le informazioni relative alla qualità del sistema sotto esame. Misura della qualità in termini di numero di difetti rilevati Rilevando difetti si aumenta la qualità del sistema in seguito alla loro correzione L’obiettivo del Testing è rilevare il maggior numero di difetti
  5. 5. Software Testing Il Testing prova la presenza di difetti, non l’assenza  Anche se nessun difetto viene trovato questa non è una prova di correttezza Il Testing esaustivo non è possibile  Effort troppo elevato per provare tutti i possibili input Anticipare il Testing il prima possibile  Per abbassare i costi di risoluzione e l’effort di Test successivo Il Testing dipende dai contesti  Sistemi safe-critical vs E-Commerce Il Testing non è Debugging  Fallimento vs Causa
  6. 6. Software Testing – Tecniche – Test Statico Test Statico Basato sulla revisione (esame manuale) della documentazione e sull’analisi statica (esame automatico) del codice  Un difetto nell’analisi inevitabilmente si ritrova nel software  Mancanze nei requisiti  Si approfondisce la conoscenza del business anticipando il test design  L’obiettivo è trovare anomalie e non fallimenti Revisione (review)  Revisione Informale  Walkthrough  Revisione Tecnica  Ispezione
  7. 7. Software Testing – Tecniche – Test StaticoRevisione Informale Propedeutica ad una revisione tecnica o walkthrough Solitamente svolta in coppia (peer) Documentazione opzionale Obiettivo: confrontoWalkthrough Condotta dall’autore Peer Group Solitamente documentata se svolta in sessioni E’ necessaria preparazione dei partecipanti (revisione informale) Obiettivo: acquisizione di informazione e rilevamento anomalie
  8. 8. Software Testing – Tecniche – Test StaticoRevisione Tecnica Condotta da un moderatore Peer Group ed esperti tecnici Documentata, metodi ben definiti Obiettivo: decisioni, rilevamento di anomalie, aderenza a standard e processiIspezione Condotta da un moderatore Peer examination e ruoli ben definiti Documentata, follow-up, checklist con I/U Obiettivo: rilevare anomalie
  9. 9. Software Testing – Tecniche – Test StaticoAnalisi Statica Utilizzo di strumenti (compilatori, control & data flow check) Uso di metriche  rilevazione di elevata misura di complessità Rilevazione di codice morto, cicli infiniti, dipendenze e inconsistenze Identificazione di anomalie non facilmente rilevabili con il test dinamico
  10. 10. Software Testing – Tecniche – Test Dinamico Test Dinamico Basato sull’esecuzione del codice Vengono rilevati i fallimenti, e cioè esiti negativi (effetti di un anomalia) Test Funzionale e Non-Funzionale Black-Box Testing  Partizionamento in classi di equivalenza  Analisi ai valori limite  Tabelle delle decisioni  Diagrammi di transizioni tra stati  Use Cases
  11. 11. Software Testing – Tecniche – Test Dinamico White-Box Testing  Copertura delle istruzioni  Copertura delle decisioni
  12. 12. Software Testing – Tecniche – Black-BoxPartizionamento in classi di equivalenza Viene partizionato il dominio di input: classi valide e non valide Un Test Case per ogni classe Si associano due classi (valida-non valida) per ogni condizione di inputEs: Funzione il cui dominio di input siano i mesi dell’anno ... -2 -1 0 1 .............. 12 13 14 15 ..... -------------|-------------------|--------------------- Partizione NON Valida 1 Partizione Valida Partizione NON Valida 2EC1= 1 ≤ N ≤ 12 Rappresentante: 6EC2= N < 1 Rappresentante: -3EC3= N > 12 Rappresentante: 16
  13. 13. Software Testing – Tecniche – Black-BoxAnalisi ai valori limite Complementare al metodo precedente Tiene in considerazione il comportamento ai margini delle classi di equivalenza  Solitamente vengono trovati più difetti utilizzando i valori limite (massimo e minimo) di una partizioneEC1= 1 ≤ N ≤ 12 --- EC3= N > 12 ● Valori limite: 12, 13
  14. 14. Software Testing – Tecniche – Black-BoxTabelle delle decisioni Condizioni 1 2 3 4 5 6 7 8 Conto attivo Y Y Y Y N N N N Conto coperto Y Y N N Y Y N N Prelievi disponibili Y N Y N Y N Y N Azioni Consentire il Prelievo Y N N N N N N N Trattenere Carta N N Y Y Y Y Y Y Inviare Comunicazione N N Y Y N N N N
  15. 15. Software Testing – Tecniche – Black-Box Ogni colonna della tabella rappresenta un Caso di Test (2n, n= # condizioni) Alcuni Casi di Test sono privi di senso:  Conto non attivo & Conto coperto  Conto non attivo & Conto non coperto & Prelievi disponibili Se il valore di particolari condizioni non incide sulle azioni, relative colonne possono essere rimosse  Solitamente sono colonne vicine  Le azioni sono le stesse  Si tiene una colonna come rappresentante e si sostituisce il valore delle condizioni diverse con ‘ – ‘ per indicare che il loro valore è ininfluente Si continua a rimuovere colonne finchè non ci sono colonne con le stesse azioni o se la rimozione di una colonna comporta l’eliminazione di una distinzione importante
  16. 16. Software Testing – Tecniche – Black-BoxTabelle delle decisioni Condizioni 1 2 3 4 5 6 7 8 Conto attivo Y Y Y Y N N N N Conto coperto Y Y N N Y Y N N Prelievi disponibili Y N Y N Y N Y N Azioni Consentire il Prelievo Y N N N N N N N Trattenere Carta N N Y Y Y Y Y Y Inviare Comunicazione N N Y Y N N N N
  17. 17. Software Testing – Tecniche – Black-BoxTabelle delle decisioni Condizioni 1 2 3 5 Conto attivo Y Y Y N Conto coperto Y Y N - Prelievi disponibili Y N Y - Azioni Consentire il Prelievo Y N N N Trattenere Carta N N Y Y Disattiva Conto N N Y N
  18. 18. Software Testing – Tecniche – Black-BoxDiagramma degli stati B Prelievo [Prelievi disponibili > 0 & Saldo Conto > -500 €] 1 A 2 3 Deposito Conto Prelievo Conto Conto Attivo Coperto Saldo ≤ -500 € Scoperto C D Deposito Prelievo TC1= 1 – A – 2 – C – 3 – D – 4 E TC2= 1 – A – 2 – B – 2 – B – 2 4 Conto NON Attivo
  19. 19. Software Testing – Tecniche – Black-BoxDiagrammi delle transizioni tra stati Gli output non sono influenzati solo dagli input ma da eventi Stato iniziale  Stati intermedi  Stato finale Eventi occorsi nel tempo (storia) influenza il comportamento dell’oggetto di test Object-oriented Diagramma degli stati, macchina a stati finiti, tabelle di transizioni degli stati
  20. 20. Software Testing – Tecniche – Black-BoxAlbero delle Transizioni 1 TC1= 1 – A – 2 – C – 3 – D – 4 A TC2= 1 – A – 2 – B – 2 – B – 2 2 B C 2 3 B D 2 4
  21. 21. Software Testing – Tecniche – Black-BoxUse Cases I Test Cases sono ricavati dagli Use Cases dell’analisi Test Cases business oriented Particolarmente utili per il test d’integrazione
  22. 22. Software Testing – Tecniche – White-BoxCopertura delle istruzioni Si valuta la % di istruzioni eseguite da una famiglia di test (Test Suite) L’obiettivo è aumentare la copertura delle istruzioni  # istruzioni eseguibili attivate dai Casi di Test (Test Cases) / # totale di istruzioni eseguibili Particolarmente utili per il test d’integrazione Si traduce il codice sorgente in un grafo del flusso di controllo  Nodi = Istruzioni non divisibili  Archi = flusso di controllo
  23. 23. Software Testing – Tecniche – White-BoxGrafo del Flusso di Controllo A B TC= A – B – F – G – H – D – E IF F IF DO C L G I WHILE H END IF END IF D E
  24. 24. Software Testing – Tecniche – White-BoxCopertura delle decisioni (branch coverage) Si valuta la % di decisioni eseguite da una famiglia di test (Test Suite) L’obiettivo è aumentare la copertura delle decisioni  # decisioni eseguibili attivate dai Casi di Test (Test Cases) / # totale di decisioni eseguibili E’ una forma di testing del flusso di controllo, ma ogni decisione deve essere eseguita con entrambi i possibili risultati (Vero/Falso) La copertura del 100% delle decisioni  La copertura del 100% delle istruzioni  Ma non il contrario
  25. 25. Software Testing – Tecniche – Test EspolorativoTest Espolorativo (Exploratory Testing) Basato sull’esperienza/intuizione dei testers  Partecipazione cognitiva Usato in unione alle altre tecniche per rafforzarle  Error guessing Utile quando la documentazione è povera e le tempistiche ristrette
  26. 26. Software Testing – Tipologie – Test Funzionale Test Funzionale Si verifica il comportamento del sistema in termini di funzionalità:  Idoneità  Correttezza  Interoperabilità Verifica il software testandolo rispetto a :  Specifica dei requisiti  Specifica Funzionale  Use-Cases
  27. 27. Software Testing – Tipologie – Test Funzionale I Test Cases vengono disegnati applicando tecniche di tipo Black-Box:  Equivalent class partitioning  Boundary Value Analysis  Error Guessing Può essere applicato a tutti i livelli di test:  Test di Modulo • Test Funzionale basato sui requisiti (Requirements-based testing)  Test d’Integrazione • Test Funzionale basato sui processi business
  28. 28. Software Testing – Tipologie – Test NON Funzionale Test NON Funzionale Si verificano attributi non funzionali, quali:  Affidabilità  Efficienza  Usabilità  Manutenibilità  Portabilità  Compatibilità Per verificare le caratteristiche non funzionali di un sistema software è utile riutilizzare i Test Cases disegnati per il test funzionale  Business Process Scenarios – I test funzionali servono per veicolare la determinazione delle caratteristiche non funzionali
  29. 29. Software Testing – Tipologie – Test NON Funzionale Performance, Load, Stress Test – Efficienza Endurance Test – Affidabilità Esecuzione di task predefiniti da parte di un focus group – Usabilità  Thinking –aloud  Interviste,  Questionari Test della documentazione tecnica e della struttura del software – Manutenibilità Test di compatibilità per SO, browser, piattaforme differenti – Compatibilità
  30. 30. Software Testing – Livelli I livelli del Test I livelli di test vengono identificati a seconda della fase del processo di sviluppo software (e indipendentemente dal modello seguito):  Test di Modulo  Test di Integrazione  Test di Sistema  Test Confermativo  Test di Regressione  Test di Accettazione
  31. 31. Software Testing – Livelli Test di Modulo Verifica del corretto funzionamento di componenti testabili separatamente Possono essere applicate sia tecniche White che Black-Box  Unit Testing  Test di copertura (istruzioni/decisioni)  Test Funzionale di Modulo  Test non funzionali di performance (memory leaks, stored procedure execution time) Approccio automatico  Test Driven Development Test il più esaustivo possibile
  32. 32. Software Testing – Livelli Test di Integrazione Verifica della corretta interazione tra moduli E’ prioritaria l’interazione rispetto alle funzionalità implementate dai singoli moduli Due approcci principali:  Top-down – Vengono integrati per primi i moduli ad alto livello  Bottom-up – Vengono testati per primi i moduli di utilità  Umbrella – Test eseguiti secondo i percorsi funzionali dei dati e del flusso di controllo (business process oriented)
  33. 33. Software Testing – Livelli Test di Sistema Verifica il corretto funzionamento dell’intero sistema software L’ambiente di test deve corrispondere il più possibile a quello finale Test Cases Business Process Oriented A differenza degli altri livelli di test è fondamentale l’utilizzo di un team di test indipendente Unitamente al Test Confermativo e di Regressione, l’output deve essere la versione che sarà sottoposta a Test di Accettazione (candidate release)
  34. 34. Software Testing – Livelli Test Confermativo Per ogni livello di test un certo numero di difetti viene rilevato, e questi devono essere risolti dal team di sviluppo Il Test Confermativo ha come obiettivo il test puntuale delle risoluzioni  Il bug fixing viene validato  Molto utili, in fasi avanzate del processo di sviluppo, strumenti che consentono un fast-forwarding E’ molto importante tenere traccia della versione del software nella quale le correzioni sono state validate  In caso di regressioni future è più semplice risalire alla causa
  35. 35. Software Testing – Livelli Test di Regressione E’ inevitabile che introducendo nuove funzionalità o apportando correzioni (nuovi sviluppi) vengano introdotte regressioni su funzionalità positivamente testate in precedenza L’obiettivo è verificare che il software non sia regredito a fronte di nuovi sviluppi Vengono tipicamente esercitati Test Cases Business Process Oriented Dovrebbe essere automatizzato
  36. 36. Software Testing – Livelli Test di Accettazione L’obiettivo è valutare il grado di maturità del sistema per approvarne il rilascio ed utilizzo Solitamente sotto la responsabilità del Cliente, Stakeholder, Key-User L’obiettivo non deve essere la ricerca di difetti, ma valutare se il sitema risponde ai requisiti espressi e se lo fa nel modo corretto/aspettato
  37. 37. Processo di Test Il Processo di Test viene portato avanti in cinque fasi:  Pianificazione  Progettazione/Design  Implementazione  Esecuzione  Gestione delle Anomalie Ogni fase deve essere ben documentata  Garantire la manutenibilità dei test  Consentire la massima sinergia tra i gruppi di lavoro
  38. 38. Processo di Test - Pianificazione Pianificazione Produce il Master (o Project) Test Plan Document  Definizione del sistema oggetto di test  Test Scope  Obiettivi del Test  Ruoli e Responsabilità  Assunzioni, vincoli e rischi  Glossario cn tutti i termini tecnici (SQC related) utilizzati  Strategia, metodologia e tecniche di test utilizzate  Strumenti di supporto utilizzati  Ambienti di Test
  39. 39. Processo di Test - Pianificazione Configurazioni hardware e software Criteri di Ingresso/Uscita del Piano di Test La pianificazione in termini di date di inizio-fine e le risorse umane necessarie
  40. 40. Processo di Test - Progettazione Progettazione Creazione delle Famiglie di Test (Test Suites)  Collezione di Casi di Test (Test Cases)  Identificazione di tutti i requisiti e delle “storie” dell’utente (use cases)  Organizzazione gerarchica per area funzionale o cross-section Creazione dei Casi di Test (Test Cases)  Costituiscono le specifiche di test  Per ogni use case deve esistere almeno un test case (m ↔ n)  Identificazione dei prerequisiti, dati necessari (setup), input, passi, risultato aspettato  Definizione dei criteri di ingresso/uscita
  41. 41. Processo di Test - Implementazione Implementazione Si realizza ciò che è stato disegnato/progettato L’output è costituito da una collezione di:  Test Suites • Test Cases per l’esecuzione manuale • Test Scripts per l’esecuzione automatica  Data sets  Configurazioni (scripts e/o documenti) - Riutilizzo  Launch Test Document • Setup e dati necessari • Ordine di esecuzione
  42. 42. Processo di Test - Esecuzione Esecuzione Le Test Suites e i Test Scripts preparati vengono eseguiti  Manualmente  In modo automatico con l’ausilio degli strumenti di supporto Per ogni Test Case (manuale/automatico) viene preparato il rapporto di esecuzione (Execution Report)  Stato di esecuzione (Passato, Fallito, Non Eseguito)  Data di esecuzione e Versione del software oggetto di test  Nome del Test Engineer che lo ha eseguito Viene preparato il Rapporto dei Test (Test Report) Viene preparato il Rapporto delle Anomalie (Anomalies Report)
  43. 43. Processo di Test – Gestione delle Anomalie Gestione delle Anomalie Procedura fondamentale per avere un’analisi affidabile e veloce dei difetti rilevati durante l’esecuzione del test Standard per il reporting dei difetti  Informazioni per una rapida ricerca e comprensione  Informazioni per la corretta riproducibilità Classificazione dei difetti  Priorità  Severità Ciclo di vita dei difetti  Stati dei difetti
  44. 44. ContattiVia Chiomonte, 26 – 10141 – Torino www.ixmasoft.it0039.011.04.37.746 info@ixmasoft.it

×