Come creare fiducia nei carichi di lavoro Azure con test efficaci

Il test è un processo continuo che convalida le modifiche introdotte in un carico di lavoro. Rileva le regressioni e mantiene la qualità man mano che il carico di lavoro si evolve.

Questa guida si basa sulle strategie di architettura di OE:09 per i test, che illustrano i principi generali da esaminare per primi. Non copre in profondità le prestazioni, l'affidabilità e i test di sicurezza. Per questi argomenti, vedere la guida ai test delle prestazioni, la guida ai test di affidabilità e la guida ai test di sicurezza.

Pianificare e progettare test insieme all'architettura ed evolverla man mano che cambia l'architettura. I test hanno quattro fasi che si sovrappongono e si eseguono invece di essere eseguiti in sequenza rigorosa:

• Pianificazione: decidere cosa convalidare e perché. Queste decisioni regolano i costi e la copertura dei test per la durata del carico di lavoro. Acquisiscili in una strategia di test e in un piano di test.
• Preparazione: configurare le condizioni che simulano scenari reali. Effettuare il provisioning di ambienti, creare dati di test, compilare test case, dipendenze fittizie e configurare framework di automazione.
• Esecuzione: integrare i test nella pipeline CI/CD, eseguirli in più livelli e dimensioni di qualità, eseguire in modo sicuro alcuni test nell'ambiente di produzione e difetti di rete.
• Analisi: analizzare i risultati e il report sulla qualità. Tenere traccia dei difetti, misurare la copertura, valutare le metriche di qualità e migliorare i feed in fase di sviluppo.

Gli esempi in questa guida seguono un singolo carico di lavoro di e-commerce che aggiunge Apple Pay come opzione di pagamento di pagamento.

Terminologia

Creare la strategia di test

La pianificazione inizia con una strategia che imposta la direzione per tutto ciò che segue.

Una strategia di test è un accordo di lunga durata su ciò che si testa e perché, in più versioni. Architetti, ingegneri e proprietari di prodotti sono d'accordo prima dell'inizio dello sviluppo e rivedirlo man mano che il carico di lavoro si evolve. Iniziare raccogliendo i requisiti aziendali, identificando i flussi utente critici e le aree di rischio e decidendo come l'architettura supporta la convalida nel tempo.

Una strategia riguarda in genere questi elementi. L'elenco esatto varia in base alla struttura del team e alle procedure organizzative.

• Obiettivi e ambito. Obiettivi di test, flussi utente critici e contratti di servizio che determinano criteri di accettazione. Definire i livelli, i componenti e gli scenari inclusi nell'ambito e quali sono esclusi.
• Metodi e tecniche. I tipi di test eseguiti, ad esempio funzionalità, sicurezza, prestazioni e accettazione dell'utente, e l'equilibrio tra test manuali e test automatizzati.
• Ruoli e responsabilità. Chi possiede ogni tipo di test e il modo in cui i team coordinano.
• Ambienti e dati di test. Gli ambienti necessari, i test eseguiti in ognuno, la parità con la produzione e le origini dati di test e i requisiti di residenza.
• Rischi e limitazioni. Potenziali rischi, ad esempio vincoli di risorse, disponibilità dell'ambiente o problemi di test dei dati.
• Criteri di ingresso e uscita. Condizioni da soddisfare prima dell'inizio dei test e delle condizioni da considerare complete.
• Strumenti e processi. Strumenti per la gestione dei test, l'esecuzione, la creazione di report e il rilevamento dei difetti con definizioni di gravità e priorità.

Sviluppare il piano di test

Il piano di test converte la strategia in un documento praticabile per una versione o uno sprint specifico. È destinato al team di test e ai collaboratori che eseguono i test. Crearlo dopo la strategia, quando i requisiti vengono definiti e le attività di test richiedono dettagli.

Il piano copre gli stessi elementi della strategia, ma a livello di rilascio. Aggiunge attività cardine, risultati finali, sequenze temporali e processo di disconnettemento, in modo da poter tenere traccia dello stato di avanzamento e terminare in tempo.

Esempio: strategia di test e piano

Il metodo di pagamento Apple Pay introduce casi d'uso specifici, ad esempio la configurazione del dispositivo, l'autenticazione e la gestione delle transazioni.

La strategia di test non cambia molto per questa versione. Impone già che i flussi di pagamento siano la priorità di test più alta, denominano gli strumenti standard come Playwright per i test dell'interfaccia utente e Test di carico di Azure per i test di carico e assegna al team back-end i propri test di integrazione dei pagamenti e il team della piattaforma per i test di carico.

Il piano di test per la versione apple Pay compila le specifiche:

Senza una strategia e un piano, ogni versione adotta un approccio ad hoc che porta a una copertura incoerente, a flussi critici persi e a ritardi dell'ultimo minuto. Insieme garantiscono test coerenti e un'implementazione uniforme.

Scegliere l'ambiente corretto

La preparazione è la posizione in cui si implementa la strategia. Per iniziare, effettuare il provisioning degli ambienti corretti, che variano in base al tipo di test. Associare ogni ambiente ai test che si prevede di eseguire, insieme ai relativi requisiti di infrastruttura, dati e sicurezza.

• Ambienti inferiori (sviluppo, integrazione): usare l'infrastruttura su scala ridotta e i servizi fittizi. Eseguire qui unit test, integrazione e regressione.
• Ambienti di pre-produzione: eseguire il mirroring dell'infrastruttura di produzione e delle dipendenze il più possibile. Eseguire qui test di prestazioni, affidabilità e sicurezza.
• Ambienti temporanei: crearli su richiesta per esigenze di breve durata, ad esempio la convalida di un ramo di funzionalità o l'esecuzione di un gruppo di test isolato. Smontarli per controllare i costi.
• Ambiente di produzione: in alcuni casi si eseguono test nell'ambiente di produzione, ad esempio la convalida di una nuova funzionalità con una piccola percentuale di utenti o l'esecuzione di test di stress durante le ore di minore attività. Usare protezioni per isolare il test e limitare l'esposizione dell'utente.

Automatizzare il provisioning dell'ambiente per la coerenza e la configurazione più rapida. Usare modelli Azure Resource Manager (ARM), Bicep o Terraform per definire e distribuire l'infrastruttura di test. La deriva della configurazione è un rischio in più ambienti, quindi eseguire una fase della pipeline che confronta la configurazione distribuita con la definizione dell'infrastruttura come codice (IaC) prima di eseguire i test. Ad esempio, distribuire l'infrastruttura che rispecchia la produzione, ma sostituisce il gateway di pagamento in tempo reale con la sandbox Apple Pay.

Usare simulazioni in modo strategico

Gli ambienti raramente replicano esattamente la produzione, quindi usare i mock per rimanere in piedi per le dipendenze reali. I mock replicano i servizi che sostituiscono, incluse le risposte previste, le condizioni di errore e la latenza. Strumenti come WireMock, Mountebank o Gestione API di Azure criteri fittizi consentono di definire e gestire risposte fittizie senza scrivere codice personalizzato.

I candidati validi per la simulazione sono API di terze parti, servizi non deterministici e servizi lenti, costosi o non disponibili in ambienti inferiori. I test di integrazione per il servizio di estrazione possono usare un gateway di pagamento fittizio per simulare transazioni riuscite e non riuscite, mentre i test delle prestazioni usano il gateway reale per acquisire la latenza e la velocità effettiva effettive. Non simulare mai il componente che si sta testando.

Progettare per testare la testabilità in modo da poter scambiare le dipendenze senza modifiche al codice. Ad esempio, usare l'inserimento delle dipendenze per sostituire il client Apple Pay reale con una simulazione durante i test.

Compromesso: L'inserimento delle dipendenze può aumentare la complessità dell'architettura e rendere il codice più difficile da comprendere. Valutare il vantaggio della testabilità rispetto alla chiarezza del codice per evitare problemi di manutenzione a lungo termine.

Usare il test del contratto per mantenere accurate le simulazioni. Un test del contratto verifica che le forme di richiesta e risposta della simulazione corrispondano all'API del servizio reale. Eseguire test del contratto ogni volta che cambia l'API del servizio reale. Senza di essi, mocks diverge in modo invisibile all'utente dal comportamento reale, causando il passaggio dei test in ambienti inferiori, ma hanno esito negativo nell'ambiente di produzione.

Generare dati di test realistici e gestirli

I dati di test determinano i test, in modo che riflettano la diversità dei dati reali, tra cui casi perimetrali, condizioni limite e variazioni nel comportamento dell'utente. Si consideri uno scenario di accesso e i relativi casi positivi, negativi e perimetrali: un account valido, una password non valida e un account bloccato.

Assegnare a ogni scenario un proprio set di dati univoco. Un set di dati condiviso è un'origine comune di test instabilità. Se l'account bloccato e i test dell'account validi vengono eseguiti con le stesse credenziali, un test può causare un errore intermittente dell'altro. Le credenziali dedicate consentono l'esecuzione dei test in parallelo senza interferire tra loro.

Creare un'ampia gamma di dati e parametrizzarla, quindi la stessa logica di test convalida più comportamenti. Per lo scenario di accesso, parametrizzare le credenziali in modo che un test convalide un account valido, una password non valida, un account bloccato, una password scaduta e un messaggio di posta elettronica non verificato. Aggiungere identificatori univoci come timestamp o GUID a nomi utente e indirizzi di posta elettronica per evitare conflitti.

Quando uno scenario richiede effettivamente i dati di produzione, renderli anonimi per primi. Maschera tutte le informazioni riservate, ad esempio nomi, indirizzi e dettagli di pagamento. Usare strumenti di generazione dei dati come Faker o Mockaroo per creare set di dati sintetici realistici.

Gestire i dati di test man mano che aumentano con la copertura:

• Automatizzare la creazione e l'eliminazione. Eseguire un passaggio prerequisito che inserisce il test nello stato corretto prima dell'esecuzione e una fase di disinstallazione che elimina i dati in un secondo momento. Mantenere i dati di test solo per la durata delle esecuzioni dei test.
• Versione e protezione dei dati persistenti. Quando i dati devono essere persistenti, archiviarlo nel repository di test sotto il controllo della versione, separato dai dati di produzione. Non impostare mai credenziali hardcoded, chiavi API o certificati negli script di test. Archiviarli in un insieme di credenziali sicuro e recuperarli in fase di esecuzione.
• Mantenere aggiornati i dati. Aggiornare i dati di test in modo da riflettere le modifiche apportate al carico di lavoro, al comportamento degli utenti e ai requisiti aziendali.

Progettare test case efficaci

Guidare gli scenari di test dai flussi utente e dai requisiti aziendali. Coprire il comportamento funzionale, i case perimetrali e gli attributi non funzionali. Classificare gli elementi da testare in base alla probabilità che si verifichi un difetto e l'impatto se raggiunge la produzione. Le aree critiche, ad esempio l'accesso, il pagamento e i flussi di pagamento, meritano molto più copertura rispetto alle pagine informative a basso rischio.

Bilanciare la copertura tra i livelli della piramide dei test. Impostare le destinazioni di copertura per ogni livello in base alle funzioni, ai rischi e ai costi di manutenzione critici dei test.

Usare i criteri seguenti per decidere in quale livello appartiene un test case:

Un singolo flusso richiede in genere test a più livelli, con ogni livello che copre una parte diversa di esso. Il flusso di estrazione può usare unit test per la logica di calcolo del carrello, i test di integrazione per l'interazione del servizio di pagamento e i test end-to-end per il percorso utente completo. Usare gli obiettivi di copertura per distribuire la copertura tra flussi critici invece di investire in un unico flusso.

Guarda oltre la funzionalità. Includere casi non funzionali, ad esempio prestazioni, sicurezza e affidabilità, e disegnare i criteri di accettazione di ognuno dai requisiti pertinenti. Se il flusso di pagamento ha un SLO di 2 secondi per la conferma del pagamento con carico di picco, i criteri di accettazione sono che la conferma del pagamento viene restituita entro 2 secondi per 95% di richieste durante un carico massimo simulato di 5.000 acquirenti simultanei.

Strutturare ogni caso chiaramente con una condizione iniziale (specificata), un'azione o un evento (quando) e un risultato previsto (quindi). Ad esempio: dato che un utente con un account Apple Pay valido e una carta di credito con fondi insufficienti, quando l'utente tenta di completare un acquisto, la transazione ha esito negativo con un messaggio di errore appropriato e l'ordine non viene elaborato.

Acquisire casi in Azure Test Plans, TestRail o uno strumento simile in modo da poter organizzare, tenere traccia e segnalarli. Collegare ogni caso al requisito o alla storia utente per mantenere visibili la tracciabilità e la copertura.

Man mano che il carico di lavoro si evolve, è consigliabile testare i test case. Gli scenari diventano obsoleti man mano che il comportamento dell'utente, i modelli di traffico e il cambiamento dell'infrastruttura. Esaminare regolarmente i casi, ritirare quelli che non riflettono più il carico di lavoro e piegare le lezioni degli eventi imprevisti di produzione in nuovi casi.

Creare il framework di automazione

I test automatizzati offrono commenti e suggerimenti più rapidi e vengono eseguiti più frequentemente rispetto ai test manuali. Richiedono investimenti iniziali per progettare e gestire, ma pagano attraverso versioni più rapide e una copertura più ampia nel tempo.

Compromesso: La compilazione di un framework ben progettato richiede tempo. Valutare l'investimento di automazione rispetto al rischio di difetti che raggiungono la produzione. Avviare l'automazione di piccole dimensioni, bilanciare l'automazione con test manuali ed espandere il framework man mano che aumenta il carico di lavoro.

Per iniziare, decidere cosa automatizzare. Prediligi test case ripetibili, critici e stabili. Lasciare il lavoro esplorativo e modificare rapidamente le interfacce utente per il test manuale.

In base alla strategia di test, scegliere gli strumenti adatti al carico di lavoro e al team. Prendere in considerazione la compatibilità dei carichi di lavoro, le licenze, la facilità d'uso, il supporto della community, l'integrazione CI/CD e la curva di apprendimento. Basarsi su framework stabiliti invece di creare framework personalizzati, ad esempio Playwright o Selenium per i test dell'interfaccia utente e Postman o RestAssured per i test API.

Creare il framework tenendo conto della gestibilità, della scalabilità e della sicurezza, in modo da poter aggiungere test senza effettuare il refactoring principale:

• Struttura per la scalabilità. Applicare progettazione modulare, componenti riutilizzabili e parametrizzazione. Organizzare configurazioni di test, casi, dati, log e risultati. Suddividere i gruppi in base al tipo di test, ad esempio integrazione, carico e stress, in modo da poter eseguire test mirati, confrontare i risultati tra le esecuzioni e gestire ogni gruppo in modo indipendente. Evitare una suite monolitica, che è lenta e rende difficile l'analisi della causa radice.
• Asset di test del controllo della versione. Mantenere i dati di test, i file di configurazione e gli script in GitHub o Azure DevOps. Abilitare i criteri delle richieste pull, la convalida della compilazione e la revisione del codice esattamente come il codice di produzione, in modo da rilevare i difetti nei test stessi prima dell'unione.
• Aggiungere asserzioni cancellate. Le asserzioni convalidano che i risultati effettivi corrispondano ai risultati previsti. Usare librerie di asserzioni come JUnit che forniscono messaggi di errore chiari e descrittivi per semplificare la diagnosi degli errori.
• Compilazione osservabile. Usare i report del framework per acquisire log e metriche strutturati. Registrare i parametri di input, i risultati previsti e effettivi e le eccezioni. Non registrare informazioni riservate, ad esempio token di autenticazione, password o dettagli sugli errori che potrebbero perdere informazioni.
• Progettare per l'isolamento. Progettare i test da eseguire in qualsiasi ordine senza stato condiviso. Ogni test configura e rimuove le proprie precondizioni, quindi i test vengono eseguiti in parallelo senza interferire. Applicare l'esecuzione sequenziale solo quando le dipendenze o i flussi di lavoro aziendali lo richiedono, usando funzionalità del framework come le annotazioni JUnit per controllare l'ordine.
• Proteggere il framework. I framework di automazione spesso toccano i dati e i sistemi di produzione, che comportano il rischio di librerie importate o codice di test vulnerabile. Applicare procedure di codifica sicure, ad esempio l'analisi delle vulnerabilità, la convalida di input e la corretta gestione dei segreti e usare strumenti come JFrog Artifactory per gestire in modo sicuro le dipendenze e gli artefatti.

Eseguire test nella pipeline

Con un framework di automazione sul posto, eseguire i test in modo continuo, in modo da ottenere commenti e suggerimenti su ogni modifica del codice e rilevare i difetti in anticipo. I livelli di base e intermedi della piramide di test si integrano più facilmente perché hanno dipendenze minime. Non è necessario un framework completo per iniziare. Iniziare con un piccolo set di test ed eseguirne la migrazione in un framework unificato man mano che le funzionalità maturano.

Usare le fasi della pipeline per separare tipi di test diversi e definire controlli di qualità tra le fasi in modo che una modifica non possa progredire fino a quando non soddisfa i criteri di qualità. Nell'applicazione di e-commerce si eseguono unit test di checkout a ogni commit, lo stato di avanzamento dei test di integrazione sulle richieste pull solo quando gli unit test superano ed eseguono test di regressione quando la richiesta pull attiva la pipeline di distribuzione.

Configurare le esecuzioni notturne della suite completa in pre-produzione per rilevare test e regressioni in flaky e monitorare il comportamento del carico di lavoro nel tempo. Queste esecuzioni possono includere test con esecuzione più lunga, ad esempio test di carico e prestazioni, che non sono pratici da eseguire a ogni commit.

Eseguire una combinazione di tipi di test per ottenere un quadro completo. La combinazione dei test rivela che i difetti di un singolo tipo non verrebbero superati. Un test di stress potrebbe mostrare che il servizio di checkout ha esito negativo a 5.000 acquirenti simultanei durante una vendita flash, mentre un test di resistenza di 12 ore al carico normale espone una perdita di memoria nel servizio carrello che avrebbe bloccato il sito durante la notte. Nessuno dei due test rileva entrambi i problemi.

Mantenere il feedback veloce gestendo il tempo di esecuzione. Usare l'esecuzione parallela, se possibile. Ad esempio, in Gradle impostare su maxParallelForks un valore maggiore di 1. Applicare un fail-fast meccanismo per i test critici in modo che la pipeline venga arrestata non appena un test critico non riesce, senza eseguire la suite di regressione completa.

Alcuni test devono essere eseguiti nell'ambiente di produzione. Ad esempio, eseguire test di stress per il servizio di checkout durante le ore di minore attività per trovare il punto di interruzione e confermare che il sistema viene ripristinato correttamente o convalidare una nuova funzionalità con una piccola percentuale di utenti. Implementare protezioni che isolano il test e limitano l'esposizione degli utenti, ad esempio i flag di funzionalità per l'implementazione mirata e gli arresti automatici quando le metriche come la frequenza di errore o la latenza violano i contratti di servizio.

Difetti di rete

Un test non riuscito segnala un difetto, che può provenire da modifiche al codice, deviazione della configurazione o problemi ambientali. Registra ogni difetto con un titolo chiaro, passaggi di riproduzione, test o ambiente non superati e log di supporto, immagini o video. Classificare la gravità (critica, alta, media, bassa), collegare ogni difetto all'impatto dell'utente e al rischio aziendale, assegnare un proprietario e tenere traccia della chiusura.

Non disabilitare i test che identificano i difetti. Aggiungere invece la logica per gestire il difetto e continuare il test. Ad esempio, aggiungere un controllo condizionale per ignorare un test nello sviluppo , ma eseguirlo in pre-produzione, in modo da poter continuare a testare altre aree mentre il difetto è fisso.

Dopo una correzione, ripetere il test di regressione nello stesso ambiente in cui è stato rilevato il difetto ed eseguire test di regressione per verificare il funzionamento della correzione e non interrompe altre parti del carico di lavoro.

Analizzare i risultati e il report sulla qualità

I risultati dei test sono utili solo se vengono analizzati e report sulla qualità. Dopo ogni esecuzione, esaminare i risultati per rispondere:

• Cosa hanno rivelato i test sulla qualità del carico di lavoro?
• Dove sono le lacune nella copertura?
• Quali difetti sono stati trovati e quanto sono critici?
• Come è possibile migliorare l'efficacia dei test?

Tenere traccia dei risultati, del tempo di esecuzione, delle tendenze di errore e dei confronti cronologici per monitorare l'integrità della suite nel tempo. Usare la creazione di report predefiniti nel framework di test e nella piattaforma CI/CD e inviare una notifica alle persone giuste in caso di errore, in modo da poter analizzare rapidamente. Monitorare le esecuzioni notturne per nuovi errori, regressioni e modelli ricorrenti per rilevare test instabili e aree instabili prima di influire sulla qualità del rilascio.

Rilevamento dei difetti

Mantenere un dashboard dei difetti che mostra difetti aperti, gravità, stato, proprietà e invecchiamento e usarlo per classificare in ordine di priorità le correzioni. Ad esempio, correggere un difetto critico nel flusso di checkout prima di un problema estetico con gravità bassa nella pagina della Guida. In Azure DevOps usare gli elementi di lavoro per tenere traccia dei difetti, collegarli ai test case e visualizzare il relativo stato nei dashboard.

Analisi della copertura

Misurare il code coverage per identificare i percorsi non verificati, ma considerare la copertura come segnale anziché come destinazione. La copertura elevata del codice a basso rischio è meno importante rispetto alla copertura mirata dei flussi critici. Usare strumenti come SonarQube o JaCoCo per generare report di copertura e individuare lacune nei pagamenti, checkout e altre aree ad alto rischio, quindi aggiungere casi in cui il rischio giustifica il costo di manutenzione. Quando un difetto esce dall'ambiente di produzione, verificare se un test deve averlo intercettato e aggiungere la copertura in cui dovrebbe essere disponibile.

Metriche e report di qualità

Tenere traccia di un piccolo set di metriche che riflettono la qualità e l'integrità della suite.

Segnalare le metriche ai destinatari necessari e personalizzare ogni dashboard in modo che risponda alle domande del pubblico. Per il flusso di estrazione, lo stesso set di metriche serve gruppi di destinatari diversi in modi diversi:

Azure DevOps fornisce dashboard e widget predefiniti per i risultati dei test, il code coverage e gli elementi di lavoro che è possibile personalizzare per gruppo di destinatari.

Cicli di feedback e miglioramento continuo

Creare un report di test alla fine di ogni versione come risultato finale nella disconnettersi del piano di test. Includere dettagli sulla versione, risultati dell'esecuzione dei test, riepiloghi dei difetti e informazioni di copertura per informare le decisioni sulla conformità del rilascio, sui rischi accettabili e sulle priorità future.

Usare queste informazioni dettagliate per migliorare l'efficacia dei test. Esaminare i test a cadenza regolare, cercare modelli in tipi di difetti e gap di copertura e perfezionare la strategia e i casi di conseguenza. Poiché i test instabili, la copertura duplicata e i test obsoleti erodono la fiducia e il recapito lento, pianificare gli sprint di manutenzione regolari per ridurre il debito dei test. Con ogni fase, si ottengono informazioni dettagliate preziose e si affina l'approccio, creando fiducia in ogni versione.

Come evitare di testare gli antipattern

Gli antipattern seguenti compromettono in genere ciò che i test possono eseguire per i carichi di lavoro.

Facilitazione di Azure

Gestione e pianificazione dei test:

• Azure Test Plans fornisce la gestione dei test basata su browser per test manuali, test di accettazione utente, test esplorativi e feedback degli stakeholder. Include Analisi test per tenere traccia della qualità dei test nel tempo.

Automazione dei test e integrazione CI/CD:

• Azure Pipelines abilita l'automazione dei test integrata nei flussi di lavoro CI/CD, con il supporto per l'esecuzione parallela, le fasi della pipeline e i controlli di qualità.

• GitHub Actions offre funzionalità CI/CD simili integrate con repository di GitHub e servizi di Azure.

Test funzionali e delle prestazioni:

• Test app di Azure supporta test funzionali e delle prestazioni con Spazi di lavoro Playwright per test end-to-end e Test di carico di Azure per la convalida delle prestazioni.

Test di affidabilità:

• Azure Chaos Studio è un servizio gestito che usa i test chaos per misurare, comprendere e migliorare l'applicazione cloud e la resilienza del servizio.

Collegamenti correlati

• Raccomandazioni per i test (OE:09)
• Raccomandazioni per i test delle prestazioni
• Raccomandazioni per i test di affidabilità
• Raccomandazioni per i test di sicurezza