Strategie di architettura per i test

Si applica alla seguente raccomandazione della lista di controllo per l'eccellenza operativa del Framework Azure Well-Architected:

Quando si introduce una modifica al carico di lavoro, è necessario assicurarsi che funzioni come previsto e non introduca nuovi problemi. Il test è il modo in cui si valutano tali modifiche. È una pratica essenziale per mantenere la qualità e creare fiducia nel carico di lavoro.

Test efficaci garantiscono prestazioni affidabili e di alta qualità. Impedisce ai difetti di raggiungere la produzione, riduce i costi di rielaborazione e ritardi e mantiene il lavoro allineato agli obiettivi aziendali durante tutto il ciclo di vita dello sviluppo.

Questo articolo fornisce strategie che consentono di offrire un carico di lavoro di alta qualità tramite procedure di test efficaci. Funge da guida di base per le linee guida di test specializzate in altri pilastri, ad esempio prestazioni, affidabilità e sicurezza.

Formalizzare la strategia e il piano di test

La strategia di test e i piani di test sono elementi essenziali. Forniscono una roadmap chiara per le attività di test e assicurano che tutti lavorino verso gli stessi obiettivi di qualità.

Definire la strategia di test

La strategia di test è un progetto di alto livello che guida l'approccio complessivo ai test. Definisce gli obiettivi di test, l'ambito, le metodologie, gli strumenti, i ruoli e le responsabilità. Consente di prendere decisioni informate sulle priorità di test, l'allocazione delle risorse e la gestione dei rischi. Acquisisce anche il modo in cui si comunica con gli stakeholder e i risultati dei report.

Una strategia ben definita per i test ottiene il consenso degli stakeholder e garantisce che tutti i membri del team seguano standard di qualità uniformi. Fornisce direzione e struttura, allinea i test agli obiettivi aziendali e protegge la qualità a lungo termine.

La strategia di test rimane in genere coerente tra le versioni per un determinato carico di lavoro. Ma personalizzarlo sempre in base alle esigenze specifiche e agli obiettivi aziendali di tale carico di lavoro.

Crea il tuo piano

Dopo aver concordato la strategia di test con il team, formalizzarla in un piano di test con casi d'uso allineati agli obiettivi aziendali.

Il piano di test è un documento dettagliato che guida l'esecuzione dei test per una versione specifica. Descrive l'ambito di test, test case specifici, report dei difetti, sequenze temporali, assegnazioni di risorse e criteri di ingresso e uscita per le attività di test.

Un piano di test ben strutturato rende i test efficienti e allineati agli obiettivi e alle tempistiche del rilascio. È il punto di riferimento per tenere traccia dello stato di avanzamento e prendere decisioni informate durante i test.

Esempio: per un sistema di checkout e-commerce, la strategia di test stabilisce un approccio coerente attraverso tutte le release. Definisce che i flussi di pagamento sono sempre classificati in ordine di priorità, specificano gli strumenti di test per il sistema, ad esempio Selenium per i test dell'interfaccia utente, JMeter per i test di carico e OWASP ZAP per i test di sicurezza e chiarisce le responsabilità del team per i diversi tipi di test. Il piano di test per la versione 2.5 è incentrato sull'aggiunta del supporto Apple Pay. Definisce esattamente cosa testare per Apple Pay in questa versione, alloca le risorse (due tecnici e tre dispositivi iOS), imposta una pianificazione di quattro settimane e stabilisce criteri di immissione chiari (codice completo e ambiente configurato) e criteri di uscita (tutti i test superano zero bug critici e un contratto di servizio di due secondi).

Testare in anticipo, testare spesso, testare ciò che conta

Avviare i test nelle prime fasi del ciclo di vita dello sviluppo software. Quando si riscontrano problemi critici in ritardo, si riscontrano un aumento delle rielaborazioni e versioni più lente. Troppo spesso, gli architetti ignorano i requisiti di test nella fase di progettazione, che influiscono negativamente sulla qualità complessiva.

Gli sviluppatori devono adottare una mentalità di controllo della qualità. Pensa ai test anche durante la progettazione. Usarlo per chiarire i requisiti e individuare potenziali limitazioni. Eseguire il test come parte integrante del processo di sviluppo. Assumere la responsabilità della scrittura e della manutenzione dei test insieme al codice.

Quando si rilevano i problemi in anticipo, è possibile rispondere rapidamente. Ad esempio, è possibile assegnare priorità alle modifiche di progettazione essenziali che influiscano sull'esperienza utente rispetto alle correzioni di bug di routine. Agire in anticipo riduce le sorprese e i ritardi dell'ultimo minuto.

Il test non è un evento una tantum. Mantenere i test dopo l'avvio come parte di una mentalità di test continua. Esaminare, aggiornare ed espandere regolarmente il gruppo di test per coprire le nuove funzionalità e risolvere i bug individuati nell'ambiente di produzione per mantenere la qualità a lungo termine.

Compromesso. I test iniziali e continui possono aumentare i costi operativi e potrebbero inizialmente rallentare lo sviluppo o creare attriti all'interno della squadra. Trovare un equilibrio, identificare quali test e modifiche sono essenziali in anticipo e quali è possibile rinviare alle fasi successive. Ciò garantisce efficienza senza compromettere la qualità.

Testare nell'ambiente di produzione con misure di sicurezza

Anche con procedure avanzate di test e convalida, alcuni problemi vengono visualizzati solo nel traffico di produzione reale. Per individuare i problemi che non è possibile simulare, eseguire test controllati nell'ambiente di produzione con misure di sicurezza che limitano l'esposizione degli utenti e riducono i rischi.

Pianificare, isolare e monitorare i test di produzione. In questo modo, è possibile raccogliere dati reali sulle prestazioni e feedback degli utenti, riducendo al minimo le interruzioni alla base di utenti più ampia.

Prendere in considerazione strategie di esposizione progressive, come ad esempio le versioni canarie (canary releases), solo dopo che il flusso di lavoro soddisfa i criteri di uscita e dimostra un'elevata qualità. Questo approccio rilascia prima gli aggiornamenti a un piccolo gruppo mirato di utenti, consentendoti di individuare rapidamente i problemi che potrebbero non apparire negli ambienti di pre-rilascio. Con questo approccio si accelera il processo di test e si riducono potenzialmente i costi associati.

Rischio: Prestare attenzione quando si esegue il test nell'ambiente di produzione, in quanto influisce direttamente sui clienti reali. Implementare sempre misure di sicurezza e limitare l'esposizione per ridurre al minimo i potenziali impatti negativi sull'azienda.

Applicare un approccio a più livelli nella copertura dei test

Una strategia di copertura dei test a più livelli offre un rapido feedback, una rilevazione anticipata dei difetti e rilasci più veloci. Quando si strutturano i test nei livelli, è possibile isolare ed eseguire rapidamente il debug dei difetti, semplificando l'identificazione e la risoluzione dei problemi.

Usare la piramide di test come guida

Il modello di piramide dei test illustra questo approccio a più livelli per l'automazione dei test. Distribuisce i test tra livelli diversi per ottimizzare la copertura riducendo al minimo i costi di esecuzione e manutenzione.

• Livello base: gli unit test verificano i singoli componenti in isolamento. Vengono eseguiti velocemente e forniscono feedback immediato.
• Livello intermedio: i test di integrazione verificano le interazioni tra componenti e servizi. Vengono eseguiti più lentamente rispetto agli unit test, ma offrono una copertura più ampia del comportamento del sistema.
• Livello principale: i test end-to-end convalidano i percorsi utente nell'intero sistema, simulando scenari reali. Questi test vanno più lentamente, ma offrono la massima affidabilità della qualità complessiva.

È possibile integrare più facilmente i test di base e di livello intermedio nelle pipeline perché hanno dipendenze minime. Questa integrazione consente un feedback rapido quando i test hanno esito negativo e consente al processo di compilazione di arrestarsi immediatamente, impedendo l'avanzamento del codice difettoso.

Man mano che aumenta la copertura dei test, il tempo di esecuzione della pipeline può aumentare significativamente. Mantenere un ciclo di feedback rapido usando strategie di esecuzione di test parallele e distribuite, mantenendo efficienti le pipeline anche quando aumenta la copertura.

Compromesso. Esiste un compromesso tra la copertura dei test e l'efficienza della pipeline. Mentre i gruppi di test di dimensioni maggiori aumentano la copertura, aumentano anche il tempo di esecuzione e i costi. Non sempre offrono un ritorno significativo sugli investimenti.

Test dell'applicazione e dell'infrastruttura separati

Creare una segmentazione chiara tra il test del codice dell'applicazione e il codice dell'infrastruttura. Convalidare l'infrastruttura osservando il comportamento dell'applicazione tramite la distribuzione del software e l'esecuzione di test su di esso.

L'esecuzione di smoke test dell'applicazione può rivelare problemi di infrastruttura, ad esempio errori di rete, errori di configurazione DNS o vincoli di risorse prima che influiscano sulla produzione. Ad esempio, un "smoke test" che convalida gli endpoint di integrità dell'API può rilevare rapidamente i problemi di provisioning dell'infrastruttura o le politiche di rete problematiche.

Con questo approccio, i test specifici dell'applicazione identificano e risolvono in modo proattivo i problemi dell'infrastruttura, riducendo la necessità di convalida dell'infrastruttura separata. Offre la certezza che il codice e l'infrastruttura sottostante funzionino correttamente.

Incorporare tipi diversi di test

Usare vari metodi di test in tutto il carico di lavoro. Il completamento degli unit test non significa che i test siano stati eseguiti. Ogni aspetto del carico di lavoro richiede un approccio distinto. Più tipi di test migliorano la qualità complessiva e migliorano la sicurezza che il sistema funzioni come previsto.

Scegliere il tipo di test corretto in base alla maturità del carico di lavoro e al profilo di rischio. Iniziare con la convalida funzionale tramite i livelli della piramide di test, quindi aggiungere test non funzionali come prestazioni, sicurezza e resilienza. Allineare la selezione del tipo di test agli scenari e ai rischi critici del carico di lavoro.

Nella tabella seguente viene illustrato quando applicare tipi di test diversi durante il ciclo di test. Ognuno affronta rischi specifici. Anche se questa tabella non è un elenco completo di tutti i possibili tipi di test, funge da esempio illustrativo.

Valutare ogni funzionalità o modifica in base all'impatto e al rischio aziendali. Classificare in ordine di priorità i tipi di test in base a questa valutazione. Per i carichi di lavoro rivolti ai clienti, evidenziare i test end-to-end e dell'interfaccia utente. Per i carichi di lavoro basati sulle API, concentrarsi sull'integrazione e sul test del contratto. Per i sistemi a disponibilità elevata, investire in resilienza e test di caos.

Compromesso. Assegnare priorità ai test di sicurezza all'inizio del processo di rilascio. Questo approccio consente di prevenire le vulnerabilità e garantisce distribuzioni più sicure. Tuttavia, questa priorità può rallentare il ritmo con cui si offrono nuove funzionalità all'ambiente di produzione.

Considerare gli asset di test come importanti come asset di codice

Gli asset di test acquisiscono regole aziendali essenziali, casi limite, modelli di difetti storici e preziose conoscenze organizzative. Quando la qualità dei test si riduce, i team sprecano tempo a eseguire il debug di test inaffidabili anziché trovare difetti reali. Questa situazione crea frustrazione e gli sviluppatori perdono fiducia nel framework di test.

Gestire gli asset di test con lo stesso rigore degli asset di codice. La responsabilità totale degli asset di test migliora sia l'affidabilità che la qualità complessiva del framework di test.

Strutturare e proteggere i test

Strutturare il codice di test con gli stessi principi architetturali del codice dell'applicazione. Quando possibile, mantenere i test insieme al codice nello stesso repository per semplificare la manutenzione e promuovere la coerenza.

Se la suite di automazione si trova in un repository separato, implementare controlli di governance equivalenti, ad esempio verifiche di codice obbligatorie, criteri di richiesta pull e pipeline di convalida per mantenere gli standard di qualità.

I test spesso interagiscono con i dati e i sistemi di produzione, che possono introdurre rischi dalle librerie importate o dal codice di test vulnerabile. Implementare procedure di codifica sicure nel codice di test per evitare vulnerabilità. Gestire i test con gli stessi standard di sicurezza del codice di produzione.

Versiona i dati di test insieme al codice. Quando si modificano schemi di dati o regole business, aggiornare i dati di test in modo che corrispondano allo stato corrente del carico di lavoro.

Eseguire la convalida di base dei propri test per assicurarsi che funzionino come previsto. Eventuali errori devono puntare ai problemi effettivi dell'applicazione, non ai difetti di test. Verificare che i test falliscano appropriamente e vengano superati in modo coerente quando il carico di lavoro è stabile. Risolvere tempestivamente i test inaffidabili e assicurarsi che le asserzioni di test rafforzano la finalità di ogni test.

Configurare procedure che garantiscono l'indipendenza e l'affidabilità dei test, ad esempio isolare i dati di test, evitare lo stato condiviso e implementare processi di installazione e disinstallazione appropriati. Implementare la pulizia automatica dei dati di test. Per trarre vantaggio dall'esecuzione di test paralleli, progettare i test in modo che siano indipendenti in modo che possano essere eseguiti in qualsiasi ordine senza influire sui risultati. I test indipendenti devono sempre configurare e disattivare i propri dati e dipendenze, in modo che gli stati non siano mantenuti nella successiva esecuzione del test.

Se l'applicazione richiede la sequenziazione nei test, usare framework di test che supportano l'esecuzione ordinata dei test.

Mantenere ed evolvere i tuoi test

La gestione degli asset di test è fondamentale per preservare la qualità del carico di lavoro. Questi asset contengono spesso preziose conoscenze organizzative. Se non li mantieni regolarmente, diventano rapidamente obsoleti, compromettendone l'efficacia e la capacità di offrire versioni di alta qualità.

Man mano che il carico di lavoro si evolve, gli asset di test devono evolversi in parallelo per rimanere allineati agli obiettivi aziendali. Usare gli stessi principi architetturali per la progettazione dei test eseguita per il codice di produzione.

Il gruppo di test di regressione deve contenere i test più importanti e stabili. Inizia con una piccola suite di regressione e cresci deliberatamente. Aggiungere test quando si verificano eventi imprevisti di produzione, quando si correggeno bug critici e quando si introducono modifiche ad alto rischio. Automatizzare la suite di regressione in modo che venga eseguita in modo coerente senza intervento umano. Creare test di fumo rapidi eseguiti su ogni commit e test di regressione più estesi che vengono eseguiti in modo notturno o prima del rilascio della versione.

I casi di test acquisiscono la finalità, l'ambito e i risultati previsti. Mantenere sincronizzati gli script di automazione dei test e i test case è essenziale. Se gli script di automazione differiscono dai test case corrispondenti, è difficile tenere traccia di ciò che viene convalidato, causando lacune nella copertura e nella responsabilità.

Pianificare in modo proattivo gli aggiornamenti regolari dei test case quando si introducono nuove funzionalità e miglioramenti al carico di lavoro. Quando si automatizza un test case, collegare l'automazione al test case originale in modo da poter tracciare la copertura.

Gestire il debito tecnico di test

Pianificare gli sprint regolari di manutenzione dei test per affrontare l'accumulo del debito prima che diventi travolgente.

I test instabili, la copertura ridondante, i test obsoleti e una scarsa progettazione dei test contribuiscono al debito tecnico dei test. Quando si identificano test inaffidabili, assegnare priorità alla correzione o alla rimozione per mantenere l'integrità del gruppo di test. Un set più piccolo di test affidabili è più prezioso di un set di test ampio e inaffidabili.

Le decisioni strategiche relative all'omissione o al rinvio dei test sono importanti quanto ciò che si decide di testare. Si può considerare di ignorare i test per codice banale o a basso rischio, ad esempio metodi getter e setter privi di logica di business, casi limite estremamente rari, librerie di terze parti e codice legacy programmato per la rimozione. Documentare queste decisioni in modo che il team possa rivederle man mano che cambia contesto.

Valutare il gruppo di test e separare test affidabili e coerenti da quelli soggetti a modifiche esterne. I test che si interrompono frequentemente a causa di fattori esterni al controllo, ad esempio i test dell'interfaccia utente interessati da frequenti aggiornamenti dell'interfaccia utente, potrebbero non essere candidati validi per l'automazione. Questa separazione consente di decidere quali test automatizzare e quali mantenere manuale.

Compromesso. Quando si rimuovono test fragili, si riduce la copertura di automazione. Bilanciare questa riduzione concentrando l'automazione su interfacce stabili e flussi di lavoro critici, accettando al contempo test manuali per gli elementi dell'interfaccia utente che cambiano di frequente.

Non tutti i test meritano manutenzione in corso. Rimuovere i test per le funzionalità rimosse, i test che duplicano la copertura e i test che non forniscono più valore. Documentare il motivo per cui si stanno rimuovendo i test in modo che la decisione sia chiara per il team.

Estendere l'osservabilità al framework di test

L'osservabilità nei test raggiunge due obiettivi chiave: garantire che il framework di test funzioni in modo affidabile e offrendo visibilità continuativa sulla qualità e sull'integrità del carico di lavoro. Integrando le procedure di osservabilità nel framework di test, si rafforzano le funzionalità di diagnostica, si facilita il monitoraggio in tempo reale della stabilità e si migliorano costantemente i processi di test.

Senza questa visibilità, si riscontrano notevoli difficoltà nella diagnosi dei problemi, capacità limitata di monitorare i sistemi in tempo reale e non si ottengono informazioni chiare e interattive sull'efficacia della copertura di automazione.

I gruppi di test peggiorano nel tempo, i test diventano inaffidabili, perdono rilevanza o non riescono a mantenere il passo con le modifiche del carico di lavoro. Incorporando l'osservabilità, è possibile monitorare efficacemente l'integrità del gruppo di test, individuare e risolvere rapidamente gli errori e prendere decisioni informate sulle priorità e sui miglioramenti della manutenzione. La generazione di report di copertura semplifica l'identificazione delle lacune nell'automazione. Quando la copertura dei test è allineata ai dati di osservabilità degli eventi imprevisti di produzione, i team ottengono informazioni dettagliate su quali scenari non dispongono di una convalida adeguata.

Utilizzare gli strumenti standard del settore per la copertura dei test e il reporting all'interno del framework per:

• Offrire visibilità chiara nei percorsi di codice testati
• Identificare i test che falliscono consistentemente
• Analizzare le tendenze a lungo termine nell'affidabilità dei test
• Tracciare le origini degli errori per i miglioramenti mirati

Rischio: Se i log sono incoerenti e eccessivamente dettagliati, potrebbero creare più rumore rispetto al valore, rendendo più difficile il debug. Implementare la registrazione strutturata con messaggi chiari, interattivi e livelli di dettaglio diversi per garantire che i log forniscano informazioni dettagliate significative senza sovraccaricare il team.

Simulare condizioni realistiche

Valutare i flussi di lavoro dal punto di vista dell'utente finale per assicurarsi che rispondano realmente alle esigenze e alle aspettative dei clienti. Definire criteri di accettazione chiari per i carichi di lavoro e progettare test che riflettono in modo accurato i flussi utente e le esperienze reali, non solo i comportamenti isolati del sistema.

Ridimensionare la copertura in modo strategico

Ridimensionare la copertura dei test in base al rischio e al valore. Classificare in ordine di priorità la copertura per percorsi utente di alto valore e percorsi critici che influiscano direttamente sull'esperienza dei clienti. Man mano che aumenta la complessità del carico di lavoro, espandere la copertura dei test valutando gli scenari che offrono la massima attendibilità nella qualità e nell'affidabilità del carico di lavoro.

Rischio: Non sovrainvestire in un singolo flusso utente oltre il punto di riduzione dei rendimenti. Dopo aver ottenuto una copertura sufficiente per i percorsi critici, sposta l’attenzione su altre aree importanti. Cerca di ottenere una copertura bilanciata anziché la perfezione in un unico flusso.

Allinearsi agli obiettivi aziendali e ai contratti di servizio

Allineare i test agli obiettivi aziendali e agli obiettivi del livello di servizio . Impostare soglie di qualità misurabili che riflettono gli impegni aziendali e le aspettative degli utenti. Accettare queste soglie, in quanto forniscono un punto di riferimento per rilevare le deviazioni e risolvere gli errori. Questo approccio protegge l'esperienza utente assicurando che le soglie di qualità del servizio chiave non vengano compromesse. Esaminare e aggiornare regolarmente le metriche di base per assicurarsi che continuino a soddisfare le esigenze e le aspettative correnti dei clienti.

Usare dati di test rappresentativi

I dati di test devono rappresentare scenari reali il più possibile. I dati sintetici possono simulare scenari utente autenticati evitando la complessità della gestione dei dati di produzione. Ad esempio, i test sintetici possono replicare scenari reali generando set di dati rappresentativi per valutare le prestazioni del carico di lavoro in condizioni di ridimensionamento pianificate.

Se è necessario usare i dati di produzione per i test, assicurarsi di rendere anonime correttamente tutte le informazioni per proteggere le informazioni riservate.

Usare i dati sintetici come scelta predefinita. Riservare i dati di produzione per scenari specifici in cui i dati sintetici non possono replicare la complessità necessaria, ad esempio i test degli script di migrazione dei dati.

Simulare l'ambiente di produzione

L'ambiente di produzione è la fonte di verità per comprendere il comportamento del carico di lavoro in condizioni reali. Creare un ambiente che rispecchia attentamente le condizioni reali in modo da poter considerare attendibile che il sistema esegua come previsto nell'ambiente di produzione.

Adatta il tuo approccio agli ambienti di mirroring di produzione in base alle specifiche esigenze del carico di lavoro. Per carichi di lavoro cruciali che richiedono disponibilità elevata, eseguire test in un ambiente dedicato simile alla produzione. Per questi carichi di lavoro, bilanciare attentamente l'ottimizzazione dei costi con la necessità di una convalida affidabile. Usare un ambiente dedicato di produzione per i test di carico e prestazioni per assicurarsi che il comportamento del servizio venga valutato accuratamente in condizioni realistiche.

Per altri carichi di lavoro, fai in modo che l'ambiente rifletta da vicino l'infrastruttura di produzione per ridurre i falsi positivi, casi in cui i test hanno esito positivo in ambienti di sviluppo o test ma hanno esito negativo in produzione. Obiettivo della coerenza in tutti gli ambienti man mano che il codice avanza attraverso la pipeline. Simulare le condizioni di produzione in vari aspetti del carico di lavoro, tra cui infrastruttura, dati e sicurezza, per garantire risultati di test affidabili.

Quando si esegue il mirroring degli ambienti nell'ambiente di produzione, la deviazione della configurazione può creare false confidenza nella qualità. Evitare questo problema implementando controlli di convalida automatizzati per verificare che il tuo ambiente rimanga allineato di configurazione all'ambiente di produzione. Se appropriato, configurare i controlli di distribuzione per verificare che la versione corretta venga distribuita prima dell'inizio del test.

Rischio: Quando si esegue il mirroring degli ambienti di produzione, può aumentare significativamente i costi operativi. Valutare se gli ambienti temporanei o gli ambienti di test permanenti offrono l'equilibrio ottimale tra efficienza dei costi e qualità per il carico di lavoro.

Creare ambienti di test basati su scopo

Progettare ambienti con un chiaro focus sullo scopo previsto. Valutare i requisiti distinti di ogni fase del ciclo di vita dei test e assicurarsi che l'ambiente sia in linea con gli obiettivi di tale fase.

Progettare intenzionalmente ogni ambiente di test in modo che corrisponda alla fase specifica e agli obiettivi dei test, sia per la convalida funzionale, il test di integrazione o altri scopi. Se un ambiente semplificato soddisfa efficacemente le esigenze di test, assegnare la priorità a tale approccio per ottimizzare l'efficienza.

Usare i servizi fittizi

La replica completa dei sistemi di produzione per ogni scenario di test è spesso poco pratica. Valutare quali componenti del carico di lavoro è possibile replicare in modo sicuro per i test senza compromettere i flussi di lavoro aziendali critici. Quando la replica completa non è fattibile, usare servizi fittizi che simulano accuratamente i comportamenti del servizio di produzione per convalidare gli scenari in modo efficace senza rischiare le operazioni in tempo reale.

Gli ambienti di test basati su scopo offrono una base ideale per la distribuzione di servizi fittizi in ambienti temporanei. Gli ambienti temporanei offrono un modo conveniente per simulare le condizioni di produzione per i test. È possibile convalidare interazioni e comportamenti senza il sovraccarico della gestione di ambienti di produzione completi per ogni scenario di test. Questi ambienti su richiesta vengono creati per scopi di test specifici e eliminati dopo l'uso, riducendo i costi dell'infrastruttura mantenendo al contempo la qualità dei test.

La creazione di ambienti temporanei richiede che il carico di lavoro raggiunga un livello di maturità superiore, in cui l'automazione con infrastruttura distribuita come codice (IaC) e le pipeline di distribuzione sono ben consolidate.

Facilitazione di Azure

Piani di test di Azure è una soluzione di gestione dei test basata su browser che fornisce tutte le funzionalità necessarie per i test manuali pianificati, i test di accettazione degli utenti, i test esplorativi e la raccolta di feedback dagli stakeholder. Include Analisi di test per tenere traccia della qualità dei test nel tempo e identificare le aree per il miglioramento.

Azure Pipelines consente di integrare i test nella pipeline CI/CD. È anche possibile usare GitHub Actions integrato con Azure.

Test app di Azure è un servizio che supporta test funzionali e delle prestazioni. Consente di eseguire test funzionali con aree di lavoro Playwright e test delle prestazioni usando Test di carico di Azure.

Gli ambienti di distribuzione di Azure possono aiutare a creare un'infrastruttura di app con modelli basati su progetti che stabiliscono coerenza e procedure consigliate, ottimizzando al contempo la sicurezza.

Azure offre anche strumenti nativi della piattaforma che supportano l'affidabilità, le prestazioni e i test di sicurezza.

Collegamenti correlati

• Raccomandazioni per i test delle prestazioni
• Raccomandazioni per i test di affidabilità
• Raccomandazioni per i test di sicurezza

Lista di controllo di Eccellenza Operativa

Fare riferimento al set completo di raccomandazioni.