api testing tutorial
In deze diepgaande zelfstudie over API-testen wordt alles uitgelegd over API-testen, webservices en hoe u API-testen in uw organisatie kunt introduceren:
Krijg diepgaand inzicht in API-testen, samen met het concept van shift-left-testen en webservices in deze inleidende tutorial.
gratis tijdkloksoftware voor kleine bedrijven
Concepten als Web API, hoe API werkt (met real-world voorbeeld) en hoe het verschilt van Web Services worden goed uitgelegd met voorbeelden in deze tutorial.
NAAR BENEDEN SCROLLENom de volledige lijst met 5 uitgebreide API-testhandleidingen voor beginners te bekijken
Wat je leert:
- Lijst met tutorials voor API-testen
- Overzicht van zelfstudies in deze API-testserie
- Zelfstudie over API-testen
- Introductie van API-testen in uw organisatie
- Gevolgtrekking
Lijst met tutorials voor API-testen
Tutorial # 1: API-testhandleiding: een complete gids voor beginners
Tutorial # 2: Webservices-zelfstudie: componenten, architectuur, typen en voorbeelden
Tutorial # 3: Top 35 ASP.Net en Web API interviewvragen met antwoorden
Tutorial # 4: POSTMAN-zelfstudie: API-testen met POSTMAN
Tutorial # 5: Webservices testen met Apache HTTP-client
Overzicht van zelfstudies in deze API-testserie
Tutorial # | Wat je leert | |
---|---|---|
LoadFocus | Op basis van het aantal gebruikers en de soorten plannen | * Kan worden gebruikt voor API-belastingtests - maakt het mogelijk om enkele tests uit te voeren om erachter te komen hoeveel gebruikers een API kan ondersteunen. * Eenvoudig te gebruiken - maakt het uitvoeren van tests in de browser mogelijk. |
Tutorial_ # 1: | API-testhandleiding: een complete gids voor beginners In deze diepgaande zelfstudie over API-testen wordt alles over API-testen en webservices in detail uitgelegd en leert u ook hoe u API-testen in uw organisatie kunt introduceren. | |
Tutorial_ # 2: | Webservices-zelfstudie: componenten, architectuur, typen en voorbeelden In deze zelfstudie voor webservices worden de architectuur, typen en componenten van webservices uitgelegd, samen met belangrijke terminologieën en de verschillen tussen SOAP en REST. | |
Tutorial_ # 3: | Top 35 ASP.Net en Web API interviewvragen met antwoorden U kunt in deze zelfstudie de lijst met de meest populaire veelgestelde ASP.Net- en Web API-interviewvragen verkennen met antwoorden en voorbeelden voor beginners en ervaren professionals. | |
Tutorial_ # 4: | POSTMAN-zelfstudie: API-testen met POSTMAN In deze stapsgewijze zelfstudie wordt API-testen met behulp van POSTMAN samen met de basisprincipes van POSTMAN, zijn componenten en voorbeeldverzoek en -respons in eenvoudige bewoordingen uitgelegd, zodat u ze gemakkelijk kunt begrijpen. | |
Tutorial_ # 5: | Webservices testen met Apache HTTP-client Deze API-zelfstudie gaat over het uitvoeren van verschillende CRUD-bewerkingen op webservices en het testen van webservices met Apache HTTP Client |
Zelfstudie over API-testen
Dit gedeelte helpt u een basiskennis te krijgen van Web Services en Web API, die op hun beurt weer nuttig zullen zijn bij het begrijpen van de belangrijkste concepten in de komende tutorials in deze API Testing-serie.
API (Application Programming Interface) is een verzameling van alle procedures en functies waarmee we een applicatie kunnen maken door toegang te krijgen tot de gegevens of functies van het besturingssysteem of de platforms. Het testen van dergelijke procedures staat bekend als API-testen.
Shift naar links testen
Een van de belangrijke soorten testen die tegenwoordig wordt gevraagd in API Testing Interviews is Shift Left Testing. Dit type testen wordt beoefend in bijna alle projecten die een Agile Methodologie volgen.
Voordat Shift Left Testing werd geïntroduceerd, kwam het testen van software pas in beeld nadat de codering was voltooid en de code aan de testers was geleverd. Deze praktijk leidde tot de last minute drukte om de deadline te halen en het belemmerde ook in grote mate de productkwaliteit.
Afgezien daarvan waren de geleverde inspanningen (toen defecten werden gemeld in de laatste fase vóór productie) enorm, aangezien ontwikkelaars zowel de ontwerp- als de coderingsfase opnieuw moesten doorlopen.
Software Development Life Cycle (SDLC) vóór Shift Left Testing
De traditionele SDLC-stroom was: Vereiste -> Ontwerp -> Codering -> Testen.
Nadelen van traditioneel testen
- Testen is uiterst rechts. Er worden veel kosten gemaakt als er op het laatste moment een bug wordt geïdentificeerd.
- De tijd die het kost om de bug op te lossen en opnieuw te testen voordat deze naar productie wordt gepromoot, is enorm.
Vandaar dat er een nieuw idee opkwam om de testfase naar links te verschuiven, wat leidde tot Shift Left Testing.
Voorgesteld lezen => Shift Left-testen: een geheime mantra voor softwaresucces
Fasen van het testen van de linker shift
Left Shift Testing leidde tot een succesvolle migratie van Defect Detection naar Defect Prevention. Het hielp ook de software om snel te falen en alle fouten op zijn vroegst op te lossen.
Web-API
In algemene termen kan een web-API worden gedefinieerd als iets dat het verzoek van een clientsysteem naar een webserver brengt en het antwoord van een webserver naar een clientcomputer stuurt.
Hoe werkt een API?
Laten we een veelvoorkomend scenario nemen voor het boeken van een vlucht op www.makemytrip.com, een online reisservice die informatie van meerdere luchtvaartmaatschappijen verzamelt. Wanneer u een vlucht boekt, voert u informatie in zoals reisdatum / terugreisdatum, klasse, etc. en klikt u op zoeken.
Dit toont u de prijs van meerdere luchtvaartmaatschappijen en hun beschikbaarheid. In dit geval werkt de applicatie samen met API's van meerdere luchtvaartmaatschappijen en geeft daardoor toegang tot de gegevens van de luchtvaartmaatschappij.
Een ander voorbeeld is www.trivago.com die de prijs, beschikbaarheid, enz. Van verschillende hotels in een bepaalde stad vergelijkt en opsomt. Deze website communiceert met API's van meerdere hotels om toegang te krijgen tot de database en geeft een overzicht van de prijzen en beschikbaarheid op hun website.
Een web-API kan dus worden gedefinieerd als 'een interface die de communicatie tussen een clientcomputer en de webserver vergemakkelijkt'.
Webservices
Webservices zijn (net als de web-API) de services die van de ene machine naar de andere worden bediend. Maar het grote verschil dat ontstaat tussen API en Web Services is dat de Web Services gebruik maakt van een netwerk.
Het is veilig om te zeggen dat alle webservices web-API's zijn, maar alle web-API's zijn geen webservices (uitgelegd in het laatste deel van het artikel). Webservices zijn dus een subset van web-API. Raadpleeg het onderstaande diagram voor meer informatie over web-API en webservices.
Web-API versus webservices
Webservices versus web-API
Zowel Web API als Web Services worden gebruikt om de communicatie tussen de client en de server te vergemakkelijken. Het belangrijkste verschil zit hem alleen in de manier waarop ze communiceren.
Elk van hen heeft een verzoekende instantie nodig die aanvaardbaar is in een specifieke taal, hun verschillen in het bieden van een beveiligde verbinding, hun snelheid van communicatie met de server en reageren op de klant, enz.
De verschillen tussen webservices en web-API worden hieronder ter referentie vermeld.
Webservice
- Webservices gebruiken doorgaans XML (Extensible Markup Language), wat betekent dat ze veiliger zijn.
- Webservices is veiliger omdat zowel webservices als API's SSL (Secure Socket Layer) bieden tijdens gegevensoverdracht, maar ook WSS (Web Services Security) biedt.
- Webservice is een subset van web-API. Bijvoorbeeld, Webservices zijn alleen gebaseerd op drie soorten gebruik, namelijk SOAP, REST en XML-RPC.
- Webservices hebben altijd een netwerk nodig om te kunnen functioneren.
- Webservices ondersteunen 'één code verschillende toepassingen'. Dit betekent dat er een meer algemene code wordt geschreven in verschillende applicaties.
Web-API
- Een web-API gebruikt over het algemeen JSON (JavaScript Object Notation), wat betekent dat de web-API sneller is.
- Web-API is sneller omdat JSON licht van gewicht is, in tegenstelling tot XML.
- Web-API's zijn de superset van webservices. Bijvoorbeeld, Alle drie de stijlen van webservices zijn ook aanwezig in de web-API, maar afgezien daarvan worden andere stijlen gebruikt, zoals JSON - RPC.
- Web API vereist niet noodzakelijk een netwerk om te functioneren.
- Web API ondersteunt al dan niet interoperabiliteit, afhankelijk van de aard van het systeem of de applicatie.
Introductie van API-testen in uw organisatie
In ons dagelijks leven zijn we allemaal zo gewend om met de apps om te gaan met API's en toch denken we niet eens na over de back-endprocessen die de onderliggende functionaliteit aansturen.
Bijvoorbeeld, Laten we eens kijken dat u door de producten op Amazon.com bladert en een product / deal ziet die u echt leuk vindt en die u wilt delen met uw Facebook-netwerk.
Op het moment dat je op het Facebook-pictogram in het deelgedeelte van de pagina klikt en je Facebook-accountgegevens invoert om te delen, heb je interactie met een API die de Amazon-website naadloos met Facebook verbindt.
Focusverschuiving naar API-testen
Laten we, voordat we meer over API-testen bespreken, de redenen bespreken waarom de op API gebaseerde applicaties de laatste tijd populair zijn geworden.
Er zijn verschillende redenen waarom organisaties overstappen op API-gebaseerde producten en applicaties. En weinigen van hen worden hieronder ter referentie vermeld.
# 1) Op API gebaseerde applicaties zijn beter schaalbaar in vergelijking met traditionele applicaties / software. De snelheid waarmee code wordt ontwikkeld, is sneller en dezelfde API kan meer verzoeken verwerken zonder grote code of infrastructurele wijzigingen.
#twee) Ontwikkelingsteams hoeven niet elke keer opnieuw te beginnen met coderen als ze beginnen met het ontwikkelen van een functie of applicatie. API's hergebruiken meestal bestaande, herhaalbare functies, bibliotheken, opgeslagen procedures, enz. En daarom kan dit proces ze in het algemeen productiever maken.
Bijvoorbeeld, Als u een ontwikkelaar bent die aan een e-commercewebsite werkt en u Amazon als betalingsverwerker wilt toevoegen, hoeft u de code niet helemaal opnieuw te schrijven.
Het enige dat u hoeft te doen, is de integratie tussen uw website en Amazon API instellen met behulp van integratiesleutels en Amazon API bellen voor het verwerken van betalingen tijdens het afrekenen.
# 3) API's maken eenvoudige integratie met de andere systemen mogelijk, zowel voor ondersteunde zelfstandige toepassingen als met op API gebaseerde softwareproducten.
Bijvoorbeeld , Laten we overwegen dat u een zending wilt verzenden van Toronto naar New York. U gaat online, navigeert naar een bekende Freight of Logistics website en voert de benodigde informatie in.
Na het verstrekken van de verplichte informatie, wanneer u op de knop Tarieven ophalen klikt - aan de achterkant, kan deze logistieke website verbinding maken met verschillende API's en applicaties van vervoerders en serviceproviders om de dynamische tarieven voor de combinatie van locaties van herkomst en bestemming te krijgen.
Volledig spectrum van API-testen
Het testen van API's is niet beperkt tot het verzenden van een verzoek naar de API en het analyseren van de respons op juistheid alleen. De API's moeten worden getest op hun prestaties onder verschillende belastingen op kwetsbaarheden.
Laten we dit in detail bespreken.
Vragen voor het programmeren van Java-serverzijde
(i) Functioneel testen
Functioneel testen kan een uitdagende taak zijn vanwege het ontbreken van een GUI-interface.
Laten we eens kijken hoe de functionele testaanpak voor API's verschilt van GUI-gebaseerde applicatie en we zullen ook enkele voorbeelden eromheen bespreken.
naar) Het meest voor de hand liggende verschil is dat er geen GUI is om mee te communiceren. Testers die meestal GUI-gebaseerde functionele tests uitvoeren, vinden het een beetje moeilijker om over te schakelen naar niet-GUI-applicatietests in vergelijking met iemand die er al bekend mee is.
In eerste instantie, zelfs voordat u begint met het testen van de API, moet u het authenticatieproces zelf testen en verifiëren. De verificatiemethode varieert van de ene API tot de andere API en omvat een soort sleutel of token voor verificatie.
Als u geen verbinding met de API kunt maken, kan verder testen niet worden voortgezet. Dit proces kan worden beschouwd als vergelijkbaar met gebruikersauthenticatie in de standaardtoepassingen waarbij u geldige inloggegevens nodig heeft om in te loggen en de toepassing te gebruiken.
b) Het testen van veldvalidaties of validatie van invoergegevens is erg belangrijk tijdens het testen van API's. Als er een daadwerkelijke, op formulieren gebaseerde (GUI) interface beschikbaar was, dan zouden veldvalidaties kunnen worden geïmplementeerd in de front-end of back-end, waardoor wordt gegarandeerd dat een gebruiker geen ongeldige veldwaarden mag invoeren.
Bijvoorbeeld, Als een aanvraag het datumnotatie nodig heeft om DD / MM / JJJJ te zijn, kunnen we deze validatie toepassen op het formulier dat informatie verzamelt om ervoor te zorgen dat de aanvraag een geldige datum ontvangt en verwerkt.
Dit is echter niet hetzelfde voor API-applicaties. We moeten ervoor zorgen dat de API goed is geschreven en in staat is om al deze validaties af te dwingen, onderscheid te maken tussen geldige en ongeldige gegevens en de statuscode en validatiefoutmelding aan de eindgebruiker te retourneren via een reactie.
c) Het testen van de juistheid van de antwoorden van de API op geldige en ongeldige antwoorden is inderdaad cruciaal. Als een statuscode van 200 (wat betekent dat alles in orde is) wordt ontvangen als een reactie van de test-API, maar als de antwoordtekst zegt dat er een fout is opgetreden, dan is dit een defect.
Bovendien, als de foutmelding zelf onjuist is, kan dat erg misleidend zijn voor de eindklant die probeert te integreren met deze API.
In de onderstaande schermafbeelding heeft de gebruiker een ongeldig gewicht ingevoerd, wat meer is dan de acceptabele 2267 kg. De API reageert met de foutstatuscode en het foutbericht. De foutmelding vermeldt echter ten onrechte de gewichtseenheden als lbs in plaats van KG. Dit is een defect dat de eindklant in verwarring kan brengen.
(ii) Testen van belasting en prestaties
API's zijn ontworpen om schaalbaar te zijn.
Dit maakt op zijn beurt Load en Prestatietests essentieel, vooral als verwacht wordt dat het systeem dat wordt ontworpen duizenden verzoeken per minuut of uur zal behandelen, afhankelijk van de behoefte. Het routinematig uitvoeren van belastings- en prestatietests op de API kan helpen de prestaties, piekbelastingen en breekpunt te benchmarken.
Deze gegevens zijn handig bij het plannen om een applicatie op te schalen. Het beschikbaar hebben van deze informatie zal helpen om beslissingen en planning te ondersteunen, vooral als de organisatie van plan is om meer klanten toe te voegen, wat meer inkomende verzoeken zou betekenen.
Bijvoorbeeld , laten we zeggen dat we op basis van de opgegeven vereisten weten dat de API die is ontworpen, ten minste 500 verzoeken per uur moet verwerken en de gemiddelde reactietijd van minder dan 0,01 seconden moet behouden.
Op basis van onze load- en prestatietests kwamen we erachter dat zolang API minder dan 500 verzoeken per uur ontvangt, de SLA kan worden gehandhaafd voor de gemiddelde responstijd. Als het echter nog eens 200 verzoeken ontvangt, neemt de gemiddelde reactietijd toe en wordt het breekpunt bereikt wanneer het inkomende verzoek meer dan 1200 per uur bedraagt.
Meestal blijkt dat tijdens de eerste ontwerpfasen de nadruk vaak ligt op de functionele aspecten van de API. Naarmate de tijd verstrijkt, begint een product meerdere live clients te ondersteunen, dat is wanneer het testen op API-prestaties en Load-testen op een meer routinematige manier in beeld komt.
(iii) Beveiligingstests
Application Programming Interfaces of API's zijn kwetsbaar en zijn het gemakkelijkste toegangspunt voor kwaadwillende hackers die toegang willen tot gegevens of controle willen krijgen over een applicatie.
Dit kan elk bedrijf in juridische problemen brengen, waarbij door een inbreuk op de beveiliging onbedoelde mensen en / of organisaties toegang kunnen krijgen tot de gegevens van de klant via een eerbiedwaardige API.
Beveiligingstesten is een gespecialiseerde tak van testen en moet door specialisten worden uitgevoerd. De middelen voor het testen van beveiliging kunnen afkomstig zijn uit de organisatie of onafhankelijke consultants.
Lees ook = >> Wat is Pact Contract Testing
Hoe u API-testen in uw organisatie kunt introduceren
Het proces voor het introduceren van API-testen in elke organisatie is vergelijkbaar met het proces dat wordt gebruikt voor het implementeren of uitrollen van andere testtools en frameworks.
De onderstaande tabel vat de belangrijkste stappen samen met het verwachte resultaat van elke stap.
Fase | Stap | Verwachte uitkomst |
---|---|---|
Gereedschapsselectie | Verzamel vereisten en identificeer beperkingen | Begrijp de vereisten voor marktonderzoek voor een geschikte API-testtool. Bijv. Wat voor soort API wordt getest - SOAP of REST? Moeten we tester inhuren voor deze rol of bestaande tester trainen? Wat voor soort tests zullen worden uitgevoerd - functionele tests, prestatietests enz. Wat is het budget voor implementatie? |
Evalueer de beschikbare tools | Vergelijk beschikbare tools en shortlist 1 of 2 tools die het beste aan de eisen voldoen. | |
Bewijs van concept | Implementeer een subset van tests met de shortlist-tool. Presenteer bevindingen aan belanghebbenden. Voltooi de te implementeren tool. | |
Implementatie | Beginnen | Afhankelijk van uw keuze f tool, zou u de vereiste tool op een pc, virtuele machine of server moeten installeren. Als de tool naar keuze op een abonnement is gebaseerd, maak dan de vereiste teamaccounts aan. Train het team indien nodig. |
Ga aan de slag | Maak tests Voer tests uit Meld defecten |
Veelvoorkomende uitdagingen en manieren om deze te verzachten
Laten we enkele van de veelvoorkomende uitdagingen bespreken waarmee QA-teams worden geconfronteerd bij het implementeren van een API-testraamwerk in een organisatie.
# 1) Het juiste gereedschap kiezen
Het selecteren van het juiste gereedschap voor de klus is de meest voorkomende uitdaging. Er zijn verschillende API-testtools die op de markt verkrijgbaar zijn.
Het lijkt misschien erg aantrekkelijk om de nieuwste, duurste tool op de markt te implementeren, maar als het niet de gewenste resultaten oplevert, heeft die tool geen zin.
Kies daarom altijd de tool die voldoet aan de ‘must-have’ -vereisten op basis van de behoeften van uw organisatie.
Hier is een voorbeeldtoolevaluatiematrix voor de beschikbare API-tools
Tool | Prijsstelling | Opmerkingen |
---|---|---|
Soap UI | Gratis versie beschikbaar voor SoapUI Open Source (Functioneel testen) | * REST, SOAP en andere populaire API- en IoT-protocollen. * Inbegrepen in gratis versie SOAP en REST ad-hoc testen Berichtverklaring Slepen en neerzetten van tests Testlogboeken Test configuratie Test van opnames Eenheidsrapportage. * De volledige lijst met functies is te vinden op hun website. |
Postbode | Gratis Postman-app beschikbaar | * Meest gebruikt voor REST. * Functies zijn te vinden op hun website. |
Parasoft | Het is een betaalde tool, vereist de aanschaf van een licentie en moet vervolgens worden geïnstalleerd voordat de tool kan worden gebruikt. | * Uitgebreide API-tests: functioneel, laden, beveiligingstests, testgegevensbeheer |
vREST | Gebaseerd op aantal gebruikers | * Geautomatiseerde REST API-tests. * Opnemen en opnieuw afspelen. * Verwijdert afhankelijkheid van frontend en backend met behulp van nep-API's. * Krachtige responsvalidatie. * Werkt voor testtoepassingen die zijn geïmplementeerd op localhost / intranet / internet. * JIRA-integratie, Jenkins-integratie geïmporteerd van Swagger, Postman. |
HttpMaster | Express Edition: gratis te downloaden Professionele versie: gebaseerd op aantal gebruikers | * Helpt bij het testen van websites en API-testen. * Andere functies zijn onder meer de mogelijkheid om algemene parameters te definiëren, waardoor de gebruiker controles kan maken voor validatie van gegevensrespons door gebruik te maken van de grote set validatietypes die het ondersteunt. |
Runscope | Op basis van het aantal gebruikers en abonnementstypen | * Voor het monitoren en testen van API's. * Kan worden gebruikt voor gegevensvalidatie om ervoor te zorgen dat correcte gegevens worden geretourneerd. * Bevat de functie voor het volgen en melden in het geval van een mislukte API-transactie (als uw toepassing betalingsvalidatie vereist, kan deze tool een goede keuze blijken te zijn). |
PingAPI | Gratis voor 1 project (1000 aanvragen) | * Gunstig voor geautomatiseerde API-tests en monitoring. |
# 2) Ontbrekende testspecificaties
Als testers hebben we de verwachte resultaten nodig om een applicatie effectief te testen. Dit is vaak een uitdaging, want om de verwachte resultaten te kennen, moeten we duidelijke precieze vereisten hebben - wat niet het geval is.
Bijvoorbeeld , houd rekening met de onderstaande vereisten:
'De aanvraag mag alleen een geldige verzenddatum accepteren en alle ongeldige vereisten moeten worden afgewezen'
Deze vereisten missen belangrijke details en zijn erg dubbelzinnig - hoe definiëren we een geldige datum? Hoe zit het met het formaat? Retourneren we een afwijzingsbericht naar de eindgebruiker, enz.?
Voorbeeld van duidelijke vereisten:
1) De applicatie mag alleen een geldige verzenddatum accepteren.
De verzenddatum wordt als geldig beschouwd als dat zo is
- Niet in het verleden
- Groter dan of gelijk aan de datum van vandaag
- Is in een acceptabel formaat: DD / MM / JJJJ
twee)
Antwoordstatuscode = 200
Bericht: OK
3) De verzenddatum die niet aan de bovenstaande criteria voldoet, moet als ongeldig worden beschouwd. Als een klant een ongeldige verzenddatum verzendt, moet deze reageren met de volgende foutmelding (en):
3.1
Antwoordstatuscode NIET 200
Fout: de opgegeven verzenddatum is ongeldig; Zorg ervoor dat de datum de indeling DD / MM / JJJJ heeft
3.2
Antwoordstatuscode NIET 200
Fout: opgegeven verzenddatum ligt in het verleden
# 3) Leercurve
Zoals eerder vermeld, is de aanpak voor API-testen anders dan de aanpak die wordt gevolgd bij het testen van GUI-gebaseerde applicaties.
c en c ++ interviewvragen
Als u intern specialisten of consultants inhuurt voor API-testen, kan de leercurve van de API-testaanpak of de API-testtool minimaal zijn. Elke leercurve zou in dit geval verband houden met het verwerven van kennis van het product of de toepassing.
Als een bestaand teamlid wordt toegewezen om API-testen te leren, kan de leercurve, afhankelijk van de gekozen tool, gemiddeld tot hoog zijn, samen met het wijzigen van de testaanpak. De leercurve voor het product of de applicatie zelf kan laag tot gemiddeld zijn, afhankelijk van of deze tester die applicatie eerder heeft getest of niet.
# 4) Bestaande vaardigheidsset
Dit sluit direct aan bij het vorige punt over de leercurve.
Als een tester overstapte van GUI-gebaseerde testen, dan zou de tester de testaanpak moeten veranderen en de nieuwe tool of het nieuwe framework moeten leren zoals vereist. Bijv. Als de API de verzoeken in JSON-indeling accepteert, moet de tester weten wat JSON is om de tests te kunnen maken.
Casestudy
Taak
Om een bestaande applicatie op te schalen, wilde een bedrijf zowel een product in API als een standaard GUI-applicatie aanbieden. Het QA-team werd gevraagd om een testdekkingsplan te verstrekken om ervoor te zorgen dat ze klaar zijn voor API-tests die verder gaan dan de reguliere GUI-gebaseerde tests.
Uitdagingen
- Geen van de andere softwareproducten had een API-gebaseerde architectuur, dus om het testen rond deze taak mogelijk te maken, moet het team het API-testproces helemaal opnieuw opzetten. Dit betekent dat de tools moesten worden geëvalueerd, op de shortlist gezet, gefinaliseerd en het team moest worden opgeleid voor de tests.
- Er was geen extra budget toegewezen voor het aanschaffen en implementeren van de tool. Dit betekent dat het team een gratis of open source API-testtool moest kiezen en iemand van het bestaande team moest worden opgeleid om deze taak op zich te nemen.
- Er waren geen vereisten voor API-velden en gegevensvalidatie. Vereisten waren 'zou hetzelfde moeten werken als de overeenkomstige GUI-applicatie'.
De aanpak die het team volgt om risico's te beperken en de uitdagingen te omzeilen
- Q Een team werkte samen met het projectteam om de volgende vereisten te identificeren:
- API-type (REST / SOAP): RUST UIT
- Tests vereist (Functioneel, Belasting, Beveiliging): Alleen functioneel testen
- Geautomatiseerde tests vereist (ja / nee): Voorlopig optioneel
- Testrapporten (ja / nee): Verplicht
- QA-team heeft tool-evaluatie uitgevoerd op het beschikbare API-testtools gebaseerd op de must-have vereisten. Postman API Tool werd afgerond als een tool naar keuze omdat het gratis was en ook gemakkelijk te gebruiken, waardoor de leercurve werd geminimaliseerd, en het potentieel had om tests te automatiseren, en werd geleverd met goede ingebouwde rapporten.
- Dezelfde tester die de applicatie heeft getest, is getraind in het gebruik van Postman om initiële tests te maken, waardoor hiaten in productkennis worden geëlimineerd.
- Om met de ontbrekende vereisten om te gaan, heeft het projectteam de velddocumentatie op hoog niveau gebouwd met Swagger. Dit liet echter enkele hiaten achter in termen van acceptabele dataformaten en dit werd met het projectteam opgepakt en de verwachte formaten werden overeengekomen en gedocumenteerd.
Gevolgtrekking
Op API gebaseerde applicaties zijn de laatste tijd populair geworden. Deze applicaties zijn beter schaalbaar in vergelijking met de traditionele applicaties / software en maken een eenvoudigere integratie met de andere API's of applicaties mogelijk.
In deze tutorial voor API-testen werd alles uitgelegd over API-testen, Shift Left-testen, Web Services en Web API. We hebben ook de verschillen tussen webservices en web-API onderzocht met voorbeelden.
In het tweede deel van de tutorial hebben we het volledige spectrum van API-tests besproken, hoe u API-tests in uw organisatie kunt introduceren en enkele veelvoorkomende uitdagingen in dit proces, samen met oplossingen daarvoor.
Bekijk onze aanstaande tutorial om meer te weten over webservices en voorbeelden !!
Aanbevolen literatuur
- Alfatesten en bètatesten (een complete gids)
- Functioneel testen versus niet-functioneel testen
- Tutorial over bruikbaarheidstests: een complete handleiding om aan de slag te gaan
- Build Verification Testing (BVT Testing) Complete Guide
- Tutorial DevOps Testing: welke invloed heeft DevOps op QA-testen?
- Tutorial over toegankelijkheidstesten (een complete stapsgewijze handleiding)
- Beste softwaretesttools 2021 [QA Test Automation Tools]
- Wat is softwaretesten? 100+ gratis zelfstudies voor handmatig testen