View a markdown version of this page

Test delle funzioni Web Lambda - AWS Lambda
Livelli di test consigliatiEsegui il server HTTP localmenteProva il pacchetto di distribuzioneEsegui il test in un ambiente cloud isolatoAutorizzazione ed esposizione al testVerifica la concorrenza, la scalabilità e la limitazioneEseguite i test di implementazione e ripristino

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 delle funzioni Web Lambda

Web Functions esegue server HTTP standard, quindi puoi testare la maggior parte del comportamento delle applicazioni localmente con i normali strumenti del tuo framework. I test sul cloud sono ancora necessari per convalidare l'autorizzazione IAM, l'accesso ad Amazon S3 AWS Key Management Service e AWS KMS(), gli stati del ciclo di vita di Web Function, la scalabilità, la telemetria e il comportamento multiregionale.

Livelli di test consigliati

La tabella seguente descrive ogni livello di test, cosa convalida e dove viene eseguito.

Livello di test Cosa convalida Dove funziona
Unità Logica aziendale, convalida, decisioni di autorizzazione, serializzazione e gestione degli errori. Sviluppo locale e ambienti di costruzione.
Integrazione HTTP Routes, middleware, header, streaming, timeout, graziose disconnessioni e comportamento del framework. Contro un server di produzione in esecuzione localmente.
Pacchetto File di immissione, dipendenze di produzione, layout dell'archivio, avvio e utilizzo diAWS_LAMBDA_HTTP_ENDPOINT. Dall'archivio esatto caricato dalla pipeline di distribuzione.
Integrazione nel cloud IAM, bucket policy, chiavi, stati del ciclo di vita, comportamento degli endpoint, telemetria e chiamate di servizio downstream. AWS In Account AWS un ambiente isolato o di test.
Carico e resilienza Sicurezza della concorrenza, latenza, limitazione, limiti a valle, rollback e comportamento in caso di guasto a livello regionale. In un ambiente cloud simile alla produzione con controlli espliciti di costi e traffico.

Esegui il server HTTP localmente

Usa un fallback locale perAWS_LAMBDA_HTTP_ENDPOINT, come mostrato in. Minima Express applicazione Puoi anche impostare la variabile in modo esplicito per testare lo stesso percorso di avvio utilizzato da Lambda:

AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js

Invia richieste con il tuo normale client HTTP e verifica i codici di stato, i corpi di risposta, le intestazioni, la convalida delle richieste, il middleware di autenticazione, i timeout, lo streaming e la gestione delle disconnessioni dei client.

Esegui richieste simultanee durante i test di integrazione locali. Verifica lo stato della richiesta globale, le cache modificabili condivise, l'inizializzazione duplicata, le collisioni tra nomi di file e il blocco del ciclo di eventi.

Prova il pacchetto di distribuzione

  1. Installa le dipendenze dal file di blocco impegnato e crea l'archivio utilizzando gli stessi comandi della pipeline di distribuzione.

  2. Estrai l'archivio in una directory pulita. Esegui l'applicazione da quella directory senza accedere alle dipendenze di sviluppo o ai file sorgente non tracciati.

  3. Verificate che il file di immissione configurato esista nel percorso previsto e avviate il server HTTP.

  4. Registra il checksum dell'archivio e l'ID della versione dell'oggetto Amazon S3 utilizzato dalla revisione. Usa questi valori per identificare l'esatto artefatto oggetto del test.

Le funzioni Web vengono eseguite su Arm64. Quando un pacchetto contiene dipendenze native, create e testate tali dipendenze per Linux Arm64 anziché riutilizzare gli artefatti di un computer di sviluppo x86-64. Ad esempio, puoi installare le dipendenze di produzione in un contenitore Arm64:

docker run --rm --platform linux/arm64 \
    --volume "$PWD":/app \
    --workdir /app \
    node:24 \
    npm ci --omit=dev

Esegui il test in un ambiente cloud isolato

  1. Carica l'archivio testato in un bucket Amazon S3 con versione e crea una revisione che faccia riferimento alla versione dell'oggetto risultante.

  2. Esegui il polling della revisione finché non diventa o. Active Failed Fallisci il test con quanto riportato stateReason invece di aspettare all'infinito.

  3. Crea o aggiorna un endpoint di test. Effettua un sondaggio su entrambi state e. updateStatus Per MultiRegion e per PerRegion gli endpoint, verifica ogni stato regionale.

  4. Invia le richieste all'endpoint e verifica la risposta dell'applicazione, i loglambda-web-request-id, le metriche e gli effetti collaterali previsti a valle.

  5. Elimina l'endpoint, la funzione, gli oggetti di test, i gruppi di log e altre risorse di test al termine del test.

Autorizzazione ed esposizione al test

  • Verificate infatti che le richieste non firmate abbiano esito negativo, che i principali consentiti abbiano esito positivo, quelli negati abbiano esito negativo e che l'accesso tra account diversi richieda politiche relative all'identità e alle risorse. IamAuth

  • PerchéApplicationManaged, verifica le credenziali dell'applicazione mancanti, scadute, non corrette e insufficienti. Esegui il test dell'autorizzazione separatamente dall'autenticazione.

  • Testa le richieste di preflight del browser, le origini consentite e negate, le richieste con credenziali e gli header di sicurezza quando i browser chiamano l'endpoint.

  • Quando una porta frontale protegge l'endpoint, verificate che le richieste di origine diretta siano negate e che solo l'identità di front-door o il percorso di rete previsti possano richiamarla.

Verifica la concorrenza, la scalabilità e la limitazione

  • Aumenta gradualmente il carico registrando latenza, risposte 4xx e 5xx, acceleratori, ambienti attivi e utilizzo a valle.

  • Prova la configurazione e in modo indipendente. rateLimit maxEnvironments maxConcurrencyPerEnvironment Usa l'intestazione della lambda-web-error-type risposta (Platform.EndpointRequestThrottle,Platform.AccountRequestThrottle, Platform.EndpointMaxEnvThrottlePlatform.AccountActiveVCPUArm64Throttle, oPlatform.EndpointConcurrentInitThrottle) per confermare quale limite ha prodotto ogni risposta HTTP 429. Registra separatamente le risposte HTTP 503 prive di intestazione. lambda-web-error-type Queste risposte possono indicare una perdita di carico temporanea o un errore interno. Per informazioni dettagliate, vedi Tipi di errore delle funzioni Web.

  • Verifica i picchi di traffico e le partenze a freddo, non solo la produttività in regime stazionario.

  • Utilizza dati di test e chiavi di idempotenza unici. Non riprovate automaticamente le richieste non idempotenti durante un test di carico.

  • Imposta limiti espliciti di traffico, durata e costo prima di iniziare un test di carico. Coordina i test che possono influire sulle quote degli account condivisi o sui sistemi a valle.

Eseguite i test di implementazione e ripristino

In un ambiente di test, implementate due revisioni ed eseguite la stessa procedura di routing ponderata utilizzata in produzione. Verifica che i log o le metriche personalizzate possano attribuire richieste a ciascuna revisione. Attiva deliberatamente le condizioni di rollback, ripristina tutto il traffico alla revisione precedente e conferma che l'oggetto di codice e le dipendenze restino disponibili.

Per un PerRegion endpoint MultiRegion OR, verifica un errore di aggiornamento parziale e verifica che l'automazione della distribuzione rilevi lo stato Regionale non riuscito. Testa l'azione di ripristino e ripeti l'aggiornamento dell'endpoint dopo aver corretto la causa.