SlideShare a Scribd company logo
1 of 44
Download to read offline
Software Quality Assurance & Control
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!
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)
Software Testing

Indagine 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
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
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
Software Testing – Tecniche – Test Statico

Revisione Informale
 Propedeutica ad una revisione tecnica o walkthrough
 Solitamente svolta in coppia (peer)
 Documentazione opzionale
 Obiettivo: confronto

Walkthrough
 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
Software Testing – Tecniche – Test Statico

Revisione Tecnica
 Condotta da un moderatore
 Peer Group ed esperti tecnici
 Documentata, metodi ben definiti
 Obiettivo: decisioni, rilevamento di anomalie, aderenza a standard e processi

Ispezione
 Condotta da un moderatore
 Peer examination e ruoli ben definiti
 Documentata, follow-up, checklist con I/U
 Obiettivo: rilevare anomalie
Software Testing – Tecniche – Test Statico

Analisi 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
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
Software Testing – Tecniche – Test Dinamico

 White-Box Testing
    Copertura delle istruzioni

    Copertura delle decisioni
Software Testing – Tecniche – Black-Box

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

Es: 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 2

EC1= 1 ≤ N ≤ 12 Rappresentante: 6

EC2= N < 1       Rappresentante: -3

EC3= N > 12       Rappresentante: 16
Software Testing – Tecniche – Black-Box

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



EC1= 1 ≤ N ≤ 12 --- EC3= N > 12 ● Valori limite: 12, 13
Software Testing – Tecniche – Black-Box

Tabelle 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
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
Software Testing – Tecniche – Black-Box

Tabelle 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
Software Testing – Tecniche – Black-Box

Tabelle 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
Software Testing – Tecniche – Black-Box

Diagramma 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
Software Testing – Tecniche – Black-Box

Diagrammi 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
Software Testing – Tecniche – Black-Box

Albero 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
Software Testing – Tecniche – Black-Box

Use Cases
 I Test Cases sono ricavati dagli Use Cases dell’analisi

 Test Cases business oriented

 Particolarmente utili per il test d’integrazione
Software Testing – Tecniche – White-Box

Copertura 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
Software Testing – Tecniche – White-Box

Grafo 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
Software Testing – Tecniche – White-Box

Copertura 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
Software Testing – Tecniche – Test Espolorativo

Test 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
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
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
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
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à
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
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
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)
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)
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
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
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
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
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
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
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
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
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)
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
Contatti




Via Chiomonte, 26 – 10141 – Torino   www.ixmasoft.it
0039.011.04.37.746                   info@ixmasoft.it

More Related Content

What's hot

Types of Software Testing
Types of Software TestingTypes of Software Testing
Types of Software TestingNishant Worah
 
Software testing tools and its taxonomy
Software testing tools and its taxonomySoftware testing tools and its taxonomy
Software testing tools and its taxonomyHimanshu
 
introduction to programming languages
introduction to programming languagesintroduction to programming languages
introduction to programming languagesNaqashAhmad14
 
Software Testing - Boundary Value Analysis, Equivalent Class Partition, Decis...
Software Testing - Boundary Value Analysis, Equivalent Class Partition, Decis...Software Testing - Boundary Value Analysis, Equivalent Class Partition, Decis...
Software Testing - Boundary Value Analysis, Equivalent Class Partition, Decis...priyasoundar
 
Quality management in software engineering
Quality management in software engineeringQuality management in software engineering
Quality management in software engineeringZain ul Abideen
 
Migration from Procedural to OOP
Migration from Procedural to OOP Migration from Procedural to OOP
Migration from Procedural to OOP GLC Networks
 
Dynamic Testing
Dynamic TestingDynamic Testing
Dynamic TestingJimi Patel
 
Component based development | what, why and how
Component based development | what, why and howComponent based development | what, why and how
Component based development | what, why and howRakesh Kumar Jha
 
Software review
Software reviewSoftware review
Software reviewamjad_09
 
Unit I Software Testing and Quality Assurance
Unit I Software Testing and Quality AssuranceUnit I Software Testing and Quality Assurance
Unit I Software Testing and Quality AssuranceVinothkumaR Ramu
 
Component Based Software Engineering
Component Based Software EngineeringComponent Based Software Engineering
Component Based Software EngineeringSatishDabhi1
 
Application Quality Gates in Continuous Delivery: Deliver Better Software Fas...
Application Quality Gates in Continuous Delivery: Deliver Better Software Fas...Application Quality Gates in Continuous Delivery: Deliver Better Software Fas...
Application Quality Gates in Continuous Delivery: Deliver Better Software Fas...Andreas Grabner
 
Generations Of Programming Languages
Generations Of Programming LanguagesGenerations Of Programming Languages
Generations Of Programming Languagessebrown
 
PyCon 2013 : Scripting to PyPi to GitHub and More
PyCon 2013 : Scripting to PyPi to GitHub and MorePyCon 2013 : Scripting to PyPi to GitHub and More
PyCon 2013 : Scripting to PyPi to GitHub and MoreMatt Harrison
 

What's hot (20)

Types of Software Testing
Types of Software TestingTypes of Software Testing
Types of Software Testing
 
5 chap - MAINTENANCE
5 chap - MAINTENANCE5 chap - MAINTENANCE
5 chap - MAINTENANCE
 
Software testing tools and its taxonomy
Software testing tools and its taxonomySoftware testing tools and its taxonomy
Software testing tools and its taxonomy
 
introduction to programming languages
introduction to programming languagesintroduction to programming languages
introduction to programming languages
 
V shape process model
V shape process modelV shape process model
V shape process model
 
Software Testing - Boundary Value Analysis, Equivalent Class Partition, Decis...
Software Testing - Boundary Value Analysis, Equivalent Class Partition, Decis...Software Testing - Boundary Value Analysis, Equivalent Class Partition, Decis...
Software Testing - Boundary Value Analysis, Equivalent Class Partition, Decis...
 
Incremental model
Incremental modelIncremental model
Incremental model
 
Quality management in software engineering
Quality management in software engineeringQuality management in software engineering
Quality management in software engineering
 
Migration from Procedural to OOP
Migration from Procedural to OOP Migration from Procedural to OOP
Migration from Procedural to OOP
 
Uml introduciton
Uml introducitonUml introduciton
Uml introduciton
 
Dynamic Testing
Dynamic TestingDynamic Testing
Dynamic Testing
 
Component based development | what, why and how
Component based development | what, why and howComponent based development | what, why and how
Component based development | what, why and how
 
Software review
Software reviewSoftware review
Software review
 
Unit I Software Testing and Quality Assurance
Unit I Software Testing and Quality AssuranceUnit I Software Testing and Quality Assurance
Unit I Software Testing and Quality Assurance
 
Component Based Software Engineering
Component Based Software EngineeringComponent Based Software Engineering
Component Based Software Engineering
 
Application Quality Gates in Continuous Delivery: Deliver Better Software Fas...
Application Quality Gates in Continuous Delivery: Deliver Better Software Fas...Application Quality Gates in Continuous Delivery: Deliver Better Software Fas...
Application Quality Gates in Continuous Delivery: Deliver Better Software Fas...
 
Dynamic binding
Dynamic bindingDynamic binding
Dynamic binding
 
Generations Of Programming Languages
Generations Of Programming LanguagesGenerations Of Programming Languages
Generations Of Programming Languages
 
PyCon 2013 : Scripting to PyPi to GitHub and More
PyCon 2013 : Scripting to PyPi to GitHub and MorePyCon 2013 : Scripting to PyPi to GitHub and More
PyCon 2013 : Scripting to PyPi to GitHub and More
 
Bapi programming
Bapi programmingBapi programming
Bapi programming
 

Viewers also liked

Test Funzionale
Test FunzionaleTest Funzionale
Test FunzionaleIxmaSoft
 
Template Piano Di Qualita
Template Piano Di QualitaTemplate Piano Di Qualita
Template Piano Di QualitaRoberto Polillo
 
Webinar: “Testing automatico: la scelta vincente per ottenere una riduzione d...
Webinar: “Testing automatico: la scelta vincente per ottenere una riduzione d...Webinar: “Testing automatico: la scelta vincente per ottenere una riduzione d...
Webinar: “Testing automatico: la scelta vincente per ottenere una riduzione d...Emerasoft, solutions to collaborate
 
Test e scrum un caso reale v3.2
Test e scrum   un caso reale v3.2Test e scrum   un caso reale v3.2
Test e scrum un caso reale v3.2Ivan Fioravanti
 
TMap: una metodologia di test business driven
TMap: una metodologia di test business drivenTMap: una metodologia di test business driven
TMap: una metodologia di test business drivenCodemotion
 
Figure libro "Plasmare il Web"
Figure libro "Plasmare il Web"Figure libro "Plasmare il Web"
Figure libro "Plasmare il Web"Roberto Polillo
 
Consuming RabbitMQ at TTL
Consuming RabbitMQ at TTLConsuming RabbitMQ at TTL
Consuming RabbitMQ at TTLjeanml
 
Template Documento dei requisiti
Template Documento dei requisitiTemplate Documento dei requisiti
Template Documento dei requisitiRoberto Polillo
 
Software Testing & Test Driven Development
Software Testing & Test Driven DevelopmentSoftware Testing & Test Driven Development
Software Testing & Test Driven DevelopmentSergio Santoro
 
Hacking Sales - Sales 2.0 e Inbound Sales
Hacking Sales - Sales 2.0 e Inbound SalesHacking Sales - Sales 2.0 e Inbound Sales
Hacking Sales - Sales 2.0 e Inbound SalesAdv Media Lab
 
Teaching HCI to computing students: some considerations
Teaching HCI to computing students: some considerationsTeaching HCI to computing students: some considerations
Teaching HCI to computing students: some considerationsRoberto Polillo
 
functional testing
functional testing functional testing
functional testing bharathanche
 
Il Testing di applicazioni e servizi nell'era delle Apps e del Cloud
Il Testing di applicazioni e servizi nell'era delle Apps e del CloudIl Testing di applicazioni e servizi nell'era delle Apps e del Cloud
Il Testing di applicazioni e servizi nell'era delle Apps e del CloudMicrofocusitalia
 

Viewers also liked (16)

Test Funzionale
Test FunzionaleTest Funzionale
Test Funzionale
 
Template Piano Di Qualita
Template Piano Di QualitaTemplate Piano Di Qualita
Template Piano Di Qualita
 
Webinar: “Testing automatico: la scelta vincente per ottenere una riduzione d...
Webinar: “Testing automatico: la scelta vincente per ottenere una riduzione d...Webinar: “Testing automatico: la scelta vincente per ottenere una riduzione d...
Webinar: “Testing automatico: la scelta vincente per ottenere una riduzione d...
 
Test e scrum un caso reale v3.2
Test e scrum   un caso reale v3.2Test e scrum   un caso reale v3.2
Test e scrum un caso reale v3.2
 
TMap: una metodologia di test business driven
TMap: una metodologia di test business drivenTMap: una metodologia di test business driven
TMap: una metodologia di test business driven
 
Figure libro "Plasmare il Web"
Figure libro "Plasmare il Web"Figure libro "Plasmare il Web"
Figure libro "Plasmare il Web"
 
Consuming RabbitMQ at TTL
Consuming RabbitMQ at TTLConsuming RabbitMQ at TTL
Consuming RabbitMQ at TTL
 
Template Documento dei requisiti
Template Documento dei requisitiTemplate Documento dei requisiti
Template Documento dei requisiti
 
Software Testing & Test Driven Development
Software Testing & Test Driven DevelopmentSoftware Testing & Test Driven Development
Software Testing & Test Driven Development
 
Unit Testing
Unit TestingUnit Testing
Unit Testing
 
Hacking Sales - Sales 2.0 e Inbound Sales
Hacking Sales - Sales 2.0 e Inbound SalesHacking Sales - Sales 2.0 e Inbound Sales
Hacking Sales - Sales 2.0 e Inbound Sales
 
Teaching HCI to computing students: some considerations
Teaching HCI to computing students: some considerationsTeaching HCI to computing students: some considerations
Teaching HCI to computing students: some considerations
 
functional testing
functional testing functional testing
functional testing
 
Black & White Box testing
Black & White Box testingBlack & White Box testing
Black & White Box testing
 
Il Testing di applicazioni e servizi nell'era delle Apps e del Cloud
Il Testing di applicazioni e servizi nell'era delle Apps e del CloudIl Testing di applicazioni e servizi nell'era delle Apps e del Cloud
Il Testing di applicazioni e servizi nell'era delle Apps e del Cloud
 
Black Box Testing
Black Box TestingBlack Box Testing
Black Box Testing
 

Software testing

  • 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. 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. Software Testing Indagine 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. 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. 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. Software Testing – Tecniche – Test Statico Revisione Informale  Propedeutica ad una revisione tecnica o walkthrough  Solitamente svolta in coppia (peer)  Documentazione opzionale  Obiettivo: confronto Walkthrough  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. Software Testing – Tecniche – Test Statico Revisione Tecnica  Condotta da un moderatore  Peer Group ed esperti tecnici  Documentata, metodi ben definiti  Obiettivo: decisioni, rilevamento di anomalie, aderenza a standard e processi Ispezione  Condotta da un moderatore  Peer examination e ruoli ben definiti  Documentata, follow-up, checklist con I/U  Obiettivo: rilevare anomalie
  • 9. Software Testing – Tecniche – Test Statico Analisi 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. 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. Software Testing – Tecniche – Test Dinamico  White-Box Testing  Copertura delle istruzioni  Copertura delle decisioni
  • 12. Software Testing – Tecniche – Black-Box Partizionamento 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 input Es: 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 2 EC1= 1 ≤ N ≤ 12 Rappresentante: 6 EC2= N < 1 Rappresentante: -3 EC3= N > 12 Rappresentante: 16
  • 13. Software Testing – Tecniche – Black-Box Analisi 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 partizione EC1= 1 ≤ N ≤ 12 --- EC3= N > 12 ● Valori limite: 12, 13
  • 14. Software Testing – Tecniche – Black-Box Tabelle 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. 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. Software Testing – Tecniche – Black-Box Tabelle 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. Software Testing – Tecniche – Black-Box Tabelle 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. Software Testing – Tecniche – Black-Box Diagramma 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. Software Testing – Tecniche – Black-Box Diagrammi 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. Software Testing – Tecniche – Black-Box Albero 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. Software Testing – Tecniche – Black-Box Use Cases  I Test Cases sono ricavati dagli Use Cases dell’analisi  Test Cases business oriented  Particolarmente utili per il test d’integrazione
  • 22. Software Testing – Tecniche – White-Box Copertura 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. Software Testing – Tecniche – White-Box Grafo 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. Software Testing – Tecniche – White-Box Copertura 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. Software Testing – Tecniche – Test Espolorativo Test 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Contatti Via Chiomonte, 26 – 10141 – Torino www.ixmasoft.it 0039.011.04.37.746 info@ixmasoft.it