Meny

En enkel tilnærming for XML til databasetesting

simple approach xml database testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Denne artikkelen vil hjelpe deg å forstå XML til Database testing konsept , som er en utfordrende testtype .

Datasammenligningen er en kritisk oppgave å utføre med kvalitet. Enhver feil vil føre til en eller flere feil i en applikasjon.

XML er et elektronisk kommunikasjonsmeldingsformat som inneholder data, og Database er en fysisk lagring med tabeller / kolonner som inneholder data.

xml til DB-testing

De fleste applikasjoner utveksler data med hverandre. Disse kommunikasjonene kan være i form av XML-meldinger som inneholder data. Også disse dataene lagres i et databasesystem, og når det er nødvendig blir dataene hentet av applikasjonene.

Les også => En utmerket måte å datateste ved hjelp av XML-teknologier

De fleste domener som økonomi, markedsføring, salg, e-handel, bil, logistikk og produksjon bruker denne teknikken for datakommunikasjon med applikasjoner.

For å gjøre XML til databasetesting vellykket, er det mest avgjørende input kartleggingsdokument som definerer hvert element i XML kontra kolonnene i databasen.

Kartleggingsdokumentet vil gi en fullstendig representasjon av elementene (XML) til kolonnene (DB). XML-elementverdiene kan være en inngang til DB-tabeller eller omvendt.

beste eksterne desktop-programvaren for Windows

Med denne artikkelen vil du ha god forståelse av hvordan du tester XML-meldingsdata til databasedataene for datanøyaktighet.

Hva du vil lære:

La oss snakke om XML og database:

Applikasjoner bruker forskjellige teknikker for å kommunisere med hverandre. Meldingskommunikasjon ved hjelp av XML er en av dem. XML er en pålitelig teknikk for å kommunisere meldinger (data) mellom to applikasjoner. XML inneholder sett med elementer som har spesifikke verdier. Noen ganger kan verdiene være NULL eller tomme.

Database lagrer data i form av tabeller. En database inneholder flere tabeller. En applikasjon kan mate data i tabellen i en database, og tabelldataene kan også hentes av applikasjoner når det er nødvendig.

xml til datatesting 1

Nå kan applikasjoner lagre / hente data fra databasetabeller i form av XML, og det er ganske pålitelig / fleksibel teknikk å gjøre det.

Søknadsarkitektur:

Som tester er det viktig å:

  • Gå gjennom produktarkitekturen for å forstå hvordan applikasjonene kommuniserer meldinger mellom moduler / databaser / Når du har gått gjennom denne informasjonen og funnet ut at det er noen uoverensstemmelser / spørsmål, kan BA / SA nås for avklaring.
  • Forstå oppstrøms- og nedstrøms applikasjonsdataflyter.
  • Inn- og utgående dataflyt til et program.

I noen tilfeller kan oppstrøms- og nedstrømsapplikasjoner være databaser for forskjellige applikasjoner, og de kommuniserer / overfører data i XML-format ved hjelp av lagrede prosedyrer, webtjenester, APIer, etc. I andre kan det være en kombinasjon av databaser og applikasjoner som kommuniserer data med hverandre.

XML mot datatesting 2

Eksempel:

For denne XML to Database-testartikkelen, la oss vurdere et program som kommuniserer med en database for å lagre data.

Vi har en nedstrøms applikasjon IBAPX , som overfører meldinger i XML-format til en databaseapplikasjon MYDBX . Vi har en oppstrømsapplikasjon OBAPX , som henter data fra MYDBX for en rapporteringssøknad RPTX og det er en oppstrøms applikasjon til OBAPX .

Merk: Før du begynner, må du kjenne teknologien som brukes til mellomvarekommunikasjon (Stored Procedure, Webservice, API, etc) og kjenne arkitekturen tydelig. Denne informasjonen er vanligvis i designdokumentet eller hos SA / BA / Dev-team.

Nå lagrer applikasjon IBAPX data i databaseapplikasjonen MYDBX. For å vite hvilket element av xml som er tilordnet kolonnen i tabellen, må vi referere kartleggingsdokument . Noen ganger kan XML-elementer og kolonnenavn være like eller ikke. Forskjellen skyldes et forretningsbehov.

F.eks . la oss si at IBAPX sender element med navnet som salgsordrenummer , men når MYDBX lagrer den samme elementverdien i en tabell, refererer den til den som p_orderid kolonnenavn. Dette kan skyldes at XML-elementet blir referert til som salgsrelatert enhet. Når den samme verdien er lagret i tabellen, kan kolonnenavnet ha blitt endret for å referere til produksjonsbruk. Dette kan endres i andre applikasjoner i henhold til forretningsbehovet.

Hvordan teste:

Nå, hvordan kan en tester teste alle scenariene effektivt og effektivt? La oss diskutere.

Først av alt tar du XML-filen og validere XML-strukturen dvs. elementer. Dette kan gjøres ved hjelp av XSD som definerer strukturen for den respektive XML.

XSD-filen ser ut som XML, og den definerer strukturen til XML, som elementnavn, elementtype, minOccurs, maxOccurs, etc. Når XML-valideringen er fullført, eksporterer du den til å utmerke seg. Bare dra xml-filen til et nytt Excel-ark. Det vil gi deg en popup som spør hvordan du vil åpne filen, bare velg 'Som en XML-tabell'. Dataene lagres i Excel-filen som tabell.

Du kan se data fylt inn i tabellen, spørre tabellen med de spesifikke dataene og hente posten. Kopier dataene til den samme Excel-filen til et annet ark. Nå som du bruker EXACT-funksjonen i excel, kan du enkelt sammenligne XML-data mot DB-data. Forsikre deg om at du bare sammenligner data, ikke kolonnenavnene.

På denne måten kan du sammenligne flere postdata og kan spare mye manuell innsats for å sammenligne XML-elementdataverdier mot DB-kolonnedataverdier.

Finn snap nedenfor for referanse:

XML mot datatesting 3

XML mot datatesting 4

XML mot datatesting 5

Merk: På bildet ovenfor kan du se at kolonnenavnene ikke stemte overens som vi diskuterte tidligere.

Tips: Noen ganger kan du møte et problem mens du sammenligner stor størrelse XML mot DB. I så fall er det eneste du trenger å administrere, å ordne kolonneverdiene i excel-arket. Husk en ting: Excel fil sammenligning bør være begrenset til 100 MB filstørrelse . Du vil møte ytelsesproblemer hvis du går utover.

Som vi diskuterte tidligere, kan XML-elementverdiene være en inngang til DB-tabeller eller omvendt. Så når du først får XML-meldingen som innkommende fil til et program fra et DB-program, må du utføre testteknikken ovenfor for å sammenligne dataverdiene til XML vs DB. En gang må vi utføre E2E-testing der flere applikasjoner behandler dataene.

Eksempel på virkeligheten:

En bruker har bestilt en bok fra Flipkart, et e-handelssted. Utgangspunktet er at brukeren bestiller en vare, og sluttpunktet er å motta fakturakopi på e-handelssenteret. Deretter kan noen scenarier som retur av ordre eller ordreutveksling, betalingsretur og så videre forekomme.

Her er flere moduler som salg, varelager, varebehandling, logistikk, betaling, retur, tilbud osv involvert for å behandle en ordre til varen når kunden. E2E-strømmen kommuniserer meldinger for å oppfylle bestillingen.

Som en tester når du skal delta i E2E-testing, kan det hende du må komme over scenariene der du vil validere Application vs DB eller DB to DB eller Application to Application data. Her bør du ha fullstendig klarhet i E2E-dataflyten, dvs. hva skal være dataene som mottas av en applikasjon eller sendes av applikasjonen, og hva er dataene som lagres i DB eller hentes fra DB.

Feilsituasjoner:

La oss diskutere om noen mulige feilscenarier.

  • Et enkelt feilscenario er feil kartlegging . Kartleggingen mellom XML-elementene og DB-kolonnene bør analyseres i løpet av analyse- eller planleggingsfasen av en tester. Diskuter alle kartproblemene med BA / SA for å avklare tvil. Når kartleggingen er frossen, kan du sikre at XML-elementene i forhold til DB-kolonneverdiene samsvarer.
  • Sammenlign verdiene, og hvis det ikke stemmer overens, logg en feil for å løse problemet. Det er mange muligheter for mangelen som er opphevet, som datadefekt - kan være testdata problem ; Kodefeil - Kan være feilen i koden som analyserer dataverdiene slik at de ikke tilordnes; Artefaktfeil - Kan være feil kartlegging levert av BA / SA.
  • Problem med XML-format - XML-overskrift eller metadata eller noen uriktige xml-koder. I dette tilfellet klarte ikke XML å lagre dataverdiene i databasetabellen.
  • Datatype mismatch - Elementverdien i XML har mer char-lengde som er mer enn DB-kolonnen kan godta. Dette vil være et kodeproblem, og dev-teamet må gjøre nødvendige endringer i datatypelengden for den kolonnen.
  • Miljøsvikt - Miljø ned eller DB-applikasjon nede, datastrømmen forblir ufullstendig.
  • Ytelsesproblem - Kan være mengden poster som består av at meldingen er enorm, eller belastningen på DB kan være høy til å begynne med at record består for stor.
  • Middleware-feil vil føre til at dataflyten slipp fra applikasjon til database.
  • Problem med databasetilgang på grunn av hvilket den innkommende applikasjonen ikke kan sende dataene til den respektive tabellen.

Konklusjon:

XML til databasetesting vil være mer komplisert når en enkelt XML-melding vil lagre data i flere systemer. Også ytelsen til databasen for lagring / henting av stort datamengde vil være en utfordring for en tester å teste slike scenarier.

Ovennevnte eksempel er et lite segment av testaktiviteter som utføres i en applikasjon. En tester kan trenge å gjøre en stor mengde datatesting med en lignende tilnærming.

Gi oss beskjed om dine kommentarer, spørsmål og erfaring nedenfor.

Anbefalt lesing

^