Návod na testování databáze (dat).

GUI obvykle kladou největší důraz členové testovacího a vývojového týmu, protože grafické uživatelské rozhraní je shodou okolností nejviditelnější částí aplikace. Co je však také důležité, je ověřit informace, které jsou srdcem aplikace, neboli DATABÁZE.

Vezměme si bankovní aplikaci, ve které uživatel provádí transakce. Nyní z hlediska testování databáze nebo testování DB jsou věci důležité:

1. Aplikace ukládá informace o transakcích v databázi aplikace a zobrazuje je správně uživateli.
2. V procesu se neztratí žádné informace.
3. Aplikace neukládá žádné informace o částečně provedené nebo přerušené operaci.
4. Žádná neoprávněná osoba nemá povolen přístup k informacím uživatele.

Abychom zajistili všechny tyto výše uvedené cíle, musíme použít ověřování dat nebo testování dat.

Rozdíly mezi testováním uživatelského rozhraní a testováním dat

Testování uživatelského rozhraní	Databáze nebo testování dat
Tento typ testování je také známý jako testování grafického uživatelského rozhraní nebo front-end testování.	Tento typ testování je také známý jako Backend Testing nebo testování dat.
Tento typ testování se zabývá především všemi testovatelnými položkami, které jsou uživateli otevřeny pro sledování a interakci, jako jsou formuláře, prezentace, grafy, nabídky a sestavy atd. (vytvořené prostřednictvím VB, VB.net, VC++, Delphi – nástroje front-end)	Tento typ testování se zabývá především všemi testovatelnými položkami, které jsou uživateli pro sledovanost obecně skryty. Patří mezi ně interní procesy a úložiště Assembly, jako DBMS Oracle, SQL Server, MYSQL atd.
Tento typ testování zahrnuje ověření textová pole vyberte rozbalovací nabídky kalendáře a tlačítka Navigace po stránce zobrazení obrázků Vzhled a dojem z celkové aplikace	Tento typ testování zahrnuje ověření: schéma databázové tabulky sloupce klíče a indexy spouštěče uložených procedur ověřování databázových serverů ověřování duplikace dat
Tester musí mít důkladné znalosti o obchodních požadavcích, stejně jako o používání vývojových nástrojů a používání automatizačních rámců a nástrojů.	Aby mohl tester provádět backendové testování, musí mít dobré zázemí v databázovém serveru a konceptech strukturovaného dotazovacího jazyka.

Typy testování databáze

Existují 3 typy testování databáze

1. Strukturální testování
2. Funkční testování
3. Nefunkční testování

V tomto tutoriálu Testování databáze se podíváme na každý typ a jeho podtypy jeden po druhém.

Co je testování schémat?

Testování schématu při testování databáze ověřuje různé formáty schémat související s databází a ověřuje, zda jsou formáty mapování tabulek/pohledů/sloupců kompatibilní s formáty mapování uživatelského rozhraní. Hlavním účelem testování schémat je zajistit, aby mapování schématu mezi front-endem a back-endem bylo podobné. Proto se také označuje jako testování mapování.

Pojďme diskutovat o nejdůležitějších kontrolních bodech pro testování schématu.

1. Ověření různých formátů schémat spojených s databázemi. Formát mapování tabulky často nemusí být kompatibilní s formátem mapování přítomným na úrovni uživatelského rozhraní aplikace.
2. V případě nenamapovaných tabulek/pohledů/sloupců je potřeba ověření.
3. Je také potřeba ověřit, zda jsou heterogenní databáze v prostředí konzistentní s celkovým mapováním aplikací.

Podívejme se také na některé zajímavé nástroje Database Testing pro ověřování databázových schémat.

• Jednotka DBUnit integrovaná s Ant je velmi vhodná pro testování mapování.
• SQL Server umožňuje testerům, aby mohli kontrolovat a dotazovat se na schéma databáze psaním jednoduchých dotazů a nikoli prostřednictvím kódu.

Pokud například vývojáři chtějí změnit strukturu tabulky nebo ji odstranit, tester se bude chtít ujistit, že všechny uložené procedury a pohledy, které používají tuto tabulku, jsou kompatibilní s konkrétní změnou. Dalším příkladem může být, že pokud chtějí testeři zkontrolovat změny schématu mezi 2 databázemi, mohou to udělat pomocí jednoduchých dotazů.

Tabulka databáze, Testování sloupců

Podívejme se na různé kontroly pro testování databáze a sloupců.

1. Je mapování databázových polí a sloupců v backendu kompatibilní s mapováním v front-endu?
2. Ověření délky a konvence pojmenování databázových polí a sloupců podle požadavků.
3. Ověření přítomnosti všech nepoužívaných/nemapovaných databázových tabulek/sloupců.
4. Ověření kompatibility

• datový typ
• délky polí

back-endových databázových sloupců s těmi, které jsou přítomny na front-endu aplikace.

5. Zda databázová pole umožňují uživateli poskytovat požadované uživatelské vstupy, jak to vyžadují dokumenty se specifikací obchodních požadavků.

Testování klíčů a indexů

Důležité kontroly klíčů a indexů –

1. Zkontrolujte, zda je požadováno

• Primární klíč
• Cizí klíč

omezení byla vytvořena na požadovaných tabulkách.

2. Zkontrolujte, zda jsou odkazy na cizí klíče platné.
3. Zkontrolujte, zda se datový typ primárního klíče a odpovídajících cizích klíčů v obou tabulkách shodují.
4. Zkontrolujte, zda byly u všech klíčů a indexů dodrženy požadované konvence pojmenování.
5. Zkontrolujte velikost a délku požadovaných polí a indexů.
6. Zda požadované

• Clustered indexy
• Ne Clustered indexy

byly vytvořeny na požadovaných tabulkách, jak je specifikováno v obchodních požadavcích.

Testování uložených procedur

Důležité testy pro kontrolu uložených procedur jsou:

1. Zda vývojový tým přijal požadované, A) standardní konvence kódování a B) zpracování výjimek a chyb. Pro všechny uložené procedury pro všechny moduly pro testovanou aplikaci.
2. Pokryl vývojový tým všechny podmínky/cykly aplikací požadovaných vstupních dat na testovanou aplikaci?
3. Zda vývojový tým správně použil operaci TRIM, kdykoli jsou data načítána z požadovaných tabulek v databázi?
4. Poskytuje ruční spuštění uložené procedury koncovému uživateli požadovaný výsledek?
5. Zajistí ruční spuštění uložené procedury aktualizace polí tabulky podle požadavků testované aplikace?
6. Umožňuje provádění uložených procedur implicitní vyvolání požadovaných spouštěčů?
7. Ověření přítomnosti všech nepoužívaných uložených procedur.
8. Ověření podmínky Allow Null, kterou lze provést na úrovni databáze.
9. Ověření skutečnosti, že všechny uložené procedury a funkce byly úspěšně provedeny, když je testovaná databáze prázdná.
10. Ověření celkové integrace modulů uložených procedur podle požadavků testované aplikace.

Některé z užitečných nástrojů pro testování databází pro testování uložených procedur jsou LINQ, SP Test tool atd.

Testování spouště

1. Byly během fáze kódování spouštěčů dodrženy požadované konvence kódování?
2. Zkontrolujte, zda spouštěče provedené pro příslušné transakce DML splňují požadované podmínky.
3. Aktualizuje spouštěč data správně po jejich provedení?
4. Ověření požadované funkce Aktualizovat/Vložit/Odstranit spouští funkcionalitu v oblasti testované aplikace.

Ověření databázového serveru

1. Zkontrolujte konfigurace databázového serveru podle obchodních požadavků.
2. Zkontrolujte oprávnění požadovaného uživatele k provádění pouze těch úrovní akcí, které aplikace vyžaduje.
3. Zkontrolujte, zda je databázový server schopen uspokojit potřeby maximálního povoleného počtu uživatelských transakcí, jak je uvedeno ve specifikacích obchodních požadavků.

Funkční testování databáze

Funkční testování databáze je typ testování databáze, který se používá k ověření funkčních požadavků databáze z pohledu koncového uživatele. Hlavním cílem funkčního testování databáze je otestovat, zda transakce a operace prováděné koncovými uživateli, které se týkají databáze, fungují podle očekávání či nikoli.

Níže jsou uvedeny základní podmínky, které je třeba dodržovat při ověřování databází.

• Zda je pole povinné, když jsou v tomto poli povoleny hodnoty NULL?
• Je délka každého pole dostatečná?
• Mají všechna podobná pole v tabulkách stejné názvy?
• Jsou v databázi přítomna nějaká vypočítaná pole?

Tento konkrétní proces je ověřením mapování polí z pohledu koncového uživatele. V tomto konkrétním scénáři by tester provedl operaci na úrovni databáze a poté by přešel k příslušné položce uživatelského rozhraní, aby pozoroval a ověřil, zda byly nebo nebyly provedeny správné ověření v terénu.

Měla by být také provedena podmínka naopak, kdy je první operace provedena testerem na uživatelském rozhraní a poté je totéž ověřeno z back-endu.

Kontrola integrity a konzistence dat

Důležité jsou následující kontroly

1. Jsou data logicky dobře uspořádána?
2. Jsou data uložená v tabulkách správná a odpovídají obchodním požadavkům?
3. Jsou v testované aplikaci nějaká zbytečná data?
4. Zda byla data uložena podle požadavku s ohledem na data, která byla aktualizována z uživatelského rozhraní?
5. Proběhly operace TRIM s daty před vložením dat do testované databáze?
6. Zda byly transakce provedeny podle specifikací obchodních požadavků a zda jsou výsledky správné či nikoli?
7. Byla data správně potvrzena, pokud byla transakce úspěšně provedena?
8. Byla data úspěšně vrácena zpět, pokud transakce nebyla úspěšně provedena koncovým uživatelem?
9. Byla data vrácena zpět, pokud transakce nebyla úspěšně provedena a do dané transakce bylo zapojeno více heterogenních databází?
10. Zda byly všechny transakce provedeny pomocí požadovaných návrhových postupů, jak je specifikováno v obchodních požadavcích systému?

Zabezpečení přihlášení a uživatele

Při ověřování přihlašovacích údajů a pověření zabezpečení uživatele je třeba vzít v úvahu následující věci.

1. Zda aplikace brání uživateli v dalším postupu v aplikaci v případě a

• neplatné uživatelské jméno, ale platné heslo
• platné uživatelské jméno, ale neplatné heslo.
• neplatné uživatelské jméno a neplatné heslo.

2. Může uživatel provádět pouze ty specifické operace, které jsou specifikovány obchodními požadavky?
3. Jsou data zabezpečena proti neoprávněnému přístupu?
4. Existují různé uživatelské role vytvořené s různými oprávněními?
5. Mají všichni uživatelé požadované úrovně přístupu ke specifikované databázi, jak to vyžadují obchodní specifikace?
6. Zkontrolujte, zda jsou citlivá data, jako jsou hesla, čísla kreditních karet, zašifrována a nejsou uložena v databázi jako prostý text. Je dobrým zvykem zajistit, aby všechny účty měly hesla, která jsou složitá a nelze je snadno uhodnout.

Nefunkční testování

Nefunkční testování v kontextu testování databáze lze rozdělit do různých kategorií, jak to vyžadují obchodní požadavky. Mohou to být zátěžové testy, zátěžové testy, Testování bezpečnosti, Testování použitelnosti, a Testování kompatibility, a tak dále. Zátěžové testování, stejně jako zátěžové testování, které lze seskupit do rozsahu testování výkonu, slouží dvěma specifickým účelům, pokud jde o roli nefunkčního testování.

Kvantifikace rizik– Kvantifikace rizika pomáhá zúčastněným stranám zjistit různé požadavky na dobu odezvy systému při požadovaných úrovních zatížení. To je původní záměr každého zabezpečování jakosti úkol. Musíme poznamenat, že zátěžové testování nesnižuje riziko přímo, ale prostřednictvím procesů identifikace a kvantifikace rizik představuje příležitosti k nápravě a podnět k nápravě, která riziko zmírní.

Minimální požadavek na systémové vybavení– Minimální konfigurace systému, která umožní systému splnit formálně stanovená výkonnostní očekávání zúčastněných stran. Aby bylo možné minimalizovat externí hardware, software a související náklady na vlastnictví. Tento konkrétní požadavek lze kategorizovat jako celkový požadavek na optimalizaci podnikání.

Testování zatížení

Účel jakékoli zátěžové zkoušky by měl být jasně pochopen a zdokumentován. Následující typy konfigurací jsou nutností zátěžové testování.

1. Nejčastěji používané uživatelské transakce mají potenciál ovlivnit výkon všech ostatních transakcí, pokud nejsou efektivní.
2. Do konečné testovací sady by měla být zahrnuta alespoň jedna uživatelská transakce bez úprav, aby bylo možné odlišit provedení takových transakcí od jiných složitějších transakcí.
3. Měly by být zahrnuty důležitější transakce, které usnadňují hlavní cíle systému, protože selhání při zatížení těmito transakcemi má podle definice největší dopad.
4. Měla by být zahrnuta alespoň jedna upravitelná transakce výkon těchto transakcí lze odlišit od ostatních transakcí.
5. Optimální doba odezvy pod velkým počtem virtuálních uživatelů pro všechny potenciální požadavky.
6. Efektivní časy pro načítání různých záznamů.

Důležité nástroje pro zátěžové testování jsou LoadRunner Professional, vyhrát běžec a JMeter.

Důležité nástroje pro zátěžové testování jsou LoadRunner Professional si JMeter.

Nejčastěji se vyskytující problémy během testování databáze

A significant amount of overhead could be involved to determine the state of the database transactions

Řešení: Celkové plánování a načasování procesu by mělo být organizováno tak, aby se neobjevily žádné problémy s časem a náklady.

New test data have to be designed after cleaning up of the old test data.

Řešení: Měl by být k dispozici předchozí plán a metodika pro generování testovacích dat.

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

Řešení: Údržba SQL dotazů a jejich průběžná aktualizace je významnou součástí celkového testovacího procesu, který by měl být součástí celku testovací strategie.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

Řešení: Měla by existovat jemná rovnováha mezi kvalitou a celkovou dobou trvání projektu.

Mýty nebo mylné představy související s testováním databází

Database Testing requires plenty of expertise and it is a very tedious job

Realita: Efektivní a efektivní testování databází v testování softwaru zajišťuje dlouhodobou funkční stabilitu celé aplikace, a proto je nutné za tím tvrdě pracovat.

Database testing adds extra work bottleneck

Realita: Naopak testování databáze přidává celkové práci větší hodnotu tím, že zjišťuje skryté problémy a tím proaktivně pomáhá vylepšovat celkovou aplikaci.

Database testing slows down the overall development process

Realita: K celkovému zkvalitnění databázové aplikace přispívá značné množství testování databáze.

Database testing could be excessively costly

Realita: Veškeré výdaje na testování databáze jsou dlouhodobou investicí, která vede k dlouhodobé stabilitě a robustnosti aplikace. Tedy výdaje na Testování databáze resp SQL Testování je nutné.

Doporučené postupy

• Všechna data včetně metadat i funkčních dat je třeba validovat podle jejich mapování v dokumentech specifikace požadavků.
• Ověření testovací data který byl vytvořen / po konzultaci s vývojovým týmem, musí být ověřen.
• Validace výstupních dat pomocí manuálních i automatizačních postupů.
• Nasazení různých technik, jako je technika grafu příčin a následků, technika rozdělení ekvivalence a technika analýzy hraničních hodnot pro generování požadovaných podmínek testovacích dat.
• Ověřovací pravidla referenční integrity pro požadované databázové tabulky je také třeba ověřit.
• Výběr výchozích hodnot tabulky pro ověření konzistence databáze je velmi důležitý koncept, zda byly události protokolu úspěšně přidány do databáze pro všechny požadované události přihlášení.
• Provádějí se naplánované úlohy včas?
• Proveďte včasnou zálohu databáze.

Zkontrolujte také - Otázky a odpovědi na pohovor k testování databáze