Menu

Jednoduchý prístup k testovaniu XML na databázu

simple approach xml database testing

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Tento článok pomôže pochopiť XML Koncept testovania databázy , čo je náročné testovací typ .

Porovnanie údajov je kľúčovou úlohou, ktorú je potrebné dosiahnuť kvalitne. Akákoľvek chyba spôsobí jednu alebo veľa zlyhaní v aplikácii.

XML je formát správy elektronickej komunikácie, ktorý obsahuje údaje, a Databáza je fyzické úložisko s tabuľkami / stĺpcami obsahujúcimi údaje.

Testovanie XML na DB

Väčšina aplikácií si navzájom vymieňa údaje. Táto komunikácia môže mať formu správ XML, ktoré obsahujú údaje. Tieto údaje sa tiež ukladajú do databázového systému a v prípade potreby ich aplikácie načítajú.

Prečítajte si tiež => Vynikajúci spôsob testovania údajov pomocou technológií XML

Väčšina domén, ako sú financie, marketing, predaj, eCommerce, automobilový priemysel, logistika a výroba, používa túto techniku ​​na dátovú komunikáciu s aplikáciami.

Aby bolo testovanie XML na databázu úspešné, najdôležitejším vstupom je mapovací dokument ktorý definuje každý prvok v XML oproti stĺpcom v databáze.

Mapovací dokument poskytne úplné znázornenie prvkov (XML) priradeniu stĺpcov (DB). Hodnoty prvkov XML môžu byť vstupom do tabuliek DB alebo naopak.

ako používať arrays.sort v jave

V tomto článku získate dobré informácie o tom, ako testovať presnosť údajov správ XML na údaje databázy.

Čo sa dozviete:

Poďme si povedať o XML a databáze:

Aplikácie používajú na vzájomnú komunikáciu rôzne techniky. Jednou z nich je komunikácia správ pomocou XML. XML je spoľahlivá technika na komunikáciu správ (dát) medzi dvoma aplikáciami. XML obsahuje množinu prvkov, ktoré majú konkrétne hodnoty. Niekedy môžu byť hodnoty NULL alebo prázdne.

Databáza ukladá údaje vo forme tabuliek. Databáza obsahuje niekoľko tabuliek. Aplikácia môže vkladať údaje do tabuľky v databáze a aplikácie môžu v prípade potreby tiež načítať údaje z tabuľky.

xml na testovanie dát 1

Aplikácie teraz môžu ukladať / načítať údaje z databázových tabuliek vo forme XML a je to celkom spoľahlivá / flexibilná technika.

Architektúra aplikácie:

Ako tester je dôležité:

  • Prejdite si architektúru produktu, aby ste pochopili, ako aplikácie komunikujú správy medzi modulmi / databázami. Keď prejdete týmito informáciami a zistíte, že existujú nejaké nezrovnalosti / otázky, môžete na vysvetlenie kontaktovať spoločnosť BA / SA.
  • Pochopte toky dátových aplikácií smerom nahor a nadol.
  • Prichádzajúce a odchádzajúce údaje prúdia do aplikácie.

V niektorých prípadoch môžu byť aplikáciami typu upstream a downstream databázy rôznych aplikácií, ktoré komunikujú / prenášajú údaje vo formáte XML pomocou uložených procedúr, webových služieb, rozhraní API atď. V iných prípadoch môže existovať kombinácia databáz a aplikácií, ktoré komunikujú údaje. spolu.

Testovanie údajov XML vs.

Príklad:

V tomto článku o testovaní XML na databázu uvažujme o aplikácii, ktorá komunikuje s databázou na ukladanie údajov.

Máme následnú aplikáciu IBAPX , ktorý prenáša správy vo formáte XML do databázovej aplikácie MYDBX . Máme aplikáciu proti prúdu OBAPX , ktorý načítava údaje z MYDBX pre aplikáciu na nahlasovanie RPTX a je to nadradená aplikácia pre OBAPX .

Poznámka: Skôr ako začnete, poznajte technológiu použitú na komunikáciu s middleware (Uložená procedúra, Webservice, API atď.) A jasne poznajte architektúru. Tieto informácie sú zvyčajne v dokumente o dizajne alebo v tímoch SA / BA / Dev.

Aplikácia IBAPX teraz ukladá údaje do databázovej aplikácie MYDBX. Aby sme vedeli, ktorý prvok xml je namapovaný na stĺpec tabuľky, musíme sa odkázať mapovací dokument . Niekedy môžu byť prvky XML a názvy stĺpcov rovnaké alebo nie. Rozdiel je spôsobený obchodnou potrebou.

Napr . povedzme, že IBAPX posiela prvok s menom ako predajne cislo , ale keď MYDBX ukladá rovnakú hodnotu prvku do tabuľky, odkazuje na ňu ako p_orderid názov stĺpca. Môže to byť spôsobené tým, že prvok XML sa označuje ako entita súvisiaca s predajom, keď sa v tabuľke uloží rovnaká hodnota, mohol sa zmeniť názov stĺpca, aby odkazoval na produkčné použitie. To sa môže zmeniť v iných aplikáciách podľa obchodných potrieb.

Ako testovať:

Ako konkrétne môže tester efektívne a efektívne testovať všetky scenáre? Poďme diskutovať.

Najskôr si vezmete vstupný súbor XML a overiť štruktúru XML teda prvky. To sa dá dosiahnuť pomocou nástroja XSD, ktorý definuje štruktúru príslušného XML.

Súbor XSD vyzerá ako XML a definuje štruktúru XML, ako je názov prvku, typ prvku, minOccurs, maxOccurs atď. Po dokončení overenia XML ho exportujte do programu Excel. Stačí pretiahnuť súbor XML na nový hárok programu Excel. Zobrazí sa kontextové okno s otázkou, ako chcete súbor otvoriť, stačí zvoliť možnosť „Ako tabuľku XML“. Údaje sa uložia do súboru programu Excel ako tabuľka.

Môžete vidieť údaje naplnené v tabuľke, dotazovať sa na tabuľku konkrétnymi údajmi a načítať záznam. Skopírujte údaje do rovnakého súboru programu Excel na iný hárok. Teraz pomocou funkcie EXACT v programe Excel môžete ľahko porovnať údaje XML s údajmi DB. Porovnajte iba údaje, nie názvy stĺpcov.

Týmto spôsobom môžete porovnať viac záznamových údajov a môže ušetriť veľa manuálneho úsilia na porovnanie dátových hodnôt prvkov XML vs hodnotám údajov stĺpca DB.

Nájdete nasledujúci obrázok pre referenciu:

Testovanie údajov XML vs.

Testovanie údajov XML vs.

Testovanie údajov XML vs.

Poznámka: Na obrázku vyššie môžete vidieť, že názvy stĺpcov sa nezhodujú, ako sme už diskutovali.

Tip: Pri porovnávaní veľkých formátov XML a DB sa niekedy môžete stretnúť s problémom. V takom prípade musíte spravovať iba usporiadanie hodnôt stĺpcov v hárku programu Excel. Pamätajte na jednu vec: Porovnanie súborov programu Excel by malo byť obmedzené na veľkosť súboru 100 MB . Ak pôjdete ďalej, narazíte na problémy s výkonom.

Ako sme už diskutovali, hodnoty prvkov XML môžu byť vstupom do tabuliek DB alebo naopak. Takže akonáhle dostanete správu XML ako prichádzajúci súbor do aplikácie z aplikácie DB, musíte vykonať vyššie uvedenú testovaciu techniku ​​na porovnanie dátových hodnôt XML vs DB. Niekedy musíme vykonať testovanie E2E, kde údaje spracúva viac aplikácií.

Príklad zo skutočného života:

Používateľ si objednal knihu na webe elektronického obchodu Flipkart. Počiatočným bodom je používateľ objednávajúci položku a koncovým bodom je prijatie kópie faktúry v centre elektronického obchodu. Potom môžu nastať niektoré scenáre, ako napríklad vrátenie objednávky alebo výmena objednávky, vrátenie platby atď.

Tu je do spracovania objednávky zapojených viac modulov, ako je predaj, inventár, spracovanie položky, logistika, platby, vrátenie, ponuky atď., Kým sa položka nedostane k zákazníkovi. Tok E2E komunikuje správy na splnenie objednávky.

Ako tester, keď sa zapojíte do testovania E2E, možno budete musieť naraziť na scenáre, v ktorých budete overovať údaje Application vs DB alebo DB to DB alebo Application to Application. Tu by ste mali mať úplnú jasnosť v toku údajov E2E, t. J. Aké by mali byť údaje prijaté aplikáciou alebo odoslané aplikáciou a aké sú údaje uložené v databáze DB alebo načítané z databázy DB.

Scenáre zlyhania:

Poďme sa rozprávať o niektorých možných scenároch zlyhania.

  • Jeden jednoduchý scenár zlyhania je nesprávne mapovanie . Mapovanie medzi stĺpcami prvkov XML a DB by malo byť analyzované počas fázy analýzy alebo plánovania testerom. Diskutujte o všetkých problémoch s mapovaním s BA / SA a objasnite pochybnosti. Po zmrazení mapovania môžete zaistiť zhodu hodnôt stĺpcov XML a DB.
  • Porovnajte hodnoty a ak sa nezhoduje, na vyriešenie problému zaregistrujte chybu. Existuje mnoho možností pre vzniknutú chybu, napríklad Data defect - May be the problém s testovacími údajmi ; Chyba kódu - môže to byť chyba v kóde, ktorá analyzuje údajové hodnoty tak, aby sa nezmapovali; Chyba artefaktu - môže to byť nesprávne mapovanie poskytnuté spoločnosťou BA / SA.
  • Problém s formátom XML - Hlavička XML alebo metadáta alebo niektoré nesprávne značky XML. V takom prípade samotný XML nedokázal uložiť hodnoty údajov do databázovej tabuľky.
  • Nezhoda dátového typu - Hodnota prvku v XML má viac znakov, čo je viac, ako je možné v stĺpci DB. Pôjde o problém s kódom a tím vývojárov musí vykonať potrebné zmeny v dĺžke dátového typu pre tento stĺpec.
  • Zlyhanie prostredia - Ak nefunguje prostredie alebo je spustená aplikácia DB, tok údajov zostáva neúplný.
  • Problém s výkonom - Môže to byť množstvo záznamov pozostávajúcich zo správy, alebo môže byť vysoké zaťaženie databázy, aby bolo možné začať so záznamom, že správa je príliš veľká.
  • Zlyhanie middlewaru spôsobí pokles dátového toku z aplikácie do databázy.
  • Problém s prístupom k databáze kvôli ktorej prichádzajúca aplikácia nedokáže odoslať údaje do príslušnej tabuľky.

Záver:

Testovanie XML na databázu bude zložitejšie, keď bude jedna správa XML ukladať údaje do viacerých systémov. Testovanie týchto scenárov bude pre testera výzvou aj výkonnosť databázy na ukladanie / načítanie veľkého množstva údajov.

Vyššie uvedený príklad je malým segmentom testovacích aktivít, ktoré sa vykonávajú v aplikácii. Možno bude potrebné, aby tester vykonal veľké množstvo dátových testov s podobným prístupom.

Nižšie nám dajte vedieť svoje pripomienky, otázky a skúsenosti.

Odporúčané čítanie

^