Sådan kører du API-smoketests i din pipeline til kontinuerlig implementering

Hvert år skifter flere softwarevirksomheder til en mikroservicearkitektur ved hjælp af applikationsprogrammeringsgrænseflader (APIs), fordi API’er gør det nemt for forskellige teams i et projekt at få adgang til hinandens ressourcer. API’er gør det også muligt for softwarevirksomheder eller enkeltpersoner at hente data fra hinanden: Twitter har for eksempel en API, som mange små virksomheder bruger til at hente tweets, der vedrører deres virksomhed, så de kan vises på virksomhedens webside.

En anden stor fordel ved API’er er, at de er mindre end en monolitisk applikation, hvilket betyder, at de kan implementeres ofte. I den virksomhed, hvor jeg arbejder, har hvert team flere API’er, og vi har otte forskellige miljøer, som vi implementerer til. Hvis vi udelukkende var afhængige af manuel test for at kontrollere, at API’erne var blevet implementeret korrekt, skulle vi køre otte testsæt for hver API-udgivelse. Og hvis vi implementerede mere end én API ad gangen, hvilket vi ofte gør, fordi vores API’er arbejder sammen, kunne vi komme til at køre hundredvis af tests. Og hvis vi implementerer hver anden uge, vil disse tests udgøre en masse kedelig, gentagende testning! 

Vi har løst dette problem ved at opsætte automatiserede smoke-tests af API’er, som køres ved hver implementering til hvert miljø. I denne artikel beskriver jeg, hvordan vi besluttede, hvad der skulle testes, og hvordan vi opsatte vores smoke-tests. Vi brugte Postman, Newman, PowerShell og Octopus til at opsætte vores automatiserede smoke-tests, så jeg vil beskrive, hvad vi gjorde med disse værktøjer. Disse strategier kan dog anvendes i enhver pipeline til kontinuerlig implementering (CD).

Trin et: Beslut, hvad der skal testes

Det primære formål med smoke-tests er at udføre nogle enkle tests på højt niveau for at sikre, at implementeringen lykkedes. Dette er ikke stedet, hvor du skal teste alt, hvad din API kan gøre. Da vi valgte, hvad der skulle med i vores smoke-tests, overvejede vi følgende:

• Vi opsatte én test af den forventede positive sti for hvert slutpunkt – altså én test, som forventes at lykkes. For eksempel forventes en GET-anmodning efter en ressource med et bestemt ID at returnere den pågældende ressource. Du bør teste hvert slutpunkt én gang for at kontrollere, at det fungerer som forventet.

• Hvis der var større variationer i, hvordan et bestemt slutpunkt ville blive brugt, tilføjede vi en eller flere tests for at kontrollere disse variationer. Vi har for eksempel en API til filhentning, hvor en fil kan hentes på to forskellige måder. Slutpunktet ser ens ud, men anmodningernes brødtekst er forskellig. Derfor tilføjede vi én test for hver metode.

• For slutpunkter, der krævede et bestemt sikkerhedsniveau, tilføjede vi en test for at validere, at en anmodning uden den relevante godkendelse IKKE ville returnere oplysninger, men i stedet ville returnere en fejl på 400-niveau.

• Vi tilføjede ikke andre negative tests, såsom en POST-anmodning med data uden for de tilladte parametre, fordi vi ikke mente, at de var nødvendige for at sikre, at API’en fungerede. I stedet kørte vi disse tests som en del af en natlig regressionstestpakke.

Trin to: Eksportér dine tests 

Vi brugte Postman til at oprette vores API-tests, så da testene var oprettet, eksporterede vi både testsamlingen og testmiljøfilen til JSON-filer. For dem, der ikke er bekendt med Postman, er et testmiljø en gruppe variabler, der kan refereres til i en samling af tests. 

Trin tre: Skriv et script til at køre dine tests

Postman har et kommandolinjeværktøj kaldet Newman, som kan bruges til at køre en testsamling, så det var dette, vi brugte til at køre vores tests. Vi oprettede et PowerShell-script, som skulle køre Newman-kommandoen. 

Trin fire: Opret et implementeringstrin, der kalder dit script

Da PowerShell-scriptet var klar, opsatte vi et implementeringstrin i hvert Octopus-implementeringsprojekt for API’er, som skulle køre testscriptet. Hvis scriptet mislykkedes, ville implementeringen mislykkes.

Trin fem: Organisér dine variabler

Variabler er ofte noget, man skal tage højde for, når man kører smoke-tests i forskellige miljøer. I dit QA-miljø har din testbruger for eksempel måske et ID på 340, mens din testbruger i dit stagingmiljø måske har et ID på 620. Et andet problem med variabler er, at du af sikkerhedsmæssige årsager nogle gange måske ikke har adgang til adgangskoder eller nøgler i produktionsmiljøer. Det var tilfældet for vores team, men heldigvis har Octopus de værdier, vi skal bruge for at køre vores tests i produktion, så vi løste problemet ved at lade Octopus videregive de værdier, vi havde brug for, til vores testscript.

Der var brug for tre forskellige slags variabler til vores smoke-test:

• Type 1: Variabler, der var uændrede for hvert testmiljø, såsom “firstName”: “Prunella”. Disse variabler kunne placeres direkte i Postman-miljøet, så der var ikke behov for at gøre mere med dem. 

• Type 2: Variabler, der ændrede sig for hvert testmiljø, men som ikke behøvede at blive holdt sikre, såsom “userId”: 340. Disse variabler blev tilføjet som Octopus-variabler på følgende måde: “smoke.userId”, og variablens værdi blev angivet for hvert miljø; QA blev for eksempel angivet til 340, Staging til 620 og Production til 450.

• Type 3: Variabler, der ændrede sig for hvert testmiljø og skulle holdes sikre, såsom “apiKey”: “b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. Type 3-variabler var allerede blevet angivet i Octopus-variabelbiblioteket. 

Vi brugte derefter variablerne således:

1. Da vi kaldte PowerShell-scriptet i Octopus, sendte vi de variabler, der var angivet i Octopus, til scriptet. 
2. I PowerShell-scriptet accepterede vi de indsendte Octopus-variabler og tildelte dem til PowerShell-variabler. 
3. Da vi brugte Newman-kommandoen i PowerShell-scriptet, sendte vi variablerne i scriptet til Postman-miljøet.
4. Newman brugte de variabler, der blev sendt i PowerShell-scriptet, kombineret med variablerne i Postman-miljøet, til at køre Postman-samlingen.

Da vores API-smoketests køres i Octopus for hver API og i hvert miljø, kan vi være sikre på, at eventuelle større problemer med en API-udrulning bliver opdaget med det samme. Desuden kan vi teste i produktionsmiljøer, selv når vi ikke har adgang til følsomme API-nøgler. Automatiske smoketests ved udrulning frigiver tid til andre typer test, såsom manuel eksplorativ testning og sikkerhedstest, samt til at skrive mere testautomatisering til natlige regressionstests. 

Du kan finde flere vejledninger ved at abonnere på The QA Lead-nyhedsbrevet.

Bliv ved med at lære, og lyt til denne podcast: SÅDAN FORENKLER OPEN SOURCE-SOFTWARE INTEGRATION I AUTOMATISERINGSTEKNIK (MED JAMES WALKER OG SANJAY KUMAR)