ETL テストのチュートリアル
デビッドカーター
ETLテストとは何ですか?
ETL テストは、ビジネス変革後にソースから宛先にロードされたデータが正確であることを確認するために実行されます。 また、ソースと宛先の間で使用されるさまざまな中間段階でのデータの検証も含まれます。 ETLは抽出-変換-ロードの略です。
データウェアハウスのテスト
データウェアハウスのテスト は、企業のデータ フレームワークに準拠するために、データ ウェアハウス内のデータの完全性、信頼性、正確性、一貫性をテストするテスト方法です。 データ ウェアハウス テストの主な目的は、データ ウェアハウス内の統合データが企業が意思決定を行うのに十分な信頼性があることを確認することです。
ETLとは何ですか？
ETL は Extract-Transform-Load の略で、データがソース システムからデータ ウェアハウスにロードされる方法のプロセスです。 データは OLTP データベースから抽出され、データ ウェアハウス スキーマに一致するように変換されて、データ ウェアハウス データベースにロードされます。 多くのデータ ウェアハウスには、テキスト ファイル、レガシー システム、スプレッドシートなどの非 OLTP システムからのデータも組み込まれています。
どのように機能するかを見てみましょう
たとえば、販売、マーケティング、物流などのさまざまな部門がある小売店があります。各部門は顧客情報を独立して処理しており、そのデータの保存方法もまったく異なります。 営業部門は顧客名ごとに保管し、マーケティング部門は顧客 ID ごとに保管しています。
顧客の履歴を確認し、さまざまなマーケティング キャンペーンによって顧客が購入したさまざまな製品を知りたい場合、それは非常に面倒な作業になります。
解決策は、 データウェアハウス ETL を使用して、さまざまなソースからの情報を均一な構造で保存します。 ETL は、異なるデータセットを統一された構造に変換できます。Later BI ツールを使用して、このデータから有意義な洞察とレポートを導き出します。
この ETL テスト チュートリアルの次の図は、ETL テスト プロセス フローのロード マップとさまざまな ETL テストの概念を示しています。
- エキス
- 関連データの抽出
- 最適化の適用
- データを DW (データ ウェアハウス) 形式に変換する
- ビルド キー – キーは、エンティティを一意に識別する XNUMX つ以上のデータ属性です。 様々な キーの種類 主キー、代替キー、外部キー、複合キー、代理キーです。 データウェアハウスはこれらのキーを所有しており、他のエンティティがキーを割り当てることを決して許可しません。
- データのクレンジング : データが抽出された後、データのクレンジングと適合という次の段階に進みます。 クリーニングでは、データの欠落を除去するだけでなく、エラーを特定して修正します。 適合とは、互換性のないデータ間の競合を解決して、エンタープライズ データ ウェアハウスで使用できるようにすることを意味します。 これらに加えて、このシステムはソース システムの問題を診断し、データ品質を向上させるために使用されるメタデータを作成します。
- 負荷
- データをDW（データウェアハウス）にロードする
- 集計の作成 – 集計の作成とは、利用可能なデータを要約して保存することです。 ファクトテーブル エンドユーザーのクエリのパフォーマンスを向上させるため。
ETL テストプロセス
他のテスト プロセスと同様に、ETL もさまざまなフェーズを通過します。 ETL テスト プロセスのさまざまなフェーズは次のとおりです。
ETL テストは XNUMX つの段階で実行されます
- データソースと要件の特定
- データ収集
- ビジネス ロジックと次元モデリングを実装する
- データの構築と入力
- ビルドレポート
ETL テストの種類
| テストの種類 | 試験プロセス |
|---|---|
| 製造検証テスト | 「テーブル バランシング」または「本番調整」このタイプの ETL テストは、データが本番システムに移行されるときにデータに対して実行されます。 ビジネス上の意思決定をサポートするには、実稼働システム内のデータが正しい順序になっている必要があります。 情報 データ検証オプションは、本番システムがデータによって侵害されないことを保証するための ETL テストの自動化および管理機能を提供します。 |
| ソース Target テスト（検証テスト） | このような種類のテストは、変換されたデータ値が期待されるデータ値であるかどうかを検証するために実行されます。 |
| 申し込み Upgrades | このようなタイプの ETL テストは自動的に生成できるため、テスト開発時間を大幅に節約できます。 このタイプのテストでは、古いアプリケーションまたはリポジトリから抽出されたデータが、リポジトリまたは新しいアプリケーションのデータとまったく同じであるかどうかをチェックします。 |
| メタデータのテスト | メタデータのテストには、データ型チェック、データ長チェック、インデックス/制約チェックのテストが含まれます。 |
| データ完全性テスト | 予想されるすべてのデータがソースからターゲットにロードされていることを確認するために、データ完全性テストが行われます。 実行できるテストには、単純な変換または変換を行わない列のソースとターゲットの間でカウント、集計、および実際のデータを比較および検証するものがあります。 |
| データ精度テスト | このテストは、データが期待どおりに正確にロードされ、変換されていることを確認するために実行されます。 |
| データ変換テスト | 多くの場合、XNUMX つのソースを作成するだけではデータ変換を実現できないため、データ変換のテストが行われます。 SQL クエリを実行し、出力とターゲットを比較します。 変換ルールを検証するには、行ごとに複数の SQL クエリを実行する必要がある場合があります。 |
| データ品質テスト | データ品質テストには、構文テストと参照テストが含まれます。 ビジネスプロセス中の日付や注文番号によるエラーを回避するために、データ品質テストが行われます。
構文テスト: 無効な文字、文字パターン、大文字または小文字の順序の誤りなどに基づいて、ダーティ データをレポートします。 参照テスト: データ モデルに従ってデータをチェックします。 例: 顧客 ID データ品質テストには、数値チェック、日付チェック、精度チェック、データ チェック、null チェックなどが含まれます。 |
| 増分ETLテスト | このテストは、新しいデータを追加して、古いデータと新しいデータのデータ整合性をチェックするために実行されます。 増分テストでは、増分 ETL プロセス中に挿入と更新が期待どおりに処理されていることを検証します。 |
| GUI/ナビゲーションのテスト | このテストは、フロントエンド レポートのナビゲーションまたは GUI の側面をチェックするために行われます。 |
ETL テスト ケースの作成方法
ETL テストは、情報管理業界のさまざまなツールやデータベースに適用できる概念です。 ETL テストの目的は、ビジネス変革後にソースから宛先にロードされたデータが正確であることを確認することです。 また、ソースと宛先の間で使用されるさまざまな中間段階でのデータの検証も含まれます。
ETL テストの実行中に、ETL テスターが常に使用する XNUMX つのドキュメントは次のとおりです。
- ETL マッピング シート:ETL マッピング シートには、各列と参照テーブル内のそれらのルックアップを含む、ソース テーブルと宛先テーブルのすべての情報が含まれています。 ETL テストでは、ETL のどの段階でもデータを検証するために複数の結合を含む大規模なクエリを作成する必要があるため、ETL テスターは SQL クエリに慣れている必要があります。 ETL マッピング シートは、データ検証のためのクエリを作成する際に大きな助けとなります。
- ソースのDBスキーマ、 Target: マッピング シートの詳細を確認できるよう、手元に置いておく必要があります。
ETL テスト シナリオとテスト ケース
| テストシナリオ | テストケース |
|---|---|
| マッピングドキュメントの検証 | マッピング ドキュメントに対応する ETL 情報が提供されているかどうかを確認します。 変更ログはすべてのマッピング ドキュメントで維持する必要があります。 |
| 検証 |
|
| 制約の検証 | 特定のテーブルに対して制約が期待どおりに定義されていることを確認します |
| データの一貫性の問題 |
|
| 完全性の問題 |
|
| 正確性の問題 |
|
| 変換 | 変換 |
| データ品質 |
|
| Null 検証 | 特定の列に「Not Null」が指定されている場合、NULL 値を確認します。 |
| 重複チェック |
|
| 日付の検証 | 日付値は、ETL 開発の多くの領域を使用します。
|
| 完全なデータ検証 |
|
| データのクリーンさ | ステージング領域にロードする前に、不要な列を削除する必要があります。 |
ETL バグの種類
| バグの種類 | Description |
|---|---|
| ユーザーインターフェイスのバグ/外観上のバグ |
|
| 境界値解析 (BVA) 関連のバグ |
|
| 同値クラス分割 (ECP) 関連のバグ |
|
| 入出力のバグ |
|
| 計算のバグ |
|
| ロード条件のバグ |
|
| 競合状態のバグ |
|
| バージョン管理のバグ |
|
| ハードウェアのバグ |
|
| ヘルプソースのバグ |
|
データベーステストとETLテストの違い
| ETL テスト | データベースのテスト |
|---|---|
| データが期待どおりに移動されたかどうかを検証します | 主な目的は、データがデータモデルで定義されたルール/標準に従っているかどうかを確認することです。 |
| ソースとターゲットのカウントが一致しているかどうかを検証します
変換されたデータが期待どおりであるかどうかを検証します |
孤立したレコードがなく、外部キーと主キーの関係が維持されていることを確認します。 |
| ETL中に外部主キー関係が保持されていることを検証します。 | 冗長なテーブルがなく、データベースが最適に正規化されていることを検証します。 |
| ロードされたデータの重複を検証します | 必要な列にデータが欠落していないかどうかを確認する |
ETL テスターの責任
ETL テスターの主な責任は XNUMX つのカテゴリに分類されます
- ステージテーブル/SFSまたはMFS
- ビジネス変革ロジックの適用
- Target 変換を適用した後、ステージ ファイルまたはテーブルからテーブルをロードします。
ETL テスターの責任には次のようなものがあります。
- ETL ソフトウェアをテストする
- ETL データウェアハウスのテスト コンポーネント
- バックエンドのデータ駆動型テストを実行する
- 作成、設計、実行 テストケース、テスト計画とテスト ハーネス
- 問題を特定し、潜在的な問題に対する解決策を提供する
- 要件と設計仕様の承認
- データ転送とフラット ファイルのテスト
- カウントテストなどのさまざまなシナリオ向けの SQL クエリ 3 の作成
ETL でのパフォーマンス テスト
ETL でのパフォーマンス テスト ETL システムが複数のユーザーとトランザクションの負荷を処理できることを確認するテスト手法です。 ETL の主な目標 性能試験 パフォーマンスのボトルネックを特定して排除することで、セッションのパフォーマンスを最適化および改善することです。 ソースおよびターゲットのデータベース、マッピング、セッション、およびシステムにパフォーマンスのボトルネックがある可能性があります。
パフォーマンスのテスト/チューニングに使用される最適なツールの XNUMX つは Informatica です。
ETLテストの自動化
ETL テストの一般的な方法論は、SQL スクリプトを使用するか、データの「目視調査」を行うことです。ETL テストへのこれらのアプローチは時間がかかり、エラーが発生しやすく、完全な結果が得られることはほとんどありません。 テストカバレッジ。 加速、カバレッジの向上、コストの削減、改善のため 欠陥 実稼働環境および開発環境における ETL テストの検出率の向上により、自動化が時代のニーズとなっています。 そのようなツールの XNUMX つが Informatica です。
ETL テストのベスト プラクティス
- データが正しく変換されていることを確認してください
- データの損失や切り捨てを行わずに、予測データをデータ ウェアハウスにロードする必要があります。
- ETL アプリケーションが適切に拒否してデフォルト値に置き換え、無効なデータを報告することを確認します。
- スケーラビリティとパフォーマンスを確認するために、規定および予想される時間枠内にデータがデータ ウェアハウスにロードされていることを確認する必要がある
- 可視性に関係なく、すべてのメソッドに適切な単体テストが必要です
- 有効性を測定するには、すべての単体テストで適切なカバレッジ手法を使用する必要があります。
- テスト ケースごとに XNUMX つのアサーションを目指します
- 創造する 単体テスト 例外を対象とする
チェックアウト - ETL テストの面接の質問と回答
