Come eseguire i test di smoke API nella pipeline di distribuzione continua
Ogni anno, sempre più aziende di software passano a un'architettura a microservizi utilizzando le Application Programming Interfaces (API), perché le API facilitano l’accesso alle risorse tra i diversi team di un progetto. Le API permettono anche alle aziende di software o ai singoli di ottenere dati l’uno dall’altro: ad esempio, Twitter ha un’API usata da molte piccole imprese per recuperare i tweet relativi alla propria attività da mostrare sulla pagina web dell’azienda.
Un altro grande vantaggio delle API è che sono più leggere rispetto a un’applicazione monolitica, il che significa che possono essere distribuite frequentemente. Nell’azienda in cui lavoro, ogni team ha diverse API e disponiamo di otto differenti ambienti su cui effettuiamo il deploy. Se ci affidassimo solo ai test manuali per verificare che le API siano state distribuite correttamente, dovremmo eseguire otto set di test per ogni rilascio dell’API. E se distribuiamo più di una API contemporaneamente, come spesso accade dato che le nostre API lavorano insieme, potremmo dover eseguire centinaia di test. E se distribuiamo ogni due settimane, questi test sarebbero davvero tanti e ripetitivi!
Abbiamo risolto questo problema impostando dei test smoke automatici per le API, che vengono eseguiti ad ogni deploy, in ogni ambiente. In questo articolo, descriverò come abbiamo deciso cosa testare e come abbiamo impostato i nostri test smoke. Per configurare i test smoke automatici abbiamo utilizzato Postman, Newman, Powershell e Octopus, quindi spiegherò ciò che abbiamo fatto con questi strumenti. Tuttavia, queste strategie possono essere adottate in qualsiasi pipeline di distribuzione continua (CD).
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Fase Uno: Decidere Cosa Testare
Lo scopo principale dei test smoke è eseguire dei test semplici e di alto livello per garantire che il deploy sia andato a buon fine. Questo non è il momento di testare ogni singola funzionalità della vostra API. Quando abbiamo scelto cosa inserire nei nostri test smoke, abbiamo considerato quanto segue:
- Abbiamo impostato un test “Happy Path” per ogni endpoint, ovvero un test che ci aspettiamo abbia successo. Ad esempio, una richiesta GET per una risorsa con un ID specifico dovrebbe restituire proprio quella risorsa. È consigliabile testare ogni endpoint una volta per verificare che funzioni come previsto.
- Se esistevano variazioni importanti su come un endpoint poteva essere utilizzato, abbiamo aggiunto uno o più test per verificare tali variazioni. Ad esempio, abbiamo un’API di recupero file in cui un file può essere recuperato con due metodi diversi. L’endpoint è lo stesso, ma i corpi delle richieste sono diversi. Quindi abbiamo inserito un test per ciascun metodo.
- Per gli endpoint che richiedevano un certo livello di sicurezza, abbiamo aggiunto un test per verificare che una richiesta senza l’autenticazione appropriata NON restituisse informazioni, ma restituisse invece un errore di tipo 400.
- Non abbiamo inserito altri test negativi, come una richiesta POST con dati al di fuori dei parametri consentiti, perché non li abbiamo ritenuti necessari per garantire il funzionamento dell’API. Questi test vengono invece eseguiti come parte della suite di regressione notturna.
Fase Due: Esporta i Tuoi Test
Abbiamo usato Postman per creare i nostri test delle API: al termine, abbiamo esportato sia la collezione di test che il file di ambiente di test in file JSON. Per chi non conoscesse Postman, un ambiente di test è un insieme di variabili che può essere richiamato in una raccolta di test.
Fase Tre: Scrivi uno Script per Eseguire i Tuoi Test
Postman ha uno strumento da linea di comando chiamato Newman, che può essere utilizzato per eseguire una raccolta di test, quindi è quello che abbiamo usato per far girare i nostri test. Abbiamo creato uno script Powershell che eseguisse il comando Newman.
Fase Quattro: Crea uno Step di Deploy che Chiami il Tuo Script
Una volta pronto lo script Powershell, abbiamo impostato uno step di deploy in ogni progetto di deploy API su Octopus che eseguisse lo script di test. Se lo script falliva, anche il deploy falliva.
Fase Cinque: Organizza le Tue Variabili
Le variabili sono spesso un aspetto importante quando si eseguono test smoke in diversi ambienti. Ad esempio, nel tuo ambiente QA l’utente di test potrebbe avere un ID pari a 340, ma nell’ambiente Staging l’utente di test potrebbe avere un ID pari a 620. Un altro problema con le variabili è che, a volte, per ragioni di sicurezza, potresti non avere accesso a password o chiavi negli ambienti di produzione. Questo è stato il caso anche per il nostro team, ma fortunatamente Octopus aveva i valori di cui avevamo bisogno per eseguire i test in produzione, così abbiamo risolto facendo passare ad Octopus i valori necessari allo script di test.
Per i nostri test smoke erano necessari tre diversi tipi di variabili:
- Tipo 1: Variabili che non cambiavano per ciascun ambiente di test, ad esempio “firstName”: “Prunella”. Queste variabili potevano essere inserite direttamente nell’ambiente Postman, quindi non era necessario fare altro.
- Tipo 2: Variabili che cambiavano in base all’ambiente di test, ma che non dovevano essere protette, ad esempio “userId”: 340. Queste variabili sono state aggiunte come variabili Octopus in questo modo: “smoke.userId”, e il valore della variabile è stato impostato per ciascun ambiente; per esempio, QA era impostato su 340, Staging su 620 e Produzione su 450.
- Tipo 3: Variabili che cambiavano per ogni ambiente di test e dovevano essere mantenute sicure, come “apiKey”: “b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. Le variabili di tipo 3 erano già state impostate nella libreria delle variabili di Octopus.
Abbiamo poi utilizzato le variabili in questo modo:
- Quando abbiamo chiamato lo script Powershell in Octopus, abbiamo inviato le variabili impostate in Octopus allo script.
- Nello script Powershell, abbiamo accettato le variabili di Octopus ricevute e le abbiamo assegnate a variabili Powershell.
- Quando abbiamo utilizzato il comando Newman nello script Powershell, abbiamo inviato le variabili presenti nello script all'ambiente Postman.
- Newman ha utilizzato le variabili inviate nello script Powershell, combinate con le variabili dell’ambiente Postman per eseguire la collezione Postman.
Con i nostri smoke test API eseguiti in Octopus per ogni API e in ogni ambiente, possiamo essere sicuri che qualsiasi problema importante relativo a un deployment API verrà individuato immediatamente. Inoltre, possiamo testare negli ambienti di Produzione anche quando non abbiamo accesso alle chiavi API sensibili. Disporre di smoke test di deploy automatici ci libera tempo per svolgere altri tipi di test, come il testing esplorativo manuale e il testing di sicurezza, oltre a scrivere altra automazione dei test per le regressioni notturne.
Per altre guide pratiche, iscriviti alla newsletter di The QA Lead.
Continua a imparare e ascolta questo podcast: COME IL SOFTWARE OPEN SOURCE SEMPLIFICA L'INTEGRAZIONE NELL'ENGINEERING DELL'AUTOMAZIONE (CON JAMES WALKER E SANJAY KUMAR)
