データベーステスト-クイックガイド
データベーステストには、データの有効性、データの整合性テスト、データベースに関連するパフォーマンスチェック、およびデータベース内のプロシージャ、トリガー、機能のテストが含まれます。
例
ユーザーの日々のトランザクションの詳細をキャプチャし、その詳細をデータベースに保存するアプリケーションについて考えてみます。データベーステストの観点から、次のチェックを実行する必要があります-
アプリケーションからのトランザクション情報はデータベースに保存され、ユーザーに正しい情報を提供する必要があります。
データベースにロードするときに情報が失われることはありません。
完了したトランザクションのみを保存し、すべての不完全な操作はアプリケーションによって中止する必要があります。
データベースへのアクセス許可を維持する必要があります。ユーザー情報への未承認または無許可のアクセスは提供しないでください。
データベーステストを実行する必要があるのはなぜですか?
データベーステストが実行される理由は複数あります。バックエンドシステムはデータの保存を担当し、複数の目的でアクセスされるため、データベースでデータの整合性、検証、およびデータの整合性チェックを実行する必要があります。
以下に、データベーステストの一般的な理由をいくつか示します。
データベースバックエンドへの呼び出しの複雑さを緩和するために、開発者は View そして Stored 手順。
これら Stored 手順と Views顧客の詳細(名前、連絡先情報など)や販売データの挿入などの重要なタスクが含まれています。これらのタスクは、いくつかのレベルでテストする必要があります。
Black-box testingフロントエンドで実行することは重要ですが、問題を特定することは困難です。バックエンドシステムでテストすると、データの堅牢性が向上します。これが、データベーステストがバックエンドシステムで実行される理由です。
データベースでは、データは複数のアプリケーションから取得され、有害または不正確なデータがデータベースに保存される可能性があります。したがって、データベースコンポーネントを定期的にチェックする必要があります。さらに、データの整合性と整合性を定期的にチェックする必要があります。
データベーステストとフロントエンドテスト
データベーステストは、フロントエンドUIテストとは異なります。次の表は、主な違いを示しています-
データベーステスト | UIテスト |
---|---|
データベーステストは、データ検証と整合性テストまたはバックエンドテストとして知られています。 |
UIテストまたはフロントエンドテストは、アプリケーションテストまたはGUIテストとも呼ばれます。 |
データベーステストには、ユーザーには表示されないバックエンドコンポーネントのテストが含まれます。 これには、データベースコンポーネントと、My SQL、OracleなどのDBMSシステムが含まれます。 |
UIテストには、アプリケーションと、フォーム、グラフ、メニュー、レポートなどのコンポーネントの機能のチェックが含まれます。 これらのコンポーネントは、VB.net、C#、Delphiなどのフロントエンド開発ツールを使用して作成されます。 |
データベーステストには、ストアドプロシージャ、ビュー、データベース内のスキーマ、テーブル、インデックス、キー、トリガー、データ検証、およびデータ整合性チェックが含まれます。 |
UIテストには、アプリケーションの機能、ボタン、フォームとフィールド、カレンダーと画像、あるページから別のページへのナビゲーション、およびアプリケーションの全体的な機能のチェックが含まれます。 |
DBテストを実行するには、テスターは、プロシージャと関数、ビュー、インデックス、キー、優れたハンズオンSQLなどのデータベースの概念に関する完全な知識が必要です。 |
UIテストを実行するには、テスターはビジネス要件、アプリケーションの機能知識、コーディングなどを十分に理解している必要があります。 |
データは、Webアプリケーション、イントラネットアプリケーション、およびその他のさまざまなアプリケーションを介した複数の異種データソースから取得されます。 |
データは手動でアプリケーションに入力されます。これには、フロントエンドアプリケーションの機能テストが含まれます。 |
データベースの機能と構造に基づいて、DBテストは3つのカテゴリに分類できます-
Structural Database Testing −テーブルと列のテスト、スキーマテスト、ストアドプロシージャとビューのテスト、トリガーのチェックなどを扱います。
Functional Testing−ユーザーの観点からデータベースの機能をチェックする必要があります。機能テストの最も一般的なタイプは、ホワイトボックステストとブラックボックステストです。
Nonfunctional Testing −負荷テスト、データベースでのリスクテスト、ストレステスト、最小システム要件が含まれ、データベースのパフォーマンスを扱います。
構造データベースのテスト
構造データベースのテストには、エンドユーザーに公開されていないデータベースのコンポーネントの検証が含まれます。これには、データの保存に使用され、エンドユーザーによって変更されないリポジトリのすべてのコンポーネントが含まれます。通常、SQLストアドプロシージャやその他の概念を熟知しているデータベース管理者がこのテストを実行します。
構造テストに関してテストされた一般的なコンポーネントについて説明します-
スキーマ/マッピングテスト
これには、データベースオブジェクトマッピングを使用してフロントエンドアプリケーションのオブジェクトを検証することが含まれます。
スキーマテスト中-
エンドユーザーのアプリケーションオブジェクトが正しくマップされていないか、データベースオブジェクトと互換性がない場合があります。したがって、データベースに関連付けられているさまざまなスキーマ形式の検証を確認する必要があります。
テーブル、ビュー、列など、データベース内のマップされていないオブジェクトを見つける必要があります。
スキーマでオブジェクトマッピングを実行するために使用できるさまざまなツールが市場に出回っています。
Example − Microsoft SQL Serverでは、テスターはデータベース内のスキーマをチェックおよび検証するための簡単なクエリを作成できます。
テスターがテーブル構造に変更を加えたい場合、テスターはすべての stored そのテーブルを持つプロシージャは、この変更と互換性があります。
ストアドプロシージャとビューのテスト
このテストでは、テスターは、ストアドプロシージャとビューを手動で実行すると、必要な結果が生成されることを確認します。
テスターは次のことを確認します-
必要なトリガーを期待どおりに実行できる場合。
開発チームが手順でアプリケーションに入力を渡すことにより、すべてのループと条件をカバーした場合。
データベースに未使用のストアドプロシージャがある場合。
TRIM操作は、データベース内の必要なテーブルからデータがフェッチされるときに適切に適用されます。
テスト対象のアプリケーションの要件に従って、ストアドプロシージャモジュールの全体的な統合を検証します。
例外およびエラー処理メカニズムに従います。
ストアドプロシージャのテストを実行するために使用される最も一般的なツールは次のとおりです。 LINQ、 SP Test tool、など。
トリガーテスト
トリガーテストでは、テスターは次のことを確認する必要があります。
トリガーのコーディング段階でコーディング規則に従うかどうか。
実行されたトリガーが必要な条件を満たすことを確認してください。
トリガーが実行された後、データが正しく更新されるかどうか。
更新/挿入/削除の検証により、テスト対象のアプリケーションの機能がトリガーされます。
テーブルと列のテスト
このテストでカバーされる重要な領域は次のとおりです。
データベース内のデータ型をフロントエンドアプリケーションのフィールド値に検証します。
データベースのデータフィールドの長さをアプリケーションのデータ型の長さに検証します。
アプリケーションフィールドオブジェクトから、データベースにマップされていないテーブルまたは列があるかどうかを確認します。
データベースのテーブルと列の命名規則は、ビジネス要件に準拠しているかどうかに関係なく検証されます。
データベース内のキーとインデックスの検証、つまりテーブル内の主キーと外部キーは、要件に従って定義されます。
主キーとそれに対応する外部キーが2つのテーブルで同じであるかどうかを確認します。
キーの一意のNOTNULL特性が維持されていることを確認します。
キーとインデックスの長さとデータ型は、要件に従って維持されます。
データベースサーバーチェック
データベースサーバーのチェックには、検証が含まれます-
データベースサーバーがビジネス要件に従って予想されるトランザクション数を処理できるかどうか。
データベースサーバーの構成の詳細がビジネス要件を満たしているかどうか。
ユーザー認証が要件に従って維持されている場合。
機能テスト
機能テストは、エンドユーザーの観点を念頭に置いて実行されます。エンドユーザーが実行する必要なトランザクションと操作がビジネス仕様を満たしているかどうか。
ブラックボックステスト
ブラックボックステストでは、データベースの統合を検証して機能を確認します。テストケースは単純で、関数からの受信データと送信データを検証するために使用されます。
データベースの機能をテストするために、因果関係グラフ作成手法、等価分割、境界値分析などのさまざまな手法が使用されます。
その advantages 次のとおりです-
- これはかなり単純で、開発の初期段階で実行されます。
- テストケースの開発コストは、ホワイトボックステストと比較して低くなっています。
その欠点は次のとおりです-
- いくつかのエラーを検出できません
- どのくらいのプログラムをテストする必要があるかは不明です。
ホワイトボックステスト
ホワイトボックステストはデータベースの内部構造を扱い、仕様の詳細はユーザーに表示されません。これには、データベースのリファクタリングをサポートするデータベーストリガーと論理ビューのテストが含まれます。
データベース関数、トリガー、ビュー、SQLクエリなどのモジュールテストを実行します。このタイプのテストは、データベーステーブル、データモデル、データベーススキーマなどを検証します。参照整合性のルールをチェックします。データベースの整合性をチェックするためにデフォルトのテーブル値を選択します。
ホワイトボックステストを実行するために使用される最も一般的な手法は、条件カバレッジ、決定カバレッジ、ステートメントカバレッジなどです。
ホワイトボックステストでコーディングエラーを検出できるため、データベースの内部バグを排除できます。ホワイトボックステストの制限は、SQLステートメントがカバーされていないことです。
非機能テスト
非機能テストには、負荷テスト、ストレステスト、ビジネス仕様を満たすための最小システム要件のチェック、リスクの検出、データベースのパフォーマンスの最適化の実行が含まれます。
負荷テスト
負荷テストの主な目的は、実行中のほとんどのトランザクションがデータベースのパフォーマンスに影響を与えるかどうかを確認することです。
負荷テストでは、テスターはチェックします-
- 複数のリモートユーザーのトランザクションを実行するための応答時間。
- データベースが特定のレコードをフェッチするのにかかった時間。
Examples of load testing in different testing types −
- 最も使用されるトランザクションを繰り返し実行して、データベースシステムのパフォーマンスを確認します。
- インターネットから一連の大きなファイルをダウンロードする。
- コンピューターまたはサーバーで複数のアプリケーションを同時に実行する。
ストレステスト
ストレステストは、システムのブレークポイントを特定するために実行されます。このテストでは、システムが一時的に失敗するような方法でアプリケーションがロードされます。この点は、breakpoint データベースシステムの。
データベーストランザクションの状態を判断するには、かなりの労力が必要です。時間とコストに基づく問題を回避するには、適切な計画が必要です。
最も一般的に使用されるストレステストツールは LoadRunner そして WinRunner。
取りましょう exampleストレステストの。CRMアプリケーションは、最大50000人の同時ユーザーのユーザー負荷をかけることができます。負荷を51000に増やし、レコードの更新やエントリの追加などのトランザクションを実行するとします。トランザクションを実行するとすぐに、アプリケーションはデータベースシステムと同期できます。したがって、次のテストは52000のユーザー負荷で実行することです。ストレステストも呼び出されることがありますFatigue Testing。
データベーステストを実行するプロセスは、他のアプリケーションのテストと同様です。DBテストは、以下に示す主要なプロセスで説明できます。
- 環境をセットアップする
- テストを実行する
- テスト結果を確認する
- 期待される結果に従って検証する
- 調査結果をそれぞれの利害関係者に報告する
テストケースの開発には、さまざまなSQLステートメントが使用されます。DBテストの実行に使用される最も一般的なSQLステートメントは、Selectステートメント。これとは別に、さまざまなDDL、DML、DCLステートメントも使用できます。
Example −作成、挿入、選択、更新など。
データベースのテスト段階
DBテストは面倒なプロセスではなく、テストプロセスに従ってデータベーステストライフサイクルのさまざまな段階が含まれます。
データベーステストの重要な段階は次のとおりです。
- 初期状態の確認
- 試運転
- 期待される結果による結果の検証
- 結果の生成
First stageDBテストでは、テストプロセスを開始する前に、データベースの初期状態を確認します。次に、定義されたテストケースについてデータベースの動作がテストされます。得られた結果に応じて、テストケースがカスタマイズされます。
データベーステストを成功させるために、以下に示すワークフローはすべてのテストによって実行されます。
Cleaning up the database −データベースにテスト可能なデータがある場合は、空にする必要があります。
Set up Fixture −これには、データベースにデータを入力し、データベースの現在の状態を確認することが含まれます。
Perform test, verify results and generate results−テストが実行され、出力が検証されます。出力が期待どおりの結果である場合、次のステップは要件に従って結果を生成することです。それ以外の場合は、データベース内のバグを見つけるためにテストが繰り返されます。
この章では、データベーステストの実行に使用される最も一般的な手法について説明します。
データベーススキーマテスト
前述のように、スキーマ内の各オブジェクトをテストする必要があります。
データベースとデバイスの検証
- データベースの名前を確認する
- データデバイス、ログデバイス、およびダンプデバイスの確認
- 各データベースに十分なスペースが割り当てられているかどうかを確認する
- データベースオプション設定の確認
テーブル、列、列タイプのルールチェック
以下の項目を確認して、実際の設定と適用された設定の違いを確認してください。
データベース内のすべてのテーブルの名前
各テーブルの列名
各テーブルの列タイプ
NULL 値がチェックされているかどうか
デフォルトが正しいテーブル列にバインドされているかどうか
テーブル名とアクセス権限を修正するためのルール定義
キーとインデックス
各テーブルのキーとインデックスを確認します-
各テーブルの主キー
各テーブルの外部キー
外部キー列と他のテーブルの列の間のデータ型インデックス、クラスター化または非クラスター化一意または一意でない
ストアドプロシージャテスト
これには、ストアドプロシージャが定義されているかどうかを確認し、出力結果を比較することが含まれます。ストアドプロシージャテストでは、次の点がチェックされます-
ストアドプロシージャ名
パラメータ名、パラメータタイプなど。
Output−出力に多くのレコードが含まれているかどうか。ゼロ行が影響を受けるか、少数のレコードのみが抽出されます。
ストアドプロシージャの機能と、ストアドプロシージャが実行するはずのないことは何ですか?
サンプル入力クエリを渡して、ストアドプロシージャが正しいデータを抽出するかどうかを確認します。
Stored Procedure Parameters−境界データと有効なデータを使用してストアドプロシージャを呼び出します。各パラメータを一度無効にして、プロシージャを実行します。
Return values−ストアドプロシージャによって返される値を確認します。失敗した場合は、ゼロ以外を返す必要があります。
Error messages check−ストアドプロシージャが失敗するように変更を加え、すべてのエラーメッセージを少なくとも1回生成します。事前定義されたエラーメッセージがない場合は、例外シナリオを確認してください。
トリガーテスト
トリガーテストでは、テスターは次のタスクを実行する必要があります-
- トリガー名が正しいことを確認してください。
- 特定のテーブル列に対してトリガーが生成された場合は、トリガーを検証します。
- トリガーの更新検証。
- 有効なデータでレコードを更新します。
- 無効なデータでレコードを更新し、すべてのトリガーエラーをカバーします。
- 他のテーブルの行によってまだ参照されているときにレコードを更新します。
- 障害が発生したときにトランザクションをロールバックするようにします。
- トリガーがトランザクションをロールバックすることになっていないケースを見つけます。
サーバーセットアップスクリプト
2種類のテストを実行する必要があります-
- データベースを最初からセットアップし、
- 既存のデータベースをセットアップします。
SQLServerの統合テスト
統合テストは、コンポーネントのテストが終了した後に実行する必要があります。
ストアドプロシージャを集中的に呼び出して、さまざまなテーブルのレコードを選択、挿入、更新、および削除して、競合や非互換性を見つける必要があります。
スキーマとトリガー間の競合。
ストアドプロシージャとスキーマの間の競合。
ストアドプロシージャとトリガーの間の競合。
機能テスト方法
機能テストは、データベースを機能ごとにモジュールに分割することで実行できます。機能は次の2種類があります-
Type 1−タイプ1テストで、プロジェクトの機能を調べます。主要な機能ごとに、その関数の実装を担当するスキーマ、トリガー、およびストアドプロシージャを見つけて、それらを機能グループに入れます。次に、各グループを一緒にテストします。
Type 2−タイプ2のテストでは、バックエンドの官能基の境界は明らかではありません。データフローを確認して、どこでデータを確認できるかを確認できます。フロントエンドから開始します。
次のプロセスが実行されます-
サービスにリクエストがあるか、データを保存すると、一部のストアドプロシージャが呼び出されます。
プロシージャはいくつかのテーブルを更新します。
これらのストアドプロシージャはテストを開始する場所になり、これらのテーブルはテスト結果を確認する場所になります。
ストレステスト
ストレステストでは、主要なデータベース機能と対応するストアドプロシージャのリストを取得します。ストレステストについては、以下の手順に従ってください-
これらの関数を試すためのテストスクリプトを作成し、すべての関数をフルサイクルで少なくとも1回チェックする必要があります。
特定の期間、テストスクリプトを何度も実行します。
ログファイルを検証して、デッドロック、メモリ不足、データ破損などをチェックします。
ベンチマークテスト
データベースにデータの問題やバグがない場合は、システムのパフォーマンスを確認できます。以下に示すパラメータを確認することにより、ベンチマークテストでシステムパフォーマンスの低下を見つけることができます。
- システムレベルのパフォーマンス
- 最もよく使用される機能/機能を特定する
- タイミング–機能を実行するための最大時間、最小時間、および平均時間
- アクセスボリューム
フロントエンドを介したデータベースのテスト
バックエンドのバグは、フロントエンドのテストを行うことで見つかることもあります。以下の簡単な手順に従って、フロントエンドテストでバグを検出できます。
フロントエンドからクエリを作成し、検索を発行します。
既存のレコードを取得し、いくつかのフィールドの値を変更して、レコードを保存します。(これには、UPDATEステートメント、またはストアード・プロシージャーの更新、およびトリガーの更新が含まれます。)
フロントエンドウィンドウに新しいメニュー項目を挿入します。情報を入力し、レコードを保存します。(これには、INSERTステートメントまたは挿入ストアード・プロシージャーと削除トリガーが含まれます。)
既存のレコードを取得し、[削除]または[削除]ボタンをクリックして、削除を確認します。(これには、DELETEステートメントまたは削除ストアード・プロシージャーと削除トリガーが含まれます。)
無効なデータを使用してこれらのテストケースを繰り返し、データベースがどのように応答するかを確認します。
この章では、さまざまなテスト方法に関するいくつかの一般的なデータベーステストシナリオについて説明します。
構造化データベースのテスト
構造化データベーステストに関する一般的なデータベースシナリオを以下に示します。
データベースの名前の確認、データデバイス、ログデバイス、およびダンプデバイスの確認、各データベースに十分なスペースが割り当てられているかどうかの確認、およびデータベースオプションの設定の確認。
データベース内のすべてのテーブルの名前、各テーブルの列名、各テーブルの列タイプ、NULL値チェックの有無。各テーブルのキーとインデックスを確認します。各テーブルの主キー、各テーブルの外部キー。
外部キー列と他のテーブルの列の間のデータ型インデックス、クラスター化または非クラスター化一意または一意ではありません。
機能データベースのテスト
に関する一般的なデータベーステストシナリオ Functional Database Testing は−
その関数を実装し、それらを機能グループにするためのスキーマ、トリガー、およびストアドプロシージャを見つけて、各グループを一緒にテストできます。
データフローを確認し、データを確認できる場所を確認してください。フロントエンドから開始します。
非機能データベーステスト
に関する一般的なデータベーステストシナリオ Non-Functional Database Testing は−
主要な機能を試すためのテストスクリプトを作成し、すべての機能をフルサイクルで少なくとも1回チェックする必要があります。
特定の期間、テストスクリプトを何度も実行します。
ログファイルを検証して、デッドロック、メモリ不足、データ破損などをチェックします。
フロントエンドからクエリを作成し、検索を発行します。既存のレコードを取得し、いくつかのフィールドの値を変更して、レコードを保存します。(これには、UPDATEステートメントまたはストアード・プロシージャーの更新、トリガーの更新が含まれます。)
フロントエンドウィンドウに新しいメニュー項目を挿入します。情報を入力し、記録を保存します。(これには、INSERTステートメントまたは挿入ストアード・プロシージャー、削除トリガーが含まれます。)
既存のレコードを取得し、[削除]または[削除]ボタンをクリックして、削除を確認します。(これには、DELETEステートメントまたはストアドプロシージャの削除、削除トリガーが含まれます。)
無効なデータを使用してこれらのテストケースを繰り返し、データベースがどのように応答するかを確認します。
Schemas、 tables、 stored procedures、および Triggersデータベースの主要なオブジェクトです。これらのデータベースオブジェクトのDBテストタイプとテストシナリオはすでに共有しています。
スキーマ
データベーススキーマは、データベース管理システムでサポートされている形式でデータベースシステムの構造を定義します。スキーマとは、データベースがどのように構造化されているかを指します(リレーショナルデータベースの場合はデータベーステーブルで構成されます)。
データベーススキーマは、データベースに課せられる整合性制約と呼ばれる一連の式です。これらの整合性制約により、スキーマの各部分間の互換性が保証されます。
リレーショナルデータベースでは、スキーマはテーブル、フィールド、ビュー、インデックス、パッケージ、プロシージャ、関数、トリガー、タイプ、マテリアライズドビュー、シノニム、データベースリンク、およびその他の要素で構成されます。
スキーマは通常、データディクショナリに格納されます。スキーマはテキストデータベース言語で定義されていますが、この用語はデータベース構造のグラフィカルな描写を指すためによく使用されます。言い換えると、スキーマはデータベース内のオブジェクトを定義するデータベースの構造です。
データウェアハウスで使用されるスキーマの一般的なタイプは次のとおりです。
- スタースキーマ
- 雪片スキーマ
- ギャラクシースキーマ
データベース内のテーブル
リレーショナルデータベースでは、テーブルを使用して情報を行と列に編成します。
Example − Customerテーブルには、顧客ID、住所、電話番号などの情報が一連の列として含まれています。
単一のデータはそれぞれ、テーブル内のフィールドです。列は、すべての顧客の電話番号など、1つのフィールドのすべてのエントリで構成されます。フィールドはレコードとして編成されます。レコードは、情報の完全なセット(特定の顧客に関する情報のセットなど)であり、それぞれが行を構成します。
ストアドプロシージャ
ストアドプロシージャは、コンパイルされた形式でデータベースに格納された一連のSQLステートメントであり、複数のプログラムで共有できます。ストアドプロシージャの使用は、データの整合性、データ制御アクセスの維持、および生産性の向上に役立ちます。
トリガー
データベーストリガーは、データベース内の特定のテーブルまたはビューの特定のイベントに応答して実行されるコードです。トリガーは主に、データベース上の情報の整合性を維持するために使用されます。
データベースでは、データの整合性が重要です。これには、挿入、更新、および削除の前のデータ検証が含まれます。参照テーブルレコードを検証するには、トリガーを設定する必要があります。
データの整合性を確認するには、次の操作を実行する必要があります-
各テーブルの主要な列をチェックして、誤ったデータが存在するかどうかを確認する必要があります。(名前フィールドの文字、負のパーセンテージなど)
一貫性のないデータを見つけて関連するテーブルに挿入し、障害が発生するかどうかを確認します。
親のデータを挿入する前に、子データを挿入します。別のテーブルのデータによってまだ参照されているレコードを削除してみてください。
テーブル内のデータが更新された場合は、他の関連データも更新されているかどうかを確認してください。複製されたサーバーまたはデータベースが同期していて、一貫性のある情報が含まれていることを確認する必要があります。
データベース内のデータマッピングは、すべてのテスターが検証する必要がある重要な概念の1つです。通常、テスターは、ユーザーインターフェイスのフロントエンドフィールドと対応するバックエンドデータベースフィールドのマッピングを確認する必要があります。
この情報は、ソフトウェア要件仕様またはビジネス要件仕様SRS / BRSドキュメントに記載されています。マッピングが提供されていない場合は、コーディング部分を確認する必要があります。
フロントエンドアプリケーションでアクションを実行すると、対応するCRUDアクションが呼び出され、テスターは呼び出されたすべてのアクションが成功したかどうかを確認する必要があります。
データマッピングの重要な側面
以下に示すのは、データマッピングの重要な側面です。
UI /フロントエンドフォームのフィールドをチェックし、対応するDBテーブルと一貫してマッピングします。このマッピング情報は、上記の要件ドキュメントで定義されています。
アプリケーションのフロントエンドで実行されるアクションの場合、対応するCRUDの「作成、取得、更新、削除」アクションがバックエンドで開始されます。
テスターは、正しいアクションが呼び出され、呼び出されたアクション自体が成功したかどうかを確認する必要があります。
データマッピングテストの手順
以下に、データマッピングテストの手順を示します。
Step 1 −まず、各スクリプトの構文エラーをチェックします。
Step 2 −次に、テーブルマッピング、列マッピング、およびデータ型マッピングを確認します。
Step 3 −ルックアップデータのマッピングを確認します。
Step 4 −宛先テーブルにレコードが存在しない場合は、各スクリプトを実行します。
Step 5 −レコードが宛先テーブルにすでに存在する場合は、各スクリプトを実行します。
応答時間が長く、パフォーマンスが低いアプリケーションは、大きな問題を引き起こす可能性があります。データベース負荷テストは、エンドユーザー向けにデータベースアプリケーションを展開する前に、パフォーマンスの問題を見つけるために使用されます。
データベース負荷テストは、パフォーマンス、信頼性、およびスケーラビリティのためのデータベースアプリケーションの設計に役立ちます。データベースアプリケーションの負荷テストには、さまざまなユーザー負荷でデータベースアプリケーションのパフォーマンスとスケーラビリティをテストすることが含まれます。
データベース負荷テストには、ターゲットデータベースアプリケーションの実際のユーザー負荷のシミュレーションが含まれます。複数のユーザーが同時にヒットした場合のデータベースアプリケーションの動作を判断するのに役立ちます。
負荷テスト
負荷テストの主な目的は、実行中のほとんどのトランザクションがデータベースのパフォーマンスに影響を与えるかどうかを確認することです。負荷テストでは、次の側面を確認する必要があります-
複数のリモートユーザーのトランザクションを実行するための応答時間を確認する必要があります。
通常のトランザクションでは、これらのタイプのpfトランザクションのデータベースのパフォーマンスを確認するために、編集可能なトランザクションを1つ含める必要があります。
通常のトランザクションでは、これらのタイプのトランザクションのデータベースのパフォーマンスをチェックするために、編集しないトランザクションを1つ含める必要があります。
データベースが特定のレコードをフェッチするのにかかる時間を確認する必要があります。
ストレステスト
システムを特定するためにストレステストが実行されます breakpoint。ここでは、システムが一時的に失敗するような方法でアプリケーションがロードされます。このポイントは、データベースシステムのブレークポイントと呼ばれます。ストレステストは、Fatigue Testing。
データベーストランザクションの状態を判断するには、かなりの労力が必要です。時間とコストに基づく問題を回避するには、適切な計画が必要です。
最も一般的なストレステストツールは LoadRunner そして WinRunner。
テストデータの生成、テストデータの管理、負荷テストや回帰テストなどのデータベーステストの実行に使用できる、ベンダーが提供するさまざまなツールがあります。
使用されるいくつかの一般的なツールを以下に示します。
シニア番号 | カテゴリと説明 | 例 |
---|---|---|
1 | Load Testing Tools これらのツールは、データベースに高い使用負荷をかけるために使用されます。これにより、システムのランドスケープがビジネスニーズに対応できるかどうかを判断できます。 |
Webパフォーマンス ラッドビュー 水星 |
2 | Data Security Tools これらのツールは、情報セキュリティ規制に従ってコンプライアンスと標準を実装するために使用されます。 |
IBM OptimDataのプライバシー |
3 | Test Data generator tools テスターはこれらのツールを使用して、データベースシステムのテストデータを生成します。これらは主に、大量のデータがあり、DBテストを実行するためのサンプルが必要な場合に必要です。これは通常、負荷およびストレステストに使用されます。 |
データファクトリ DTMデータジェネレータ ターボデータ |
4 | Test Data Management Tool これらのツールは、テストデータのバージョン管理を維持するために使用されます。期待される結果を定義してから、それをテストの実際の結果と比較する必要があります。 |
IBM Optim Test Data Management |
5 | Tools to perform Unit Testing これらのツールは、データベースで回帰テストを実行するために使用されます。 |
SQLUnit TSQLUnit DBFit DBUnit |
組織の成長の最も重要な部分はそのデータです。システム障害が発生した場合は、データを復元する必要があります。バックアップはデータベースの正確なコピーであり、データが失われた場合にデータを復元するのに役立ちます。
A / C番号、顧客名、貸方と借方、期間など、顧客に関連するデータを持っている金融会社を考えてみましょう。そのような組織は、データ障害が発生した場合にそのような重要な情報を失うというプレッシャーにどのように対処しますか?
これが、データをバックアップする理由です。これにより、ディスクやディスクコントローラなどに障害が発生した場合に、バックアップを利用してデータベースに復元できます。
データバックアップの種類
使用できるバックアップには2つのタイプがあります-
Physical Backups −物理バックアップには、Veritas Net Back、IBM Tivoli Managerなどのサードパーティのバックアップツールを使用したバックアップ、またはOSユーティリティを使用したユーザーマネージャーのバックアップが含まれます。
Logical Backups −データベースの論理バックアップには、テーブル、インデックス、プロシージャなどの論理オブジェクトのバックアップを取ることが含まれます。
Example −データバックアップを取るための一般的なツールの1つは Oracle Recovery Manager (RMAN) これは、データベースのバックアップを取るためのOracleユーティリティです。
RMAN 2つのコンポーネントで構成されています-
Target database バックアップが必要な対象。
RMAN クライアントは、データをバックアップするコマンドを実行するために使用されます。
BACKUP VALIDATEデータベースファイルの有効なバックアップを作成できるかどうかをテストするために使用されます。それは保証します-
- データベースの物理オブジェクトまたは論理オブジェクトのバックアップが実施されている場合。
- 貴重なデータに対して定期的なバックアップが設定されている場合。
- バックアップツールが組織のバックアップ要件を満たしているかどうか。
Database recovery testingデータベースが確実に回復されるようにするために使用されます。回復テストでは、アプリケーションが適切に実行されているかどうかを確認し、回復方法が適切に設定されていない場合に失われる可能性のある貴重なデータの取得を確認できます。
また、いくつかの重要なプロセスがスムーズに実行されているかどうかを確認して、データ回復がテストフェーズをスムーズに通過することを確認します。
データベースの回復のために次のチェックを実行できます-
バックアップソフトウェアのエラーや間違い。これらの問題は早い段階で解決する必要があります。
緊急事態が発生した場合の対処方法がわかるように、回復テストを実施する必要があります。
効果的な回復戦略を計画できるように、回復テストのニーズを確認する必要があります。
また、ドキュメントを回復する方法も知っておく必要があります。
プロジェクトの初期段階で回復テストを実行する必要があります。これにより、システムからあらゆる種類のエラーを削除して破棄できます。テスト時に考慮すべき重要なポイントのリストを次に示します-
データベースシステムで変更または修正が発生する期間。
復旧計画を実行する期間。
データベースシステム内のデータの機密性。データが重要であるほど、ソフトウェアをより定期的にテストする必要があります。
データベースのバックアップとリカバリのテストにおける一般的な手順
データベース復旧テストでは、実際の環境でテストを実行して、ビジネス環境で災害やその他の予期しないイベントが発生した場合にシステムまたはデータを実際に復旧できるかどうかを確認する必要があります。
以下に示すのは、データベース回復テストで実行される一般的なアクションです。
- データベースシステムのテスト
- SQLファイルのテスト
- 部分ファイルのテスト
- データバックアップのテスト
- バックアップツールのテスト
- ログバックアップのテスト
データベースセキュリティテストは、セキュリティメカニズムの抜け穴を見つけるために、またデータベースシステムの脆弱性や弱点を見つけるために行われます。
データベースセキュリティテストの主な目的は、システムの脆弱性を見つけ、そのデータとリソースが潜在的な侵入者から保護されているかどうかを判断することです。セキュリティテストは、定期的に実行される場合に、潜在的な脆弱性を効果的に特定する方法を定義します。
データベースセキュリティテストを実行する主な目的は次のとおりです。
- Authentication
- Authorization
- Confidentiality
- Availability
- Integrity
- Resilience
データベースシステム上の脅威の種類
SQLインジェクション
これは、悪意のあるSQLステートメントがデータベースシステムに挿入され、データベースシステムから重要な情報を取得するために実行される、データベースシステムで最も一般的なタイプの攻撃です。この攻撃は、ユーザーアプリケーションの実装における抜け穴を利用します。これを防ぐには、ユーザー入力フィールドを慎重に処理する必要があります。
データベースでの権限昇格
この攻撃では、ユーザーはすでにデータベースシステムに何らかのアクセス権を持っており、データベースシステムで不正なアクティビティを実行できるように、このアクセス権をより高いレベルに上げようとするだけです。
サービス拒否
このタイプの攻撃では、攻撃者はデータベースシステムまたはアプリケーションリソースを正当なユーザーが利用できないようにします。また、アプリケーションは、アプリケーション、場合によってはマシン全体を使用できなくする方法で攻撃される可能性があります。
データへの不正アクセス
別のタイプの攻撃は、アプリケーションまたはデータベースシステム内のデータへの不正アクセスを取得することです。不正アクセスには以下が含まれます-
- ユーザーベースのアプリケーションを介したデータへの不正アクセス
- 他人のアクセスを監視することによる不正アクセス
- 再利用可能なクライアント認証情報への不正アクセス
アイデンティティのなりすまし
Identity Spoofingでは、ハッカーはユーザーまたはデバイスの資格情報を使用して、ネットワークホストに対する攻撃を開始したり、データを盗んだり、データベースシステムへのアクセス制御をバイパスしたりします。この攻撃を防ぐには、ITインフラストラクチャとネットワークレベルの緩和策が必要です。
データ操作
データ操作攻撃では、ハッカーがデータを変更して、何らかの利点を得たり、データベース所有者のイメージを傷つけたりします。
データベースセキュリティテスト手法
ペネトレーションテスト
ペネトレーションテストは、セキュリティの抜け穴を見つけ、その抜け穴、その機能、およびデータにアクセスする可能性があることを目的としたコンピュータシステムへの攻撃です。
リスク発見
リスク発見は、損失の種類と脆弱性の発生の可能性に関連するリスクを評価および決定するプロセスです。これは、さまざまなインタビュー、ディスカッション、分析によって組織内で決定されます。
SQLインジェクションテスト
これには、アプリケーションフィールドでのユーザー入力の確認が含まれます。たとえば、「、」、「;」などの特殊文字を入力します。ユーザーアプリケーションのテキストボックスへの入力は許可しないでください。データベースエラーが発生すると、ユーザー入力がクエリに挿入され、アプリケーションによって実行されることを意味します。このような場合、アプリケーションはSQLインジェクションに対して脆弱です。
攻撃者はサーバーデータベースから重要な情報にアクセスできるため、これらの攻撃はデータに対する大きな脅威です。WebアプリケーションへのSQLインジェクションエントリポイントを確認するには、いくつかのユーザー入力を受け入れることにより、データベースで直接MySQLクエリが実行されるコードベースからコードを見つけます。
SQLインジェクションテストは、ブラケット、コンマ、および引用符に対して実行できます。
パスワードクラッキング
これは、データベースシステムのテストを実行する際の最も重要なチェックです。重要な情報にアクセスするために、ハッカーはパスワードクラッキングツールを使用するか、一般的なユーザー名/パスワードを推測することができます。これらの一般的なパスワードはインターネットで簡単に入手でき、パスワードクラッキングツールも自由に存在します。
したがって、テスト時にパスワードポリシーがシステムで維持されているかどうかを確認する必要があります。銀行や金融のアプリケーションの場合、すべての重要な情報データベースシステムに厳格なパスワードポリシーを設定する必要があります。
データベースシステムのセキュリティ監査
セキュリティ監査は、企業のセキュリティポリシーを定期的に評価して、必要な基準が満たされているかどうかを判断するプロセスです。ビジネス要件に従ってさまざまなセキュリティ標準に従ってセキュリティポリシーを定義し、それらの標準に対して設定されたポリシーの評価を行うことができます。
最も一般的なセキュリティ標準の例は、ISO 27001、BS15999などです。
データベースセキュリティテストツール
市場にはさまざまなシステムテストツールがあり、OSやアプリケーションのチェックをテストするために使用できます。最も一般的なツールのいくつかを以下で説明します。
ZedAttackプロキシ
これは、Webアプリケーションの脆弱性を見つけるための侵入テストツールです。幅広いセキュリティ経験を持つ人々が使用するように設計されているため、侵入テストに不慣れな開発者や機能テスターに最適です。これは通常、Windows、Linux、MacOSで使用されます。
パロス
Cookieやフォームフィールドを含む、サーバーとクライアント間のすべてのHTTPおよびHTTPSデータは、これらのスキャナーを使用して傍受および変更できます。クロスプラットフォーム、Java JRE / JDK1.4.2以降で使用されます。
ソーシャルエンジニアツールキット
これはオープンソースツールであり、システム要素ではなく人的要素が攻撃されます。これにより、攻撃コードを含む電子メール、Javaアプレットなどを送信できます。Linux、Apple Mac OS X、およびMicrosoftWindowsに推奨されます。
スキップフィッシュ
このツールは、サイトの脆弱性をスキャンするために使用されます。ツールによって生成されたレポートは、専門的なWebアプリケーションのセキュリティ評価の基盤として機能することを目的としています。Linux、FreeBSD、MacOS X、およびWindowsに適しています。
ベガ
これは、SQLインジェクション、クロスサイトスクリプティング(XSS)、およびWebアプリケーションの他の脆弱性のインスタンスを見つけるために使用されるオープンソースのマルチプラットフォームWebセキュリティツールです。Java、Linux、およびWindowsに適しています。
ワピティ
Wapitiは、WebアプリケーションのWebページをスキャンし、データを挿入できるスクリプトとフォームをチェックする、オープンソースのWebベースのツールです。Pythonで構築されており、ファイル処理エラー、データベース、XSS、LDAPおよびCRLFインジェクション、コマンド実行検出を検出できます。
Webスカラブ
これはJavaで記述されており、HTTP / HTTPSプロトコルを介して通信するアプリケーションを分析するために使用されます。このツールは主に、自分でコードを記述できる開発者向けに設計されています。このツールはOSに依存しません。
データベーステストを正常に実行するには、テスターは技術要件や機能要件など、すべてのソースから要件を収集する必要があります。いくつかの要件が高レベルである可能性があるため、それらの要件を小さな部分に分割する必要があります。データベースのテストは複雑なタスクであり、テスターはこのテストを実行する際に多くの課題に直面します。最も一般的なデータベーステストの課題は次のとおりです。
テスト範囲が大きすぎます
テスターは、データベーステストでテスト項目を特定する必要があります。そうしないと、何をテストし、何をテストしないかを明確に理解できない可能性があります。したがって、要件を明確にすると、データベース内の重要でないオブジェクトのテストに多くの時間を浪費する可能性があります。
テストするオブジェクトのリストがある場合、次に、テストを設計し、各テスト項目のテストを実行するために必要な労力を見積もります。設計とデータサイズによっては、一部のデータベーステストの実行に時間がかかる場合があります。
データベースのサイズが大きすぎるため、テストする必要のあるオブジェクトと除外する必要のあるオブジェクトを見つけることが大きな課題になります。
縮小されたテストデータベース
通常、テスターには、テスト用の開発データベースのコピーが提供されます。そのデータベースには、アプリケーションを実行するのに十分なデータがほとんどありません。したがって、開発、ステージング、および本番データベースシステムをテストする必要があります。
データベース構造の変更
これは、DBテストにおける一般的な課題の1つです。テストを設計または実行し、その時点でデータベース構造が変更されている場合があります。これは、テスト中にデータベースに加えられた変更に注意する必要があります。
データベース構造が変更されたら、変更の影響を分析し、テストを変更する必要があります。さらに、複数のユーザーがテストデータベースを使用している場合、テスト結果について確信が持てないため、テストデータベースがテスト目的でのみ使用されていることを確認する必要があります。
DBテストのもう1つの課題は、複数のテストを同時に実行することです。少なくともパフォーマンステストでは、一度に1つのテストを実行する必要があります。データベースが複数のタスクを実行し、パフォーマンスを過少報告することは望ましくありません。
複雑なテスト計画
データベースの構造は通常複雑でデータが膨大であるため、不完全なテストや同じテストを繰り返し実行している可能性があります。したがって、テスト計画を作成し、それに応じて進行し、定期的に進捗状況を確認する必要があります。
SQLをよく理解している
データベースをテストするには、SQLクエリと必要なデータベース管理ツールに関する十分な知識が必要です。
データベーステストには、データの有効性、データの整合性テスト、データベースに関連するパフォーマンスチェック、およびデータベース内のプロシージャ、トリガー、機能のテストの実行が含まれます。
データベーステストが実行される理由は複数あります。バックエンドシステムはデータの保存を担当し、複数の目的でアクセスされるため、データベースでデータの整合性、検証、およびデータの整合性チェックを実行する必要があります。
データベーステストを実行する必要がある一般的な理由のいくつかは次のとおりです。
データベースバックエンドへの呼び出しの複雑さを緩和するために、開発者は View そして Stored 手順。
これら Stored 手順と Views顧客の詳細(名前、連絡先情報など)や販売データの挿入などの重要なタスクが含まれています。これらのタスクは、いくつかのレベルでテストする必要があります。
フロントエンドで実行されるブラックボックステストは重要ですが、問題を特定することは困難です。バックエンドシステムでテストすると、データの堅牢性が向上します。これが、データベーステストがバックエンドシステムで実行される理由です。
データベースでは、データは複数のアプリケーションから取得され、有害または不正確なデータがデータベースに保存される可能性があります。したがって、データベースコンポーネントを定期的にチェックする必要があります。さらに、データの整合性と整合性を定期的にチェックする必要があります。
データベーステストの実行中に実行する必要のある手順は次のとおりです。
- データベースにあるデータを確認する必要があります。
- 制約が維持されているかどうかを確認します。
- プロシージャのパフォーマンスとトリガーの実行を確認する必要があります。
- ロールバックしてトランザクションのコミットをチェックする必要があります。
データベースの機能と構造に基づいて、DBテストは次のカテゴリに分類できます-
Structural Database testing −テーブルと列のテスト、スキーマテスト、ストアドプロシージャとビューのテスト、トリガーのチェックなどを扱います。
Functional Testing−ユーザーの観点からデータベースの機能をチェックする必要があります。機能テストの最も一般的なタイプは、ホワイトボックステストとブラックボックステストです。
Nonfunctional Testing −負荷テスト、データベースでのリスクテスト、ストレステスト、最小システム要件が含まれ、データベースのパフォーマンスを向上させます。
ストアドプロシージャのテストを実行するために使用される最も一般的なツールは、LINQ、SPテストツールなどです。
結合は、論理的な方法で2つ以上のテーブルを接続するために使用されます。結合の一般的なタイプには、内部結合、非等結合、外部結合、自己結合、および相互結合が含まれます。
単一のテーブルをそれ自体に結合できます。この場合、同じテーブルを2回使用しています。
Step 1 −データベースに接続します
db_connect(query1 DRIVER {drivername};SERVER server_name;UID uidname;
PWD password;DBQ database_name );
Step 2 −データベースのクエリを実行します−
db_excecute_query (write the required query that is to execute); Specify the appropriate condition
Step 3 −を使用してデータベース接続を切断します
db_disconnect(query);
出力データベースチェックポイントを使用して、SQL手動クエリオプションを選択する必要があります。ここでは、selectクエリを記述できます。
まず、ストアドプロシージャの要件を確認します。次のステップは、ストアドプロシージャに記載されているテーブルと比較して、インデックス、結合、削除、更新が正しいかどうかを確認することです。
次に、次のタスクを実行します-
さまざまな入力パラメーターのセットについて、呼び出し元のプロシージャー名、呼び出し元のパラメーター、および予期される応答を検証します。
TOADまたはMySQLまたはQueryAnalyzerを使用して手順を実行します。
さまざまなパラメーターを送信して使用可能な手順を再実行し、期待値に対して結果を確認します。
プロセスを終了して、WinRunnerでテストを自動化します。
テスターは、EXECコマンドを使用してデータベース内のストアドプロシージャを呼び出す必要があります。パラメータが必要な場合は、それらを渡す必要があります。ストアドプロシージャが実行されるかどうかを確認するには、さまざまな値のパラメータを渡す必要があります。このコマンドを呼び出すときは、データベースの性質と動作を確認および検証する必要があります。
Example −ストアドプロシージャがテーブルにデータを入力するように記述されている場合は、テーブルの値を確認する必要があります。
SQLステートメントには3つのタイプがあります-
- データ操作言語(DML)
- データ定義言語(DDL)
- データ制御言語(DCL)
DDLステートメントは、データベース構造またはスキーマを定義するために使用されます。いくつかの例-
CREATE −データベースにオブジェクトを作成する
ALTER −データベースの構造を変更します
DROP −データベースからオブジェクトを削除します
演算子は、SQLステートメントで条件を指定し、ステートメントで複数の条件の接続詞として機能するために使用されます。
- 算術演算子
- 比較/関係演算子
- 論理演算子
- 演算子の設定
- 条件を否定するために使用される演算子
共用体は、2つ以上のSelectステートメントの結果を組み合わせるために使用されます。ただし、重複する行は削除されます。ユニオンは集合演算子です。
Union2つ以上のSelectステートメントの結果を組み合わせるために使用されます。ただし、重複する行は削除されます
Union All 操作はUnionに似ていますが、重複する行も表示されます。
トリガーは、データベースの整合性を維持するために使用されます。トリガーが起動されているかどうかを確認するには、監査ログを確認します。
トリガーはオンデマンドで呼び出すことはできません。それらは、それらが定義されているテーブルで関連するアクション(挿入、削除、および更新)が発生したときに呼び出されます。トリガーは、ビジネスルールの適用、監査、および参照整合性チェックに使用されます。
まず、機能要件を取得します。次に、テーブル構造、結合、カーソルとトリガー、使用されるストアドプロシージャ、およびその他のパラメーターを理解します。次に、これらのオブジェクトへの入力としてさまざまな値を使用してテストケースを作成できます。
DBテストには、ユーザーには表示されないバックエンドコンポーネントのテストが含まれます。これには、データベースコンポーネントとMySQLやOracleなどのDBMSシステムが含まれます。
フロントエンドテストでは、アプリケーションと、フォーム、グラフ、メニュー、レポートなどのコンポーネントの機能をチェックします。これらのコンポーネントは、VB.net、C#、Delphiなどのフロントエンド開発ツールを使用して作成されます。
データベーステストを実行するプロセスは、他のアプリケーションのテストと同様です。DBテストは、次の主要なプロセスで説明できます。
- 環境の設定
- テストを実行する
- テスト結果を確認する
- 期待される結果に従って検証する
- 調査結果をそれぞれの利害関係者に報告する
テストケースの開発には、さまざまなSQLステートメントが使用されます。DBテストの実行に使用される最も一般的なSQLステートメントはselectステートメントです。これとは別に、さまざまなDDL、DML、DCLステートメントも使用できます。
Example −作成、挿入、選択、更新など。
ビューは、それ自体では実際には存在しないテーブルですが、代わりに1つ以上のベーステーブルから派生します。つまり、ビューを直接表す保存ファイルはなく、代わりにビューの定義がデータディクショナリに保存されます。
ベーステーブルの拡大と再構築は、ビューには反映されません。したがって、ビューはデータベースの変更からユーザーを隔離できます。したがって、論理データの独立性を説明します。
ユーザービューとその概念スキーマへのマッピングを指定します。
これは、情報を失うことなく、テーブルを複数のテーブルに分解するプロセスです。正規化は、次の目標を達成するために行われます-
- 冗長性を最小限に抑えるため。
- 挿入、削除、更新の異常を最小限に抑えるため。
インデックス作成は、特定のデータをどれだけ迅速に見つけることができるかを判断するための手法です。クエリパフォーマンスの最適化に使用されます。インデックス作成には次のタイプがあります-
- 二分探索スタイルの索引付け
- Bツリーのインデックス作成
- 転置リストインデックス
- メモリ常駐テーブル
- テーブルのインデックス作成
SQLは、正規化されたリレーショナルデータベース構造でのデータアクセス操作用に特別に設計された構造化クエリ言語です。
SQLと他の従来のプログラミング言語との主な違いは、SQLステートメントは、実行方法ではなく、実行する必要のあるデータ操作を指定することです。
ストアドプロシージャは、ユーザー定義の操作を実行するために使用されます。ストアドプロシージャには、一連の複合SQLステートメントを含めることができます。ストアドプロシージャはSQLコマンドを実行し、結果をクライアントに返します。
PL / SQLは、すべてのデータベース情報アクセス文にカーソルを使用します。この言語は、暗黙と明示の2種類のカーソルの使用をサポートしています。
Cold Backup−コールドバックは、インスタンスのシャットダウン時にデータベースファイル、REDOログ、および制御ファイルをバックアップすることとして知られています。これはファイルのコピーであり、通常はディスクから直接テープにコピーされます。一貫したコピーを保証するには、インスタンスをシャットダウンする必要があります。
コールドバックアップが実行された場合、データファイルが失われた場合に使用できる唯一のオプションは、最新のバックアップからすべてのファイルを復元することです。最後のバックアップ後に実行されたすべての変更は失われます。
Hot Backup−一部のデータベースは、ファイルのバックアップコピーを作成しているときにシャットダウンできないため、コールドバックアップは使用できません。これらのタイプのデータベースには、ホットバックアップを使用します。
SQLサブクエリは、2つ以上のテーブルを同時にクエリする手段です。サブクエリ自体は、別のSQLSELECTステートメントのWHERE句内に含まれるSQLSELECTステートメントであり、括弧で囲まれて区切られています。一部のサブクエリには同等のSQL結合構造がありますが、相関サブクエリは結合によって複製できません
このような場合、次の側面をテストする必要があります-
- 多値従属性
- 機能従属性
- 候補キー
- 主キー
- 外部キー
データベースに移動して、関連するSQLクエリを実行できます。WinRunnerでは、データベースチェックポイント機能を使用できます。アプリケーションがビュー機能を提供している場合は、フロントエンドから同じことを確認できます。
データ駆動型テストは、アプリケーションが複数のテストデータでテストされる自動化テストプロセスとして定義されます。テスターがシステムの前に座って、フロントエンドインターフェイスから手動でさまざまな新しい入力値を入力する再テストよりもシンプルで簡単です。
テストケースを実行し、すでに検出されて修正されている欠陥を見つけたら。元の欠陥が正常に除去されたことを確認するために、異なる入力値を使用して同じテストを再実行することを、再テストと呼びます。
再テストはデータ駆動型テストとも呼ばれますが、わずかな違いがあります-
Retesting −これは手動テストプロセスですが、アプリケーションテストはまったく新しいデータセットを使用して行われます。
Data-driven Testing−これは、アプリケーションが複数のテストデータでテストされる自動化テストプロセスです。テスターがシステムの前に座って、フロントエンドインターフェイスから手動でさまざまな新しい入力値を入力する再テストよりもシンプルで簡単です。
データ駆動型テストには4つのタイプがあります-
- キーボードを介した動的テストデータの送信
- .txt、.docフラットファイルを介したデータ駆動型テスト
- フロントエンドオブジェクトを介したデータ駆動型テスト
- Excelシートによるデータ駆動型テスト
パフォーマンステストは、重いワークロードの下で速度、感度、および安定性の観点からシステムがどのように機能するかを判断するためのソフトウェアテスト手法です。
データベースリカバリテストを実行する際には、次の重要なポイントを考慮する必要があります。
データベースシステムで変更または修正が発生する期間。
復旧計画を実行する期間。
データベースシステム内のデータの機密性。データが重要であるほど、ソフトウェアをより定期的にテストする必要があります。
以下のツールを使用してテストデータを生成します-
- データファクトリ
- DTMデータジェネレータ
- ターボデータ
使用できるバックアップには2つのタイプがあります-
Physical Backups−物理バックアップには、Veritasネットバック、IBM Tivoli Manager、またはOSユーティリティーを使用したユーザーマネージャーバックアップなどのサードパーティバックアップツールを使用したバックアップが含まれます。
Logical Backups −データベースの論理バックアップには、テーブル、インデックス、プロシージャなどの論理オブジェクトのバックアップが含まれます。
データのバックアップを取るための一般的なツールは、データベースのバックアップを取るためのOracleユーティリティであるOracle Recovery Manager(RMAN)です。
データベースリカバリテストでは、次のアクションが実行されます-
- データベースシステムのテスト
- SQLファイルのテスト
- 部分ファイルのテスト
- データバックアップのテスト
- バックアップツールのテスト
- ログバックアップのテスト
データベースセキュリティテストは、セキュリティメカニズムの抜け穴を見つけるために、またデータベースシステムの脆弱性や弱点を見つけるために実行されます。
データベースのセキュリティテストは、次の側面をチェックするために実行されます-
- Authentication
- Authorization
- Confidentiality
- Availability
- Integrity
- Resilience
SQLインジェクションの脅威は、悪意のあるSQLステートメントがデータベースシステムに挿入され、データベースシステムから重要な情報を取得するために実行される、データベースシステムで最も一般的なタイプの攻撃です。この攻撃は、ユーザーアプリケーションの実装における抜け穴を利用します。このユーザー入力を防ぐには、フィールドを慎重に処理する必要があります。
データベースセキュリティテストの実行には、Zed Attack Proxy、Paros、Social Engineer Toolkit、Skipfish、Vega、Wapiti、およびWebScarabのツールを使用できます。
データベーステストの実行中に直面する一般的な課題は次のとおりです。
- テスト範囲が大きすぎます
- 縮小されたテストデータベース
- データベース構造の変更
- 複雑なテスト計画
- SQLをよく理解している