Vodič za testiranje baze podataka (podataka).

GUI obično najveći naglasak pridaju članovi testnog i razvojnog tima budući da je grafičko korisničko sučelje najvidljiviji dio aplikacije. Međutim, ono što je također važno je potvrditi informacije koje su srce aplikacije, poznate i kao BAZA PODATAKA.

Razmotrimo bankovnu aplikaciju u kojoj korisnik vrši transakcije. Sa sljedećeg gledišta testiranja baze podataka ili testiranja baze podataka, stvari su važne:

1. Aplikacija pohranjuje informacije o transakcijama u bazi podataka aplikacije i ispravno ih prikazuje korisniku.
2. U procesu se ne gube nikakve informacije.
3. Aplikacija ne sprema podatke o djelomično izvedenim ili prekinutim operacijama.
4. Neovlaštenim osobama nije dopušten pristup podacima o korisniku.

Kako bismo osigurali sve gore navedene ciljeve, moramo koristiti provjeru valjanosti podataka ili testiranje podataka.

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

Testiranje korisničkog sučelja	Baza podataka ili testiranje podataka
Ova vrsta testiranja također je poznata kao testiranje grafičkog korisničkog sučelja ili testiranje frontalnog dijela.	Ova vrsta testiranja također je poznata kao testiranje pozadine ili testiranje podataka.
Ova vrsta testiranja uglavnom se bavi svim testiranim stavkama koje su korisniku otvorene za gledanje i interakciju kao što su obrasci, prezentacije, grafikoni, izbornici i izvješća itd. (stvoreni putem VB, VB.net, VC++, Delphi – Front-end alati)	Ova vrsta testiranja uglavnom se bavi svim testiranim stavkama koje su općenito skrivene od korisnika za gledanje. To uključuje interne procese i pohranu poput Assembly, poput DBMS-a Oracle, SQL Server, MYSQL itd.
Ova vrsta testiranja uključuje potvrđivanje okviri za tekst odaberite padajuće izbornike kalendari i gumbi Navigacija po stranici prikaz slika Izgled i dojam cjelokupne aplikacije	Ova vrsta testiranja uključuje potvrđivanje: shema tablice baze podataka stupovi ključeve i indekse pohranjene procedure okidači validacije poslužitelja baze podataka potvrđivanje dupliciranja podataka
Ispitivač mora dobro poznavati poslovne zahtjeve, kao i korištenje razvojnih alata i korištenje okvira i alata za automatizaciju.	Da bi mogao izvršiti pozadinsko testiranje, ispitivač mora imati dobro iskustvo u poslužitelju baze podataka i konceptima Structured Query Language.

Vrste testiranja baze podataka

Postoje 3 vrste testiranja baze podataka

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

U ovom vodiču za testiranje baze podataka, pogledat ćemo svaku vrstu i njene podvrste jednu po jednu.

Što je testiranje sheme?

Ispitivanje sheme u testiranju baze podataka potvrđuje različite formate sheme povezane s bazom podataka i provjerava jesu li formati mapiranja tablica/prikaza/stupaca kompatibilni s formatima mapiranja korisničkog sučelja. Glavna svrha testiranja sheme je osigurati da je preslikavanje sheme između front-end-a i back-end-a slično. Stoga se također naziva testiranjem mapiranja.

Raspravljajmo o najvažnijim kontrolnim točkama za testiranje sheme.

1. Validacija različitih formata shema povezanih s bazama podataka. Mnogo puta format mapiranja tablice možda nije kompatibilan s formatom mapiranja prisutnim na razini korisničkog sučelja aplikacije.
2. Postoji potreba za provjerom u slučaju nemapiranih tablica/prikaza/stupaca.
3. Također postoji potreba za provjerom jesu li heterogene baze podataka u okruženju konzistentne s ukupnim preslikavanjem aplikacije.

Pogledajmo također neke od zanimljivih alata za testiranje baze podataka za provjeru valjanosti shema baze podataka.

• DBUnit koji je integriran s Antom vrlo je pogodan za testiranje mapiranja.
• SQL Server omogućuje testerima da mogu provjeriti i postaviti upite o shemi baze podataka pisanjem jednostavnih upita, a ne kroz kod.

Na primjer, ako programeri žele promijeniti strukturu tablice ili je izbrisati, ispitivač bi želio osigurati da su sve pohranjene procedure i pogledi koji koriste tu tablicu kompatibilni s određenom promjenom. Drugi primjer bi mogao biti da ako testeri žele provjeriti promjene sheme između 2 baze podataka, to mogu učiniti pomoću jednostavnih upita.

Tablica baze podataka, testiranje stupaca

Pogledajmo različite provjere za testiranje baza podataka i stupaca.

1. Je li preslikavanje polja i stupaca baze podataka u pozadini kompatibilno s tim preslikavanjima u prednjem dijelu?
2. Provjera valjanosti duljine i pravila imenovanja polja i stupaca baze podataka prema zahtjevima.
3. Provjera prisutnosti neiskorištenih/nemapiranih tablica/stupaca baze podataka.
4. Validacija kompatibilnosti

• tip podataka
• duljine polja

stupaca pozadinske baze podataka s onima prisutnima na prednjem dijelu aplikacije.

5. Dopuštaju li polja baze podataka korisniku da pruži željene korisničke unose kako zahtijevaju dokumenti specifikacije poslovnih zahtjeva.

Testiranje ključeva i indeksa

Važne provjere za ključeve i indekse –

1. Provjerite je li potrebno

• Glavni ključ
• Strani kljuc

stvorena su ograničenja na potrebnim tablicama.

2. Provjerite jesu li reference za strane ključeve valjane.
3. Provjerite jesu li tip podataka primarnog ključa i odgovarajućih stranih ključeva isti u dvije tablice.
4. Provjerite jesu li ispoštovane potrebne konvencije imenovanja za sve ključeve i indekse.
5. Provjerite veličinu i duljinu potrebnih polja i indeksa.
6. Bilo da je potrebno

• Clustered indeksi
• Ne Clustered indeksi

su kreirani na potrebnim tablicama kako je navedeno u poslovnim zahtjevima.

Testiranje pohranjenih procedura

Važni testovi za provjeru pohranjenih procedura su:

1. Je li razvojni tim usvojio potrebne, A) standardne konvencije kodiranja i B) rukovanje iznimkama i pogreškama. Za sve pohranjene procedure za sve module za aplikaciju koja se testira.
2. Je li razvojni tim pokrio sve uvjete/petlje primjenom potrebnih ulaznih podataka na aplikaciju koja se testira?
3. Je li razvojni tim ispravno primijenio operaciju TRIM kad god se podaci dohvate iz potrebnih tablica u bazi podataka?
4. Daje li ručno izvršavanje pohranjene procedure krajnjem korisniku traženi rezultat?
5. Osigurava li ručno izvršavanje pohranjene procedure da se polja tablice ažuriraju prema zahtjevima aplikacije koja se testira?
6. Omogućuje li izvođenje pohranjenih procedura implicitno pozivanje potrebnih okidača?
7. Validacija prisutnosti svih neiskorištenih pohranjenih procedura.
8. Provjera valjanosti uvjeta Allow Null koja se može obaviti na razini baze podataka.
9. Provjera valjanosti činjenice da su sve pohranjene procedure i funkcije uspješno izvršene kada je baza podataka koja se testira prazna.
10. Validacija cjelokupne integracije modula pohranjene procedure prema zahtjevima aplikacije koja se testira.

Neki od korisnih alata za testiranje baze podataka za testiranje pohranjenih procedura su LINQ, SP Test alat itd.

Testiranje okidača

1. Jesu li tijekom faze kodiranja okidača poštovane potrebne konvencije kodiranja?
2. Provjerite jesu li okidači izvršeni za odgovarajuće DML transakcije ispunili potrebne uvjete.
3. Ažurira li okidač ispravno podatke nakon što se izvrše?
4. Validacija potrebnog ažuriranja/umetanja/brisanja pokreće funkcionalnost u području aplikacije koja se testira.

Validacije poslužitelja baze podataka

1. Provjerite konfiguracije poslužitelja baze podataka prema poslovnim zahtjevima.
2. Provjerite autorizaciju potrebnog korisnika za obavljanje samo onih razina radnji koje zahtijeva aplikacija.
3. Provjerite može li poslužitelj baze podataka zadovoljiti potrebe maksimalnog dopuštenog broja korisničkih transakcija kako je određeno specifikacijama poslovnih zahtjeva.

Funkcionalno testiranje baze podataka

Funkcionalno testiranje baze podataka je vrsta testiranja baze podataka koja se koristi za provjeru funkcionalnih zahtjeva baze podataka iz perspektive krajnjeg korisnika. Glavni cilj funkcionalnog testiranja baze podataka je provjeriti rade li transakcije i operacije koje izvode krajnji korisnici, a koje su povezane s bazom podataka, prema očekivanjima ili ne.

Slijede osnovni uvjeti koje je potrebno poštovati za provjeru valjanosti baze podataka.

• Je li polje obavezno dok dopušta NULL vrijednosti u tom polju?
• Je li duljina svakog polja dovoljne veličine?
• Imaju li sva slična polja ista imena u tablicama?
• Postoje li izračunata polja prisutna u bazi podataka?

Ovaj određeni proces je provjera valjanosti preslikavanja polja sa stajališta krajnjeg korisnika. U ovom konkretnom scenariju, ispitivač bi izvršio operaciju na razini baze podataka, a zatim bi otišao do relevantne stavke korisničkog sučelja kako bi promatrao i potvrdio jesu li pravilne provjere polja provedene ili ne.

Trebao bi se izvršiti i obrnuti uvjet pri kojem prvu operaciju provodi tester na korisničkom sučelju, a zatim se ista potvrđuje sa stražnje strane.

Provjera integriteta i dosljednosti podataka

Sljedeće provjere su važne

1. Jesu li podaci logički dobro organizirani?
2. Jesu li podaci pohranjeni u tablicama točni i u skladu s poslovnim zahtjevima?
3. Ima li nepotrebnih podataka u aplikaciji koja se testira?
4. Jesu li podaci pohranjeni prema zahtjevu s obzirom na podatke koji su ažurirani s korisničkog sučelja?
5. Jesu li TRIM operacije izvedene na podacima prije umetanja podataka u bazu podataka koja se testira?
6. Jesu li transakcije izvršene prema specifikacijama poslovnih zahtjeva i jesu li rezultati točni ili ne?
7. Jesu li podaci ispravno predani ako je transakcija uspješno izvršena?
8. Jesu li podaci uspješno vraćeni ako krajnji korisnik nije uspješno izvršio transakciju?
9. Jesu li podaci vraćeni ako transakcija nije uspješno izvršena i više je heterogenih baza podataka uključeno u predmetnu transakciju?
10. Jesu li sve transakcije izvršene korištenjem potrebnih postupaka projektiranja kako je navedeno u poslovnim zahtjevima sustava?

Prijava i sigurnost korisnika

Provjere vjerodajnica za prijavu i sigurnost korisnika moraju uzeti u obzir sljedeće stvari.

1. Sprječava li aplikacija korisnika da nastavi dalje u aplikaciji u slučaju a

• nevažeće korisničko ime, ali važeća lozinka
• važeće korisničko ime, ali nevažeća lozinka.
• nevažeće korisničko ime i nevažeća lozinka.

2. Smije li korisnik obavljati samo one specifične operacije koje su specificirane poslovnim zahtjevima?
3. Jesu li podaci zaštićeni od neovlaštenog pristupa?
4. Postoje li različite korisničke uloge stvorene s različitim dopuštenjima?
5. Imaju li svi korisnici tražene razine pristupa navedenoj bazi podataka prema poslovnim specifikacijama?
6. Provjerite jesu li osjetljivi podaci poput lozinki, brojeva kreditnih kartica šifrirani i nisu pohranjeni kao običan tekst u bazi podataka. Dobra je praksa osigurati da svi računi imaju lozinke koje su složene i koje nije lako pogoditi.

Nefunkcionalno testiranje

Nefunkcionalno testiranje u kontekstu testiranja baze podataka može se kategorizirati u različite kategorije prema zahtjevima poslovanja. To mogu biti testiranje opterećenja, testiranje stresa, Ispitivanje sigurnosti, Ispitivanje upotrebljivostii Ispitivanje kompatibilnosti, i tako dalje. Testiranje opterećenja, kao i testiranje stresa, koje se može grupirati pod rasponom testiranja performansi, ima dvije specifične svrhe kada se radi o ulozi nefunkcionalnog testiranja.

Kvantifikacija rizika– Kvantifikacija rizika pomaže dionicima da utvrde različite zahtjeve vremena odziva sustava pod potrebnim razinama opterećenja. Ovo je izvorna namjera bilo kojeg osiguravanje kvalitete zadatak. Moramo napomenuti da testiranje opterećenja ne ublažava rizik izravno, ali kroz procese identifikacije rizika i kvantifikacije rizika, predstavlja korektivne mogućnosti i poticaj za sanaciju koja će ublažiti rizik.

Minimalni zahtjev za opremu sustava– Minimalna konfiguracija sustava koja će omogućiti sustavu da ispuni formalno navedena očekivanja dionika. Tako da se dodatni hardver, softver i povezani troškovi vlasništva mogu svesti na minimum. Ovaj posebni zahtjev može se kategorizirati kao ukupni zahtjev za optimizaciju poslovanja.

Testiranje opterećenja

Svrha svakog ispitivanja opterećenja treba biti jasno shvaćena i dokumentirana. Sljedeće vrste konfiguracija su neophodne za ispitivanje opterećenja.

1. Najčešće korištene korisničke transakcije mogu utjecati na izvedbu svih ostalih transakcija ako nisu učinkovite.
2. Najmanje jedna korisnička transakcija bez uređivanja trebala bi biti uključena u konačni skup testova, tako da se izvedba takvih transakcija može razlikovati od drugih složenijih transakcija.
3. Trebalo bi uključiti važnije transakcije koje olakšavaju temeljne ciljeve sustava, budući da neuspjeh pod opterećenjem tih transakcija ima, po definiciji, najveći utjecaj.
4. Mora biti uključena barem jedna transakcija koja se može uređivati predstava takvih transakcija može se razlikovati od drugih transakcija.
5. Optimalno vrijeme odziva pod velikim brojem virtualnih korisnika za sve potencijalne zahtjeve.
6. Efektivna vremena za dohvaćanje raznih zapisa.

Važni alati za testiranje opterećenja su LoadRunner Professional, pobijedi trkač i JMeter.

Važni alati za testiranje otpornosti na stres su LoadRunner Professional i JMeter.

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

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

Rješenje: Sveukupno planiranje procesa i vremenski raspored treba organizirati tako da se ne pojave problemi koji se temelje na vremenu i troškovima.

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

Rješenje: Prethodni plan i metodologija za generiranje testnih podataka trebali bi biti pri ruci.

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.

Rješenje: Održavanje SQL upita i njihovo kontinuirano ažuriranje značajan je dio ukupnog procesa testiranja koji bi trebao biti dio cjelokupnog testna strategija.

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

Rješenje: Mora postojati fina ravnoteža između kvalitete i ukupnog trajanja projekta.

Mitovi ili zablude u vezi s testiranjem baze podataka

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

Stvarnost: Učinkovito i djelotvorno testiranje baze podataka u testiranju softvera pruža dugoročnu funkcionalnu stabilnost cjelokupnoj aplikaciji, stoga je potrebno uložiti naporan rad iza toga.

Database testing adds extra work bottleneck

Stvarnost: Naprotiv, testiranje baze podataka dodaje više vrijednosti cjelokupnom radu pronalaženjem skrivenih problema i time proaktivno pomaže u poboljšanju ukupne aplikacije.

Database testing slows down the overall development process

Stvarnost: Značajna količina testiranja baze podataka pomaže u ukupnom poboljšanju kvalitete za aplikaciju baze podataka.

Database testing could be excessively costly

Stvarnost: Svaki izdatak za testiranje baze podataka je dugoročna investicija koja vodi dugoročnoj stabilnosti i robusnosti aplikacije. Stoga izdaci za testiranje baze podataka ili SQL Testiranje je neophodno.

Najbolje prakse

• Svi podaci, uključujući metapodatke, kao i funkcionalne podatke moraju biti potvrđeni u skladu s njihovim preslikavanjem dokumentima specifikacije zahtjeva.
• Provjera podaci ispitivanja koji je kreirao/u dogovoru s razvojnim timom treba potvrditi.
• Validacija izlaznih podataka korištenjem ručnih i automatiziranih postupaka.
• Primjena različitih tehnika kao što je tehnika crtanja grafikona uzročno-posljedičnih učinaka, tehnika dijeljenja ekvivalencije i tehnika analize graničnih vrijednosti za generiranje potrebnih uvjeta testnih podataka.
• Valjanost pravila referentnog integriteta za potrebne tablice baze podataka također treba potvrditi.
• Odabir zadanih vrijednosti tablice za provjeru dosljednosti baze podataka vrlo je važan koncept Jesu li događaji dnevnika uspješno dodani u bazu podataka za sve potrebne događaje prijave
• Izvršavaju li se planirani poslovi na vrijeme?
• Pravovremeno napravite sigurnosnu kopiju baze podataka.

Također provjerite- Pitanja i odgovori za intervju za testiranje baze podataka