データベースのテスト-タイプ

データベースの機能と構造に基づいて、DBテストは3つのカテゴリに分類することができます-

構造データベースのテスト-テーブルと列のテスト、スキーマのテスト、ストアドプロシージャとビューのテスト、トリガーのチェックなどを扱います。
機能テスト-ユーザーの観点からデータベースの機能をチェックします。機能テストの最も一般的なタイプは、ホワイトボックステストとブラックボックステストです。
非機能テスト-負荷テスト、データベースでのリスクテスト、ストレステスト、最小システム要件を含み、データベースのパフォーマンスを扱います。

構造データベースのテスト

構造データベースのテストでは、エンドユーザーに公開されていないデータベースのコンポーネントを検証します。これには、リポジトリのすべてのコンポーネントが含まれます。これらのコンポーネントは、データの保存に使用され、エンドユーザーによって変更されることはありません。通常、このテストは、SQLストアドプロシージャやその他の概念に対する優れたコマンドを持つデータベース管理者が実行します。

構造テストに関してテストされた一般的なコンポーネントについて説明します-

スキーマ/マッピングのテスト

データベースオブジェクトマッピングを使用して、フロントエンドアプリケーションのオブジェクトを検証する必要があります。

スキーマテスト-

エンドユーザーアプリケーションオブジェクトが正しくマッピングされていないか、データベースオブジェクトと互換性がない場合があります。したがって、データベースに関連付けられているさまざまなスキーマ形式の検証を確認する必要があります。
テーブル、ビュー、列など、データベース内でマップされていないオブジェクトを見つける必要があります。必要とされている。

市場には、スキーマでオブジェクトマッピングを実行するために使用できるさまざまなツールがあります。

例-Microsoft SQL Serverでは、テスターはデータベース内のスキーマをチェックおよび検証するための簡単なクエリを作成できます。

テスターがテーブル構造を変更する場合、そのテーブルを持つすべての*ストアドプロシージャがこの変更と互換性があることを確認する必要があります。

スキーママッピングテスト

ストアドプロシージャとビューのテスト

このテストでは、テスターがストアドプロシージャとビューの手動実行により必要な結果が生成されることを確認します。

テスターは確認します-

必要なトリガーを期待どおりに実行できる場合。
開発チームが手順のアプリケーションに入力を渡すことで、すべてのループと条件をカバーした場合。
データベースに未使用のストアドプロシージャがある場合。
データベース内の必要なテーブルからデータがフェッチされると、TRIM操作が適切に適用されます。
テスト対象のアプリケーションの要件に応じたストアドプロシージャモジュールの全体的な統合の検証。
例外およびエラー処理メカニズムが続きます。

ストアドプロシージャテストの実行に使用される最も一般的なツールは、 LINQ 、* SPテストツール*などです。

トリガーテスト

トリガーテストでは、テスターは以下を確認する必要があります-

トリガーのコーディング段階でコーディング規則に従うかどうか。
実行されたトリガーが必要な条件を満たしていることを確認してください。
トリガーが実行されると、トリガーがデータを正しく更新するかどうか。
更新/挿入/削除の検証は、テスト中のアプリケーションで機能をトリガーします。

テーブルと列のテスト

このテストでカバーされる主要な領域は次のとおりです-

データベース内のデータ型をフロントエンドアプリケーションのフィールド値に検証します。
データベース内のデータフィールドの長さを、アプリケーション内のデータ型の長さに検証します。
アプリケーションフィールドオブジェクトからデータベースにマップされていないテーブルまたは列があるかどうかを確認します。
データベースのテーブルと列の命名規則は、ビジネス要件に準拠しているかどうかにかかわらず検証されます。
データベース内のキーとインデックス、つまりテーブル内のプライマリキーと外部キーの検証は、要件に従って定義されます。
主キーとそれに対応する外部キーが2つのテーブルで同じかどうかを確認します。
キーの一意およびNOT NULL特性が維持されていることを確認します。
キーとインデックスの長さとデータ型は、要件に従って維持されます。

データベースサーバーチェック

データベースサーバーのチェックには検証が含まれます-

データベースサーバーがビジネス要件に従ってトランザクションの予想数を処理できる場合。
データベースサーバーの構成の詳細がビジネス要件を満たしている場合。
ユーザーの承認が要件に従って維持されている場合。

機能テスト

機能テストは、エンドユーザーの視点を念頭に置いて実行されます。エンドユーザーが実行する必要なトランザクションと操作がビジネス仕様を満たしているかどうか。

ブラックボックステスト

ブラックボックステストでは、データベースの統合を検証して機能を確認します。テストケースは単純で、関数からの着信データと発信データを検証するために使用されます。

データベースの機能をテストするために、因果関係のグラフ作成手法、等価分割、境界値分析などのさまざまな手法が使用されます。

その*利点*は次のとおりです-

これはかなり単純で、開発の初期段階で実行されます。
テストボックスの開発コストは、ホワイトボックステストに比べて低くなります。

その欠点は次のとおりです-

いくつかのエラーを検出できません
どのくらいのプログラムをテストする必要があるかは不明です。

ホワイトボックステスト

ホワイトボックステストは、データベースの内部構造を処理し、仕様の詳細はユーザーには表示されません。データベースリファクタリングをサポートするデータベーストリガーと論理ビューのテストが含まれます。

データベース関数、トリガー、ビュー、SQLクエリなどのモジュールテストを実行します。このタイプのテストでは、データベーステーブル、データモデル、データベーススキーマなどを検証します。参照整合性のルールをチェックします。デフォルトのテーブル値を選択して、データベースの一貫性をチェックします。

ホワイトボックステストの実行に使用される最も一般的な手法は、条件カバレッジ、決定カバレッジ、ステートメントカバレッジなどです。

ホワイトボックステストでコーディングエラーを検出できるため、データベースの内部バグを排除できます。ホワイトボックステストの制限は、SQLステートメントがカバーされないことです。

非機能テスト

機能しないテストには、負荷テスト、ストレステスト、ビジネス仕様を満たすための最小システム要件の確認、データベースのリスク発見およびパフォーマンス最適化が含まれます。

負荷テスト

負荷テストの主な目的は、実行中のトランザクションのほとんどがデータベースのパフォーマンスに影響するかどうかを確認することです。

負荷テストでは、テスターがチェックします-

複数のリモートユーザーのトランザクションを実行するための応答時間。
データベースが特定のレコードをフェッチするのにかかった時間。

さまざまなテストタイプでの負荷テストの例-

最もよく使用されるトランザクションを繰り返し実行して、データベースシステムのパフォーマンスを確認します。
インターネットから一連の大きなファイルをダウンロードします。
コンピューターまたはサーバーで同時に複数のアプリケーションを実行します。

ストレステスト

システムブレークポイントを識別するために、ストレステストが実行されます。このテストでは、ある時点でシステムに障害が発生するようにアプリケーションがロードされます。このポイントは、データベースシステムの*ブレークポイント*と呼ばれます。

データベーストランザクションの状態を判断するには、多大な労力が必要です。時間とコストに基づく問題を回避するには、適切な計画が必要です。

最も一般的に使用されるストレステストツールは、 LoadRunner および WinRunner です。

ストレステストの*例*を見てみましょう。 CRMアプリケーションは、最大50000の同時ユーザーのユーザー負荷を取得できます。負荷を51000に増やし、レコードの更新やエントリの追加などのトランザクションを実行するとします。トランザクションを実行するとすぐに、アプリケーションはデータベースシステムと同期できます。したがって、次のテストは、52000のユーザー負荷で実行することです。ストレステストは*疲労テスト*と呼ばれることもあります。

Database-testing-types

目次