Wat is interfacetesten? Typen & voorbeeld
โก Slimme samenvatting
Interfacetesten verifiรซren of twee verbonden softwaresystemen correct gegevens uitwisselen. Het omvat de verbindingen tussen de webserver, applicatieserver en databaseserver die alle verzoeken van een applicatie verwerken, evenals de foutafhandeling daarbij.
Wat is interfacetesten?
Interface testen Dit wordt gedefinieerd als een type softwaretest dat verifieert of de communicatie tussen twee verschillende softwaresystemen correct verloopt.
Een verbinding die twee componenten integreert, wordt een interface genoemd. In de computerwereld kan deze interface van alles zijn, zoals API's, webservices, enzovoort. Het testen van deze verbindende services of interfaces wordt interfacetesten genoemd.
Een interface is eigenlijk software die bestaat uit sets opdrachten, berichten en andere attributen die communicatie tussen een apparaat en een gebruiker mogelijk maken.
Het belangrijkste punt is dat een interface een contract: een overeengekomen verzoekformaat, een overeengekomen antwoordformaat, een overeengekomen set foutcodes en een overeengekomen time-out. Interface-testoefeningen die contracHet verkeer komt van beide kanten, dus een wijziging door het ene team brengt het andere team niet ongemerkt in de problemen. Omdat het grootste deel van dit verkeer nooit een scherm bereikt, zijn de gevonden defecten onzichtbaar voor de gebruiker. black box testen Dit wordt uitsluitend via de gebruikersinterface gedaan.
Interfacetesten uitvoeren
Interface Testing omvat het testen van twee hoofdsegmenten:
- Webserver en applicatieserverinterface
- Applicatieserver en databaseserverinterface.
Voor bovengenoemde scenario's worden de interfacetests uitgevoerd
- Controleer of servers correct worden uitgevoerd of niet
- Fouten worden correct afgehandeld of geven een foutmelding bij elke zoekopdracht van een applicatie
- Controleer de uitkomsten wanneer de verbinding met een webserver tussentijds wordt gereset
Het onderstaande diagram toont deze twee segmenten als รฉรฉn enkele keten, waarbij de browser communiceert met de webserver, de webserver met de applicatieserver en de applicatieserver met de databaseserver.
In de praktijk doorloopt een tester die keten stap voor stap. Elke stap wordt eerst uitgevoerd met een geldig verzoek, vervolgens met een onjuist verzoek en ten slotte met een opzettelijk ontoegankelijke eindbestemming, zodat zowel het succesvolle als het mislukte pad aan dezelfde kant worden gekoppeld. testcase.
Voorbeeld van interfacetesten
Stel dat voor elke xyz-toepassing de interface het volgende aanneemt: XML bestand als invoer en levert JSON Het bestand wordt als uitvoer gebruikt. Om de interface van deze applicatie te testen, zijn alleen de specificaties van het XML-bestandsformaat en het JSON-bestandsformaat nodig.
Met behulp van deze specificaties kunnen we voorbeeld-XML-invoerbestanden maken en deze aan de interface aanbieden. Het valideren van het invoerbestand (XML) en het uitvoerbestand (JSON) aan de hand van de vereisten, wordt interfacetesten genoemd.
Merk op wat het voorbeeld niet nodig heeft: geen scherm, geen front-end build en geen kennis van de code binnen de interface. Twee formaatspecificaties zijn voldoende om de tests te schrijven, waardoor interfacetesten al lang voordat de gebruikersinterface bestaat, kunnen beginnen.
Waarom interfacetesten?
Interfacetesten zijn voltooid
- Om ervoor te zorgen dat eindgebruikers of klanten geen problemen ondervinden bij het gebruik van een bepaald softwareproduct
- Om te identificeren welke toepassingsgebieden doorgaans door eindgebruikers worden gebruikt en om ook de gebruiksvriendelijkheid ervan te controleren.
- Om de beveiligingsvereisten te verifiรซren terwijl de communicatie zich tussen de systemen voortplant
- Om te controleren of een oplossing netwerkstoringen tussen een applicatieserver en website kan afhandelen
Er is ook een kostenargument. Een fout in een aanvraagformaat is goedkoop te verhelpen terwijl de twee systemen nog met elkaar verbonden zijn, maar duur zodra een downstream-systeem de onjuiste gegevens al heeft opgeslagen.
Soorten interfacetests
Tijdens het testen van de interface worden verschillende soorten tests op de interface uitgevoerd, waaronder mogelijk:
- Workflow: Het zorgt ervoor dat de interface-engine uw standaardworkflows zoals verwacht verwerkt.
- Randgevallen - onverwachte waarden: Hiermee wordt rekening gehouden bij het testen, waarbij datum, maand en dag worden omgekeerd.
- Prestatie-, belasting- en netwerktesten: Een interface met een hoog volume kan meer vereisen. load Testen dan een interface met laag volume, afhankelijk van de interface-engine en connectiviteitsinfrastructuur
- Individuele systemen: Dit omvat het afzonderlijk testen van elk systeem. Bijvoorbeeld, het factureringssysteem en het voorraadbeheersysteem voor de winkel zouden afzonderlijk moeten kunnen werken.
Het eerste item is dichtbij genoeg om workflow testen om de scenario's opnieuw te gebruiken, en het laatste punt overlapt met moduletestenomdat een systeem dat vanzelf uitvalt, opnieuw zal uitvallen zodra het is aangesloten.
Strategie voor het testen van interfaces
Een interface-teststrategie is een methode om interfaces te testen met behulp van standaardtests, ongeacht de implementatie. We kunnen abs gebruiken.tractestgevallen en creรซer concrete instanties van het testgeval voor elke implementatie van de interface-teststrategie. De basis/abstracTestcases voeren implementatie-neutrale tests uit, terwijl concrete tests de te testen objecten instantiรซren en implementatiespecifieke tests uitvoeren.
Het voordeel van die structuur is hergebruik. Wanneer een derde implementatie van dezelfde interface verschijnt, wordt de abstract suite wordt er ongewijzigd op uitgevoerd, en alleen de instantiecode hoeft te worden geschreven. Hetzelfde idee wordt op grotere schaal toegepast in testen van componenten, waar een gedeelde contract suite wordt uitgevoerd op elk component dat beweert eraan te voldoen.
Interface-testtools
Omdat een interface geen scherm heeft, moet de tooling de verzoeken direct construeren en de onbewerkte antwoorden verwerken. Teams combineren doorgaans drie categorieรซn tools.
- API-clients en aanvraagbouwers: Tools zoals Postman, SoapUIInsomnia en Hoppscotch versturen REST-, SOAP- of GraphQL-aanroepen, slaan deze op als herbruikbare collecties en controleren statuscodes, headers en antwoordbody's.
- Code-niveau testbibliotheken: Bibliotheken die binnen de bestaande testsuite worden uitgevoerd, zorgen ervoor dat interfacecontroles naast unit tests kunnen worden uitgevoerd bij elke build, waardoor ze actueel blijven.
- Laad- en protocoltools: Een hulpmiddel zoals JMeter stuurt dezelfde interface op volume aan, wat een functionele controle verandert in prestatie testen van de verbinding.
- Servicevirtualisatie en mocks: Een tussenstuk dat als noodoplossing dient, maakt het mogelijk om รฉรฉn kant te testen terwijl de andere kant niet beschikbaar, onafgewerkt of te duur is om herhaaldelijk te bellen.
De keuze van de client is minder belangrijk dan de dekking. Ongeacht de gekozen client, moet de verzameling verzoeken samen met de code in versiebeheer worden opgeslagen, zodat een wijziging in de interface en een wijziging in de bijbehorende tests in dezelfde commit terechtkomen. Details over de bredere categorie worden behandeld in API-testen.
Checklist en beste werkwijzen voor interfacetesten
Een korte checklist zorgt ervoor dat de interfacedekking consistent blijft bij elke release. Doorloop de checklist voor elke verbinding afzonderlijk, in plaats van voor de applicatie als geheel.
- mettract eerst: Controleer of de aanvraag- en antwoordschema's veld voor veld overeenkomen met de gepubliceerde specificatie, inclusief gegevenstypen en optionele velden.
- Grenswaarden: Verzend lege gegevens, velden met de maximale lengte, onverwachte tekensets en omgekeerde datumformaten.
- Foutpaden: Controleer of elke fout een zinvolle code en bericht retourneert in plaats van een stacktrace. trace of een stil succes.
- Time-outs en herhaalpogingen: Onderbreek de verbinding halverwege het verzoek en bevestig dat de beller het veilig opnieuw probeert zonder de transactie te dupliceren.
- Beveiliging: Controleer de authenticatie, autorisatie en versleuteling van de link en bevestig dat foutmeldingen geen interne gegevens prijsgeven.
- Data consistentie: Lees de opname vanaf de andere kant terug en controleer of er tijdens het transport niets is afgekapt, opnieuw gecodeerd of in een andere volgorde is geplaatst.
- Volume: Herhaal het gesprek met de hoogste belasting onder gelijktijdige belasting en houd in de gaten of de verbindingspool uitgeput raakt.
Drie werkwijzen maken die checklist herhaalbaar. Ten eerste, automatiseer de testsuite en voer deze uit bij elke build, omdat interfaces stiller veranderen dan schermen. Ten tweede, registreer de volledige aanvraag en respons bij elke fout, aangezien een interfacefout bijna onmogelijk te reproduceren is aan de hand van een screenshot. Ten derde, houd de testsuite onafhankelijk van testgegevens die door andere suites zijn gegenereerd, zodat een fout wijst naar de interface in plaats van naar een ontbrekend record.
Deze controles passen vanzelfsprekend in het bredere plan dat beschreven staat in soorten softwaretestenen ze worden uitgevoerd voordat dezelfde verbindingen van begin tot eind worden gebruikt tijdens systeem testen.
Interfacetesten versus integratietesten
De twee termen zijn eerder verwant dan tegenovergesteld: interfacetesten is het onderdeel van integratiewerk dat zich concentreert op de verbinding zelf. De onderstaande tabel geeft de nadruk van beide kanten weer.
| Interface testen | Integratietesten |
|---|---|
| Een integratietesttype dat zich bezighoudt met het testen van de interfaces tussen componenten of systemen | Tests uitgevoerd om defecten in de interfaces en in de interacties tussen geรฏntegreerde componenten of systemen bloot te leggen. |
| Focus is het nadeeltract โ verzoekformaat, antwoordformaat, foutcodes en time-outs | Focus verwijst naar het gecombineerde gedrag van de componenten zodra ze samengevoegd zijn. |
| Kan worden uitgevoerd zodra de specificatie bestaat, waarbij het uiteinde is gestubd. | Vereist dat de deelnemende componenten samen worden gebouwd en geรฏmplementeerd. |
| Een storing wijst op รฉรฉn verbinding. | Een storing kan wijzen op elk onderdeel in de complete set. |
Wie nieuw is in dit bredere vakgebied, zal de omliggende niveaus die beschreven worden in integratie testen en in het algemeen software testen inleiding, terwijl de hierboven gebruikte terminologie afkomstig is van standaard software engineering oefening. Voor systemen die via een browser toegankelijk zijn, worden dezelfde verbindingen uiteindelijk opnieuw gebruikt tijdens testen van webapplicaties.

