data warehouse testing tutorial with examples etl testing guide
このチュートリアルでは、データウェアハウステストの目標と重要性、ETLテストの責任、DWおよびETL展開のエラーについて詳しく説明します。
これで 詳細なデータウェアハウストレーニングシリーズ 、私たちは見ていた ETとは のデータウェアハウスでのLプロセス 詳細は前のチュートリアルで。
このチュートリアルでは、組織内でデータウェアハウステストを実行する方法について理解します。また、DWテストの目標、バックエンドで実行できるテストの方法と種類、このプロセスに関与するすべての人、DWエラー、およびETL展開について詳しく知ることができます。
=> ここですべてのデータウェアハウジングチュートリアルを確認してください。
ターゲットオーディエンス
- データウェアハウス/ ETL開発者およびテスター。
- データベースの概念に関する基本的な知識を持つデータベースの専門家。
- データウェアハウス/ ETLの概念を理解したいデータベース管理者/ビッグデータの専門家。
- データウェアハウスの仕事を探している大学卒業生/フレッシャーズ。
学習内容：
データウェアハウス（ETL）テスト
データウェアハウスとビジネスインテリジェンスシステムをテストすることの重要性は何ですか？
テストは、エンドユーザーの信頼を構築するデータの正確性を保証することにより、上記の2つのシステムのいずれかの成功に重要な役割を果たします。
一般に、ソフトウェア開発ライフサイクルの後の段階で見つかった欠陥は、その欠陥を修正するためにより多くの費用がかかります。 DWのこの状況は、後の段階で見つかった間違ったデータがその時点までに重要なビジネス上の意思決定に使用されていた可能性があるため、悪化する可能性があります。
したがって、DWでの修正は、プロセス、人員、およびテクノロジーの変更の点でより費用がかかります。要件収集フェーズから直接DWテストを開始できます。
要件のトレーサビリティマトリックスが作成およびレビューされ、これは主にDW機能をそれぞれのビジネス要件にマッピングします。トレーサビリティマトリックスは、テスターが作成するDWテスト計画への入力として機能します。テスト計画では、DWシステムを検証するために実行するテストについて説明します。
また、システムで実行されるテストの種類についても説明します。テスト計画の準備ができたら、すべての詳細なテストケースがさまざまなDWシナリオ用に準備されます。次に、すべてのテストケースが実行され、欠陥がログに記録されます。
運用の世界には、開発、テスト、および本番用にさまざまな環境を維持する標準があります。 DWの世界では、開発者とテスターの両方が、作業を開始する前に、本番データのレプリカで開発環境とテスト環境が利用可能であることを確認します。
これは、本番データが非常に大きいため、プロジェクトのニーズに応じてデータが制限されているか完全なテーブルのリストにコピーされます。開発者は、開発者の環境でコードを開発し、それをテスターに配信します。
テスターは、テスト環境で提供されたコードをテストして、すべてのシステムが機能しているかどうかを確認します。その後、コードは本番環境で公開されます。 DWコードは、各リリースで修正された欠陥に基づいて、さまざまなバージョンで維持されます。複数の環境とコードバージョンを維持することは、高品質のシステムを構築するのに役立ちます。
javaは配列から要素を削除します
データウェアハウス（ETL）テストの目標
データウェアハウステストの目標を見てみましょう。
＃1）データの完全性： さまざまなソースからのすべてのデータがデータウェアハウスにロードされていることを確認します。テストチームは、以下のサンプル戦略に従って、ソースデータベースとフラットファイルに対して、すべてのDWレコードがロードされているかどうかを検証します。
- ソースシステムからアップロードされたレコードカウントの総数は、DWにロードされたレコードの総数と一致する必要があります。違いがある場合は、拒否されたレコードについて考えることができます。
- DWの各フィールドにロードされたデータをソースシステムのデータフィールドと比較します。これにより、データエラーが発生します。
＃2）データ変換： ソースデータをデータウェアハウスにアップロードする際に、ソースデータを直接ロードできるフィールドはほとんどありませんが、ビジネスロジックに従って変換されたデータをロードするフィールドはほとんどありません。これは、DW（ETL）のテストの複雑な部分です。
以下は、これをテストするためのサンプル戦略です。
- スプレッドシートでデータを作成して比較することでテストできます。ソース変換されたデータとDWデータをスプレッドシートにロードし、比較を行います。不一致があってはなりません。
- テスターは、変換ロジックに従ってクエリを記述して、DWデータをソースデータと比較する必要があります。クエリを実行すると、どのフィールドのデータ検証も欠落していないことが保証されます。
＃3）データ品質： データウェアハウス（ETL）システムは、データを拒否（または）修正することにより、ロードされたデータの品質を保証する必要があります。
DWは 拒否する ビジネス要件ロジックに基づくソースシステムデータのいくつか。 例えば、 特定のフィールドに数値以外のデータがある場合、レコードを拒否します。拒否されたすべてのレコードは、参照用に拒否テーブルにロードされます。
拒否されたデータは、DWシステムにロードされないため、この失われたデータについて知る機会がないため、クライアントに報告されます。 DWは 正しい null値などの代わりにゼロをロードすることによるデータ。
＃4）スケーラビリティとパフォーマンス： データウェアハウスは、負荷の増加に伴ってシステムのスケーラビリティを確保する必要があります。これにより、クエリの実行中にパフォーマンスが低下することはなく、特定の時間枠で予想される結果が得られます。したがって、パフォーマンステストは問題を発見し、本番前に修正します。
以下は、パフォーマンスおよびスケーラビリティテストのサンプル戦略です。
- 実稼働ボリュームのデータをロードしてパフォーマンステストを実行し、時間枠を逃さないようにします。
- バルクデータを使用して各クエリのパフォーマンスを検証します。単純な結合と複数の結合を使用してパフォーマンスをテストします。
- システムの容量を概算するために予想されるデータの量に2倍（または）3倍の負荷をかけます。
- リストされているすべてのレポートのジョブを同時に実行してテストします。
＃5）統合テスト： データウェアハウスは、他のアップストリームおよびダウンストリームアプリケーションとの統合テストを実行する必要があります。可能であれば、統合テストのために本番データをテスト環境にコピーすることをお勧めします。
すべてのシステムチームは、すべてのシステムを一緒に理解してテストしながら、ギャップを埋めるためにこのフェーズに関与する必要があります。
＃6）ユニットテスト： これは、個々の開発者が成果物に対して実行します。開発者は、要件の理解に基づいて単体テストシナリオを準備し、単体テストを実行して、結果を文書化します。これは、開発者がコードをテストチームに配信する前に、バグが見つかった場合に修正するのに役立ちます。
＃7）回帰テスト： 欠陥を修正した後、DWシステムが誤動作していないことを検証します。これは、新しいコードが変更されるたびに何度も実行されます。
＃8）ユーザー受け入れテスト： このテストは、システム機能を検証するためにビジネスユーザーによって実行されます。 UAT環境はQA環境とは異なります。 UATからのサインオフは、コードを本番環境に移行する準備ができていることを意味します。
オープンソースのRESTAPIテストツール
データウェアハウスとビジネスインテリジェンスシステムの観点から、ビジネスユーザーはユーザーインターフェイス（UI）を介してさまざまなレポートを検証できます。レポートの仕様を要件に照らして検証したり、レポート内のデータの正確性を検証したり、システムが結果を返す速度を検証したりできます。
DWテストのフロー図：
データウェアハウスのテスト責任
以下に、成功するDWシステムの提供に関与するさまざまなチームを示します。
- ビジネスアナリスト： システムのすべてのビジネス要件を収集し、すべての人の好みに合わせて文書化します。
- インフラストラクチャチーム： 開発者とテスターの両方の必要に応じて、さまざまな環境をセットアップします。
- 開発者： 要件に従ってETLコードを開発し、単体テストを実行します。
- QA（品質保証）/テスター： テスト計画、テストケースなどを作成します。テストケースを実行することにより、システムの欠陥を特定します。さまざまなレベルのテストを実行します。
- DBA： DBAは、論理ETLデータベースシナリオから物理ETLデータベースシナリオへの変換を担当し、パフォーマンステストにも関与します。
- ビジネスユーザー： ユーザー受け入れテストに参加し、DWテーブルでクエリとレポートを実行します。
データウェアハウスのエラー
複数のソースから（ETL）データを抽出、変換、およびロードしている場合、長時間実行されているジョブを中止する可能性のある不良データを取得する可能性があります。
DWシステムの障害の主な原因は次のとおりです。
＃1）ビジネスルール違反（論理エラー）： 論理的に間違ったデータはビジネスルールに違反します。このようなデータは、主に変換フェーズまたはロードフェーズで処理できます。
＃2）データルール違反（データエラー）： データタイプの不一致、データ制約の失敗など、DWデータベースシステム内でデータエラーが発生します。
ETL展開
これは、すべての努力が実行されるフェーズです。すべての生産サポートドキュメントを準備する必要があります。
ドキュメントには、実行するジョブのシーケンス、障害回復シナリオ、展開後にシステムを監視するためのDWサポートチーム、およびレポートを実行するための管理サポートチームへのトレーニング資料が記載されています。
結論
このチュートリアルでは、データウェアハウステストの目標、ETLテストの責任、DWのエラー、およびETL展開について詳しく学習しました。
データウェアハウス（ETL）システムで詳細なテストを実行する方法を理解していただければ幸いです。
=> ゼロからデータウェアハウジングを学ぶには、こちらにアクセスしてください。