database testing complete guide why
実用的なヒントと例を含むデータベーステストの完全ガイド：
最近のコンピューターアプリケーションは、Androidのようなテクノロジーや、多くのスマートフォンアプリを使用することでより複雑になっています。フロントエンドが複雑になるほど、バックエンドは複雑になります。
したがって、DBテストについて学び、データベースを効果的に検証して、データベースのセキュリティと品質を確保することがさらに重要になります。
このチュートリアルでは、データテストについてすべてを学びます–なぜ、どのように、そして何をテストするのですか？
データベースは、ソフトウェアアプリケーションの必然的な部分の1つです。
それがWeb、デスクトップ、モバイル、クライアントサーバー、ピアツーピア、エンタープライズ、または個人のビジネスであるかどうかは関係ありません。データベースはバックエンドのどこにでも必要です。
同様に、それがヘルスケア、金融、リース、小売、郵送アプリケーション、または宇宙船の制御であるかどうか。データベースは常に舞台裏で活動しています。
アプリケーションの複雑さが増すにつれて、より強力で安全なデータベースの必要性が浮上します。同様に、トランザクションの頻度が高いアプリケーションの場合（ 例えば、 銀行または金融アプリケーション）、フル機能のDBツールの必要性が組み合わされています。
今日では、従来のデータベースでは処理できない、大きくて複雑なビッグデータがあります。
いくつかあります データベースツール 市場で入手可能です 例えば、 MS-Access、MS SQL Server、SQL Server、Oracle、Oracle Financial、MySQL、PostgreSQL、DB2、Toad、Admirerなど。これらのツールは、コスト、堅牢性、機能、およびセキュリティが異なります。 それぞれの 独自の長所と短所があります。
学習内容：
なぜデータベースをテストするのですか？
以下に、DBの次の側面を検証する必要がある理由を示します。
＃1）データマッピング
ソフトウェアシステムでは、データはUI（ユーザーインターフェイス）とバックエンドDBの間を行き来することが多く、その逆もあります。したがって、これらは注意すべきいくつかの側面です。
- UI /フロントエンドフォームのフィールドがDBテーブルの対応するフィールドと一貫してマップされているかどうかを確認します。通常、このマッピング情報は要件ドキュメントで定義されています。
- アプリケーションのフロントエンドで特定のアクションが実行されるたびに、対応するCRUD（作成、取得、更新、および削除）アクションがバックエンドで呼び出されます。テスターは、正しいアクションが呼び出されたかどうか、および呼び出されたアクション自体が成功したかどうかを確認する必要があります。
＃2）ACIDプロパティの検証
原子性、一貫性、分離、および耐久性。 DBが実行するすべてのトランザクションは、これら4つのプロパティに準拠する必要があります。
- アトミシティ トランザクションが失敗または成功することを意味します。これは、トランザクションの一部が失敗した場合でも、トランザクション全体が失敗したことを意味します。通常、これは「オールオアナッシング」ルールと呼ばれます。
- 一貫性 ：トランザクションは常にDBの有効な状態になります
- 隔離 ：複数のトランザクションがあり、それらが一度に実行される場合、DBの結果/状態は、それらが次々に実行された場合と同じである必要があります。
- 耐久性 ：トランザクションが完了してコミットされると、電力損失やクラッシュなどの外部要因によってトランザクションが変更されることはありません。
推奨読書= >> MySQLトランザクションチュートリアル
＃3）データの整合性
のいずれかのために CRUD操作 、共有データの更新された最新の値/ステータスがすべてのフォームと画面に表示されます。ある画面で値を更新したり、別の画面で古い値を表示したりしないでください。
アプリケーションが実行中の場合、 エンドユーザーは主に、DBツールによって促進される「CRUD」操作を利用します 。
C：作成 –ユーザーが新しいトランザクションを「保存」すると、「作成」操作が実行されます。
R：取得 –ユーザーが保存されたトランザクションを「検索」または「表示」すると、「取得」操作が実行されます。
U：更新 –ユーザーが既存のレコードを「編集」または「変更」すると、DBの「更新」操作が実行されます。
D：削除 –ユーザーがシステムからレコードを「削除」すると、DBの「削除」操作が実行されます。
エンドユーザーによって実行されるデータベース操作は、常に上記の4つのうちの1つです。
したがって、DBテストケースを考案して、データが一貫して同じであるかどうかを確認するために、表示されるすべての場所でデータをチェックするようにします。
＃4）ビジネスルールの適合性
データベースがより複雑になるということは、リレーショナル制約、トリガー、ストアドプロシージャなどのより複雑なコンポーネントを意味します。したがって、テスターはこれらの複雑なオブジェクトを検証するために適切なSQLクエリを考え出す必要があります。
何をテストするか（データベーステストチェックリスト）
＃1）トランザクション
トランザクションをテストするときは、トランザクションがACIDプロパティを満たしていることを確認することが重要です。
一般的に使用されるステートメントは次のとおりです。
- トランザクショントランザクションの開始＃
- トランザクショントランザクションの終了＃
Rollbackステートメントは、データベースが一貫性のある状態を維持することを保証します。
- ロールバックトランザクション＃
これらのステートメントを実行した後、Selectを使用して、変更が反映されていることを確認します。
- SELECT * FROM TABLENAME
＃2）データベーススキーマ
データベーススキーマは、データがDB内でどのように編成されるかを正式に定義したものにすぎません。それをテストするには：
- データベースの運用に基づく要件を特定します。サンプル要件：
- 他のフィールドが作成される前に作成される主キー。
- 外部キーは、簡単に検索および検索できるように、完全にインデックス付けする必要があります。
- 特定の文字で開始または終了するフィールド名。
- 特定の値を挿入できる、または挿入できないという制約のあるフィールド。
- 関連性に応じて、次のいずれかの方法を使用します。
- SQLクエリ DESC
スキーマを検証します。
- 個々のフィールドの名前とその値を検証するための正規表現
- SchemaCrawlerのようなツール
＃3）トリガー
特定のテーブルで特定のイベントが発生すると、コードの一部（トリガー）を自動で実行するように指示できます。
例えば、 新入生が学校に入学しました。生徒は数学と科学の2つのクラスを受講しています。学生は「学生テーブル」に追加されます。トリガーは、学生が学生テーブルに追加されると、対応するサブジェクトテーブルに学生を追加できます。
テストする一般的な方法は、最初にトリガーに埋め込まれたSQLクエリを個別に実行し、結果を記録することです。これに続いて、トリガー全体を実行します。結果を比較します。
これらは、ブラックボックスとホワイトボックスの両方のテストフェーズでテストされます。
どのようにして製品テスターになりますか
- ホワイトボックステスト ：スタブとドライバーは、トリガーが呼び出される結果となるデータを挿入、更新、または削除するために使用されます。基本的な考え方は、フロントエンド（UI）との統合が行われる前であっても、DBだけをテストすることです。
- ブラックボックステスト ：
に） UIとDB以降、統合が可能になりました。トリガーが呼び出されるように、フロントエンドからデータを挿入/削除/更新できます。その後、Selectステートメントを使用してDBデータを取得し、トリガーが目的の操作の実行に成功したかどうかを確認できます。
b） これをテストする2番目の方法は、トリガーを呼び出すデータを直接ロードして、意図したとおりに機能するかどうかを確認することです。
＃4）ストアドプロシージャ
ストアドプロシージャは、ユーザー定義関数とほぼ同じです。これらは、Call Procedure / Execute Procedureステートメントによって呼び出すことができ、出力は通常、結果セットの形式になります。
これらはRDBMSに保存され、アプリケーションで使用できます。
これらは、次の期間にもテストされます。
- ホワイトボックステスト： スタブはストアドプロシージャを呼び出すために使用され、結果は期待値に対して検証されます。
- ブラックボックステスト： アプリケーションのフロントエンド（UI）から操作を実行し、ストアドプロシージャの実行とその結果を確認します。
＃5）フィールドの制約
デフォルト値、一意の値、および外部キー：
- データベースオブジェクトの条件を実行するフロントエンド操作を実行します
- SQLクエリを使用して結果を検証します。
特定のフィールドのデフォルト値を確認するのは非常に簡単です。これはビジネスルール検証の一部です。手動で行うことも、QTPなどのツールを使用することもできます。手動で、フロントエンドからフィールドのデフォルト値以外の値を追加するアクションを実行して、エラーが発生するかどうかを確認できます。
次に、VBScriptコードのサンプルを示します。
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) 上記のコードの結果は、デフォルト値が存在する場合はTrue、存在しない場合はFalseです。
一意の値の確認は、デフォルト値の場合とまったく同じ方法で実行できます。このルールに違反するUIから値を入力して、エラーが表示されるかどうかを確認してください。
AutomationVBスクリプトコードは次のようになります。
Function VBScriptRegularexpressionvlaidation(pattern , string_to_match) Set newregexp = new RegExp newregexp.Pattern = “” newregexp.Ignorecase = True newregexp.Global = True VBScriptRegularexpressionvlaidation = newregexp.Test(string_to_match) End Function Msgbox VBScriptRegularexpressionvlaidation(pattern , string_to_match) のために外部キー制約検証では、制約に違反するデータを直接入力するデータロードを使用して、アプリケーションがそれらを制限しているかどうかを確認します。バックエンドのデータロードに加えて、制約に違反する方法でフロントエンドのUI操作も実行し、関連するエラーが表示されるかどうかを確認します。
データテスト活動
データベーステスターは、次のテストアクティビティに焦点を当てる必要があります。
＃1）データマッピングを確認する：
データマッピングはデータベースの重要な側面の1つであり、すべてのソフトウェアテスターが厳密にテストする必要があります。
AUTのさまざまなフォームまたは画面とそのDBの間のマッピングが正確であるだけでなく、設計ドキュメント（SRS / BRS）またはコードごとであることを確認してください。基本的に、すべてのフロントエンドフィールドとそれに対応するバックエンドデータベースフィールドの間のマッピングを検証する必要があります。
すべてのCRUD操作について、ユーザーがアプリケーションのGUIから(保存)、(更新)、(検索)、または(削除)をクリックしたときに、それぞれのテーブルとレコードが更新されることを確認します。
確認する必要があるもの：
- テーブルマッピング、列マッピング、およびデータ型マッピング。
- ルックアップデータマッピング。
- UIでのすべてのユーザーアクションに対して、正しいCRUD操作が呼び出されます。
- CRUD操作は成功しました。
＃2）トランザクションのACIDプロパティを確認します。
DBトランザクションのACIDプロパティは、「 に トミシティ」、「 C 一貫性」、「 私 孤独」と「 D urability」。これらの4つのプロパティの適切なテストは、データベースのテストアクティビティ中に実行する必要があります。すべてのトランザクションがデータベースのACIDプロパティを満たしていることを確認する必要があります。
以下のSQLコードで簡単な例を見てみましょう。
CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));ACIDテストテーブルには、AとBの2つの列があります。AとBの値の合計は常に100である必要があるという整合性の制約があります。
アトミシティテスト このテーブルで実行されるトランザクションがすべてまたはまったくないことを確認します。つまり、トランザクションのいずれかのステップが失敗した場合、レコードは更新されません。
一貫性テスト 列AまたはBの値が更新されるたびに、合計が常に100のままになるようにします。合計が100以外の場合、AまたはBでの挿入/削除/更新は許可されません。
分離試験 2つのトランザクションが同時に発生し、ACIDテストテーブルのデータを変更しようとしている場合、これらのトラクションは分離して実行されます。
耐久性試験 このテーブルでのトランザクションがコミットされると、停電、クラッシュ、またはエラーが発生した場合でも、そのトランザクションがコミットされたままになります。
アプリケーションが分散データベースを使用している場合、この領域では、より厳密で徹底的かつ鋭敏なテストが必要です。
＃3）データの整合性を確保する
アプリケーションのさまざまなモジュール（つまり、画面またはフォーム）が同じデータをさまざまな方法で使用し、データに対してすべてのCRUD操作を実行することを考慮してください。
その場合は、最新のデータ状態が随所に反映されていることを確認してください。システムは、更新された最新の値、またはそのような共有データのステータスをすべてのフォームと画面に表示する必要があります。これはデータ整合性と呼ばれます。
データベースデータの整合性を検証するためのテストケース：
- 参照テーブルレコードを更新するためのすべてのトリガーが設定されているかどうかを確認します。
- 各テーブルの主要な列に不正な/無効なデータが存在するかどうかを確認します。
- テーブルに間違ったデータを挿入して、障害が発生するかどうかを確認してください。
- 親を挿入する前に子を挿入しようとするとどうなるかを確認します（主キーと外部キーで遊んでみてください）。
- 他のテーブルのデータによってまだ参照されているレコードを削除した場合に、障害が発生するかどうかをテストします。
- レプリケートされたサーバーとデータベースが同期しているかどうかを確認します。
＃4）実装されたビジネスルールの正確性を確保します。
今日、データベースはレコードを保存することだけを目的としたものではありません。実際、データベースは、開発者がDBレベルでビジネスロジックを実装するための十分なサポートを提供する非常に強力なツールに進化しました。
強力な機能の簡単な例としては、「参照整合性」、リレーショナル制約、トリガー、ストアドプロシージャなどがあります。
そのため、開発者はDBが提供するこれらの機能や他の多くの機能を使用して、DBレベルでビジネスロジックを実装します。テスターは、実装されたビジネスロジックが正しく、正確に機能することを確認する必要があります。
上記のポイントは、DBをテストするための4つの最も重要な「WhatTo」について説明しています。それでは、「ハウツー」の部分に移りましょう。
データベースをテストする方法（ステップバイステップのプロセス）
一般的なテストプロセステストデータベースは、他のアプリケーションとそれほど変わりません。
コアステップは次のとおりです。
ステップ1） 環境を整える
ステップ2） テストを実行する
ステップ3） テスト結果を確認する
ステップ4） 期待される結果に従って検証する
ステップ5） 調査結果をそれぞれの利害関係者に報告する
通常、SQLクエリはテストの開発に使用されます。最も一般的に使用されるコマンドは「選択」です。
どこから*を選択
Selectとは別に、SQLには3つの重要なタイプのコマンドがあります。
- DDL：データ定義言語
- DML：データ操作言語
- DCL：データ制御言語
最も一般的に使用されるステートメントの構文を見てみましょう。
データ定義言語 CREATE、ALTER、RENAME、DROP、およびTRUNCATEを使用して、テーブル（およびインデックス）を処理します。
データ操作言語 レコードを追加、更新、および削除するためのステートメントが含まれています。
データ制御言語： データの操作とアクセスをユーザーに許可することを扱います。 GrantとRevokeは、使用される2つのステートメントです。
構文の付与：
選択/更新を許可する
オン
に;構文を取り消す：
選択の取り消し/更新
オン
から;いくつかの実用的なヒント
＃1）自分でクエリを書く：
データベースを正確にテストするには、テスターはSQLおよびDML（データ操作言語）ステートメントについて十分な知識を持っている必要があります。テスターは、AUTの内部DB構造も知っている必要があります。
GUIとデータ検証をそれぞれのテーブルで組み合わせて、カバレッジを向上させることができます。 SQLサーバーを使用している場合は、SQLクエリアナライザーを使用して、クエリの作成、実行、および結果の取得を行うことができます。
これは、アプリケーションの複雑さが中小規模の場合にデータベースをテストするための最良かつ堅牢な方法です。
アプリケーションが非常に複雑な場合、テスターが必要なすべてのSQLクエリを作成するのは困難または不可能な場合があります。複雑なクエリの場合は、開発者の助けを借りてください。テストに自信があり、SQLスキルも向上するため、この方法を常にお勧めします。
＃2）各テーブルのデータを観察します。
CRUD操作の結果を使用してデータ検証を実行できます。これは、データベース統合がわかっている場合は、アプリケーションUIを使用して手動で実行できます。ただし、さまざまなデータベーステーブルに膨大なデータがある場合、これは面倒で面倒な作業になる可能性があります。
手動データテストの場合、データベーステスターはデータベーステーブル構造に関する十分な知識を持っている必要があります。
＃3）開発者からクエリを取得します。
これは、データベースをテストする最も簡単な方法です。 GUIからCRUD操作を実行し、開発者から取得したそれぞれのSQLクエリを実行してその影響を確認します。 SQLに関する十分な知識も、アプリケーションのDB構造に関する十分な知識も必要ありません。
ただし、この方法は慎重に使用する必要があります。開発者によって提供されたクエリが意味的に間違っているか、ユーザーの要件を正しく満たしていない場合はどうなりますか？プロセスは単にデータの検証に失敗します。
＃4）データベース自動化テストツールを利用する：
データテストプロセスに利用できるツールがいくつかあります。必要に応じて適切なツールを選択し、それを最大限に活用する必要があります。
=> これがあなたがチェックすべきトップDBテストツールのリストです
結論
データベースでテストするためのこれらすべての機能、要素、およびプロセスにより、テスターがデータベースの主要な概念に技術的に習熟していることがますます求められています。データベースのテストは新しいボトルネックを生み出し、多くの追加費用がかかるという否定的な信念にも関わらず、これは大きな注目と需要を集めているテストの領域です。
推奨読書= >> データベースセキュリティテストとは
このチュートリアルが、その理由に焦点を当てるのに役立ち、データベースのテストに必要な基本的な詳細も提供されたことを願っています。
DBテストに取り組んでいる場合は、フィードバックをお知らせください。また、個人的な経験も共有してください。
推奨読書
- JMeterを使用したデータベーステスト
- 40以上の最高のデータベーステストツール-人気のあるデータテストソリューション
- データベーステストへのXMLの簡単なアプローチ
- ETLテストデータウェアハウステストチュートリアル（完全ガイド）
- データ移行テストチュートリアル：完全ガイド
- 複雑なデータモデルを構築するためのトップ10データベース設計ツール
- 例を含むデータウェアハウステストチュートリアル| ETLテストガイド
- Oracleデータベースをテストする方法
^
- SQLクエリ DESC
