Slik kjører du API-røyketester i pipelinen for kontinuerlig distribusjon

Hvert år går flere programvareselskaper over til en mikrotjenestearkitektur ved hjelp av Application Programming Interfaces (APIs), fordi API-er gjør det enkelt for ulike team i et prosjekt å få tilgang til hverandres ressurser. API-er gjør det også mulig for programvareselskaper eller enkeltpersoner å hente data fra hverandre: Twitter har for eksempel et API som brukes av mange små bedrifter til å hente ut tvitringer relatert til virksomheten deres, slik at de kan vises på bedriftens nettside.

En annen stor fordel med API-er er at de er mindre enn en monolittisk applikasjon, noe som betyr at de kan distribueres ofte. I selskapet jeg jobber i, har hvert team flere API-er, og vi har åtte forskjellige miljøer som vi distribuerer til. Hvis vi kun skulle ha vært avhengige av manuell testing for å bekrefte at API-ene var distribuert riktig, måtte vi ha kjørt åtte testsett for hver API-utgivelse. Og hvis vi distribuerte mer enn ett API om gangen, noe vi ofte gjør fordi API-ene våre fungerer sammen, kunne vi ha kjørt hundrevis av tester. Og hvis vi distribuerer annenhver uke, vil disse testene utgjøre mye kjedelig, repetitiv testing! 

Vi løste dette problemet ved å sette opp automatiserte smoke-tester for API-er som kjøres ved hver distribusjon, til hvert miljø. I denne artikkelen skal jeg beskrive hvordan vi bestemte hva som skulle testes, og hvordan vi satte opp smoke-testene våre. Vi brukte Postman, Newman, Powershell og Octopus til å sette opp de automatiserte smoke-testene, så jeg skal beskrive hva vi gjorde med disse verktøyene. Disse strategiene kan imidlertid tas i bruk i enhver kontinuerlig distribusjonspipeline (CD).

Trinn én: Bestem hva som skal testes

Hovedformålet med smoke-tester er å utføre noen enkle tester på høyt nivå for å sikre at distribusjonen var vellykket. Dette er ikke stedet for å teste alt API-et kan gjøre. Da vi valgte hva som skulle inngå i smoke-testene våre, vurderte vi følgende:

• Vi satte opp én test for et vellykket scenario for hvert endepunkt – altså én test som forventes å være vellykket. En GET-forespørsel etter en ressurs med en bestemt ID forventes for eksempel å returnere denne ressursen. Du bør teste hvert endepunkt én gang for å bekrefte at det fungerer som forventet.

• Hvis det var store variasjoner i hvordan et bestemt endepunkt ville bli brukt, la vi til én eller flere tester for å kontrollere disse variasjonene. Vi har for eksempel et API for filhenting der en fil kan hentes på to forskjellige måter. Endepunktet ser likt ut, men forespørselsteksten er forskjellig. Derfor la vi til én test for hver metode.

• For endepunkter som krevde et visst sikkerhetsnivå, la vi til en test for å validere at en forespørsel uten riktig autentisering IKKE ville returnere informasjon, men i stedet ville returnere en feil på 400-nivå.

• Vi la ikke til andre negative tester, for eksempel en POST-forespørsel med data utenfor de tillatte parameterne, fordi vi ikke mente at dette var nødvendig for å sikre at API-et fungerte. I stedet kjørte vi disse testene som en del av en nattlig regresjonstestserie.

Trinn to: Eksporter testene dine 

Vi brukte Postman til å opprette API-testene våre, så da testene var opprettet, eksporterte vi både testsamlingen og testmiljøfilen til JSON-filer. For dem som ikke kjenner Postman, er et testmiljø en gruppe variabler som kan refereres til i en samling med tester. 

Trinn tre: Skriv et skript for å kjøre testene dine

Postman har et kommandolinjeverktøy kalt Newman som kan brukes til å kjøre en testsamling, så det var dette vi brukte til å kjøre testene våre. Vi opprettet et Powershell-skript som skulle kjøre Newman-kommandoen. 

Trinn fire: Opprett et distribusjonstrinn for å kalle skriptet ditt

Da Powershell-skriptet var klart, satte vi opp et distribusjonstrinn i hvert Octopus-distribusjonsprosjekt for API-et, som skulle kjøre testskriptet. Hvis skriptet mislyktes, ville distribusjonen mislykkes.

Trinn fem: Organiser variablene dine

Variabler er ofte noe man må ta hensyn til når man kjører smoke-tester i ulike miljøer. I QA-miljøet ditt kan testbrukeren din for eksempel ha ID-en 340, mens testbrukeren din i stagingmiljøet kan ha ID-en 620. Et annet problem med variabler er at du av sikkerhetshensyn noen ganger kanskje ikke har tilgang til passord eller nøkler i produksjonsmiljøer. Dette var tilfellet for teamet vårt, men heldigvis har Octopus verdiene vi trenger for å kjøre testene våre i Production, så vi løste problemet ved å la Octopus sende verdiene vi trengte til testskriptet vårt.

Det var behov for tre forskjellige typer variabler i smoke-testen vår:

• Type 1: Variabler som var uforanderlige for hvert testmiljø, for eksempel «firstName»: «Prunella». Disse variablene kunne legges direkte inn i Postman-miljøet, så det var ikke nødvendig å gjøre noe mer med dem. 

• Type 2: Variabler som ble endret for hvert testmiljø, men som ikke trengte å holdes sikre, for eksempel «userId»: 340. Disse variablene ble lagt til som Octopus-variabler på følgende måte: «smoke.userId», og verdien til variabelen ble angitt for hvert miljø; QA ble for eksempel satt til 340, Staging ble satt til 620, og Production ble satt til 450.

• Type 3: Variabler som ble endret for hvert testmiljø og måtte holdes sikre, for eksempel “apiKey”: “b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. Variabler av type 3 var allerede angitt i Octopus-variabelbiblioteket. 

Deretter brukte vi variablene slik:

1. Da vi kalte PowerShell-skriptet i Octopus, sendte vi variablene som var angitt i Octopus, til skriptet. 
2. I PowerShell-skriptet tok vi imot Octopus-variablene som ble sendt inn, og tilordnet dem til PowerShell-variabler. 
3. Da vi brukte Newman-kommandoen i PowerShell-skriptet, sendte vi variablene i skriptet til Postman-miljøet.
4. Newman brukte variablene som ble sendt inn i PowerShell-skriptet, kombinert med variablene i Postman-miljøet, til å kjøre Postman-samlingen.

Når API-smoketestene våre kjører i Octopus for hvert API og i hvert miljø, kan vi være trygge på at eventuelle store problemer med en API-distribusjon blir oppdaget med en gang. Dessuten kan vi teste i produksjonsmiljøer selv når vi ikke har tilgang til sensitive API-nøkler. Automatiske smoketester ved distribusjon frigjør tid til andre typer testing, for eksempel manuell utforskende testing og sikkerhetstesting, samt til å skrive mer testautomatisering for nattlige regresjonstester. 

For flere veiledninger, abonner på nyhetsbrevet til The QA Lead.

Fortsett å lære, og hør på denne podkasten: SLIK FORENKLER PROGRAMVARE MED ÅPEN KILDEKODE INTEGRASJON INNEN AUTOMATISERINGSTEKNIKK (MED JAMES WALKER OG SANJAY KUMAR)