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:
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.
È 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.
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]
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:
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.
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.
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:
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.
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.
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.
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.
È 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.
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.
È 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.
|
|