Testing: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica
Correzioni con wikEd
Riga 3:
{{Risorsa|tipo = lezione|materia1 =Ingegneria del software|materia2=Metodi di verifica e testing |avanzamento = }}
 
= Definizione =
 
Il Testing è un metodo di [[verifica]] nel quale si accerta la correttezza di un sistema esercitandolo e comparandone il funzionamento rispetto alle attese.
 
== Attività sottese al Testing ==
 
;Test Case Selection: scelta dei Test Cases
; Test Case Selection: scelta dei Test Cases
; Sensitization: identificare gli input che portano ai Test Cases scelti
; Execution: creare stub, driver, log
; Oracle Verdict: il sistema verifica le attese?
; Debugging: tracciare ciascuna Failure su una o più Faults
; Coverage Analysis: Stimare il grado di copertura raggiunto rispetto alla complessità reale del sistema - ''Ci da un indicatore di confidenza sulla assenza di errori residui''
 
Occorre innanzi tutto domandarsi a quale livello di astrazione del sistema possiamo lavorare
*Codice Sorgente
*Codice Compilato
*Diagramma UML
 
* Codice Sorgente
* Codice Compilato
* Diagramma UML
 
Sono possibili inoltre diverse astrazioni rispetto ad altrettante prospettive che intendiamo investigare
;Funzionale: il sistema è visto come una ''BlackBox'' investigabile solo in termini di relazioni tra l'input immesso e l'output restituito. Viene testato facendo riferimento alla specifica dei requisiti.
;Strutturale: il sistema è visto come una ''WhiteBox'', ovvero si ha accesso, invece che alle relazioni di Ingresso/Uscita, al codice sorgente.
;Architetturale: il sistema è visto come una ''GreyBox'', ovvero si ha accesso all'aspetto Funzionale e alle principali relazioni funzionali interne.
 
; Funzionale: il sistema è visto come una ''BlackBox'' investigabile solo in termini di relazioni tra l'input immesso e l'output restituito. Viene testato facendo riferimento alla specifica dei requisiti.
; Strutturale: il sistema è visto come una ''WhiteBox'', ovvero si ha accesso, invece che alle relazioni di Ingresso/Uscita, al codice sorgente.
; Architetturale: il sistema è visto come una ''GreyBox'', ovvero si ha accesso all'aspetto Funzionale e alle principali relazioni funzionali interne.
 
Solitamente il miglior approccio da adottare prevede:
 
* Prospettiva ''Funzionale'' nel TCS
* Prospettiva ''Strutturale'' nella CA
 
==== Approccio al Testing ====
 
{| border=1
! Approccio !!Control Flow !! Data Flow !! Finite States !! OO testing
|-
! Funzionale || NO || NO || OK || OK
|-
! Strutturale || OK || OK || NO || OK
|}
===Test Case Selection===
 
;=== Test Case Selection: scelta dei Test Cases===
 
=== Sensitization ===
 
=== Execution ===
 
=== Oracle Verdict ===
 
=== Debugging ===
 
=== Coverage Analysis ===
 
Una volta definito il livello di astrazione desiderato, utiliziamo un opportuno '''Criterio di Copertura'''
 
* All Nodes
* All Edges
* All Conditions
* Condition Decision
* Multiple Conditions
* Modified Condition-Decision
 
==== All Nodes ====
 
Con questo criterio si intende visitare tutti i nodi del Control Flow Graph
 
Pro:
 
* Complessità: <math>O(N)</math>
 
Contro:
 
* Non garantisce la copertura di tutte le scelte
 
==== All Edges ====
 
Con questo criterio oltre a verificare tutti i nodi del control flow graph si controllano anche tutti gli archi.
La complessità è O(N*C) dove N è il numero di nodi e E è il massimo grado di uscita.
 
==== All Conditions ====
 
==== Condition Decision ====
 
==== Multiple Conditions ====
 
==== Modified Condition-Decision ====
 
== Riferimenti ==
 
* [[Data Flow Testing]]
==Riferimenti==
* [[DataFinite FlowState Testing]]
* [[Finite State Speciale:Whatlinkshere/Testing|Pagine collegate]]
*[[Speciale:Whatlinkshere/Testing | Pagine collegate]]