Test tempestivi e frequenti
L'individuazione di problemi quanto prima possibile rappresenta il metodo meno costoso per garantire la qualità del software. Kent Beck e Cynthia Andrés hanno affermato che il dilemma dello sviluppo di software sono i difetti e il relativo costo che ne deriva, anche in termini di risorse impiegate per eliminarli. Tuttavia, la maggior parte dei difetti finiscono per costare più di quanto non sarebbe costato prevenirli. Per ulteriori informazioni, vedere le informazioni sulla pubblicazione Extreme Programming Explained: Embrace Change relativa alla programmazione estrema. Procedure consigliate e strumenti consentono al team di ridurre i costi correlati alla prevenzione e alla correzione dei problemi, garantendo la qualità del progetto durante tutto il ciclo di vita.
In qualsiasi momento il team può misurare con maggiore precisione la qualità del progetto in caso di individuazione di errori, correzione di errori o verifica delle correzioni. Testando spesso il progetto, il team e le parti interessate possono restare informati sullo stato corrente del codice e adottare decisioni consapevoli durante tutto il progetto. Infine, è necessario essere in grado di sapere se il prodotto è idoneo al rilascio e comprendere le implicazioni per le persone che utilizzano il software.
In questo argomento vengono consigliate le procedure seguenti:
Creare un set di unit test automatizzati per ogni classe e per l'API di ogni componente principale. La scrittura di unit test deve occupare all'incirca il 40% del tempo dei membri del team. Per ulteriori informazioni, vedere Creazione di test automatizzati.
Creare test per ogni storia utente. È consigliabile che tali test siano automatizzati. Per ulteriori informazioni, vedere Creazione di un piano di test utilizzando i requisiti o le storie utente.
Creare criteri di archiviazione per ricordare ai membri del team di eseguire unit test prima di archiviare il codice. Per ulteriori informazioni, vedere Aggiungere criteri di archiviazione.
Configurare una compilazione continua o notturna per l'esecuzione del set completo di test.
Monitorare il code coverage dei test per garantire che venga testato tutto il codice. Definire un code coverage almeno del 70%. Per ulteriori informazioni, vedere Rapporto Excel sui Gap del test (Agile).
Eseguire test manuali verso la fine di ogni sprint.
Il team può gestire e scalare tali attività di test nelle fasi iniziali del progetto utilizzando l'integrazione tra Microsoft Test Manager, Visual Studio Application Lifecycle Management (ALM) e Visual Studio Team Foundation Server. Per ulteriori informazioni, vedere Test dell'applicazione.
In questo argomento
Strategia dei test
Pianificazione dei test
Test di accettazione
Unit test
Sviluppo basato su test e test tempestivi
Confronto tra test manuali e automatizzati
Creazione di rapporti per i risultati dei test
Strategia dei test
Il successo del team relativamente ai test dipende da diversi fattori, ad esempio la dimensione, i metodi e gli strumenti di gestione del team. È possibile utilizzare metodi Agile per continuare a migliorare i risultati dei test. Applicando questa metodologia, non solo è possibile avviare i test con risorse molto limitate, ma si possono anche adattare le procedure alle proprie esigenze durante tutto il progetto.
Aspetti da considerare nell'introdurre test Agile
Nell'introdurre test Agile in un'applicazione esistente, il team può iniziare definendo la strategia di test sia a livello di sprint sia a livello di progetto. A livello di sprint, è possibile includere un set di test di accettazione per analizzare ogni storia utente dello sprint corrente. A livello di progetto, è possibile eseguire test che interessano tutto il progetto, ad esempio il test completo. Ciò si rivela utile se si desidera verificare la funzionalità che si estende su due o più sprint. È possibile creare qualsiasi tipo di test mentre il team compila il codice durante uno sprint. Questi test includono gli unit test, i test di accettazione e i test non funzionali, ad esempio i test delle prestazioni, di sicurezza e di usabilità.
Per applicare le metodologie di test Agile, è necessario innanzitutto considerare la cronologia dell'applicazione e il sistema utilizzato dal team. Le metodologie di test Agile possono essere utilizzate sia per le applicazioni nuove sia per quelle esistenti. È possibile utilizzare Microsoft Test Manager per creare un piano di test per tutto il progetto e un piano di test per ogni sprint del progetto. Questi piani di test consentono al team di organizzare i test case in gruppi di test che permettono di classificare in ordine di priorità i test in esecuzione e di capire i risultati dei test. Per ulteriori informazioni, vedere Creazione di un piano di test utilizzando i requisiti o le storie utente. Il team può utilizzare ALM di Visual Studio per raggruppare i test case in gruppi di test tramite diversi metodi:
Creazione e gestione di un gruppo statico di test case.
Utilizzo di una query per creare e gestire un gruppo dinamico di test case (ovvero individuare i test case in base alla priorità).
Aggiunta di una storia utente o di un requisito in un piano di test in cui i test case dispongono di un collegamento al requisito.
Copia di un gruppo di test esistente da un altro piano di test.
Per ulteriori informazioni, vedere Organizzazione di test case mediante gruppi di test.
In secondo luogo, è necessario considerare la testabilità del codice. Per conoscerla, è necessario capire l'architettura e i modelli dell'applicazione. Se si utilizzano modelli quali Model View Controller (MVC), Model View ViewModel (MVVM) o Model View Presenter (MVP), è possibile isolare alcune funzioni ed eseguire test funzionali senza l'impatto negativo del test dell'interfaccia utente. Tuttavia, ciò non corrisponde sempre alla realtà. Ad esempio, non è possibile isolare la funzionalità per le parti di refactoring dell'applicazione ed alcune aree del codice possono essere raggiunte solo tramite l'interfaccia utente o i gestori eventi della rete. Se si desidera migliorare in modo significativo la qualità dei test, è necessario aumentare la percentuale di codice testabile. Per ulteriori informazioni su questi modelli, vedere MVC ASP.NET 2.
In terzo luogo, è necessario considerare le capacità del team prima di implementare i test Agile. Alcuni membri del team devono essere in grado di creare unit test quando si implementano le funzionalità. Altri devono essere in grado di creare e definire casi di utilizzo manuali e test del flusso di lavoro se hanno familiarità con le regole business dell'applicazione. Altri ancora devono essere in grado di creare test automatizzati e più dettagliati, basati su questi test manuali, se dispongono delle competenze tecniche necessarie.
Come gestire il ciclo di vita dei test
Un test è un processo iterativo durante tutto il progetto. Fare riferimento ai passaggi seguenti:
Definire obiettivi precisi per i test e assicurarsi che siano approvati dall'intero team. In base a questi obiettivi, determinare la strategia dei test. La strategia, ad esempio, potrebbe prevedere l'esecuzione dei test prima di ogni archiviazione, un code coverage del 70% per gli unit test e almeno un test automatizzato per ogni storia utente.
Definire il piano di test in base alle storie utente del progetto, alle ipotesi di progettazione e ai requisiti non funzionali nello sprint corrente.
- È possibile aggiungere storie utente al backlog e pianificarle per gli sprint futuri. È necessario associare ogni piano di test ad almeno uno sprint e, pertanto, disporre di test case per tutte le storie utente dello sprint.
Definire e compilare test case, ad esempio test di accettazione, unit test, test funzionali e test delle prestazioni.
Raggruppare i test case in gruppi di test. È possibile adattare questi gruppi di test ai piani di test definiti che consentono di condurre l'attività di test.
Eseguire ripetutamente i gruppi di test e i test case contenuti durante tutto lo sprint. Iniziare a eseguire test all'inizio di uno sprint e continuare ad aggiungere test case ai gruppi di test. Se si desidera identificare le condizioni e le situazioni importanti relative ai test, è possibile applicare il testing esplorativo e pianificare incontri frequenti a livello di team.
Assicurarsi che tutti i test di accettazione per una storia utente siano stati superati prima di impostarne lo stato su completo.
.png "Ciclo di vita dei test iterativo")
Anche se il flusso di lavoro può essere maggiormente complesso a seconda della suddivisione del software, nell'illustrazione precedente è mostrata l'essenza di un flusso di lavoro tra i componenti principali.
Il codice genera compilazioni.
Il codice viene influenzato dal lavoro definito, dai piani di test e dalla qualità delle compilazioni.
I piani di test, i gruppi di test e i test case vengono influenzati dagli obiettivi pianificati e da altri aspetti del progetto non mostrati in questa illustrazione.
Le modifiche apportate al codice possono influire sui test case.
Correzione di bug
È necessario gestire i bug il più presto possibile. Un bug grave indica che le storie utente su cui influisce non sono state completate.
Creare elementi di lavoro bug per i bug individuati durante i test o altre attività. Impostare la gravità del bug per indicarne il grado di influenza sulle storie utente. Una gravità elevata, ad esempio 0 o 1, indica che importanti storie utente non vengono implementate o che gli utenti devono eseguire soluzioni alternative significative per realizzare la storia. Una gravità bassa, ad esempio 3, indica che gli utenti possono ancora realizzare gli obiettivi principali senza attività aggiuntive.
Collaborare con gli altri membri del team per definire un piano di azione per ogni bug.
Risolvere i bug non appena vengono corretti. È consigliabile assegnare il bug a un altro utente per la verifica. Verificare e chiudere i bug non appena possibile.
Tenere traccia dello stato dei bug. Nella riunione retrospettiva alla fine di ogni iterazione esaminare il rapporto Tendenze del bug e discutere le cause di ogni aumento anomalo. Per ulteriori informazioni, vedere Rapporto Tendenze del bug.
Pianificazione dei test
La pianificazione dei test consente al team di capire l'idea principale del progetto e di prepararsi per qualsiasi tipo di test. Il test Agile inizia a livello di sprint. In ogni sprint il team crea test per verificare le storie utente compilate nello sprint. Il team esegue i test creati sia nello sprint corrente sia in quelli precedenti. Durante il progetto viene creato un numero elevato di test per analizzare tutte le funzionalità. Nell'immagine seguente è illustrato un modello di piano di test nel progetto.
.png "Piano di test master")
Creare un piano di test per ogni sprint e per il progetto
Tramite le funzionalità di test di ALM di Visual Studio, il team può pianificare, organizzare, eseguire e creare un rapporto sui test in modo incrementale. Il team può creare un modello per i piani di test e i membri del team possono compilare i gruppi di test. In un piano di test, il team può identificare i casi in cui è necessario utilizzare test case automatizzati o manuali.
Per ogni sprint del progetto, è possibile iniziare a creare un piano di test. Tramite questo piano, il team può concentrarsi sulla verifica della funzionalità nello sprint corrente. Anche se, inizialmente, il piano è vuoto, è possibile utilizzarlo come segnaposto per i gruppi di test. Successivamente è possibile organizzare i test case in gruppi di test appropriati. Questi test case devono essere creati tempestivamente e durante tutto lo sprint, se si desidera ottenere un feedback tempestivo dalle parti interessate del progetto.
È possibile inoltre creare un piano di test che riguarda tutto il progetto. I piani di test del progetto possono essere utilizzati per unire i test degli sprint precedenti e organizzare gruppi di test che si applicano a tutto il progetto. È necessario continuare a eseguire gruppi di test di regressione poiché è importante mantenere la stabilità e il flusso quando il team compila progetti di ampie dimensioni. In particolare, se si lavora con team di ampie dimensioni, distribuiti e distanti tra loro, i gruppi di test di regressione possono rilevare gli errori basati sulle modifiche che causano impatti a catena. Senza misure appropriate, questi errori sono molto difficili da rilevare e possono essere individuati tardi nel ciclo o dopo il recapito.
Alcuni team potrebbero voler definire un piano di test che si estende su tutto il progetto. Questi tipi di piani di test possono verificare la funzionalità correlata in alcuni sprint e contenere gruppi di test che vengono eseguiti in tutto il progetto. Ad esempio, è possibile testare una funzionalità che si estende sulle storie utente negli sprint solo quando è completa l'intera funzionalità.
Definire i test di accettazione prima di uno sprint
Prima di uno sprint è necessario definire i test di accettazione che possono consentire di determinare se una storia utente è completa. È possibile tenere traccia dei test case di accettazione se, per ogni sprint, si crea un gruppo di test denominato Test di accettazione in un piano di test. Per ulteriori informazioni, vedere Test di accettazione più avanti in questo argomento.
Compilare unit test durante uno sprint
Durante uno sprint il team deve compilare gli unit test che possono verificare le prestazioni del codice, ad esempio il tempo e le risorse utilizzati per eseguire il codice. Altri tipi di test, quali i test non funzionali (ovvero i test delle prestazioni e di sicurezza) devono essere compilati e aggiunti ai gruppi di test appropriati. Questi gruppi di test devono essere organizzati in modo da poter calcolare facilmente il costo.
Concentrare i test in aree di utilizzo elevato
Una volta individuato il punto di maggior variabilità nel software è possibile stabilire le aree sensibili. L'input dell'utente, l'ambiente in cui viene eseguito il software, la rete e l'hardware sono esempi di variabili di configurazione che consentono al team di individuare le aree sensibili nel software. Se una condizione si verifica raramente oppure durante un test si presentano alcune condizioni complesse, il valore del test diminuisce a meno che l'impatto potenziale di un difetto sia molto elevato. In generale, è consigliabile isolare la funzionalità, se possibile. Anche il test di situazioni a impatto elevato è importante. Per ulteriori informazioni su come gestire le configurazioni tramite Microsoft Test Manager, vedere Definizione della matrice di test utilizzando configurazioni di test.
Per i progetti esistenti, monitorare le aree che presentano il maggior numero di difetti e stabilirne la causa. Monitorare anche la varianza del codice poiché questa area potrebbe ignorare i presupposti sottostanti. Tra la cause dei difetti del codice vi è la difficoltà di gestione degli stati (ad esempio rete e interfaccia utente), ma anche del codice.
Separare i test per l'elaborazione e l'archiviazione di dati
Generalmente, il codice che utilizza un database separa l'elaborazione di dati dall'archiviazione. L'elaborazione di dati può essere testata eseguendo unit test, mentre l'archivio dati direttamente a livello di database. Visual Studio Test Professional 2010 fornisce la funzionalità per testare le stored procedure del database. Questi test devono essere organizzati nel relativo gruppo. Per ulteriori informazioni, vedere Creazione e definizione di unit test del database.
Microsoft Test Manager può essere utilizzato per creare snapshot di immagini del computer che possono essere sfruttati per ripristinare uno stato noto dopo aver eseguito test che dipendono dai dati (o da qualche altro aspetto dello stato). Questi test sono molto importanti e generalmente richiedono molto tempo.
Test di accettazione
I test di accettazione verificano le storie utente. Tali test non solo possono assicurare la corretta compilazione di quanto richiesto dai clienti durante tutto il ciclo di vita del progetto, ma generano anche fiducia nei clienti e indicano le responsabilità accettate. Per ulteriori informazioni, vedere la seguente guida Acceptance Test Engineering Guide relativa alla progettazione di test di accettazione.
Come iniziare con i test di accettazione
Aprire Microsoft Test Manager, quindi, nel piano di test, creare un gruppo di test denominato Test di accettazione. Il team deve disporre di almeno un gruppo di test che raggruppi i test di accettazione per ogni sprint. Per ulteriori informazioni, vedere Definizione dell'attività di test utilizzando piani di test.
Eseguire la migrazione da test manuali a test automatizzati
I test manuali sono più facili da definire rispetto ai test automatizzati, ma più costosi da eseguire. Una buona strategia, pertanto, consiste nell'iniziare con test manuali e sostituire gradualmente quelli più importanti con test automatizzati.
Innanzitutto, iniziare a compilare un set di test case manuali che verifichi ogni storia utente definita per lo sprint. Poiché non è presente codice all'inizio di uno sprint, un test case deve delineare le azioni di livello elevato che mappano alle parti di una storia utente. Ad esempio, un passaggio di un test case potrebbe essere "In qualità di utente autenticato, eseguire...". Iniziare con un test case manuale consente al team di definire rapidamente i test di accettazione ideali prima dell'avvio di uno sprint.
In secondo luogo, revisionare e aggiornare i test di accettazione per riflettere specifiche esperienze dell'utente quando il team dispone del codice che implementa le storie utente di uno sprint. Tuttavia, se il team non desidera modificare il set esistente di test di accettazione, è possibile importare i test in un nuovo gruppo e disporre di un punto di partenza per test più dettagliati. Ad esempio, un passaggio di un test case più dettagliato potrebbe essere "Digitare il nome nella casella di testo Nome utente e fare clic sul pulsante Accesso per accedere al conto bancario".
Infine, in base ai test di accettazione, creare test codificati dell'interfaccia utente (UI) tramite la registrazione delle azioni. Per ulteriori informazioni, vedere Procedura: generare un test codificato dell'interfaccia utente da una registrazione delle azioni. I test codificati dell'interfaccia utente possono generare codice se si creano passaggi che isolano la funzionalità. È possibile eseguire test automatizzati dal piano di test se si associa il test codificato dell'interfaccia utente ai test case manuali (per ulteriori informazioni, vedere Procedura: associare un test automatizzato a un test case).
I test manuali definiti all'inizio di uno sprint possono consentire di creare test automatizzati. Sia i test manuali sia quelli automatizzati implicano un costo poiché i test manuali devono essere eseguiti da una persona e quelli automatizzati devono essere aggiornati se il codice o l'esperienza dell'utente cambia. Per ulteriori informazioni, vedere la sezione Confronto tra test manuali e automatizzati più avanti in questo argomento.
Esecutori dei test case di accettazione
I test case di accettazione possono essere eseguiti dal team, dal proprietario del prodotto e dai clienti. Il team deve eseguirli il più spesso possibile per fornire una linea di base relativa al set di test che deve passare uno sprint. Anche il proprietario del prodotto e il cliente possono eseguire i test di accettazione e richiedere una verifica per completare correttamente lo sprint.
Il team può utilizzare Microsoft Test Manager per eseguire ogni test case di accettazione e registrare un'acquisizione a video dei risultati dei test. In questo modo, è possibile ottenere un record visivo dei risultati dei test e anche condividere i risultati con i clienti. Tale soluzione è utile quando risulta difficile creare le configurazioni obbligatorie (ad esempio le configurazioni multiserver).
Definire test case di accettazione insieme alle storie utente
I criteri di accettazione possono essere definiti subito dopo la definizione delle storie utente. Definendo i test di accettazione, è possibile consentire al team di capire i criteri di accettazione per lo sprint corrente del proprietario del prodotto e dei clienti. Poiché il cliente deve accettare i test di accettazione, è consigliabile creare i test case di accettazione prima dell'avvio dello sprint.
Unit test
Gli unit test sono test automatizzati che verificano la funzionalità a livello di componente, classe, metodo o proprietà. Gli unit test costituiscono la base dei test automatizzati e di regressione e garantiscono stabilità a lungo termine e manutenibilità futura del progetto.
Intervento degli unit test nello sviluppo della progettazione dell'applicazione
Il processo di creazione di unit test durante la compilazione del codice testato consente di definire la forma del codice. È possibile creare codice testabile utilizzando unit test. Se la creazione di unit test per il codice risulta difficile, il codice deve essere sottoposto a refactoring.
Organizzazione degli unit test
Ogni membro del team che scrive codice deve creare unit test per i componenti compilati e verificare il codice degli unit test nel controllo della versione all'interno di un progetto Visual Studio. Archiviare gli elementi di lavoro test case in un gruppo di test di verifica della compilazione che sarà eseguito durante ogni compilazione tramite l'integrazione continuata, nonché nel gruppo di test che verifica la storia utente corrispondente.
Gestione della varianza di unit test senza apportare modifiche al codice del test
La varianza negli input di test definisce gli aspetti simili o differenti tra i test poiché verifica la funzionalità nel codice del progetto. Nel testare, ad esempio, il componente di accesso di un'applicazione Web, è possibile fornire diversi tipi di password per creare un account utente. Il sistema potrebbe disporre di regole inerenti l'ordine e la combinazione dei tipi di carattere utilizzati.
Visual Studio Test Professional 2010 fornisce le funzionalità per scrivere unit test basati su dati e test codificati dell'interfaccia utente. Per ulteriori informazioni, vedere Procedura: creare uno unit test basato sui dati e Procedura: creare un test codificato dell'interfaccia utente basato sui dati.
Sviluppo basato su test e test tempestivi
Lo sviluppo basato su test (TDD, Test-driven development) è una disciplina di progettazione e programmazione in cui ogni riga di codice viene scritta in risposta a un test scritto dal programmatore poco prima della codifica. L'idea di diventare l'utente del codice che si desidera implementare è molto utile e consente di mantenere un'aspettativa realistica della modalità di utilizzo e progettazione del codice.
In TDD lo sviluppatore procede in base a molti piccoli incrementi. Lo sviluppo di ogni piccolo incremento richiede da pochi minuti ad alcune ore. Molti incrementi di questo tipo costituiscono in genere una storia utente. Lo sviluppatore archivia i test e il codice quando la storia utente funziona. Lo sviluppatore procede in base al ciclo seguente:
Scrittura di un test automatizzato di cui è previsto il superamento quando viene scritto l'incremento.
Verifica del mancato superamento del nuovo test per accertare il funzionamento del test.
Scrittura del codice per il superamento del test.
Esecuzione del test per verificarne il superamento.
Esecuzione anche di altri test nella stessa area per verificare che non siano stati introdotti bug.
Refactoring del codice, se necessario, per migliorarne la struttura senza aggiungere comportamento. Riesecuzione dei test per verificare che il codice funzioni ancora.
Ripetizione di tutti questi passaggi fino all'implementazione di una storia utente completa. Poiché gli incrementi precedenti vengono integrati in una storia completa, aggiungere test che consentano di verificare l'intera storia.
Archiviazione del codice di implementazione e degli unit test.
Se si desidera sfruttare i vantaggi dei metodi di test meno recenti, è possibile iniziare creando test manuali (o test di accettazione manuali). Tali test manuali possono essere automatizzati creando un test codificato dell'interfaccia utente. Per ulteriori informazioni, vedere Procedura: generare un test codificato dell'interfaccia utente registrando l'applicazione sottoposta a test. I test di integrazione che utilizzano il framework degli unit test in ALM di Visual Studio possono essere creati anche per verificare la funzionalità in fase di implementazione. I gruppi di test case creati tempestivamente nell'iterazione vengono eseguiti altrettanto presto per tentare sia di verificare la funzionalità sia di individuare eventuali bug. Questi gruppi di test e i test case possono essere eseguiti continuamente come test di regressione durante tutta la vita del progetto. Continuando a eseguire questi test, è possibile assicurarsi che i bug individuati e la funzionalità verificata tempestivamente nell'iterazione non siano interessati da modifiche successive del progetto.
Utilizzare unit test per l'integrazione continuata
Gli unit test creati utilizzando il metodo di test preventivi devono essere organizzati all'interno del gruppo di test per lo sprint corrente e la storia utente. Questi unit test possono essere promossi al piano di test a livello di progetto ed eseguiti periodicamente dal team e nel ciclo di integrazione continuata. Gli unit test possono servire anche come base per l'integrazione, il caricamento e il test delle prestazioni.
Gli unit test creati all'inizio possono essere utilizzati come parte dell'integrazione continuata. Per ulteriori informazioni su come eseguire i test durante una compilazione, vedere Attività TestToolsTask.
Utilizzare la virtualizzazione per gestire le configurazioni di test
Per eseguire gli unit test, è possibile creare un set di ambienti gestiti corrispondenti a immagini Hyper-V in Microsoft Test Manager. Per ulteriori informazioni sull'esecuzione di test automatizzati da un piano di test mediante Microsoft Test Manager, vedere Attività TestToolsTask.
Confronto tra test manuali e automatizzati
I test case automatizzati e quelli manuali sono complementari. I team Agile si impegnano per disporre di un numero maggiore di test case automatizzati poiché promuovono esecuzioni di test frequenti o continue. Ai fini di un'esecuzione continuativa, i test devono essere eseguiti rapidamente e frequentemente, un comportamento difficile da realizzare con i test manuali.
Quando si deve prendere una decisione relativamente a una distribuzione di test case manuali e automatizzati è opportuno fare diverse considerazioni.
Influenza delle capacità presenti all'interno dell'organizzazione sulla distribuzione dei tipi di test
Il proprietario del prodotto aiuta a definire le storie utente per il progetto e deve inoltre collaborare alla creazione dei test di accettazione. Il proprietario del prodotto probabilmente non produce test codificati ma conosce molto bene il dominio aziendale. I test case definiti dal proprietario del prodotto riguarderanno, pertanto, il vocabolario aziendale e le regole business. Ad esempio, un proprietario del prodotto di una società di spedizioni specificherà diversi mezzi di trasporto supportati dalle aziende (ad esempio autocarro, treno, aereo, nave o una combinazione). Il proprietario del prodotto può quindi definire diversi test case che verificano le differenti possibilità. Per questi test manuali, è importante specificare il numero minimo di test che verificano le diverse opzioni (in questo caso i mezzi di spedizione).
I membri del team che producono codice possono compilare i test codificati dell'interfaccia utente che possono essere basati sui test manuali oppure indipendenti da qualsiasi altro test. Per ulteriori informazioni, vedere How to: Generate a Coded UI Test by Recording the Application Under Test. I test codificati dell'interfaccia utente devono essere supportati dai membri del team in grado di gestire e sviluppare codice del progetto.
Conversione da test manuali a test automatizzati o creazione iniziale di test automatizzati
È possibile compilare test automatizzati quando si prevede di eseguire ripetutamente test per mantenere la stabilità del codice. È importante considerare l'impegno richiesto dalla creazione di test automatizzati, in quanto l'investimento dell'automazione influisce sulle risorse del team. La creazione di test automatizzati quando la varianza del codice è minima comporta un maggiore ritorno sugli investimenti (ROI) poiché la varianza dei test è inferiore. Tuttavia, creando tempestivamente l'automazione è possibile individuare i problemi sia nella logica sia nella progettazione. In entrambi i casi, è necessario considerare le risorse richieste per supportare il codice dei test automatizzati.
Dopo aver stabilito che un set di test deve essere automatizzato, completare l'automazione il più rapidamente possibile, in quanto i vantaggi dell'automazione includono la gestione della stabilità del codice. La stabilità e il numero di difetti individuati quando l'automazione viene scritta influiranno sull'impegno richiesto per completare l'automazione. Infine, l'equilibrio tra test manuali e automatizzati riguarda la definizione di priorità per i tipi di test che devono essere compilati ed eseguiti durante la vita del progetto.
Tipi di test automatizzati
Unit test
Gli unit test verificano la funzionalità nel codice o in un processo quale TDD. Gli unit test sono importanti poiché consentono di gestire la stabilità e le dipendenze nel codice. TDD tende inoltre a garantire una migliore progettazione con dipendenze e una buona definizione del livello, in quanto semplifica la comprensione della progettazione dal punto di vista dell'utente del codice.
Test di carico
È possibile creare test di carico basati su test case automatizzati esistenti oppure creare test che generano tipi specifici di carichi in applicazioni o servizi. Per ulteriori informazioni su come utilizzare i controller di agenti di test e gli agenti di test per generare test di carico simulati, vedere Procedura: eseguire un test mediante controller e agenti di test.
Per ulteriori informazioni sui test di carico con ALM di Visual Studio, vedere la pagina seguente nel sito Web Microsoft: Informazioni sui test di carico.
Test di integrazione continuata
È possibile utilizzare l'integrazione continuata con ALM di Visual Studio per garantire che ogni qualvolta venga sviluppato e archiviato codice, questo funzioni correttamente con il codice esistente. L'integrazione continuata è essenziale quando il team e la codebase si ampliano. È possibile definire un tipo di compilazione che includa parametri di test e specificare i test da eseguire al termine della compilazione. Per ulteriori informazioni su come definire una compilazione che esegue test, vedere Definire una compilazione utilizzando il modello predefinito.
Tipi di test automatizzabili
Test delle configurazioni
L'esecuzione di test in più ambienti installati può risultare molto laboriosa. Microsoft Test Manager consente di eseguire gruppi di test in diverse configurazioni tramite macchine virtuali o computer fisici. Per ulteriori informazioni su come eseguire i test e raccogliere i dati in più ambienti, vedere Configurazione di computer di test per l'esecuzione di test o la raccolta di dati.
Test dell'interfaccia utente
ALM di Visual Studio consente di creare test automatizzati direttamente per l'interfaccia utente. Per ulteriori informazioni su come creare test codificati dell'interfaccia utente, vedere Procedura: creare un test codificato dell'interfaccia utente.
Test dell'installazione
Utilizzare le funzionalità lab di Microsoft Test Manager per configurare un gruppo di configurazioni da utilizzare per verificare se i programmi di installazione per le applicazioni funzionano nel modo previsto.
Ostacoli all'automazione
Funzionalità del team
La creazione dell'automazione richiede a un gruppo del team di test di imparare a scrivere codice. Pianificare la necessità di sostenere la curva di apprendimento della creazione dell'automazione e la progettazione del codice di test. Come per il codice di produzione, progettare il codice di automazione in base agli obiettivi desiderati, ad esempio la manutenibilità, la facilità di composizione e la durata.
Per ulteriori informazioni su come creare test automatizzati tramite Visual Studio Test Professional 2010, vedere Creazione di test automatizzati.
Varianza del codice
Un codice che cambia frequentemente è una destinazione mobile e avrà effetti a catena sul codice di automazione dei test dal momento che dovrà essere a sua volta modificato. Evitare questi effetti a catena creando il codice di automazione dei test per i componenti e le interfacce che hanno meno probabilità di cambiare.
Progettazione del codice
I framework per il codice, ad esempio ASP.NET MVC e MVVM, consentono ai membri del team di scrivere codice dotato dell'isolamento richiesto per verificare le diverse parti del codice. Il codice strettamente associato all'interfaccia utente è difficile da testare poiché può richiedere all'utente di interagire con i controlli dell'interfaccia utente.
Vantaggi dei test case manuali
I test case manuali assicurano i vantaggi seguenti:
I test manuali consentono al team di individuare i bug nel processo di esplorazione.
La definizione dei test case manuali è semplice poiché è possibile definire il set di passaggi a un qualsiasi livello di astrazione, nonché stabilire risultati positivi e negativi nel modo preferito.
È molto facile cominciare a scrivere i test case manuali all'inizio del progetto, ovvero prima che venga scritto qualsiasi codice. Tale operazione è importante durante il processo di definizione dei test di accettazione.
Se si utilizza Visual Studio Test Professional 2010, i test case possono essere costituiti da passi condivisi che assicurano un risparmio di tempo nella definizione di test simili e che consentono al team di riutilizzare una singola versione di un subset del test. L'utilizzo di passi condivisi rappresenta un supporto utile anche quando si modificano i test case poiché una modifica ai passi condivisi cambia automaticamente tutti i test case che li utilizzano. Per ulteriori informazioni su come creare e utilizzare i passi condivisi, vedere How to: Share Common Test Case Steps Using Shared Steps.
I test case manuali possono fungere da mezzo di comunicazione nel progetto o nello sprint.
I test case manuali possono fungere da mezzo di documentazione di un test case automatizzato senza che il codice debba essere esaminato da altri utenti.
Se si utilizza ALM di Visual Studio, l'esecuzione di test manuali può raccogliere metrica di code coverage.
Svantaggi dei test case manuali
I test case manuali presentano gli svantaggi seguenti:
La definizione di criteri di successo può essere complicata poiché dipende dalla prospettiva e dal linguaggio utilizzato nella definizione del test. Alcuni linguaggi possono essere interpretati in modi diversi, pertanto si possono verificare degli equivoci.
L'esecuzione di gruppi di test che includono test case manuali richiede che una persona segua fisicamente i passi dei test e generi un rapporto relativo ai risultati. Questo processo può richiedere molto tempo, pertanto potrebbe essere necessario un numero elevato di membri del team per eseguire i test oppure più tempo per eseguire il gruppo di test. Tramite Visual Studio Test Professional 2010, il team può sfruttare il "test manuale ad avanzamento rapido", in cui le azioni vengono registrate durante il test, che può poi essere utilizzato per le esecuzioni future di test.
Il tempo e l'impegno richiesti per eseguire i test varieranno a seconda della stabilità del codice. Di conseguenza, l'esecuzione di test manuali può influire sul flusso del team.
Lo svantaggio maggiore consiste nel fatto che i test manuali sono inclini a errori umani relativamente al rilevamento di bug. I tester possono trovarsi di fronte al bug senza però riconoscerlo.
Vantaggi dei test case automatizzati
I test case automatizzati assicurano i vantaggi seguenti:
I test automatizzati consentono di gestire la stabilità e di individuare le regressioni che si potrebbero verificare a causa delle modifiche del codice.
I test automatizzati possono essere eseguiti in modo automatico.
I test automatizzati sono software e possono essere progettati e costituiti da altro codice riutilizzabile, pertanto risultano flessibili e gestibili.
L'automazione può essere eseguita su più configurazioni tramite Microsoft Test Manager.
Quando vengono eseguiti i test automatizzati è possibile raccogliere la metrica di code coverage.
Svantaggi dei test case automatizzati
I test case automatizzati presentano gli svantaggi seguenti:
Le condizioni speciali devono essere considerate e implementate utilizzando il codice. Durante la creazione e l'esecuzione dell'automazione, le eventuali condizioni aggiuntive individuate verranno subito implementate.
Quando il codice viene modificato o sottoposto a refactoring, si possono verificare degli effetti a catena che richiederanno un impegno appropriato per modificare i test automatizzati interessati.
Vi può essere un impatto psicologico sul team quando le modifiche al codice impediscono il superamento di numerosi test. Se questi test vengono utilizzati come flag, il team potrebbe non voler generare i flag.
Si potrebbe percepire una falsa sensazione di sicurezza quando tutti i test vengono superati, qualora i test case non stiano verificando le condizioni corrette. È importante gestire i gruppi di test e assicurarsi che verifichino le condizioni e i risultati corretti.
Creazione di rapporti per i risultati dei test
Da una prospettiva Agile, la creazione di rapporti e l'esecuzione di query su Team Foundation Server relativamente allo stato corrente della qualità, in base a bug o metrica di aggregazione, costituiscono la parte del ciclo di feedback che consente al team di iterare e apportare modifiche al codice, al piano del progetto e al piano di test. Per ulteriori informazioni, vedere Rapporto Stato di avanzamento piano test.
Livelli di test da fornire al team
Tramite Visual Studio Test Professional 2010 e Team Foundation Server, il team è in grado di capire lo stato della pianificazione e dell'esecuzione di test. In Team Foundation Server vengono archiviati i piani di test, i gruppi di test, i test case, i risultati dei test e tutti gli altri dati associati generati durante tutto il processo di test. È possibile visualizzare il processo di test e di controllo qualità se si combina Microsoft Test Manager con la creazione di rapporti e l'esecuzione di query sugli elementi di lavoro in Team Foundation Server. È possibile utilizzare Microsoft Test Manager per eseguire query di bug in molti stati diversi. Per i bug contrassegnati come corretti da altri membri del team deve essere impostato lo stato Risolto. È possibile utilizzare compilazioni successive per verificare i bug corretti. Per informazioni su come verificare se un bug è stato corretto, vedere Procedura: verificare l'avvenuta correzione di un bug tramite Microsoft Test Manager.