Databasetesting består av svartboks-testing, hvitboks-testing og ACID (atomicitet, konsistens, isolasjon og varighet). I denne veiledningen får du definisjoner, fremgangsmåter og eksempler.
Hva er databasetesting?
Databasetesting, backend-testing eller datatesting skiller seg fra motstykket som gjelder brukergrensesnittet, ved at den ikke er opptatt av systemprogramvarens visuelle grensesnitt i det hele tatt. Hovedfokuset er å kontrollere at alle interne prosesser kjører som de skal, og at de kan hente data raskt, nøyaktig og sikkert.
Databasetesting tester databaseskjemaet, tabellene og utløserne i databasen. Databasen utsettes for belastning, og testingen kan omfatte kjøring av komplekse spørringer for å teste funksjonaliteten og responsiviteten grundig. Den tester også databaseadministrasjonssystemer (DBMS) som Oracle og SQL Server.
Relatert lesing: DE POSITIVE RESULTATENE AV NEGATIV TESTING
Hva er et databaseskjema?
Et databaseskjema er en logisk struktur som definerer organiseringen av og forholdet mellom data i en database. Det beskriver hvordan data lagres, åpnes og manipuleres i et DBMS. Skjemaet beskriver datatypene, begrensningene og forholdene mellom databaseentiteter, for eksempel tabeller, visninger, indekser og utløsere.
Databaseskjemaet er avgjørende for å sikre dataintegriteten og datakonsistensen i en database. Det gir utviklere og databaseadministratorer et rammeverk for å organisere og strukturere data på en meningsfull måte. Det bidrar også til å sikre at dataene som lagres i databasen, oppfyller bestemte krav, for eksempel datavalidering, datasikkerhet og datatilgjengelighet. Organisasjoner kan bruke et databaseskjema for å sikre organisering og optimalisering av databasene sine, slik at data kan håndteres effektivt, driften forbedres og beslutningstakingen styrkes.
Hvorfor er databasetesting viktig?
Databasetesting er viktig fordi
- Noen feil kan bare oppdages gjennom databasetesting
- Enkelte bruksforhold kan bare testes i databasen
- Databasetesting forbedrer stabiliteten og sikkerheten
- Databasetesting sikrer konsistens
Eksempel på databasefunksjon
Se for deg at du åpner en nettbankapp på telefonen (eller åpne faktisk nettbankappen på telefonen). Flytt nå en liten sum penger fra brukskontoen til sparekontoen. Når du er ferdig, kan du tenke på alt som måtte skje i bakgrunnen i løpet av disse få sekundene.
- Appen sendte transaksjonsinformasjonen til databasen.
- Ingen av opplysningene dine (det vil si PENGENE) gikk tapt underveis.
- Appen krasjet ikke eller mislyktes i å fullføre overføringen.
- Transaksjonen ble gjennomført på en sikker måte.
- Pengene dine ligger nå trygt på sparekontoen (gratulerer!)
Alle disse funksjonene skjer i databasen. Databasetestingsprosessen er viktig fordi systemet stopper helt opp hvis et databasesystem svikter alvorlig. Ingen informasjon kan sendes, hentes, overføres eller sikres. Programmet kan se ut til å fungere på overflaten (du kan navigere mellom vinduer og gjøre deg klar til å gjennomføre transaksjoner), men ingenting med reell betydning vil skje.
Alt ser fint ut på utsiden, men internt er det en katastrofe.
Databasetesting sørger for at det ikke skjer noen katastrofe. Ingen brann, ingen stans og ingen manglende penger. Det er i alles interesse at databasetesting gjennomføres. Derfor har jeg skrevet en omfattende veiledning som skal hjelpe deg med å føle deg trygg på at alt er grundig testet når du er ferdig.
Prinsipper for databasetesting
Ordet «prinsipper» høres kanskje mer ut som hvorfor enn hvordan. Stol på meg, dette er to viktige og praktiske konsepter.
- ACID-egenskaper
- Atomicitet
- Konsistens
- Isolasjon
- Varighet
- Dataintegritet
Hva er ACID-egenskaper?
Dette er den sikreste formen for syre du noen gang kommer til å bruke. Ingen hansker er nødvendige. ACID-egenskapene står for Atomicitet, Consistens, Isolasjon og Durability. Hver eneste transaksjon i databasetesting må oppfylle disse prinsippene.
En transaksjon er en gruppe oppgaver. Selv en enkel transaksjon fra virkeligheten, som bankoverføringen jeg nevnte tidligere, vil innebære flere underordnede oppgaver. ACID-egenskapene skal bekrefte at hver transaksjon fullføres nøyaktig, fullstendig og med integritet.
Have an account? Log In
ACID-egenskaper
- Atomisitet sier at hver transaksjon må behandles som en atomisk enhet. Uten molekylære termer betyr det at hver transaksjon må fullføres i sin helhet, ellers mislykkes den. Ved å behandle hver transaksjon på denne måten unngår man den rotete situasjonen der en pengeoverføring bare blir delvis fullført. Det høres stressende ut, ikke sant? Med atomisitet mislykkes hele transaksjonen hvis noe går galt når transaksjonen er halvveis fullført. Pengene tilbake. Ingen stress.
- Konsistens krever at databasen forblir konsistent etter en transaksjon. Ingen transaksjon kan påvirke andre data i databasen negativt. Når du setter inn penger på bankkontoen din, blir det ikke trukket penger fra andres konto.
- Isolasjon forhindrer at datastrømmer krysser hverandre. Det sikrer at hver transaksjon behandles som om den var den eneste transaksjonen som foregår i databasen, når flere transaksjoner skjer samtidig. Ingen får informasjonen sin blandet sammen med andres informasjon.
- Varighet krever at databasen er tilstrekkelig robust til å beholde alle de nyeste transaksjonene, selv om det oppstår en systemfeil. Også her finnes det praktiske grunner til å kreve slik varighet fra en database. Hvis du foretar en pengeoverføring og databasen går ned ti minutter senere, hvordan skulle du vite at du må foreta overføringen på nytt? Slike strenge krav hindrer forvirring hos sluttbrukerne.
Dataintegritet
Dataintegritet er praksisen med å kontrollere at alle de nyeste dataene er oppdatert overalt. Det finnes fire individuelle deler som sammen bekrefter at dataene har integritet. For å oppnå et høyt nivå av dataintegritet må en QA-tester bekrefte at:
- Dataene kan verifiseres
- Dataene kan hentes frem
- Dataene er nøyaktige
- Dataene er fullstendige
Hvis dataene ikke oppfyller disse fire kravene, oppfyller de sannsynligvis ikke standarden for dataintegritet. Verktøy for datahåndtering kan hjelpe med dette, men til syvende og sist er det opp til deg å sikre høyest mulig datakvalitet.
Som Huw Price påpekte i episoden av The QA Lead Podcast med tittelen Datakvaliteten din er elendig, blir det stadig viktigere å sørge for at systemene dine kjører på data av høy kvalitet og med god sikkerhet, ettersom stadig flere selskaper bygger opp egne databanker.
Språk for databasemanipulering
Et språk for databasemanipulering (DML) er et programmeringsspråk som brukes til å manipulere data i et databasehåndteringssystem. DML brukes hovedsakelig til å utføre oppgaver som å sette inn, oppdatere, slette og hente data fra en database. I praksis tilbyr DML et sett med kommandoer og funksjoner som gjør det mulig for brukere å samhandle med data i en database og endre eller hente disse dataene i henhold til bestemte kriterier. DML er en viktig komponent i ethvert databasesystem, ettersom det gjør det mulig for brukere å utføre operasjoner på data uten å forstå databasens underliggende struktur eller teknologi.
DML-kommandoer brukes vanligvis sammen med et språk for databasedefinisjon (DDL), som brukes til å opprette og endre databaseobjekter som tabeller, visninger og indekser. DDL og DML utgjør kjernekomponentene i et databasesystem og gjør det mulig for brukere å opprette, endre og manipulere data på en sikker, effektiv og pålitelig måte. Bruken av DML i databasehåndtering gjør det mulig for organisasjoner å lagre, håndtere og analysere store mengder data, noe som gjør det til et kritisk verktøy for virksomheter i dagens datadrevne verden.
Typer databasetesting
Nå som vi har gått gjennom to av kjerneprinsippene for databasetesting, kan vi gå videre til ulike testtyper. Du har sannsynligvis hørt om noen av disse tilnærmingene før. Husk at jeg sa at hvis du forsto QA-testing, ville du lett forstå databasetesting. Her forklarer jeg hvordan hvert av disse konseptene gjelder for databasetesting.
Det finnes tre typer databasetesting:
- Strukturell
- Funksjonell
- Ikke-funksjonell
Innenfor disse tre typene databasetesting finnes det undertyper. Ikke bekymre deg, jeg skal forklare dem også.
Strukturell testing
Strukturell testing validerer elementer i datalageret som brukes til datalagring. Disse elementene er skjult for sluttbrukerne og foregår i sin helhet i bakgrunnen. Databasetestere utfører disse testene ved å skrive SQL-spørringer.
Testing av datatilordning
Tilordning av datastrukturer er prosessen med å etablere forbindelser mellom to ulike datamodeller. En test av datatilordning, også kalt skjematesting, validerer frontenden og backend-løsningen. Den sikrer at de to kommuniserer riktig med hverandre.
Hvis du for eksempel fyller ut et registreringsskjema på et nettsted, vil riktig datatilordning hente dataene fra nettskjemaet og overføre dem til databasen. Navnet, e-postadressen og passordet ditt blir lagret der de skal. Testing av datatilordningen bekrefter at prosessen fungerer.
Det finnes flere verktøy for datatilordning som en kvalitetssikringstester vil arbeide med. En kort liste over verktøy for datatilordning omfatter:
Testing av databasetabeller
Tabelltesting utfører flere kontroller av strukturen for datatilordning. Den kontrollerer at feltene i grensesnittet og bakenden er kompatible med hverandre. Den validerer lengden på databasefeltene. Og den bekrefter om det finnes databasetabeller eller kolonner uten tilordning som du må håndtere.
Validering av databaseserver
Servervalideringer sørger for at serverkonfigurasjonen oppfyller kravene. De sikrer også at alle som prøver å få tilgang til bestemte områder på databaseserveren, har riktig autorisasjon. Dette er et viktig trinn for å holde databasen trygg og sikker for brukerne. Til slutt sørger servervalideringen for at serveren kan håndtere maksimalt antall transaksjoner samtidig.
En servervalidering for en bankapp vil for eksempel kontrollere at serveren kan håndtere den økonomiske transaksjonen til et bestemt antall brukere, og at alle brukere bare får tilgang til sin egen informasjon.
Funksjonell testing
Vi skal gjøre funksjonell testing morsom igjen. Virkelig. Funksjonell testing handler om å kontrollere at databasen oppfyller klientens spesifikasjoner, og at handlingene til sluttbrukeren er i samsvar med disse kravene. Det betyr at man må late som man er sluttbrukeren ganske mye. Høres ikke det morsomt ut? Jeg synes det høres morsomt ut.
Svartboks-testing
Svartboks-testing er en strategi for programvaretesting der utformingen av programvaresystemet som testes, er ukjent for testeren. Uten inngående kjennskap til programvarens utforming vil testeren nærme seg programvaren med forventninger som ligner sluttbrukerens.
Svartboks-testing utføres under databasetesting fordi den finner feil i vanlige brukerflyter som sluttbrukeren sannsynligvis vil møte. Det er den ultimate testkjøringen som sluttbruker.
Vi har gått grundig gjennom svartboks-testing i veiledningen vår 9 typer programvaretesting alle kvalitetssikringsanalytikere bør kjenne til.
Hvitboks-testing
Hvitboks-testing er det diametralt motsatte av svartboks-testing. Ved hvitboks-testing har kvalitetssikringsmedarbeideren full forståelse av den interne strukturen og utformingen av programvaren som testes.
De går inn i testen som en inspektør. Hvitboks-testing kalles noen ganger klarboks-testing fordi testeren observerer samhandlingen mellom enhetene mens programvaren testes. I motsetning til ved svartboks-testing er en hvitboks-tester ikke på langt nær like opptatt av brukeropplevelsen.
Enhetstesting
Enhetstesting er en teknikk for programvaretesting som innebærer å teste individuelle enheter eller komponenter i en applikasjon isolert fra resten av systemet. Denne testtypen brukes til å teste individuelle databaseobjekter, for eksempel tabeller, visninger, lagrede prosedyrer og funksjoner. Ved å teste disse objektene isolert kan utviklere sikre at hvert objekt fungerer som tiltenkt.
Enhetstester for databaser innebærer vanligvis å skrive automatiserte tester som kjører bestemte SQL-kommandoer mot et databaseobjekt eller en modul, og kontrollerer at de forventede resultatene returneres. En enhetstest for en lagret prosedyre kan for eksempel innebære å sende et sett med inndataparametere til prosedyren og kontrollere at resultatet er riktig. Ved å bruke enhetstester på denne måten kan utviklere sikre at hvert databaseobjekt fungerer som forventet, og at endringer i databaseskjemaet eller programkoden ikke fører til utilsiktede konsekvenser eller feil.
Ikke-funksjonell testing
Ikke-funksjonell testing bryr seg ikke om sluttbrukeren. Ikke fordi sluttbrukeren ikke er viktig. De har ganske enkelt andre ting å bekymre seg for. Ikke-funksjonelle tester kontrollerer databasens ytelse under belastning og stress, og ser etter steder der ytelsen kan optimaliseres.
Belastningstesting
Lasttesting av databaser er en type ytelsestesting av databaser som kontrollerer at brukerbelastning ikke vil ha en dramatisk negativ innvirkning på databaseytelsen. Kvalitetstesteren vil kjøre en rekke belastningsspørringer og kjøre dem om og om og om igjen for å simulere en aktiv brukerbase.
Stresstesting
Stresstester er belastningstester, men kraftigere. De vil ikke se om databasen blir tregere, men vil se hvor den kan brytes. Dette er langt mer destruktivt. Så det er jo morsomt.
Har du noen gang spent ventet på lanseringen av et nytt videospill eller en ny telefon? I så fall kjenner du kanskje til å laste inn nettstedet eller åpne appen for å gjennomføre kjøpet, og bli møtt med uvanlig lange lasteskjermer, uventede feilkoder og feil ved behandling av informasjonen din. Det er en database under belastning.
Det er annerledes enn lasttesting fordi databasen utsettes for en plutselig, uventet høy trafikkmengde.
More Articles
Automatisert databasetesting
Automatisert databasetesting har blitt mer populært de siste årene. Å kreve at databasen testes manuelt, ville tatt for lang tid, krevd for mange personer og ganske enkelt kostet for mye penger.
Det finnes mange måter å utføre automatisert testing på. Her er en liste over noen verktøy for databaseadministrasjon som tilbyr testfunksjoner.
Liste over verktøy for databaseadministrasjon
Testing av en database med API
Et API (programmeringsgrensesnitt) er et sett med protokoller og standarder som gjør det mulig for ulike programvareapplikasjoner å kommunisere med hverandre. Ved databasetesting kan et API koble seg til en database og utføre ulike operasjoner, som å sette inn, oppdatere, slette og hente data.
Forholdet mellom et API og databasetesting er at API-er kan brukes til å automatisere og effektivisere testprosessen. Ved å bruke et API til å koble seg til en database kan testere automatisere oppgaver som innsetting, oppdatering og sletting av data, samt utføre spørringer for å hente data og validere resultater. Dette kan redusere tiden og innsatsen som kreves til manuell testing betydelig, og forbedre nøyaktigheten og konsistensen i testresultatene.
Flere ressurser
Etter å ha lest denne artikkelen bør du forstå hvordan du utfører databasetesting. Det er selvfølgelig umulig å dekke absolutt alt i én enkelt artikkel. Her er to ekstra ressurser som kan hjelpe deg med å løse spesifikke problemer.
- Slik regresjonstester du en relasjonsdatabase
- Slik utfører du en ytelsestest mot en SQL Server-instans
Hva synes du?
Det kan føles som et stort ansvar å få i oppgave å teste en database. Jeg er sikker på at du klarer det. Føler du deg tryggere på fremgangsmåten din for databasetesting? Fortell meg det i kommentarfeltet!
