Menu

Volledige gids voor databasetests (waarom, wat en hoe gegevens te testen)

database testing complete guide why

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Een complete gids voor databasetests met praktische tips en voorbeelden:

Computertoepassingen zijn tegenwoordig complexer met technologieën zoals Android en ook met veel smartphone-apps. Hoe complexer de voorkant, hoe ingewikkelder de achterkant wordt.

Het is dus des te belangrijker om te leren over DB-testen en om databases effectief te kunnen valideren om de veiligheid en kwaliteitsdatabases te waarborgen.

In deze tutorial leert u alles over datatesten - waarom, hoe en wat te testen?

Gids voor het testen van databases

De database is een van de onvermijdelijke onderdelen van een softwaretoepassing.

Het maakt niet uit of het een web, desktop of mobiel, client-server, peer-to-peer, enterprise of individueel bedrijf is; de database is overal op de backend vereist.

Evenzo, of het nu gaat om gezondheidszorg, financiën, leasing, detailhandel, posttoepassing of het besturen van een ruimteschip; een database is altijd achter de schermen in actie.

Naarmate de complexiteit van applicaties toeneemt, ontstaat de behoefte aan een sterkere en veilige database. Op dezelfde manier, voor de applicaties met een hoge frequentie van transacties ( Bijvoorbeeld, Banking of Finance applicatie), is de noodzaak van een volledig functionele DB Tool gekoppeld.

Tegenwoordig hebben we big data die groot en complex zijn en die de traditionele databases niet aankunnen.

Er zijn meerdere Database-instrumenten zijn op de markt verkrijgbaar Bijvoorbeeld, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer, etc. Deze tools variëren in prijs, robuustheid, features en beveiliging. Elk van deze heeft zijn eigen voor- en nadelen.

Wat je leert:

Waarom een ​​database testen?

Hieronder zullen we zien waarom de volgende aspecten van een database moeten worden gevalideerd:

Alles over databasetests

# 1) Datamapping

In softwaresystemen reizen gegevens vaak heen en weer van de UI (gebruikersinterface) naar de backend-database en vice versa. Dit zijn dus enkele aspecten om op te letten:

  • Controleer of de velden in de UI / frontend-formulieren consistent zijn toegewezen aan de overeenkomstige velden in de DB-tabel. Deze mappinginformatie wordt doorgaans gedefinieerd in de behoeftedocumenten.
  • Telkens wanneer een bepaalde actie wordt uitgevoerd aan de voorkant van een applicatie, wordt een overeenkomstige CRUD-actie (maken, ophalen, bijwerken en verwijderen) aangeroepen aan de achterkant. Een tester zal moeten controleren of de juiste actie wordt aangeroepen en of de aangeroepen actie op zichzelf succesvol is of niet.

# 2) ACID Eigenschappen Validatie

Atomiciteit, consistentie, isolatie en duurzaamheid. Elke transactie die een DB uitvoert, moet aan deze vier eigenschappen voldoen.

DB ACID-eigenschappen

  • Atomiciteit betekent dat een transactie mislukt of slaagt. Dit betekent dat zelfs als een enkel deel van de transactie mislukt, dit betekent dat de hele transactie is mislukt. Meestal wordt dit de 'alles-of-niets' -regel genoemd.
  • Consistentie : Een transactie zal altijd resulteren in een geldige toestand van de DB
  • Isolatie : Als er meerdere transacties zijn en ze worden allemaal tegelijk uitgevoerd, moet het resultaat / de status van de database hetzelfde zijn alsof ze de een na de ander zijn uitgevoerd.
  • Duurzaamheid : Zodra een transactie is voltooid en vastgelegd, mogen externe factoren zoals stroomuitval of crash deze niet kunnen veranderen

Voorgestelde lezing = >> MySQL-transactiehandleiding

# 3) Gegevensintegriteit

Voor elk van de CRUD-operaties moeten de bijgewerkte en meest recente waarden / status van gedeelde gegevens op alle formulieren en schermen verschijnen. De waarde mag niet op het ene scherm worden bijgewerkt en een oudere waarde op een ander scherm weergeven.

Wanneer de toepassing wordt uitgevoerd, wordt het eindgebruiker maakt voornamelijk gebruik van de ‘CRUD’-bewerkingen die worden gefaciliteerd door de DB Tool ​

C: Creëren - Wanneer de gebruiker een nieuwe transactie ‘Opslaan’, wordt ‘Maken’ uitgevoerd.
R: Ophalen - Wanneer de gebruiker een opgeslagen transactie ‘Zoeken’ of ‘Bekijkt’, wordt ‘Ophalen’ uitgevoerd.
U: bijwerken - Wanneer de gebruiker een bestaand record ‘Bewerken’ of ‘Wijzigen’, wordt de ‘Update’ bewerking van DB uitgevoerd.
D: Verwijderen - Wanneer een gebruiker een record uit het systeem ‘Verwijderen’, wordt de ‘Verwijderen’ bewerking van DB uitgevoerd.

Elke databasebewerking die door de eindgebruiker wordt uitgevoerd, is altijd een van de bovenstaande vier.

Dus bedenk uw DB-testcases zo dat u de gegevens op alle plaatsen controleert om te zien of ze consistent hetzelfde zijn.

Testen van gegevensintegriteit

# 4) Conformiteit met zakelijke regels

Meer complexiteit in databases betekent meer gecompliceerde componenten zoals relationele beperkingen, triggers, opgeslagen procedures, enz. Testers zullen dus de juiste SQL-queries moeten bedenken om deze complexe objecten te valideren.

Wat te testen (checklist voor databasetesten)

# 1) Transacties

Bij het testen van transacties is het belangrijk om ervoor te zorgen dat ze voldoen aan de ACID-eigenschappen.

Dit zijn de meest gebruikte uitspraken:

  • BEGIN TRANSACTIE TRANSACTIE #
  • EINDE TRANSACTIE TRANSACTIE #

De Rollback-instructie zorgt ervoor dat de database in een consistente staat blijft.

  • ROLLBACK TRANSACTIE #

Nadat deze instructies zijn uitgevoerd, gebruikt u een Select om ervoor te zorgen dat de wijzigingen zijn doorgevoerd.

  • SELECTEER * UIT TABLENAME

# 2) Databaseschema's

Een databaseschema is niets meer dan een formele definitie van hoe de gegevens in een database worden georganiseerd. Om het te testen:

  • Identificeer de vereisten op basis waarvan de database werkt. Voorbeeldvereisten:
    • Primaire sleutels die moeten worden gemaakt voordat andere velden worden gemaakt.
    • Vreemde sleutels moeten volledig worden geïndexeerd zodat ze gemakkelijk kunnen worden opgehaald en doorzocht.
    • Veldnamen die beginnen of eindigen met bepaalde tekens.
    • Velden met een beperking dat bepaalde waarden wel of niet kunnen worden ingevoegd.
  • Gebruik een van de volgende methoden, afhankelijk van de relevantie:
    • SQL-query DESC om het schema te valideren.
    • Reguliere expressies voor het valideren van de namen van de afzonderlijke velden en hun waarden
    • Tools zoals SchemaCrawler

      • # 3) Triggers

      Wanneer een bepaalde gebeurtenis plaatsvindt op een bepaalde tafel, kan een stuk code (een trigger) automatisch worden geïnstrueerd om te worden uitgevoerd.

      Bijvoorbeeld, een nieuwe leerling ging naar een school. De student volgt 2 lessen: wiskunde en natuurkunde. De student wordt toegevoegd aan de “studententafel”. Een trigger kan de student toevoegen aan de corresponderende onderwerptabellen zodra hij is toegevoegd aan de studententabel.

      De gebruikelijke methode om te testen is om de SQL-query die is ingesloten in de Trigger eerst onafhankelijk uit te voeren en het resultaat op te nemen. Volg dit door de Trigger als geheel uit te voeren. Vergelijk de resultaten.

      Deze worden getest in zowel de Black-box als de White-box testfase.

      hoe open ik een json-bestand?
      • White box testen : Stubs en Drivers worden gebruikt om gegevens in te voegen, bij te werken of te verwijderen die ertoe zouden leiden dat de trigger wordt aangeroepen. Het basisidee is om de DB alleen te testen, zelfs voordat de integratie met de front-end (UI) is gemaakt.
      • Black box testen ​

      naar) Sinds de UI en DB is integratie nu beschikbaar; we kunnen gegevens invoegen / verwijderen / bijwerken vanaf de front-end op een manier dat de trigger wordt aangeroepen. Daarna kunnen Select-instructies worden gebruikt om de DB-gegevens op te halen om te zien of de Trigger de beoogde bewerking heeft uitgevoerd.

      b) De tweede manier om dit te testen, is door de gegevens die de trigger zouden aanroepen direct te laden en te kijken of deze werkt zoals bedoeld.

      # 4) Opgeslagen procedures

      Opgeslagen procedures lijken min of meer op door de gebruiker gedefinieerde functies. Deze kunnen worden aangeroepen door middel van Call Procedure / Execute Procedure-instructies en de uitvoer heeft meestal de vorm van resultatensets.

      Deze worden opgeslagen in het RDBMS en zijn beschikbaar voor applicaties.

      Deze worden ook getest tijdens:

      • White box testen: Stubs worden gebruikt om de opgeslagen procedures aan te roepen en vervolgens worden de resultaten gevalideerd tegen de verwachte waarden.
      • Black box testen: Voer een bewerking uit vanaf de front-end (UI) van de applicatie en controleer de uitvoering van de opgeslagen procedure en de resultaten ervan.

      # 5) Veldbeperkingen

      De standaardwaarde, unieke waarde en externe sleutel:

      • Voer een front-end-bewerking uit die de voorwaarde Databaseobject oefent
      • Valideer de resultaten met een SQL-query.

      Het controleren van de standaardwaarde voor een bepaald veld is vrij eenvoudig. Het maakt deel uit van de validatie van bedrijfsregels. U kunt het handmatig doen of u kunt tools zoals QTP gebruiken. Handmatig kunt u een actie uitvoeren die een andere waarde toevoegt dan de standaardwaarde van het veld vanaf de voorkant en kijken of dit resulteert in een fout.

      Het volgende is een voorbeeld van een VBScript-code:

      ​

      Het resultaat van de bovenstaande code is True als de standaardwaarde bestaat of False als dat niet het geval is.

      Het controleren van de unieke waarde kan precies zo worden gedaan als voor de standaardwaarden. Probeer waarden uit de gebruikersinterface in te voeren die in strijd zijn met deze regel en kijk of er een fout wordt weergegeven.

      Automation VB Script-code kan zijn:

      ​

      Voor deVreemde sleutelbij beperking validatie wordt gebruik gemaakt van het laden van gegevens die direct gegevens invoeren die de beperking schenden en kijken of de toepassing deze beperkingen beperkt of niet. Voer samen met het laden van de back-end-gegevens ook de front-end UI-bewerkingen uit op een manier die de beperkingen schendt en kijk of de relevante fout wordt weergegeven.

      Data Testing Activiteiten

      Databasetester moet zich concentreren op de volgende testactiviteiten:

      # 1) Zorg voor datamapping:

      Datamapping is een van de belangrijkste aspecten van de database en moet door elke softwaretester grondig worden getest.

      Zorg ervoor dat de mapping tussen verschillende formulieren of schermen van AUT en zijn DB niet alleen nauwkeurig is, maar ook volgens de ontwerpdocumenten (SRS / BRS) of code. In principe moet u de toewijzing tussen elk front-end-veld valideren met het bijbehorende back-end-databaseveld.

      Controleer voor alle CRUD-bewerkingen of de respectieve tabellen en records worden bijgewerkt wanneer de gebruiker op ‘Opslaan’, ‘Bijwerken’, ‘Zoeken’ of ‘Verwijderen’ klikt in de GUI van de applicatie.

      Wat u nodig heeft om te verifiëren:

      • Tabeltoewijzing, kolomtoewijzing en gegevenstypetoewijzing.
      • Gegevens in kaart brengen.
      • De juiste CRUD-bewerking wordt aangeroepen voor elke gebruikersactie in de gebruikersinterface.
      • CRUD-bewerking is geslaagd.

      # 2) Zorg voor ACID-eigenschappen van transacties:

      ACID-eigenschappen van DB-transacties verwijzen naar de ‘ NAAR tomiciteit ’,‘ C consistentie ’,‘ ik solation 'en' D urability '. Het correct testen van deze vier eigenschappen moet worden uitgevoerd tijdens de databasetestactiviteit. U moet controleren of elke afzonderlijke transactie voldoet aan de ACID-eigenschappen van de database.

      ACID-eigenschappen

      Laten we een eenvoudig voorbeeld nemen via onderstaande SQL-code:

      ​

      De ACID-testtabel heeft twee kolommen: A en B. Er is een integriteitsbeperking dat de som van de waarden in A en B altijd 100 moet zijn.

      Atomiciteitstest zorgt ervoor dat elke transactie die op deze tabel wordt uitgevoerd, alles of geen is, d.w.z. dat er geen records worden bijgewerkt als een stap van de transactie is mislukt.

      Consistentietest zorgt ervoor dat wanneer de waarde in kolom A of B wordt bijgewerkt, de som altijd 100 blijft. Het is niet mogelijk om in A of B in te voegen / verwijderen / bijwerken als de totale som iets anders is dan 100.

      Isolatietest zal ervoor zorgen dat als twee transacties tegelijkertijd plaatsvinden en de gegevens van de ACID-testtabel proberen te wijzigen, deze tracties geïsoleerd worden uitgevoerd.

      Uithoudings test zal ervoor zorgen dat zodra een transactie over deze tafel is vastgelegd, dit zo blijft, zelfs in het geval van stroomuitval, crashes of fouten.

      Dit gebied vereist meer rigoureuze, grondige en scherpere tests als uw toepassing de gedistribueerde database gebruikt.

      # 3) Zorg voor gegevensintegriteit

      Bedenk dat verschillende modules (d.w.z. schermen of formulieren) van applicaties dezelfde gegevens op verschillende manieren gebruiken en alle CRUD-bewerkingen op de gegevens uitvoeren.

      Zorg er in dat geval voor dat overal de laatste stand van de gegevens wordt weergegeven. Het systeem moet de bijgewerkte en meest recente waarden of de status van dergelijke gedeelde gegevens op alle formulieren en schermen weergeven. Dit wordt gegevensintegriteit genoemd.

      van

      Testcases voor het valideren van databasegegevensintegriteit:

      • Controleer of alle triggers aanwezig zijn om referentietabelrecords bij te werken.
      • Controleer of er onjuiste / ongeldige gegevens zijn in de hoofdkolommen van elke tabel.
      • Probeer verkeerde gegevens in tabellen in te voegen en kijk of er een storing optreedt.
      • Controleer wat er gebeurt als u probeert een kind in te voegen voordat u de ouder invoert (probeer te spelen met primaire en externe sleutels).
      • Test of er een fout optreedt als u een record verwijdert waarnaar nog steeds wordt verwezen door gegevens in een andere tabel.
      • Controleer of gerepliceerde servers en databases gesynchroniseerd zijn.

      # 4) Zorg voor de nauwkeurigheid van de geïmplementeerde bedrijfsregels:

      Tegenwoordig zijn databases niet alleen bedoeld om de records op te slaan. In feite zijn databases geëvolueerd tot uiterst krachtige tools die de ontwikkelaars ruimschoots ondersteunen om de bedrijfslogica op DB-niveau te implementeren.

      Enkele eenvoudige voorbeelden van krachtige functies zijn ‘Referentiële integriteit’, relationele beperkingen, triggers en opgeslagen procedures.

      Dus met behulp van deze en vele andere functies die door DB's worden aangeboden, implementeren ontwikkelaars de bedrijfslogica op DB-niveau. De tester moet ervoor zorgen dat de geïmplementeerde bedrijfslogica correct is en nauwkeurig werkt.

      De bovenstaande punten beschrijven de vier belangrijkste ‘What To’ van het testen van DB. Laten we nu verder gaan met het gedeelte ‘How To’.

      Hoe de database te testen (stapsgewijs proces)

      De algemene testdatabase voor testprocessen verschilt niet veel van elke andere applicatie.

      Dit zijn de belangrijkste stappen:

      Stap 1) Bereid de omgeving voor
      Stap 2) Voer een test uit
      Stap 3) Controleer het testresultaat
      Stap 4) Valideer volgens de verwachte resultaten
      Stap # 5) Rapporteer de bevindingen aan de respectievelijke belanghebbenden

      Database testproces

      Meestal worden SQL-queries gebruikt om de tests te ontwikkelen. De meest gebruikte opdracht is 'Selecteer'.

      Selecteer * van waar

      Naast Select heeft SQL 3 belangrijke soorten commando's:

      1. DDL: taal voor gegevensdefinitie
      2. DML: taal voor gegevensmanipulatie
      3. DCL: Data control language

      Laten we de syntaxis voor de meest gebruikte uitspraken bekijken.

      Data Definition-taal Gebruikt CREATE, ALTER, RENAME, DROP en TRUNCATE om tabellen (en indexen) af te handelen.

      Data Manipulatie Taal Bevat verklaringen om records toe te voegen, bij te werken en te verwijderen.

      Data control taal: Behandelt het verlenen van autorisatie aan gebruikers voor manipulatie van en toegang tot de gegevens. Grant en Revoke zijn de twee verklaringen die worden gebruikt.

      Syntaxis toekennen:
      Verleen selecteren / bijwerken
      Aan


      Naar ;

      Syntaxis intrekken:
      Selectie / update intrekken
      Aan


      van;

      Enkele praktische tips

      # 1) Zelf vragen stellen:

      Om de database nauwkeurig te testen, moet de tester een zeer goede kennis hebben van SQL- en DML-instructies (Data Manipulation Language). De tester moet ook de interne DB-structuur van AUT kennen.

      U kunt GUI en gegevensverificatie combineren in respectieve tabellen voor een betere dekking. Als u de SQL-server gebruikt, kunt u SQL Query Analyzer gebruiken om queries te schrijven, uit te voeren en resultaten op te halen.

      Dit is de beste en meest robuuste manier om een ​​database te testen wanneer de applicatie een klein of gemiddeld complexiteitsniveau heeft.

      Als de applicatie erg complex is, kan het voor de tester moeilijk of onmogelijk zijn om alle vereiste SQL-queries te schrijven. Bij complexe vragen raak je hulp van de ontwikkelaar. Ik raad deze methode altijd aan, omdat het je vertrouwen geeft bij het testen en ook je SQL-vaardigheden verbetert.

      # 2) Bekijk de gegevens in elke tabel:

      U kunt gegevensverificatie uitvoeren met behulp van de resultaten van CRUD-bewerkingen. Dit kan handmatig worden gedaan door de gebruikersinterface van de applicatie te gebruiken als u de database-integratie kent. Maar dit kan een vervelende en omslachtige taak zijn als er enorme gegevens in verschillende databasetabellen staan.

      Voor handmatige gegevenstests moet de databasetester een goede kennis hebben van de databasetabelstructuur.

      # 3) Krijg vragen van de ontwikkelaars:

      Dit is de eenvoudigste manier om de database te testen. Voer een CRUD-bewerking uit vanuit de GUI en verifieer de impact ervan door de respectieve SQL-query's uit te voeren die zijn verkregen van de ontwikkelaar. Het vereist geen goede kennis van SQL en ook geen goede kennis van de DB-structuur van de applicatie.

      Maar deze methode moet voorzichtig worden gebruikt. Wat moet ik doen als de vraag van de ontwikkelaar semantisch onjuist is of niet correct voldoet aan de eisen van de gebruiker? Het proces zal eenvoudigweg de gegevens niet valideren.

      # 4) Maak gebruik van tools voor het testen van databaseautomatisering:

      Er zijn verschillende tools beschikbaar voor het gegevenstestproces. Kies het juiste gereedschap volgens uw behoeften en maak er optimaal gebruik van.

      ​ Hier is de lijst met de TOP DB-testtools die u moet controleren

      Gevolgtrekking

      Met al deze functies, factoren en processen die op een database moeten worden getest, is er een toenemende vraag naar de testers om technisch bekwaam te zijn in de belangrijkste databaseconcepten. Ondanks enkele van de negatieve opvattingen dat het testen van een database nieuwe knelpunten creëert en veel extra uitgaven met zich meebrengt, is dit een gebied van testen dat veel aandacht en vraag trekt.

      Voorgestelde lezing = >> Wat is databasebeveiligingstests

      Ik hoop dat deze tutorial heeft geholpen om je te concentreren op waarom dat zo is en je ook de basisdetails heeft gegeven van wat er nodig is om een ​​database te testen.

      Laat ons uw feedback weten en deel ook uw persoonlijke ervaringen als u aan DB-testen werkt.

      Aanbevolen literatuur

      ^