データベーステスト

データベーステストは通常​​、ユーザーインターフェース（UI）層、ビジネス層、データアクセス層、そしてデータベース自体を含む階層化されたプロセスで構成されます。UI層はデータベースのインターフェース設計を扱い、ビジネス層にはビジネス戦略をサポートするデータベースが含まれます。

目的

データベースは、サーバー上で相互接続されたファイルの集合であり、情報を保存しますが、同じ種類のデータを扱うとは限らないため、異種データベースとなる可能性があります。その結果、大規模なデータベースシステムでは、様々な実装エラーや統合エラーが発生し、システムのパフォーマンス、信頼性、一貫性、セキュリティに悪影響を及ぼす可能性があります。したがって、データベース管理システムのACID特性（原子性、一貫性、独立性、永続性）を満たすデータベースシステムを実現するためには、テストが重要です。[ 1 ]

最も重要な層の一つはデータアクセス層であり、通信プロセスにおいてデータベースと直接やり取りします。データベーステストは主にこの層で行われ、製品データベースの品質管理や品質保証といったテスト戦略が含まれます。[ 2 ]これらの異なる層でのテストは、データベースシステムの一貫性を維持するために頻繁に行われ、最もよく見られる例としては、以下のものがあります。

  • データはビジネスの観点から非常に重要です。GoogleやSymantecといったデータストレージ関連の企業は、耐久性と一貫性を備えたデータベースシステムを必要としています。データベースの整合性を事前にテストせずに、挿入、削除、更新などのデータベース操作を実行すると、システム全体がクラッシュするリスクがあります。
  • 企業によっては、データベースの種類や目標、ミッションが異なります。これらの目標を達成するための機能レベルを達成するには、データベースシステムをテストする必要があります。
  • 開発者がデータベースを正式にテストするという現在のアプローチよりも、より効果的な方法が必要になるかもしれません。しかし、このアプローチは、データベース開発者間のコミュニケーションギャップによりテストプロセスの遅延が発生する可能性があるため、十分な効果を発揮しません。独立したデータベーステストチームを設置することが望ましいと考えられます。
  • データベーステストは主に、データベース内のエラーを発見し、それを排除することに重点を置きます。これにより、データベースまたはWebベースのシステムの品質が向上します。
  • データベーステストは、データベースのクラッシュ、挿入、削除、更新といった他の問題に対処するための戦略とは区別する必要があります。ここでは、データベースリファクタリングが適用可能な進化的手法です。

テストとプロセスの種類

データベーステストにおけるブラックボックステストとホワイトボックステスト

この図は、ブラック ボックス テストやホワイト ボックス テストなど、さまざまなデータベース テスト方法で実行されるテストの領域を示しています。

ブラックボックス

ブラック ボックス テストには、次の内容を含むインターフェースとデータベースの統合のテストが含まれます。

  1. データのマッピング（メタデータを含む）
  2. 受信データの検証
  3. クエリ関数からの出力データの検証
  4. 原因結果グラフ化手法、同値分割、境界値分析などのさまざまな手法。

これらの技術の助けを借りて、データベースの機能を徹底的にテストすることができます。

ブラックボックステストの長所と短所は以下の通りである。ブラックボックステストにおけるテストケース生成は非常に単純である。テストケース生成はソフトウェア開発から完全に独立しており、開発の初期段階で行うことができる。その結果、プログラマーはデータベースアプリケーションの設計方法に関する知識を深め、デバッグにかかる​​時間を短縮できる。ブラックボックステストケースの開発コストは、ホワイトボックステストケースの開発コストよりも低い。ブラックボックステストの主な欠点は、プログラムのどの程度がテストされているか不明である点である。また、特定のエラーを検出できないこともある。[ 3 ]

ホワイトボックス

ホワイトボックステストは主にデータベースの内部構造を扱います。仕様の詳細はユーザーからは隠されています。

  1. これには、データベース リファクタリングをサポートするデータベース トリガーと論理ビューのテストが含まれます。
  2. データベース関数、トリガー、ビュー、SQLクエリなどのモジュール テストを実行します。
  3. データベース テーブル、データ モデル、データベース スキーマなどを検証します。
  4. 参照整合性のルールをチェックします。
  5. データベースの一貫性をチェックするためにデフォルトのテーブル値を選択します。
  6. ホワイト ボックス テストで使用される手法には、条件カバレッジ、決定カバレッジ、ステートメント カバレッジ、循環的複雑度などがあります。

データベーステストにおけるホワイトボックステストの主な利点は、コーディングエラーを検出することでデータベース内部のバグを排除できることです。ホワイトボックステストの限界は、SQL文がテスト対象とならないことです。

WHODATEアプローチ

SQL文の変換におけるWHODATEアプローチ

データベーステスト用のテストケースを生成する際には、SQL文のセマンティクスをテストケースに反映させる必要があります。そのために、ホワイトボックスデータベースアプリケーションテクニック（WHite bOx Database Application Technique）「(WHODATE)」と呼ばれる手法が用いられます。図に示すように、SQL文は個別にGPL文に変換され、その後、従来のホワイトボックステストによってSQLセマンティクスを含むテストケースが生成されます。[ 4 ]

4つの段階

設定されたフィクスチャは、テストに入る前のデータベースの初期状態を記述します。フィクスチャの設定後、定義されたテストケースに基づいてデータベースの動作がテストされます。結果に応じて、テストケースは修正されるか、そのまま維持されます。「ティアダウン」段階では、テストが終了するか、他のテストケースが続行されます。[ 5 ]

データベース テストを成功させるには、通常、各テストごとに次のワークフローを実行します。

  1. データベースをクリーンアップする: テスト可能なデータがすでにデータベース内に存在する場合は、データベースを空にする必要があります。
  2. フィクスチャをセットアップします。PHPUnit などのツールは、フィクスチャを反復処理し、データベースに挿入を実行します。
  3. テストを実行し、結果を検証し、ティアダウンします。データベースを空にリセットし、フィクスチャをリストした後、テストを実行し、出力を検証します。出力が期待どおりであればティアダウンプロセスに進み、そうでない場合はテストを繰り返します。

基本的なテクニック

  • SQL クエリ アナライザーは、 Microsoft SQL Server を使用するときに役立つツールです。
  • よく使用される関数の 1 つは、create_input_dialog["label"]ユーザー入力による出力を検証するために使用されます。
  • 自動データベース テスト用のフォーム (フロントエンドおよびバックエンド フォーム) の設計は、データベース保守作業者に役立ちます。
  • データ負荷テスト:
    • データ ロード テストでは、ソース データベースとターゲット データベースに関する知識が必要です。
    • ワーカーは、 DTSパッケージを使用して、ソース データベースと宛先データベース間の互換性を確認します。
    • ソース データベースを更新する場合、ワーカーはそれをターゲット データベースと必ず比較します。
    • データベース負荷テストは、データベースサーバがクエリを処理する能力と、データベースサーバとクライアントの応答時間を測定します。[ 6 ]
  • データベースのテストでは、原子性、一貫性、分離性、耐久性、整合性、トリガーの実行、回復などの問題がよく考慮されます。
  1. データベース システムは、予想される挿入、削除、更新操作によって常に変化するため、データベース テストのセットアップはコストがかかり、維持が複雑になります。
  2. データベース トランザクションの状態を判断するために、追加のオーバーヘッドが発生します。
  3. データベースをクリーンアップした後、新しいテストケースを設計する必要があります。
  4. SQL セマンティクスをデータベース テスト ケースに含めるには、SQL ステートメントを変換する SQL ジェネレーターが必要です。

参照

参考文献

  1. ^ Korth, Henry (2010).データベースシステムの概念. Macgraw-Hill. ISBN 978-0-07-352332-3。
  2. ^アンブラー、スコット (2003).アジャイルデータベーステクニック：アジャイルソフトウェア開発者のための効果的な戦略. ワイリー. ISBN 978-0-471-20283-7。
  3. ^プレスマン、ロジャー（1994年）『ソフトウェアテスター：実践者のアプローチ』マグロウヒル・エデュケーション、ISBN 978-0-07-707732-7。
  4. ^張 燕春 (1999). 『協調データベースとアプリケーション '99：第2回国際協調データベースシステム高度応用シンポジウム (CODAS '99) 議事録』, オーストラリア、ウォロンゴン, 1999年3月27日～28日. シュプリンガー. ISBN 978-981-4021-64-7。
  5. ^ Kan, Stephen.ソフトウェア品質工学におけるメトリクスとモデル. ピアソン・エデュケーション. ISBN 978-81-297-0175-6。
  6. ^ "InfoWorld" . InfoWorld Media Group, Inc. 1996年1月15日.
「 https://en.wikipedia.org/w/index.php?title=データベーステスト&oldid= 1321380357」より取得