Back to Manual QA

2. API-testning

7. Vilka typer av API:er känner du till och har arbetat med?
Vanliga API-typer inkluderar REST (Representational State Transfer), SOAP (Simple Object Access Protocol) och GraphQL. Nämn specifikt vilka du har praktisk erfarenhet av.
8. Vad är skillnaden mellan SOAP- och REST-API:er?
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.
9. Vad är skillnaden mellan PUT- och PATCH-förfrågningar?
PUT används för att uppdatera en resurs helt (ersätta den). PATCH används för att tillämpa partiella ändringar på en resurs.
10. Vad är API-kedjning och hur använder du svar mellan förfrågningar?
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.
11. Har du arbetat med Swagger eller cURL? Hur använde du dem?
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'.
12. Hur avgör du om en bugg kommer från frontend eller backend?
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.
13. Får du en svarskropp med statuskod 204?
Nej, statuskod 204 No Content betyder att servern framgångsrikt behandlade begäran, men returnerar inget innehåll.
Vad betyder HTTP-statuskodfamiljerna (1xx-5xx)?
1xx informativa, 2xx lyckade (200 OK, 201 Created, 204 No Content), 3xx omdirigering (301/302/304), 4xx klientfel (400, 401, 403, 404, 422), 5xx serverfel (500, 502, 503). Som SDET verifierar du att API:et returnerar rätt kod för varje scenario — fel kod (t.ex. 200 i stället för 404) är en bugg.
Vad är skillnaden mellan 401 och 403?
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.
Vad är skillnaden mellan 400 och 422?
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.
Vilka HTTP-metoder är säkra och idempotenta?
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.
Vad är skillnaden mellan PUT och PATCH?
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.
Vilka konventioner gäller för design av RESTful-endpoints?
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.
Hur fungerar variabelomfång (scopes) i Postman?
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.
Hur skriver man assertions i ett Postman-testskript?
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.
Varför och hur validerar man svarens schema?
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.