Så kör du röktester för API:er i din pipeline för kontinuerlig driftsättning
Varje år går fler programvaruföretag över till en mikrotjänstarkitektur med hjälp av programmeringsgränssnitt (APIs), eftersom API:er gör det enkelt för olika team i ett projekt att få åtkomst till varandras resurser. API:er gör det också möjligt för programvaruföretag eller privatpersoner att hämta data från varandra: Twitter har till exempel ett API som används av många småföretag för att hämta tweets som rör deras verksamhet och visa dem på företagets webbsida.
En annan stor fördel med API:er är att de är mindre än en monolitisk applikation, vilket innebär att de kan distribueras ofta. På företaget där jag arbetar har varje team flera API:er, och vi har åtta olika miljöer som vi distribuerar till. Om vi enbart förlitade oss på manuella tester för att verifiera att API:erna hade distribuerats korrekt, skulle vi behöva köra åtta uppsättningar tester för varje API-version. Och om vi distribuerade mer än ett API åt gången, vilket vi ofta gör eftersom våra API:er arbetar tillsammans, skulle vi kunna behöva köra hundratals tester. Och om vi distribuerar varannan vecka skulle dessa tester tillsammans innebära en hel del tröttsamma, repetitiva tester!
Vi har löst problemet genom att konfigurera automatiserade röktester för API:er som körs vid varje distribution, till varje miljö. I den här artikeln beskriver jag hur vi beslutade vad som skulle testas och hur vi konfigurerade våra röktester. Vi använde Postman, Newman, Powershell och Octopus för att konfigurera våra automatiserade röktester, så jag kommer att beskriva vad vi gjorde med dessa verktyg. Dessa strategier kan dock användas i alla pipelines för kontinuerlig distribution (CD).
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Steg ett: Bestäm vad som ska testas
Huvudsyftet med röktester är att utföra några enkla tester på hög nivå för att säkerställa att distributionen lyckades. Det här är inte platsen för att testa allt som ditt API kan göra. När vi valde vad som skulle ingå i våra röktester tog vi hänsyn till följande:
- Vi konfigurerade ett test av en ”lyckad väg” för varje slutpunkt – det vill säga ett test som förväntas lyckas. En GET-begäran för en resurs med ett specifikt ID skulle till exempel förväntas returnera den resursen. Du bör testa varje slutpunkt en gång för att verifiera att den fungerar som förväntat.
- Om det fanns betydande variationer i hur en specifik slutpunkt skulle användas lade vi till ett eller flera tester för att kontrollera dessa variationer. Vi har till exempel ett API för filhämtning där en fil kan hämtas med två olika metoder. Slutpunkten ser likadan ut, men begärandenas innehåll är olika. Därför lade vi till ett test för varje metod.
- För slutpunkter som krävde en viss säkerhetsnivå lade vi till ett test för att validera att en begäran utan lämplig autentisering INTE skulle returnera någon information, utan i stället returnera ett fel på 400-nivå.
- Vi lade inte till några andra negativa tester, till exempel en POST-begäran med data utanför de tillåtna parametrarna, eftersom vi inte ansåg att de behövdes för att säkerställa att API:et fungerade. I stället körde vi dessa tester som en del av en nattlig regressionssvit.
Steg två: Exportera dina tester
Vi använde Postman för att skapa våra API-tester, så när testerna hade skapats exporterade vi både testsamlingen och testmiljöfilen till JSON-filer. För den som inte känner till Postman är en testmiljö en grupp variabler som kan refereras till i en testsamling.
Steg tre: Skriv ett skript för att köra dina tester
Postman har ett kommandoradsverktyg som heter Newman och som kan användas för att köra en testsamling, så det var detta vi använde för att köra våra tester. Vi skapade ett Powershell-skript som skulle köra Newman-kommandot.
Steg fyra: Skapa ett distributionssteg som anropar ditt skript
När Powershell-skriptet var klart konfigurerade vi ett distributionssteg i varje Octopus-projekt för API-distribution som skulle köra testskriptet. Om skriptet misslyckades skulle distributionen misslyckas.
Steg fem: Organisera dina variabler
Variabler är ofta något man måste ta hänsyn till när man kör röktester i olika miljöer. I din QA-miljö kan din testanvändare till exempel ha ID:t 340, medan din testanvändare i din stagingmiljö kan ha ID:t 620. Ett annat problem med variabler är att du ibland av säkerhetsskäl kanske inte har åtkomst till lösenord eller nycklar i produktionsmiljöer. Så var fallet för vårt team, men som tur är har Octopus de värden vi behöver för att köra våra tester i produktion, så vi löste problemet genom att låta Octopus skicka de värden vi behövde till vårt testskript.
Det fanns tre olika typer av variabler som behövdes för vårt röktest:
- Typ 1: Variabler som inte ändrades för någon testmiljö, till exempel “firstName”: “Prunella”. Dessa variabler kunde läggas direkt i Postman-miljön, så inget mer behövde göras med dem.
- Typ 2: Variabler som ändrades för varje testmiljö, men som inte behövde hållas hemliga, till exempel “userId”: 340. Dessa variabler lades till som Octopus-variabler på följande sätt: “smoke.userId”, och variabelns värde angavs för varje miljö; QA angavs till exempel som 340, Staging som 620 och Production som 450.
- Typ 3: Variabler som ändrades för varje testmiljö och behövde hållas säkra, till exempel “apiKey”: “b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. Typ 3-variablerna hade redan angetts i Octopus-variabelbiblioteket.
Vi använde sedan variablerna så här:
- När vi anropade Powershell-skriptet i Octopus skickade vi variablerna som angetts i Octopus till skriptet.
- I Powershell-skriptet tog vi emot Octopus-variablerna och tilldelade dem till Powershell-variabler.
- När vi använde Newman-kommandot i Powershell-skriptet skickade vi variablerna i skriptet till Postman-miljön.
- Newman använde variablerna som skickades i Powershell-skriptet, tillsammans med variablerna i Postman-miljön, för att köra Postman-samlingen.
Med våra API-röktester körande i Octopus för varje API och i varje miljö kan vi känna oss trygga med att alla större problem med en API-distribution upptäcks direkt. Dessutom kan vi testa i produktionsmiljöer även när vi inte har åtkomst till känsliga API-nycklar. Automatiska röktester vid distribution frigör tid för andra typer av tester, till exempel manuell explorativ testning och säkerhetstestning, samt för att skriva mer testautomatisering för nattliga regressionstester.
Prenumerera på The QA Lead-nyhetsbrevet för fler instruktionsguider.
Fortsätt lära dig och lyssna på den här podden: HUR PROGRAMVARA MED ÖPPEN KÄLLKOD FÖRENKLAR INTEGRATION I AUTOMATISERINGSTEKNIK (MED JAMES WALKER OCH SANJAY KUMAR)
