データベーステスト–テクニック

この章では、データベーステストの実行に使用される最も一般的な手法について説明します。

データベーススキーマテスト

前述のように、スキーマ内の各オブジェクトをテストする必要があります。

データベースとデバイスの検証

  • データベースの名前を確認する
  • データデバイス、ログデバイス、およびダンプデバイスの確認
  • 各データベースに十分なスペースが割り当てられているかどうかを確認する
  • データベースオプション設定の確認

テーブル、列、列タイプのルールチェック

以下の項目を確認して、実際の設定と適用された設定の違いを確認してください。

  • データベース内のすべてのテーブルの名前

  • 各テーブルの列名

  • 各テーブルの列タイプ

  • NULL 値がチェックされているかどうか

  • デフォルトが正しいテーブル列にバインドされているかどうか

  • テーブル名とアクセス権限を修正するためのルール定義

キーとインデックス

各テーブルのキーとインデックスを確認します-

  • 各テーブルの主キー

  • 各テーブルの外部キー

  • 外部キー列と他のテーブルの列の間のデータ型インデックス、クラスター化または非クラスター化一意または一意でない

ストアドプロシージャテスト

これには、ストアドプロシージャが定義されているかどうかを確認し、出力結果を比較することが含まれます。ストアドプロシージャテストでは、次の点がチェックされます。

  • ストアドプロシージャ名

  • パラメータ名、パラメータタイプなど。

  • Output−出力に多くのレコードが含まれているかどうか。ゼロ行が影響を受けるか、少数のレコードのみが抽出されます。

  • ストアドプロシージャの機能と、ストアドプロシージャが実行するはずのないことは何ですか?

  • サンプル入力クエリを渡して、ストアドプロシージャが正しいデータを抽出するかどうかを確認します。

  • Stored Procedure Parameters−境界データと有効なデータを使用してストアドプロシージャを呼び出します。各パラメータを一度無効にして、プロシージャを実行します。

  • Return values−ストアドプロシージャによって返される値を確認します。失敗した場合は、ゼロ以外を返す必要があります。

  • Error messages check−ストアドプロシージャが失敗するように変更を加え、すべてのエラーメッセージを少なくとも1回生成します。事前定義されたエラーメッセージがない場合は、例外シナリオを確認してください。

トリガーテスト

トリガーテストでは、テスターは次のタスクを実行する必要があります-

  • トリガー名が正しいことを確認してください。
  • 特定のテーブル列に対してトリガーが生成された場合は、トリガーを検証します。
  • トリガーの更新検証。
  • 有効なデータでレコードを更新します。
  • 無効なデータでレコードを更新し、すべてのトリガーエラーをカバーします。
  • 他のテーブルの行によってまだ参照されているときにレコードを更新します。
  • 障害が発生したときにトランザクションをロールバックするようにします。
  • トリガーがトランザクションをロールバックすることになっていないケースを見つけます。

サーバーセットアップスクリプト

2種類のテストを実行する必要があります-

  • データベースを最初からセットアップし、
  • 既存のデータベースをセットアップします。

SQLServerの統合テスト

統合テストは、コンポーネントのテストが終了した後に実行する必要があります。

  • ストアドプロシージャを集中的に呼び出して、さまざまなテーブルのレコードを選択、挿入、更新、および削除して、競合や非互換性を見つける必要があります。

  • スキーマとトリガー間の競合。

  • ストアドプロシージャとスキーマの間の競合。

  • ストアドプロシージャとトリガーの間の競合。

機能テスト方法

機能テストは、データベースを機能ごとにモジュールに分割することで実行できます。機能は次の2種類があります-

  • Type 1−タイプ1テストで、プロジェクトの機能を調べます。主要な機能ごとに、その関数の実装を担当するスキーマ、トリガー、およびストアドプロシージャを見つけて、それらを機能グループに入れます。次に、各グループを一緒にテストします。

  • Type 2−タイプ2のテストでは、バックエンドの官能基の境界は明らかではありません。データフローを確認して、どこでデータを確認できるかを確認できます。フロントエンドから開始します。

次のプロセスが実行されます-

  • サービスにリクエストがあるか、データを保存すると、一部のストアドプロシージャが呼び出されます。

  • プロシージャはいくつかのテーブルを更新します。

  • これらのストアドプロシージャはテストを開始する場所になり、これらのテーブルはテスト結果を確認する場所になります。

ストレステスト

ストレステストでは、主要なデータベース機能と対応するストアドプロシージャのリストを取得します。ストレステストについては、以下の手順に従ってください-

  • これらの関数を試すためのテストスクリプトを作成し、すべての関数をフルサイクルで少なくとも1回チェックする必要があります。

  • 特定の期間、テストスクリプトを何度も実行します。

  • ログファイルを検証して、デッドロック、メモリ不足、データ破損などをチェックします。

ベンチマークテスト

データベースにデータの問題やバグがない場合は、システムのパフォーマンスを確認できます。以下に示すパラメータを確認することにより、ベンチマークテストでシステムパフォーマンスの低下を見つけることができます。

  • システムレベルのパフォーマンス
  • 最もよく使用される機能/機能を特定する
  • タイミング–機能を実行するための最大時間、最小時間、および平均時間
  • アクセスボリューム

フロントエンドを介したデータベースのテスト

バックエンドのバグは、フロントエンドのテストを行うことで見つかることもあります。以下の簡単な手順に従って、フロントエンドテストでバグを検出できます。

  • フロントエンドからクエリを作成し、検索を発行します。

  • 既存のレコードを取得し、いくつかのフィールドの値を変更して、レコードを保存します。(これには、UPDATEステートメント、またはストアード・プロシージャーの更新、およびトリガーの更新が含まれます。)

  • フロントエンドウィンドウに新しいメニュー項目を挿入します。情報を入力し、レコードを保存します。(これには、INSERTステートメントまたは挿入ストアード・プロシージャーと削除トリガーが含まれます。)

  • 既存のレコードを取得し、[削除]または[削除]ボタンをクリックして、削除を確認します。(これには、DELETEステートメントまたは削除ストアード・プロシージャーと削除トリガーが含まれます。)

  • 無効なデータでこれらのテストケースを繰り返し、データベースがどのように応答するかを確認します。