この質問に対する完全な回答は非常に長くなります。要点を申し上げます。
懸念事項を分離するために、次のようなテストを検討している場合があります。
A-データベース設計を検証します。
B-プログラムがデータベースと正しく相互作用していることを確認します。
データベース設計の検証は、データベースを設計した人が行う必要があります。開発者（単体テスト中）は、パート（B）にもっと関心を持つ必要があります。2つのタイプのテストの主な違いは、使用するツールです。（A）の場合、プロジェクトコードから独立した環境を使用しますが、（B）の場合は、プロジェクトのコードを使用します。次のテキストでは、両方を混合します。
特定の質問に答えるには：
列ドメイン値のルール
各列にはデータ型が関連付けられています。各列をビジネスルールに対して検証して、正しいデータ型を表していることを証明する必要があります。列のデータ型がビジネス要件と互換性がない場合、またはコードがデータベースでの定義とは異なるデータ型を使用している場合、問題が発生する可能性があります。
例えば：
列のデフォルト値のルール
一部の列は、DDL（データ定義言語）のデフォルト値の指定に関連付けられており、挿入時に挿入によって値が提供されない場合、データベースはデフォルト値を想定します。これは、値を渡さずに、データベースに格納されている結果の値を観察することでテストできます。このテストには、Nullable列のチェックも含まれます。列に一意のインデックスが構築されていない限り、DDLから検証できるため、テストが必要になることはほとんどありません。
価値存在ルール
これを理解したところで、挿入または更新されたデータがデータベースで期待どおりに表示されることを確認します。
行の値のルール
これが正確に何を意味するのか私ははっきりしていません。
サイズルール
各列には、DDLでの定義方法に基づいて、データベース内のサイズがあります。要件に適合する値（GUIから入力されたもの、または計算の出力として得られたもの）が列に正しく格納されるようにする必要があります。たとえば、Small Integerデータ型では50億の値を格納できません。また、VARCHAR2（30）として定義された名前は40文字に対応しないため、特に列をデータの集計に使用する場合は、ここでビジネスルールを明確にする必要があります。そのような状況で何が起こるかをテストしたいとします。
開始する方法/場所に関するガイドライン
これを行う1つの方法は、テスト計画を作成することです。仕様（要件ドキュメントやユースケースなど）およびソフトウェアの正しいバージョンを使用していることを確認したい。また、ユニットテスト（存在する場合）によって行われたテストとこれらのテストを調整する必要があります。再度実行する必要のない重複したテストを見つける場合があります。テストの前にデータベースのコピーを取得して、必要に応じて特定のテストを繰り返すことができます。DBAがこれをお手伝いします。また、チームがこれらのテストをどのように文書化し、テストの範囲を検証するかをチームに確認する必要があります。データベースを論理部分に分割し、各論理部分のテストを個別に開始できます。テストプロセスは、データベースのDDLを調査し、列がビジネスの必要に応じて正しく定義されていることを確認することから始まります。テストの大部分を実行するには、アプリケーションのソフトウェアを使用し、他のツールは使用しないでください。たとえば、次の質問：
次に、上記をテストするためのテストケースを設計できます。GUIを使用してほとんどのテストを実行できます。
あなたが言及していない他の重要なデータベーステストがあります。それらは以下を扱います：
1-主キーがビジネスの観点から本当にユニークであることをテストします。
2-一意のインデックス（PK以外）がビジネスの観点から本当に一意であることをテストします。
3-外部キー制約のテストが機能します。
4-行が削除されたときに何が起こるか、および関連する行への影響をテストします。
5-CHEKC、トリガー（存在する場合）などの特別なデータベース構成に関するその他のテスト。
6-正しいテーブル正規化とその正規化された列が正しい値を保持します。
上記は完全なリストではありませんが、それであなたは始められるはずです。