Esercitazione sul test del database (dati).

Alla GUI viene solitamente 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 delle transazioni. Ora, dal punto di vista del test del database o del test del DB, le cose importanti sono:

1. L'applicazione memorizza le informazioni sulla transazione nel database dell'applicazione e le visualizza correttamente all'utente.
2. Nessuna informazione viene persa nel processo.
3. Nessuna informazione sulle operazioni parzialmente eseguite o interrotte viene salvata dall'applicazione.
4. Nessun individuo non autorizzato è autorizzato ad 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	Test del database o dei dati
Questo tipo di test è noto anche come test dell'interfaccia utente grafica o test front-end.	Questo tipo di test è noto anche come test backend o test dei dati.
Questo tipo di test riguarda principalmente 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 – Strumenti front-end)	Questo tipo di test riguarda principalmente tutti gli elementi testabili che generalmente sono nascosti all'utente per il pubblico. Questi includono processi interni e archiviazione come Assembly, Tipo DBMS Oracle, SQL Server, MYSQL, ecc.
Questo tipo di test include la convalida di caselle di testo seleziona i menu a discesa calendari e pulsanti Navigazione della pagina visualizzazione delle immagini Aspetto grafico dell'applicazione complessiva	Questo tipo di test prevede la convalida: lo schema tabelle di database colonne chiavi e indici trigger di procedure memorizzate convalide del server di database convalidare la duplicazione dei dati
Il tester deve avere una conoscenza approfondita dei requisiti aziendali, nonché dell'utilizzo degli strumenti di sviluppo e dell'utilizzo di framework e strumenti di automazione.	Per essere in grado di eseguire test di backend, il tester deve avere una solida conoscenza del server di database e dei concetti di Structured Query Language.

Tipi di test del database

I 3 tipi di test del database sono

1. Test strutturali
2. Test di funzionalità
3. Test non funzionali

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

Cos'è il test dello schema?

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.

Parliamo dei checkpoint più importanti per il test dello schema.

1. Validazione 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.
2. È necessaria una verifica nel caso di tabelle/viste/colonne non mappate.
3. È inoltre necessario verificare se i database eterogenei in un ambiente siano coerenti con la mappatura complessiva dell'applicazione.

Diamo anche un'occhiata ad alcuni degli interessanti strumenti di test del database per convalidare gli schemi di database.

• DBUnit integrato con Ant è molto adatto per i test di mappatura.
• SQL Server consente ai tester di poter verificare 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 vorrà garantire che tutte le procedure memorizzate e le visualizzazioni che utilizzano quella tabella siano compatibili con la particolare modifica. 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 vari controlli per il test di database e colonne.

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

• tipo di dati
• lunghezze di campo

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

5. 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 –

1. Controlla se è richiesto

• Chiave primaria
• chiave esterna

sono stati creati dei vincoli sulle tabelle richieste.

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

• Clusterindici ed
• No Clusterindici ed

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

Test delle procedure memorizzate

Test importanti per verificare le procedure memorizzate sono:

1. 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 procedure memorizzate per tutti i moduli per l'applicazione in prova.
2. Il team di sviluppo ha coperto tutte le condizioni/i cicli applicando i dati di input richiesti all'applicazione sottoposta a test?
3. Il team di sviluppo ha applicato correttamente l'operazione TRIM ogni volta che i dati vengono recuperati dalle tabelle richieste nel database?
4. L'esecuzione manuale della Stored Procedure fornisce all'utente finale il risultato richiesto?
5. L'esecuzione manuale della Stored Procedure garantisce che i campi della tabella vengano aggiornati come richiesto dall'applicazione sottoposta a test?
6. Se l'esecuzione delle Stored Procedure consente l'invocazione implicita dei trigger richiesti?
7. Convalida della presenza di eventuali stored procedure non utilizzate.
8. Convalida per la condizione Consenti null che può essere eseguita a livello di database.
9. Convalida del fatto che tutte le Stored Procedure e Funzioni sono state eseguite con successo quando il Database sotto test è vuoto.
10. Convalida dell'integrazione complessiva dei moduli di procedura memorizzata secondo i requisiti dell'applicazione in prova.

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

Test di attivazione

1. Sono state seguite le convenzioni di codifica richieste durante la fase di codifica dei Trigger?
2. Verificare se i trigger eseguiti per le rispettive transazioni DML hanno soddisfatto le condizioni richieste.
3. Il trigger aggiorna correttamente i dati una volta eseguiti?
4. La convalida dell'aggiornamento/inserimento/eliminazione richiesto attiva la funzionalità nell'ambito dell'applicazione sotto test.

Convalide del server database

1. Controllare le configurazioni del server database come specificato dai requisiti aziendali.
2. Verificare l'autorizzazione dell'utente richiesto per eseguire solo i livelli di azioni richiesti dall'applicazione.
3. 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 del database funzionale

Test del database funzionale è 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 funzionale del database è verificare se le transazioni e le operazioni eseguite dagli utenti finali correlate al database funzionano come previsto o meno.

Di seguito sono riportate le condizioni di base che devono essere rispettate per la convalida del database.

• Il campo è obbligatorio ma consente valori NULL in quel campo?
• Se la lunghezza di ciascun campo è di dimensioni sufficienti?
• Tutti i campi simili hanno gli stessi nomi nelle tabelle?
• Sono presenti campi calcolati nel database?

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

Dovrebbe essere fatta anche la condizione viceversa per cui la prima operazione viene effettuata dal tester sull'interfaccia utente, e poi la stessa viene validata dal back-end.

Controllo dell'integrità e della coerenza dei dati

I seguenti controlli sono importanti

1. Se i dati sono logicamente ben organizzati?
2. Se i dati archiviati nelle tabelle sono corretti e conformi ai requisiti aziendali?
3. Sono presenti dati non necessari nell'applicazione sottoposta a test?
4. Se i dati sono stati archiviati secondo i requisiti relativi ai dati aggiornati dall'interfaccia utente?
5. Se le operazioni TRIM sono state eseguite sui dati prima di inserirli nel database in prova?
6. Se le transazioni sono state eseguite secondo le specifiche dei requisiti aziendali e se i risultati sono corretti o meno?
7. Se i dati sono stati correttamente impegnati se la transazione è stata eseguita con successo?
8. Se il rollback dei dati è stato eseguito correttamente se la transazione non è stata eseguita correttamente dall'utente finale?
9. Se i dati sono stati ripristinati se la transazione non è stata eseguita correttamente e nella transazione in questione sono stati coinvolti più database eterogenei?
10. Se tutte le transazioni sono state eseguite utilizzando le procedure di progettazione richieste come specificato dai requisiti aziendali del sistema?

Accesso e sicurezza utente

Le convalide delle credenziali di accesso e di sicurezza dell'utente devono tenere in considerazione i seguenti aspetti.

1. 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 non valido e password non valida.

2. Se all'utente è consentito eseguire solo quelle operazioni specifiche specificate dai requisiti aziendali?
3. I dati sono protetti da accessi non autorizzati?
4. Sono presenti ruoli utente diversi creati con autorizzazioni diverse?
5. Tutti gli utenti hanno richiesto i livelli di accesso al database specificato come richiesto dalle specifiche aziendali?
6. Controllare che i dati sensibili come password, numeri di carte di credito siano criptati e non archiviati come testo normale nel database. È una buona norma assicurarsi che tutti gli account abbiano password complesse e non facilmente indovinabili.

Test non funzionali

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. I test di carico, così come i test di stress, che possono essere raggruppati nella gamma dei test delle prestazioni, servono a 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 di tempo di risposta del sistema sotto i livelli di carico richiesti. Questo è l'intento originale di any garanzia della qualità compito. 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 attenuerà il rischio.

Requisiti minimi di attrezzatura di sistema– La configurazione minima del sistema che consentirà al sistema di soddisfare le aspettative di performance formalmente dichiarate dagli stakeholder. In modo che hardware, software e costi di proprietà associati possano essere ridotti al minimo. Questo particolare requisito può essere categorizzato come requisito di ottimizzazione aziendale complessiva.

Caricare i test

Lo scopo di qualsiasi test di carico deve essere chiaramente compreso e documentato. I seguenti tipi di configurazioni sono obbligatori per test di carico.

1. Le transazioni utente utilizzate più frequentemente possono influire sulle prestazioni di tutte le altre transazioni se non sono efficienti.
2. Almeno una transazione utente non modificabile dovrebbe essere inclusa nella suite di test finale, in modo che le prestazioni di tali transazioni possano essere differenziate da altre transazioni più complesse.
3. Dovrebbero essere incluse le transazioni più importanti che facilitano gli obiettivi fondamentali del sistema, poiché il fallimento sotto il carico di queste transazioni ha, per definizione, l’impatto maggiore.
4. A questo scopo è necessario includere almeno una transazione modificabile performance di tali operazioni possono essere differenziate da altre operazioni.
5. Tempo di risposta ottimale con un numero enorme di utenti virtuali per tutti i potenziali requisiti.
6. Tempi effettivi per il recupero di vari record.

Importanti strumenti di test del carico sono LoadRunner Professional, vinci corridore e JMeter.

Importanti strumenti di stress test sono LoadRunner Professional e JMeter.

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

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

Soluzione: La pianificazione e la tempistica complessiva del processo dovrebbero essere organizzate in modo tale che non emergano problemi basati su tempi e costi.

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

Soluzione: Dovrebbero essere a portata di mano un piano e una metodologia preliminari per la generazione dei dati di test.

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.

Soluzione: La manutenzione delle query SQL e il loro aggiornamento continuo rappresentano una parte significativa del processo di test complessivo che dovrebbe far parte dell'insieme strategia di prova.

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

Soluzione: Dovrebbe esserci un buon equilibrio tra la qualità e la durata complessiva della pianificazione del progetto.

Miti o idee sbagliate relative al test del database

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

La realtà: Il test efficace ed efficiente del database nel test del software fornisce stabilità funzionale a lungo termine all'applicazione complessiva, pertanto è necessario dedicare un duro lavoro alle sue spalle.

Database testing adds extra work bottleneck

La 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.

Database testing slows down the overall development process

La realtà: Una quantità significativa di test del database contribuisce al miglioramento complessivo della qualità dell'applicazione del database.

Database testing could be excessively costly

La realtà: Qualsiasi spesa per il test del database è un investimento a lungo termine che porta alla stabilità e alla robustezza a lungo termine dell'applicazione. Quindi le spese per il test del database o SQL Il test è necessario.

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.
• Verifica del dati di test che è stato creato da/in consultazione con il team di sviluppo deve essere convalidato.
• Validazione dei dati di output utilizzando sia procedure manuali che automatizzate.
• Implementazione di varie tecniche come la tecnica del grafico causa-effetto, la tecnica di partizionamento dell'equivalenza e la tecnica di analisi dei valori limite per la generazione delle condizioni dei dati di test richieste.
• È necessario convalidare anche le regole di convalida dell'integrità referenziale per le tabelle del database richieste.
• La selezione dei valori di tabella predefiniti per la convalida della coerenza del database è un concetto molto importante Se gli eventi di registro sono stati aggiunti con successo nel database per tutti gli eventi di accesso richiesti
• I lavori pianificati vengono eseguiti in modo tempestivo?
• Effettuare il backup tempestivo del database.

Controlla anche- Domande e risposte all'intervista sui test del database