Hvad er grænsefladetestning? Typer og eksempler

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

⚡ Smart opsummering

Interfacetestning verificerer, at to forbundne softwaresystemer udveksler data korrekt. Det dækker webserver-, applikationsserver- og databaseserverforbindelserne, der bærer alle anmodninger fra en applikation, sammen med fejlhåndteringen omkring dem.

  • 🔗 Definition: En grænseflade er enhver forbindelse – en API, en webtjeneste eller en meddelelseskø – der forbinder to komponenter.
  • 🧭 To segmenter: Testningen er målrettet mellem webserver og applikationsserver og applikationsserver og databaseserver.
  • 📄 Udarbejdet eksempel: Et XML-input og et JSON-output valideres i forhold til deres offentliggjorte formatspecifikationer.
  • 🧪 Testtyper: Arbejdsgang, kanttilfælde, ydeevne og belastning, plus hvert enkelt system, der trænes isoleret.
  • 🛠️ Værktøj: API-klienter og tjenestevirtualisering driver anmodninger, når der ikke findes en brugergrænseflade at klikke sig igennem.
  • 🔍 Omfangsgrænse: Interfacetestning er en undertype af integrationstest, der fokuserer på forbindelseskonsekvenser.tract selv.
Læs mere

Grænsefladetest mellem webserver, applikationsserver og databaseserver

Hvad er grænsefladetestning?

Interface test er defineret som en softwaretesttype, der verificerer, om kommunikationen mellem to forskellige softwaresystemer udføres korrekt.

En forbindelse, der integrerer to komponenter, kaldes en grænseflade. Denne grænseflade i en computerverden kan være alt i retning af API'er, webtjenester osv. Test af disse forbindelsestjenester eller grænseflader kaldes grænsefladetestning.

En grænseflade er faktisk software, der består af sæt af kommandoer, beskeder og andre attributter, der muliggør kommunikation mellem en enhed og en bruger.

Det vigtige punkt er, at en grænseflade har en ulempetract: et aftalt anmodningsformat, et aftalt svarformat, et aftalt sæt fejlkoder og en aftalt timeout. Grænsefladetestøvelser, der omfattertracfra begge sider, så en ændring foretaget af det ene hold ikke lydløst forstyrrer det andet. Fordi det meste af denne trafik aldrig når en skærm, er de fejl, den finder, usynlige for sort kasse test udføres udelukkende via brugergrænsefladen.

Sådan laver du grænsefladetestning

Interfacetestning omfatter test af to hovedsegmenter:

  1. Webserver og applikationsservergrænseflade
  2. Applikationsserver og databaseservergrænseflade.

For ovennævnte scenarier udføres grænsefladetesten til

  • Kontroller, at serverne er udført korrekt eller ej
  • Fejl håndteres korrekt eller returnerer en fejlmeddelelse for enhver forespørgsel fra en applikation
  • Tjek resultaterne, når forbindelsen til en webserver nulstilles ind imellem

Diagrammet nedenfor viser disse to segmenter som en enkelt kæde, hvor browseren kommunikerer med webserveren, webserveren kommunikerer med applikationsserveren, og applikationsserveren kommunikerer med databaseserveren.

Grænsefladetest på tværs af webserver-, applikationsserver- og databaseserverkæden

I praksis arbejder en tester sig gennem den kæde ét hop ad gangen. Hvert hop køres først med en gyldig anmodning, derefter med en misdannet anmodning, og derefter med den fjerne ende bevidst utilgængelig, således at både successtien og fejlstien registreres mod den samme. test sag.

Eksempel på grænsefladetestning

Antag for enhver xyz-applikation, at grænsefladen tager XML fil som input og leverer JSON fil som output. For at teste brugerfladen til denne applikation kræver den blot specifikationerne for XML-filformatet og JSON-filformatet.

Ved hjælp af disse specifikationer kan vi oprette eksempler på XML-inputfiler og indlæse dem i grænsefladen. Derefter validere input- (XML) og output- (JSON) filerne i henhold til kravet om grænsefladetestning.

Bemærk, hvad eksemplet ikke behøver: ingen skærm, ingen opbygning af frontend og ingen kendskab til koden i grænsefladen. To formatspecifikationer er nok til at skrive testene, hvilket er grunden til, at grænsefladetestning kan starte længe før brugergrænsefladen eksisterer.

Hvorfor laver grænsefladetestning

Interfacetest er udført

  • For at sikre, at slutbrugere eller kunder ikke støder på problemer, når de bruger et bestemt softwareprodukt
  • For at identificere, hvilke applikationsområder der normalt tilgås af slutbrugere og for også at kontrollere dets brugervenlighed.
  • For at verificere sikkerhedskrav, mens kommunikation udbreder sig mellem systemerne
  • For at kontrollere, om en løsning er i stand til at håndtere netværksfejl mellem en applikationsserver og websted

Der er også et omkostningsargument. En fejl i et anmodningsformat er billig at udbedre, mens de to systemer stadig er forbundet, og dyr, når et downstream-system allerede har lagret de forkerte data.

Typer af grænsefladetestning

Under grænsefladetestning udføres forskellige typer test på grænsefladen, som kan omfatte

  • Workflow: Det sikrer, at interfacemotoren håndterer dine standardarbejdsgange som forventet.
  • Kanttilfælde - uventede værdier: Dette tages i betragtning, når test inkluderer dato, måned og dag omvendt.
  • Ydeevne-, belastnings- og netværkstest: En grænseflade med høj volumen kan kræve mere Load Testing end en grænseflade med lav volumen, afhængigt af grænseflademotoren og tilslutningsinfrastrukturen
  • Individuelle systemer: Dette inkluderer test af hvert system individuelt. For eksempel bør faktureringssystem og lagerstyringssystem for detailbutikken kunne fungere separat.

Det første element er tæt nok på test af arbejdsgange at genbruge sine scenarier, og det sidste element overlapper med modultestning, da et system, der fejler af sig selv, vil fejle igen, når det først er tilsluttet.

Interface teststrategi

Interfaceteststrategi er en metode, der bruges til at teste grænseflader med almindelige tests uanset implementering. Vi kan bruge abstract testcases og opret konkrete instanser af testcasen for hver implementering af grænsefladeteststrategien. Basen/abstract-testcases udfører implementeringsneutrale tests, mens konkrete tests tager sig af at instantiere objekter, der skal testes, og udføre implementeringsspecifikke tests.

Gevinsten ved den struktur er genbrug. Når en tredje implementering af den samme grænseflade dukker op, vil abs'entract suite kører uændret imod den, og kun instantieringskoden skal skrives. Den samme idé anvendes i større skala i komponenttest, hvor en delt kontract suite køres mod alle komponenter, der hævder at opfylde den.

RELATEREDE ARTIKLER

Værktøjer til grænsefladetestning

Fordi en grænseflade ikke har nogen skærm, skal værktøjerne konstruere anmodninger direkte og basere sig på rå svar. Teams kombinerer normalt tre kategorier af værktøjer.

  • API-klienter og anmodningsbyggere: Værktøjer såsom Postman, SoapUI, Insomnia og Hoppscotch sender REST-, SOAP- eller GraphQL-kald, gemmer dem som genanvendelige samlinger og foretager assert på statuskoder, headere og svartekster.
  • Code-niveau testbiblioteker: Biblioteker, der kører inde i den eksisterende testsuite, lader grænsefladetjek fungere ved siden af ​​enhedstests og udføres på alle builds, hvilket forhindrer dem i at blive forældede.
  • Indlæsnings- og protokolværktøjer: Et værktøj som f.eks. JMeter driver den samme grænseflade ved volumen, hvilket er det, der forvandler en funktionel kontrol til test af ydeevne af forbindelsen.
  • Servicevirtualisering og mocks: En stub, der står i den anden ende, lader den ene side blive testet, mens den anden ikke er tilgængelig, ufærdig eller for dyr at ringe til gentagne gange.

Udvælgelsen betyder mindre end dækningen. Uanset hvilken klient der vælges, skal samlingen af ​​anmodninger gemmes i versionsstyring sammen med koden, så en ændring af grænsefladen og en ændring af dens tests ankommer i den samme commit. Detaljer om den bredere kategori er dækket i API-test.

Tjekliste og bedste praksis for grænsefladetestning

En kort tjekliste sikrer, at grænsefladedækningen er korrekt på tværs af versioner. Gennemgå den for hver forbindelse i stedet for for applikationen som helhed.

  • medtracførst: Bekræft, at anmodnings- og svarskemaerne stemmer overens med den offentliggjorte specifikation, felt for felt, inklusive datatyper og valgfrie felter.
  • Grænseværdier: Send tomme nyttelast, felter med maksimal længde, uventede tegnsæt og omvendte datoformater.
  • Fejlstier: Bekræft, at hver fejl returnerer en meningsfuld kode og besked i stedet for en stak trace eller en stille succes.
  • Timeouts og genforsøg: Afbryd forbindelsen midt i anmodningen, og bekræft, at den, der ringer op, forsøger sikkert igen uden at duplikere transaktionen.
  • Sikkerhed: Kontrollér godkendelse, autorisation og kryptering på linket, og bekræft, at fejlmeddelelser ikke lækker interne detaljer.
  • Datakonsistens: Læs optegnelsen tilbage fra den anden side, og bekræft, at intet blev afkortet, omkodet eller omordnet under transport.
  • Volumen: Gentag opkaldet med den højeste trafik under samtidig belastning, og hold øje med udtømning af forbindelsespuljen.

Tre fremgangsmåder gør den tjekliste gentagelig. For det første, automatiser pakken og kør den på hvert build, fordi grænseflader ændrer sig mere stille end skærme. For det andet, log den fulde anmodning og svar for hver fejl, da en grænsefladefejl er næsten umulig at reproducere fra et skærmbillede. For det tredje, hold pakken uafhængig af testdata oprettet af andre pakker, så en fejl peger på grænsefladen snarere end på en manglende post.

Disse kontroller ligger naturligt inden for den bredere plan beskrevet i typer af softwaretestning, og de kører, før de samme forbindelser udføres ende til anden under system test.

Interfacetest vs integrationstest

De to begreber er relaterede snarere end modsatrettede: interfacetestning er den del af integrationsarbejdet, der fokuserer på selve forbindelsen. Tabellen nedenfor viser vægtningen af ​​hver side.

Interface test Integrationstest
En integrationstesttype, der beskæftiger sig med test af grænseflader mellem komponenter eller systemer Test udført for at afsløre fejl i grænseflader og i interaktioner mellem integrerede komponenter eller systemer.
Fokus er ulempentract — anmodningsformat, svarformat, fejlkoder og timeouts Fokus er komponenternes kombinerede opførsel, når de er forbundet
Kan udføres, så snart specifikationen findes, med den fjerneste ende stubbet Kræver, at de deltagende komponenter bygges og implementeres sammen
En fejl peger på én forbindelse En fejl kan pege på en hvilken som helst komponent i den samlede gruppe

Enhver, der er ny inden for den bredere disciplin, vil finde de omkringliggende niveauer beskrevet i integrationstest og i det generelle software test introduktion, mens den anvendte terminologi ovenfor stammer fra standard software Engineering praksis. For browser-orienterede systemer udføres de samme forbindelser til sidst igen under test af webapplikationer.

Ofte Stillede Spørgsmål

Normalt er det QA-ingeniørerne, der har integrationsdækningen og arbejder med udviklerne af begge systemer. På servicetunge produkter tager en dedikeret API-tester sig af opgaven, fordi arbejdet kræver færdigheder inden for konstruktion snarere end færdigheder inden for skærmnavigation.

Intet synligt output at inspicere, tredjepartsslutpunkter, der ikke kan kaldes frit, testdata, der skal findes på begge sider, og specifikationer, der ændres uden varsel. Stubs og versionsstyrede anmodningssamlinger reducerer de fleste af dem.

De overlapper hinanden meget. En API er én slags grænseflade, så API-test Anvendes interfacetestning til den specifikke teknologi? Interfacetestning dækker også fildrops, meddelelseskøer og databaselinks, der ikke har nogen API.

Nej. Navnet er delt, men målet er forskelligt. Interfacetestning kontrollerer system-til-system-forbindelser; brugergrænsefladetestning kontrollerer skærme, kontroller og layout. Hvis de to sammenblandes, bliver serversideforbindelserne utestet.

Så snart anmodnings- og svarspecifikationerne er aftalt, hvilket normalt er før et af systemerne er færdigt. Ved at stoppe den fjerne ende kører pakken tidligt, og den samme suite genbruges, når begge systemer er live.

Andelen af ​​dokumenterede slutpunkter med mindst én positiv og én negativ test, andelen af ​​deklarerede fejlkoder, der faktisk blev udløst, og antallet af grænsefladefejl, der escaping til senere faser. Rå testtællinger viser meget lidt.

Maskinlæring læser et skema og genererer grænse- og negative nyttelast, som et menneske ville springe over, og grupperer derefter fejlende svar, så én rodårsag ikke rapporteres otte gange. Den markerer også skemaændringer, som eksisterende anmodninger ikke længere matcher.

Ja. Med et skema eller en eksempelnyttelast udarbejder den hurtigt request builders, assertions og stub responses. Specifikationen skal stadig leveres af et menneske, fordi en genereret assertion kun er så korrekt som selve konsekvensen.tract bag det.

Opsummer dette indlæg med: