Menu

Guida completa al test del database (perché, cosa e come testare i dati)

database testing complete guide why

Prova Il Nostro Strumento Per Eliminare I Problemi

Una guida completa al test del database con suggerimenti pratici ed esempi:

Le applicazioni per computer sono più complesse in questi giorni con tecnologie come Android e anche con molte app per smartphone. Più complesse sono le estremità anteriori, più complesse diventano le estremità posteriori.

Quindi è tanto più importante conoscere i test dei DB ed essere in grado di convalidare i database in modo efficace per garantire la sicurezza e la qualità dei database.

In questo tutorial imparerai tutto sul test dei dati: perché, come e cosa testare?

Guida al test del database

Il database è una delle parti inevitabili di un'applicazione software.

Non importa se si tratta di un'azienda Web, desktop o mobile, client-server, peer-to-peer, aziendale o individuale; il database è richiesto ovunque nel backend.

Allo stesso modo, che si tratti di applicazioni sanitarie, finanziarie, di leasing, vendita al dettaglio, di posta o di controllo di un'astronave; un database è sempre in azione dietro le quinte.

Con l'aumentare della complessità dell'applicazione, emerge la necessità di un database più forte e sicuro. Allo stesso modo, per le applicazioni con un'alta frequenza di transazioni ( Per esempio, Banking o Finance application), la necessità di uno strumento DB completo è accoppiata.

Al giorno d'oggi, abbiamo big data di grandi dimensioni e complessi che i database tradizionali non possono gestire.

Ce ne sono diversi Strumenti di database sono disponibili sul mercato Per esempio, MS-Access, MS SQL Server, SQL Server, Oracle, Oracle Financial, MySQL, PostgreSQL, DB2, Toad, Admirer, ecc. Questi strumenti variano in termini di costo, robustezza, funzionalità e sicurezza. Ognuno di questi ha i suoi vantaggi e svantaggi.

Cosa imparerai:

Perché testare il database?

Di seguito, vedremo perché i seguenti aspetti di un DB dovrebbero essere convalidati:

Tutto sul test del database

# 1) Mappatura dei dati

Nei sistemi software, i dati viaggiano spesso avanti e indietro dall'interfaccia utente (interfaccia utente) al database back-end e viceversa. Quindi questi sono alcuni aspetti da tenere d'occhio:

  • Controlla se i campi nei moduli UI / frontend sono mappati in modo coerente con i campi corrispondenti nella tabella DB. Di solito queste informazioni di mappatura sono definite nei documenti dei requisiti.
  • Ogni volta che una determinata azione viene eseguita sul front-end di un'applicazione, viene richiamata un'azione CRUD (Crea, Recupera, Aggiorna ed Elimina) corrispondente nel back-end. Un tester dovrà verificare se viene invocata l'azione corretta e se l'azione invocata di per sé ha successo o meno.

# 2) Convalida delle proprietà ACID

Atomicità, coerenza, isolamento e durata. Ogni transazione eseguita da un DB deve aderire a queste quattro proprietà.

Proprietà DB ACID

  • Atomicita significa che una transazione fallisce o va a buon fine. Ciò significa che anche se una singola parte della transazione fallisce, significa che l'intera transazione è fallita. Di solito, questa è chiamata regola del 'tutto o niente'.
  • Consistenza : Una transazione risulterà sempre in uno stato valido del DB
  • Solitudine : Se sono presenti più transazioni e vengono eseguite tutte in una volta, il risultato / stato del DB dovrebbe essere lo stesso come se fossero state eseguite una dopo l'altra.
  • Durevolezza : Una volta che una transazione è stata eseguita e confermata, nessun fattore esterno come la perdita di alimentazione o il crash dovrebbe essere in grado di modificarla

Lettura consigliata = >> Tutorial sulle transazioni MySQL

# 3) Integrità dei dati

Per uno qualsiasi dei Operazioni CRUD , i valori / lo stato aggiornati e più recenti dei dati condivisi dovrebbero apparire su tutti i moduli e schermate. Il valore non deve essere aggiornato su una schermata e visualizzare un valore precedente su un'altra.

Quando l'applicazione è in esecuzione, il l'utente finale utilizza principalmente le operazioni 'CRUD' facilitate dal DB Tool .

C: Crea - Quando l'utente 'Salva' una nuova transazione, viene eseguita l'operazione 'Crea'.
R: Recupera - Quando l'utente 'Cerca' o 'Visualizza' una transazione salvata, viene eseguita l'operazione 'Recupera'.
U: Aggiorna - Quando l'utente 'Modifica' o 'Modifica' un record esistente, viene eseguita l'operazione 'Aggiorna' del DB.
D: Elimina - Quando un utente 'rimuove' un record dal sistema, viene eseguita l'operazione 'Elimina' del DB.

Qualsiasi operazione sul database eseguita dall'utente finale è sempre una delle quattro precedenti.

Quindi concepisci i tuoi casi di test DB in modo da includere il controllo dei dati in tutti i punti in cui sembra che siano gli stessi.

Test di integrità dei dati

# 4) Conformità alle regole aziendali

Più complessità nei database significa componenti più complicati come vincoli relazionali, trigger, stored procedure, ecc. Quindi i tester dovranno elaborare query SQL appropriate per convalidare questi oggetti complessi.

Cosa testare (elenco di controllo del test del database)

# 1) Transazioni

Quando si testano le transazioni è importante assicurarsi che soddisfino le proprietà ACID.

Queste sono le dichiarazioni comunemente usate:

  • INIZIA LA TRANSAZIONE TRANSAZIONE #
  • FINE TRANSAZIONE TRANSAZIONE #

L'istruzione Rollback garantisce che il database rimanga in uno stato coerente.

  • TRANSAZIONE ROLLBACK #

Dopo che queste istruzioni sono state eseguite, usa un Seleziona per assicurarti che le modifiche siano state riflesse.

  • SELEZIONA * DA TABLENAME

# 2) Schemi di database

Uno schema di database non è altro che una definizione formale di come i dati verranno organizzati all'interno di un DB. Per provarlo:

  • Identificare i requisiti in base ai quali opera il database. Requisiti del campione:
    • Chiavi primarie da creare prima di creare qualsiasi altro campo.
    • Le chiavi esterne dovrebbero essere completamente indicizzate per un facile recupero e ricerca.
    • Nomi di campo che iniziano o finiscono con determinati caratteri.
    • Campi con un vincolo che determinati valori possono o non possono essere inseriti.
  • Utilizzare uno dei seguenti metodi in base alla rilevanza:
    • Query SQL DESC per convalidare lo schema.
    • Espressioni regolari per la convalida dei nomi dei singoli campi e dei loro valori
    • Strumenti come SchemaCrawler

      • # 3) Trigger

      Quando un determinato evento si verifica su una determinata tabella, è possibile istruire automaticamente un pezzo di codice (un trigger) per essere eseguito.

      Per esempio, un nuovo studente si è iscritto a una scuola. Lo studente sta frequentando 2 lezioni: matematica e scienze. Lo studente viene aggiunto alla 'tabella studenti'. Un attivatore potrebbe aggiungere lo studente alle tabelle delle materie corrispondenti una volta che è stato aggiunto alla tabella degli studenti.

      Il metodo comune per eseguire il test consiste nell'eseguire prima la query SQL incorporata nel trigger in modo indipendente e registrare il risultato. Segui questo con l'esecuzione dell'intero trigger. Confronta i risultati.

      Questi vengono testati in entrambe le fasi di test Black-box e White-box.

      miglior software di backup gratuito per Windows 7 64 bit
      • Test della scatola bianca : Stub e driver vengono utilizzati per inserire o aggiornare o eliminare i dati che comporterebbero il richiamo del trigger. L'idea di base è testare solo il DB anche prima che venga realizzata l'integrazione con il front-end (UI).
      • Test della scatola nera :

      per) Dall'interfaccia utente e dal database, l'integrazione è ora disponibile; possiamo inserire / eliminare / aggiornare i dati dal front-end in modo che il trigger venga richiamato. Successivamente, le istruzioni Select possono essere utilizzate per recuperare i dati del DB per vedere se il trigger è riuscito a eseguire l'operazione prevista.

      b) Il secondo modo per testarlo è caricare direttamente i dati che richiamerebbero il trigger e vedere se funziona come previsto.

      # 4) Stored procedure

      Le stored procedure sono più o meno simili alle funzioni definite dall'utente. Questi possono essere richiamati dalle istruzioni Call Procedure / Execute Procedure e l'output è solitamente sotto forma di set di risultati.

      Questi sono memorizzati nell'RDBMS e sono disponibili per le applicazioni.

      Questi vengono anche testati durante:

      • Test della scatola bianca: Gli stub vengono utilizzati per richiamare le stored procedure e quindi i risultati vengono convalidati rispetto ai valori previsti.
      • Test della scatola nera: Eseguire un'operazione dal front-end (UI) dell'applicazione e verificare l'esecuzione della stored procedure e dei relativi risultati.

      # 5) Vincoli di campo

      Il valore predefinito, il valore univoco e la chiave esterna:

      • Eseguire un'operazione front-end che esercita la condizione dell'oggetto Database
      • Convalida i risultati con una query SQL.

      Controllare il valore predefinito per un determinato campo è abbastanza semplice. Fa parte della convalida delle regole aziendali. Puoi farlo manualmente o puoi usare strumenti come QTP. Manualmente, è possibile eseguire un'azione che aggiungerà un valore diverso dal valore predefinito del campo dal front-end e vedere se si verifica un errore.

      Di seguito è riportato un codice VBScript di esempio:

      Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)

      Il risultato del codice precedente è True se il valore predefinito esiste o False se non lo è.

      Il controllo del valore univoco può essere eseguito esattamente come abbiamo fatto per i valori predefiniti. Prova a inserire valori dall'interfaccia utente che violeranno questa regola e verifica se viene visualizzato un errore.

      Il codice dello script VB di automazione può essere:

      Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match)

      Per ilChiave esternala convalida del vincolo utilizza caricamenti di dati che immettono direttamente dati che violano il vincolo e verifica se l'applicazione li limita o meno. Insieme al caricamento dei dati di back-end, eseguire anche le operazioni dell'interfaccia utente del front-end in modo da violare i vincoli e verificare se viene visualizzato l'errore pertinente.

      Attività di test dei dati

      Il tester del database dovrebbe concentrarsi sulle seguenti attività di test:

      # 1) Garantire la mappatura dei dati:

      La mappatura dei dati è uno degli aspetti chiave del database e dovrebbe essere testata rigorosamente da ogni tester di software.

      Assicurati che la mappatura tra le diverse forme o schermate di AUT e il suo DB non sia solo accurata ma anche per i documenti di progettazione (SRS / BRS) o il codice. Fondamentalmente, è necessario convalidare la mappatura tra ogni campo front-end con il corrispondente campo del database back-end.

      Per tutte le operazioni CRUD, verificare che le rispettive tabelle e record siano aggiornati quando l'utente fa clic su 'Salva', 'Aggiorna', 'Cerca' o 'Elimina' dalla GUI dell'applicazione.

      Cosa devi verificare:

      • Mappatura di tabelle, mapping di colonne e mapping del tipo di dati.
      • Ricerca mappatura dei dati.
      • La corretta operazione CRUD viene richiamata per ogni azione dell'utente sull'interfaccia utente.
      • L'operazione CRUD è riuscita.

      # 2) Garantire le proprietà ACID delle transazioni:

      Le proprietà ACID delle transazioni DB si riferiscono a ' PER tomicità ',' C onsistency ',' io solation 'e' D urability '. La verifica corretta di queste quattro proprietà deve essere eseguita durante l'attività di test del database. È necessario verificare che ogni singola transazione soddisfi le proprietà ACID del database.

      Proprietà ACID

      Facciamo un semplice esempio attraverso il seguente codice SQL:

      CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));

      La tabella di test ACID avrà due colonne: A e B. Esiste un vincolo di integrità per cui la somma dei valori in A e B deve essere sempre 100.

      Test di atomicità assicurerà che tutte le transazioni eseguite su questa tabella siano tutte o nessuna, ovvero nessun record viene aggiornato se qualsiasi passaggio della transazione non è riuscito.

      Test di coerenza assicurerà che ogni volta che il valore nella colonna A o B viene aggiornato, la somma rimanga sempre 100. Non consentirà l'inserimento / l'eliminazione / l'aggiornamento in A o B se la somma totale è diversa da 100.

      Test di isolamento assicurerà che se due transazioni avvengono contemporaneamente e provano a modificare i dati della tabella di test ACID, queste trazioni vengono eseguite in isolamento.

      Test di durata assicurerà che una volta che una transazione su questa tabella è stata confermata, rimarrà tale, anche in caso di interruzione di corrente, crash o errori.

      Quest'area richiede test più rigorosi, approfonditi e approfonditi se l'applicazione utilizza il database distribuito.

      # 3) Garantire l'integrità dei dati

      Considera che diversi moduli (cioè schermate o forme) dell'applicazione utilizzano gli stessi dati in modi diversi ed eseguono tutte le operazioni CRUD sui dati.

      In tal caso, assicurati che lo stato più recente dei dati si rifletta ovunque. Il sistema deve mostrare i valori aggiornati e più recenti o lo stato di tali dati condivisi su tutti i moduli e schermate. Questo è chiamato come integrità dei dati.

      di

      Casi di test per la convalida dell'integrità dei dati del database:

      • Verificare se sono presenti tutti i trigger per aggiornare i record della tabella di riferimento.
      • Controlla se sono presenti dati errati / non validi nelle colonne principali di ciascuna tabella.
      • Prova a inserire dati errati nelle tabelle e osserva se si verifica un errore.
      • Controlla cosa succede se provi a inserire un bambino prima di inserire il suo genitore (prova a giocare con chiavi primarie ed esterne).
      • Verificare se si verifica un errore se si elimina un record a cui fanno ancora riferimento i dati in qualsiasi altra tabella.
      • Controlla se i server ei database replicati sono sincronizzati.

      # 4) Garantire l'accuratezza delle regole aziendali implementate:

      Oggi, i database non sono pensati solo per archiviare i record. In effetti, i database si sono evoluti in strumenti estremamente potenti che forniscono ampio supporto agli sviluppatori per implementare la logica di business a livello di DB.

      Alcuni semplici esempi di potenti funzionalità sono 'integrità referenziale', vincoli relazionali, trigger e stored procedure.

      Quindi, utilizzando queste e molte altre funzionalità offerte dai DB, gli sviluppatori implementano la logica di business a livello di DB. Il tester deve assicurarsi che la logica di business implementata sia corretta e funzioni accuratamente.

      I punti precedenti descrivono i quattro 'Cosa fare' più importanti del test di DB. Ora, passiamo alla parte 'Come fare per'.

      Come testare il database (procedura dettagliata)

      Il database di test del processo di test generale non è molto diverso da qualsiasi altra applicazione.

      I seguenti sono i passaggi principali:

      Passo 1) Prepara l'ambiente
      Passo 2) Esegui un test
      Passaggio 3) Controlla il risultato del test
      Passaggio 4) Convalida in base ai risultati attesi
      Passaggio 5) Riferire i risultati alle rispettive parti interessate

      Processo di test del database

      Di solito, le query SQL vengono utilizzate per sviluppare i test. Il comando più comunemente utilizzato è 'Seleziona'.

      Seleziona * da dove

      Oltre a Select, SQL ha 3 importanti tipi di comandi:

      1. DDL: linguaggio di definizione dei dati
      2. DML: linguaggio di manipolazione dei dati
      3. DCL: linguaggio di controllo dei dati

      Vediamo la sintassi per le istruzioni più comunemente usate.

      Linguaggio di definizione dei dati Utilizza CREATE, ALTER, RENAME, DROP e TRUNCATE per gestire tabelle (e indici).

      Linguaggio di manipolazione dei dati Include istruzioni per aggiungere, aggiornare ed eliminare record.

      Linguaggio di controllo dati: Si occupa di autorizzare gli utenti alla manipolazione e all'accesso ai dati. Concedere e revocare sono le due dichiarazioni utilizzate.

      Concedi sintassi:
      Concedi selezione / aggiornamento
      Su


      Per ;

      Revoca sintassi:
      Revoca selezione / aggiornamento
      su


      a partire dal;

      Alcuni consigli pratici

      # 1) Scrivi tu stesso le domande:

      Per testare accuratamente il database, il tester deve avere un'ottima conoscenza delle istruzioni SQL e DML (Data Manipulation Language). Il tester dovrebbe anche conoscere la struttura DB interna di AUT.

      È possibile combinare la GUI e la verifica dei dati nelle rispettive tabelle per una migliore copertura. Se si utilizza il server SQL, è possibile utilizzare SQL Query Analyzer per scrivere query, eseguirle e recuperare i risultati.

      Questo è il modo migliore e affidabile per testare un database quando l'applicazione ha un livello di complessità medio o piccolo.

      Se l'applicazione è molto complessa, potrebbe essere difficile o impossibile per il tester scrivere tutte le query SQL richieste. Per domande complesse, chiedi aiuto allo sviluppatore. Consiglio sempre questo metodo in quanto ti dà fiducia nei test e migliora anche le tue abilità SQL.

      # 2) Osserva i dati in ogni tabella:

      È possibile eseguire la verifica dei dati utilizzando i risultati delle operazioni CRUD. Questa operazione può essere eseguita manualmente utilizzando l'interfaccia utente dell'applicazione quando si conosce l'integrazione del database. Ma questo può essere un compito noioso e macchinoso quando ci sono dati enormi in diverse tabelle di database.

      Per il test manuale dei dati, il tester del database deve possedere una buona conoscenza della struttura delle tabelle del database.

      # 3) Ricevi domande dagli sviluppatori:

      Questo è il modo più semplice per testare il database. Eseguire qualsiasi operazione CRUD dalla GUI e verificarne gli impatti eseguendo le rispettive query SQL ottenute dallo sviluppatore. Non richiede una buona conoscenza di SQL né una buona conoscenza della struttura del database dell'applicazione.

      Ma questo metodo deve essere usato con cautela. Cosa succede se la query fornita dallo sviluppatore è semanticamente errata o non soddisfa correttamente i requisiti dell'utente? Il processo semplicemente non riuscirà a convalidare i dati.

      # 4) Utilizza gli strumenti di test dell'automazione del database:

      Sono disponibili diversi strumenti per il processo di test dei dati. Dovresti scegliere lo strumento corretto in base alle tue esigenze e utilizzarlo al meglio.

      => Ecco l'elenco dei TOP DB Testing Tools che dovresti controllare

      Conclusione

      Con tutte queste caratteristiche, fattori e processi da testare su un database, vi è una crescente domanda per i tester di essere tecnicamente competenti nei concetti chiave del database. Nonostante alcune delle convinzioni negative che il test di un database crei nuovi colli di bottiglia e costi molto aggiuntivi, questo è un ambito di test che sta attirando molta attenzione e domanda.

      Lettura consigliata = >> Che cos'è il test di sicurezza del database

      Spero che questo tutorial ti abbia aiutato a concentrarti sul perché è così e ti abbia anche fornito i dettagli di base di ciò che è necessario per testare un database.

      Fateci sapere il vostro feedback e condividete anche le vostre esperienze personali se state lavorando al test DB.

      Lettura consigliata

      ^