Une réponse complète à cette question serait très longue. J'essaierai de mentionner les points principaux.
Pour séparer les préoccupations, vous pouvez envisager des tests pour:
A - Validez la conception de la base de données.
B - Validez que le ou les programmes interagissent correctement avec la base de données.
La validation de la conception de la base de données doit être effectuée par la ou les personnes qui ont conçu la base de données. Les développeurs (pendant les tests unitaires) devraient se préoccuper davantage de la partie (B). La principale différence que je vois entre les deux types de tests est les outils utilisés. Pour (A), vous utiliseriez un environnement indépendant du code du projet, tandis que sur (B) vous utiliseriez bien sûr le code du projet. Dans le texte suivant, je mélangerai les deux.
Pour répondre à vos questions spécifiques:
Règles de valeur de domaine de colonne
Chaque colonne a un type de données associé. Chaque colonne doit être validée par rapport aux règles métier pour prouver qu'elle représente le type de données correct. Des problèmes peuvent survenir si le type de données de la colonne n'est pas compatible avec les besoins de l'entreprise ou si le code utilise un type de données différent de celui défini dans la base de données.
Par exemple:
Si la colonne est définie comme petit int, vous ne devriez pas pouvoir y stocker de texte. Il s'agit d'un test important, spécialement lorsque les colonnes sont facultatives, car il peut passer inaperçu jusqu'à ce que quelqu'un y entre des données.
Pourriez-vous stocker une valeur négative dans une colonne où l'entreprise exige que cela se produise?
Règles de valeur par défaut des colonnes
Certaines colonnes sont associées à une spécification de valeur par défaut dans le DDL (Data Def. Language) où si lors de l'insertion l'insert ne fournit pas de valeur, la base de données prendra la valeur par défaut. Cela peut être testé en ne transmettant pas la valeur et en observant la valeur de résultat que la base de données stocke. Ce test peut également inclure la vérification des colonnes Nullable. Cela nécessite rarement un test car il peut être vérifié à partir de DDL à moins qu'un index unique ne soit construit sur la colonne.
Règles d'existence de valeur
Si je comprends bien, vous vérifiez que les données insérées ou mises à jour s'affichent comme prévu dans la base de données.
Règles de valeur de ligne
Je ne sais pas exactement ce que cela signifie exactement.
Règles de taille
Chaque colonne a une taille dans la base de données en fonction de la façon dont elle est définie dans DDL. vous voulez vous assurer que toute valeur qui correspond aux exigences (soit sous forme de GUI entré ou résultant en sortie d'un calcul) soit stockée correctement dans la colonne. Par exemple, un type de données Small Integer ne vous permet pas de stocker une valeur de 5 milliards. De plus, un nom défini comme VARCHAR2 (30) ne peut pas contenir 40 caractères, les règles métier doivent donc être très claires ici, spécialement lorsque la colonne est utilisée pour agréger des données. Vous voulez tester ce qui se passe dans de telles situations.
des directives sur la façon et le début
Une façon de procéder consiste à élaborer un plan de test. Vous voulez vous assurer que vous utilisez la version correcte des spécifications (telles que les documents d'exigences et les cas d'utilisation) et du logiciel. Vous devez également coordonner ces tests avec les tests effectués par Unit Testing (le cas échéant). Vous pouvez trouver des tests en double que vous n'avez pas besoin d'effectuer à nouveau. Vous souhaitez prendre une copie de la base de données avant le test afin de pouvoir répéter un test spécifique si vous en avez besoin. Le DBA peut vous aider avec cela. Vous devez également vérifier avec votre équipe comment documentent-ils ces tests et vérifier la portée des tests avec eux. Vous pouvez diviser votre base de données en parties logiques et commencer le test de chaque partie logique séparément. Le processus de test pourrait commencer par étudier la DDL de la base de données et vérifier que les colonnes sont définies correctement comme l'exige l'entreprise. Vous devez utiliser le logiciel de l'application et non aucun autre outil pour effectuer la majorité des tests. Par exemple, posez les questions suivantes:
La colonne est-elle censée être du type défini (inutile de faire un nom comme Int).
La taille est-elle compatible avec les exigences de l'entreprise?
Toutes les colonnes des exigences commerciales se trouvent-elles dans la base de données?
Les colonnes nulles sont-elles vraiment facultatives?
etc.
Ensuite, vous pouvez concevoir des cas de test pour tester ce qui précède. Vous pouvez utiliser l'interface graphique pour effectuer la plupart des tests.
Il existe d'autres tests de base de données importants que vous n'avez pas mentionnés. Ceux-ci concernent:
1 - Vérifier que les clés primaires sont vraiment uniques d'un point de vue commercial.
2 - Tester que les index uniques (autres que le PK) sont vraiment uniques du point de vue commercial.
3 - Tester le travail des contraintes de clé étrangère.
4 - Tester ce qui se passe lorsqu'une ligne est supprimée et son effet sur les lignes liées.
5 - Autres tests concernant les constructions de bases de données spéciales telles que CHEKC, Déclencheurs s'ils existent.
6 - Normalisation correcte des tables et que les colonnes normalisées contiennent des valeurs correctes.
Ce qui précède n'est pas une liste complète, mais il devrait vous aider à démarrer.