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 stiano interagendo correttamente con il database.
La convalida della progettazione del database deve essere eseguita dalla persona o dalle persone che hanno progettato il database. Gli sviluppatori (mentre test unitari) dovrebbero preoccuparsi maggiormente della parte (B). La differenza principale che vedo tra i due tipi di test è gli strumenti utilizzati. Per (A), useresti un ambiente indipendente dal codice del progetto, mentre su (B) useresti ovviamente il codice del progetto. Nel testo seguente, mescolerò entrambi.
Per rispondere alle tue domande specifiche:
Regole del valore del dominio della colonna
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. Potrebbero sorgere problemi 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.
Per esempio:
Se la colonna è definita come int piccolo, non dovresti essere in grado di memorizzare il testo al suo interno. Questo è un test importante specialmente quando le colonne sono opzionali, dal momento che potrebbe passare inosservato fino a quando qualcuno non inserisce effettivamente alcuni dati al suo interno.
Potresti memorizzare un valore negativo in una colonna in cui l'attività richiede che ciò accada?
Regole del valore predefinito della colonna
Alcune colonne sono associate a una specifica del valore predefinito nel DDL (Data Def. Language) in cui se durante l'inserimento l'inserimento non fornisce un valore, il database assumerà il valore predefinito. Questo può essere testato non passando il valore e osservando il valore del risultato archiviato dal database. Questo test può anche includere il controllo delle colonne Nullable. Ciò richiede raramente un test poiché può essere verificato da DDL a meno che non venga creato un indice univoco sulla colonna.
Valori delle regole di esistenza
A quanto ho capito, verifichi che i dati inseriti o aggiornati mostrino come previsto nel database.
Regole del valore di riga
Non sono chiaro su cosa significhi esattamente questo.
Regole di dimensione
Ogni colonna ha una dimensione nel database in base alla sua definizione in DDL. si desidera assicurarsi che qualsiasi valore che soddisfi i requisiti (o immesso nella GUI del modulo o risultante come output di un calcolo) venga archiviato correttamente nella colonna. Ad esempio, un tipo di dati Numero intero piccolo 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 provare cosa succede in tali situazioni.
linee guida su come / dove iniziare
Un modo per farlo è quello di elaborare un piano di test. Desideri assicurarti di utilizzare la versione corretta delle specifiche (come documenti sui requisiti e casi d'uso) e del software. È inoltre necessario coordinare questi test con i test effettuati da Unit Testing (se presente). Potresti trovare test duplicati che non devi ripetere. Volete prendere una copia del database prima del test in modo da poter ripetere un test specifico, se necessario. Il DBA può aiutarti in questo. È inoltre necessario verificare con il proprio team come documentare questi test e verificare l'ambito dei test con loro. È possibile suddividere il database in parti logiche e iniziare il test di ciascuna parte logica separatamente. 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 quanto segue:
La colonna dovrebbe essere del tipo definito (non ha senso fare un nome come Int)?
Le dimensioni sono compatibili con i requisiti aziendali?
Tutte le colonne dei requisiti aziendali sono state trovate nel database?
Le colonne null sono davvero opzionali?
eccetera.
Successivamente, è possibile progettare casi di test per testare quanto sopra. È possibile utilizzare la GUI per eseguire la maggior parte dei test.
Esistono altri importanti test del database che non hai menzionato. Quelli si occupano di:
1 - Test che le chiavi primarie sono davvero uniche dal punto di vista aziendale.
2 - Test che indici unici (diversi dal PK) sono davvero unici dal punto di vista aziendale.
3 - Test dei vincoli di chiave esterna funzionano.
4 - Testare cosa succede quando una riga viene eliminata e il suo effetto sulle righe correlate.
5 - Altri test riguardanti costrutti di database speciali come CHEKC, Trigger se esistono.
6 - Corretta normalizzazione della tabella e che le colonne normalizzate contengono valori corretti.
Quanto sopra non è un elenco completo ma dovrebbe iniziare.