Menu

Jednoduchý přístup pro testování XML k databázi

simple approach xml database testing

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Tento článek pomůže porozumět XML Koncept testování databáze , což je náročné typ testování .

Porovnání dat je zásadní úkol, který je třeba dosáhnout kvalitním způsobem. Jakákoli chyba způsobí jednu nebo více selhání aplikace.

XML je formát zprávy elektronické komunikace, který obsahuje data, a databáze je fyzické úložiště s tabulkami / sloupci obsahujícími data.

Testování XML na DB

Většina aplikací si navzájem vyměňuje data. Tato komunikace může mít formu zpráv XML, které obsahují data. Také tato data jsou ukládána do databázového systému a v případě potřeby jsou data načítána aplikacemi.

Přečtěte si také => Vynikající způsob testování dat pomocí technologií XML

Většina domén, jako jsou finance, marketing, prodej, eCommerce, automobilový průmysl, logistika a výroba, používá tuto techniku ​​pro datovou komunikaci s aplikacemi.

Aby bylo testování XML na databázi úspěšné, nejdůležitějším vstupem je mapovací dokument který definuje každý prvek v XML versus sloupce v databázi.

Mapovací dokument poskytne úplné zastoupení prvků (XML) přidružení sloupců (DB). Hodnoty prvků XML mohou být vstupem do tabulek DB nebo naopak.

spyware na mobilní telefon

V tomto článku budete dobře rozumět tomu, jak testovat data zpráv XML na data databáze na přesnost dat.

Co se naučíte:

Promluvme si o XML a databázi:

Aplikace používají ke vzájemné komunikaci různé techniky. Jednou z nich je komunikace zpráv pomocí XML. XML je spolehlivá technika pro komunikaci zpráv (dat) mezi dvěma aplikacemi. XML obsahuje sadu prvků, které mají konkrétní hodnoty. Někdy mohou být hodnoty NULL nebo prázdné.

Databáze ukládá data ve formě tabulek. Databáze obsahuje několik tabulek. Aplikace může vložit data do tabulky v databázi a také data tabulky mohou aplikace načíst, pokud je to požadováno.

xml k testování dat 1

Aplikace nyní mohou ukládat / načítat data z databázových tabulek ve formě XML a je to docela spolehlivá / flexibilní technika.

Architektura aplikace:

Jako tester je důležité:

  • Projděte si architekturu produktu, abyste pochopili, jak aplikace komunikují zprávy mezi moduly / databázemi / Jakmile projdete tyto informace a zjistíte, že existují nějaké nesrovnalosti / otázky, můžete se k objasnění obrátit na BA / SA.
  • Pochopte toky dat před a za aplikací.
  • Příchozí a odchozí datový tok do aplikace.

V některých případech mohou být upstream a downstream aplikacemi databáze různých aplikací a tyto komunikují / přenášejí data ve formátu XML pomocí uložených procedur, webových služeb, API atd. V jiných může existovat kombinace databází a aplikací, které komunikují data jeden s druhým.

Testování dat XML Vs 2

Příklad:

V tomto článku o testování XML na databázi pojďme uvažovat o aplikaci, která komunikuje s databází za účelem ukládání dat.

Máme následnou aplikaci IBAPX , který přenáší zprávy ve formátu XML do databázové aplikace MYDBX . Máme upstreamovou aplikaci OBAPX , který načítá data z MYDBX pro aplikaci hlášení RPTX a je to upstream aplikace pro OBAPX .

Poznámka: Než začnete, znáte technologii používanou pro komunikaci s middlewarem (Uložená procedura, Webservice, API atd.) A znáte jasně architekturu. Tyto informace jsou obvykle v konstrukčním dokumentu nebo u týmů SA / BA / Dev.

Aplikace IBAPX nyní ukládá data do databázové aplikace MYDBX. Abychom věděli, který prvek xml je namapován na sloupec tabulky, musíme se odkázat mapovací dokument . Někdy prvky XML a názvy sloupců mohou být stejné nebo ne. Rozdíl je způsoben obchodní potřebou.

Např . řekněme, že IBAPX posílá prvek s názvem jako prodejní číslo , ale když MYDBX ukládá stejnou hodnotu prvku do tabulky, odkazuje na ni jako p_orderid název sloupce. To může být způsobeno skutečností, že element XML je označován jako entita související s prodejem, když je v tabulce uložena stejná hodnota, mohl být název sloupce změněn tak, aby odkazoval na produkční použití. To se může v jiných aplikacích změnit podle obchodních potřeb.

Jak testovat:

Jak přesně může tester efektivně a efektivně testovat všechny scénáře? Pojďme diskutovat.

Nejprve vezmete vstupní soubor XML a ověřte strukturu XML tj. prvky. To lze provést pomocí XSD, které definuje strukturu pro příslušný XML.

Soubor XSD vypadá jako XML a definuje strukturu XML, jako je název prvku, typ prvku, minOccurs, maxOccurs atd. Po dokončení ověření XML jej exportujte do aplikace Excel. Jednoduše přetáhněte soubor XML na nový list aplikace Excel. Zobrazí se vyskakovací okno s dotazem, jak chcete soubor otevřít, stačí vybrat možnost „Jako tabulku XML“. Data se uloží do souboru aplikace Excel jako tabulka.

Můžete vidět data naplněná do tabulky, dotazovat se na tabulku s konkrétními daty a načíst záznam. Zkopírujte data do stejného souboru aplikace Excel na jiný list. Nyní pomocí funkce EXACT v aplikaci Excel můžete snadno porovnat data XML s daty DB. Ujistěte se, že budete porovnávat pouze data, nikoli názvy sloupců.

Tímto způsobem můžete porovnat více dat záznamu a může ušetřit spoustu manuálního úsilí pro porovnání datových hodnot prvků XML s hodnotami dat sloupce DB.

Níže naleznete snímek pro referenci:

Testování dat XML Vs 3

Testování dat XML Vs 4

Testování dat XML Vs 5

Poznámka: Na obrázku výše můžete vidět, že názvy sloupců se neshodovaly, jak jsme diskutovali dříve.

Spropitné: Někdy se můžete setkat s problémem při porovnávání velkých formátů XML a DB. V takovém případě je potřeba spravovat pouze uspořádání hodnot sloupců v listu aplikace Excel. Pamatujte si jednu věc: Porovnání souborů aplikace Excel by mělo omezena na velikost souboru 100 MB . Pokud jdete dále, narazíte na problémy s výkonem.

Jak jsme již diskutovali dříve, hodnoty prvků XML mohou být vstupem do tabulek DB nebo naopak. Jakmile tedy obdržíte zprávu XML jako příchozí soubor do aplikace z aplikace DB, musíte provést výše uvedenou testovací techniku ​​a porovnat hodnoty dat XML vs. DB. Někdy musíme provést testování E2E, kde data zpracovává více aplikací.

Příklad ze skutečného života:

Uživatel si objednal knihu z webu Flipkart, elektronického obchodu. Výchozím bodem je uživatel objednávající položku a koncovým bodem je přijetí kopie faktury v centru elektronického obchodu. Poté mohou nastat některé scénáře, jako je vrácení objednávky nebo výměna objednávky, vrácení platby atd.

Zde je do zpracování objednávky zapojeno více modulů, jako je prodej, inventář, zpracování zboží, logistika, platby, vrácení, nabídky atd., Dokud se položka nedostane k zákazníkovi. Tok E2E komunikuje zprávy za účelem splnění objednávky.

Jako tester, když se zapojíte do testování E2E, možná budete muset narazit na scénáře, kde budete ověřovat data aplikace vs. databáze nebo databáze DB nebo aplikace aplikace. Zde byste měli mít úplnou jasnost v toku dat E2E, tj. Co by měla být data přijatá aplikací nebo zaslaná aplikací a jaká jsou data uložená v DB nebo načtená z DB.

Scénáře selhání:

Pojďme diskutovat o některých možných scénářích selhání.

  • Jeden jednoduchý scénář selhání je nesprávné mapování . Mapování mezi sloupci prvků XML vs DB by mělo být během fáze analýzy nebo plánování analyzováno testerem. Diskutujte o všech problémech s mapováním s BA / SA, abyste vyjasnili pochybnosti. Jakmile je mapování zamrzlé, můžete zajistit, aby se hodnoty prvků XML proti sloupcům DB shodovaly.
  • Porovnejte hodnoty a pokud se neshoduje, přihlaste se k závadě a problém vyřešte. Existuje mnoho možností pro vznik defektu, například Data defect - May be the problém s testovacími daty ; Vada kódu - Může to být chyba v kódu, který analyzuje datové hodnoty, aby se nemapovaly; Vada artefaktu - může to být nesprávné mapování poskytnuté společností BA / SA.
  • Problém s formátem XML - Záhlaví XML nebo metadata nebo některé nesprávné značky XML. V tomto případě samotné XML nedokázalo uložit hodnoty dat do databázové tabulky.
  • Neshoda datového typu - Hodnota prvku v XML má více char na délku, což je více, než může sloupec DB přijmout. Bude to problém s kódem a tým vývojářů musí provést nezbytné změny v délce datového typu pro daný sloupec.
  • Selhání prostředí - Prostředí dole nebo aplikace DB dole, tok dat zůstává neúplný.
  • Problém s výkonem - Může to být množství záznamů sestávajících ze zprávy je obrovské nebo zatížení databáze může být vysoké, aby bylo možné začít se záznamem sestávat je příliš velké.
  • Selhání middlewaru způsobí pokles datového toku z aplikace do databáze.
  • Problém s přístupem k databázi kvůli kterému příchozí aplikace nemůže odeslat data do příslušné tabulky.

Závěr:

Testování XML na databázi bude složitější, když jedna zpráva XML uloží data do více systémů. Také výkon databáze pro ukládání / načítání velkého objemu dat bude pro testera výzvou testovat takové scénáře.

Výše uvedený příklad je malým segmentem testovacích aktivit prováděných v aplikaci. Možná bude muset tester provést velké množství testování dat podobným přístupem.

Níže nám sdělte své připomínky, dotazy a zkušenosti.

Doporučené čtení

^