Linee guida per smoke test

Articolo
09/12/2008

Aggiornamento: novembre 2007

Nel software, il termine "smoke test" (test di integrità funzionale) descrive il processo di convalida delle modifiche del codice prima che venga effettuata la verifica di tali modifiche nella struttura sorgente del prodotto. Una volta terminate le verifiche, lo smoke test è il metodo più conveniente per l'identificazione e la risoluzione dei difetti presenti nel software. Gli smoke test sono stati progettati per confermare che le modifiche nel codice funzionano come stabilito e non destabilizzano l'intera build.

Nota:
Il termine smoke test trae le sue origini dal settore dell'hardware. Il termine nasce dalla pratica seguente: una volta che un componente hardware era stato cambiato o aggiustato, la macchina veniva semplicamente accesa. Se dalla macchina non usciva fumo, il test del componente era stato superato.

Di seguito sono riportati alcuni suggerimenti per l'esecuzione degli smoke test. Grazie a tali indicazioni si otterranno risultati diversi: da una migliore comunicazione fra i membri del team fino allo sviluppo di nuove modalità di utilizzo degli strumenti di test e debug.

Collaborare con lo sviluppatore

Poiché gli smoke test si focalizzano sul codice che è stato modificato, è necessario collaborare con lo sviluppatore del codice. È indispensabile capire:

Cosa è cambiato nel codice. Per capire che cosa è cambiato bisogna conoscere la tecnologia che è stata utilizzata e a tal proposito lo sviluppatore può essere di grande aiuto.
Il modo in cui le modifiche hanno effetto sulla funzionalità.
Il modo in cui le modifiche hanno effetto sulle interdipendenze fra i vari componenti.

Effettuare una verifica del codice prima di procedere allo smoke test

Prima di procedere allo smoke test, è necessario eseguire una verifica del codice al fine di rilevare tutte le modifiche presenti. La verifica del codice costituisce il metodo più efficace che consente di convalidare la qualità del codice e garantire l'assenza di difetti ed errori. Grazie agli smoke test, la prima area critica identificata durante la verifica del codice e la valutazione dei rischi deve essere convalidata poiché se non dovesse superare il test, la procedura non potrebbe continuare.

Installare file binari privati in una build di debug in un ambiente di test pulito

Poiché lo scopo degli smoke test è quello di convalidare solo le modifiche funzionali nei file binari aggiornati, i test devono essere eseguiti in un ambiente pulito, vale a dire nei file binari di debug dei file sottoposti al test.

Nota:
Il test effettuato con file binari non corrispondenti è un errore ricorrente. Per ovviare a questo errore, quando è presente una dipendenza fra due o più file binari aggiornati includere tutti i file binari aggiornati nella build del test. In caso contrario il risultato del test potrebbe non essere valido.

Creare build giornaliere

Per ottenere build giornaliere è necessario che i membri del team collaborino fra loro e incoraggino gli sviluppatori a rimanere sincronizzati. Se le iterazioni delle nuove build vengono ritardate, i prodotti con più dipendenze potrebbero non essere più in sincronia. Per ottenere un livello di qualità elevato è necessario produrre build giornaliere ed effettuare uno smoke test per ogni parte modificata e per ogni file binario aggiunto.

Per ulteriori informazioni sull'impostazione di build ricorrenti vedere Esecuzione delle generazioni in Team Foundation Build. Per ulteriori informazioni sulla verifica delle build di un prodotto vedere Procedura: configurare ed eseguire test di verifica delle generazioni (BVT).

Nota:
Fare in modo che la priorità assoluta del team sia la creazione di una build giornaliera di qualità Se la build non è funzionante a causa di un nuovo codice sul quale non è stato effettuato alcuno smoke test, chiedere allo sviluppatore e al tester di interrompere il lavoro fin tanto che il problema non viene risolto. La punizione per aver danneggiato la build non deve essere severa, ma è necessario enfatizzare l'importanza di una build giornaliera funzionante come priorità assoluta del team.

Fare in modo che la priorità assoluta del team sia la creazione di una build giornaliera di qualità Se la build non è funzionante a causa di un nuovo codice sul quale non è stato effettuato alcuno smoke test, chiedere allo sviluppatore e al tester di interrompere il lavoro fin tanto che il problema non viene risolto. La punizione per aver danneggiato la build non deve essere severa, ma è necessario enfatizzare l'importanza di una build giornaliera funzionante come priorità assoluta del team.

Non è necessario effettuare test esaustivi. Lo scopo dello smoke test non è quello di assicurare che il file binario sia al 100% esente da errori poiché richiedere troppo tempo. Gli smoke test servono a convalidare la build ad un livello elevato. Basterà quindi garantire che le modifiche apportate nel file binario non destabilizzano la build nel suo insieme né causano errori catastrofici di funzionalità.

Test Web e test di carico

Quando si creano i test Web e i test di carico, è consigliabile eseguire uno smoke test prima di procedere ad altri test più lunghi e appronditi. Nei test Web e di carico, lo smoke test è breve e superficiale. Esso serve a garantire che tutto sia correttamente configurato e funzionante prima di procedere ai test delle prestazioni e ai test di stress.