2. API-testning

Vanliga API-typer inkluderar REST (Representational State Transfer), SOAP (Simple Object Access Protocol) och GraphQL. Nämn specifikt vilka du har praktisk erfarenhet av.

SOAP är ett protokoll som använder XML för meddelandeformat och är mer strikt. REST är en arkitektonisk stil som kan använda flera format (XML, JSON, HTML, etc.) och är generellt mer flexibel och lättviktig.

API-kedjning är processen att använda svaret från en API-begäran som indata (begäranparameter) för en efterföljande API-begäran. Detta är vanligt vid testning av komplexa arbetsflöden.

Swagger används för API-dokumentation och testning via ett gränssnitt. cURL är ett kommandoradsverktyg för att överföra data med URL:er. Förklara din specifika användning, t.ex. 'Jag använder Swagger för att förstå ändpunkter och cURL för att snabbt verifiera svar från terminalen'.

Inspektera nätverksfliken i webbläsarens utvecklarverktyg. Om API-begäran skickar korrekt data men returnerar ett fel eller felaktig data, är det troligen ett backend-problem. Om API:et returnerar korrekt data men UI visar det fel, är det ett frontend-problem.

Nej, statuskod 204 No Content betyder att servern framgångsrikt behandlade begäran, men returnerar inget innehåll.

401 Unauthorized betyder att du inte är autentiserad — servern vet inte vem du är, så logga in. 403 Forbidden betyder att du är autentiserad men saknar behörighet till resursen. Minnesregel: 401 = vem är du?, 403 = jag vet vem du är, men nej.

400 Bad Request betyder att själva begäran är felformaterad — ogiltig JSON, saknade obligatoriska fält, fel format. 422 Unprocessable Entity betyder att formatet är korrekt men värdena bryter mot affärsregler (t.ex. ogiltig e-post eller negativt pris). Båda är klientfel men pekar på olika buggar.

Säker = ändrar inte serverns tillstånd: GET, HEAD, OPTIONS. Idempotent = att anropa N gånger ger samma effekt som en gång: GET, HEAD, OPTIONS, PUT, DELETE. POST är ingendera (varje anrop kan skapa en ny resurs). PATCH garanteras inte idempotent. Detta är viktigt för retry-logik och testdesign.

PUT ersätter hela resursen — fält du utelämnar försvinner. PATCH uppdaterar bara de fält du skickar och lämnar resten orörda. Vanlig intervjufälla: PUT /users/42 med enbart {namn} raderar e-post och ålder; PATCH med {namn} behåller dem.

Använd resursnamn i plural (/users, inte /getUser); inga verb i URL:en (HTTP-metoden är verbet); nästla relaterade resurser (/users/42/orders); använd query-parametrar för filtrering, sortering och paginering (?category=x&page=2&sort=price). Alltså: GET /users, POST /users, GET /users/42, PATCH /users/42, DELETE /users/42.

Från mest lokal till mest global: data (CSV/JSON för datadrivna körningar), local (inom en requests skript), environment (per dev/stg/prod), collection (delad i hela samlingen), global. Referera som {{baseUrl}}/users/{{userId}}. Lägg miljöspecifika värden (baseUrl, inloggning) i environment och delade konstanter i collection.

Använd pm.test med pm.expect (Chai): pm.test('Status 200', () => pm.response.to.have.status(200)). Kontrollera JSON-kroppen med pm.expect(body).to.have.property('id'), typer med .to.be.a('number'), och att hemligheter inte läcker med .to.not.have.property('password'). Du kan även verifiera att svarstiden är under en gräns.

Schemavalidering kontrollerar svarets struktur — obligatoriska fält, typer, intervall, enums, tillåtna värden — oberoende av exakt data. Den fångar kontraktsregressioner (ett omdöpt eller saknat fält) som värde-assertions missar. I praktiken använder du JSON Schema med en validator som ajv eller joi, och verifierar att svaret matchar innan du kontrollerar enskilda värden.

Nej, det är inte nödvändigt att faktiskt skicka riktiga notifikationer. Istället bör man mocka eller simulera de externa API:erna och tjänsterna. Detta tillvägagångssätt gör det möjligt att testa notifikationslogiken utan att vara beroende av tredjepartstjänster, och det är god praxis för att lära sig mocka externa beroenden i sin testsvit. Om man vill använda en riktig tjänst för integrationstestning är AWS SNS ett bra alternativ som täcker både SMS och push-notifikationer.

Det allmänna tillvägagångssättet är: 1) Avgränsa problemet — fastställ var (vilken tjänst eller process) och när (under vilka förhållanden) felet uppstår. 2) Kontrollera befintliga loggar i den felande tjänsten eller processen; om de saknas, implementera loggning i API:erna för att registrera varje HTTP-anrop tillsammans med dess svarskod (t.ex. 200 OK, 500 Server Error, 400 Bad Request). Använd try/catch-block för att fånga och registrera fel. Överväg centraliserade molnloggningsverktyg som AWS CloudWatch. 3) När du har data, försök reproducera felet konsekvent för att kunna analysera det. 4) Undersök vanliga orsaker till intermittenta fel: uttömda anslutnings-/request-pooler (vilket leder till 500-fel när gränsen nås), nätverks- eller infrastrukturproblem (t.ex. duplicerade IP-adresser) eller tillfälliga problem hos tredjepartstjänster. 5) Utforma en åtgärdsstrategi som kan inkludera återförsöksmekanismer (retries), ett circuit breaker-mönster för att förhindra kaskaderande fel, ett meddelandekösystem som håller kvar misslyckade förfrågningar och automatiskt försöker igen, eller schemalagda jobb (t.ex. ett cron-jobb var 30:e minut) för att återbearbeta misslyckade poster. 6) Upprätthåll en historisk logg över fel för att identifiera mönster över tid.