Menu

En enkel tilgang til XML til databasetestning

simple approach xml database testing

Prøv Vores Instrument Til At Fjerne Problemer

Denne artikel hjælper med at forstå XML til Databasetestkoncept , hvilket er en udfordrende testtype .

Datasammenligningen er en kritisk opgave at udføre med kvalitet. Enhver fejl vil resultere i en eller flere fejl i en applikation.

XML er et elektronisk kommunikationsmeddelelsesformat, der indeholder data, og databasen er et fysisk lager med tabeller / kolonner, der indeholder data.

xml til DB-test

De fleste applikationer udveksler data med hinanden. Disse kommunikationer kan være i form af XML-meddelelser, der indeholder data. Disse data lagres også i et databasesystem, og når det kræves, hentes dataene af applikationerne.

Læs også => En fremragende måde at datatest på ved hjælp af XML-teknologier

De fleste domæner såsom økonomi, marketing, salg, e-handel, bil, logistik og produktion bruger denne teknik til datakommunikation med applikationer.

For at gøre testningen af ​​XML til database vellykket er det mest afgørende input kortlægningsdokument der definerer hvert element i XML versus kolonnerne i databasen.

Kortlægningsdokumentet giver en komplet repræsentation af elementerne (XML) til kolonnerne (DB). XML-elementværdierne kan være et input til DB-tabeller eller omvendt.

world of warcraft pvp privat server

Med denne artikel vil du have en god forståelse af, hvordan du tester XML-meddelelsesdata til databasedata for datanøjagtighed.

Hvad du vil lære:

Lad os tale om XML og database:

Applikationer bruger forskellige teknikker til at kommunikere med hinanden. Beskedkommunikation ved hjælp af XML er en af ​​dem. XML er en pålidelig teknik til at kommunikere meddelelser (data) mellem to applikationer. XML indeholder sæt elementer, der har specifikke værdier. Nogle gange kan værdierne være NULL eller tomme.

Database gemmer data i form af tabeller. En database indeholder flere tabeller. En applikation kan føje data ind i tabellen i en database, og også tabeldataene kan hentes af applikationer, når det er nødvendigt.

xml til datatest 1

Nu kan applikationer gemme / hente data fra databasetabeller i form af XML, og det er ret pålidelig / fleksibel teknik at gøre det.

Applikationsarkitektur:

Som tester er det vigtigt at:

  • Gå gennem produktarkitekturen for at forstå, hvordan applikationerne kommunikerer meddelelser mellem moduler / databaser / Når du har gennemgået denne info og fundet ud af, at der er uoverensstemmelser / spørgsmål, kan BA / SA nås til afklaring.
  • Forstå opstrøms og nedstrøms applikationsdatastrømme.
  • Den indgående og udgående datastrøm til en applikation.

I nogle tilfælde kan opstrøms- og nedstrømsapplikationer være databaser med forskellige applikationer, og de kommunikerer / transmitterer data i XML-format ved hjælp af lagrede procedurer, webservices, API'er osv. I andre kan der være en kombination af databaser og applikationer, der kommunikerer data med hinanden.

XML Vs Data Testing 2

Eksempel:

Lad os overveje en applikation, der kommunikerer med en database for at gemme data i denne XML-til-database-testartikel.

Vi har en downstream-applikation IBAPX , som overfører meddelelser i XML-format til en databaseapplikation MYDBX . Vi har en upstream-applikation OBAPX , der henter data fra MYDBX til en rapporteringsansøgning RPTX og det er en opstrøms applikation til OBAPX .

Bemærk: Inden du starter, skal du kende teknologien, der bruges til middlewarekommunikation (Stored Procedure, Webservice, API osv.) Og kende arkitekturen tydeligt. Disse oplysninger findes normalt i designdokumentet eller hos SA / BA / Dev-teams.

Nu gemmer applikation IBAPX data i databaseapplikationen MYDBX. For at vide hvilket element af xml der er kortlagt til kolonnen i tabellen, skal vi henvise kortlægningsdokument . Undertiden kan XML-elementer og kolonnenavne være ens eller ikke. Forskellen skyldes et forretningsbehov.

For eksempel . Lad os sige, at IBAPX sender element med navnet som salgsordrenummer , men når MYDBX gemmer den samme elementværdi i en tabel, henviser den til den som p_orderid kolonnenavn. Dette kan skyldes, at XML-elementet omtales som salgsrelateret enhed, når den samme værdi er gemt i tabellen, kan kolonnenavnet muligvis være ændret til at henvise til produktionsanvendelse. Dette kan ændre sig i andre applikationer alt efter forretningsbehov.

Sådan tester du:

Hvordan præcist kan en tester nu teste alle scenarierne effektivt og effektivt? Lad os diskutere.

Først og fremmest tager du input XML-filen og valider XML-strukturen dvs. elementer. Dette kan gøres ved hjælp af XSD, der definerer strukturen for den respektive XML.

XSD-filen ligner XML, og den definerer XML-strukturen, som elementnavn, elementtype, minOccurs, maxOccurs osv. Når XML-valideringen er færdig, skal du eksportere den til at excelere. Træk bare xml-filen til et nyt Excel-ark. Det giver dig en popup, der spørger, hvordan du vil åbne filen, bare vælg 'Som en XML-tabel'. Dataene gemmes i excel-filen som tabel.

Du kan se data, der er udfyldt i tabellen, forespørge tabellen med de specifikke data og hente posten. Kopier dataene til den samme excel-fil til et andet ark. Brug nu EXACT-funktionen i Excel, og du kan nemt sammenligne XML-data vs DB-data. Sørg for, at du kun sammenligner data, ikke kolonnenavnene.

På denne måde kan du sammenligne flere postdata og kan spare en masse manuel indsats til sammenligning af XML-elementdataværdier vs DB-kolonnedataværdier.

Find nedenstående snap til reference:

XML Vs datatest 3

XML Vs datatest 4

XML Vs datatest 5

Bemærk: I ovenstående billede kan du se, at kolonnenavnene ikke matchede, som vi diskuterede før.

Tip: Nogle gange kan du stå over for et problem, mens du sammenligner stor størrelse XML vs DB. I så fald er det eneste, du skal styre, at arrangere kolonneværdierne i excel-arket. Husk en ting: Excel-fil sammenligning skal være begrænset til 100 MB filstørrelse . Du vil støde på ydeevneproblemer, hvis du går ud over.

Som vi diskuterede før, kan XML-elementværdierne være et input til DB-tabeller eller omvendt. Så når du først får XML-beskeden som indgående fil til et program fra et DB-program, skal du udføre ovenstående testteknik for at sammenligne dataværdierne for XML vs DB. Engang er vi nødt til at udføre E2E-test, hvor flere applikationer behandler dataene.

Eksempel på virkelige liv:

En bruger har bestilt en bog fra Flipkart, et e-handelswebsted. Udgangspunktet er, at brugeren bestiller en vare, og slutpunktet er ved modtagelse af fakturakopi i e-handelscenter. Derefter kan der opstå nogle scenarier som returnering af ordre eller ordreudveksling, betalingsretur og så videre.

Her er flere moduler som salg, lager, varebehandling, logistik, betaling, retur, tilbud osv. Involveret for at behandle en ordre, indtil varen når kunden. E2E-strømmen kommunikerer beskeder for at udføre ordren.

Som tester, når du deltager i E2E-testen, skal du muligvis komme på tværs af de scenarier, hvor du vil validere Application vs DB eller DB til DB eller Application to Application-data. Her skal du have en fuldstændig klarhed om E2E-dataflytning, dvs. hvad skal de data, der modtages af en applikation eller sendes af applikationen, og hvad er de data, der lagres i DB eller hentes fra DB?

Fejlscenarier:

Lad os diskutere om nogle mulige fejlscenarier.

  • Et simpelt fejlscenarie er forkert kortlægning . Kortlægningen mellem XML-elementerne og DB-kolonnerne skal analyseres af en tester under analyse- eller planlægningsfasen. Diskuter alle kortlægningsproblemer med BA / SA for at afklare tvivl. Når kortlægningen er frossen, kan du sikre, at XML-elementerne i forhold til DB-kolonneværdierne stemmer overens.
  • Sammenlign værdierne, og hvis det ikke stemmer overens, skal du logge en defekt for at løse problemet. Der er mange muligheder for den defekt, der er rejst, som Datadefekt - Kan være problem med testdata ; Kodefejl - Kan være fejlen i koden, som parser dataværdierne for ikke at kortlægge; Artefaktfejl - Kan være forkert kortlægning leveret af BA / SA.
  • Problem med XML-format - XML-header eller metadata eller nogle forkerte xml-tags. I dette tilfælde kunne XML selv ikke gemme dataværdierne i databasetabellen.
  • Datatypefejl - Elementværdien i XML har mere char i længden, hvilket er mere end DB-kolonnen kan acceptere. Dette vil være et kodeproblem, og dev-teamet skal foretage de nødvendige ændringer i datatypelængden for den pågældende kolonne.
  • Miljøsvigt - Miljø nede eller DB-applikation nede, datastrømmen forbliver ufuldstændig.
  • Problem med ydeevne - Kan være mængden af ​​poster, der består af, at beskeden er enorm, eller belastningen på DB'en kan være høj til at begynde med, at record består for stor.
  • Middlewarefejl vil medføre dataflytning fra applikation til database.
  • Problem med databaseadgang på grund af hvilken den indgående applikation ikke er i stand til at sende dataene til den respektive tabel.

Konklusion:

XML til databasetestning vil være mere kompleks, når en enkelt XML-besked gemmer data i flere systemer. Også udførelsen af ​​en database til lagring / hentning af store datamængder vil være en udfordring for en tester at teste sådanne scenarier.

Ovenstående eksempel er et lille segment af testaktiviteter, der udføres i en applikation. En tester skal muligvis udføre en stor mængde datatest med en lignende tilgang.

Fortæl os venligst dine kommentarer, spørgsmål og erfaring nedenfor.

Anbefalet læsning

^