Automazione del processo di compilazione

Un processo di compilazione automatizzato compila, distribuisce e quindi esegue test di verifica della compilazione (BVT) sul codice sorgente più recente per un progetto a intervalli regolari predeterminati. Quindi, un "report di compilazione", che descrive in dettaglio l'esito positivo o negativo del processo di compilazione, viene distribuito agli stakeholder del progetto. Il report di compilazione viene analizzato per determinare quali aree del progetto richiedono attenzione e se è necessario eseguire il rollback del progetto a una versione o a una build precedente.

La potenza di un processo di compilazione automatizzato è che può essere pianificata per l'esecuzione durante le "ore di minore attività". In questo modo, può contribuire a garantire la stabilità del progetto senza portare cicli direttamente lontano dal tempo di sviluppo. Questo argomento fornisce una panoramica del processo di compilazione, descrive il modo in cui i test di verifica della compilazione rientrano nel processo di compilazione, descrivono gli aspetti dei test funzionali usati durante il test di verifica della compilazione e forniscono informazioni sull'importanza di automatizzare il processo di compilazione.

Panoramica del processo di compilazione

Prima di esaminare le specifiche dei test, è importante considerare il contesto del modo in cui i test si adattano al processo di compilazione complessivo. Tutti i gruppi di prodotti Microsoft operano dalla filosofia secondo cui il processo di compilazione è l'heartbeat di qualsiasi progetto software. Questo approccio viene usato anche da molte delle principali aziende di consulenza al mondo che creano soluzioni cruciali sopra lo stack di software Microsoft. Senza un battito cardiaco costante e un controllo regolare su di esso, è impossibile conoscere la salute del progetto. Per garantire che i gruppi di prodotti abbiano una visione continua dell'integrità complessiva del progetto, il processo di compilazione viene eseguito ogni giorno, in genere a mezzanotte. I passaggi seguenti riepilogano un tipico processo di compilazione automatizzato:

1. Ottenere la build più recente del codice sorgente dal repository del codice sorgente.

2. Compilare il codice sorgente.

3. Comprimere i file binari per la distribuzione, in genere usando script o file di Microsoft Windows Installer.

4. Distribuire il progetto in un server di test.

5. Eseguire automaticamente un set completo di test di verifica della compilazione (BVT).

6. Pubblicare un report di compilazione dettagliato ai membri del team di progetto.

Annotazioni

I BVT sono test funzionali che esercitano le principali caratteristiche della soluzione per testarne la qualità. È necessario assicurarsi che i file VBT siano sufficientemente completi per misurare la qualità della compilazione, ma abbastanza piccolo da eseguire entro il tempo di compilazione giornaliero allocato!

Annotazioni

È inoltre consigliabile considerare qualsiasi distribuzione, un-distribuzione, script di configurazione e installazione o processi come parte del progetto software a scopo di test. Entrambe le operazioni del progetto, nonché la distribuzione e la configurazione di esso, devono essere testate.

Questo processo viene di solito completato entro le 6 del mattino, il che consente ai primi membri del team di iniziare a lavorare sulla nuova build della giornata. Se uno o più dei BVT della notte precedente hanno fallito, allora è responsabilità del team correggerlo il prima possibile.

L'esecuzione di un processo di build giornaliero presenta molti vantaggi per il progetto. In primo luogo, fornisce un heartbeat regolare (costituito dalla compilazione giornaliera più i BVT automatizzati). In secondo luogo, l'uso dei BVT forza l'integrazione con i sistemi, che è un compito difficile, e farlo precocemente di per sé riduce i rischi del progetto. A causa del tempo necessario per completarli, i test dello stress e delle prestazioni vengono in genere eseguiti al di fuori del processo di compilazione giornaliero. I test di stress e prestazioni sono tipicamente pianificati per essere eseguiti su una versione di sviluppo cardine nel progetto.

Il processo di compilazione giornaliero può essere ed è stato usato in modo molto efficace nelle soluzioni BizTalk. Tuttavia, è necessario assicurarsi che le attività che vengono in genere lasciate alla fine dei progetti vengano eseguite in modo iterativo dall'inizio. Ad esempio, la distribuzione in BizTalk Server è certamente non semplice. È importante sviluppare in anticipo gli script di distribuzione automatizzati. Se non esegui questa operazione, sarai costretto a distribuire e ritirare manualmente la soluzione numerose volte nel corso del progetto, ciò ti farà perdere più tempo alla fine. Sono disponibili strumenti per guidare il processo di compilazione giornaliero; Visual Studio Team System e Team Foundation Server sono la scelta principale per molte persone. Gli script MSBuild possono essere usati per guidare i passaggi del processo di compilazione.

Annotazioni

L'uso di questo strumento non è supportato da Microsoft e Microsoft non garantisce l'idoneità di questi programmi. L'uso di questo programma è interamente a tuo rischio.

Per altre informazioni sull'automazione dei test con Microsoft Test Manager, vedere Esecuzione di test automatizzati.

Test di verifica del build

I test di verifica della build in genere comprendono gli elementi seguenti:

• Unit test : poiché gli unit test sono in genere i primi test da sviluppare, idealmente devono essere creati prima che il codice sia stato effettivamente scritto, se si usa effettivamente un approccio di sviluppo basato su test. Aggiungendoli ai test di convalida del build (BVT) durante le fasi iniziali di un progetto, si fornisce immediatamente almeno una copertura del codice. Man mano che aumenta il numero di test funzionali e quindi la copertura dei test cresce, è possibile scegliere di rimuovere i test di unità dai BVT.

• Smoke Tests - test funzionali end-to-end che verificano la funzionalità di base della tua soluzione. Se queste falliscono, qualcosa è gravemente sbagliato. Questi possono in genere essere eseguiti relativamente rapidamente.

• Test funzionali : si tratta anche di scenari end-to-end, ma in questo caso testano tutti gli scenari nel progetto. Per progetti di grandi dimensioni può essere opportuno classificare ulteriormente i test funzionali (ad esempio, per consentire a un determinato componente di essere testato rapidamente, in modo affidabile e in isolamento). Questi test funzionali devono essere stabilizzati dopo che hai approvato la soluzione come corretta dal punto di vista funzionale.

• Test di verifica della regressione : ogni volta che viene trovato e corretto un bug della soluzione, è necessario aggiungere test case di verifica della regressione per verificare che il bug sia stato corretto e che non venga reintrodotto più avanti nel ciclo di vita del progetto. Questi test sono in genere casi non trattati nei test case funzionali. È consigliabile prevedere che i test di verifica della regressione aumentino di numero anche dopo che la soluzione è stata messa in produzione, se vengono individuati e corretti nuovi bug.

  Su progetti molto grandi, potrebbe essere necessario rendere i TUOI BVT un sottoinsieme del gruppo di test funzionale completo (a causa del tempo necessario per l'esecuzione). Per i progetti più piccoli, i BVT costituiranno l'intero set. Ovviamente, se si intende integrare i BVT come parte della compilazione giornaliera, l'intero processo deve essere automatizzato. Nel resto di questo argomento verrà illustrato come usare BizUnit e altri strumenti per eseguire questa operazione.

Test funzionali

Nel contesto dei test funzionali delle applicazioni BizTalk, testare uno scenario end-to-end specifico. Quando si esegue questo tipo di test, è utile immaginare BizTalk Server come una casella nera che si testa funzionalmente da un punto di vista esterno. Ad esempio, un test può comportare l'inserimento di un messaggio di input (con valori noti) a un punto finale della destinazione di ricezione (ad esempio, URL, posizione FTP, a prescindere dalla modalità di trasporto scelta). Il test monitorerà quindi il numero corretto di messaggi con l'output corretto generato sul lato di invio. Questo può sembrare relativamente semplice. Tuttavia, quando si considera che alcuni scenari richiedono input per venire in un determinato ordine e in un determinato momento, e questo viene composto con altri requisiti della soluzione (ad esempio, quando si registrano i dati di rilevamento in BAM), diventa chiaro che uno strumento e un framework possono essere usati per orchestrare questa operazione.

È fondamentale che i test funzionali siano progettati per coprire tutti i possibili percorsi attraverso la soluzione. Questo deve includere non solo gli scenari previsti nell'ambiente di produzione, ma anche i percorsi di gestione degli errori e i percorsi di gestione delle eccezioni implementati, ma si spera di non usare mai, una frase comunemente usata per descrivere questo è il test per lo "scenario di giorno non valido". È necessario assicurarsi che tutte le orchestrazioni, tutti i tipi di messaggio consentiti e tutti i rami di codice vengano esercitati dal gruppo di test funzionale. Le sezioni seguenti descrivono lo sviluppo di test case funzionali positivi e negativi per coprire tutti i percorsi di codice.

Per altre informazioni sui test funzionali e sulle altre categorie di test da implementare prima di inserire una soluzione BizTalk Server nell'ambiente di produzione, vedere Elenco di controllo: Test della conformità operativa.

Test positivi

• È importante, quando si eseguono test positivi, assicurarsi che tutte le combinazioni di messaggi, pipeline, orchestrazioni ed endpoint siano testate all'interno della soluzione, in modo che tutti i flussi di messaggi siano sperimentati. Per assicurarsi di testare tutti i percorsi di codice richiederà probabilmente l'elaborazione di messaggi diversi con contenuto diverso.

• Durante il test, usare il tipo di trasporto che verrà utilizzato nell'ambiente di produzione. Purtroppo, troppo spesso, i test funzionali vengono eseguiti solo utilizzando l'adattatore di file quando alcuni altri trasporti verranno usati nell'ambiente di produzione. L'adozione di questo approccio vi porta al fallimento, sia voi che il progetto complessivo, più avanti.

• Convalidare il payload di tutti i messaggi inviati dal sistema. Se i messaggi sono XML, è necessario convalidare i relativi campi di schema e chiave nel messaggio usando espressioni XPath.

• Convalidare tutti i dati di rilevamento archiviati in BAM (se usato); tutti gli altri dati lasciati nei repository di dati esterni devono essere considerati.

• Testare l'esecuzione di tutti i criteri e le regole di Business Rule Engine (BRE) se la soluzione usa BRE.

Test negativi

• Assicurarsi di testare la gestione dei messaggi non validi tramite il sistema. È necessario verificare che la strategia scelta (per rifiutarle prima che entrino in BizTalk Server o per sospenderle) funzioni correttamente.

• Quando si testa la gestione dei messaggi non validi, verificare che siano state implementate le orchestrazioni di gestione degli errori sul lato ricezione per gestire i messaggi sospesi.

• Assicurati che gli scenari di errore coprano ogni blocco di eccezione nelle orchestrazioni. La mancata verifica adeguata di questo è un problema comune.

• Se si usano transazioni a esecuzione prolungata con un comportamento di compensazione, testare questi scenari con molta attenzione. Si tratta di un'altra area in cui i test inadeguati subiranno gravi conseguenze in un ambiente di produzione.

• Verificare che gli errori vengano registrati correttamente nei log degli errori appropriati.

L'automazione è fondamentale

Per eseguire tutto questo in modo efficiente ed efficace, investire il tempo iniziale per automatizzare i test. Il test manuale richiede molto tempo, è soggetto a errori e costoso (in termini di tempo e costi). Ogni volta che si esegue un test manuale, si aggiunge un altro batch di attività che devono essere gestite dalle risorse del progetto (persone del team). Automatizzando questo in anticipo, è possibile ottenere un ritorno sull'investimento iniziale necessario per sviluppare i test ogni volta che vengono eseguiti. I test funzionali validi devono essere eseguiti in modo rapido ed efficiente ed essere ripetibili; ogni test deve anche essere autonomo (deve essere indipendente da qualsiasi altro; l'adozione di questo approccio consente di eseguire più test in sequenza come gruppo di test). I test funzionali devono sempre produrre lo stesso risultato. I test funzionali scritti in modo non corretto o codice scritto in modo non corretto genereranno risultati diversi tra le esecuzioni dei test, causando confusione e tempo sprecato per analizzare la causa radice dell'errore.

È importante ridurre al minimo lo sforzo di sviluppo necessario per scrivere ogni test funzionale. In genere, più è costoso produrre qualcosa (in termini di tempo di sviluppo), il numero minore di casi di test si è probabile che abbia. Ciò significa che si avrà un livello inferiore di copertura dei test sul codice. Usando un framework di test, è possibile sviluppare test case più velocemente e più facilmente e, di conseguenza, semplificare l'ottenimento di una copertura del codice completa. I framework di test più validi usano un approccio dichiarativo per definire i test. Ovvero, la configurazione per un test viene archiviata in un file di configurazione, che in genere è un file XML. Utilizzare un buon framework di test consente di sviluppare una suite di test funzionale completa in modo agile e affidabile ed evita di dover "reinventare la ruota," per così dire.

Supporto di MSBUILD per progetti BizTalk Server

BizTalk Server offre supporto per la piattaforma Microsoft Build Engine (MSBUILD), che supporta la compilazione di progetti gestiti in ambienti lab di compilazione in cui Visual Studio non è installato. MSBUILD supporta la compilazione di progetti da una riga di comando e funzionalità avanzate, tra cui la registrazione e l'invio in batch di MSBUILD. Per altre informazioni su MSBUILD, vedere Panoramica di MSBuild.

Vedere anche

Implementazione di test automatizzati