Meny

En enkel metod för testning av XML till databas

simple approach xml database testing

Prova Vårt Instrument För Att Eliminera Problem

Den här artikeln hjälper dig att förstå XML till Databastestningskoncept , vilket är en utmaning testtyp .

Datajämförelsen är en viktig uppgift att utföra med kvalitet. Eventuella brister kommer att resultera i ett eller flera fel i en applikation.

XML är ett elektroniskt kommunikationsmeddelandeformat som innehåller data och databas är en fysisk lagring med tabeller / kolumner som innehåller data.

xml till DB-testning

De flesta applikationer utbyter data med varandra. Dessa kommunikationer kan vara i form av XML-meddelanden som innehåller data. Dessa data lagras också i ett databassystem och vid behov hämtas data av applikationerna.

Läs också => Ett utmärkt sätt att datatestas med XML-teknik

De flesta domäner som ekonomi, marknadsföring, försäljning, e-handel, bil, logistik och tillverkning använder denna teknik för datakommunikation med applikationer.

För att göra testningen av XML till databas framgångsrik är den viktigaste inmatningen mappningsdokument som definierar varje element i XML kontra kolumnerna i databasen.

Kartdokumentet ger en fullständig representation av elementen (XML) till kolumnerna (DB). XML-elementvärdena kan vara en inmatning till DB-tabeller eller vice versa.

bästa drivrutinsprogramvaran för Windows 10

Med den här artikeln kommer du att ha en god förståelse för hur du testar XML-meddelandedata till databasdata för datainkorrektion.

Vad du kommer att lära dig:

Låt oss prata om XML och databas:

Applikationer använder olika tekniker för att kommunicera med varandra. Meddelandekommunikation med XML är en av dem. XML är en pålitlig teknik för att kommunicera meddelanden (data) mellan två applikationer. XML innehåller uppsättning element som har specifika värden. Ibland kan värdena vara NULL eller tomma.

Databasen lagrar data i form av tabeller. En databas innehåller flera tabeller. En applikation kan mata in data i tabellen i en databas och även tabelldata kan hämtas av applikationer vid behov.

xml till datatestning 1

Nu kan applikationer lagra / hämta data från databastabeller i form av XML, och det är en ganska tillförlitlig / flexibel teknik att göra det.

Applikationsarkitektur:

Som testare är det viktigt att:

  • Gå igenom produktarkitekturen för att förstå hur applikationerna kommunicerar meddelanden mellan moduler / databaser / När du har gått igenom den här informationen och upptäckt att det finns några inkonsekvenser / frågor kan BA / SA nås för att förtydliga.
  • Förstå dataflödet för applikationer uppströms och nedströms.
  • In- och utgående dataflöde till en applikation.

I vissa fall kan applikationerna uppströms och nedströms vara databaser för olika applikationer och de kommunicerar / överför data i XML-format med hjälp av lagrade procedurer, webbtjänster, API, etc. I andra kan det finnas en kombination av databaser och applikationer som kommunicerar data med varandra.

XML mot datatestning 2

Exempel:

Låt oss överväga en applikation som kommunicerar med en databas för att lagra data för denna XML-till-databas-testartikel.

Vi har en nedströmsapplikation IBAPX , som överför meddelanden i XML-format till en databasapplikation MYDBX . Vi har en applikation uppströms OBAPX , som hämtar data från MYDBX för en rapporteringsansökan RPTX och det är en applikation uppströms till OBAPX .

Notera: Innan du börjar känner du till tekniken som används för mellanvarukommunikation (Stored Procedure, Webservice, API, etc) och känner till arkitekturen tydligt. Denna information finns vanligtvis i designdokumentet eller med SA / BA / Dev-team.

Nu lagrar applikation IBAPX data i databasapplikationen MYDBX. För att veta vilket element i xml som är mappat till kolumnen i tabellen måste vi hänvisa mappningsdokument . Ibland kan XML-element och kolumnnamn vara desamma eller inte. Skillnaden beror på ett affärsbehov.

T.ex . låt oss säga att IBAPX skickar element med namnet som försäljningsnummer , men när MYDBX lagrar samma elementvärde i en tabell hänvisar det till det som p_orderid kolumnnamn. Detta kan bero på att XML-elementet kallas försäljningsrelaterad enhet, när samma värde lagras i tabellen kan kolumnnamnet ha ändrats för att hänvisa till produktionsanvändning. Detta kan förändras i andra applikationer beroende på affärsbehov.

Hur man testar:

Hur exakt kan en testare testa alla scenarier effektivt och effektivt? Låt oss diskutera.

Först och främst tar du in-XML-filen och validera XML-strukturen dvs. element. Detta kan göras med hjälp av XSD som definierar strukturen för respektive XML.

XSD-filen ser ut som XML och definierar strukturen för XML, som elementnamn, elementtyp, minOccurs, maxOccurs, etc. När XML-valideringen är klar exporterar du den till Excel. Dra bara xml-filen till ett nytt Excel-ark. Det ger dig en popup som frågar hur du vill öppna filen, välj bara ”Som en XML-tabell”. Data sparas i Excel-filen som tabell.

Du kan se data som fyllts i tabellen, fråga tabellen med specifika data och hämta posten. Kopiera data till samma Excel-fil till ett annat ark. Nu med EXACT-funktionen i Excel kan du enkelt jämföra XML-data mot DB-data. Se till att du bara jämför data, inte kolumnnamnen.

På detta sätt kan du jämföra flera postdata och kan spara mycket manuell ansträngning för jämförelse av XML-elementdatavärden mot DB-kolumndatavärden.

Hitta nedanstående snap för referens:

XML mot datatestning 3

XML mot datatestning 4

XML mot datatestning 5

Notera: I bilden ovan kan du se att kolumnnamnen inte matchade som vi diskuterade tidigare.

Dricks: Ibland kan du stöta på ett problem när du jämför stora XML-format mot DB. I så fall är det enda du behöver hantera att ordna kolumnvärdena i excel-arket. Kom ihåg en sak: Excel-filjämförelse bör begränsas till 100 MB filstorlek . Du kommer att stöta på prestandaproblem om du går längre än.

Som vi diskuterade tidigare kan XML-elementvärdena vara en input till DB-tabeller eller vice versa. Så när du får XML-meddelandet som inkommande fil till en applikation från en DB-applikation måste du utföra ovanstående testteknik för att jämföra datavärdena för XML mot DB. Någon gång måste vi utföra E2E-testning där flera applikationer bearbetar data.

Exempel på verkliga livet:

En användare har beställt en bok från Flipkart, en e-handelswebbplats. Utgångspunkten är att användaren beställer ett objekt och slutpunkten är att ta emot fakturakopia på e-handelscentret. Därefter kan vissa scenarier som retur av order eller utbyte av order, betalningsretur och så vidare inträffa.

Här är flera moduler som försäljning, lager, artikelhantering, logistik, betalning, returer, erbjudanden etc. involverade för att bearbeta en order tills artikeln når kunden. E2E-flödet kommunicerar meddelanden för att uppfylla ordern.

Som testare när du kommer att delta i E2E-testning kan du behöva stöta på scenarier där du kommer att validera Application vs DB eller DB to DB eller Application to Application data. Här bör du ha en fullständig klarhet i E2E-dataflöde, dvs vad ska vara den data som mottas av en applikation eller skickas av applikationen och vad är den data som lagras i DB eller hämtas från DB.

Fel scenarier:

Låt oss diskutera om några möjliga felscenarier.

  • Ett enkelt felscenario är felaktig mappning . Kartläggningen mellan XML-elementen och DB-kolumnerna ska analyseras under analys- eller planeringsfasen av en testare. Diskutera alla kartläggningsproblem med BA / SA för att klargöra tvivel. När kartläggningen är fryst kan du se till att XML-elementen jämfört med DB-kolumnerna skulle matcha.
  • Jämför värdena och om det inte matchar, logga in en defekt för att åtgärda problemet. Det finns ett antal möjligheter för den defekt som tas upp, som datafel - kan vara problem med testdata ; Kodfel - Kan vara fel i koden som analyserar datavärdena för att inte mappa; Artefaktfel - Kan vara felaktig kartläggning från BA / SA.
  • XML-formatproblem - XML-rubrik eller metadata eller några felaktiga XML-taggar. I det här fallet misslyckades XML i sig att lagra datavärdena i databastabellen.
  • Datatypfel - Elementvärdet i XML har mer char i längd vilket är mer än DB-kolumnen kan acceptera. Detta kommer att vara ett kodproblem och dev-teamet måste göra nödvändiga ändringar i datatypens längd för den kolumnen.
  • Miljöfel - Miljö ner eller DB-applikation nere, dataflödet förblir ofullständigt.
  • Prestandafråga - Kan vara den mängd poster som består av att meddelandet är enormt eller att belastningen på DB kan vara hög för att börja med att posten består är för stor.
  • Middleware-fel kommer att orsaka dataflödet från program till databas.
  • Problem med databasåtkomst på grund av vilken den inkommande applikationen inte kan skicka data till respektive tabell.

Slutsats:

XML-till-databas-testning blir mer komplex när ett enda XML-meddelande lagrar data i flera system. Utförandet av databasen för lagring / hämtning av stora datamängder kommer också att vara en utmaning för en testare att testa sådana scenarier.

Ovanstående exempel är ett litet segment av testaktiviteter som utförs i en applikation. En testare kan behöva göra en stor mängd datatester med en liknande metod.

Låt oss veta dina kommentarer, frågor och erfarenheter nedan.

Rekommenderad läsning

^