ETL テストのチュートリアル
デビッドカーター
ETLテストとは何ですか?
ETL テストは、ビジネス変革後にソースから宛先にロードされたデータが正確であることを確認するために実行されます。 また、ソースと宛先の間で使用されるさまざまな中間段階でのデータの検証も含まれます。 ETLは抽出-変換-ロードの略です。
データウェアハウスのテスト
データウェアハウスのテスト は、企業のデータ フレームワークに準拠するために、データ ウェアハウス内のデータの完全性、信頼性、正確性、一貫性をテストするテスト方法です。 データ ウェアハウス テストの主な目的は、データ ウェアハウス内の統合データが企業が意思決定を行うのに十分な信頼性があることを確認することです。
ETLとは何ですか？
ETL は Extract-Transform-Load の略で、データがソース システムからデータ ウェアハウスにロードされる方法のプロセスです。 データは OLTP データベースから抽出され、データ ウェアハウス スキーマに一致するように変換されて、データ ウェアハウス データベースにロードされます。 多くのデータ ウェアハウスには、テキスト ファイル、レガシー システム、スプレッドシートなどの非 OLTP システムからのデータも組み込まれています。
どのように機能するかを見てみましょう
たとえば、販売、マーケティング、物流などのさまざまな部門がある小売店があります。各部門は顧客情報を独立して処理しており、そのデータの保存方法もまったく異なります。 営業部門は顧客名ごとに保管し、マーケティング部門は顧客 ID ごとに保管しています。
顧客の履歴を確認し、さまざまなマーケティング キャンペーンによって顧客が購入したさまざまな製品を知りたい場合、それは非常に面倒な作業になります。
解決策は、 データウェアハウス ETL を使用して、さまざまなソースからの情報を均一な構造で保存します。 ETL は、異なるデータセットを統一された構造に変換できます。Later BI ツールを使用して、このデータから有意義な洞察とレポートを導き出します。
この ETL テスト チュートリアルの次の図は、ETL テスト プロセス フローのロード マップとさまざまな ETL テストの概念を示しています。
1) 抽出
- 関連データの抽出
2) 変換
- データを DW (データ ウェアハウス) 形式に変換する
- ビルド キー – キーは、エンティティを一意に識別する XNUMX つ以上のデータ属性です。 様々な キーの種類 主キー、代替キー、外部キー、複合キー、代理キーです。 データウェアハウスはこれらのキーを所有しており、他のエンティティがキーを割り当てることを決して許可しません。
- データのクレンジング : データが抽出された後、データのクレンジングと適合という次の段階に進みます。 クリーニングでは、データの欠落を除去するだけでなく、エラーを特定して修正します。 適合とは、互換性のないデータ間の競合を解決して、エンタープライズ データ ウェアハウスで使用できるようにすることを意味します。 これらに加えて、このシステムはソース システムの問題を診断し、データ品質を向上させるために使用されるメタデータを作成します。
3) ロード
- データを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 情報が提供されているかどうかを確認します。 変更ログはすべてのマッピング ドキュメントで維持する必要があります。 - 検証
テストケース：1) 対応するマッピング ドキュメントに対してソース テーブルとターゲット テーブルの構造を検証します。
2) ソースデータ型とターゲットデータ型は同じである必要があります
3) ソースとターゲットの両方のデータ型の長さは同じである必要があります
4) データフィールドの種類と形式が指定されていることを確認する
5) ソースデータ型の長さはターゲットデータ型の長さ以上である必要があります
6) マッピング ドキュメントに対してテーブル内の列の名前を検証します。 - 制約の検証
テストケース： 特定のテーブルに対して制約が期待どおりに定義されていることを確認します - データの一貫性の問題
テストケース：1) 特定の属性のデータ型と長さは、セマンティック定義は同じであっても、ファイルまたはテーブルごとに異なる場合があります。
2) 整合性制約の誤用 - 完全性の問題
テストケース：1) 予想されるすべてのデータがターゲット テーブルにロードされていることを確認します。
2) ソースとターゲットのレコード数を比較します。
3) 拒否されたレコードを確認する
4) 対象テーブルの列でデータが切り捨てられていないか確認する
5) 境界値解析をチェックする
6) WHにロードされたデータとソースデータ間のキーフィールドの一意の値を比較します。 - 正確性の問題
テストケース：1) スペルミスや不正確な記録があるデータ
2) NULL、一意でない、または範囲外のデータ - 変換
テストケース： 変換 - データ品質
テストケース：1) 番号チェック: 番号をチェックして検証する必要があります
2) 日付チェック: 日付の形式に従う必要があり、すべてのレコードで同じである必要があります。
3) 精度チェック
4) データチェック
5) ヌルチェック - Null 検証
テストケース： 特定の列に「Not Null」が指定されている場合、NULL 値を確認します。 - 重複チェック
テストケース：1) 一意のキー、主キー、その他の列は、重複する行がないかビジネス要件に従って一意であることを検証する必要があります。
2) ソース内の複数の列から抽出して XNUMX つの列に結合する列に重複する値が存在するかどうかを確認します。
3) クライアントの要件に従って、ターゲット内の複数の列の組み合わせで重複がないことを確認する必要があります。 - 日付の検証
テストケース： 日付値は、ETL 開発の多くの領域を使用します。1) 行の作成日を知る
2) ETL開発の観点からアクティブなレコードを識別する
3) ビジネス要件の観点からアクティブなレコードを特定する
4) 場合によっては、日付の値に基づいて更新と挿入が生成されることがあります。 - 完全なデータ検証
テストケース：1) 最適なソリューションでクエリを除いたソーステーブルとターゲットテーブルの完全なデータセットを検証する
2) ソースからターゲットを引いて、ターゲットからソースを引く必要があります
3) マイナスクエリが何らかの値を返す場合、それらは不一致の行とみなされる必要がある
4) intersect文を使用してソースとターゲットの行を一致させる必要がある
5) intersectによって返されるカウントは、ソーステーブルとターゲットテーブルの個々のカウントと一致する必要があります。
6) マイナス クエリが行を返し、交差数がソース数またはターゲット テーブルより少ない場合、重複行が存在するとみなすことができます。 - データのクリーンさ
テストケース： ステージング領域にロードする前に、不要な列を削除する必要があります。
ETL バグの種類
| バグの種類 | 詳細説明 |
|---|---|
| ユーザーインターフェイスのバグ/外観上のバグ |
• アプリケーションのGUIに関連する • フォントスタイル、フォントサイズ、色、配置、スペルミス、ナビゲーションなど |
| 境界値解析 (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 テストの面接の質問と回答
