using json interface testing
Använda JSON för gränssnitttestning:
Gränssnitttestning verifierar kommunikationen mellan två olika system. Det utförs på den applikation som testas för att verifiera om fram och tillbaka kommunikationen mellan två nätverk utförs korrekt.
Ett gränssnitt är i grunden anslutningen mellan två mjukvarusystem och att testa den anslutningen för dataöverföring kallas gränssnitttestning. Gränssnittet täcker ett brett utbud av tjänster i den verkliga världen, det kan användas för att hänvisa till webbtjänst, API, etc.
Ett gränssnitt innehåller en uppsättning regler, meddelanden, kommandon etc som underlättar kommunikationen mellan två system.
Denna testning koncentrerar sig främst på testning av två huvudsegment:
- Databas- och applikationsserverkommunikation
- Webb- och applikationsserverkommunikation
Gränssnitttest utförs för att utvärdera ovan nämnda scenarier för att validera om komponenterna korrekt skickar kontrollen och data till varandra korrekt. Det verifierar också interaktionen mellan olika moduler.
Vad du kommer att lära dig:
- Varför utförs gränssnitttest?
- Hur utförs det?
- Skillnaden mellan gränssnitttestning och integrationstestning
- Affärsscenario
- Testa miljöinställningar
- Starta din testning
- Slutsats
- Rekommenderad läsning
Varför utförs gränssnitttest?
Det utförs för att säkerställa:
- IIom kommunikationen mellan systemen utförs korrekt.
- All programvara och hårdvara som används i systemet fungerar korrekt.
- Alla dokument som är länkade till kommunikationen finns på alla integrerade plattformar.
- Säkerhets- och krypteringskrav följer kommunikationen mellan systemen.
- De integrerade komponenterna kan hantera nätverksfel och kommunikationsförlust.
Typer av fel som hittats
De flesta av de fel som hittats i testet på användargränssnittet beror på felaktig mappning av data mellan systemen. Därför kan de flesta buggarna i grunden klassificeras i följande kategorier.
- Inkonsekvent dataöverföring mellan de två systemen.
- Ett av systemen tolkar dataöverföring från ett annat system felaktigt.
- Överföringskanalen eller gränssnittet mellan de två systemen misslyckas och det begränsar dataöverföringen mellan systemen och orsakar därmed att hela gränssnittet misslyckas.
Hur utförs det?
Det kan huvudsakligen kategoriseras i följande faser:
- Gränssnitt kan testas individuellt under systemtestning . Denna typ av testning utförs huvudsakligen med stub eller dummy-system. Ett dummy-system eller stub imiterar beteendet för hela systeminteraktionen.
- En annan instans där gränssnitttestet utförs är en korsning där två system kommunicerar med varandra.
- Därför testar vi om data som skickas av ett system har kartlagts korrekt och införts i ett annat system eller inte. Utöver datainföringen kontrollerar vi också om dataintegritet, dvs. data, när de sätts in i ett annat system, har inte manipulerats eller ändrats, etc.
- Testning kan också utföras när ett system överför data till en annan applikationsdatabas. Här kommer vi att testa om data från ett system har införts korrekt i en viss kolumn i den angivna tabellen baserat på kartläggningen. Vi kommer också att testa dataintegriteten och datakonsistensen med avseende på källsystemet.
I alla dessa testscenarier utförs gränssnitttest baserat på affärsbehov och affärsflödesregler.
Skillnaden mellan gränssnitttestning och integrationstestning
Verifiering och validering av slut-till-slut-funktionalitet för komponenter som är anslutna tillsammans kallas Integrationstestning eller mer populärt som test av systemintegration. Integrationstestning validerar huvudsakligen om två eller flera system integrerade tillsammans har fungerat felfritt tillsammans eller inte.
Testning Gränssnitt å andra sidan koncentrerar sig i princip på anslutningskanalen mellan de två systemen. Anslutningskanalen mellan två eller flera system kallas ett gränssnitt. Testning av denna anslutningskanal kallas Interface Testing. De flesta gränssnitt är antingen API: er eller webbtjänster. Det har inget användargränssnitt men tar en inmatning och ger användaren en utdata.
Till exempel
I exemplet ovan delar webbplatsen och databasen ett gränssnitt för att överföra inloggningsinformationen, dvs. användarnamn och lösenord.
Gränssnittet använder webbtjänst för att skicka inloggningsinformationen till databasen, vilket i sin tur validerar äktheten hos det inkommande meddelandet (användarnamn och lösenord) och returnerar värdet som sant om både användarnamnet och lösenordet matchar den post som finns i databasen eller falskt om något av dem eller både användarnamnet och lösenordet inte stämmer överens med de uppgifter som finns inuti.
Låt oss diskutera exempel på gränssnitttestning:
Låt oss säga att vi har en applikation där vi har olika databaser som interagerar med varandra.
I denna exempel , kommer vi att överväga två databasinteraktioner via en gränssnittskanal.
Låt oss överväga att det finns två databaser eller applikationer, databas A och B. 'A' överför en del data till 'B', som sedan används av B för att utföra vissa operationer. Efter att ha utfört en viss operation på inkommande data infogar B dessa data i databasen och skapar en utdata-JSON för bekräftelse med listan över uppdaterade data och skickar den tillbaka till A.
Både A och B använder gränssnittskanal för kommunikation mellan dem.
Affärsscenario
”A” innehåller medarbetardata för alla anställda som tillhör ekonomiavdelningen.
Uppgifterna måste överföras till “B ' dagligen. ”B” innehåller uppgifter om allmänna anställda. All data från 'A' måste överföras till en viss tabell och kolumn 'B'. Förutom inmatningsdata måste 'B' också sortera och organisera data. Det måste också se till att uppgifterna har matats in mot rätt anställd.
När data har matats in i systemet ska 'B' skicka en utdata-JSON för att bekräfta om data har införts i databasen.
I händelse av avvikelse i JSON-schema eller saknade data kommer 'B' inte att behandla data och det kommer att skicka ett avvisa JSON-meddelande med anledningen till avslag.
Testa miljöinställningar
För att testa ett scenario som det här behöver vi en teststub för att efterlikna databasen 'A'. Utvecklaren kan tillhandahålla en plats där du antingen kan dumpa ditt test-JSON eller ett mock-gränssnitt och klistra in dina JSON-data och åberopa behandlingen genom gränssnittet. För teständamål kan vi också ha en utmatningsplats där vi kan få bekräftelsen JSON från “B”.
I vår exempel , kommer vi att använda en mappsökväg där vi kommer att testa JSON, tjänsten kommer ständigt att hitta platsen för JSON-filen. När filen är närvarande tar tjänsten upp filen och skickar den till “B” via gränssnittet. När filen har hämtats raderas den från hämtningsplatsen.
Starta din testning
När testmiljön har ställts in är nästa steg att skapa testdata.
När vi skapar testdata (läs test JSON) bör vi ha några saker i åtanke:
- Följ affärsreglerna.
- Se till att de obligatoriska fälten finns.
- Ändra värdet på fälten enligt affärsreglerna för varje test.
- Se till att JSON-schemat har rätt format.
- Se till att nomenklaturen för JSON-filnamnet har följts.
Låt oss ta en titt på provtestet JSON vi kommer att använda för testning:
{ 'employeeID ': 2569875, 'LastName': “Jackson”, 'baseSalary': 2569, 'DesignationCode':'P102', “Expenditure”:{ 'Month':“Feb”, 'Year': 2017, 'Official':560, 'Others”:0, } }
Börja ditt test
När du har skapat din JSON-testfil släpper du den vid upphämtningsplatsen. Tjänsten hämtar detta och lägger upp det i databas B.
Scenarier att testa:
Det kan finnas ett antal scenarier som måste testas för detta exempel som:
- Arbetar med webbtjänsten för att skicka och ta emot data.
- Dataintegritet för indata. Detta kan valideras genom att fråga tabeller och kolumner i databas B för de data som matats in genom testet JSON.
- Negativa scenarier.
Först kontrollerar vi om JSON-testfilen har hämtats från platsen eller inte finns på platsen. Detta kommer att validera tjänsten. Därefter navigerar vi till utdatamappen för att visa utdata JSON. Närvaro av utdata JSON validerar om ingångsdata har skickats till databas B och bekräftelse för densamma har mottagits.
Nästa del av testningen består av att validera de data som matats in i databasen.
I ovanstående test kommer vi att validera om data som skickas via JSON-testet har skrivits in korrekt i databasen. Vi kommer att validera dataintegritet, datakonsekvens och infoga data. Vi måste fråga databas B för den angivna kolumnen i en viss tabell för att validera om data har införts korrekt i tabellen.
Låt oss säga att vi har EmpDetails-tabell där data måste infogas. Så vi kommer att köra en fråga för att validera data.
Frågan kommer att vara ungefär så här:
SELECT employeeID, LastName, baseSalary, DesignationCode, Month, Year, Official, Others FROM EmpDetails Where employeeID = 2569875;
Här kommer vi att använda medarbetar-ID som den primära nyckeln för att fråga informationen i EmpDetails-tabellen. Vi kommer att fråga med alla kolumnnamn där data har infogats. Sedan kan data i kolumnnamnet valideras med data som skickas via JSON.
I ovanstående fall lagras data från JSON i mer än en tabell i databasen, så du kan använda SQL JOINS för att hämta alla önskade data.
Det tredje steget i testningen blir att testa de negativa scenarierna.
Några av de negativa scenarierna som kan testas är:
- Systemets beteende när fel data matas via JSON.
- När JSON har fel schema eller struktur.
- När den bearbetade JSON saknas den primära nyckeln eller några obligatoriska fält.
- Nomenklaturen för JSON-filen är inte giltig.
I alla dessa fall bör systemet kunna hantera dessa scenarier och inga data ska införas i systemet enligt affärsregeln.
Slutsats
Anslutningskanalen mellan två system genom vilka data överförs kallas ett gränssnitts- och gränssnitttest fungerar främst kring testningen av dessa anslutningar. De flesta gränssnitt använder webbtjänster eller API: er. Det har inte alltid ett användargränssnitt men det accepterar inmatning och ger utdata.
vänster koppling vs vänster yttre koppling
JSON är ett av de mest använda dataöverföringsformaten och kan användas för gränssnittsdataöverföring.
En testare måste ha grundläggande kunskap om JSON-strukturen för att skapa testdata (i form av JSON) och för att läsa utdata från systemet. En testare bör också vara väl insatt i kartläggningen mellan JSON-nycklar och databastabellkolumn.
Alla testare som vill arbeta med gränssnitttestning bör ha en klar kunskap om affärsriktlinjerna och reglerna för en applikation. En testare bör också ha tillräcklig kunskap om databasen och bör kunna skriva enkla SQL-frågor.
För frågor eller förtydliganden, vänligen kontakta oss i kommentarsektionen.
Handledning nr 5: JSON intervjufrågor
Rekommenderad läsning
- Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
- Databastestning med JMeter
- Testing Primer eBook Download
- 40+ bästa databastestverktyg - Populära datatestlösningar
- GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide
- En enkel metod för testning av XML till databas
- ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
- Vad är gränssnitttestning? Känn dess typer, strategi och verktyg