Close

Test del software nella continuous delivery

Scopri i vantaggi dei test del software e il loro ruolo nella continuous delivery.


I test del software rappresentano un processo organizzativo nell'ambito dello sviluppo software in cui il software business-critical viene verificato in termini di correttezza, qualità e prestazioni. I test del software vengono utilizzati per garantire che i sistemi aziendali e le funzionalità dei prodotti si comportino correttamente come previsto.

Il test del software può essere un processo manuale o automatico.

  • Il test manuale del software è condotto da un team o da un utente che gestirà manualmente un prodotto software e si assicurerà che si comporti come previsto.
  • Il test automatico del software prevede molti strumenti diversi con funzionalità diverse, che vanno dai controlli isolati di correttezza del codice alla simulazione di un'esperienza di test manuale completa condotta da un utente.

I diversi tipi di test nel software

Confronta diversi tipi di test del software, come unit test, test di integrazione, test funzionali, test di accettazione e molto altro.

Test esplorativi

Scopri cosa sono i test esplorativi e la loro storia. Scopri i pro e i contro dei test esplorativi e quando utilizzarli al meglio.

Introduzione alla code coverage

Scopri come iniziare a usare la code coverage, trovare lo strumento giusto e come calcolarla.

Tutorial sull'esecuzione di test di integrazione

Scopri come eseguire test di integrazione in questo tutorial con Bitbucket Pipelines.

Vantaggi dei test del software


I test del software faranno risparmiare tempo e denaro all'organizzazione riducendo i costi di sviluppo e manutenzione del software. I test del software integrano garanzie di stabilità nello sviluppo di nuove funzionalità. I test assicurano che una funzionalità funzioni come previsto e che gli utenti non riscontrino bug.

I tempi di sviluppo delle nuove funzionalità sono ridotti specificando una serie di test case che la nuova funzionalità deve soddisfare per essere considerata completa e realizzabile. Questo offre agli sviluppatori un obiettivo fisso su cui lavorare per consentire stime temporali più accurate e ridurre l'introduzione di nuovi bug. Una volta disponibili questi test case, i costi complessivi di manutenzione si riducono. I test possono essere eseguiti su una funzionalità già distribuita per verificare che funzioni ancora come previsto.

Livelli dei test del software


I test del software prevedono diversi livelli fondamentali, ognuno dei quali esamina la funzionalità del software da un punto di vista unico all'interno del processo di sviluppo. Diamo un'occhiata a ciascun tipo di test ed esaminiamo il loro uso pratico.

Unit test

Gli unit test sono il livello iniziale dei test del software. Gli unit test sono la strumentazione di controllo della correttezza in ingresso e in uscita per singole unità di codice. L'unità di misura, in questo caso, è una funzione o un metodo di codice autonomo.

Durante gli unit test, le funzioni del codice di produzione vengono eseguite in un ambiente di test con input simulato. L'output della funzione viene quindi confrontato con l'output previsto per quell'input. Se l'output corrisponde a quello previsto, il test è superato. In caso contrario, non è superato. Gli unit test sono un ottimo modo per convalidare le funzioni dei dati derivati.

Un ipotetico esempio di storia utente di uno unit test potrebbe essere: "funzione 2VAL, dati 2 valori x e y restituisce sempre x+y". Lo unit test eseguirebbe quindi 2VAL con due valori e confermerebbe che l'output era x+y. Gli unit test sono ottimi per confermare la correttezza del codice che opera sui valori monetari.

Livelli di test del software: unit test, test di integrazione, test funzionali e test esplorativi

Test di integrazione

Quando un test case del software riguarda più di un'unità, è considerato un test di integrazione. Quando si sviluppa un test case del software, gli unit test possono evolversi rapidamente in test di integrazione. Spesso può essere sviluppato uno unit test che opera in base a una dipendenza da codice di terze parti. La dipendenza in sé non dovrà essere testata e l'integrazione a essa sarà fittizia o simulata.

Test funzionali o end-to-end

I test case che simulano un'esperienza completa a livello di utente sono chiamati test funzionali o test end-to-end. I test end-to-end utilizzano strumenti che simulano il comportamento reale degli utenti. Passaggi comuni in un test end-to-end:

  • Fai clic su questo pulsante
  • Leggi questo testo
  • Invia questo modulo

Considerando il contesto completo di esecuzione dell'esperienza, i test end-to-end verificano la correttezza su tutti i livelli di uno stack software.

Prove esplorative

I test esplorativi sono un esercizio di test in cui ai tester viene assegnato un task definito debolmente da eseguire utilizzando il software in fase di test. Ciò significa che puoi imparare molto sul modo in cui le persone usano il tuo prodotto nella vita reale. Le sessioni di test esplorativi possono persino motivare i propri utenti offrendo premi per il rilevamento del maggior numero di problemi, del miglior difetto o per aver fatto qualcosa di inaspettato con il prodotto.

Uno dei vantaggi dei test esplorativi del software è che chiunque può contribuire al test, esplorando liberamente. I test esplorativi non sono casuali, ma non sono nemmeno controllati da script come i test manuali.

Test del software nella continuous delivery


La continuous delivery sfrutta tutte le strategie di test sopra menzionate per creare una pipeline senza interruzioni che fornisca automaticamente le attività di codice completate. Una configurazione ottimale consentirebbe a uno sviluppatore di eseguire il push del codice completato di recente nella pipeline di continuous delivery per la valutazione. La pipeline eseguirebbe quindi il codice appena inviato attraverso i livelli di test. Se il codice supera il test, verrà eseguito automaticamente il merge e distribuito in produzione. Se invece il codice non supera i test, verrà rifiutato e lo sviluppatore verrà automaticamente informato dei passaggi da seguire per la correzione.

Gli ecosistemi di sviluppo dei linguaggi software più diffusi e affermati presentano un proprio sottoinsieme di ecosistemi di test. Sono disponibili molti strumenti che forniscono utilità per aiutare a instrumentare e sviluppare suite di test. Questi strumenti sono generalmente installati tramite un gestore di pacchetti specifico per il linguaggio di programmazione utilizzato nel progetto.

Oltre alla strumentazione di test, sono disponibili anche strumenti per l'esecuzione e lo sviluppo dei test. È possibile installare vari test runner per fornire i dati di output da una suite di test. Una pratica comune è misurare la "code coverage del test" nell'ambito di un progetto. È possibile utilizzare uno strumento di code coverage per indicare la quantità di codebase coperta in modo adeguato.

Una volta sviluppata una suite di test e dopo aver verificato il suo funzionamento su un progetto locale, in genere la sua integrazione in una pipeline di CD è piuttosto semplice. La maggior parte dei sistemi CD/CI ospitati avrà guide su come integrare una suite di test nella pipeline.

Come rendere i test parte integrante della pipeline di CD


Una vera pipeline di CD automatizzata e a valore aggiunto si basa su solide basi di test. Queste basi iniziano con test case manuali, che si evolvono in soluzioni automatizzate.

Dare priorità alla qualità in ogni fase della pipeline

Tutti, sviluppatori, tester, ecc., sono pienamente responsabili del rapporto di qualità con il cliente. Ogni riga di codice migliora o peggiora l'esperienza del cliente. La suite di test di una pipeline di CD è uno strumento poliedrico per lo sviluppo di codice corretto e di alta qualità. Durante la fase di progettazione del prodotto, si può tenere a mente la suite di test per considerazioni preventive su come sviluppare una funzionalità. La suite di test viene utilizzata principalmente per semplificare il processo di sviluppo, ma può anche essere eseguita in ambienti di staging e produzione per garantirne la qualità.

Consentire agli sviluppatori di verificare la qualità delle funzionalità

La metodologia di test tradizionale sostiene che il test è un processo separato e indipendente rispetto allo sviluppatore. L'assenza degli sviluppatori dal controllo qualità comporta una mancanza di empatia con i clienti da parte del team di sviluppo. Inoltre, la mancanza di coinvolgimento degli sviluppatori nella qualità porta a un peggioramento prolungato dei problemi nella codebase, rendendoli più costosi da risolvere. Questa metodologia è anche costosa in termini di costi organizzativi per i dipendenti, in quanto incoraggia l'assunzione di un team di controllo qualità dedicato.

La continuous delivery promuove la consapevolezza degli sviluppatori e l'empatia con l'esperienza dell'utente finale. Gli sviluppatori hanno il compito di fornire una code coverage del test per le funzionalità che producono e di supervisionarle dagli ambienti di sviluppo a quelli di produzione. Ciò offre agli sviluppatori l'opportunità di gestire e verificare la qualità di una funzionalità.

Integrare il feedback dei clienti

La continuous delivery consente una distribuzione e aggiornamenti rapidi di un progetto software. Ciò consente l'integrazione immediata del feedback dei clienti in un rilascio successivo. In caso di una segnalazione di un problema da parte di un utente, è possibile consultare la suite di test della pipeline di CD per restringere l'ambito dei possibili vettori problematici. I team di sviluppo e test che rispondono rapidamente al feedback dei clienti hanno più successo.

Vuoi creare il tuo ambiente continuous delivery? Ti aiuteremo a iniziare.

Sviluppare una solida strategia di test del software


Quando si elabora una strategia di test del software, è meglio tenere a mente le strategie complessive di prodotto, utente e business. Dovranno essere identificati gli obiettivi di code coverage del test con il valore più elevato.

In un mondo ideale, un progetto software punterebbe a una code coverage del test del 100%, a garanzia che il codice sia privo di bug e funzioni come previsto. Sfortunatamente, nel mondo del business reale, con tempistiche e vincoli di budget, questa prospettiva non è realistica.

Dovrebbero essere prese in considerazione anche diverse strategie di test, a seconda del tipo di software distribuibile. Se il software è un'applicazione basata su GUI, i test end-to-end acquisiranno un'importanza strategica. I progetti di software gratuiti con interfaccia utente headless rinunceranno ai test end-to-end in favore degli unit test.

Una strategia globale per le applicazioni utente basate su GUI è la seguente.

  1. Test end-to-end strumentali su tutti i flussi utente principali, accesso, registrazione, check-out, ecc.
  2. Unit test strumentali su tutte le funzioni di codice di dati sensibili, come gli strumenti per le transazioni monetarie
  3. Test di integrazione strumentali per qualsiasi punto di integrazione di terze parti per garantire che il flusso di dati verso terze parti ed eventuali errori vengano propagati correttamente

Migliorare i test del software con la continuous delivery


La ricerca di un flusso di lavoro di continuous delivery presenta molti vantaggi aziendali. I costi organizzativi dell'assunzione e della gestione di team separati per ruoli di controllo qualità, gestione dei rilasci e test engineering possono essere drasticamente ridotti con un flusso di lavoro basato sulla CD.

La continuous delivery promuove un livello complessivo più elevato di qualità del prodotto rispetto a quello dei flussi di lavoro tradizionali per i test di controllo di qualità. I test sulla CD incoraggiano gli sviluppatori ad assumersi la proprietà e la responsabilità dell'esperienza dell'utente finale e della qualità delle funzionalità distribuite. La CD offre un framework che semplifica l'attenzione e la discussione a livello aziendale sulla qualità del rilascio.

L'implementazione di una solida strategia di test del software è la base della continuous delivery e l'automazione è la chiave per una pipeline di continuous delivery di successo.

Desideri potenziare i test del software? Scopri di più sui test in un ambiente di CD. Puoi anche dare un'occhiata ai nostri tutorial sui test DevOps per scoprire come Atlassian e gli strumenti di terze parti possono integrare i test nel tuo flusso di lavoro.

Claire Maynard
Claire Maynard

Claire is an Atlassian marketing veteran who’s worked across growth, performance, and product marketing throughout her tenure. Currently she drives brand, content, and go-to-marketing strategy for Confluence Cloud. Outside work, you can find Claire surfing, running, or trying out new restaurants in San Francisco or new cities across the globe.


Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Leggi il blog

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up