Vodič za testiranje baze podataka

Testiranje baze podataka - ponekad nazivano backend testiranjem ili testiranjem podataka - ono je što održava nevidljivu polovicu svake aplikacije poštenom. Ovaj vodič vodi kroz što pokriva, zašto je važno, tri osnovne kategorije testiranja, uobičajene zamke i najbolje prakse koje razlikuju solidne pakete od onih koji propuštaju.

Što je testiranje baze podataka?

Testiranje baze podataka je vrsta testiranja softvera koja provjerava shemu, tablice, okidače, pohranjene procedure i druge objekte testirane baze podataka. Također provjerava integritet, konzistentnost i sigurnost podataka. Testiranje baze podataka često uključuje pisanje složenih upita za testiranje učitavanja ili stresnog testiranja baze podataka i mjerenje njezine odzivnosti.

Zašto je testiranje baze podataka važno?

Testiranje baze podataka je ključno u testiranje softvera jer potvrđuje da su vrijednosti pohranjene u bazi podataka i dohvaćene iz nje valjane. Snažno testiranje baze podataka sprječava gubitak podataka, sadrži prekinute transakcije i blokira neovlašteni pristup informacijama. Budući da je baza podataka srce svake poslovne aplikacije, testeri moraju biti upoznati sa SQL-om.

Većina timova usredotočuje se na GUI jer je to najvidljiviji dio aplikacije. Informacije ispod GUI-ja jednako su važne, a njihova validacija je zadatak testiranja baze podataka. Razmotrimo bankarsku aplikaciju u kojoj korisnik obavlja transakcije. Iz perspektive testiranja baze podataka, moraju vrijediti sljedeće invarijante:

1. Aplikacija pohranjuje svaku transakciju u bazu podataka i ispravno je prikazuje korisniku.
2. Tijekom operacije se ne gube nikakve informacije.
3. Nijedna djelomično dovršena ili prekinuta operacija se ne pohranjuje.
4. Nijedna neovlaštena osoba ne može pristupiti korisničkim podacima.

Potvrđivanje svake od ovih invarijanti je svrha validacije baze podataka i testiranja podataka.

Razlike između testiranja korisničkog sučelja i testiranja podataka

Testiranje korisničkog sučelja	Testiranje baze podataka / podataka
Također poznato kao testiranje grafičkog korisničkog sučelja (GUI) ili front-end testiranje.	Također poznato kao backend testiranje ili testiranje podataka.
Odnosi se na stavke koje korisnik vidi i s kojima može komunicirati - obrasci, prezentacije, grafikoni, izbornici i izvješća (izrađena pomoću VB, VB.NET, VC++, Delphi i slični front-end alati).	Odnosi se na stavke skrivene od korisnika - interne procese i pohranu kao što su DBMS mehanizmi (Oracle, SQL poslužitelj, MySQL).
Uključuje provjeru valjanosti tekstualnih okvira, padajućih izbornika, kalendara, gumba, navigacije stranicama, prikaza slika i cjelokupnog izgleda i dojma.	Uključuje provjeru valjanosti sheme, tablica, stupaca, ključeva i indeksa, pohranjenih procedura, okidača i konfiguracije poslužitelja baze podataka.
Tester treba imati znanje poslovne domene, kao i poznavanje razvojnih alata i okvira za automatizaciju.	Tester treba imati snažno iskustvo u radu s poslužiteljima baza podataka i strukturiranim jezikom upita (SQL).

Vrste testiranja baze podataka

Testiranje baze podataka dijeli se u tri kategorije najviše razine. Svaka provjerava drugačiji sloj steka baze podataka.

1. Strukturno ispitivanje
2. Funkcionalno ispitivanje
3. Nefunkcionalno testiranje

Strukturno testiranje baze podataka

Strukturno testiranje baze podataka validira elemente unutar repozitorija podataka koji se koriste za pohranu, ali ih krajnji korisnici ne manipuliraju izravno. Validacija poslužitelja baze podataka dio je strukturnog testiranja. Uspješno izvršenje zahtijeva snažne SQL vještine.

Što je testiranje sheme?

Ispitivanje sheme provjerava formate sheme povezane s bazom podataka i provjerava je li mapaping tablica, prikaza i stupaca odgovara kartiping očekuje korisničko sučelje. Cilj je osigurati mapu shemeping između front-enda i back-enda je konzistentna. Testiranje sheme se također naziva kartaping testiranje.

Ključne kontrolne točke za testiranje sheme:

1. Validirajte svaki format sheme povezan s bazom podataka. Mapaping Formati na razini tablice često se razlikuju od onih na razini korisničkog sučelja.
2. Provjerite prisutnost nemapiranih tablica, prikaza ili stupaca.
3. Provjerite jesu li heterogene baze podataka u okruženju dosljedne s ukupnom mapom aplikacijeping.

Korisni alati za validaciju shema baza podataka:

• DBUnit integrirano s Antom — dobro prilagođeno za karteping testiranje.
• SQL Server omogućuje testerima da pregledaju shemu pisanjem jednostavnih upita umjesto koda.

Na primjer, ako razvojni tim promijeni ili ukloni tablicu, tester potvrđuje da je svaka pohranjena procedura i prikaz koji referencira tu tablicu kompatibilan s promjenom. Drugi primjer: prilikom usporedbe razlika u shemama između dvije baze podataka, jednostavni upiti prema sistemskom katalogu brzo obavljaju posao.

Tablica baze podataka, testiranje stupaca

1. Provjerite jesu li polja i stupci pozadinske baze podataka jasno usklađeni s njihovim ekvivalentima u prednjem dijelu.
2. Provjerite duljinu i konvencije imenovanja polja i stupaca baze podataka u skladu sa zahtjevima.
3. Otkrijte sve nekorištene ili nemapirane tablice i stupce.
4. Provjerite jesu li tip podataka i duljina polja pozadinskih stupaca kompatibilni s poljima obrasca na prednjem dijelu.
5. Potvrdite da polja baze podataka prihvaćaju korisničke unose potrebne prema specifikaciji poslovnih zahtjeva.

Testiranje ključeva i indeksa

1. Provjerite je li potrebno Osnovni ključ i strani kljuc Postoje ograničenja na potrebnim tablicama.
2. Potvrdite da reference stranog ključa upućuju na valjane zapise.
3. Provjerite odgovara li tip podataka primarnog ključa tipu podataka odgovarajućih stranih ključeva u povezanim tablicama.
4. Potvrdite da konvencije imenovanja ključeva i indeksa slijede standarde projekta.
5. Provjerite veličinu i duljinu indeksiranih polja.
6. Provjerite je li potrebno skupljeni i neklasterirani indeksi kreiraju se na tablicama određenim zahtjevima.

Testiranje pohranjenih procedura

1. Potvrdite da je razvojni tim slijedio potrebne konvencije kodiranja, rukovanje iznimkama i rukovanje greškama za svaku pohranjenu proceduru u svakom modulu.
2. Provjerite da li se svi uvjeti i petlje izvršavaju ulaznim podacima unesenim tijekom testiranja.
3. Potvrdite da se operacija TRIM primjenjuje svaki put kada se podaci dohvaćaju iz potrebnih tablica.
4. Ručno izvršite svaku pohranjenu proceduru i provjerite odgovara li rezultat očekivanjima.
5. Potvrdite da ručno izvršavanje ažurira polja temeljne tablice kako to zahtijeva testirana aplikacija.
6. Provjerite da izvršavanje pohranjene procedure implicitno poziva potrebne okidače.
7. Otkrijte sve nekorištene pohranjene procedure.
8. Validirajte ponašanje za NULL ulaze na razini baze podataka.
9. Potvrdite da se svaka pohranjena procedura i funkcija uspješno izvršava kada je testirana baza podataka prazna.
10. Validirajte end-to-end integraciju modula pohranjenih procedura u odnosu na zahtjeve aplikacije.

Korisni alati za testiranje pohranjenih procedura uključuju LINQ i SP test korisnost.

Testiranje okidača

1. Provjerite jesu li se tijekom razvoja okidača poštovale potrebne konvencije kodiranja.
2. Potvrdite da se okidači aktiviraju na namjeravanim DML transakcijama i samo na njima.
3. Provjerite ažurira li okidač podatke ispravno nakon aktiviranja.
4. Validirajte potrebnu funkcionalnost okidača ažuriranja, umetanja i brisanja unutar testirane aplikacije.

Validacije poslužitelja baze podataka

1. Provjerite konfiguraciju poslužitelja baze podataka u skladu s poslovnim zahtjevima.
2. Provjerite je li korisnik ovlašten samo za radnje koje aplikacija dopušta.
3. Provjerite može li poslužitelj baze podataka podnijeti maksimalno istodobno opterećenje korisničkih transakcija definirano u zahtjevima.

Funkcionalno testiranje baze podataka

Funkcionalno testiranje baze podataka provjerava funkcionalne zahtjeve baze podataka iz perspektive krajnjeg korisnika. Njegov je cilj potvrditi da se transakcije i operacije koje pokreće krajnji korisnik ponašaju kako se očekuje na razini baze podataka.

Osnovni uvjeti koje treba provjeriti tijekom validacije baze podataka:

• Je li svako polje obavezno ili prihvaća NULL vrijednosti.
• Pruža li svako polje dovoljnu duljinu za očekivane podatke.
• Koriste li semantički slična polja isti naziv u svim tablicama.
• Postoje li u bazi podataka izračunata polja i koje formule primjenjuju.

Ova validacija se izvodi u oba smjera. Tester izvodi operaciju na razini baze podataka i provjerava je na korisničkom sučelju, zatim izvodi operaciju na korisničkom sučelju i provjerava je na razini baze podataka.

Provjera integriteta i dosljednosti podataka

1. Provjerite jesu li podaci logički organizirani.
2. Potvrdite da pohranjeni podaci odgovaraju poslovnim zahtjevima.
3. Otkrijte sve nepotrebne podatke u testiranoj aplikaciji.
4. Provjerite jesu li podaci ažurirani s korisničkog sučelja ispravno primljeni u bazu podataka.
5. Potvrdite TRIM operacije na podacima prije umetanja.
6. Provjerite odgovara li svaka transakcija poslovnim specifikacijama i daje li očekivani rezultat.
7. Potvrdite uspješne commite-ove kada se transakcije završe.
8. Potvrdite ispravno vraćanje na prethodno stanje kada transakcija ne uspije.
9. Potvrdite ispravno vraćanje u transakcijama koje obuhvaćaju heterogene baze podataka.
10. Provjerite slijedi li svaka transakcija postupke dizajna definirane u sistemskim zahtjevima.

Prijava i sigurnost korisnika

1. Provjerite blokira li aplikacija pokušaje prijave sa: (a) nevažećim korisničkim imenom + valjanom lozinkom, (b) valjanim korisničkim imenom + nevažećom lozinkom i (c) nevažećim korisničkim imenom + nevažećom lozinkom.
2. Potvrdite da svaki korisnik može izvršavati samo operacije definirane njegovom ulogom.
3. Provjerite jesu li osjetljivi podaci zaštićeni od neovlaštenog pristupa.
4. Potvrdite da postoje različite korisničke uloge s različitim skupovima dopuštenja.
5. Provjerite ima li svaki korisnik razinu pristupa navedenu u poslovnim zahtjevima.
6. Potvrdite da su osjetljivi podaci - lozinke, brojevi kreditnih kartica, osobni identifikatori - šifrirani u stanju mirovanja i nikada se ne pohranjuju kao obični tekst. Svi računi trebali bi koristiti složene, teško pogodne lozinke.

Nefunkcionalno testiranje

Nefunkcionalno testiranje u kontekstu baze podataka pokriva ispitivanje opterećenja, testiranje otpornosti na stres, testiranje sigurnosti, ispitivanje upotrebljivostii testiranje kompatibilnostiTestiranje opterećenja i stresa - oba oblika testiranja performansi - služe dvjema specifičnim svrhama:

• Kvantifikacija rizika: Kvantificiranje rizika pomaže dionicima da utvrde vrijeme odziva sustava pod definiranim razinama opterećenja. To je glavna namjera svakog osiguravanje kvalitete trud. Testiranje opterećenja ne smanjuje rizik izravno; već ga otkriva i stvara poticaj za sanaciju.
• Minimalni hardverski zahtjevi: Testiranje performansi identificira minimalnu infrastrukturu potrebnu za zadovoljavanje navedenih očekivanja performansi, omogućujući timovima da izbjegnu prekomjerno korištenje hardvera i povećanje troškova vlasništva.

Testiranje opterećenja

Svrha svakog testa opterećenja mora biti jasno shvaćena i dokumentirana. Sljedeće konfiguracije su obavezne za ispitivanje opterećenja:

1. Uključite najčešće izvršavane korisničke transakcije, budući da njihova izvedba utječe na svaku drugu transakciju.
2. Uključite barem jednu transakciju koja nije za uređivanje kako biste razlikovali performanse čitanja od performansi pisanja.
3. Uključite transakcije koje pokreću glavni poslovni cilj - neuspjesi ovdje imaju najveći utjecaj.
4. Uključite barem jednu transakciju uređivanja kako biste razlikovali performanse pisanja od performansi čitanja.
5. Izmjerite vrijeme odziva pod maksimalnim projiciranim opterećenjem virtualnog korisnika.
6. Mjerenje latencije dohvaćanja zapisa u velikim razmjerima.

Uobičajeni alati za testiranje opterećenja uključuju LoadRunner Professional, WinRunner i Apache JMeter.

Što je testiranje otpornosti na baze podataka?

Testiranje opterećenja baze podataka primjenjuje veliko opterećenje na bazu podataka dok ne zakaže. To identificira točku kvara sustava. Stres testiranje zahtijeva pažljivo planiranje kako bi se izbjeglo iscrpljivanje resursa na dijeljenoj infrastrukturi. Stres testiranje se naziva i testiranje mučenjem or ispitivanje umoraPogledajte šire tutorijal za testiranje otpornosti na stres za pozadinu. Uobičajeni alati uključuju LoadRunner Professional i JMeter.

Najbolji alati za testiranje baza podataka (2026.)

Pravi alat ovisi o tome koji sloj baze podataka testirate. Tablica u nastavku uparuje uobičajene kategorije s najpoznatijim opcijama.

Kategorija	Oruđe	Najbolje za
Ispitivanje jedinice	DBUnit, tSQLt	Ponovljivi testovi shema i pohranjenih procedura integrirani s Antom ili cjevovodima za izgradnju.
Opterećenje i stres	LoadRunner Professional, Apache JMeter	Simulacija virtualnih korisnika velikog volumena u odnosu na radna opterećenja produkcijske razine.
Usporedba podataka	Redgate SQL usporedba podataka, Apache DBUtils	Provjera da li dvije baze podataka sadrže identične podatke nakon migracije ili ETL-a.
Generiranje probnih podataka	Mockaroo, Datatect	Izrada realističnih testnih skupova podataka koji poštuju referencijalni integritet.
Upravljanje shemom	Liquibase, Flyway	Migracije kontrolirane verzijama i testiranje vraćanja prethodnih verzija u različitim okruženjima.
SQL editor / ad-hoc validacija	DBeaver, Azure Podatkovni studio, SSMS	Interaktivno kreiranje upita tijekom istraživačkog testiranja baze podataka.

Uparite barem jedan alat iz kategorije opterećenja s jednim iz kategorije jedinica kako biste pokrili rizik performansi i regresije.

Najčešći problemi koji se javljaju tijekom testiranja baze podataka

Izdanje	Preporučeno rješenje
Značajni režijski troškovi potrebni su za određivanje stanja transakcija baze podataka.	Unaprijed planirajte vrijeme i ovisnosti kako se tijekom izvršavanja ne bi pojavile dvosmislenosti oko stanja transakcije.
Novi testni podaci moraju se dizajnirati nakon čišćenja starih testnih podataka.	Održavajte dokumentiranu strategiju generiranja testnih podataka i postupak osvježavanja prije svakog ciklusa.
Za transformaciju SQL validatora tako da upiti odgovaraju potrebnim testnim slučajevima potreban je SQL generator.	Održavanje SQL-a tretirajte kao prvorazredni dio cjelokupnog testna strategija, a ne kao ad-hoc posao.
Gore navedeni preduvjeti mogu učiniti postavljanje skupim i dugotrajnim.	Uravnotežite dubinu testiranja s rasporedom slojevitim pokrivanjem: duboka automatizacija za područja visokog rizika, lagane provjere drugdje.

Mitovi i zablude o testiranju baza podataka

Mit	Stvarnost
Testiranje baze podataka zahtijeva duboko stručno znanje i previše je zamorno da bi se opravdalo.	Učinkovito testiranje baze podataka pruža dugoročnu funkcionalnu stabilnost. Trud se višestruko isplati smanjenjem broja odgovora na incidente.
Testiranje baze podataka stvara dodatno usko grlo u radu.	Rano otkriva skrivene nedostatke i poboljšava ukupnu kvalitetu aplikacije, uklanjajući uska grla umjesto da ih stvara.
Testiranje baze podataka usporava proces razvoja.	Ulaganje u testiranje baze podataka ubrzava razvoj sustava otkrivanjem nedostataka u shemi i integritetu prije nego što se kaskadno prošire.
Testiranje baze podataka je pretjerano skupo.	Baza podataka (i SQL) testiranje je dugoročno ulaganje u stabilnost aplikacije i zaštita od skupih kvarova u proizvodnji.

Najbolje prakse

• Validirajte sve podatke - metapodatke i funkcionalne podatke - u odnosu na specifikaciju zahtjeva, uključujući i njihovu mapuping Pravila.
• Revpogledajte svaki set podaci ispitivanja proizvedeno od strane ili s razvojnim timom prije nego što se na njega oslonite.
• Validirajte izlazne podatke koristeći i ručne i automatizirane postupke.
• Primijenite grafički prikaz uzroka i posljedice, particioniranje ekvivalencije i analizu graničnih vrijednosti pri generiranju uvjeta testnih podataka.
• Validirajte pravila referencijalnog integriteta u svim potrebnim tablicama baze podataka.
• Koristite namjerne zadane vrijednosti prilikom provjere konzistentnosti baze podataka i provjerite jesu li događaji zapisa zabilježeni za svaki potreban događaj prijave.
• Potvrdite da se planirani poslovi izvršavaju na vrijeme i daju očekivane rezultate.
• Izradite sigurnosnu kopiju baze podataka prema definiranom rasporedu i provjerite put vraćanja barem tromjesečno.

Vidi također — Pitanja i odgovori za intervju za testiranje baze podataka.

Pitanja i odgovori