Tietokannan (datan) testauksen opetusohjelma

Testaus- ja kehitystiimin jäsenet painottavat yleensä GUI:ta eniten, koska graafinen käyttöliittymä sattuu olemaan sovelluksen näkyvin osa. Tärkeää on kuitenkin myös vahvistaa tiedot, jotka ovat sovelluksen ydin, eli DATABASE.

Tarkastellaanpa pankkisovellusta, jossa käyttäjä tekee liiketoimia. Tietokantatestauksen tai DB-testauksen näkökulmasta seuraavat asiat ovat tärkeitä:

1. Sovellus tallentaa tapahtumatiedot sovellustietokantaan ja näyttää ne oikein käyttäjälle.
2. Mitään tietoa ei menetetä prosessissa.
3. Sovellus ei tallenna osittain suoritetun tai keskeytetyn toiminnon tietoja.
4. Kukaan luvaton henkilö ei saa päästä käsiksi käyttäjän tietoihin.

Kaikkien edellä mainittujen tavoitteiden varmistamiseksi meidän on käytettävä tietojen validointia tai tietojen testausta.

Erot käyttöliittymätestauksen ja datatestauksen välillä

Käyttöliittymän testaus	Tietokanta tai tietojen testaus
Tämäntyyppinen testaus tunnetaan myös nimellä graafinen käyttöliittymätestaus tai käyttöliittymätestaus.	Tämäntyyppinen testaus tunnetaan myös nimellä taustatestaus tai datatestaus.
Tämän tyyppinen testaus käsittelee pääasiassa kaikkia testattavia kohteita, jotka ovat avoimia käyttäjälle katselua ja vuorovaikutusta varten, kuten lomakkeet, esitys, kaaviot, valikot ja raportit jne. ( luotu VB:n, VB.netin, V:n kautta)C++, Delphi – käyttöliittymätyökalut)	Tämän tyyppinen testaus käsittelee pääasiassa kaikkia testattavia kohteita, jotka yleensä piilotetaan käyttäjältä katsojalta. Näitä ovat sisäiset prosessit ja tallennus, kuten Assembly, DBMS kuten Oracle, SQL Server, MYSQL jne.
Tämäntyyppinen testaus sisältää validoinnin tekstilaatikot valitse pudotusvalikosta kalentereita ja painikkeita Sivunavigointi kuvien näyttäminen Koko sovelluksen ulkoasu ja tuntuma	Tämäntyyppinen testaus sisältää validoinnin: skeema tietokantataulukot sarakkeet avaimet ja hakemistot tallennetut proseduurit laukaisevat tietokantapalvelimen tarkistukset tietojen kopioinnin validointi
Testaajan tulee tuntea perusteellisesti liiketoiminnan vaatimukset sekä kehitystyökalujen käyttö ja automaatiokehysten ja -työkalujen käyttö.	Voidakseen suorittaa taustatestauksen testaajalla on oltava vahva tietokantapalvelimen ja Structured Query Language -konseptien tausta.

Tietokantatestauksen tyypit

Tietokantatestauksen 3 tyyppiä ovat

1. Rakennetestaus
2. Toiminnallinen testaus
3. Ei-toiminnallinen testaus

Tässä tietokantatestauksen opetusohjelmassa tarkastelemme jokaista tyyppiä ja sen alatyyppejä yksitellen.

Mikä on Schema Testing?

Kaavojen testaus tietokantatestauksessa validoi erilaisia ​​tietokantaan liittyviä skeemamuotoja ja varmistaa, ovatko taulukoiden/näkymien/sarakkeiden kartoitusmuodot yhteensopivia käyttöliittymän kartoitusmuotojen kanssa. Kaavatestauksen päätarkoitus on varmistaa, että käyttöliittymän ja taustan välinen skeemakartoitus on samanlainen. Siksi sitä kutsutaan myös kartoitustestaukseksi.

Keskustellaan tärkeimmistä skeematestauksen tarkistuspisteistä.

1. Tietokantoihin liittyvien erilaisten skeemamuotojen validointi. Usein taulukon kartoitusmuoto ei ehkä ole yhteensopiva sovelluksen käyttöliittymätasolla olevan kartoitusmuodon kanssa.
2. Vahvistaminen on tarpeen kartoittamattomien taulukoiden/näkymien/sarakkeiden tapauksessa.
3. On myös tarkistettava, ovatko ympäristön heterogeeniset tietokannat yhdenmukaisia ​​yleisen sovelluskartoituksen kanssa.

Katsotaanpa myös joitain mielenkiintoisia tietokantatestaustyökaluja tietokantaskeemojen validoimiseksi.

• Ant:iin integroitu DBUnit soveltuu erittäin hyvin kartoitustestaukseen.
• SQL Serverin avulla testaajat voivat tarkistaa ja kysellä tietokannan skeemaa kirjoittamalla yksinkertaisia ​​kyselyitä eikä koodin kautta.

Jos kehittäjät esimerkiksi haluavat muuttaa taulukkorakennetta tai poistaa sen, testaaja haluaa varmistaa, että kaikki taulukkoa käyttävät tallennetut menettelyt ja näkymät ovat yhteensopivia tietyn muutoksen kanssa. Toinen esimerkki voisi olla, että jos testaajat haluavat tarkistaa skeeman muutokset kahden tietokannan välillä, he voivat tehdä sen yksinkertaisilla kyselyillä.

Tietokantataulukko, saraketestaus

Tarkastellaan erilaisia ​​tietokanta- ja saraketestauksen tarkistuksia.

1. Onko taustasovelluksen tietokantakenttien ja sarakkeiden kartoitus yhteensopiva käyttöliittymän määritysten kanssa?
2. Tietokannan kenttien ja sarakkeiden pituuden ja nimeämiskäytännön validointi vaatimusten mukaisesti.
3. Käyttämättömien/kartoittamattomien tietokantataulukoiden/sarakkeiden olemassaolon tarkistus.
4. Yhteensopivuuden vahvistaminen

• tietotyyppi
• kenttien pituudet

taustatietokannan sarakkeiden sarakkeiden kanssa sovelluksen etupäässä olevien sarakkeiden kanssa.

5. Antavatko tietokantakentät käyttäjälle mahdollisuuden antaa haluttuja käyttäjäsyötteitä liiketoimintavaatimusten määrittelyasiakirjojen edellyttämällä tavalla.

Avainten ja indeksien testaus

Tärkeitä avaimien ja hakemistojen tarkistuksia –

1. Tarkista onko vaadittu

• Pääavain
• viiteavain

vaadituille taulukoille on luotu rajoitukset.

2. Tarkista, ovatko vieraiden avainten viittaukset voimassa.
3. Tarkista, ovatko ensisijaisen avaimen ja vastaavien vieraiden avainten tietotyyppi samat kahdessa taulukossa.
4. Tarkista, onko kaikkien avainten ja indeksien kohdalla noudatettu vaadittuja nimeämiskäytäntöjä.
5. Tarkista vaadittujen kenttien ja hakemistojen koko ja pituus.
6. Olipa vaadittu

• Clustered indeksit
• Ei Clustered indeksit

on luotu vaadituille taulukoille liiketoiminnan vaatimusten mukaisesti.

Tallennettujen menetelmien testaus

Tärkeitä testejä tallennettujen menettelyjen tarkistamiseksi ovat:

1. Hyväksyikö kehitystiimi vaaditut A) koodausstandardit ja B) poikkeus- ja virhekäsittely. Kaikille tallennetuille menettelyille kaikille testattavan sovelluksen moduuleille.
2. Kattiko kehitystiimi kaikki ehdot/silmukat soveltamalla vaadittuja syöttötietoja testattavaan sovellukseen?
3. Käyttikö kehitystiimi TRIM-toimintoa oikein aina, kun tietoja haettiin vaadituista tietokannan taulukoista?
4. Saako Tallennetun Proseduurin manuaalinen suorittaminen loppukäyttäjälle vaaditun tuloksen?
5. Varmistaako tallennetun prosessin manuaalinen suorittaminen, että taulukon kentät päivitetään testattavan sovelluksen edellyttämällä tavalla?
6. Mahdollistaako tallennettujen toimintojen suorittaminen vaadittujen laukaisujen implisiittisen kutsumisen?
7. Käyttämättömien tallennettujen toimenpiteiden olemassaolon validointi.
8. Allow Null -ehdon validointi, joka voidaan tehdä tietokantatasolla.
9. Varmennus siitä, että kaikki tallennetut proseduurit ja toiminnot on suoritettu onnistuneesti, kun testattava tietokanta on tyhjä.
10. Tallennettujen menettelymoduulien kokonaisintegraation validointi testattavan sovelluksen vaatimusten mukaisesti.

Joitakin hyödyllisiä tietokannan testaustyökaluja tallennettujen menettelyjen testaamiseen ovat LINQ, SP Test Tool jne.

Liipaisimen testaus

1. Onko vaadittuja koodauskäytäntöjä noudatettu Triggerien koodausvaiheessa?
2. Tarkista, ovatko vastaaville DML-tapahtumille suoritetut triggerit täyttäneet vaaditut ehdot.
3. Päivittääkö triggeri tiedot oikein, kun ne on suoritettu?
4. Vaaditun päivityksen/lisää/poistamisen vahvistaminen käynnistää toiminnallisuuden testattavan sovelluksen alueella.

Tietokantapalvelimen validoinnit

1. Tarkista tietokantapalvelimen kokoonpanot liiketoiminnan vaatimusten mukaisesti.
2. Tarkista vaaditun käyttäjän valtuutus suorittaa vain sovelluksen edellyttämiä toimintoja.
3. Tarkista, että tietokantapalvelin pystyy vastaamaan liiketoimintavaatimusmäärityksissä määritetyn suurimman sallitun määrän käyttäjätapahtumia tarpeisiin.

Toiminnallisen tietokannan testaus

Toiminnallisen tietokannan testaus on eräänlainen tietokantatestaus, jota käytetään tietokannan toiminnallisten vaatimusten vahvistamiseen loppukäyttäjän näkökulmasta. Toiminnallisen tietokantatestauksen päätavoitteena on testata, toimivatko loppukäyttäjien tietokantaan liittyvät tapahtumat ja toiminnot odotetusti vai eivät.

Seuraavassa on perusehdot, joita on noudatettava tietokannan validoinnissa.

• Onko kenttä pakollinen, mutta sallii kentässä NULL-arvot?
• Onko kunkin kentän pituus riittävän suuri?
• Onko kaikilla samankaltaisilla kentillä samat nimet eri taulukoissa?
• Onko tietokannassa laskettuja kenttiä?

Tämä prosessi on kenttäkartoitusten validointi loppukäyttäjän näkökulmasta. Tässä skenaariossa testaaja suorittaisi toiminnon tietokantatasolla ja navigoisi sitten asiaankuuluvaan käyttöliittymäkohteeseen tarkkailemaan ja vahvistamaan, onko asianmukaiset kenttätarkistukset suoritettu vai ei.

Päinvastoin ehto, jossa testaaja suorittaa ensin toiminnon käyttöliittymässä ja sen jälkeen validoidaan takapäästä, tulee myös tehdä.

Tietojen eheyden ja johdonmukaisuuden tarkistaminen

Seuraavat tarkastukset ovat tärkeitä

1. Onko data loogisesti hyvin järjestetty?
2. Ovatko taulukoihin tallennetut tiedot oikein ja liiketoiminnan vaatimusten mukaisia?
3. Onko testattavassa sovelluksessa tarpeettomia tietoja?
4. Onko tiedot tallennettu vaatimusten mukaisesti käyttöliittymästä päivitettyjen tietojen osalta?
5. Suoritettiinko TRIM-toiminnot tiedoille ennen tietojen lisäämistä testattavaan tietokantaan?
6. Onko tapahtumat suoritettu liiketoimintavaatimusmäärittelyjen mukaisesti ja ovatko tulokset oikein vai eivät?
7. Onko tiedot siirretty oikein, jos tapahtuma on suoritettu onnistuneesti?
8. Onko tiedot rullattu onnistuneesti, jos loppukäyttäjä ei ole suorittanut tapahtumaa onnistuneesti?
9. Onko tietoja rullattu, jos tapahtumaa ei ole suoritettu onnistuneesti ja kyseiseen tapahtumaan on liittynyt useita heterogeenisiä tietokantoja?
10. Onko kaikki tapahtumat toteutettu järjestelmäliiketoiminnan vaatimusten mukaisilla suunnittelumenettelyillä?

Kirjautuminen ja käyttäjän suojaus

Sisäänkirjautumisen ja käyttäjän suojaustunnusten tarkistuksissa on otettava huomioon seuraavat asiat.

1. Estääkö sovellus käyttäjää jatkamasta sovelluksessa, jos a

• virheellinen käyttäjätunnus, mutta kelvollinen salasana
• kelvollinen käyttäjätunnus mutta virheellinen salasana.
• virheellinen käyttäjätunnus ja salasana.

2. Saako käyttäjä suorittaa vain ne tietyt toiminnot, jotka liiketoiminnan vaatimukset määrittelevät?
3. Onko tiedot suojattu luvattomalta käytöltä?
4. Onko olemassa erilaisia ​​käyttäjärooleja, jotka on luotu eri käyttöoikeuksilla?
5. Onko kaikilla käyttäjillä vaaditut käyttöoikeustasot määritellyssä tietokannassa liiketoiminnan eritelmien edellyttämällä tavalla?
6. Tarkista, että arkaluontoiset tiedot, kuten salasanat, luottokorttien numerot, on salattu eikä niitä tallenneta pelkkänä tekstinä tietokantaan. On hyvä käytäntö varmistaa, että kaikilla tileillä on salasanat, jotka ovat monimutkaisia ​​ja joita ei ole helppo arvata.

Ei-toiminnallinen testaus

Ei-toiminnallinen testaus tietokantatestauksen yhteydessä voidaan luokitella eri luokkiin liiketoiminnan vaatimusten mukaisesti. Nämä voivat olla kuormitustestausta, stressitestausta, Suojaustestaus, Käytettävyystestausja Yhteensopivuuden testaus, ja niin edelleen. Kuormitustestaus sekä stressitestaus, jotka voidaan ryhmitellä Performance Testingin skaalaan, palvelee kahta erityistä tarkoitusta, kun kyse on ei-toiminnallisen testauksen roolista.

Riskien kvantifiointi– Riskin kvantifiointi auttaa sidosryhmiä varmistamaan järjestelmän eri vasteaikavaatimukset vaaditulla kuormitustasolla. Tämä on minkä tahansa alkuperäinen tarkoitus laadunvarmistus tehtävä. Meidän on huomioitava, että kuormitustestaus ei vähennä riskiä suoraan, mutta riskien tunnistamis- ja kvantifiointiprosessien kautta tarjoaa korjaavia mahdollisuuksia ja sysäyksen riskiä vähentävään korjaamiseen.

Järjestelmän vähimmäisvaatimus– Järjestelmän vähimmäiskokoonpano, jonka avulla järjestelmä voi täyttää sidosryhmien virallisesti ilmoittamat suorituskykyodotukset. Jotta ylimääräiset laitteistot, ohjelmistot ja niihin liittyvät omistuskustannukset voidaan minimoida. Tämä erityinen vaatimus voidaan luokitella yleiseksi liiketoiminnan optimointivaatimukseksi.

Kuormitustesti

Jokaisen kuormitustestin tarkoitus on ymmärrettävä selvästi ja dokumentoitava. Seuraavat kokoonpanotyypit ovat pakollisia kuormitustestaus.

1. Useimmin käytetyt käyttäjätapahtumat voivat vaikuttaa kaikkien muiden tapahtumien suorituskykyyn, jos ne eivät ole tehokkaita.
2. Ainakin yksi ei-muokkaus käyttäjätapahtuma tulisi sisällyttää lopulliseen testisarjaan, jotta tällaisten tapahtumien suoritus voidaan erottaa muista monimutkaisemmista tapahtumista.
3. Tärkeimmät tapahtumat, jotka helpottavat järjestelmän ydintavoitteiden saavuttamista, tulisi ottaa mukaan, sillä epäonnistumisella näiden tapahtumien kuormituksen alla on määritelmän mukaan suurin vaikutus.
4. Vähintään yksi muokattava tapahtuma tulee sisällyttää niin suorituskyky Tällaiset liiketoimet voidaan erottaa muista liiketoimista.
5. Optimaalinen vasteaika suurella määrällä virtuaalisia käyttäjiä kaikkiin mahdollisiin tarpeisiin.
6. Tehokkaat ajat eri tietueiden hakemiseen.

Tärkeitä kuormitustestaustyökaluja ovat LoadRunner Professional, voita juoksija ja JMeter.

Tärkeitä stressitestaustyökaluja ovat LoadRunner Professional ja JMeter.

Yleisimmät ongelmat tietokannan testauksen aikana

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

Ratkaisu: Kokonaisprosessin suunnittelu ja ajoitus tulee järjestää siten, ettei aika- ja kustannusperusteisia ongelmia esiinny.

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

Ratkaisu: Ennakkosuunnitelman ja menetelmän testitietojen luomista varten tulisi olla käsillä.

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.

Ratkaisu: SQL-kyselyiden ylläpito ja niiden jatkuva päivitys on merkittävä osa yleistä testausprosessia, jonka tulisi olla osa yleistä testausprosessia. testistrategia.

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

Ratkaisu: Laadun ja projektin kokonaisaikataulun keston välillä tulee olla hyvä tasapaino.

Tietokantatestaukseen liittyvät myytit tai väärinkäsitykset

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

todellisuus: Tehokas ja tehokas tietokantatestaus ohjelmistotestauksessa tarjoaa pitkän aikavälin toiminnallista vakautta koko sovellukselle, joten sen takana on tehtävä kovaa työtä.

Database testing adds extra work bottleneck

todellisuus: Päinvastoin, tietokantatestaus lisää lisäarvoa kokonaistyöhön, koska se löytää piiloongelmia ja auttaa näin ennakoivasti parantamaan yleistä sovellusta.

Database testing slows down the overall development process

todellisuus: Merkittävä määrä tietokantatestausta auttaa parantamaan tietokantasovelluksen laatua yleisesti.

Database testing could be excessively costly

todellisuus: Kaikki tietokantatestaukseen liittyvät kulut ovat pitkän aikavälin investointi, joka johtaa sovelluksen pitkäaikaiseen vakauteen ja kestävyyteen. Näin ollen tietokantatestauksesta tai SQL Testaus on tarpeen.

Esimerkkikäytäntöjä

• Kaikki tiedot, mukaan lukien metatiedot sekä toiminnalliset tiedot, on validoitava vaatimusmäärittelydokumenttien kartoituksen mukaisesti.
• Vahvistus testitiedot joka on luotu / kuultuaan kehitystiimiä, on validoitava.
• Tulostiedon validointi käyttämällä sekä manuaalisia että automaatiomenetelmiä.
• Erilaisten tekniikoiden, kuten syy-seurausgrafiikkatekniikan, ekvivalenssiositustekniikan ja raja-arvoanalyysitekniikan, käyttöönotto vaadittujen testidataolosuhteiden luomiseksi.
• Myös vaadittujen tietokantataulukoiden viittauksen eheyden validointisäännöt on validoitava.
• Taulukon oletusarvojen valinta tietokannan johdonmukaisuuden validointia varten on erittäin tärkeä käsite Onko lokitapahtumat lisätty onnistuneesti tietokantaan kaikille vaadituille kirjautumistapahtumille
• Suoritetaanko ajoitetut työt ajallaan?
• Varmuuskopioi tietokannasta ajoissa.

Tarkista myös- Tietokantatestauksen haastattelukysymyksiä ja vastauksia