Zelfstudie voor het testen van databases (gegevens).

Wat is databasetesten?

Databasetesten is een type softwaretesten dat het schema, de tabellen, triggers, etc. van de te testen database controleert. Het controleert ook de integriteit en consistentie van de gegevens. Het kan het maken van complexe query's inhouden om de database te laden/stresstesten en de responsiviteit ervan te controleren.

Databasetesten

Waarom databasetesten belangrijk zijn?

Databasetesten zijn belangrijk in software testen omdat het ervoor zorgt dat gegevenswaarden en informatie die worden ontvangen en opgeslagen in de database geldig zijn of niet. Het testen van databases helpt gegevensverlies te voorkomen, afgebroken transactiegegevens op te slaan en ongeautoriseerde toegang tot de informatie te voorkomen. Database is belangrijk voor elke softwaretoepassing. Daarom moeten testers een goede kennis van SQL hebben voor het testen van databases.

De GUI krijgt doorgaans de meeste nadruk van de leden van het test- en ontwikkelingsteam, aangezien de grafische gebruikersinterface het meest zichtbare deel van de applicatie is. Wat echter ook belangrijk is, is het valideren van de informatie die het hart van de applicatie vormt, ook wel DATABASE genoemd.

Laten we eens kijken naar een Banking-applicatie waarin een gebruiker transacties uitvoert. Vanuit het oogpunt van Database Testing of DB Testing zijn de volgende zaken belangrijk:

  1. De applicatie slaat de transactie-informatie op in de applicatiedatabase en geeft deze correct weer aan de gebruiker.
  2. Er gaat geen informatie verloren tijdens het proces.
  3. De toepassing slaat geen informatie op over gedeeltelijk uitgevoerde of afgebroken bewerkingen.
  4. Geen enkele onbevoegde persoon heeft toegang tot de gegevens van de gebruiker.

Om al deze bovenstaande doelstellingen te garanderen, moeten we datavalidatie of datatesten gebruiken.

Verschillen tussen het testen van de gebruikersinterface en het testen van gegevens

Testen van gebruikersinterface versus testen van gegevens

Testen van de gebruikersinterface Database- of gegevenstesten
Dit type testen wordt ook wel Graphical User Interface-testen of Front-end-testen genoemd. Dit type testen wordt ook wel Backend Testen of datatesten genoemd.
Dit type testen houdt zich voornamelijk bezig met alle testbare items die openstaan ​​voor de gebruiker voor kijkers en interactie, zoals formulieren, presentaties, grafieken, menu's en rapporten, enz. (gemaakt via VB, VB.net, VC++, Delphi – Front-endtools) Dit type testen heeft voornamelijk betrekking op alle testbare items die over het algemeen voor de gebruiker verborgen zijn voor kijkers. Deze omvatten interne processen en opslag zoals Assembly, DBMS-achtig Oracle, SQL Server, MYSQL, enz.

Dit type testen omvat het valideren van de

  • tekstvakken
  • vervolgkeuzelijsten selecteren
  • kalenders en knoppen
  • Paginanavigatie
  • weergave van afbeeldingen
  • Look en feel van de totale applicatie

Dit type testen omvat het valideren van:

  • het schema
  • databasetabellen
  • kolommen
  • sleutels en indexen
  • opgeslagen procedures worden geactiveerd
  • validaties van databaseservers
  • het valideren van gegevensduplicatie
De tester moet grondig geïnformeerd zijn over de zakelijke vereisten, het gebruik van de ontwikkeltools en het gebruik van automatiseringsframeworks en -tools. Om backend-testen te kunnen uitvoeren, moet de tester een gedegen achtergrond hebben in de concepten van databaseservers en Structured Query Language.

Soorten databasetesten

Soorten databasetesten

De 3 soorten databasetests zijn

  1. Structureel testen
  2. Functioneel testen
  3. Niet-functioneel testen

In deze zelfstudie over het testen van databases zullen we elk type en zijn subtypen één voor één bekijken.

Structurele databasetests

Structurele databasetests is een databasetesttechniek die alle elementen in de gegevensopslag valideert die voornamelijk worden gebruikt voor gegevensopslag en die niet rechtstreeks door eindgebruikers mogen worden gemanipuleerd. De validatie van databaseservers is ook een belangrijke overweging bij het structureel testen van databases. Voor een succesvolle afronding van deze test is beheersing van SQL-query's vereist.

Wat is schematesten?

Schema testen valideert bij het testen van databases verschillende schemaformaten die aan de database zijn gekoppeld en verifieert of de mappingformaten van tabellen/views/kolommen compatibel zijn met mappingformaten van de gebruikersinterface. Het belangrijkste doel van schematesten is ervoor te zorgen dat de schematoewijzing tussen front-end en back-end vergelijkbaar is. Het wordt daarom ook wel mapping-testen genoemd.

Laten we de belangrijkste controlepunten voor schematests bespreken.

  1. Validatie van de verschillende schemaformaten die aan de databases zijn gekoppeld. Vaak is het mappingformaat van de tabel mogelijk niet compatibel met het mappingformaat dat aanwezig is op het gebruikersinterfaceniveau van de applicatie.
  2. Er is verificatie nodig in het geval van niet-toegewezen tabellen/views/kolommen.
  3. Er moet ook worden gecontroleerd of heterogene databases in een omgeving consistent zijn met de algehele toepassingsmapping.

Laten we ook eens kijken naar enkele interessante tools voor het testen van databases voor het valideren van databaseschema's.

  • DBUnit dat geïntegreerd is met Ant is zeer geschikt voor mappingtesten.
  • Met SQL Server kunnen de testers het schema van de database controleren en opvragen door eenvoudige query's te schrijven en niet via code.

Als de ontwikkelaars bijvoorbeeld een tabelstructuur willen wijzigen of verwijderen, wil de tester er zeker van zijn dat alle opgeslagen procedures en weergaven die die tabel gebruiken, compatibel zijn met de specifieke wijziging. Een ander voorbeeld zou kunnen zijn dat als de testers willen controleren op schemawijzigingen tussen twee databases, ze dat kunnen doen met behulp van eenvoudige query's.

Databasetabel, kolomtesten

Laten we eens kijken naar verschillende controles voor het testen van databases en kolommen.

  1. Of de mapping van de databasevelden en -kolommen in de backend compatibel is met die mappings in de frontend?
  2. Validatie van de lengte en naamgevingsconventie van de databasevelden en -kolommen zoals gespecificeerd door de vereisten.
  3. Validatie van de aanwezigheid van ongebruikte/niet-toegewezen databasetabellen/kolommen.
  4. Validatie van de compatibiliteit van de
  • data type
  • veld lengtes

van de back-end databasekolommen met die van de kolommen aan de voorkant van de applicatie.

  1. Of de databasevelden de gebruiker in staat stellen de gewenste gebruikersinvoer te leveren, zoals vereist door de specificatiedocumenten voor zakelijke vereisten.

Toetsen en indexen testen

Belangrijke controles voor sleutels en indexen –

  1. Controleer of het vereiste
  • Hoofdsleutel
  • Vreemde sleutel

Er zijn beperkingen gemaakt voor de vereiste tabellen.

  1. Controleer of de referenties voor externe sleutels geldig zijn.
  2. Controleer of het gegevenstype van de primaire sleutel en de bijbehorende externe sleutels in de twee tabellen hetzelfde zijn.
  3. Controleer of voor alle sleutels en indexen de vereiste naamgevingsconventies zijn gevolgd.
  4. Controleer de grootte en lengte van de vereiste velden en indexen.
  5. Of het nu gaat om de vereiste
  • Clustered-indexen
  • Niet Clustered-indexen

zijn gemaakt op de vereiste tabellen zoals gespecificeerd door de bedrijfsvereisten.

Opgeslagen procedures testen

Belangrijke tests om opgeslagen procedures te controleren zijn:

  1. Of het ontwikkelteam de vereiste A) coderingsstandaardconventies en B) uitzonderings- en foutafhandeling heeft overgenomen. Voor alle opgeslagen procedures voor alle modules voor de geteste applicatie.
  2. Of het ontwikkelteam alle voorwaarden/loops heeft afgedekt door de vereiste invoergegevens toe te passen op de te testen applicatie?
  3. Heeft het ontwikkelteam de TRIM-bewerking correct toegepast telkens wanneer gegevens uit de vereiste tabellen in de database worden opgehaald?
  4. Of het handmatig uitvoeren van de Stored Procedure de eindgebruiker het gewenste resultaat oplevert?
  5. Zorgt de handmatige uitvoering van de opgeslagen procedure ervoor dat de tabelvelden worden bijgewerkt zoals vereist door de geteste applicatie?
  6. Of de uitvoering van de Opgeslagen Procedures het impliciet aanroepen van de vereiste triggers mogelijk maakt?
  7. Validatie van de aanwezigheid van ongebruikte opgeslagen procedures.
  8. Validatie voor de voorwaarde Allow Null, die op databaseniveau kan worden uitgevoerd.
  9. Validatie van het feit dat alle opgeslagen procedures en functies met succes zijn uitgevoerd wanneer de te testen database leeg is.
  10. Validatie van de algehele integratie van de opgeslagen proceduremodules volgens de vereisten van de geteste applicatie.

Enkele van de nuttige databasetesttools voor het testen van opgeslagen procedures zijn LINQ, SP Testtool enz.

Triggertesten

  1. Of de vereiste codeerconventies zijn gevolgd tijdens de codeerfase van de Triggers?
  2. Controleer of de uitgevoerde triggers voor de betreffende DML-transacties aan de vereiste voorwaarden voldoen.
  3. Of de trigger de gegevens correct bijwerkt nadat ze zijn uitgevoerd?
  4. Validatie van de vereiste Update/Insert/Delete activeert functionaliteit in het domein van de applicatie die wordt getest.

Validaties van databaseservers

Validaties van databaseservers

  1. Controleer de databaseserverconfiguraties zoals gespecificeerd door de zakelijke vereisten.
  2. Controleer de autorisatie van de vereiste gebruiker om alleen die actieniveaus uit te voeren die door de applicatie vereist zijn.
  3. Controleer of de databaseserver in staat is om tegemoet te komen aan de behoeften van het maximaal toegestane aantal gebruikerstransacties, zoals gespecificeerd in de specificaties van de bedrijfsvereisten.

Functioneel databasetesten

Functioneel databasetesten is een type databasetesten dat wordt gebruikt om de functionele vereisten van een database te valideren vanuit het perspectief van de eindgebruiker. Het hoofddoel van functioneel databasetesten is om te testen of de transacties en bewerkingen die door de eindgebruikers worden uitgevoerd en die verband houden met de database, werken zoals verwacht of niet.

Hieronder staan ​​de basisvoorwaarden waaraan moet worden voldaan bij databasevalidaties.

  • Is het veld verplicht terwijl NULL-waarden in dat veld zijn toegestaan?
  • Of de lengte van elk veld voldoende groot is?
  • Of alle vergelijkbare velden dezelfde naam hebben in alle tabellen?
  • Zijn er berekende velden aanwezig in de database?

Dit specifieke proces is de validatie van de veldtoewijzingen vanuit het oogpunt van de eindgebruiker. In dit specifieke scenario zou de tester een bewerking uitvoeren op databaseniveau en vervolgens naar het relevante gebruikersinterface-item navigeren om te observeren en valideren of de juiste veldvalidaties zijn uitgevoerd of niet.

De omgekeerde voorwaarde, waarbij de eerste handeling door de tester wordt uitgevoerd op de gebruikersinterface en deze vervolgens wordt gevalideerd aan de back-end, moet ook worden uitgevoerd.

Het controleren van de integriteit en consistentie van gegevens

De volgende controles zijn belangrijk

  1. Of de data logisch goed georganiseerd zijn?
  2. Of de gegevens die in de tabellen zijn opgeslagen correct zijn en voldoen aan de zakelijke vereisten?
  3. Zijn er onnodige gegevens aanwezig in de te testen applicatie?
  4. Of de gegevens zijn opgeslagen volgens de vereisten met betrekking tot gegevens die zijn bijgewerkt via de gebruikersinterface?
  5. Zijn de TRIM-bewerkingen op de gegevens uitgevoerd voordat de gegevens in de te testen database werden ingevoegd?
  6. Of de transacties zijn uitgevoerd volgens de specificaties van de businessvereisten en of de resultaten correct zijn of niet?
  7. Of de gegevens goed zijn vastgelegd als de transactie succesvol is uitgevoerd?
  8. Of de gegevens succesvol zijn teruggedraaid als de transactie niet succesvol is uitgevoerd door de eindgebruiker?
  9. Zijn de gegevens teruggedraaid als de transactie niet succesvol is uitgevoerd en er meerdere heterogene databases bij de betreffende transactie betrokken zijn geweest?
  10. Of alle transacties zijn uitgevoerd met behulp van de vereiste ontwerpprocedures zoals gespecificeerd door de bedrijfsvereisten van het systeem?

Inloggen en gebruikersbeveiliging

Bij de validatie van de inloggegevens en de beveiligingsgegevens van de gebruiker moet rekening worden gehouden met de volgende zaken.

  1. Of de applicatie de gebruiker verhindert om verder te gaan in de applicatie in geval van a
  • ongeldige gebruikersnaam maar geldig wachtwoord
  • geldige gebruikersnaam maar ongeldig wachtwoord.
  • ongeldige gebruikersnaam en ongeldig wachtwoord.
  1. Mag de gebruiker alleen die specifieke handelingen uitvoeren die zijn gespecificeerd in de bedrijfsvereisten?
  2. Zijn de gegevens beveiligd tegen ongeoorloofde toegang?
  3. Of er verschillende gebruikersrollen zijn aangemaakt met verschillende rechten?
  4. Of alle gebruikers de vereiste toegangsniveaus voor de opgegeven database hebben, zoals vereist door de bedrijfsspecificaties?
  5. Controleer of gevoelige gegevens zoals wachtwoorden, creditcardnummers gecodeerd zijn en niet als platte tekst in de database zijn opgeslagen. Het is een goede gewoonte om ervoor te zorgen dat alle accounts wachtwoorden hebben die complex zijn en niet gemakkelijk te raden.

Niet-functioneel testen

Niet-functioneel testen in de context van databasetests kunnen worden onderverdeeld in verschillende categorieën, afhankelijk van de zakelijke vereisten. Dit kunnen belastingtests, stresstests, Beveiligingstests, Usability Testing en Compatibiliteitstesten, enzovoort. Zowel de belastingstests als de stresstests, die kunnen worden gegroepeerd onder het spectrum van prestatietests, dienen twee specifieke doelen als het gaat om de rol van niet-functioneel testen.

Risico kwantificering– Kwantificering van risico's helpt de belanghebbenden bij het vaststellen van de verschillende systeemresponstijdvereisten onder de vereiste belastingsniveaus. Dit is de oorspronkelijke bedoeling van ieder kwaliteitsborging taak. We moeten opmerken dat het testen van de belasting het risico niet direct beperkt, maar via de processen van risico-identificatie en risicokwantificering corrigerende mogelijkheden biedt en een impuls voor herstel biedt die het risico zal beperken.

Minimale vereiste systeemapparatuur– De minimale systeemconfiguratie waarmee het systeem kan voldoen aan de formeel gestelde prestatieverwachtingen van belanghebbenden. Zodat overbodige hardware, software en de bijbehorende eigendomskosten tot een minimum kunnen worden beperkt. Deze specifieke vereiste kan worden gecategoriseerd als de algehele bedrijfsoptimalisatievereiste.

load Testen

Het doel van elke belastingstest moet duidelijk worden begrepen en gedocumenteerd. De volgende typen configuraties zijn een must voor belasting testen.

  1. De meest gebruikte gebruikerstransacties kunnen de prestaties van alle andere transacties beïnvloeden als ze niet efficiënt zijn.
  2. Er moet minimaal één niet-bewerkende gebruikerstransactie in de uiteindelijke testsuite worden opgenomen, zodat de prestaties van dergelijke transacties kunnen worden onderscheiden van andere, complexere transacties.
  3. De belangrijkste transacties die de kerndoelstellingen van het systeem faciliteren, moeten worden opgenomen, omdat falen onder een belasting van deze transacties per definitie de grootste impact heeft.
  4. Er moet ten minste één bewerkbare transactie worden opgenomen prestatie van dergelijke transacties kan worden onderscheiden van andere transacties.
  5. Optimale responstijd onder een groot aantal virtuele gebruikers voor alle toekomstige vereisten.
  6. Effectieve tijden voor het ophalen van verschillende records.

Belangrijke tools voor het testen van belastingen zijn LoadRunner Professioneel, win loper en JMeter.

Wat is database-stresstesten?

Databasestresstesten is een testmethode die wordt gebruikt om een ​​databasesysteem onder zware belasting te testen, zodat het op een gegeven moment faalt. Dit helpt bij het identificeren van het storingspunt van het databasesysteem. Het vereist een goede planning en inspanningen om overmatig gebruik van hulpbronnen te voorkomen. Gegevens stresstests is ook bekend als marteltesten of vermoeidheidstesten.

Belangrijke tools voor stresstests zijn LoadRunner Professioneel en JMeter.

Meest voorkomende problemen tijdens het testen van databases

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

Oplossing: De algehele procesplanning en timing moeten zo worden georganiseerd dat er geen op tijd en kosten gebaseerde problemen optreden.

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

Oplossing: Er moet een voorafgaand plan en een methodologie voor het genereren van testgegevens beschikbaar zijn.

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.

Oplossing: Het onderhoud van de SQL-query's en het voortdurend bijwerken ervan vormen een belangrijk onderdeel van het algehele testproces, dat daar deel van zou moeten uitmaken test strategie.

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

Oplossing: Er moet een goed evenwicht zijn tussen kwaliteit en de totale duur van de projectplanning.

Mythen of misvattingen met betrekking tot het testen van databases

Mythen

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

Realiteit: Effectief en efficiënt databasetesten bij softwaretesten biedt functionele stabiliteit op de lange termijn voor de algehele applicatie, dus het is noodzakelijk om er hard aan te werken.

Database testing adds extra work bottleneck

Realiteit: Integendeel, het testen van databases voegt meer waarde toe aan het totale werk door verborgen problemen op te sporen en zo proactief te helpen de algehele applicatie te verbeteren.

Database testing slows down the overall development process

Realiteit: Een aanzienlijke hoeveelheid databasetests helpt bij de algehele verbetering van de kwaliteit van de databasetoepassing.

Database testing could be excessively costly

Realiteit: Alle uitgaven aan het testen van databases zijn een langetermijninvestering die leidt tot stabiliteit en robuustheid van de applicatie op de lange termijn. Dus uitgaven voor het testen van databases of SQL Testen is noodzakelijk.

Best Practices

  • Alle gegevens, inclusief de metadata en de functionele gegevens, moeten worden gevalideerd volgens hun mapping door de vereistenspecificatiedocumenten.
  • Verificatie van de testgegevens die door/in overleg met het ontwikkelteam is gemaakt dient gevalideerd te worden.
  • Validatie van de outputgegevens door zowel handmatige als geautomatiseerde procedures te gebruiken.
  • Inzet van verschillende technieken, zoals de oorzaak-gevolggrafiektechniek, de equivalentiepartitioneringstechniek en de grenswaardeanalysetechniek voor het genereren van de vereiste testgegevensomstandigheden.
  • De validatieregels van referentiële integriteit voor de vereiste databasetabellen moeten ook worden gevalideerd.
  • De selectie van standaardtabelwaarden voor validatie op databaseconsistentie is een zeer belangrijk concept. Of de loggebeurtenissen met succes zijn toegevoegd aan de database voor alle vereiste inloggebeurtenissen
  • Worden geplande taken op tijd uitgevoerd?
  • Maak tijdig een back-up van de database.

Controleer ook Interviewvragen en antwoorden voor het testen van databases