Linea guida: Programmazione di script di test automatizzati
Questa linea guida descrive i principi dello sviluppo efficace di uno script di test automatizzato.
Relazioni
Elementi correlati
Descrizione principale

Struttura degli script di test

Per aumentare la gestibilità e il riutilizzo dei propri script di test, sarebbe opportuno strutturarli prima che vengano implementati. Probabilmente si noterà che esistono azioni che saranno presenti in numerosi script di test. Un obiettivo dovrebbe essere l'identificazione di tali azioni in modo che sia possibile riutilizzare la relativa implementazione.

Ad esempio, potrebbero esistere script di test che sono combinazioni di azioni differenti che è possibile eseguire su un record. Tali script di test potrebbero essere combinazioni di aggiunta, modifica ed eliminazione di un record:

  • Aggiungi, Modifica, Elimina (il più ovvio)
  • Aggiungi, Elimina, Modifica
  • Aggiungi, Elimina, Aggiungi, Elimina...
  • Aggiungi, Aggiungi, Aggiungi, ...

Se si identificano e si implementano tali azioni come script di test separati e si riutilizzano tali script in altri script di test, si otterrà un elevato livello di riutilizzo.

Un altro obiettivo potrebbe essere la strutturazione degli script di test in modo che una modifica nel software di destinazione causi una modifica localizzata e controllabile negli script di test. Ciò renderà gli script più elastici alle modifiche nel software di destinazione. Ad esempio, si supponga che la porzione di log-in del software è stata modificata. Per tutti gli scenari di test che attraversano la porzione di log-in, solo lo script di test appartenente al log-in dovrà cambiare.

Tecnica di registrazione

Per ottenere un'elevata gestibilità dei propri script di test, sarebbe opportuno registrarli in un modo che sia il meno vulnerabile alle modifiche nell'obiettivo del test. Ad esempio, per uno script di test che compila i campi di una finestra di dialogo, sono disponibili alcune opzioni relative a come procedere da un campo al successivo:

  • Utilizzare il tasto TAB
  • Utilizzare il mouse
  • Utilizzare il tasti di scelta rapida della tastiera

Di tali opzioni, alcune sono più vulnerabili di altri a designare le modifiche. Se viene inserito un nuovo campo nella schermata, l'approccio del tasto TAB non sarà affidabile. Se i tasti di scelta rapida vengono riassegnati, non forniranno una buona registrazione. Se il metodo utilizzato dal mouse per identificare un campo è soggetto a modifica, potrebbe non essere affidabile. Tuttavia, alcuni tool di automazione dei test dispongono di registratori degli script di test che è possibile istruire per identificare il campo tramite un metodo più affidabile, ad esempio il relativo nome oggetto assegnato dal tool di sviluppo (PowerBuilder, SQLWindows o Visual Basic). In questo modo, uno script di test del registratore non viene influenzato da modifiche minori all'interfaccia utente (ad esempio, modifiche di layout, modifiche all'etichetta del campo, modifiche di formattazione, ecc.)

Verifica basata sui dati

Numerosi script di test prevedono l'immissione di diverse serie di dati del campo in una schermata di immissione dati specificata per controllare le funzioni di convalida del campo, la gestione degli errori e così via. Le fasi procedurali sono le stesse; soltanto i dati sono differenti. Anziché registrare uno script di test per ogni serie di dati di input, sarebbe opportuno eseguire una singola registrazione e quindi modificarla per gestire più serie di dati. Ad esempio, tutte le serie di dati che producono lo stesso errore a causa di dati non validi possono condividere lo stesso script di test del registratore. Lo script di test viene modificato per utilizzare i dati come informazioni variabili, per leggere le serie di dati da un file o da altre fonti esterne e per eseguire un loop attraverso tutte le serie di dati rilevanti.

Se gli script di test o il codice del test sono stati sviluppati per eseguire un loop attraverso serie di dati di input e output, occorre stabilire tali serie. Il formato consueto da utilizzare per queste serie di dati è costituito da record di campi separati da virgole in un file di testo. Questo formato è di semplice lettura negli script di test e nel codice del test ed è facile da creare e gestire.

La maggior parte dei pacchetti di fogli di calcolo e dei database sono in grado di produrre un output testuale separato da virgole. L'utilizzo di tali pacchetti per organizzare o catturare le serie di dati ha due vantaggi importanti. Innanzitutto, essi forniscono un ambiente più strutturato per l'immissione e la modifica dei dati rispetto al semplice utilizzo di un editor o di un elaboratore di testi. Secondo poi, la maggior parte di essi è in grado di interrogare i database esistenti e di catturare i dati restituiti, consentendo di estrarre con facilità le serie di dati dalle origini esistenti.

Gestione degli errori

Lo script di test registrato è sequenziale nella relativa esecuzione. Non esistono diramazioni. Una gestione degli errori solida negli script di test richiede un'ulteriore logica per rispondere alle condizioni di errore. La logica di decisione che è possibile impiegare in caso di errore prevede:

  • Branching a uno script di test differente.
  • Chiamata a uno script che tenti di eliminare la condizione di errore.
  • Uscita dallo script e avvio del successivo.
  • Uscita dallo script e dal software, riavvio e ripresa della verifica allo script successivo dopo lo script in errore.

Ogni tecnica di gestione degli errori richiede una logica del programma aggiunta allo script del test. Per quanto possibile, si consiglia di confinare la logica agli script di test di livello elevato che controllano la sequenza di script di test di livello inferiore. Ciò consente la creazione di script di test di livello inferiore unicamente dalla registrazione.

Pianificazione e sincronizzazione degli script di test

Quando si esegue una verifica della resistenza, generalmente è bene sincronizzare gli script di test in modo che inizino a orari predefiniti. E' possibile pianificare l'inizio di tali script confrontando l'ora di inizio desiderata con il tempo di sistema. In sistemi connessi in rete, ogni stazione di test condividerà, tramite la rete, lo stesso orologio. Nel seguente esempio, (da uno script scritto in BASIC) sono state inserite delle istruzioni all'inizio dello script per sospendere l'esecuzione dello script finché non viene raggiunta l'ora richiesta.

InputFile$ = "TIME.DAT"
Open InputFile$ For Input As 1
Input #1, StartTime$
Close #1
Do While TimeValue(StartTime$) > Time
   DoEvents
Loop

[Inizio script]

In questo esempio, l'ora di inizio richiesta è memorizzata in un file. Ciò consente la modifica di tale ora senza necessità di modificare lo script di test. L'ora viene letta e memorizzata in una variabile denominata StartTime$. Il loop Do While continua finché non viene raggiunta l'ora di inizio. L'istruzione DoEvents è importante, perché consente l'esecuzione delle attività di background mentre lo script di test è sospeso e in attesa di iniziare. Senza l'istruzione DoEvents, il sistema non risponderebbe finché non fosse raggiunta l'ora di inizio.

Verifica e debug degli script di test

Quando gli script di test registrati recentemente vengono eseguiti sullo stesso software su cui sono stati registrati, non dovrebbero verificarsi degli errori. L'ambiente e il software sono identici al momento in cui essi sono stati registrati. E' possibile che esistano delle istanze in cui lo script di test non viene eseguito correttamente. La verifica degli script di test non prevede tali scenari e consente la correzione degli script prima che questi vengano utilizzati in un test reale. In questa sezione vengono discussi due tipi di problemi comuni:

  • L'ambiguità nei metodi utilizzati per la selezione delle voci in un'interfaccia utente può fare in modo che gli script di test operino in modo differente durante la riproduzione. Ad esempio, è possibile che due voci riconosciute in base al testo (o didascalia) abbiano un testo identico. Vi sarà ambiguità durante l'esecuzione dello script.
  • I dati specifici di una sessione o esecuzione di un test vengono registrati (ad esempio, puntatore, data/ora o altri valori di dati generati dal sistema), ma sono differenti in caso di riproduzione.

Le differenze di sincronizzazione nella registrazione e nella riproduzione potrebbero portare dei problemi. La registrazione di uno script di test è essenzialmente un processo più lento rispetto all'esecuzione. Talvolta, questa differenza temporale dà come risultato un'esecuzione di script di test anticipata rispetto al software. In questi casi, è possibile inserire degli stati di attesa per rallentare lo script alla velocità del software.