Una risposta completa a questa domanda sarebbe molto lunga. Proverò a menzionare i punti principali.
Per separare le preoccupazioni, potresti esaminare i test per:
A - Convalida la progettazione del database.
B - Convalida che i programmi interagiscono correttamente con il database.
La convalida del progetto del database dovrebbe essere eseguita dalle persone che hanno progettato il database. Gli sviluppatori (mentre i test unitari) dovrebbero preoccuparsi maggiormente della parte (B). La differenza principale che vedo tra i due tipi di test è gli strumenti utilizzati. Per (A), usereste un ambiente indipendente dal codice del progetto, mentre su (B) userete ovviamente il codice del progetto. Nel testo seguente, mescolerò entrambi.
Per rispondere alle tue specifiche domande:
Column domain value rules
Ogni colonna ha un tipo di dati associato. Ogni colonna deve essere convalidata in base alle regole aziendali per dimostrare che rappresenta il tipo di dati corretto. I problemi possono verificarsi se il tipo di dati della colonna non è compatibile con i requisiti aziendali o se il codice utilizza un tipo di dati diverso da come è definito nel database.
Ad esempio:
-
Se la colonna è definita come int piccola, non si dovrebbe essere in grado di memorizzare il testo al suo interno. Questo è un test importante specialmente quando le colonne sono opzionali, poiché potrebbero passare inosservate fino a quando qualcuno inserisce effettivamente alcuni dati in esso.
-
Potresti memorizzare un valore negativo in una colonna in cui l'azienda richiede che ciò accada?
Column default value rules
Alcune colonne sono associate a una specifica di valore predefinita nel DDL (Data Def. Language) dove se durante l'inserimento l'inserto non fornisce un valore, il database assumerà il valore predefinito. Questo può essere verificato non passando il valore e osservando il valore del risultato memorizzato nel database. Questo test può anche includere il controllo di colonne Nullable. Questo richiede raramente un test poiché può essere verificato da DDL a meno che non venga creato un indice univoco sulla colonna.
Value existence rules
A quanto mi risulta, verificate che i dati inseriti o aggiornati vengano visualizzati come previsto nel database.
Row value rules
Non sono chiaro su cosa significhi esattamente questo.
Size rules
Ogni colonna ha una dimensione nel database in base a come è definita in DDL. si desidera assicurarsi che qualsiasi valore che soddisfi i requisiti (immesso nella GUI o risultante come output di un calcolo) venga archiviato correttamente nella colonna. Ad esempio, un tipo di dati Small Integer non consente di memorizzare un valore di 5 miliardi. Inoltre, un nome definito come VARCHAR2 (30) non può contenere 40 caratteri, quindi le regole aziendali devono essere molto chiare qui, specialmente quando la colonna viene utilizzata per aggregare i dati. Vuoi testare cosa succede in tali situazioni.
guidelines on how/where to begin
Un modo per farlo è quello di elaborare un piano di test. Si desidera assicurarsi di utilizzare la versione corretta delle specifiche (quali documenti dei requisiti e casi d'uso) e del software. È inoltre necessario coordinare questi test con i test effettuati da Unit Testing (se presenti). È possibile trovare test duplicati che non è necessario eseguire di nuovo. Si desidera prendere una copia del database prima di eseguire il test in modo da poter ripetere un test specifico se è necessario. Il DBA può aiutarti con questo. È inoltre necessario verificare con il proprio team come documentare i test di tesi e verificare con essi il campo di prova. È possibile suddividere il database in parti logiche e iniziare separatamente il test di ciascuna parte logica. Il processo di test potrebbe iniziare studiando il DDL del database e verificando che le colonne siano definite correttamente come richiesto dall'azienda. Dovresti utilizzare il software dell'applicazione e non altri strumenti per eseguire la maggior parte dei test. Ad esempio domanda la seguente:
-
La colonna dovrebbe essere del tipo definito (nessun punto nel creare un nome come Int).
-
Le dimensioni sono compatibili con i requisiti aziendali?
-
Tutte le colonne nei requisiti aziendali sono presenti nel database?
-
Le colonne null sono davvero facoltative?
-
ecc.
Successivamente, potresti progettare casi di test per testare quanto sopra. Potresti usare la GUI per fare la maggior parte dei test.
Ci sono altri importanti test di database che non hai menzionato. Quelli si occupano di:
1 - Verifica che le chiavi primarie siano davvero uniche dal punto di vista del business.
2 - Test di indici univoci (diversi dal PK) sono davvero unici dal punto di vista del business.
3 - Verifica dei vincoli di chiave esterna.
4 - Verifica cosa succede quando una riga viene cancellata e il suo effetto sulle righe correlate.
5 - Altri test relativi a costrutti di database speciali come CHEKC, Trigger se esistono.
6 - Correggere la normalizzazione della tabella e le colonne normalizzate mantengono i valori corretti.
Quanto sopra non è un elenco completo ma dovrebbe iniziare.