Handleiding voor het testen van REST API's: Voorbeelden van handmatige testcases

Wat is REST API-testen?

REST API-testen REST API-testen is een open-source webautomatiseringstechniek die wordt gebruikt voor het testen van RESTful API's voor webapplicaties. Het doel van REST API-testen is het vastleggen van de respons van de REST API door verschillende HTTP/S-verzoeken te verzenden om te controleren of de REST API correct werkt. REST API-testen worden uitgevoerd met behulp van de methoden GET, POST, PUT en DELETE.

REST staat voor Representational State Transfer. Het is een architecturale stijl en een benadering voor communicatie die wordt gebruikt bij de ontwikkeling van Web ServicesREST is een logische keuze geworden voor het bouwen van API's, omdat het gebruikers in staat stelt om efficiënt verbinding te maken met en te interageren met cloudservices.

Een API, ofwel Application Programming Interface, is een set programmeerinstructies voor toegang tot een webgebaseerde softwareapplicatie. Met andere woorden, het is een set commando's die door het ene programma worden gebruikt om rechtstreeks met een ander programma te communiceren en elkaars functies te gebruiken om informatie te verkrijgen.

Bijvoorbeeld een Google Een website kan een API hebben voor zoekfuncties, vertalingen en agenda's. Over het algemeen zien API's eruit zoals in het onderstaande voorbeeld, met een servernaam, paden en parameters.

http://<server name>/v1/export/Publisher/Standard_Publisher_Report?format=csv

Maar waarom zou je überhaupt testinspanningen op dit niveau investeren?

Waarom het testen van REST API's belangrijk is

Een REST API bevindt zich tussen de gebruikersinterface en de database, waardoor het de laag is waar de meeste bedrijfslogica zich daadwerkelijk bevindt. Een fout in een prijsregel of een toegangsbeheercontrole komt al in de API-respons aan het licht lang voordat iemand een verkeerd getal op een scherm ziet. Testen op dit niveau zorgt er dus voor dat problemen eerder en dichter bij de oorzaak worden opgespoord.

Snelheid is de tweede reden. Een verzoek wordt binnen milliseconden voltooid en vereist geen browser, geen rendering engine en geen kwetsbare element locators. Een tester kan tientallen endpoints testen in de tijd die één interfacetest nodig heeft om een ​​pagina te laden, en hetzelfde verzoek gedraagt ​​zich identiek, of de front-end nu een website, een mobiele app of een partnerintegratie is.

Stabiliteit is de derde reden. Lay-outs veranderen voortdurend, maar een gepubliceerde REST-omgeving blijft stabiel.tract zal naar verwachting stabiel blijven. Tests die daartegen zijn geschreven, zullen dat ook doen.tracZe zijn bestand tegen herontwerpen, waardoor ze de onderdelen van het product beschermen waarop andere teams daadwerkelijk voortbouwen.

Soorten API-methoden

Er zijn hoofdzakelijk 4 soorten API-testen Methoden: GET, POST, DELETE en PUT.

• Begin– De GET-methode wordt gebruikt om uit tetracInformatie ophalen van de opgegeven server met behulp van een opgegeven URI. Bij gebruik van een GET-verzoek mag dit alleen informatie bevatten die afkomstig is van de opgegeven server.tract-gegevens en mogen geen ander effect op de gegevens hebben.
• POST– Een POST-verzoek wordt gebruikt om een ​​nieuwe entiteit te maken. Het kan ook worden gebruikt om gegevens naar de server te sturen, bijvoorbeeld klantinformatie, het uploaden van bestanden, enz. met behulp van HTML-formulieren.
• PUT– Maak een nieuwe entiteit of update een bestaande.
• VERWIJDEREN– Verwijdert alle huidige representaties van de doelbron die door een URI worden gegeven.

Hoe u de REST-API kunt testen

Voor het testen van een REST API is het nodig dat een applicatie communiceert met een voorbeeld-API. Om een ​​API te testen, heb je twee dingen nodig:

• Testtool/framework om de API aan te sturen
• Schrijf uw eigen code op om de voorbeeld-REST API te testen

Testcases voor REST API's kunnen worden getest met tools zoals:

• Geavanceerde rustclient
• Postman- Rust cliënt
• Krul in Linux

Hier gebruiken we Advanced Rest Client. Hieronder volgen de stappen om Advanced Rest Client te verkrijgen.

Hoe krijg ik een geavanceerde REST-client?

• Ga naar Google Chrome's Webwinkel
• Zoek naar “Advanced Rest Client” of ga direct hier en Installeer de extensie
• Selecteer het pictogram 'Advanced Rest Client' onder het app-gedeelte van Chrome - chrome://apps/

De webwinkelpagina ziet er als volgt uit.

Zodra de installatie is voltooid, volg dan de onderstaande test om een ​​test uit te voeren. RESTful API.

Stappen voor het testen van de REST API

Hier gebruiken we de REST-clientextensie in de Chrome-browser. Om het duidelijk te maken, gebruiken we een dummy-API voor testdoeleinden:

http://ip.jsontest.com/

Stap 1) Open de geavanceerde REST-client

Start de app Advanced REST client (ARC) zodra deze succesvol is geïnstalleerd.

Stap 2) Voer de in URL API om te testen

Voer de voorbeeld-REST-API in URL voor testen in de URL tekstvak.

Stap 3) Selecteer de HTTP-methode

Selecteer de methode voor het type HTTP-methoden dat bij API-testen moet worden gebruikt, bijvoorbeeld POST

Stap 4) Geef headers op

Geef Headers Set op in het Headers-tekstvak. Klik op Insert header set.

Stap 5) Bevestig de ingestelde headers

Klik vervolgens op GEBRUIK DEZE SET.

Stap 6) Geef de vereiste lichaamsinhoud op

1. Schakel nu over naar het Body-tabblad.
2. Stel het vereiste Body-inhoudstype en Editor-weergave in, bijvoorbeeld Body-inhoudstype: application/json
3. Editorweergave: onbewerkte invoer.
4. Geef onder Payload de request body van de demo-API door voor testdoeleinden in de vorm van sleutel-waardeparen, bijvoorbeeld {“key1″:”value1″,”key2″:”value2”}. Als het een POST-API betreft, moeten we een body of parameters meesturen. Deze geven we door onder de opgegeven payload.

{"property" : ["Sites"], "report_type" : ["ALL"]}

⚠️ Waarschuwing: Een Content-Type van application/json met een ongeldige payload. JSON Geeft een 400 Bad Request-foutmelding terug.

Stap 7) Dien de gegevens in om de test te starten

1. Druk op de verzendknop.
2. U kunt op de knop DETAILS klikken om de antwoordheaders te bekijken.

Hier zijn de antwoorddetails:

De reactie moet nog steeds worden beoordeeld aan de hand van een verwacht resultaat.

Validatie van de resultaten

Voor het testen van web-API's moeten we met name de responsstatuscode, het responsbericht en de responsbody controleren.

De responscodes vallen in vijf categorieën:

Hieronder staan ​​de mogelijke responscodes die men kan tegenkomen.

Eén enkele aanvraag bewijst dat het eindpunt werkt. Een reeks aanvragen bewijst dat het blijft werken.

Testcases voor REST API's die u absoluut moet behandelen

Een nuttige suite van REST API's is onderverdeeld in verschillende categorieën in plaats van steeds dezelfde succesvolle API-aanroep met verschillende gegevens te herhalen:

• Het gelukkige pad: Verstuur een geldig verzoek naar elk eindpunt en bevestig de statuscode, het schema en elke veldwaarde.
• Negatieve gevallen: Als je onjuist opgemaakte JSON, een niet-ondersteunde methode en een ontbrekende resource-ID verstuurt, kun je 400-, 405- en 404-fouten verwachten in plaats van 500-fouten.
• Grenswaarden: Als een veld 1 tot 200 tekens accepteert, test dan 0, 1, 200 en 201. Validatieregels werken niet meer aan de randen.
• Speciale tekens: Voer geaccentueerde letters, emoji, aanhalingstekens en tekst met meerdere bytes door elk veld om coderingsfouten aan het licht te brengen.
• mettract controleert: Vergelijk het antwoord met de gepubliceerde OpenAPI- of Swagger-specificatie, zodat ongedocumenteerde wijzigingen vroegtijdig worden opgespoord.
• Volgorde aanbrengen in: Roep de eindpunten aan in een realistische volgorde, bijvoorbeeld eerst POST, dan GET en dan DELETE, omdat de status tussen de aanroepen behouden blijft.
• Prestatieverstand: Registreer de responstijden bij elke testrun en markeer elk eindpunt dat de met het team overeengekomen drempelwaarde overschrijdt.

REST API-testtool

Verschillende tools zijn geschikt voor verschillende testfasen.

Bekijk het overzicht van API-testtools.

De meeste echte eindpunten weigeren te reageren totdat het verzoek bewijst wie het heeft verzonden.

Authenticatie en beveiligingscontroles voor REST API

Openbare demo-endpoints beantwoorden ieders vraag, maar een REST API in productieomgevingen werkt met een authenticatieschema, en een autorisatiefout is veel schadelijker dan een onjuiste veldwaarde. Identificeer eerst het mechanisme: een statische API-sleutel, HTTP Basic-referenties, een OAuth 2.0 bearer-token of een ondertekend JSON Web Token.

Zodra een geauthenticeerd verzoek succesvol is, doorloop dan doelbewust de mogelijke foutscenario's:

1. Geen inloggegevens: Verwijder de Authorization-header. Verwacht een 401 Unauthorized-fout en geen recordgegevens in de body.
2. Onjuist opgemaakte inloggegevens: Een van de tekens van het token is beschadigd. Verwacht opnieuw een 401-fout, met een bericht dat niet uitlegt waarom.
3. Verlopen inloggegevens: Een token hergebruiken nadat de vervaldatum is verstreken. Bevestigen dat het wordt afgewezen in plaats van geaccepteerd, een veelvoorkomend probleem dat te maken heeft met een verkeerde klok.
4. Onjuist privilege-niveau: Authenticeer als een gebruiker met lage privileges en roep een endpoint aan dat alleen toegankelijk is voor beheerders. Verwacht een 403 Forbidden-fout, geen 200.
5. Record van een andere gebruiker: Wijzig de ID zodat gebruiker A de gegevens van gebruiker B opvraagt. Als dit lukt, is dat een ernstig toegangsbeheerprobleem.

Controleer tot slot of alle aanroepen via HTTPS verlopen en of mislukte reacties geen stacktrace lekken. traces of versiebanners, en dat snelle herhalingen een 429 Too Many Requests-fout veroorzaken.

Het testen van REST API's brengt ook moeilijkheden met zich mee die bij interfacetesten niet voorkomen.

Uitdagingen voor API-testen

De interessante problemen waar testers mee te maken krijgen bij het testen van REST API's zijn:

1. Om ervoor te zorgen dat de testharness de parameters van de API-aanroepen zodanig varieert dat zowel de functionaliteit wordt geverifieerd als de fouten aan het licht komen. Dit omvat het onderzoeken van randvoorwaarden en het toewijzen van gemeenschappelijke parameters.
2. Interessante parameterwaardecombinaties maken voor oproepen met twee of meer parameters
3. Het bepalen van de context waaronder de API-aanroepen moeten worden gedaan. Dit kan het instellen van externe omgevingsfactoren omvatten (randapparatuur, bestanden, enz.) evenals intern opgeslagen gegevens die van invloed zijn op de API.
4. Sequencing van API-aanroepen volgens de volgorde waarin de functie wordt uitgevoerd
5. Om de API nuttige resultaten te laten produceren uit opeenvolgende oproepen.

Veelgestelde vragen