Operazione: Implementazione test
Questa attività descrive in che modo sviluppare test autonomi o collaborativi.
Discipline: Verifica
Scopo

Lo scopo di questo compito è di:

  • implementare uno o più prodotti di lavoro del test che permettano la convalida del prodotto software tramite esecuzione fisica
  • sviluppare test che possano essere eseguiti in combinazione con altri come parte di una più grande infrastruttura di test
Relazioni
Passi
Selezionare la tecnica di implementazione appropriata
Scopo:  Determinazione della tecnica di implementazione del test appropriata. 

Selezionare la tecnica di implementazione di test più appropriata. Per ogni test da eseguire, considerare di implementare almeno uno script di test. In alcune istanze, l'implementazione per un determinato test si estenderà su più script di test. In altre, un unico script di test fornirà l'implementazione per più test.

I metodi tipici per l'implementazione dei test comprendono la scrittura di una descrizione testuale sotto forma di uno script da seguire (per la verifica manuale) e la programmazione, la registrazione acquisita o la generazione di un linguaggio di programmazione basato su script (per la verifica automatizzata). Ogni metodo viene discusso nelle successive sezioni.

Come per la maggior parte dei metodi, si consiglia di utilizzare un insieme misto delle successive tecniche per ottenere risultati più utili. Anche se non è necessario utilizzarle tutte, non è consigliabile limitarsi all'utilizzo di una sola tecnica.

Argomenti secondari:

Script di test manuali Selezione della tecnica di implementazione

Molti test vengono eseguiti meglio manualmente, per cui occorre evitare l'errore di automatizzarli in modo inappropriato. I testi di utilizzabilità rappresentano un'area in cui la verifica manuale è in molti casi una soluzione migliore rispetto a quella automatizzata. Anche i test che richiedono la convalida dell'accuratezza e della qualità dell'output fisico da parte di un sistema software, di solito richiedono la convalida manuale. Come metodo generale, è buona idea iniziare i primi test di un particolare elemento di test di destinazione con una implementazione manuale; questo metodo consente al tester di conoscere l'elemento di destinazione, adattare il suo comportamento inatteso e applicare il giudizio umano per determinare la successiva azione appropriata da eseguire.

Alcune volte, i test eseguiti manualmente verranno successivamente automatizzati e riutilizzati come parte di una strategia di verifica di regresso. Si noti, tuttavia, che non è necessario né desiderabile e neanche possibile automatizzare ogni test che può essere eseguito manualmente. L'automazione offre vantaggi nella velocità e accuratezza di esecuzione del test, nella visibilità e raccolta dei risultati dettagliati del test e nell'efficienza della creazione e gestione di test complessi ma, come tutti gli strumenti utili, non è la soluzione a tutte le proprie esigenze.

L'automazione comporta determinati svantaggi: questi si basano essenzialmente sull'assenza del giudizio e del ragionamento dell'uomo durante l'esecuzione del test. Le soluzioni di automazione attualmente disponibili non dispongono delle capacità conoscitive tipiche dell'uomo ed è poco probabile che le abbiano in futuro. Durante l'implementazione di un test manuale, il ragionamento dell'uomo può essere applicato alle risposte ricevute dal sistema in seguito agli stimoli. Le tecniche di verifica automatizzate attuali e i rispettivi tool di supporto hanno, di solito, una limitata capacità di accorgersi delle implicazioni di determinati comportamenti del sistema e una minima capacità di dedurre i possibili problemi in base al ragionamento deduttivo.

Script di test programmati Selezione della tecnica di implementazione

È discutibilmente il metodo di scelta praticato dalla maggior parte dei tester che utilizzano l'automazione del test. Nella sua forma più pura, tale pratica viene eseguita nello stesso modo e utilizzando gli stessi principi generali della programmazione software. Per cui, la maggior parte dei metodi e dei tool utilizzati per la programmazione del software è generalmente applicabile e utile nella programmazione dell'automazione del test.

Utilizzando un ambiente di sviluppo software standard (come Microsoft Visual Studio o IBM Visual Age) oppure un ambiente di sviluppo di automazione test specializzato (come l'IDE fornito con Rational Robot), il tester è libero di utilizzare le caratteristiche e la potenza dell'ambiente di sviluppo per il raggiungimento del risultato migliore.

Gli aspetti negativi della programmazione dei test automatizzati riguardano gli stessi aspetti negativi della programmazione come tecnica generale. Affinché la programmazione sia efficace, occorre prestabilire alcune considerazioni per il progetto appropriato, altrimenti non avrà probabilmente esito positivo. Se il software sviluppato sarà sottoposto a probabili modifiche da parte di persone diverse nel tempo, situazione consueta, allora è necessario prestabilire alcune considerazioni sullo stile comune e sulla forma da utilizzare nello sviluppo del programma e assicurarne il corretto utilizzo. Molto probabilmente, le due più importanti preoccupazioni riguardano l'utilizzo sbagliato di questa tecnica.

Come prima cosa, c'è il rischio che il tester venga impegnato nelle caratteristiche dell'ambiente di programmazione e passi troppo tempo nel creare soluzioni ai problemi eleganti e sofisticate, raggiungibili in modo più semplice. La conseguenza è uno spreco di tempo prezioso da parte del tester in quelle che sono attività di programmazione che tolgono tempo alla verifica e alla valutazione degli elementi del test di destinazione. È necessaria disciplina ed esperienza per evitare queste insidie.

Come seconda cosa, c'è il rischio che il codice del programma utilizzato per implementare il test possa contenere errori di programmazione introdotti da errori od omissioni dell'uomo. Alcuni di tali errori saranno facili da rimuovere e correggere ne corso naturale dell'implementazione del test automatizzato, per altri errori non avverrà la stessa cosa. Così come gli errori possono sfuggire al rilevamento nell'elemento del test di destinazione, può essere ugualmente difficile rilevarli nel software di automazione di test. Inoltre, gli errori possono essere introdotti nei punti in cui gli algoritmi utilizzati nell'implementazione del test automatizzato si basano sugli stessi algoritmi imperfetti utilizzati dalla stessa implementazione del software. Ne conseguono errori non rilevati, nascosti dalla falsa protezione dei test automatizzati che vengono apparentemente eseguiti con successo. Ridurre tale rischio utilizzando diversi algoritmi nei test automatizzati, dovunque sia possibile.

Script di test registrati o acquisiti Selezione della tecnica di implementazione

Esistono alcuni tool di automazione di test che forniscono la possibilità di registrare o acquisire l'interazione dell'uomo con un'applicazione software e produrre uno script di test di base. A tal fine, ci sono diverse soluzioni di tool. La maggior parte dei tool produce uno script di test implementato in alcune forme, normalmente modificabili, di linguaggio di programmazione di alto livello. I progetti più comuni funzionano in uno dei seguenti modi:

  • Acquisendo l'interazione con la UI del client di un'applicazione basata sull'intercettazione degli input inviati dai dispositivi di input della periferica hardware del client (mouse, tastiera e così via) al sistema operativo del client. In alcune soluzioni, ciò viene fatto intercettando i messaggi di alto livello scambiati tra il sistema operativo e il driver del dispositivo che descrivono le interazioni in un modo alquanto significativo; in altre soluzioni, si acquisiscono i messaggi di basso livello, spesso basati al livello dei movimenti in funzione del tempo delle coordinate del mouse o degli eventi di tasto su e tasto giù.
  • Intercettazione dei messaggi inviati e ricevuti attraverso la rete tra l'applicazione client e una o più applicazioni server. L'interpretazione riuscita di tali messaggi fa affidamento di solito sull'utilizzo di protocolli di messaggistica standard riconosciuti, come HTTP, SQL e così via. Alcuni tool consentono anche l'acquisizione di protocolli di comunicazione di "base" come TCP/IP; comunque, può essere molto più complesso lavorare con gli script di test di questa natura.

Mentre queste tecniche sono generalmente utili da includere come parte del metodo di verifica automatizzata, alcuni professionisti pensano che tali tecniche abbiano dei limiti. Una delle principali preoccupazioni è che alcuni tool si limitano semplicemente ad acquisire l'interazione dell'applicazione e nient'altro. Senza l'inclusione aggiuntiva di punti di osservazione che acquisiscono e confrontano lo stato del sistema durante la susseguente esecuzione dello script, lo script di test di base non può essere considerato un test completo. Dove si verifica tale situazione, la registrazione iniziale dovrà successivamente essere aumentata con il codice supplementare di programma personalizzato per implementare i punti di osservazione all'interno dello script di test.

Sono stati pubblicati libri e saggi di vari autori su questa e altre problematiche riguardanti la registrazione o l'acquisizione della procedura di test come tecnica di automazione di test. Per avere una maggiore comprensione di tali problemi, si consiglia di esaminare il lavoro disponibile su Internet dei seguenti autori: James Bach, Cem Kaner, Brian Marick e Bret Pettichord e i contenuti attinenti presenti nel libro Lessons Learned in Software Testing [KAN01]

Test generati Selezione della tecnica di implementazione

Alcuni dei più sofisticati software di automazione test consentono la generazione effettiva di vari aspetti del test, sia procedurali che relativi ai dati di test dello script di test basato sugli algoritmi di generazione. Questo tipo di automazione può ricoprire un ruolo utile nell'attuazione del test, ma non deve essere considerato come un metodo sufficiente da solo. Il tool Rational TestFactory e la funzione di generazione di pool di dati Rational TestManager sono implementazioni di esempio di questi tipo di tecnologia.

Configurazione delle condizioni preliminari dell'ambiente di test
Scopo:  Preparazione dell'ambiente per il corretto stato di inizio. 

Configurare l'ambiente del test, includendo tutto l'hardware, il software, i tool e i dati. Assicurarsi che tutti i componenti siano in funzione in modo appropriato. Di solito ciò riguarderà qualche forma di reimpostazione dell'ambiente base (ad esempio, la reimpostazione del registro di Windows e altri file di configurazione), il ripristino di database sottostanti allo stato conosciuto e così via in aggiunta alle attività come il caricamento della carta nelle stampanti. Mentre alcune attività possono essere eseguite in modo automatico, alcuni aspetti richiedono tuttavia l'intervento umano.

Argomenti secondari:

(Facoltativo) Percorso manuale del test Configurazione

Applicabile soprattutto agli script di test automatizzati, può essere di aiuto inizialmente nella spiegazione del procedimento di test manuale per la conferma della presenza dei prerequisiti previsti. Durante il percorso, occorre verificare l'integrità dell'ambiente, il software e la progettazione del test. Il percorso è maggiormente attinente dove si utilizza una tecnica di registrazione interattiva e meno dove si programma lo script di test. L'obiettivo è di verificare che tutti gli elementi richiesti per implementare il test con successo siano presenti.

Quando si è sicuri della stabilità o maturità del software, è possibile ignorare questo passaggio dove si ritiene che il rischio di problemi che si verificano nelle aree che il percorso manuale indirizza sia relativamente basso.

Identificazione e conferma dell'appropriatezza delle previsioni di test Configurazione

Confermare l'appropriatezza delle previsioni di test che si intendono utilizzare. Dove non sono state ancora identificate, è il momento di farlo.

È necessario provare a confermare attraverso mezzi alternativi che la scelta delle previsioni di test fornirà risultati accurati e affidabili. Ad esempio, se si pianifica di convalidare i risultati di test utilizzando un campo visualizzato tramite l'interfaccia grafica dell'applicazione che indica l'avvenuto aggiornamento di un database, si consideri di interrogare in modo indipendente il database back-end per verificare lo stato dei corrispondenti record nel database. In alternativa, si possono ignorare i risultati presentati in una finestra di dialogo di conferma di aggiornamento e, al contrario, confermare l'aggiornamento interrogando il record attraverso il front-end di una funzione od operazione alternativa.

Ripristino dell'ambiente e dei tool di test Configurazione

Occorre successivamente ripristinare l'ambiente, includendo i tool di supporto, allo stato originale. Come menzionato nei passi precedenti, ciò riguarderà qualche forma di reimpostazione dell'ambiente base, il ripristino di database sottostanti a uno stato conosciuto e così via in aggiunta alle attività come il caricamento della carta nelle stampanti. Mentre alcune attività di ripristino possono essere eseguite automaticamente, alcuni aspetti richiedono tuttavia l'intervento umano.

Configurare le opzioni di implementazione i tool di supporto al test, che varieranno in funzione della sofisticazione del tool. Dove possibile, è necessario considerare di memorizzare le impostazioni dell'opzione per ogni tool, in modo che possano essere ricaricate facilmente in base a uno o più profili predeterminati. Nel caso di verifica manuale, includerà attività come il partizionamento di una nuova immissione in un sistema di supporto per la registrazione dei risultati del test o la firma in un sistema di registrazione di problema e richiesta di modifica.

Nel caso di tool di implementazione di test automatizzato, si possono dover considerare molte diverse impostazioni. La non corretta impostazione di queste opzioni potrebbe ridurre l'utilità e il valore delle risorse di test risultanti.

Implementazione del test
Scopo:  Implementazione di una o più risorse di implementazione di test riutilizzabili. 

Utilizzando l'elenco di proposte di test oppure uno o più artefatti di test selezionati, avviare l'implementazione del test. Iniziare fornendo al test un nome univocamente identificabile (se non presente) e preparare l'IDE, il tool di acquisizione, il foglio elettronico o il documento per iniziare la registrazione dei passi specifici del test. Avanzare attraverso le seguenti sezioni secondarie tutte le volte che viene richiesto di implementare il test.

Tenere presente che per alcuni test specifici o tipi di test, può esserci poco valore nella documentazione dei passi espliciti necessari per eseguire il test. In determinati stili di verifica d'esplorazione, la ripetizione del test non è un aspetto distribuibile. Per i test molto semplici, una breve descrizione dell'obiettivo dei test sarà sufficiente in molti casi per consentirne la riproduzione .

Argomenti secondari:

Implementazione delle azioni di navigazione Inizio pagina

Programmare, registrare o generare le azioni di navigazione richieste. Iniziare selezionando il metodo di scelta di navigazione appropriato. Per la maggior parte dei sistemi attuali, il "mouse" o altro dispositivo di puntamento è il preferito e principale mezzo di navigazione. Ad esempio, il dispositivo di puntamento e scrittura utilizzato con un PDA (Personal Digital Assistants) è concettualmente equivalente a un mouse.

Il mezzo di navigazione secondario è fornito dall'interazione della tastiera. Nella maggioranza dei casi, la navigazione sarà una combinazione delle azioni determinate dal mouse e dalla tastiera.

In alcuni casi, sarà necessario considerare forme di riconoscimento vocale, luminoso, visivo e di altri tipi. Queste possono essere più difficili per l'automazione dei test e possono richiedere l'aggiunta di speciali estensioni di interfaccia per test all'applicazione per consentire agli elementi audio o visivi di essere caricati ed elaborati da file piuttosto che acquisiti dinamicamente.

In alcune situazioni, si può desiderare o avere necessità di eseguire lo stesso test utilizzando più metodi di navigazione. Si possono seguire diversi metodi per ottenere ciò, ad esempio: automatizzare tutti i test utilizzando un metodo ed eseguendo manualmente tutti o alcuni sottoinsiemi di test utilizzandone altri; separare gli aspetti della navigazione dei test dai dati del test che caratterizzano il test specifico, fornendo e creando un'interfaccia logica di navigazione che consente la selezione di uno o dell'altro metodo per la conduzione del test; combinare e accoppiare semplicemente i metodi di navigazione.

Implementazione dei punti di osservazione Inizio pagina

In ciascun punto dello script di test dove occorre effettuare un'osservazione, utilizzare la previsione di test appropriata per acquisire le informazioni desiderate. In molti casi, le informazioni ottenute dal punto di osservazione devono essere registrate e conservate per essere richiamate durante i successivi punti di controllo.

Nei punti in cui si tratta di un test automatizzato, decidere in che modo le informazioni osservate devono essere riportate dallo script di test. Nella maggior parte dei casi, è di solito appropriato registrare semplicemente l'osservazione in un log di test centrale relativo al proprio intervallo di tempo dall'avvio dello script di test; in altri casi le osservazioni specifiche potrebbero essere emesse separatamente in un foglio elettronico o file di dati per utilizzi più sofisticati.

Implementazione dei punti di controllo Inizio pagina

In ogni punto nello script di test dove occorre prendere una decisione di controllo, ottenere e valutare le informazioni appropriate per determinare il ramo corretto del flusso di controllo da seguire. I dati recuperati da precedenti punti di osservazione vengono di solito immessi ai punti di controllo.

Dove si verifica un punto di controllo e viene presa una decisione sulla successiva azione nel flusso di controllo, si consiglia di registrare nel log di test i valori immessi al punto di controllo e il flusso risultante che viene selezionato.

Risoluzione degli errori nell'implementazione del test Inizio pagina

Durante l'implementazione del test, verranno probabilmente introdotti degli errori nell'implementazione stessa. Tali errori possono essere la conseguenza di omissioni dall'implementazione del test o essere relativi a errori di considerazione relativi all'ambiente del test. Questi errori devono essere risolti prima che il test possa essere considerato completamente implementato. Identificare ogni errore riscontrato e lavorare per risolverlo.

Nel caso di automazione del test che utilizza un linguaggio di programmazione, ciò potrebbe comprendere errori di compilazione dovuti a variabili e funzioni non dichiarate o l'utilizzo non valido di tali funzioni. Adoperarsi utilizzando i messaggi di errore visualizzati dal compilatore o da qualsiasi alla fonte di messaggi di errore, fino a quando lo script di test sia privo di errori sintattici e di implementazione di base.

Tenere presente che durante la successiva esecuzione del test, potrebbero manifestarsi altri errori nell'implementazione del test. Inizialmente possono sembrare come errori nell'elemento di test destinazione, per cui occorre essere diligenti nell'analizzarli e confermare che sono errori dell'elemento di test di destinazione e non dell'implementazione del test.

Determinazione di insiemi di dati esterni
Scopo:  Creazione e gestione dei dati memorizzati esternamente allo script di test e utilizzati dal test durante l'esecuzione. 

In molti casi è più appropriato gestire i dati del test esternamente allo script di test. Ciò fornisce flessibilità, semplicità e sicurezza nella gestione dello script e dei dati del test. Gli insiemi di dati esterni forniscono valore al test nei seguenti modi:

  • I dati di test sono esterni allo script di test che elimina i riferimenti fissi del codice nello script di test
  • I dati di test esterni possono essere modificati facilmente, di solito con un minimo impatto per lo script di test
  • I test aggiuntivi possono essere facilmente supportati dai dati di test senza o con piccole modifiche dello script di test
  • I dati di test esterni possono essere condivisi con molti script di test
  • Gli script di test possono essere sviluppati per utilizzare dati di test esterni per il controllo della ramificazione logica condizionale all'interno dello script di test.
Verifica dell'implementazione del test
Scopo:  Verifica del corretto funzionamento dello script di test attraverso la sua esecuzione. 

Soprattutto nel caso dell'automazione di test, sarà probabilmente necessario impiegare del tempo per stabilizzare il funzionamento del test quando viene eseguito. Dopo aver completato l'implementazione di base dello script di test, occorre verificarlo per assicurarsi che implementi i singoli test in modo appropriato e che vengano eseguiti correttamente.

Ripristino dell'ambiente di test allo stato conosciuto Verifica dell'implementazione del test

È necessario ripristinare l'ambiente al suo stato originale, ripulendo dopo il lavoro di implementazione del test. Come riferito nei precedenti passi, ciò riguarderà qualche forma di reimpostazione dell'ambiente operativo di base, il ripristino di database sottostanti a uno stato conosciuto e così via in aggiunta alle attività come il caricamento della carta nelle stampanti. Mentre alcune attività possono essere eseguite in modo automatico, alcuni aspetti richiedono tuttavia l'intervento umano.

Configurazione dei tool e avvio dell'esecuzione del test Verifica dell'implementazione del test

Soprattutto nel caso di automazione del test, le impostazioni all'interno dei tool di supporto devono essere modificate. L'obiettivo è quello di verificare il corretto funzionamento dello script di test tramite la sua esecuzione.

È una buona idea eseguire questo passo utilizzando la stessa versione di Build del software utilizzato per implementare gli script di test. Ciò elimina la possibilità di problemi relativi a errori introdotti nei build successivi.

Risoluzione di errori di esecuzione Verifica dell'implementazione del test

È abbastanza comune che alcune delle cose fatte e i metodi utilizzati durante l'implementazione abbiano la necessità di alcune regolazioni per consentire al test di essere eseguito senza essere sorvegliato, soprattutto in relazione all'esecuzione del test in configurazioni di ambiente di test multiple.

Nel caso di automazione del test, è necessario impiegare del tempo per verificare che i test funzionino entro determinate tolleranze e per regolarli fino a che funzionino in modo attendibile prima di dichiarare il test implementato. Anche se è possibile ritardare questo passo a quello successivo nel ciclo vitale (ad. es., durante lo sviluppo della suite di test), si consiglia di non farlo, altrimenti si potrebbe finire con un notevole carico di lavoro di arretrato di errori da risolvere.

Ripristino dell'ambiente di test a uno stato conosciuto
Scopo:  Lasciare l'ambiente come lo si è trovato oppure in uno stato necessario per implementare il test successivo.  

Anche se questo passo potrebbe sembrare banale, è una importante buona abitudine per disporre il lavoro in modo efficace con gli altri tester del team, soprattutto dove l'ambiente di implementazione è condiviso. È importante anche stabilire una procedura che faccia pensare alla seconda natura dello stato del sistema.

Mentre in uno sforzo di verifica soprattutto manuale, è spesso semplice identificare e fissare i problemi di ripristino dell'ambiente, l'automazione del test ha una capacità molto inferiore nel tollerare i problemi imprevisti con lo stato dell'ambiente.

Gestione delle relazioni di tracciabilità
Scopo:  Abilitare l'esecuzione della segnalazione dell'analisi d'impatto e della valutazione sugli elementi tracciati. 

Utilizzando i requisiti di tracciabilità evidenziati nel piano di test, aggiornare le relazioni di tracciabilità come richiesto.

Valutazione e verifica dei risultati
Scopo:  Verificare che il compito sia stato completato in modo appropriato e che i prodotti di lavoro risultanti siano accettabili. 

A questo punto di completamento del lavoro, è preferibile verificare che il lavoro sia stato di livello sufficiente. È necessario valutare se il proprio lavoro sia stato all'altezza, e che sia completo abbastanza da essere utile ai membri del team che l'utilizzeranno in seguito. Dove possibile, utilizzare l'elenco di controllo fornito da RUP per verificarne la qualità e la completezza.

È necessario che le persone che utilizzeranno il proprio lavoro come input per eseguire le attività a valle prendano parte alla revisione del proprio lavoro provvisorio. Procedere in questo modo mentre si ha ancora tempo a disposizione per prendere decisioni e discutere delle loro considerazioni. Inoltre, è necessario valutare il lavoro svolto rispetto ai prodotti di lavoro di input chiave per accertarsi che vengano rappresentati o considerati in modo accurato e sufficiente. Potrebbe essere utile chiedere all'autore del prodotto di lavoro di input di revisionare il vostro lavoro su queste basi.

Tenere presente che RUP è un processo di produzione iterativo e che in molti casi i prodotti di lavoro evolvono nel tempo. Come tale, non è di solito necessario (spesso è controproducente) formare completamente un prodotto di lavoro che sarà solo parzialmente utilizzato o non utilizzato affatto in un immediato lavoro a valle successivo. Ciò è dovuto all'elevata probabilità che le condizioni presenti intorno al prodotto di lavoro cambieranno - e le supposizioni fatte quando il prodotto di lavoro è stato creato valutate non corrette - prima che il prodotto venga utilizzato, determinando come risultato una rilavorazione e pertanto uno spreco di impegno lavorativo.

Inoltre, evitare l'inconveniente di spendere troppi cicli in presentazioni a danno del valore del contenuto. Negli ambienti di progettazione dove la presentazione ha importanza e valore economico come progetto distribuibile, si può considerare di utilizzare una risorsa amministrativa o junior per eseguire il lavoro su un prodotto di lavoro per migliorarne la presentazione.



Ulteriori informazioni