Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Test di applicazioni serverless su AWS

Amazon Web Services (Collaboratoricollaboratori)

Marzo 2026 (cronologia dei documenti)

Questa guida illustra le metodologie per testare applicazioni serverless, descrive le sfide che potresti incontrare durante i test e introduce le best practice. Queste tecniche di test hanno lo scopo di aiutarti a iterare più rapidamente e a rilasciare il codice con maggiore sicurezza.

Questa guida è destinata agli sviluppatori che desiderano stabilire strategie di test per le proprie applicazioni serverless. Puoi utilizzare la guida come punto di partenza per conoscere le strategie di test e poi visitare il repository Serverless Test Samples per vedere esempi di test che seguono i modelli e le procedure consigliate descritti in questa guida. Questa guida descrive le metodologie di test serverless, descrive le sfide che i clienti incontrano quando testano le applicazioni serverless e introduce le migliori pratiche per testare le applicazioni serverless. Queste tecniche hanno lo scopo di aiutare gli sviluppatori a iterare più rapidamente e rilasciare con maggiore sicurezza.

Panoramica di

I test automatizzati sono investimenti fondamentali che aiutano a garantire la qualità delle applicazioni e la velocità di sviluppo. I test accelerano anche il feedback degli sviluppatori. In qualità di sviluppatore, vuoi essere in grado di iterare rapidamente sulla tua applicazione e ottenere feedback sulla qualità del codice. Molti sviluppatori sono abituati a scrivere applicazioni da implementare in un ambiente desktop, direttamente nel sistema operativo o all'interno di un ambiente basato su container. Quando si lavora in ambienti desktop o basati su container, in genere si scrivono test su un codice ospitato interamente sul desktop. Tuttavia, nelle applicazioni serverless, i componenti dell'architettura potrebbero non essere implementabili in un ambiente desktop, ma potrebbero invece esistere solo nel cloud. Un'architettura basata sul cloud può includere livelli di persistenza, sistemi di messaggistica, costrutti di sicurezza e altri componenti. APIs Quando si scrive un codice applicativo basato su questi componenti, potrebbe essere difficile determinare il modo migliore per progettare ed eseguire i test.

Questa guida ti aiuta ad allinearti a una strategia di test che riduce l'attrito e la confusione e aumenta la qualità del codice.

Prerequisiti

Questa guida presuppone che tu abbia familiarità con le nozioni di base dei test automatizzati, incluso il modo in cui vengono utilizzati i test automatizzati del software per garantire la qualità del software. La guida fornisce un'introduzione di alto livello a una strategia di test delle applicazioni serverless e non richiede alcuna esperienza pratica nella scrittura di test.

Definizioni

Questa guida usa i termini seguenti:

Obiettivi

Le best practice riportate in questa guida hanno lo scopo di aiutarti a raggiungere due obiettivi principali:

Aumentare la qualità del software

La qualità di un'applicazione dipende in larga misura dalla capacità degli sviluppatori di testare una varietà di scenari per verificarne la funzionalità. Quando non si implementano test automatici o, più in genere, se i test non coprono adeguatamente gli scenari richiesti, la qualità dell'applicazione non può essere determinata o garantita.

In un'architettura basata su server, i team possono definire facilmente l'ambito di test: qualsiasi codice che viene eseguito sul server applicativo deve essere testato. Gli altri componenti che richiamano il server, o le dipendenze richiamate dal server, sono spesso considerati esterni e non possono essere testati dal team responsabile dell'applicazione sul server.

Le applicazioni serverless sono spesso costituite da unità di lavoro più piccole, ad esempio funzioni AWS Lambda , eseguite nel proprio ambiente. Probabilmente, i team saranno responsabili di molte di queste unità più piccole all'interno di una singola applicazione. Alcune funzionalità delle applicazioni possono essere delegate interamente a servizi gestiti come Amazon Simple Storage Service (Amazon S3) o Amazon Simple Queue Service (Amazon SQS) senza utilizzare alcun codice sviluppato internamente. I modelli tradizionali basati su server per il test del software possono escludere i servizi gestiti considerandoli esterni all'applicazione. Ciò può portare a una copertura inadeguata, in cui gli scenari critici potrebbero essere limitati a test esplorativi manuali o a pochi casi di test di integrazione in cui il risultato varia a seconda dell'ambiente. Pertanto, l'adozione di strategie di test che comprendano comportamenti dei servizi gestiti e configurazioni cloud può migliorare la qualità del software.

Test ai confini dell'architettura

Man mano che le applicazioni serverless crescono, si diffondono naturalmente su più componenti architettonici. Sebbene ciò utilizzi funzionalità AWS distribuite, può rendere difficile la comprensione end-to-end del comportamento.

Identificazione dei confini naturali

Quando progetti la tua architettura seguendo le migliori pratiche serverless (una funzione = un lavoro, disaccoppiamento), noterai i confini naturali tra i sottosistemi. Questi limiti rappresentano punti di separazione logica nell'applicazione.

I confini come contratti di test

Questi confini architettonici sono ottimi candidati per testare i bordi. Tratta ogni limite come un contratto e verifica che si comporti secondo le specifiche definite. Pensate a questi limiti come a delle giunture nella vostra applicazione in cui inserire la convalida dei test.

Vantaggi principali

Di seguito sono riportati i principali vantaggi del test ai confini dell'architettura:

Test ai limiti del codice

Definisci confini chiari del codice separando il codice dell'infrastruttura, come il codice Lambda, dalla tua logica aziendale principale. Questa separazione crea ambiti di test distinti che semplificano la strategia di test.

Lo schema di confine

Stabilisci due limiti di codice chiari nelle tue funzioni Lambda:

Gestore come adattatore (ambito esterno)

Il gestore di funzioni Lambda dovrebbe essere un livello sottile che:

Logica aziendale (ambito interno)

La tua logica aziendale principale dovrebbe:

Vantaggi dei test per ambito

Questo approccio basato sui limiti ti consente di testare la maggior parte del codice come funzioni pure, mantenendo i test Lambda minimi e mirati.

Ridurre il tempo necessario per implementare o modificare le funzionalità

È possibile ridurre al minimo l'effetto dei bug del software e dei problemi di configurazione su costi e pianificazioni rilevando questi problemi durante un ciclo di sviluppo iterativo. Quando uno sviluppatore non riesce a rilevare questi problemi, più persone devono impegnarsi ulteriormente per identificarli.

Un'architettura serverless può includere servizi gestiti che forniscono funzionalità applicative critiche tramite chiamate API. Per questo motivo, il ciclo di sviluppo dovrebbe includere test che convalidino sia il percorso positivo (in cui le interazioni con questi servizi si comportano come previsto) sia il percorso triste (in cui le chiamate falliscono, restituiscono risposte impreviste o si comportano diversamente tra gli ambienti). Senza questi test, è possibile riscontrare problemi derivanti dalle differenze tra l'ambiente locale e l'ambiente distribuito. Quando ciò accade, è necessario dedicare più tempo al tentativo di riprodurre e verificare una correzione, poiché ogni iterazione ora richiede la convalida delle modifiche rispetto a un ambiente diverso dalla configurazione preferita.

Un'adeguata strategia di test serverless migliora i tempi di iterazione fornendo risultati accurati per i test che includono chiamate ad altri servizi.