データベース (データ) テストのチュートリアル

グラフィカル ユーザー インターフェイスはアプリケーションで最も目に見える部分であるため、通常、テスト チームと開発チームのメンバーは GUI を最も重視します。 ただし、アプリケーションの中心となる情報、つまりデータベースを検証することも重要です。

ユーザーが取引を行う銀行アプリケーションを考えてみましょう。データベース テストまたは DB テストの観点から、次のことが重要になります。

1. アプリケーションはトランザクション情報をアプリケーション データベースに保存し、ユーザーに正しく表示します。
2. プロセス中に情報が失われることはありません。
3. 部分的に実行された操作や中止された操作の情報はアプリケーションによって保存されません。
4. 権限のない個人がユーザーの情報にアクセスすることは許可されていません。

上記の目的をすべて確実に達成するには、データ検証またはデータ テストを使用する必要があります。

ユーザーインターフェイステストとデータテストの違い

ユーザーインターフェイスのテスト	データベースまたはデータのテスト
このタイプのテストは、グラフィカル ユーザー インターフェイス テストまたはフロントエンド テストとも呼ばれます。	このタイプのテストは、バックエンド テストまたはデータ テストとも呼ばれます。
このタイプのテストは、主にフォーム、プレゼンテーション、グラフ、メニュー、レポートなど、ユーザーが閲覧および操作できるテスト可能なすべての項目を扱います（VB、VB.net、VC++、Delphi – フロントエンドツール)	このタイプのテストでは、主に、一般に閲覧のためにユーザーから隠されているテスト可能なすべての項目を扱います。これらには、次のような内部プロセスとストレージが含まれます。 Assembly、DBMSのような Oracle、SQL Server、MYSQL など。
このタイプのテストには、 テキストボックス ドロップダウンを選択 カレンダーとボタン ページナビゲーション 画像の表示 アプリケーション全体のルックアンドフィール	このタイプのテストには、以下の検証が含まれます。 スキーマ データベーステーブル コラム キーとインデックス ストアド プロシージャ トリガー データベースサーバーの検証 データの重複を検証する
テスターは、ビジネス要件、開発ツールの使用法、自動化フレームワークとツールの使用法について十分な知識を持っている必要があります。	バックエンド テストを実行するには、テスターがデータベース サーバーと構造化クエリ言語の概念について十分な知識を持っている必要があります。

データベーステストの種類

データベース テストには次の 3 種類があります。

1. 構造試験
2. 機能テスト
3. 非機能テスト

このデータベース テスト チュートリアルでは、各タイプとそのサブタイプを XNUMX つずつ見ていきます。

スキーマテストとは何ですか?

スキーマのテスト データベース テストでは、データベースに関連付けられたさまざまなスキーマ形式を検証し、テーブル/ビュー/列のマッピング形式がユーザー インターフェイスのマッピング形式と互換性があるかどうかを検証します。 スキーマ テストの主な目的は、フロントエンドとバックエンドの間のスキーマ マッピングが類似していることを確認することです。 したがって、マッピング テストとも呼ばれます。

スキーマテストの最も重要なチェックポイントについて説明します。

1. データベースに関連付けられたさまざまなスキーマ形式の検証。 多くの場合、テーブルのマッピング形式は、アプリケーションのユーザー インターフェイス レベルに存在するマッピング形式と互換性がない可能性があります。
2. マップされていないテーブル/ビュー/列の場合は検証が必要です。
3. また、環境内の異種データベースが全体的なアプリケーション マッピングと一致しているかどうかを確認する必要もあります。

データベース スキーマを検証するための興味深いデータベース テスト ツールのいくつかも見てみましょう。

• Ant と統合された DBUnit は、マッピング テストに非常に適しています。
• SQL Server を使用すると、テスターはコードを使用せずに簡単なクエリを作成することによって、データベースのスキーマを確認したりクエリしたりすることができます。

たとえば、開発者がテーブル構造を変更または削除したい場合、テスターはそのテーブルを使用するすべてのストアド プロシージャとビューが特定の変更と互換性があることを確認したいと考えます。 別の例としては、テスターが 2 つのデータベース間のスキーマの変更をチェックしたい場合、単純なクエリを使用してそれを行うことができます。

データベーステーブル、列のテスト

データベースとカラムのテストのためのさまざまなチェックを見てみましょう。

1. バックエンドのデータベースのフィールドと列のマッピングは、フロントエンドのマッピングと互換性があるかどうか?
2. 要件で指定されたデータベースのフィールドと列の長さと命名規則の検証。
3. 未使用またはマップされていないデータベース テーブル/列の存在の検証。
4. の互換性の検証

• データ・タイプ
• フィールド長

バックエンド データベースの列とアプリケーションのフロントエンドに存在する列の列を比較します。

5. ビジネス要件仕様文書の要求に応じて、データベース フィールドでユーザーが希望のユーザー入力を行うことができるかどうか。

キーとインデックスのテスト

キーとインデックスの重要なチェック –

1. 必要かどうかを確認してください

• 主キー
• 外部キー

必要なテーブルに制約が作成されています。

2. 外部キーの参照が有効かどうかを確認してください。
3. XNUMX つのテーブルの主キーと対応する外部キーのデータ型が同じであるかどうかを確認します。
4. すべてのキーとインデックスに対して必要な命名規則に従っているかどうかを確認してください。
5. 必要なフィールドとインデックスのサイズと長さを確認してください。
6. 必要かどうか

• Cluster編集されたインデックス
• Non Cluster編集されたインデックス

ビジネス要件で指定された必要なテーブルに作成されている。

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

ストアド プロシージャをチェックするための重要なテストは次のとおりです。

1. 開発チームが必要な、A) コーディング標準規約、B) 例外およびエラー処理を採用したかどうか。 テスト対象アプリケーションのすべてのモジュールのすべてのストアド プロシージャ。
2. 開発チームは、テスト対象のアプリケーションに必要な入力データを適用して、すべての条件/ループをカバーしたかどうか?
3. 開発チームは、データベース内の必要なテーブルからデータが取得されるたびに TRIM 操作を適切に適用しましたか?
4. ストアド プロシージャを手動で実行すると、エンド ユーザーに必要な結果が得られるかどうか?
5. ストアド プロシージャを手動で実行すると、テスト対象のアプリケーションの要求に応じてテーブル フィールドが確実に更新されるかどうか。
6. ストアド プロシージャの実行により、必要なトリガーを暗黙的に呼び出すことができるかどうか?
7. 未使用のストアド プロシージャの存在の検証。
8. Null を許可する条件の検証はデータベース レベルで実行できます。
9. テスト対象のデータベースが空の場合に、すべてのストアド プロシージャと関数が正常に実行されたという事実の検証。
10. テスト対象アプリケーションの要件に従って、ストアド プロシージャ モジュールの全体的な統合を検証します。

ストアド プロシージャのテストに役立つデータベース テスト ツールには、 LINQ 、 SP テスト ツールなどがあります。

トリガーテスト

1. トリガーのコーディング段階で、必要なコーディング規約に従っているかどうか?
2. 各DMLトランザクションに対して実行されたトリガーが必要な条件を満たしているかを確認します。
3. トリガーが実行された後、データが正しく更新されるかどうか?
4. 必要な更新/挿入/削除の検証により、テスト対象のアプリケーションのレルムで機能がトリガーされます。

データベースサーバーの検証

1. ビジネス要件で指定されているデータベース サーバーの構成を確認してください。
2. アプリケーションに必要なレベルのアクションのみを実行するために、必要なユーザーの権限を確認してください。
3. データベース サーバーが、ビジネス要件の仕様で指定されている最大許容数のユーザー トランザクションのニーズに対応できることを確認します。

機能データベースのテスト

機能データベースのテスト は、エンドユーザーの観点からデータベースの機能要件を検証するために使用されるデータベース テストの一種です。機能データベース テストの主な目的は、データベースに関連してエンドユーザーが実行するトランザクションと操作が期待どおりに動作するかどうかをテストすることです。

以下は、データベース検証で遵守する必要がある基本条件です。

• そのフィールドで NULL 値を許可する場合、そのフィールドは必須ですか?
• 各フィールドの長さは十分なサイズかどうか?
• すべての同様のフィールドがテーブル間で同じ名前を持つかどうか?
• データベースに計算フィールドが存在するかどうか?

この特定のプロセスは、エンドユーザーの観点からフィールド マッピングを検証するものです。この特定のシナリオでは、テスターはデータベース レベルで操作を実行し、関連するユーザー インターフェイス項目に移動して、適切なフィールド検証が実行されたかどうかを観察および検証します。

逆の条件、つまり、最初にテスターがユーザー インターフェイスで操作を実行し、次にバックエンドから同じ操作を検証することも実行する必要があります。

データの整合性と一貫性のチェック

以下のチェックが重要です

1. データが論理的に整理されているかどうか?
2. テーブルに保存されているデータは正しく、ビジネス要件に従っているか?
3. テスト対象のアプリケーションに不要なデータが存在していないか?
4. ユーザーインターフェースから更新されたデータについて、要件通りにデータが保存されているか？
5. テスト対象のデータベースにデータを挿入する前に、データに対して TRIM 操作を実行したかどうか。
6. 業務要求仕様に従って取引が行われたのか、その結果は正しいのか？
7. トランザクションが正常に実行された場合、データが適切にコミットされたかどうか?
8. エンドユーザーによってトランザクションが正常に実行されなかった場合、データは正常にロールバックされたかどうか?
9. トランザクションが正常に実行されず、問題のトランザクションに複数の異種データベースが関与している場合、データはロールバックされているかどうか。
10. システムのビジネス要件で指定された必要な設計手順を使用して、すべてのトランザクションが実行されているか?

ログインとユーザーのセキュリティ

ログインとユーザーのセキュリティ資格情報の検証では、次の点を考慮する必要があります。

1. 次のような問題が発生した場合に、アプリケーションがユーザーのアプリケーション内での続行を妨げているかどうか。

• ユーザー名は無効ですが、パスワードは有効です
• ユーザー名は有効ですが、パスワードが無効です。
• 無効なユーザー名と無効なパスワード。

2. ユーザーは、ビジネス要件によって指定された特定の操作のみを実行できるかどうか。
3. データは不正アクセスから保護されていますか?
4. 異なる権限を持つ異なるユーザー ロールが作成されているかどうか?
5. すべてのユーザーが、ビジネス仕様で要求されている、指定されたデータベースに対する必要なレベルのアクセス権を持っているかどうか?
6. パスワードやクレジットカード番号などの機密データが暗号化され、データベースにプレーンテキストとして保存されていないことを確認します。すべてのアカウントに複雑で簡単に推測できないパスワードを設定することをお勧めします。

非機能テスト

非機能テスト データベース テストのコンテキストでは、ビジネス要件に応じてさまざまなカテゴリに分類できます。 これらには、負荷テスト、ストレス テスト、 セキュリティテスト, ユーザビリティテスト, 互換性テスト、 等々。 パフォーマンス テストの範囲に分類できる負荷テストとストレス テストは、非機能テストの役割に関して XNUMX つの特定の目的を果たします。

リスクの定量化– リスクの定量化は、関係者が必要な負荷レベルでのさまざまなシステム応答時間要件を確認するのに役立ちます。 これがあらゆるものの本来の目的です 品質保証 タスク。 負荷テストはリスクを直接軽減するものではありませんが、リスクの特定とリスクの定量化のプロセスを通じて、修正の機会とリスクを軽減する修復の推進力を提供することに注意する必要があります。

最小システム機器要件– 利害関係者が正式に表明したパフォーマンスの期待をシステムが満たせるようにする最小限のシステム構成。これにより、余分なハードウェア、ソフトウェア、および関連する所有コストを最小限に抑えることができます。この特定の要件は、全体的なビジネス最適化要件として分類できます。

負荷テスト

負荷テストの目的は明確に理解され、文書化されている必要があります。次の種類の構成は必須です。 負荷テスト.

1. 最も頻繁に使用されるユーザー トランザクションは、効率的でない場合、他のすべてのトランザクションのパフォーマンスに影響を与える可能性があります。
2. 最終テスト スイートには、編集を行わないユーザー トランザクションを少なくとも 1 つ含める必要があります。これにより、そのようなトランザクションのパフォーマンスを、他のより複雑なトランザクションと区別できるようになります。
3. 定義上、これらのトランザクションの負荷下での障害は最大の影響を与えるため、システムの中核目的を促進するより重要なトランザクションを含める必要があります。
4. 少なくとも XNUMX つの編集可能なトランザクションを含める必要があります。 パフォーマンス そのようなトランザクションは他のトランザクションと区別できます。
5. 予想されるすべての要件に対して、膨大な数の仮想ユーザーの下で最適な応答時間を実現します。
6. 各種レコードの取得にかかる有効時間。

重要な負荷テスト ツールは次のとおりです。 ロードランナー プロフェッショナル、優勝ランナーと JMeter.

重要なストレス テスト ツールは次のとおりです。 ロードランナー プロフェッショナル と JMeter.

データベースのテスト中に発生する最も一般的な問題

A significant amount of overhead could be involved to determine the state of the database transactions

解決法： 時間とコストに基づく問題が発生しないように、全体的なプロセスの計画とタイミングを整理する必要があります。

New test data have to be designed after cleaning up of the old test data.

解決法： テスト データ生成のための事前の計画と方法論を手元に用意しておく必要があります。

An SQL generator is required to transform SQL validators in order to ensure the SQL queries are apt for handling the required database test cases.

解決法： SQL クエリのメンテナンスとその継続的な更新は、テスト プロセス全体の重要な部分であり、全体的なテストの一部である必要があります。 テスト戦略.

The above mentioned prerequisite ensure that the set-up of the database testing procedure could be costly as well as time consuming.

解決法： 品質とプロジェクト全体のスケジュール期間との間には、適切なバランスが必要です。

データベース テストに関する神話や誤解

Database Testing requires plenty of expertise and it is a very tedious job

現実： ソフトウェア テストにおける効果的かつ効率的なデータベース テストは、アプリケーション全体に長期的な機能安定性を提供するため、その裏で多大な労力を費やす必要があります。

Database testing adds extra work bottleneck

現実： それどころか、データベース テストは、隠れた問題を見つけ出し、アプリケーション全体の改善に積極的に役立つため、作業全体にさらなる価値をもたらします。

Database testing slows down the overall development process

現実： 大量のデータベース テストは、データベース アプリケーションの全体的な品質の向上に役立ちます。

Database testing could be excessively costly

現実： データベースのテストにかかる費用は長期的な投資となり、アプリケーションの長期的な安定性と堅牢性につながります。 したがって、データベースのテストや SQL テストが必要です。

ベストプラクティス

• 機能データだけでなくメタデータを含むすべてのデータは、要件仕様書によるマッピングに従って検証される必要があります。
• の検証 テストデータ 開発チームによって、または開発チームと協議して作成されたものは、検証する必要があります。
• 手動手順と自動手順の両方を使用した出力データの検証。
• 原因影響グラフ法、等価分割法、境界値解析法などの各種手法を導入し、必要なテストデータ条件を生成します。
• 必要なデータベース テーブルの参照整合性の検証ルールも検証する必要があります。
• データベースの整合性を検証するためのデフォルトのテーブル値の選択は、非常に重要な概念です。 必要なすべてのログイン イベントに対してログ イベントがデータベースに正常に追加されているかどうか
• スケジュールされたジョブは適時に実行されますか?
• データベースのバックアップをタイムリーに取得します。

またチェック- データベース テストの面接の質問と回答