Esercitazione sul test del database (dati).

Che cos’è il test del database?

Il test del database è un tipo di test del software che verifica lo schema, le tabelle, i trigger, ecc. del database sottoposto a test. Controlla inoltre l’integrità e la coerenza dei dati. Può comportare la creazione di query complesse per caricare/stressare il database e verificarne la reattività.

Perché il test del database è importante?

Il test del database è importante nel test del software perché garantisce che i valori dei dati e le informazioni ricevute e archiviate nel database siano validi o meno. Il test del database aiuta a salvare la perdita di dati, salva i dati delle transazioni interrotte e nessun accesso non autorizzato alle informazioni. Il database è importante per qualsiasi applicazione software, quindi i tester devono avere una buona conoscenza di SQL per il test del database.

Alla GUI viene generalmente data la massima enfasi dai membri del team di test e sviluppo poiché l’interfaccia utente grafica sembra essere la parte più visibile dell’applicazione. Tuttavia, ciò che è anche importante è convalidare le informazioni che sono il cuore dell’applicazione, ovvero DATABASE.

Consideriamo un’applicazione bancaria in cui un utente effettua transazioni. Ora, dal punto di vista del test del database o del test del database, le cose sono importanti:

L’applicazione memorizza le informazioni sulla transazione nel database dell’applicazione e le visualizza correttamente all’utente.
Nessuna informazione viene persa durante il processo.
Nessuna informazione sulle operazioni parzialmente eseguite o interrotte viene salvata dall’applicazione.
A nessun individuo non autorizzato è consentito accedere alle informazioni dell’utente.

Per garantire tutti questi obiettivi di cui sopra, dobbiamo utilizzare la convalida dei dati o il test dei dati.

Differenze tra test dell’interfaccia utente e test dei dati

Test dell'interfaccia utente vs test dei dati

Test dell’interfaccia utente	Database o test dei dati
Questo tipo di test è anche noto come test dell’interfaccia utente grafica o test front-end.	Questo tipo di test è anche noto come Backend Testing o test dei dati.
Questo tipo di test si occupa principalmente di tutti gli elementi testabili che sono aperti all’utente per la visualizzazione e l’interazione come moduli, presentazioni, grafici, menu e report, ecc. (creati tramite VB, VB.net, VC++, Delphi – Front- strumenti finali)	Questo tipo di test si occupa principalmente di tutti gli elementi testabili che sono generalmente nascosti all’utente per la visualizzazione. Questi includono processi interni e archiviazione come Assembly, DBMS come Oracle, SQL Server, MYSQL, ecc.
Questo tipo di test include la convalida del filecaselle di testoselezionare i menu a discesacalendari e pulsantiNavigazione della paginavisualizzazione delle immaginiAspetto dell’applicazione complessiva	Questo tipo di test prevede la convalida di:lo schematabelle di databasecolonnechiavi e indicitrigger di procedure memorizzateconvalide del server di databaseconvalidare la duplicazione dei dati
Il tester deve conoscere a fondo i requisiti aziendali, nonché l’utilizzo degli strumenti di sviluppo e l’utilizzo di framework e strumenti di automazione.	Per essere in grado di eseguire test di back-end, il tester deve avere una solida esperienza nel server di database e nei concetti di Structured Query Language.

ANNO DOMINI

Tipi di test del database

I 3 tipi di test del database sono

Collaudo strutturale
Test Funzionale
Test non funzionali

In questo tutorial sul test del database, esamineremo ogni tipo e i suoi sottotipi uno per uno.

Test di database strutturali

Structural Database Testing è una tecnica di test del database che convalida tutti gli elementi all’interno del repository di dati che vengono utilizzati principalmente per l’archiviazione dei dati e che non possono essere manipolati direttamente dagli utenti finali. Anche la convalida dei server di database è una considerazione importante nei test strutturali dei database. Per completare con successo questo test è necessaria la padronanza delle query SQL.

Cos’è il test dello schema?

Il test dello schema nel test del database convalida vari formati di schema associati al database e verifica se i formati di mappatura di tabelle/viste/colonne sono compatibili con i formati di mappatura dell’interfaccia utente. Lo scopo principale del test dello schema è garantire che la mappatura dello schema tra front-end e back-end sia simile. Pertanto, viene anche definito test di mappatura.

Discutiamo i punti di controllo più importanti per il test dello schema.

Convalida dei vari formati di schema associati ai database. Molte volte il formato di mappatura della tabella potrebbe non essere compatibile con il formato di mappatura presente a livello di interfaccia utente dell’applicazione.
È necessaria una verifica nel caso di tabelle/viste/colonne non mappate.
È inoltre necessario verificare se i database eterogenei in un ambiente sono coerenti con la mappatura generale dell’applicazione.

Diamo anche un’occhiata ad alcuni degli interessanti strumenti di test del database per la convalida degli schemi di database.

DBUnit integrato con Ant è molto adatto per i test di mappatura.
SQL Server consente ai tester di poter controllare ed interrogare lo schema del Database scrivendo semplici query e non tramite codice.

Ad esempio, se gli sviluppatori desiderano modificare la struttura di una tabella o eliminarla, il tester vorrebbe assicurarsi che tutte le stored procedure e le viste che utilizzano tale tabella siano compatibili con la modifica specifica. Un altro esempio potrebbe essere che se i tester desiderano verificare le modifiche allo schema tra 2 database, possono farlo utilizzando semplici query.

Tabella del database, test delle colonne

Esaminiamo i vari controlli per il test del database e delle colonne.

Se la mappatura dei campi e delle colonne del database nel back-end è compatibile con quelle mappature nel front-end?
Convalida della lunghezza e della convenzione di denominazione dei campi e delle colonne del database come specificato dai requisiti.
Convalida della presenza di tabelle/colonne di database inutilizzate/non mappate.
Convalida della compatibilità del

tipo di dati
lunghezze di campo

delle colonne del database di back-end con quella di quelle presenti nel front-end dell’applicazione.

Se i campi del database consentono all’utente di fornire gli input utente desiderati come richiesto dai documenti di specifica dei requisiti aziendali.

Test di chiavi e indici

Controlli importanti per chiavi e indici –

Verificare se il richiesto

Chiave primaria
Chiave esterna

sono stati creati vincoli sulle tabelle richieste.

Controlla se i riferimenti per le chiavi esterne sono validi.
Verificare se il tipo di dati della chiave primaria e le corrispondenti chiavi esterne sono gli stessi nelle due tabelle.
Verificare se le convenzioni di denominazione richieste sono state seguite per tutte le chiavi e gli indici.
Controlla la dimensione e la lunghezza dei campi e degli indici richiesti.
Se il richiesto

Indici cluster
Indici non cluster

sono stati creati nelle tabelle richieste come specificato dai requisiti aziendali.

Test delle procedure memorizzate

Test importanti per verificare le stored procedure sono:

Se il team di sviluppo ha adottato le convenzioni standard di codifica A) richieste e B) la gestione delle eccezioni e degli errori. Per tutte le stored procedure per tutti i moduli per l’applicazione in prova.
Se il team di sviluppo ha coperto tutte le condizioni/loop applicando i dati di input richiesti all’applicazione sottoposta a test?
Se il team di sviluppo ha applicato correttamente l’operazione TRIM ogni volta che i dati vengono recuperati dalle tabelle richieste nel database?
Se l’esecuzione manuale della stored procedure fornisce all’utente finale il risultato richiesto?
Se l’esecuzione manuale della stored procedure garantisce che i campi della tabella vengano aggiornati come richiesto dall’applicazione sottoposta a test?
Se l’esecuzione delle stored procedure consente l’invocazione implicita dei trigger richiesti?
Convalida della presenza di eventuali stored procedure non utilizzate.
Convalida per la condizione Allow Null che può essere eseguita a livello di database.
Convalida del fatto che tutte le stored procedure e le funzioni sono state eseguite correttamente quando il database sottoposto a test è vuoto.
Convalida dell’integrazione complessiva dei moduli di stored procedure secondo i requisiti dell’applicazione in prova.

Alcuni degli utili strumenti di test del database per testare le stored procedure sono LINQ, SP Test tool ecc.

Prova di innesco

Se le convenzioni di codifica richieste sono state seguite durante la fase di codifica dei Trigger?
Verificare se i trigger eseguiti per le rispettive transazioni DML hanno soddisfatto le condizioni richieste.
Se il trigger aggiorna correttamente i dati una volta che sono stati eseguiti?
Convalida della funzionalità di trigger di aggiornamento/inserimento/eliminazione richiesta nell’ambito dell’applicazione sottoposta a test.

Convalide del server database

Verificare le configurazioni del server del database come specificato dai requisiti aziendali.
Verificare l’autorizzazione dell’utente richiesto per eseguire solo i livelli di azioni richiesti dall’applicazione.
Verificare che il server del database sia in grado di soddisfare le esigenze del numero massimo consentito di transazioni utente come specificato dalle specifiche dei requisiti aziendali.

Test funzionale del database

Il test funzionale del database è un tipo di test del database utilizzato per convalidare i requisiti funzionali di un database dal punto di vista dell’utente finale. L’obiettivo principale del test del database funzionale è verificare se le transazioni e le operazioni eseguite dagli utenti finali che sono correlate al database funzionano come previsto o meno.

Di seguito sono riportate le condizioni di base che devono essere osservate per le convalide del database.

Se il campo è obbligatorio pur consentendo valori NULL su quel campo?
Se la lunghezza di ciascun campo è di dimensioni sufficienti?
Se tutti i campi simili hanno gli stessi nomi nelle tabelle?
Se sono presenti campi calcolati nel database?

Questo particolare processo è la convalida delle mappature dei campi dal punto di vista dell’utente finale. In questo particolare scenario, il tester eseguirà un’operazione a livello di database e quindi passerà all’elemento dell’interfaccia utente pertinente per osservare e convalidare se le opportune convalide del campo sono state eseguite o meno.

Dovrebbe essere eseguita anche la condizione viceversa per cui la prima operazione viene eseguita dal tester sull’interfaccia utente e quindi la stessa viene convalidata dal back-end.

Controllo dell’integrità e della coerenza dei dati

I successivi controlli sono importanti

Se i dati sono logicamente ben organizzati?
Se i dati memorizzati nelle tabelle sono corretti e conformi ai requisiti aziendali?
Se sono presenti dati non necessari nell’applicazione sottoposta a test?
Se i dati sono stati archiviati secondo il requisito rispetto ai dati che sono stati aggiornati dall’interfaccia utente?
Se le operazioni TRIM eseguite sui dati prima di inserire i dati nel database in prova?
Se le transazioni sono state eseguite secondo le specifiche dei requisiti aziendali e se i risultati sono corretti o meno?
Se i dati sono stati correttamente impegnati se la transazione è stata eseguita con successo?
Se il rollback dei dati è stato eseguito correttamente se la transazione non è stata eseguita correttamente dall’utente finale?
Se è stato eseguito il rollback dei dati se la transazione non è stata eseguita correttamente e più database eterogenei sono stati coinvolti nella transazione in questione?
Se tutte le transazioni sono state eseguite utilizzando le procedure di progettazione richieste come specificato dai requisiti aziendali del sistema?

Le convalide delle credenziali di accesso e di sicurezza dell’utente devono prendere in considerazione quanto segue.

Se l’applicazione impedisce all’utente di procedere ulteriormente nell’applicazione in caso di a

nome utente non valido ma password valida
nome utente valido ma password non valida.
nome utente e password non validi.

Se all’utente è consentito eseguire solo quelle operazioni specifiche specificate dai requisiti aziendali?
Se i dati sono protetti da accessi non autorizzati?
Se sono stati creati diversi ruoli utente con autorizzazioni diverse?
Se tutti gli utenti hanno i livelli di accesso richiesti sul database specificato come richiesto dalle specifiche aziendali?
Verifica che i dati sensibili come password, numeri di carte di credito siano crittografati e non archiviati come testo normale nel database. È buona norma assicurarsi che tutti gli account dispongano di password complesse e non facili da indovinare.

Test non funzionali

I test non funzionali nel contesto del test del database possono essere classificati in varie categorie come richiesto dai requisiti aziendali. Questi possono essere test di carico, stress test, test di sicurezza , test di usabilità e test di compatibilità e così via. Il test di carico, così come lo stress test, che può essere raggruppato sotto la gamma di test delle prestazioni, ha due scopi specifici quando si tratta del ruolo dei test non funzionali.

Quantificazione del rischio – La quantificazione del rischio aiuta le parti interessate ad accertare i vari requisiti del tempo di risposta del sistema sotto i livelli di carico richiesti. Questo è l’intento originale di qualsiasi attività di garanzia della qualità . Dobbiamo notare che i test di carico non mitigano il rischio direttamente, ma attraverso i processi di identificazione e quantificazione del rischio, presentano opportunità correttive e uno slancio per la riparazione che mitigherà il rischio.

Requisiti minimi dell’attrezzatura di sistema – La configurazione minima del sistema che consentirà al sistema di soddisfare le aspettative di prestazioni formalmente dichiarate delle parti interessate. In questo modo è possibile ridurre al minimo l’hardware e il software estranei e il relativo costo di proprietà. Questo particolare requisito può essere classificato come requisito generale di ottimizzazione aziendale.

Prova di carico

Lo scopo di qualsiasi prova di carico dovrebbe essere chiaramente compreso e documentato. I seguenti tipi di configurazioni sono indispensabili per i test di carico .

Le transazioni utente utilizzate più di frequente hanno il potenziale per influire sulle prestazioni di tutte le altre transazioni se non sono efficienti.
Nella suite di test finale dovrebbe essere inclusa almeno una transazione utente non di modifica, in modo che le prestazioni di tali transazioni possano essere differenziate da altre transazioni più complesse.
Dovrebbero essere incluse le transazioni più importanti che facilitano gli obiettivi fondamentali del sistema, poiché il fallimento sotto un carico di queste transazioni ha, per definizione, l’impatto maggiore.
Dovrebbe essere inclusa almeno una transazione modificabile in modo che le prestazioni di tali transazioni possano essere differenziate da altre transazioni.
Tempo di risposta ottimale con un numero enorme di utenti virtuali per tutti i requisiti potenziali.
Tempi effettivi per il recupero di vari record.

Importanti strumenti di test di carico sono LoadRunner Professional , win runner e JMeter .

Cos’è lo stress test del database?

Lo stress test del database è un metodo di test utilizzato per sottoporre a stress test il sistema di database con un carico pesante tale da fallire a un certo punto. Questo aiuta a identificare il punto di rottura del sistema di database. Richiede una pianificazione e sforzi adeguati per evitare un uso eccessivo delle risorse. Lo stress test dei dati è anche noto come test tortuoso o test di fatica.

Importanti strumenti di stress test sono LoadRunner Professional e JMeter .

Problemi più comuni che si verificano durante il test del database

Potrebbe essere coinvolta una quantità significativa di sovraccarico per determinare lo stato delle transazioni del database

Soluzione: la pianificazione e la tempistica complessiva del processo dovrebbero essere organizzate in modo tale da evitare problemi basati su tempi e costi.

I nuovi dati di test devono essere progettati dopo aver ripulito i vecchi dati di test.

Soluzione: dovrebbero essere disponibili un piano e una metodologia preliminari per la generazione dei dati di test.

È necessario un generatore SQL per trasformare i validatori SQL al fine di garantire che le query SQL siano adatte a gestire i casi di test del database richiesti.

Soluzione: la manutenzione delle query SQL e il loro aggiornamento continuo è una parte significativa del processo di test complessivo che dovrebbe far parte della strategia di test complessiva .

Il suddetto prerequisito garantisce che l'impostazione della procedura di test del database possa essere costosa e richiedere molto tempo.

Soluzione: dovrebbe esserci un buon equilibrio tra la qualità e la durata complessiva del programma del progetto.

Il test del database richiede molta esperienza ed è un lavoro molto noioso

Realtà: il test del database efficace ed efficiente nel test del software fornisce stabilità funzionale a lungo termine all’intera applicazione, quindi è necessario impegnarsi a fondo.

Il test del database aggiunge ulteriore collo di bottiglia di lavoro

Realtà: al contrario, il test del database aggiunge più valore al lavoro complessivo scoprendo problemi nascosti e contribuendo così in modo proattivo a migliorare l’applicazione complessiva.

Il test del database rallenta il processo di sviluppo complessivo

Realtà: una quantità significativa di test del database aiuta nel miglioramento generale della qualità per l’applicazione del database.

Il test del database potrebbe essere eccessivamente costoso

Realtà: qualsiasi spesa per il test del database è un investimento a lungo termine che porta alla stabilità e robustezza a lungo termine dell’applicazione. Pertanto è necessaria la spesa per il test del database o il test SQL.

Migliori pratiche

Tutti i dati, inclusi i metadati e i dati funzionali, devono essere convalidati in base alla loro mappatura da parte dei documenti di specifica dei requisiti.
La verifica dei dati di test che sono stati creati da/in consultazione con il team di sviluppo deve essere convalidata.
Convalida dei dati di output utilizzando sia procedure manuali che automatizzate.
Implementazione di varie tecniche come la tecnica di rappresentazione grafica dell’effetto causa, la tecnica di partizionamento dell’equivalenza e la tecnica di analisi del valore limite per la generazione delle condizioni dei dati di test richieste.
È inoltre necessario convalidare le regole di convalida dell’integrità referenziale per le tabelle del database richieste.
La selezione dei valori predefiniti della tabella per la convalida sulla coerenza del databaseèun concetto molto importante Se gli eventi di registro sono stati aggiunti correttamente nel database per tutti gli eventi di accesso richiesti
I lavori pianificati vengono eseguiti in modo tempestivo?
Eseguire il backup tempestivo del database.