continuous testing devops
Che cosa sono i test continui e la pipeline di test continui in DevOps?
Spero vi sia piaciuto l'ultimo tutorial su Distribuzione continua in DevOps .
Conosciamo l'importanza dei test in qualsiasi fornitura di software e DevOps essendo un ciclo di consegne breve, è impossibile eseguire manualmente tutti i casi di test progettati ogni volta, quando una singola riga di codice viene aggiornata nello strumento di controllo della versione ed è lì che continua i test e la pipeline di test continui automatizzati entrano in scena in DevOps.
Letture consigliate => Tutorial di formazione DevOps da zero
Vantaggi della TC:
-
- Qualità e velocità sono gli enormi vantaggi di CT.
- Feedback più rapido e veloce sul codice.
- Aumenta la fiducia del team e lo incoraggia a migliorare continuamente.
VIDEO Parte 3 Blocco 4: Test continuo- 14 minuti e 39 secondi
Trascrizione:
In questo blocco, impareremo Test continui e pipeline di test continui in dettaglio.
come creare un nuovo elenco in java
Il test continuo è un altro processo importante della pipeline di distribuzione continua insieme all'integrazione continua, in una pipeline, include, varie fasi di test in cui i test automatizzati vengono eseguiti insieme ai quality gate automatizzati nel mezzo.
Pertanto, il test continuo consiste nell'esecuzione di test automatizzati, continuamente e ripetutamente sulla base del codice e nei vari ambienti di distribuzione.
Principalmente, unit test, analisi statica del codice, analisi del codice di sicurezza, test di integrazione, test di carico e prestazioni fanno parte di un test continuo che viene eseguito in una pipeline di test continui automatizzati.
Poiché l'integrazione continua e l'implementazione continua sono chiamate CI, CD, il test continuo è più spesso chiamato CT.
Se vedi questo diagramma, che è una pipeline di distribuzione continua, questa pipeline include due pipeline, una è una pipeline di compilazione che è pipeline CI o pipeline di integrazione continua, che consiste in trigger di build automatizzato, compilazione, compilazione e distribuzione.
L'altro è una pipeline di test, che è una pipeline di test continua
Ora vediamo di più sui test continui.
Conosciamo l'importanza del test, del test di ogni riga di codice… .. del test ogni volta… e del test in fasi diverse ed è quasi impossibile eseguire manualmente tutti i test progettati ogni volta quando una riga di codice viene aggiornata nel controllo della versione.
È qui che entra in gioco il test continuo.
come faccio ad aprire un torrent
Quindi, a meno che il codice che entra nella pipeline integrata continua automatizzata, non venga testato accuratamente e garantisca la qualità richiesta, non serve rilasciare il software ai clienti. Voglio dire che la qualità non può essere garantita a meno che il codice non sia stato accuratamente testato.
Quindi, il test continuo, come definito in precedenza, consiste nell'eseguire vari tipi di test, continuamente sulla base del codice e su diversi ambienti in cui viene distribuito, come predefinito e progettato nella pipeline di distribuzione continua.
Come si vede nella figura, gli unit test vengono eseguiti sul server CI stesso, che testa ogni unità del sistema in isolamento.
I test di integrazione avvengono sull'ambiente di integrazione che sostanzialmente verifica i componenti integrati insieme. Test di sistema nell'ambiente di test del sistema in cui il sistema BIG con tutti i componenti e le interfacce integrati viene testato attraverso scenari a livello di sistema in un ambiente di test del sistema e così via.
E la profondità dei test spesso progredisce man mano che la simulazione dell'ambiente si avvicina alla produzione.
I test continui diventano progressivamente più difficili e più lunghi con la progressione verso l'ambiente di produzione poiché è necessario aggiungere lentamente un numero di test e test più complicati man mano che il codice matura e la complessità dell'ambiente avanza.
Non è che gli stessi casi di test vengano eseguiti in tutto, i casi di test devono essere aggiornati ogni volta in fasi diverse e gli script automatici vengono aggiornati, man mano che il codice diventa più maturo, progredisce verso un livello superiore di ambiente in cui anche le configurazioni e l'infrastruttura avanzare, finché non entra in produzione.
Quindi, anche il tempo impiegato per eseguire i test aumenta man mano che il test progredisce verso il punto di rilascio, come il test unitario potrebbe richiedere molto meno tempo per essere eseguito mentre alcuni test di integrazione o alcuni test di sistema o test di carico potrebbero richiedere poche ore per essere eseguiti o potrebbero richiedere pochi giorni per correre.
Qui il test continuo sarebbe principalmente l'esecuzione automatica dei casi di test automatizzati con un trigger. Ma come abbiamo definito in precedenza, la consegna continua coinvolge anche alcuni test e cancelli manuali, in cui alcuni test vengono eseguiti manualmente, prima di entrare in produzione.
Queste porte di qualità intermedie in ogni fase del test e aumentano la fiducia nel codice.
Pertanto, la pipeline di test continui in quanto tale include test unitari insieme a verifiche di sicurezza automatizzate preliminari. Quindi entra in un livello di integrazione del test, in cui vengono eseguiti i test di integrazione automatizzati, quindi a un livello di sistema in cui gli scenari a livello di sistema vengono automatizzati ed eseguiti.
Qui vengono eseguiti anche alcuni scenari di test delle prestazioni.
Quindi si passa al 'Test di accettazione' che fondamentalmente include i casi di test di accettazione del sito automatizzati e quindi infine al 'Test di accettazione dell'utente' che potrebbe essere un'esecuzione manuale e include la partecipazione dell'utente finale per eseguire i test e questo sarà una sorta di firma finale sul prodotto o una funzionalità, in cui il gate manuale viene richiamato e infine distribuito al sito di produzione.
Quindi, fondamentalmente, man mano che i test continui progrediscono, la complessità dei test e l'ambiente di test aumenta e arriva all'ambiente che è più vicino alla produzione come la simulazione.
Non ho bisogno di menzionare specificamente che tutte queste fasi di test includono test di verifica della costruzione, test di sanità mentale, test del fumo e test di regressione, ancora una volta, come ho detto, dipende da ciò che progettiamo nella pipeline di test e consegna continui.
Questa è la tipica pipeline di test continui, beh, può essere progettata dal team in base al tipo di prodotto e ai diversi livelli di test e ai tipi di test richiesti dal prodotto.
Il test continuo richiede l'integrazione del framework di automazione con il controllo della versione e lo strumento CI e i vari strumenti automatizzati per eseguire il test funzionale e non funzionale nelle diverse fasi del test, come:
- Sonar per l'analisi statica del codice,
- Fortifica per un'analisi sicura del codice,
- Selenio per test funzionali,
- Load runner per test di carico ecc.,
Microsoft TFS, Jenkins, chef, puppet sono pochi strumenti disponibili sul mercato per progettare la pipeline CI-CD.
Ma il fatto è che questi strumenti potrebbero non supportare l'automazione end-to-end completa, a seconda dello strumento di controllo della versione utilizzato, quindi poche organizzazioni potrebbero preferire sviluppare i propri framework di automazione, che consentono l'automazione end-to-end della pipeline di distribuzione dal codice impegnarsi nella consegna del codice.
Quindi, essendo il test continuo una parte molto cruciale del test, si garantisce la qualità del prodotto o del rilascio e si dovrebbe essere molto attenti alla selezione di uno strumento, framework, ecc.
Pertanto, l'impostazione della pipeline di test continua corretta richiede un po 'più di tempo nella pipeline di distribuzione continua. Non solo sulla parte dello strumento e del framework, ma anche sulla parte dei casi di test. Il test continuo include anche la definizione della pipeline di distribuzione all'interno.
Perché CT richiede la distribuzione automatizzata della build in vari ambienti in fasi diverse, il che richiede l'automazione della distribuzione e la configurazione degli ambienti tramite script automatizzati.
Questi script automatizzati che includono la configurazione dell'infrastruttura e delle configurazioni dell'ambiente come codice vengono archiviati nello strumento di controllo della versione e la pipeline di consegna lo preleva dallo strumento di controllo della versione per eseguire la distribuzione. Questa è chiamata pipeline di distribuzione.
Ora veniamo ai vantaggi della TC,
Il raggiungimento di qualità e velocità è il più grande vantaggio dei test continui.
A differenza di prima, dove i test venivano eseguiti solo alla fine, il test in tutto è il concetto di test continuo e quindi il test continuo in una pipeline di consegna, consente al team di introdurre porte di qualità ovunque e qualsiasi numero di porte di qualità, desiderano, in ordine per raggiungere il grado di qualità di cui hanno bisogno.
Quindi, se del tutto, il codice non riesce a testare in un punto o gate particolare in una pipeline, il team può tornare indietro e fallire automaticamente l'intera distribuzione fino a quel punto.
Ciò fornisce una chiara indicazione sia al team di sviluppo che a quello operativo che manca qualcosa e il team può lavorare per risolverlo. Quindi, questo è il vantaggio e la flessibilità della pipeline di test continui.
Quindi, l'introduzione di quality gate in varie fasi di test governa meglio la qualità del codice nella pipeline.
Maggiore è il numero di porte che il codice supera, maggiore sarà la fiducia del team nel codice che potrà arrivare alla produzione a un livello di qualità superiore.
Quindi, i test continui aumentano la fiducia del team e lo incoraggiano a migliorare continuamente.
Nel complesso, se il team non trascura davvero nessuno dei fallimenti dei test in nessuna fase di test o quality gate in cantiere, sicuramente i test continui saranno un bonus per il raggiungimento di obiettivi di alta qualità.
Quindi, per concludere sui test continui, proprio dai test unitari eseguiti durante la fase preliminare attraverso i test di accettazione, i test delle prestazioni e anche alcuni test manuali che verranno eseguiti sono MOLTO MOLTO critici per definire i test continui nella pipeline DevOps.
Questo completa la nostra discussione sugli argomenti della Parte 3 di integrazione continua, fornitura continua e test continui.
Nel nostro prossimo tutorial, discuteremo di più su Gestione della configurazione, gestione delle versioni e monitoraggio delle prestazioni delle applicazioni.
come testare il sito Web su browser diversi
Tutorial PREV | PROSSIMO Tutorial
Lettura consigliata
- Distribuzione continua in DevOps
- Consegna continua in DevOps
- I 10 migliori strumenti di test continuo per i test DevOps [Elenco 2021]
- Migliori strumenti di test del software 2021 [Strumenti di automazione del test QA]
- Tutorial sul test DevOps: in che modo DevOps influirà sui test di controllo qualità?
- Riepilogo dei tutorial video DevOps
- Integrazione continua in DevOps
- Download dell'eBook Testing Primer