ETL テストのチュートリアル

ETLテストとは何ですか?

ETL テストは、ビジネス変革後にソースから宛先にロードされたデータが正確であることを確認するために実行されます。 また、ソースと宛先の間で使用されるさまざまな中間段階でのデータの検証も含まれます。 ETLは抽出-変換-ロードの略です。

ETL テスト

データウェアハウスのテスト

データウェアハウスのテスト は、企業のデータ フレームワークに準拠するために、データ ウェアハウス内のデータの完全性、信頼性、正確性、一貫性をテストするテスト方法です。 データ ウェアハウス テストの主な目的は、データ ウェアハウス内の統合データが企業が意思決定を行うのに十分な信頼性があることを確認することです。

ETLとは何ですか?

ETL は Extract-Transform-Load の略で、データがソース システムからデータ ウェアハウスにロードされる方法のプロセスです。 データは OLTP データベースから抽出され、データ ウェアハウス スキーマに一致するように変換されて、データ ウェアハウス データベースにロードされます。 多くのデータ ウェアハウスには、テキスト ファイル、レガシー システム、スプレッドシートなどの非 OLTP システムからのデータも組み込まれています。

どのように機能するかを見てみましょう

たとえば、販売、マーケティング、物流などのさまざまな部門がある小売店があります。各部門は顧客情報を独立して処理しており、そのデータの保存方法もまったく異なります。 営業部門は顧客名ごとに保管し、マーケティング部門は顧客 ID ごとに保管しています。

ここで、顧客の履歴を確認し、彼/彼女が購入したさまざまな製品を知りたい場合は、wing さまざまなマーケティングキャンペーンへ。 とても面倒でしょう。

解決策は、 データウェアハウス ETL を使用して、さまざまなソースからの情報を均一な構造で保存します。 ETL は、異なるデータセットを統一された構造に変換できます。Later BI ツールを使用して、このデータから有意義な洞察とレポートを導き出します。

次のことwing この ETL テスト チュートリアルの図は、ETL テスト プロセス フローとさまざまな ETL テストのロード マップを示します。 concepts:

抽出-変換-読み込み

  1. エキス
  • 関連データの抽出
  1. 最適化の適用
  • データを DW (データ ウェアハウス) 形式に変換する
  • ビルド キー – キーは、エンティティを一意に識別する XNUMX つ以上のデータ属性です。 様々な キーの種類 主キー、代替キー、外部キー、複合キー、代理キーです。 データウェアハウスはこれらのキーを所有しており、他のエンティティがキーを割り当てることを決して許可しません。
  • データのクレンジング : データが抽出された後、データのクレンジングと適合という次の段階に進みます。 クリーニングでは、データの欠落を除去するだけでなく、エラーを特定して修正します。 適合とは、互換性のないデータ間の競合を解決して、エンタープライズ データ ウェアハウスで使用できるようにすることを意味します。 これらに加えて、このシステムはソース システムの問題を診断し、データ品質を向上させるために使用されるメタデータを作成します。
  1. 負荷
  • データをDW(データウェアハウス)にロードする
  • 集計の作成 – 集計の作成は合計ですmariで利用可能なデータの保存と保存 ファクトテーブル エンドユーザーのクエリのパフォーマンスを向上させるため。

ETL テストプロセス

他のテスト プロセスと同様に、ETL もさまざまなフェーズを通過します。 ETL テスト プロセスのさまざまなフェーズは次のとおりです。

ETL テストプロセス

ETL テストは XNUMX つの段階で実行されます

  1. データソースと要件の特定
  2. データ収集
  3. ビジネス ロジックと次元モデリングを実装する
  4. データの構築と入力
  5. ビルドレポート

ETL テストプロセス

ETL テストの種類

テストの種類 試験プロセス
製造検証テスト 「テーブル バランシング」または「本番調整」このタイプの ETL テストは、データが本番システムに移行されるときにデータに対して実行されます。 ビジネス上の意思決定をサポートするには、実稼働システム内のデータが正しい順序になっている必要があります。 情報 データ検証オプションは、本番システムがデータによって侵害されないことを保証するための ETL テストの自動化および管理機能を提供します。
ソースからターゲットへのテスト (検証テスト) このような種類のテストは、変換されたデータ値が期待されるデータ値であるかどうかを検証するために実行されます。
申し込み Upgrades このようなタイプの ETL テストは自動的に生成できるため、テスト開発時間を大幅に節約できます。 このタイプのテストでは、古いアプリケーションまたはリポジトリから抽出されたデータが、リポジトリまたは新しいアプリケーションのデータとまったく同じであるかどうかをチェックします。
メタデータのテスト メタデータのテストには、データ型チェック、データ長チェック、インデックス/制約チェックのテストが含まれます。
データ完全性テスト 予想されるすべてのデータがソースからターゲットにロードされていることを確認するために、データ完全性テストが行​​われます。 実行できるテストには、単純な変換または変換を行わない列のソースとターゲットの間でカウント、集計、および実際のデータを比較および検証するものがあります。
データ精度テスト このテストは、データが期待どおりに正確にロードされ、変換されていることを確認するために実行されます。
データ変換テスト 多くの場合、XNUMX つのソースを作成するだけではデータ変換を実現できないため、データ変換のテストが行​​われます。 SQL クエリを実行し、出力とターゲットを比較します。 変換ルールを検証するには、行ごとに複数の SQL クエリを実行する必要がある場合があります。
データ品質テスト データ品質テストには、構文テストと参照テストが含まれます。 ビジネスプロセス中の日付や注文番号によるエラーを回避するために、データ品質テストが行​​われます。

構文テスト: 無効な文字、文字パターン、大文字または小文字の順序の誤りなどに基づいて、ダーティ データをレポートします。

参照テスト: データ モデルに従ってデータをチェックします。 例: 顧客 ID

データ品質テストには、数値チェック、日付チェック、精度チェック、データ チェック、null チェックなどが含まれます。

増分ETLテスト このテストは、新しいデータを追加して、古いデータと新しいデータのデータ整合性をチェックするために実行されます。 増分テストでは、増分 ETL プロセス中に挿入と更新が期待どおりに処理されていることを検証します。
GUI/ナビゲーションのテスト このテストは、フロントエンド レポートのナビゲーションまたは GUI の側面をチェックするために行われます。

ETL テスト ケースの作成方法

ETL テストは、情報管理業界のさまざまなツールやデータベースに適用できる概念です。 ETL テストの目的は、ビジネス変革後にソースから宛先にロードされたデータが正確であることを確認することです。 また、ソースと宛先の間で使用されるさまざまな中間段階でのデータの検証も含まれます。

ETL テストの実行中に、ETL テスターが常に使用する XNUMX つのドキュメントは次のとおりです。

  1. ETL マッピング シート:ETL マッピング シートには、各列と参照テーブル内のそれらのルックアップを含む、ソース テーブルと宛先テーブルのすべての情報が含まれています。 ETL テストでは、ETL のどの段階でもデータを検証するために複数の結合を含む大規模なクエリを作成する必要があるため、ETL テスターは SQL クエリに慣れている必要があります。 ETL マッピング シートは、データ検証のためのクエリを作成する際に大きな助けとなります。
  2. ソース、ターゲットの DB スキーマ: マッピング シートの詳細を確認できるよう、手元に置いておく必要があります。

ETL テスト シナリオとテスト ケース

テストシナリオ テストケース
マッピングドキュメントの検証 マッピング ドキュメントに対応する ETL 情報が提供されているかどうかを確認します。 変更ログはすべてのマッピング ドキュメントで維持する必要があります。
検証
  1. ソースとターゲットのテーブル構造を、対応するマッピング ドキュメントと照合して検証します。
  2. ソース データ型とターゲット データ型は同じである必要があります
  3. ソースとターゲットの両方のデータ型の長さは同じである必要があります
  4. データフィールドのタイプと形式が指定されていることを確認してください
  5. ソースのデータ型の長さはターゲットのデータ型の長さ以上である必要があります
  6. テーブル内の列の名前をマッピング ドキュメントと照合して検証します。
制約の検証 特定のテーブルに対して制約が期待どおりに定義されていることを確認します
データの一貫性の問題
  1. 特定の属性のデータ型と長さは、ファイルまたはテーブル内で異なる場合がありますが、セマンティック定義は同じです。
  2. 整合性制約の悪用
完全性の問題
  1. 予期されるすべてのデータがターゲット テーブルにロードされていることを確認してください。
  2. ソースとターゲットのレコード数を比較します。
  3. 拒否されたレコードがないか確認する
  4. ターゲットテーブルの列でデータが切り捨てられないことを確認してください
  5. チェック境界値解析
  6. カンプares 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 バグの種類

ETL バグの種類

バグの種類 Description
ユーザーインターフェイスのバグ/外観上のバグ
  • アプリケーションのGUI関連
  • フォントスタイル、フォントサイズ、色、配置、スペルミス、ナビゲーションなど
境界値解析 (BVA) 関連のバグ
  • 最小値と最大値
同値クラス分割 (ECP) 関連のバグ
  • 有効なタイプと無効なタイプ
入出力のバグ
  • 有効な値は受け入れられません
  • 無効な値が受け入れられました
計算のバグ
  • 数学的エラー
  • 最終出力が間違っている
ロード条件のバグ
  • 複数のユーザーを許可しません
  • 顧客が期待する負荷を許可しない
競合状態のバグ
  • システムのクラッシュとハング
  • システムはクライアント プラットフォームを実行できません
バージョン管理のバグ
  • 一致するロゴがありません
  • バージョン情報がありません
  • これは通常、次のような状況で発生します。 回帰テスト
ハードウェアのバグ
  • デバイスがアプリケーションに応答していません
ヘルプソースのバグ
  • ヘルプドキュメントの間違い

データベーステストとETLテストの違い

ETL テスト データベースのテスト
データが期待どおりに移動されたかどうかを検証します 主な目的は、データが次のとおりであるかどうかを確認することです。wing データモデルで定義されたルール/標準
ソースとターゲットのカウントが一致しているかどうかを検証します

変換されたデータが期待どおりであるかどうかを検証します

孤立したレコードがなく、外部キーと主キーの関係が維持されていることを確認します。
ETL中に外部主キー関係が保持されていることを検証します。 冗長なテーブルがなく、データベースが最適に正規化されていることを検証します。
ロードされたデータの重複を検証します 必要な列にデータが欠落していないかどうかを確認する

ETL テスターの責任

ETL テスターの主な責任は XNUMX つのカテゴリに分類されます

  • ステージテーブル/SFSまたはMFS
  • ビジネス変革ロジックの適用
  • 変換の適用後にステージ ファイルまたはテーブルからロードされるターゲット テーブル。

ETL テスターの責任には次のようなものがあります。

  • ETL ソフトウェアをテストする
  • ETL データウェアハウスのテスト コンポーネント
  • バックエンドのデータ駆動型テストを実行する
  • 作成、設計、実行 テストケース、テスト計画とテスト ハーネス
  • 問題を特定し、潜在的な問題に対する解決策を提供する
  • 要件と設計仕様の承認
  • データ転送とフラット ファイルのテスト
  • カウントテストなどのさまざまなシナリオ向けの SQL クエリ 3 の作成

ETL でのパフォーマンス テスト

ETL でのパフォーマンス テスト ETL システムが複数のユーザーとトランザクションの負荷を処理できることを確認するテスト手法です。 ETL の主な目標 性能試験 パフォーマンスのボトルネックを特定して排除することで、セッションのパフォーマンスを最適化および改善することです。 ソースおよびターゲットのデータベース、マッピング、セッション、およびシステムにパフォーマンスのボトルネックがある可能性があります。

パフォーマンスのテスト/チューニングに使用される最適なツールの XNUMX つは Informatica です。

ETLテストの自動化

ETL テストの一般的な方法論は、SQL スクリプトを使用するか、データの「目視調査」を行うことです。ETL テストへのこれらのアプローチは時間がかかり、エラーが発生しやすく、完全な結果が得られることはほとんどありません。 テストカバレッジ。 加速、カバレッジの向上、コストの削減、改善のため 欠陥 実稼働環境および開発環境における ETL テストの検出率の向上により、自動化が時代のニーズとなっています。 そのようなツールの XNUMX つが Informatica です。

ETL テストのベスト プラクティス

  1. データが正しく変換されていることを確認してください
  2. データの損失や切り捨てを行わずに、予測データをデータ ウェアハウスにロードする必要があります。
  3. ETL アプリケーションが適切に拒否してデフォルト値に置き換え、無効な​​データを報告することを確認します。
  4. スケーラビリティとパフォーマンスを確認するために、規定および予想される時間枠内にデータがデータ ウェアハウスにロードされていることを確認する必要がある
  5. 可視性に関係なく、すべてのメソッドに適切な単体テストが必要です
  6. 有効性を測定するには、すべての単体テストで適切なカバレッジ手法を使用する必要があります。
  7. テスト ケースごとに XNUMX つのアサーションを目指します
  8. 創造する 単体テスト 例外を対象とする

チェックアウト - ETL テストの面接の質問と回答