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
|}
=== 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==
* [[
* [[
|