Hva er grensesnitttesting? Typer og eksempler

Hva er grensesnitttesting?

Grensesnitttesting er definert som en programvaretestingstype som verifiserer om kommunikasjonen mellom to forskjellige programvaresystemer gjøres riktig.

En forbindelse som integrerer to komponenter kalles grensesnitt. Dette grensesnittet i en dataverden kan være hva som helst som API-er, webtjenester osv. Testing av disse forbindelsestjenestene eller grensesnittene kalles grensesnittstesting.

Et grensesnitt er faktisk programvare som består av sett med kommandoer, meldinger og andre attributter som muliggjør kommunikasjon mellom en enhet og en bruker.

Det viktige poenget er at et grensesnitt har en ulempetract: et avtalt forespørselsformat, et avtalt svarformat, et avtalt sett med feilkoder og en avtalt tidsavbrudd. Grensesnitttestingsøvelser som konkluderer medtracfra begge sider, slik at en endring gjort av ett lag ikke i stillhet ødelegger det andre. Fordi mesteparten av denne trafikken aldri når en skjerm, er feilene den finner usynlige for svart boks testing utføres kun gjennom brukergrensesnittet.

Hvordan gjøre grensesnitttesting

Grensesnitttesting inkluderer testing av to hovedsegmenter:

1. Webserver og applikasjonsservergrensesnitt
2. Applikasjonsserver og databaseservergrensesnitt.

For ovennevnte scenarier utføres grensesnitttestingen for å

• Sjekk at servere kjøres riktig eller ikke
• Feil håndteres riktig eller returnerer en feilmelding for ethvert spørsmål fra en applikasjon
• Sjekk resultatene når tilkobling til en webserver tilbakestilles i mellom

Diagrammet nedenfor viser disse to segmentene som én enkelt kjede, der nettleseren kommuniserer med webserveren, webserveren kommuniserer med applikasjonsserveren, og applikasjonsserveren kommuniserer med databaseserveren.

I praksis jobber en tester seg gjennom den kjeden ett hopp om gangen. Hvert hopp kjøres først med en gyldig forespørsel, deretter med en feilformet forespørsel, og deretter med den andre enden bevisst utilgjengelig, slik at både suksessveien og feilveien registreres mot den samme. testforsøk.

Eksempel på grensesnitttesting

Anta at for enhver xyz-applikasjon tar grensesnittet XML fil som input og leverer JSON fil som utdata. For å teste grensesnittet til dette programmet trenger det bare spesifikasjonene for XML-filformatet og JSON-filformatet.

Ved hjelp av disse spesifikasjonene kan vi opprette eksempel-XML-filer for input og mate dem inn i grensesnittet. Deretter validere input- (XML) og output- (JSON) filene med kravet om grensesnittstesting.

Legg merke til hva eksemplet ikke trenger: ingen skjerm, ingen bygging av front-end og ingen kunnskap om koden i grensesnittet. To formatspesifikasjoner er nok til å skrive testene, og det er derfor grensesnitttesting kan starte lenge før brukergrensesnittet eksisterer.

Hvorfor gjør grensesnitttesting

Interface Testing er utført

• For å sikre at sluttbrukere eller kunder ikke skal støte på problemer når de bruker et bestemt programvareprodukt
• For å identifisere hvilke applikasjonsområder som vanligvis er tilgjengelig for sluttbrukere og for å sjekke brukervennligheten også.
• For å verifisere sikkerhetskrav mens kommunikasjon forplanter seg mellom systemene
• For å sjekke om en løsning er i stand til å håndtere nettverksfeil mellom en applikasjonsserver og et nettsted

Det er også et kostnadsargument. En feil i et forespørselsformat er billig å fikse mens de to systemene fortsatt kobles sammen, og dyrt når et nedstrømssystem allerede har lagret de feilformede dataene.

Typer grensesnitttesting

Under grensesnitttesting utføres ulike typer testing på grensesnittet som kan inkludere

• arbeidsflyt: Den sikrer at grensesnittmotoren håndterer standardarbeidsflytene dine som forventet.
• Kanttilfeller - uventede verdier: Dette tas i betraktning når testing inkluderer dato, måned og dag reversert.
• Ytelses-, belastnings- og nettverkstesting: Et grensesnitt med høyt volum kan kreve mer Load Testing enn et lavvolumsgrensesnitt, avhengig av grensesnittmotoren og tilkoblingsinfrastrukturen
• Individuelle systemer: Dette inkluderer testing av hvert system individuelt. For eksempel bør faktureringssystem og lagerstyringssystem for detaljhandelen kunne operere separat.

Det første elementet er nært nok til arbeidsflyttesting å gjenbruke scenariene sine, og det siste elementet overlapper med modultesting, siden et system som svikter av seg selv, vil svikte igjen når det først er tilkoblet.

Strategi for grensesnitttesting

Grensesnittteststrategi er en metode som brukes til å teste grensesnitt med vanlige tester uavhengig av implementering. Vi kan bruke abstract testtilfeller og lag konkrete instanser av testtilfellet for hver implementering av grensesnittteststrategien. Basen/abstract-testtilfeller utfører implementeringsnøytrale tester, mens konkrete tester tar seg av å instansiere objekter for testing og utføre implementeringsspesifikke tester.

Gevinsten med den strukturen er gjenbruk. Når en tredje implementering av det samme grensesnittet dukker opp, vil abstract suite kjører uendret mot den, og bare instansieringskoden må skrives. Den samme ideen brukes i større skala i komponenttesting, hvor en delt konvensjontract suite kjøres mot alle komponenter som hevder å tilfredsstille den.

Verktøy for grensesnitttesting

Fordi et grensesnitt ikke har noen skjerm, må verktøyet konstruere forespørsler direkte og gjøre krav på råsvar. Team kombinerer vanligvis tre kategorier av verktøy.

• API-klienter og forespørselsbyggere: Verktøy som Postman, SoapUI, Insomnia og Hoppscotch sender REST-, SOAP- eller GraphQL-kall, lagrer dem som gjenbrukbare samlinger og bekrefter statuskoder, overskrifter og svartekster.
• Code-nivå testbiblioteker: Biblioteker som kjører inne i den eksisterende testsuiten lar grensesnittsjekker fungere ved siden av enhetstester og kjøres på hver build, noe som hindrer dem i å bli utdaterte.
• Last- og protokollverktøy: Et verktøy som f.eks. JMeter driver det samme grensesnittet på volum, som er det som gjør en funksjonskontroll til ytelsestesting av forbindelsen.
• Tjenestevirtualisering og mockup-metoder: En stub som står inn for den andre enden lar den ene siden testes mens den andre er utilgjengelig, uferdig eller for dyr til å ringe gjentatte ganger.

Utvalget er mindre viktig enn dekningen. Uansett hvilken klient som velges, må samlingen av forespørsler lagres i versjonskontroll sammen med koden, slik at en endring i grensesnittet og en endring i testene kommer i samme commit. Detaljer om den bredere kategorien er dekket i API-testing.

Sjekkliste og beste praksis for grensesnitttesting

En kort sjekkliste sørger for at grensesnittdekningen er ærlig på tvers av versjoner. Gå gjennom den for hver tilkobling i stedet for for applikasjonen som helhet.

• medtracførst: Bekreft at forespørsels- og svarskjemaene samsvarer med den publiserte spesifikasjonen, felt for felt, inkludert datatyper og valgfrie felt.
• Grenseverdier: Send tomme nyttelaster, felt med maksimal lengde, uventede tegnsett og reverserte datoformater.
• Feilstier: Bekreft at hver feil returnerer en meningsfull kode og melding i stedet for en stakk trace eller en stille suksess.
• Tidsavbrudd og nye forsøk: Avbryt tilkoblingen midt i forespørselen og bekreft at innringeren forsøker på nytt på en sikker måte uten å duplisere transaksjonen.
• Sikkerhet: Sjekk autentisering, autorisasjon og kryptering på lenken, og bekreft at feilmeldinger ikke lekker interne detaljer.
• Datakonsistens: Les oppføringen tilbake fra den andre siden og bekreft at ingenting ble avkortet, omkodet eller omordnet underveis.
• Volum: Gjenta kallet med høyest trafikk under samtidig belastning, og se etter uttømming av tilkoblingspoolen.

Tre fremgangsmåter gjør at denne sjekklisten er repeterbar. For det første, automatiser pakken og kjør den på hver build, fordi grensesnitt endres stillere enn skjermer. For det andre, loggfør hele forespørselen og svaret for hver feil, siden en grensesnittfeil er nesten umulig å reprodusere fra et skjermbilde. For det tredje, hold pakken uavhengig av testdata opprettet av andre pakker, slik at en feil peker på grensesnittet snarere enn på en manglende post.

Disse kontrollene faller naturlig inn under den større planen beskrevet i typer programvaretesting, og de kjører før de samme forbindelsene utøves ende til ende under systemtesting.

Grensesnitttesting vs integrasjonstesting

De to begrepene er relaterte snarere enn motstridende: grensesnitttesting er den delen av integrasjonsarbeidet som konsentrerer seg om selve forbindelsen. Tabellen nedenfor viser vektleggingen av hver side.

Alle som er nye innen det bredere fagfeltet vil finne de omkringliggende nivåene beskrevet i integrasjonstesting og generelt programvaretesting innledning, mens terminologien som brukes ovenfor kommer fra standard software engineering praksis. For nettleservendte systemer blir de samme tilkoblingene til slutt utøvd igjen under testing av webapplikasjoner.

Spørsmål og svar