...

Una metodologia per il controllo della qualità di software sviluppato

by user

on
Category: Documents
9

views

Report

Comments

Transcript

Una metodologia per il controllo della qualità di software sviluppato
UNIVERSITA’ DEGLI STUDI DI MILANO BICOCCA
FACOLTA’ DI SCIENZE MATEMATICHE, FISICHE E NATURALI
Corso di Laurea Magistrale in Informatica
Automazione di Test di Sistemi Embedded
Relatore: Prof. Mauro PEZZE’
Correlatori: Lorena SIMONI
Giuseppe GORGOGLIONE
Relazione della prova finale di:
Carmine Carella
Matricola: 055465
Anno Accademico 2009/2010
1
Indice
 Il Software nei sistemi embedded
 Testing nei sistemi embedded
 Automazione del Testing
 Il Progetto Cartesio
 Contributo
della Tesi
 Attività di testing
 Conclusioni
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Il SW nei Sistemi Embedded
Incidenza percentuale dei sistemi embedded nel costo
finale dei prodotti (1)
AUTOMAZIONE
AMBIENTE
SPERIMENTALE
Mercato globale dei sistemi embedded in
miliardi di dollari (1)
CONTRIBUTO
TESI
ATTIVITA’
TESTING
CONCLUSIONI
Fatturato del software embedded per
categoria(1)
Utilizzo recente dei sistemi operativi per
sistemi embedded (1)
(AAGR - Average Annual Growth Rate)
(1) Brandolese, C. and Fornaciari, W., Sistemi Embedded - sviluppo hardware e software per sistemi dedicati, 2007, Mondadori
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Testing nei Sistemi Embedded
AUTOMAZIONE
Tipologie di
Testing
Software
Processore
Sistema
Ambiente
One way
Simulato
-
-
-
Feedback
Simulato
-
-
-
Rapid prototyping
Sperimentale
Sperimentale
Sperimentale
Reale
Host
Simulato
Simulato
Reale (finale)
Emulatore
Simulato
Simulato
-
Reale (finale)
Reale (finale)
Reale (finale)
Reale(finale)
Reale (finale)
Sperimentale
Simulato
Reale(finale)
Reale (finale)
Prototipo
Simulato
Test ambientale
Reale(finale)
Reale (finale)
Prototipo maturo
Simulato
Pre-produzione
Test di sistema
Reale(finale)
Reale (finale)
Reale
Reale
Post-produzione
Test mantenimento
Reale(finale)
Reale (finale)
Reale (finale)
Reale (finale)
Fasi
Simulazione
AMBIENTE
SPERIMENTALE
Test unità/integrazione Sperimentale/reale
sw (1)
(host)
Test unità/integrazione
sw (2)
CONTRIBUTO
TESI
Prototipazione Test unità/integrazione
hw
ATTIVITA’
TESTING
Test integrazione
hw/sw
Test di sistema
CONCLUSIONI
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Gli ambienti di Testing
AUTOMAZIONE
Ambiente Target
Ambiente Host
Ambiente di
sviluppo
AMBIENTE
SPERIMENTALE
Host-testing
CONTRIBUTO
TESI
ATTIVITA’
TESTING
Approccio simulativo
tramite emulazione
di piattaforma
Crosscompilazione
Ambiente di
esecuzione
Target-testing

Test integrazione hw/sw
 Test di sistema
CONCLUSIONI
Verifica delle
caratteristiche non
funzionali del SW

SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Automazione del testing
 Importanza: migliora efficacia ed efficienza del
AUTOMAZIONE
testing
 Problema:
AMBIENTE
SPERIMENTALE

Soluzioni ad-hoc (application-specific)
 Metodologie interne aziendali

CONTRIBUTO
TESI
Letteratura scarsa e approcci poco concreti
 Soluzione proposta:
ATTIVITA’
TESTING
 personalizzazione di strumenti
CONCLUSIONI
off-the-shelf per
adattarli all’architettura specifica in modo
garantire il corretto funzionamento dello
strumento di automazione
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Il Progetto Cartesio
Board ST
AUTOMAZIONE
SERIAL
PORT
GPIO
CLCD
USB
SDCARD
TOUCHPANEL
GPS
AUDIO
KEYBOARD
NAND
AMBIENTE
SPERIMENTALE
Graphic
PND Customer
POWER
MANAGEMENT
ETHERNET
• GUI e applicazioni
proprietarie
• BSP customizzato
BSP linux Cartesio
CONTRIBUTO
TESI
Sviluppo e testing sw in STM
Sviluppo BSP LINUX
CARTESIO
ATTIVITA’
TESTING
Command line interface
Kernel + (BSP) device
driver
CONCLUSIONI
Bootloader
Firmware
PROCESSO TESTING
• Test object: device
driver
• manual and automatic
test suite
• Test funzionali e
strutturali
• Test report: excel
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Contributo della Tesi

Analisi fattibilità e costi della soluzione adottata:
AUTOMAZIONE

Valutazione caratteristiche non funzionali del sw
nell’ambiente target attraverso 4 attivita’ di testing
rilevanti nel processo di testing del BSP Linux Cartesio
AMBIENTE
SPERIMENTALE
CONTRIBUTO
TESI
ATTIVITA’
TESTING
CONCLUSIONI
Attività di Testing
Classe problemi
analizzati
Requisiti di Qualità
prestazioni codice in
fase di boot
punti critici del software
con maggiore tempo di esecuzione
nella fase di boot
prestazioni
uso e gestione della
memoria
memory leak
prestazioni,
affidabilità
prestazioni di I/O su
dispositivi di mass
storage
scarsa efficienza delle operazioni
di I/O (lettura, scrittura)
prestazioni
test di copertura
problemi nell’efficacia dei test
funzionali e strutturali dell’ambiente
sperimentale
copertura
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Valutazione delle Prestazioni del
Codice nella Fase di Boot (1)
AUTOMAZIONE
Obiettivi e Scelta Strumento:
 Profiling: strategia per valutare le prestazioni del codice
 Function Tracing - tecnica di profiling per valutazione di:
AMBIENTE
SPERIMENTALE



Analisi e scelta strumento di automazione
CONTRIBUTO
TESI



Prestazioni funzioni kernel eseguite al boot
Funzioni dei device driver
Bootchart
Ftrace
Ftrace: framework del kernel Linux

ATTIVITA’
TESTING
Function Graph Tracer:
CONCLUSIONI
 Misura il tempo di esecuzione delle funzioni (durata delle funzioni)
 Costruisce il grafo delle chiamate
 Debug filesystem per esportare i risultati nello user-space
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Valutazione delle Prestazioni del
Codice nella Fase di Boot (2)
AUTOMAZIONE
 Personalizzazione di Function
Graph Tracer
per l’applicazione su architettura ARM
AMBIENTE
SPERIMENTALE
KERNEL
CONTRIBUTO
TESI
Function{
probe
}
invoca
Mcount
__gnu_mcount_mc
arch/arm/kernel/entrycommon.S
invoca
ATTIVITA’
TESTING
compila
CONCLUSIONI
GCC
Function Graph
Tracer
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Valutazione delle Prestazioni del
Codice nella Fase di Boot (3)
AUTOMAZIONE

AMBIENTE
SPERIMENTALE

Problema: valori
durata non
accurati
Soluzione: utilizzo
di un timer ad alta
risoluzione
CONTRIBUTO
TESI
Sottosistema
time-management kernel
Modifica driver del timer: arch/arm/mach-cartesio/time.c
LR/HR Timer Framework
definisce
ATTIVITA’
TESTING
API
implementa
Device driver timer
CONCLUSIONI
LR/HR Hardware clock chips
API
Sched-clock()
chiama
Function Duration
Tracer
invoca
Struttura di Stato
Struct clock_source
Clock_source_read()
astrae
Hardware
HR timer clock chip
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Valutazione delle Prestazioni del Codice nella
Fase di Boot (4)
Risultati Sperimentali
AMBIENTE
SPERIMENTALE
Startup sistema
AUTOMAZIONE
Ambiente Target
User-space
Debug file
system
Risultati
Kernel-space
(Valori temporali in microsecondi)
CONTRIBUTO
TESI
0.18sec
0.05sec
ATTIVITA’
TESTING
0.04sec
CONCLUSIONI
0.02sec
0.02sec
Function
Graph Tracer
Ambiete Host
Risultati
MMC
Strumento Post-Analisi
FDD
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Rilevazione di Memory Leak

AUTOMAZIONE


AMBIENTE
SPERIMENTALE

Memory leakage: consumo di memoria
 Zona di memoria non più necessaria, non deallocata
 Errore di programmazione
Rilevanza nei sistemi embedded
 Impatto negativo prestazioni e affidabilità sistema
Scelto e personalizzato kmemleak
Memory leak nei device driver

CONTRIBUTO
TESI
ATTIVITA’
TESTING
cartesio_sga_probe
Fase
inizializzazione
driver


CONCLUSIONI
cartesio_sga_init
Funzione init
Funzione exit
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Valutazione delle Prestazioni di
I/O su Dispositivi di Mass Storage
Device driver MMC su release BSP 2.3 e 2.4
AUTOMAZIONE

Obiettivi:


AMBIENTE
SPERIMENTALE

Valutare le
prestazioni
Ottimizzazione
Strumenti base
CONTRIBUTO
TESI
time cp source dest
 Limite: scarsa
efficacia per processi
di ottimizzazione

1018 KB/s (media)
57.642 KB/s (media)
Strumenti
complessi per
ATTIVITA’
TESTING
correlare le
prestazioni ad altri
parametri: cpu cache,
buffer cache, ecc.
CONCLUSIONI

50.207 KB/s (media)
IOzone
9.204 KB/s (media)
SW SISTEMI
EMBEDDED
TESTING
EMBEDDED
Conclusioni
AUTOMAZIONE
AMBIENTE
SPERIMENTALE
CONTRIBUTO
TESI
ATTIVITA’
TESTING
CONCLUSIONI
Problema:
 Approcci ad-hoc
 Soluzione:
 Personalizzazione di strumenti generali
 Risultati:
 Approccio ad-hoc superato
 Personalizzazione, può influenzare la raccolta e
l'analisi dei risultati per valutare la qualità
 Migliorato il processo di testing STM
 aree di qualità non esplorate
 strumenti di automazione

Criteri Scelta Strumenti di
Automazione
1.
2.
3.
4.
5.
6.
7.
Instrumentazione (implicita o esplicita),
Licenza degli strumenti
Linguaggio di programmazione con il quale è
scritto il sw da testare
Sistema operativo
Architettura hw utilizzata
Ambito di utilizzo e integrazione (strumenti
user-space e kernel-space)
Interfaccia e reporting (GUI/command-line)
Rilevazione di Memory Leak (1)
Scelta dello Strumento


Non necessaria la
personalizzazione
per l’architettura
ARM
Facilmente
integrabile nel
kernel
Rilevazione di Memory Leak (2)
nei device driver

Fasi di un device driver:
 Esecuzione
 Inizializzazione
 Fase Inizializzazione
 Fase platform-dependet
del processo di boot del
kernel
 Registrazione dei
device
 Registrazione dei
driver
 Associazione tra
device e driver
Associazione tra device e driver
Rilevazione di Memory Leak (3)
Risultati Sperimentali


Errore programmazione: mancanza dell’istruzione di deallocazione della
struttura di stato
Funzione probe e funzione remove
FUNZIONE PROBE
FUNZIONE REMOVE
MEMORIA
struct cartesio_sga *sga
sga=kzalloc(struct cartesio_sga)
kfree (sga)
struttura di stato
struttura di stato
sga
struttura di stato
Rilevazione dell'errore con kmemleak
struttura di stato

cartesio_sga_probe
cartesio_sga_init
Problema con i driver
caricati come modulo
Rilevazione di Memory Leak (4)
Risultati Sperimentali


Errore programmazione: mancanza salvataggio dell’handle della struttura
di stato allocata
MEMORIA
Funzione probe
FUNZIONE PROBE
struttura di stato
struct cartesio_sga *sga
sga=kzalloc(struct cartesio_sga)
amba_set_drvdata(dev,sga)
sga
Struct device
Struct device_private *p
cartesio_sga_probe
cartesio_sga_init
Rilevazione dell'errore con
kmemleak
Valutazione delle Prestazioni di I/O su
Dispositivi a Blocchi
Scelta dello Strumento e Personalizzazione

Scelta dello strumento di automazione:



Bonnie e Bonnie++: valutazione di prestazioni su hard disk (tempi di seek)
Tiobench: stress test multi-thread
Iozone: verificare le prestazioni con l’influenza della gerarchia di memorie. Più
completo


diverse operazioni: read, write
dimensioni di file differenti (da 64KB a 512MB) trasferiti con record di diverse
dimensioni (da 4K a 16MB)
Ambiente Target
Risultati
compatibili excel
Risultati
MMC
User-space
IOzone
 Personalizzazione
CC= cc
C89= c89
GCC= gcc
CCS= /usr/ccs/bin/cc
NACC= /opt/ansic/bin/cc
CC= arm-stm-linux-gnueabi-gcc
C89= c89
GCC= gcc
CCS= /usr/ccs/bin/cc
NACC= /opt/ansic/bin/cc
Ambiete Host
Excel
Fly UP