OOAD - Test e garanzia di qualità

Una volta che un codice di programma è stato scritto, deve essere testato per rilevare e successivamente gestire tutti gli errori in esso contenuti. Diversi schemi vengono utilizzati a scopo di test.

Un altro aspetto importante è l'idoneità allo scopo di un programma che accerti se il programma serve allo scopo a cui mira. L'idoneità definisce la qualità del software.

Test di sistemi orientati agli oggetti

Il test è un'attività continua durante lo sviluppo del software. Nei sistemi orientati agli oggetti, il test comprende tre livelli, vale a dire test di unità, test di sottosistemi e test di sistema.

Test unitario

In unit testing, le singole classi vengono testate. Si vede se gli attributi della classe sono implementati come da progetto e se i metodi e le interfacce sono privi di errori. L'unità di test è responsabilità dell'ingegnere dell'applicazione che implementa la struttura.

Test del sottosistema

Ciò comporta il test di un particolare modulo o sottosistema ed è responsabilità del responsabile del sottosistema. Implica la verifica delle associazioni all'interno del sottosistema e dell'interazione del sottosistema con l'esterno. I test del sottosistema possono essere utilizzati come test di regressione per ogni nuova versione del sottosistema.

Test di sistema

Il test del sistema implica il test del sistema nel suo insieme ed è responsabilità del team di controllo qualità. Il team utilizza spesso i test di sistema come test di regressione durante l'assemblaggio di nuove versioni.

Tecniche di test orientate agli oggetti

Test della scatola grigia

I diversi tipi di test case che possono essere progettati per testare programmi orientati agli oggetti sono chiamati casi di test gray box. Alcuni dei tipi importanti di test della scatola grigia sono:

  • State model based testing - Questo comprende la copertura dello stato, la copertura della transizione di stato e la copertura del percorso di transizione dello stato.

  • Use case based testing - Ogni scenario in ogni caso d'uso viene testato.

  • Class diagram based testing - Ogni classe, classe derivata, associazioni e aggregazioni vengono testate.

  • Sequence diagram based testing - I metodi nei messaggi nei diagrammi di sequenza vengono testati.

Tecniche per il test dei sottosistemi

I due approcci principali del test del sottosistema sono:

  • Thread based testing - Vengono integrate e testate tutte le classi necessarie per realizzare un singolo caso d'uso in un sottosistema.

  • Use based testing- Vengono testate le interfacce e i servizi dei moduli a ciascun livello gerarchico. Il test inizia dalle singole classi ai piccoli moduli costituiti da classi, gradualmente a moduli più grandi e infine tutti i principali sottosistemi.

Categorie di test di sistema

  • Alpha testing - Viene eseguito dal team di test all'interno dell'organizzazione che sviluppa il software.

  • Beta testing - Ciò viene effettuato da un gruppo selezionato di clienti che collaborano.

  • Acceptance testing - Questo viene eseguito dal cliente prima di accettare i deliverable.

Garanzia di qualità del software

Qualità del software

Schulmeyer e McManus hanno definito la qualità del software come "l'idoneità all'uso dell'intero prodotto software". Un software di buona qualità fa esattamente quello che dovrebbe fare e viene interpretato in termini di soddisfazione delle specifiche dei requisiti stabilite dall'utente.

Garanzia di qualità

La garanzia della qualità del software è una metodologia che determina la misura in cui un prodotto software è idoneo all'uso. Le attività incluse per determinare la qualità del software sono:

  • Auditing
  • Sviluppo di standard e linee guida
  • Produzione di report
  • Revisione del sistema di qualità

Fattori di qualità

  • Correctness - La correttezza determina se i requisiti software sono adeguatamente soddisfatti.

  • Usability - L'usabilità determina se il software può essere utilizzato da diverse categorie di utenti (principianti, non tecnici ed esperti).

  • Portability - La portabilità determina se il software può funzionare su piattaforme diverse con dispositivi hardware diversi.

  • Maintainability - La manutenibilità determina la facilità con cui gli errori possono essere corretti e i moduli possono essere aggiornati.

  • Reusability - La riusabilità determina se i moduli e le classi possono essere riutilizzati per lo sviluppo di altri prodotti software.

Metriche orientate agli oggetti

Le metriche possono essere classificate in tre categorie: metriche di progetto, metriche di prodotto e metriche di processo.

Metriche del progetto

Le metriche di progetto consentono a un project manager di software di valutare lo stato e le prestazioni di un progetto in corso. Le seguenti metriche sono appropriate per progetti software orientati agli oggetti:

  • Numero di script di scenario
  • Numero di classi chiave
  • Numero di classi di supporto
  • Numero di sottosistemi

Metriche del prodotto

Le metriche del prodotto misurano le caratteristiche del prodotto software che è stato sviluppato. Le metriche del prodotto adatte per i sistemi orientati agli oggetti sono:

  • Methods per Class- Determina la complessità di una classe. Se si presume che tutti i metodi di una classe siano ugualmente complessi, allora una classe con più metodi è più complessa e quindi più suscettibile agli errori.

  • Inheritance Structure- I sistemi con diversi piccoli reticoli di ereditarietà sono più ben strutturati rispetto ai sistemi con un unico grande reticolo di ereditarietà. Come regola empirica, un albero ereditario non dovrebbe avere più di 7 (± 2) numero di livelli e l'albero dovrebbe essere bilanciato.

  • Coupling and Cohesion - I moduli con basso accoppiamento e alta coesione sono considerati meglio progettati, in quanto consentono una maggiore riutilizzabilità e manutenibilità.

  • Response for a Class - Misura l'efficienza dei metodi chiamati dalle istanze della classe.

Metriche di processo

Le metriche di processo aiutano a misurare le prestazioni di un processo. Vengono raccolti su tutti i progetti per lunghi periodi di tempo. Sono utilizzati come indicatori per il miglioramento dei processi software a lungo termine. Alcune metriche di processo sono:

  • Numero di KLOC (Kilo Lines of Code)
  • Efficienza di rimozione dei difetti
  • Numero medio di errori rilevati durante il test
  • Numero di difetti latenti per KLOC