Vad är gränssnittstestning? Typer och exempel

Vad är gränssnittstestning?

Gränssnittstestning definieras som en typ av mjukvarutestning som verifierar om kommunikationen mellan två olika mjukvarusystem sker korrekt.

En anslutning som integrerar två komponenter kallas gränssnitt. Detta gränssnitt i en datorvärld kan vara vad som helst som API:er, webbtjänster etc. Testning av dessa anslutna tjänster eller gränssnitt kallas gränssnittstestning.

Ett gränssnitt är faktiskt programvara som består av uppsättningar av kommandon, meddelanden och andra attribut som möjliggör kommunikation mellan en enhet och en användare.

Den viktiga poängen är att ett gränssnitt har en nackdeltract: ett överenskommet förfrågningsformat, ett överenskommet svarsformat, en överenskommen uppsättning felkoder och en överenskommen timeout. Gränssnittstestövningar som konstruerartracfrån båda sidor, så att en förändring som görs av ett lag inte tyst bryter mot det andra. Eftersom det mesta av denna trafik aldrig når en skärm är de defekter som hittas osynliga för svartbox testning utförs enbart via användargränssnittet.

Hur man gör gränssnittstestning

Gränssnittstestning inkluderar testning av två huvudsegment:

1. Webbserver och applikationsservergränssnitt
2. Applikationsserver och databasservergränssnitt.

För ovan nämnda scenarier görs gränssnittstesten för att

• Kontrollera att servrarna körs korrekt eller inte
• Fel hanteras korrekt eller returnerar ett felmeddelande för alla frågor som görs av ett program
• Kontrollera utfallen när anslutningen till en webbserver återställs däremellan

Diagrammet nedan visar dessa två segment som en enda kedja, där webbläsaren kommunicerar med webbservern, webbservern kommunicerar med applikationsservern och applikationsservern kommunicerar med databasservern.

I praktiken arbetar en testare genom den kedjan ett hopp i taget. Varje hopp körs först med en giltig begäran, sedan med en felaktigt utformad begäran, och sedan med den bortre änden avsiktligt otillgänglig, så att både lyckade och misslyckade försök registreras mot samma hopp. testfall.

Exempel på gränssnittstestning

Antag att för vilken xyz-applikation som helst tar gränssnittet XML fil som indata och levererar JSON fil som utdata. För att testa gränssnittet för den här applikationen krävs bara specifikationerna för XML-filformat och JSON-filformat.

Med hjälp av dessa specifikationer kan vi skapa exempel på XML-indatafiler och mata in dem i gränssnittet. Sedan validerar vi indata- (XML) och utdata- (JSON) filerna med kravet gränssnittstestning.

Lägg märke till vad exemplet inte behöver: ingen skärm, ingen byggnation av front-end och ingen kunskap om koden inuti gränssnittet. Två formatspecifikationer räcker för att skriva testerna, vilket är anledningen till att gränssnittstestning kan börja långt innan användargränssnittet finns.

Varför gör gränssnittstestning

Gränssnittstestning är gjord

• För att säkerställa att slutanvändare eller kunder inte ska stöta på några problem när de använder en viss mjukvaruprodukt
• För att identifiera vilka applikationsområden som vanligtvis nås av slutanvändare och att även kontrollera dess användarvänlighet.
• För att verifiera säkerhetskrav medan kommunikation sprids mellan systemen
• För att kontrollera om en lösning är kapabel att hantera nätverksfel mellan en applikationsserver och webbplats

Det finns också ett kostnadsargument. En defekt i ett förfrågningsformat är billig att åtgärda medan de två systemen fortfarande är sammankopplade, och dyr när ett nedströmssystem redan har lagrat den felaktiga datan.

Typer av gränssnittstestning

Under gränssnittstestning utförs olika typer av tester på gränssnittet som kan inkludera

• Arbetsflöde: Det säkerställer att gränssnittsmotorn hanterar dina standardarbetsflöden som förväntat.
• Kantfall - oväntade värden: Detta beaktas när testerna inkluderar datum, månad och dag omvända.
• Prestanda-, belastnings- och nätverkstestning: Ett gränssnitt med hög volym kan kräva mer Lasttestning än ett gränssnitt med låg volym, beroende på gränssnittsmotorn och anslutningsinfrastrukturen
• Individuella system: Detta inkluderar att testa varje system individuellt. Till exempel bör faktureringssystem och lagerhanteringssystem för detaljhandeln kunna fungera separat.

Det första objektet är tillräckligt nära arbetsflödestestning att återanvända sina scenarier, och det sista objektet överlappar med modultestning, eftersom ett system som fallerar av sig självt kommer att fallera igen när det väl är anslutet.

Gränssnittsteststrategi

Gränssnittsteststrategi är en metod som används för att testa gränssnitt med vanliga tester oavsett implementering. Vi kan använda abstractestfall och skapa konkreta instanser av testfallet för varje implementering av gränssnittsteststrategin. Basen/abstract-testfall utför implementeringsneutrala tester medan konkreta tester tar hand om att instansiera objekt att testa och utföra implementeringsspecifika tester.

Vinsten med den strukturen är återanvändning. När en tredje implementering av samma gränssnitt dyker upp, kommer abstract suite körs oförändrad mot den, och endast instansieringskoden behöver skrivas. Samma idé tillämpas i större skala i komponenttestning, där en delad kontract-sviten körs mot varje komponent som påstår sig uppfylla den.

Verktyg för gränssnittstestning

Eftersom ett gränssnitt saknar skärm måste verktygen konstruera förfrågningar direkt och använda råa svar. Team kombinerar normalt tre kategorier av verktyg.

• API-klienter och förfrågningsbyggare: Verktyg som Postman, SoapUI, Insomnia och Hoppscotch skickar REST-, SOAP- eller GraphQL-anrop, lagrar dem som återanvändbara samlingar och asserterar på statuskoder, rubriker och svarskroppar.
• Code-nivå testbibliotek: Bibliotek som körs inuti den befintliga testsviten låter gränssnittskontroller live bredvid enhetstester och köras på varje build, vilket förhindrar att de blir föråldrade.
• Verktyg för laddning och protokoll: Ett verktyg som t.ex. JMeter driver samma gränssnitt vid volym, vilket är det som förvandlar en funktionskontroll till prestandatester av anslutningen.
• Tjänstevirtualisering och mockup-metoder: En stub som står i för den bortre änden låter ena sidan testas medan den andra är otillgänglig, oavslutad eller för dyr att ringa upprepade gånger.

Urvalet spelar mindre roll än täckningen. Oavsett vilken klient som väljs måste samlingen av förfrågningar lagras i versionshantering tillsammans med koden, så en ändring av gränssnittet och en ändring av dess tester anländer i samma commit. Detaljer om den bredare kategorin behandlas i API-testning.

Checklista och bästa praxis för gränssnittstestning

En kort checklista håller gränssnittstäckningen ärlig över alla versioner. Gå igenom den för varje anslutning snarare än för applikationen som helhet.

• medtracförst: Bekräfta att förfrågnings- och svarsscheman matchar den publicerade specifikationen, fält för fält, inklusive datatyper och valfria fält.
• Gränsvärden: Skicka tomma nyttolaster, fält med maximal längd, oväntade teckenuppsättningar och omvända datumformat.
• Felsökvägar: Verifiera att varje fel returnerar en meningsfull kod och ett meddelande snarare än en stack trace eller en tyst framgång.
• Timeouts och återförsök: Avbryt anslutningen mitt i en begäran och bekräfta att anroparen försöker igen på ett säkert sätt utan att duplicera transaktionen.
• Säkerhet: Kontrollera autentisering, auktorisering och kryptering på länken och bekräfta att felmeddelanden inte läcker interna detaljer.
• Datakonsistens: Läs posten bakåt från den andra sidan och bekräfta att ingenting har avkortats, kodats om eller ordnats om under transporten.
• Volym: Upprepa anropet med högst trafik under samtidig belastning och titta på om anslutningspoolen är uttömd.

Tre metoder gör den checklistan upprepningsbar. För det första, automatisera sviten och kör den på varje build, eftersom gränssnitt ändras tystare än skärmar. För det andra, logga hela begäran och svaret för varje fel, eftersom ett gränssnittsfel är nästan omöjligt att reproducera från en skärmdump. För det tredje, håll sviten oberoende av testdata som skapats av andra sviten, så att ett fel pekar på gränssnittet snarare än på en saknad post.

Dessa kontroller ligger naturligt inom den bredare planen som beskrivs i typer av mjukvarutestning, och de körs innan samma anslutningar utövas ände till ände under systemtestning.

Gränssnittstestning kontra integrationstestning

De två termerna är relaterade snarare än motsatta: gränssnittstestning är den del av integrationsarbetet som koncentrerar sig på själva anslutningen. Tabellen nedan anger betoningen för varje sida.

Den som är ny inom den bredare disciplinen kommer att finna de omgivande nivåerna som beskrivs i integrationstest och i allmänhet mjukvarutestning introduktion, medan terminologin som används ovan kommer från standard mjukvaruutveckling För webbläsarstyrda system används så småningom samma anslutningar igen under testning av webbapplikationer.

Vanliga frågor