Quali sono e a cosa servono gli strumenti di testing software

Quali sono e a cosa servono gli strumenti di testing software

Strumenti di testing

Gli strumenti a supporto delle attività di testing software sono:

  1. strumento per la registrazione dei difetti;
  2. strumento per la gestione delle modifiche
  3. strumento per la gestione e progettazione dei test;
  4. strumento per l’esecuzione dei test unitari;
  5. strumento per l’esecuzione automatica dei test;
  6. strumento per la simulazione delle condizioni di carico;
  7. strumenti per l’analisi statica del codice;
  8. altri strumenti specifici (ad esempio: creazione delle basi di dati, creazione di scaffolding tra cui driver e stub, ecc.).

Quali sono e a cosa servono gli strumenti di testing software

Strumento per la registrazione dei difetti

Lo strumento permette di registrare i difetti rilevati durante l’esecuzione dei test e di gestire gli stati previsti. Le principali funzioni fornite sono:

  1. Registrazione di un difetto e gestione degli stati previsti: il flusso di lavoro prevede, in sequenza, le seguenti attività: apertura del difetto ed assegnazione al gruppo di sviluppo, accettazione o rigetto del difetto da parte del gruppo di sviluppo, risoluzione dell’errore che ha causato il difetto (nel caso di accettazione) o registrazione delle motivazioni del rigetto (in caso di non accettazione), verifica della risoluzione (esecuzione del caso di test che ha rilevato il difetto), chiusura del difetto;
  2. Inserimento e/o aggiornamento dei dati del difetto: i dati inseriti e/o aggiornati dipendono dalla fase di gestione del difetto e relativo stato del difetto:
    1. Apertura ed assegnazione del difetto: identificativo, data apertura, descrizione, caso di test, gravità, data assegnazione, nominativo/gruppo cui è assegnato il difetto. L’assegnazione è notificata all’assegnatario via e-mail;
    2. Analisi e risoluzione del difetto: descrizione della causa del difetto (individuazione dell’errore), tipo di errore (codice, dati, disegno, specifiche, requisiti, documentazione utente, altro), correzione (elemento componenti modificati), altre informazioni utili (eventuali aree contigue da testare, ecc.);
    3. Verifica della risoluzione: esito dell’esecuzione del caso di test che ha rilevato il difetto e verifica della sua scomparsa, data completamento della verifica;
    4. Chiusura del difetto: data di chiusura, motivazione.
  3. Produzione di report statistici di sintesi e di dettaglio sui difetti e gli errori.

Lo strumento è essenziale nelle attività di testing e permette, nelle versioni più sofisticate di creare anche le curve di rimozione degli errori e di individuare il limite di saturazione (l’asintoto della curva).

Esistono diversi strumenti informatici per la gestione dei difetti, alcuni disponibili anche in internet.

Strumento per la gestione delle modifiche del software

Le funzioni principali relative alla gestione delle modifiche del software sono:

  • Registrazione delle modifiche: si tratta di poter aprire una richiesta di modifica e di registrare le informazioni relative (identificativo, descrizione, data, priorità, applicazione cui si applica la modifica, altre informazioni di dettaglio);
  • Aggioramento delle informazioni legate al ciclo di vita della modifica: analisi e valutazione dell’impatto, stato dello sviluppo, stato del test, chiusura della modifica;
  • Gestione del flusso (work-flow) e degli stati del processo: apertura, analisi e stima degli impatti, approvazione, pianificazione, progettazione e sviluppo, testing, rilascio;
  • Produzione di report sullo stato delle modifiche: report statistici co dati di sintesi e di dettaglio relativamente agli stati delle richieste di modifica (aperte, approvate, sviluppate, testate, rilasciate).

La gestione delle richieste di modifica è strettamente legata alla gestione della configurazione del software e degli ambienti di test.

Strumento per la gestione e la progettazione dei test

Si tratta di uno strumento informatico per pianificare le fasi di test, progettare i casi di test, registrare l’esito della loro esecuzione e produrre la reportistica necessaria.

Le funzionalità principali svolte dal responsabile dei test (Test Manager) e dai singoli tester con l’utilizzo di tale strumento sono:

  • Apertura di una fase di testing ed inserimento delle informazioni previste: fase di test (unitario, d’integrazione, di sistema, di accettazione), responsabile, data di inizio e di fine previste;
  • Definizione dei casi di test previsti: elenco dei casi di test previsti dalla fase;
  • Progettazione dei casi di test e registrazione delle informazioni: funzionalità testate, requisiti indirizzati, attività da eseguire e/o input richiesti, risultati attesi, prerequisiti;
  • Aggiornamento dello stato dei casi di test: aggiornamento dell’esito dei casi di test man mano che essi sono eseguiti, bloccati a causa di un difetto, ripresi ed infine completati con successo; di conseguenza è aggiornata la fase complessiva della fase di test;
  • Produzione della documentazione tecnica relativa ai casi di test;
  • Produzione di report sullo stato dei casi di test (completati, in esecuzione, bloccati, ancora da far partire).

Per quanto riguarda la progettazione dei casi di test, la descrizione delle attività che il tester dovrà svolgere nell’eseguire il caso di test può essere direttamente tratta dal “caso d’uso” (Use Case) nel caso in cui si utilizzi tale notazione e questa sia disponibile elettronicamente.

Durante l’esecuzione dei casi di test si rende necessario registrare i difetti rilevati tramite lo strumento descritto in un paragrafo precedente. Alcune soluzioni offrono strumenti integrati tra di loro: l’aggiornamento di un caso di test che ha rilevato un difetto attiva automaticamente il secondo strumento per la registrazione del difetto e viceversa.

Tali strumenti sono spesso inseriti all’interno di una “suite” che comprende anche altri strumenti.

Esistono strumenti offerti da ditte specializzate nel settore ma esistono anche prodotti resi disponibili all’interno della politica “open source”.

Strumento per l’esecuzione dei test unitari

Si tratta di strumenti, ambienti di sviluppo (development framework) e librerie integrati, a supporto dei test unitari, eseguiti generalmente dagli stessi sviluppatori nei propri ambienti di sviluppo (ad esempio: Unix e/o Windows) e sono generalmente legati al particolare linguaggio di sviluppo utilizzato (C, C++, Java, JavaScript, VB, Delphi, ecc.).

Permettono l’esecuzione principalmente di test di componente (“white-box”), ma anche di test “black-box”, cioè di tipo funzionali.

Possono essere legati ad altri tool con funzioni particolari quali, ad esempio, l’analisi dei rami del codice e verificare il livello di copertura eseguito dai test eseguiti.

Alcuni strumenti per i test unitari consentono anche di realizzare codice “di simulazione” (scaffolding, driver e stub) da compilare ed integrare nel codice da testare.

Le funzioni principali che questi strumenti permettono di svolgere sono:

  • eseguire il codice “vedendo” direttamente le istruzioni eseguite, i dati elaborati, i risultati ottenuti, il contenuto della memoria;
  • modificare, se necessario, i dati per modifica re e/o correggere l’esecuzione;
  • avere una visione “grafica” dei percorsi eseguiti e del livello di copertura del codice.

La disponibilità di strumenti di questo tipo è molto ampia, sia per le piattaforme proprietarie sia per quelle open source.

Strumento per l’esecuzione automatica dei test

Gli strumenti di questo tipo permettono di registrazione l’esecuzione dei casi di test e di rieseguirli automaticamente comparando i risultati delle due esecuzioni ed evidenziando le differenze.

Un utilizzo tipico quanto efficace di questi strumenti è nei test di “regressione”. Si tratta di quei casi in cui occorre rieseguire un insieme di casi di test (anche un numero molto alto) su di un sistema consolidato ogni volta che siano apportate delle modifiche e si vuole assicurare che il resto del sistema non sia stato alterato dai cambiamenti.

L’utilizzo di tali strumenti (record and play back) richiede che i casi di test siano progettati in modo particolare, lasciando inalterato l’ambiente così come lo era prima dell’esecuzione. Se, per esempio, un caso di test inserisce un nuovo record su cui testare delle funzioni applicative, occorre che al termine del test sia cancellato il record inserito. In questo modo, l’esecuzione successiva dello stesso caso di test eviterà di fermarsi immediatamente per “errore di duplicazione nell’inserimento del record”.

Anche non registrando test eseguiti precedentemente, è possibile utilizzare procedure apposite (scritte nei linguaggi forniti dai tool) per preparare o ripristinare gli ambienti e consentire l’esecuzione automatica di insiemi di casi di test anche molto sofisticati (test case suite).

Altri strumenti, molto più sofisticati, sono in grado di distinguere le variazioni nelle interfacce durante le diverse riesecuzioni (variazioni nelle dimensioni delle finestre, posizione di alcuni campi, colore e dimensioni delle schermate, ecc.).

Strumento per la simulazione delle condizioni di carico

Si tratta di strumenti specializzati nel simulare un carico alto sul sistema (specialmente sui sistemi client-server). Questi strumenti sono spesso comandati attraverso un’interfaccia grafica (GUI).

A seconda del tipo, dell’ambiente e dei linguaggi supportati gli strumenti possono essere utilizzati in modi e con obiettivi diversi.

Un modo di utilizzo, per esempio, è quello di simulare un numero alto di utenti contemporanei che accedono al sistema e di verificare quale sia il valore massimo supportato prima di mostrare un degrado nelle prestazioni.

Altri strumenti sono in grado di analizzare il codice (ad esempio: SQL) e di identificare i componenti che costituiscono un collo di bottiglia e riducono le prestazioni del sistema.

Altri strumenti, più sofisticati, permettono di testare il carico sulla rete e di predire il comportamento e le prestazioni dell’applicazione web. Sono in grado di testare l’intera architettura simulando un numero realistico di utenti connessi all’applicazione tramite la rete ed il carico che ne consegue. Alcuni sono in grado di identificare in tempo reale i componenti i crisi (colli di bottiglia) e le relative cause (velocità insufficiente, scarsa memoria, ecc.). Utilizzati come monitoraggio, alcuni di essi sono in grado di sorvegliare le transazioni e di registrare il contesto nel quale si generano eventuali problemi o incidenti (fermi, rallentamenti eclatanti, ecc.).

Altri strumenti, anche Open Source, sono molto specialistici e richiedono competenza specifica; in compenso permettono di generare carichi anche molto pesanti simulando l’attività anche di migliaia di utenti contemporanei virtuali. La funzione è realizzabile tramite l’architettura distribuita dello strumento nei diversi layer e componenti del sistema. Lo strumento visualizza anche in forma grafica i tempi di risposta degli utenti e l’utilizzo delle diverse risorse del sistema (Web Servers, Application Servers, Database Servers e Piattaforme operative su cui sono condotti i test).

Altri ancora sono specifici per i test di applicazioni che utilizzano apparecchiature wireless.

Molti generano anche report di dettaglio con le informazioni registrate.

Strumenti per l’analisi statica del codice

Si tratta di strumenti che analizzano i programmi senza eseguire il codice. L’analisi del codice sorgente riguarda caratteristiche come la “complessità”, la “strutturazione”, “la leggibilità”, la “semplicità sintattica”, ecc.

Ovviamente, questi tipi strumento dipendono fortemente dal linguaggio utilizzato per la scrittura del codice; non per tutti i linguaggi ci sono strumenti con le stesse funzionalità. Comunque, i linguaggi più utilizzati sono coperti.

I dati raccolti dall’analisi del codice sono elaborati e presentati in report con informazioni di sintensi e di dettaglio diversi.

Per quanto riguarda la complessità del software, gli strumenti calcolano quella “ciclomatica” e quella “esenziale” fornendo il valore calcolato per ogni singolo modulo e quello medio complessivo per l’intero parco applicativo analizzato.

Per quanto riguarda al “leggibilità”, per esempio, viene effettuata l’analisi sintattica del codice sorgente in termini di:

  • lunghezza di ciascun modulo/funzione/blocco/if/while/switche;
  • numero di strutture di controllo;
  • numero di operatori nelle espressioni;
  • livello di annidamento (nesting) dei blocchi;
  • ecc.

Per alcuni linguaggi specifici (ad esempio: C/C++, Java, ecc.) è poi possibile adoperare strumenti ad hoc in grado di effettuare l’analisi del codice sorgente, individuare violazioni degli standard (alcuni strumenti hanno la capacità di verificare anche più di 300 standard) e permettere la correzione del codice direttamente dallo strumento che si posiziona sull’istruzione incriminata e suggerisce cosa e come cambiare.

Altri strumenti, simili a quelli precedenti, permettono di registrare i cammini percorsi dai casi di test eseguiti ed evidenziano gli eventuali percorsi duplicati seguiti da alcuni casi di test; in questo modo possibile eliminare i casi di test duplicati ed ottimizzare l’efficienza dei test.

Infine, è garantito da prove di assoluta certezza l’aumento di produttività e di qualità che si ottiene con l’utilizzo di tali strumenti.

Altri strumenti specifici

Si tratta di strumenti specifici utilizzati nella fase di testing e con modalità e scopi diversi.

Alcuni, per esempio, permettono di creare delle basi di dati a partire da algoritmi e procedure specifiche. Possono generare intere basi di dati, specialmente se di grandissime dimensioni, con la generazione casuale (random) di dati specifici, oppure sequenziale (sequential) a partire da parametri definiti (da “a” a “z” con passo “x”). Sono utilissimi quando si tratti di generare archivi di grandi dimensioni con alcune chiavi sequenziali o casuali.

Altri strumenti permettono di costruire driver e stub a partire dal codice che li dovrà chiamare o da cui saranno chiamati.

Altri ancora, sono specifici per l’esecuzione di test di usabilità permettendo di registrare i comportamenti degli utenti a fronte di specifiche funzioni applicative adoperate. I comportamenti possono essere rappresentati dai tempi di risposta dell’utente nell’eseguire una transazione, oppure il tempo di reazione a fronte di una decisione da prendere, oppure ancora la correttezza nell’interpretare un messaggio del sistema, ecc. Altri comportamenti possono essere registrati a fronte dei “commenti” espressi dall’utente di fronte ad una funzione dell’applicativo. Gli strumenti relativi ai test di usabilità sono molto specifici e sono da utilizzare solo da parte di esperti in grado di valutare le reazioni degli utenti ed evitare qualsiasi tipo di equivoco, cattiva interpretazione o reazione negativa da parte dell’utente.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *