Ingegneria del software: 16 maggio 2005

Testing delle interfacce

Quali interfacce (grafiche? a linea di comando? A condivisione di memoria? A passaggio di messaggi?)
Tipi d'errore
Sbaglio nell'uso dell'interfaccia
Fraintendimenti dell'interfaccia
Errori di tempistica o di sincronizzazione
Quali sottoinsiemi del dominio di ingresso verranno trattati allo stesso modo?
Definiamo Classi di equivalenza i "gruppi di input" che verranno trattati in maniera analoga nel programma, così possiamo scegliere solo un rappresentante per ogni classe anziché testare tutta la classe
Si cerca di individuare dati di test che possano rivelare eventuali errori (es. numero negativi o zero)
Nel caso un dato sia un valore specifico provare sia con una classe valida che una non valida (es. password)
Gli errori tendono ad annidarsi ai limiti del dominio (ad esempio per 0, l'ultimo elemento di un array, ecc.)

Category PartitionE' un modo di dividere in classi di equivalenza

1. Analisi delle specifiche (individuare l'unità minima testabile e raggrupparle in categorie: ad esempio un parametro, lo stato di un particolare file (non presente, sola lettura, ecc.))


2. Partizionare le categorie in "scelte" (ad esempio sul dato parametro provare casi accettabili, stringhe vuote, casi non accettabili come stringhe troppo lunghe; oppure sull'ambiente: file non valido, ecc.)


3. Determinare eventuali vincoli fra le scelte (Fare tutte le combinazioni significative delle scelte dei test; trovare dei vincoli fra le scelte per limitare il numero di combinazioni. Ad es. un file non valido potrebbe invalidare tutte gli altri input)


4. Scrivere test e documentazione (Cercare di generare automaticamente i test in base alle scelte e ai vincoli

Approccio combinatorio: al posto di scegliere tutte le possibili combinazioni tra i test (contanto i vincoli) potrei prenderne solo alcune a caso

Software inspection
E’ una tecnica manuale (fatta da persone)
Moderatore: coordina i meeting, sceglie i partecipanti, controlla i processi
Readers, testers: sono quelli che al meeting leggono ad alta voce il codice (interpretandolo), cercano i difetti
Autore: l’autore del codice, risponde ad eventuali dubbi

Indicativamente 5/6 personeFasi:
Pianificazione (moderatore pianifica e sceglie le persone),
overview (per fornire il background e assegnare i ruoli),
preparation (attività X la comprensione del codice da parte dei partecipanti),
inspection (attività centrale: la lettura del codice e individuazione degli errori),
rework (l’autore corregge gli errori).

L’ispezione Goal: trovare il maggior numero di difetti
Massimo 2 sessioni al giorno da massimo 2 ore (molto pesante).
Trovare i difetti, ma non correggerli (non servono 5 programmatori per correggere gli errori)
Il moderatore regola che non si perda tempo (potevi farlo così, potevi farlo cosà)
C’è una checklist di cose da controllare SEMPRE (aggiornate e modificate per l’azienda)
Incentivi sociali: non dare punizioni, se mai darle dopo questa fase.

Active Design Review (variazione da software inspection)
Scegliere revisori con adeguata esperienza
L’autore fa domande al revisore (checklist) (per evitare che i revisori siano passivi)
Ci sono dei tool di supporto (controlli banali: tipo formattazione, riferimenti (checklists, standard con esempi, aiuti alla comprensione del codice (reenginering, ecc.), annotazioni e comunicazioni, guida al processo e rinforzo)
Posso usarlo anche su programmi incompleti e non funzionanti
In realtà è un processo piuttosto rigoroso…

Limiti:
Test solo di singole parti del codice
Non incrementale (non posso riproporlo automaticamente ad una nuova versione del software)

Vantaggi di avere un gruppo di testing (che faccia solo testing)
Maggiore specializzazione
Conoscenza di tecniche/strumenti
Distacco dal codice (pensa a cose diverse da chi l’ha scritto)
Indipendenza dalla valutazione

Svantaggi:
Si perde la capacità di scrivere codice
Minore conoscenza dei requisiti
Possibile pressione psicologica negativa sul team di sviluppo
Difficile stabilire le responsabilità (di chi scrive e sbaglia o di chi testa e non trova?)
Better testing-worst quality (“tanto poi loro correggono…”)
Alternativa: rotazione del personale

Modelli statistici
Ci sono studi sulla presenza di errori a seconda di alcune metriche del codice (lunghezza dei moduli, numero di uscite dal modulo, ecc.) quindi posso tentare di predire la distribuzione degli errori (però è solo una cosa statistica)
In alcuni casi al posto di ultra-testare un modulo “pericoloso” lo si fa riscrivere…