Etl-testing-quick-guide
ETLテスト–はじめに
データウェアハウスシステムのデータは、ETL（抽出、変換、ロード）ツールでロードされます。 名前が示すように、それは次の3つの操作を実行します-
- Oracle、Microsoft、またはその他のリレーショナルデータベースであるトランザクションシステムからデータを抽出します。
- データクレンジング操作を実行してデータを変換し、次に
- OLAPデータウェアハウスにデータをロードします。
また、ETLツールを使用してスプレッドシートやCSVファイルなどのフラットファイルからデータを抽出し、データ分析とレポートのためにOLAPデータウェアハウスにロードすることもできます。 例をよく理解してみましょう。
例
販売、人事、資材管理、EWMなどの複数の部門を持つ製造会社があると仮定しましょう。 これらすべての部門には、情報w.r.tを維持するために使用する個別のデータベースがあります。 彼らの仕事と各データベースには異なる技術、風景、テーブル名、列などがあります。 現在、企業が履歴データを分析してレポートを生成する場合は、これらのデータソースからすべてのデータを抽出してデータウェアハウスにロードし、分析作業のために保存する必要があります。
ETLツールは、これらすべての異種データソースからデータを抽出し、データを変換して（計算の適用、フィールド、キーの結合、不正なデータフィールドの削除など）、データウェアハウスにロードします。 後で、さまざまなビジネスインテリジェンス（BI）ツールを使用して、このデータを使用して意味のあるレポート、ダッシュボード、視覚化を生成できます。
ETLとBIツールの違い
ETLツールを使用して、さまざまなデータソースからデータを抽出し、データを変換し、DWシステムにロードします。ただし、BIツールを使用して、エンドユーザー向けのインタラクティブでアドホックなレポート、上級管理職向けのダッシュボード、月次、四半期、および年次の取締役会のデータ視覚化を生成します。
最も一般的なETLツールには、SAP BOデータサービス（BODS）、Informatica – Power Center、Microsoft – SSIS、Oracle Data Integrator ODI、Talend Open Studio、Clover ETL Open sourceなどが含まれます。
人気のあるBIツールには、SAP Business Objects、SAP Lumira、IBM Cognos、JasperSoft、Microsoft BI Platform、Tableau、Oracle Business Intelligence Enterprise Editionなどがあります。
ETLプロセス
ここで、ETL手順に含まれる重要な手順についてもう少し詳しく説明します-
データの抽出
異なる異種データソースからデータを抽出する必要があります。 トランザクションシステムからのデータ抽出は、要件と使用中のETLツールによって異なります。 通常、夜間や週末にジョブを実行するなど、営業時間外にスケジュールされたジョブを実行することによって行われます。
データの変換
データをDWシステムに簡単にロードできる適切な形式に変換する必要があります。 データ変換には、計算、結合、およびデータの主キーと外部キーの定義が含まれます。 たとえば、データベースにない総収益の％が必要な場合、変換に％式を適用し、データをロードします。 同様に、ユーザーの姓と名が異なる列にある場合、データをロードする前に連結操作を適用できます。 一部のデータは変換を必要としません。このようなデータは、*直接移動*または*パススルーデータ*と呼ばれます。
データ変換には、データの修正とデータのクレンジング、不正なデータの削除、不完全なデータ形成、データエラーの修正も含まれます。 また、DWシステムにロードする前に、データの整合性と互換性のないデータをフォーマットします。
DWシステムへのデータのロード
分析レポートと情報のためにデータをDWシステムにロードする必要があります。 ターゲットシステムは、単純な区切りのあるフラットファイルまたはデータウェアハウスにすることができます。
ETLツール機能
典型的なETLツールベースのデータウェアハウスは、ステージング領域、データ統合、およびアクセスレイヤーを使用してその機能を実行します。 通常は3層のアーキテクチャです。
- ステージング層-ステージング層またはステージングデータベースは、異なるソースデータシステムから抽出されたデータを格納するために使用されます。
- データ統合層-統合層は、ステージング層からデータを変換し、データをデータベースに移動します。データベースでは、データは、*ディメンション*と呼ばれる階層グループ、および*ファクト*および*集計ファクト*に配置されます。 DWシステムでのファクトテーブルとディメンションテーブルの組み合わせは、*スキーマ*と呼ばれます。
- アクセス層-アクセス層は、分析レポートおよび情報用のデータを取得するためにエンドユーザーによって使用されます。
次の図は、3つのレイヤーがどのように相互作用するかを示しています。
ETLテスト-タスク
ETLテストは、データが運用データウェアハウスシステムに移動される前に行われます。 また、「テーブルバランシング」または「生産調整」とも呼ばれます。 データベースのテストとは、その範囲とこれを完了するために実行する手順の点で異なります。
ETLテストの主な目的は、分析レポート用にデータを処理する前に発生するデータの欠陥と一般的なエラーを特定して軽減することです。
ETLテスト-実行するタスク
ETLテストに関連する一般的なタスクのリストを次に示します-
- レポートに使用されるデータを理解する
- データモデルを確認する
- ソースからターゲットへのマッピング
- ソースデータのデータチェック
- パッケージとスキーマの検証
- ターゲットシステムでのデータ検証
- データ変換の計算と集計ルールの検証
- ソースシステムとターゲットシステム間のサンプルデータの比較
- ターゲットシステムでのデータの整合性と品質のチェック
- データのパフォーマンステスト
ETLとデータベースのテスト
ETLテストとデータベーステストの両方にデータ検証が含まれますが、それらは同じではありません。 ETLテストは通常、データウェアハウスシステムのデータに対して実行されますが、データベーステストは一般に、異なるアプリケーションからトランザクションデータベースにデータが送られるトランザクションシステムで実行されます。
ここでは、ETLテストとデータベーステストの主な違いを強調しました。
ETLテスト
ETLテストには、次の操作が含まれます-
- ソースシステムからターゲットシステムへのデータ移動の検証。
- ソースシステムとターゲットシステムのデータ数の検証。
- データの抽出、要件および期待どおりの変換の検証。
- 変換中にテーブルの関係（結合とキー）が保持されるかどうかを確認します。
一般的なETLテストツールには、 QuerySurge、Informatica などが含まれます。
データベースのテスト
データベースのテストでは、データの正確性、データの正確性、有効な値に重点が置かれます。 次の操作が含まれます-
- 主キーと外部キーが維持されているかどうかを確認します。
- テーブルの列に有効なデータ値があるかどうかを確認します。 列のデータの正確性を検証します。 例*-月数の列に12を超える値を設定しないでください。
- 列の欠落データを検証します。 実際に有効な値を持つ必要があるヌル列があるかどうかを確認してください。
一般的なデータベーステストツールには、 Selenium、QTP などが含まれます。
次の表は、データベースおよびETLテストの主要な機能とその比較を示しています-
| Function | Database Testing | ETL Testing |
|---|---|---|
| Primary Goal | Data validation and Integration | Data Extraction, Transform and Loading for BI Reporting |
| Applicable System | Transactional system where business flow occurs | System containing historical data and not in business flow environment |
| Common tools | QTP, Selenium, etc. | QuerySurge, Informatica, etc. |
| Business Need | It is used to integrate data from multiple applications, Severe impact. | It is used for Analytical Reporting, information and forecasting. |
| Modeling | ER method | Multidimensional |
| Database Type | It is normally used in OLTP systems | It is applied to OLAP systems |
| Data Type | Normalized data with more joins | De-normalized data with less joins, more indexes, and aggregations. |
ETLテスト–カテゴリー
ETLテストの分類は、テストとレポートの目的に基づいて行われます。 テストのカテゴリは組織の標準によって異なり、クライアントの要件にも依存します。 一般的に、ETLテストは次の点に基づいて分類されます-
- ソースからターゲットへのカウントテスト-ソースシステムとターゲットシステムのレコードカウントの一致を伴います。
- ソースからターゲットへのデータテスト-ソースシステムとターゲットシステム間のデータ検証が含まれます。 また、ターゲットシステムでのデータ統合としきい値チェック、重複データチェックも含まれます。
- データマッピングまたは変換テスト-ソースシステムとターゲットシステムのオブジェクトのマッピングを確認します。 また、ターゲットシステムのデータの機能を確認することも含まれます。
- エンドユーザーテスト-レポートのデータが期待どおりかどうかを検証するために、エンドユーザー向けのレポートを生成します。 レポートの偏差を見つけ、レポート検証のためにターゲットシステムのデータをクロスチェックします。
- 再テスト-ターゲットシステムのデータのバグと欠陥を修正し、データ検証のためにレポートを再度実行します。
- システム統合テスト-すべての個々のシステムをテストし、後で結果を組み合わせて偏差があるかどうかを調べます。 これを実行するために使用できるアプローチには、トップダウン、ボトムアップ、ハイブリッドの3つがあります。
データウェアハウスシステムの構造に基づいて、ETLテスト（使用されているツールに関係なく）は、次のカテゴリに分類することができます-
新しいDWシステムテスト
このタイプのテストでは、新しいDWシステムが構築および検証されます。 データ入力は顧客/エンドユーザーから取得され、異なるデータソースからも取得され、新しいデータウェアハウスが作成されます。 その後、ETLツールを使用して、新しいシステムでデータが検証されます。
移行テスト
移行テストでは、既存のデータウェアハウスとETLがありますが、効率を改善するために新しいETLツールを探しています。 新しいETLツールを使用して、既存のシステムからデータを移行します。
変更テスト
変更テストでは、新しいデータが異なるデータソースから既存のシステムに追加されます。 顧客はETLの既存のルールを変更することも、新しいルールを追加することもできます。
レポートテスト
レポートのテストには、データ検証用のレポートの作成が含まれます。 レポートは、DWシステムの最終出力です。 レポートは、レイアウト、レポート内のデータ、および計算値に基づいてテストされます。
ETLテスト–課題
ETLテストは、データベーステストやその他の従来のテストとは異なります。 ETLテストの実行中に、さまざまなタイプの課題に直面する必要がある場合があります。 ここでは、いくつかの一般的な課題をリストしました-
- ETLプロセス中のデータ損失。
- データが正しくない、不完全である、または重複している。
- DWシステムには履歴データが含まれているため、ターゲットシステムでETLテストを実行するにはデータ量が大きすぎて非常に複雑です。
- ETLテスターには通常、ETLツールでジョブスケジュールを表示するためのアクセス権が提供されません。 レポートやレポート内のデータの最終的なレイアウトを見るために、BIレポートツールにアクセスすることはほとんどありません。
- データ量が多すぎて複雑であるため、テストケースを生成および構築するのは困難です。
- ETLテスターは通常、エンドユーザーレポートの要件と情報のビジネスフローを把握していません。
- ETLテストには、ターゲットシステムでのデータ検証のためのさまざまな複雑なSQLの概念が含まれます。
- テスターにソースからターゲットへのマッピング情報が提供されない場合があります。
- 不安定なテスト環境は、プロセスの開発とテストを遅らせます。
ETL –テスターの役割
ETLテスターは、データソースの検証、データの抽出、変換ロジックの適用、およびターゲットテーブルへのデータのロードを主に担当します。
ETLテスターの主な責任は以下のとおりです。
ソースシステムのテーブルを確認する
次の操作が含まれます-
- カウントチェック
- レコードをソースデータと調整する
- データ型チェック
- スパムデータが読み込まれないようにする
- 重複データを削除する
- すべてのキーが配置されていることを確認します
変換ロジックを適用
変換ロジックは、データをロードする前に適用されます。 次の操作が含まれます-
- データのしきい値の検証チェック。たとえば、年齢の値は100以下である必要があります。
- 変換ロジックの適用前後のレコードカウントチェック。
- ステージング領域から中間テーブルへのデータフロー検証。
- 代理キーチェック。
データの読み込み
データはステージング領域からターゲットシステムにロードされます。 次の操作が含まれます-
- 中間テーブルからターゲットシステムへのレコード数チェック。
- キーフィールドデータが欠落していないか、ヌルではないことを確認します。
- 集計値と計算されたメジャーがファクトテーブルに読み込まれているかどうかを確認します。
- ターゲットテーブルに基づいてモデリングビューを確認します。
- CDCが増分ロードテーブルに適用されているかどうかを確認します。
- ディメンションテーブルのデータチェックと履歴テーブルのチェック。
- ロードされたファクトとディメンションテーブルに基づいて、予想される結果に従ってBIレポートを確認します。
ETLツールのテスト
ETLテスターは、ツールとテストケースもテストする必要があります。 次の操作が含まれます-
- ETLツールとその機能をテストする
- ETL Data Warehouseシステムをテストする
- テスト計画とテストケースを作成、設計、および実行します。
- フラットファイルデータ転送をテストします。
ETLテスト–テクニック
テストプロセスを開始する前に、正しいETLテスト手法を定義することが重要です。 すべての利害関係者の承認を得て、ETLテストを実行するための正しい手法が選択されていることを確認する必要があります。 この手法はテストチームによく知られている必要があり、テストプロセスに関係する手順を知っている必要があります。
使用できるテスト手法にはさまざまな種類があります。 この章では、テスト手法について簡単に説明します。
生産検証試験
分析レポートと分析を実行するには、プロダクションのデータが正しい必要があります。 このテストは、実稼働システムに移動されたデータに対して実行されます。 実稼働システムでのデータ検証と、ソースデータとの比較が含まれます。
ソースからターゲットへのカウントテスト
このタイプのテストは、テスターがテスト操作を実行する時間が少ないときに行われます。 これには、ソースシステムとターゲットシステムのデータ数の確認が含まれます。 ターゲットシステムのデータの値を確認する必要はありません。 また、データのマッピング後にデータが昇順または降順であるかどうかは関係しません。
ソースからターゲットへのデータテスト
このタイプのテストでは、テスターはソースからターゲットシステムへのデータ値を検証します。 変換後、ソースシステムのデータ値とターゲットシステムの対応する値をチェックします。 このタイプのテストは時間がかかり、通常は金融プロジェクトや銀行プロジェクトで実行されます。
データ統合/しきい値検証テスト
このタイプのテストでは、テスターがデータの範囲を検証します。 ターゲットシステム内のすべてのしきい値は、予想される結果に従っている場合にチェックされます。 また、変換およびロード後に複数のソースシステムからターゲットシステムにデータを統合することも含まれます。
例-年齢属性には100を超える値を指定しないでください。 日付列DD/MM/YYでは、月フィールドの値が12を超えてはなりません。
アプリケーション移行テスト
通常、アプリケーション移行テストは、古いアプリケーションから新しいアプリケーションシステムに移行するときに自動的に実行されます。 このテストは多くの時間を節約します。 古いアプリケーションから抽出されたデータが、新しいアプリケーションシステムのデータと同じかどうかをチェックします。
データチェックと制約テスト
これには、データ型チェック、データ長チェック、インデックスチェックなどのさまざまなチェックの実行が含まれます。 ここで、テストエンジニアは次のシナリオを実行します-主キー、外部キー、NOT NULL、NULL、およびUNIQUE。
重複データチェックテスト
このテストには、ターゲットシステムの重複データのチェックが含まれます。 対象システムに大量のデータがある場合、分析レポートに誤ったデータをもたらす可能性のある本番システムに重複データがある可能性があります。
重複する値は、次のようなSQLステートメントで確認できます-
Select Cust_Id, Cust_NAME, Quantity, COUNT (*)
FROM Customer
GROUP BY Cust_Id, Cust_NAME, Quantity HAVING COUNT (*) >1;次の理由により、ターゲットシステムに重複したデータが表示されます-
- 主キーが定義されていない場合、値が重複する可能性があります。
- マッピングまたは環境の問題が原因です。
- ソースからターゲットシステムにデータを転送する際の手動エラー。
データ変換テスト
単一のSQLステートメントを実行しても、データ変換テストは実行されません。 時間がかかり、各行に対して複数のSQLクエリを実行して、変換ルールを検証する必要があります。 テスターは、各行に対してSQLクエリを実行し、出力をターゲットデータと比較する必要があります。
データ品質テスト
データ品質テストには、数値チェック、日付チェック、ヌルチェック、精度チェックなどが含まれます。 テスターは Syntax Test を実行して、無効な文字、大文字と小文字の順序の誤りなどを報告します データがデータモデルに従っているかどうかを確認する*参照テスト*。
増分テスト
増分テストを実行して、InsertおよびUpdateステートメントが期待どおりに実行されるかどうかを確認します。 このテストは、古いデータと新しいデータを使用して段階的に実行されます。
回帰試験
テスターが新しいエラーを見つけるのに役立つ新しい機能を追加するためにデータ変換および集約ルールに変更を加えるとき、それは回帰テストと呼ばれます。 回帰テストで発生するデータのバグは、回帰と呼ばれます。
再テスト
コードを修正した後にテストを実行することは、再テストと呼ばれます。
システム統合テスト
システム統合テストでは、システムのコンポーネントを個別にテストし、後でモジュールを統合します。 システム統合を行うには、トップダウン、ボトムアップ、ハイブリッドの3つの方法があります。
ナビゲーションテスト
ナビゲーションテストは、システムのフロントエンドのテストとしても知られています。 これには、フロントエンドレポートのすべての側面をチェックすることによるエンドユーザーの視点テストが含まれます。さまざまなフィールド、計算、集計などのデータが含まれます。
ETLテスト–プロセス
ETLテストは、ETLライフサイクルに含まれるすべてのステップをカバーします。 要約レポートが生成されるまで、ビジネス要件を理解することから始めます。
ETLテストライフサイクルでの一般的な手順は以下のとおりです-
- ビジネス要件を理解する。
- ビジネス要件の検証。
- テスト推定は、テストケースを実行して概要レポートを完了するための推定時間を提供するために使用されます。
- テスト計画には、ビジネス要件ごとの入力に基づいてテスト手法を見つけることが含まれます。
- テストシナリオとテストケースの作成。
- テストケースの準備と承認が完了したら、次のステップは実行前チェックを実行することです。
- すべてのテストケースを実行します。
- 最後のステップは、完全な要約レポートを生成し、閉鎖プロセスを提出することです。
ETLテスト-シナリオ
ETLテストシナリオは、ETLテストプロセスを検証するために使用されます。 次の表は、ETLテスターで使用される最も一般的なシナリオとテストケースの一部を説明しています。
| Test Scenarios | Test-Cases |
|---|---|
| Structure Validation |
It involves validating the source and the target table structure as per the mapping document. データ型は、ソースシステムとターゲットシステムで検証する必要があります。 ソースシステムとターゲットシステムのデータ型の長さは同じでなければなりません。 データフィールドタイプとその形式は、ソースシステムとターゲットシステムで同じである必要があります。 ターゲットシステムの列名の検証。 |
| Validating Mapping document | It involves validating the mapping document to ensure all the information has been provided. The mapping document should have change log, maintain data types, length, transformation rules, etc. |
| Validate Constraints | It involves validating the constraints and ensuring that they are applied on the expected tables. |
| Data Consistency check |
It involves checking the misuse of integrity constraints like Foreign Key. 属性の定義はセマンティックレイヤーで同じままですが、属性の長さとデータ型はテーブルによって異なる場合があります。 |
| Data Completeness Validation |
It involves checking if all the data is loaded to the target system from the source system. ソースシステムとターゲットシステムのレコード数をカウントします。 境界値分析。 主キーの一意の値を検証します。 |
| Data Correctness Validation |
It involves validating the values of data in the target system. スペルミスまたは不正確なデータがテーブルにあります。 インポート時に整合性制約を無効にすると、Null、Not Uniqueデータが保存されます。 |
| Data Transform validation |
It involves creating a spreadsheet of scenarios for input values and expected results and then validating with end-users. シナリオを作成して、データ内の親子関係を検証します。 データプロファイリングを使用して、各フィールドの値の範囲を比較します。 ウェアハウス内のデータ型がデータモデルに記載されているものと同じかどうかの検証。 |
| Data Quality Validation |
It involves performing number check, date check, precision check, data check, Null check, etc. 例-日付形式はすべての値で同じである必要があります。 |
| Null Validation | It involves checking the Null values where Not Null is mentioned for that field. |
| Duplicate Validation |
It involves validating duplicate values in the target system when data is coming from multiple columns from the source system. ビジネス要件に従って値が重複している場合は、主キーとその他の列を検証します。 |
| Date Validation check |
Validating date field for various actions performed in ETL process. 日付検証を実行する一般的なテストケース-
|
| Full Data Validation Minus Query |
It involves validating full data set in the source and the target tables by using minus query.
|
| Other Test Scenarios |
Other Test scenarios can be to verify that the extraction process did not extract duplicate data from the source system. テストチームは、ソースシステムから重複データが抽出されていないことを検証するために実行されるSQLステートメントのリストを保持します。 |
| Data Cleaning | Unwanted data should be removed before loading the data to the staging area. |
ETLテスト-パフォーマンス
ETLパフォーマンスチューニングは、ETLシステムが複数のユーザーとトランザクションの予想される負荷を処理できるかどうかを確認するために使用されます。 通常、パフォーマンスチューニングには、ETLシステムでのサーバー側のワークロードが含まれます。 マルチユーザー環境でサーバーの応答をテストし、ボトルネックを見つけるために使用されます。 これらは、ソースおよびターゲットシステム、システムのマッピング、セッション管理プロパティなどの構成などにあります。
ETLテストのパフォーマンスチューニングを実行する方法
ETLテストのパフォーマンスチューニングを実行するには、以下の手順に従ってください-
- *ステップ1 *-本番環境で変換されている負荷を見つけます。
- *ステップ2 *-同じ負荷の新しいデータを作成するか、実稼働データからローカルパフォーマンスサーバーに移動します。
- *ステップ3 *-必要な負荷を生成するまでETLを無効にします。
- *ステップ4 *-データベースのテーブルから必要なデータのカウントを取得します。
- *ステップ5 *-ETLの最後の実行を書き留め、ETLを有効にします。これにより、作成された負荷全体を変換するのに十分なストレスが得られます。 それを実行します
- *ステップ6 *-ETLが実行を完了した後、作成されたデータのカウントを取得します。
主要業績評価指標
- 負荷の変換にかかった合計時間を調べます。
- パフォーマンス時間が改善したか、低下したかを調べます。
- 予想される負荷全体が抽出および転送されたことを確認します。
ETLテスト-スケーラビリティ
ETLテストの目標は、信頼できるデータを達成することです。 データの信頼性は、テストサイクルをより効果的にすることで達成できます。
包括的なテスト戦略は、効果的なテストサイクルの設定です。 テスト戦略は、データが移動するたびにETLプロセスの各段階のテスト計画をカバーし、各利害関係者（ビジネスアナリスト、インフラストラクチャチーム、QAチーム、DBA、開発者、ビジネスユーザーなど）の責任を述べる必要があります。
すべての側面からテストの準備を確実にするために、テスト戦略が重点を置くべき重要な領域は次のとおりです-
- テストの範囲-使用するテスト手法とタイプを説明します。
- テスト環境をセットアップします。
- データの可用性をテストする-すべての/重要なビジネス要件をカバーするデータのような本番環境を持つことをお勧めします。
- データ品質とパフォーマンスの受け入れ基準。
ETLテスト-データ精度
ETLテストでは、期待どおりにデータがターゲットシステムに正確にロードされるかどうかを確認するために、データの精度が使用されます。 データの正確性を実行するための重要な手順は次のとおりです-
値の比較
値の比較では、ソースシステムとターゲットシステムのデータを、最小限の変換または変換なしで比較します。 Informaticaのソース修飾子変換など、さまざまなETLテストツールを使用して実行できます。
一部の式変換は、データ精度テストでも実行できます。 さまざまな集合演算子をSQLステートメントで使用して、ソースシステムとターゲットシステムのデータの正確性を確認できます。 一般的な演算子は、マイナス演算子と交差演算子です。 これらの演算子の結果は、ターゲットシステムとソースシステムの値の偏差と見なすことができます。
重要なデータ列を確認する
重要なデータ列は、ソースシステムとターゲットシステムの異なる値を比較することで確認できます。 重要なデータ列を確認するために使用できるサンプルクエリを次に示します-
SELECT cust_name, Order_Id, city, count(*) FROM customer
GROUP BY cust_name, Order_Id, city;ETLテスト-メタデータ
メタデータの確認には、ソースとターゲットのテーブル構造w.r.tの検証が含まれます。 マッピング文書。 マッピング文書には、ソースおよびターゲット列、データ変換ルール、データ型の詳細、ソースおよびターゲットシステムのテーブルの構造を定義するすべてのフィールドが含まれます。
データ長チェック
ターゲット列のデータ型の長さは、ソース列のデータ型以上でなければなりません。 例を挙げましょう。 ソーステーブルに名と姓があり、それぞれのデータ長が50文字として定義されているとします。 次に、ターゲットシステムのフルネーム列のターゲットデータ長は、100以上である必要があります。
データ型チェック
データ型チェックでは、ソースとターゲットのデータ型を検証し、それらが同じであることを確認します。 変換後のターゲットデータタイプがソースデータと異なる可能性があります。 したがって、変換ルールも確認する必要があります。
制約/インデックスチェック
制約チェックでは、設計仕様書に従ってインデックス値と制約を検証します。 Null値を持つことができないすべての列には、Not Null制約が必要です。 主キー列には、設計ドキュメントに従ってインデックスが作成されます。
ETLテスト-データ変換
データ変換の実行は少し複雑です。単一のSQLクエリを記述し、出力をターゲットと比較することでは達成できないためです。 ETLテストデータトランスフォーメーションの場合、トランスフォーメーションルールを検証するために、各行に複数のSQLクエリを記述する必要があります。
まず、ソースデータがすべての変換ルールをテストするのに十分であることを確認します。 データ変換のETLテストを成功させるための鍵は、ソースシステムから適切で十分なサンプルデータを選択して、変換ルールを適用することです。
ETLテストデータ変換の主要な手順を以下に示します-
- 最初のステップは、入力データのシナリオと期待される結果のリストを作成し、これらをビジネス顧客と検証することです。 これは、設計中に要件を収集するための優れたアプローチであり、テストの一部としても使用できます。
- 次のステップでは、すべてのシナリオを含むテストデータを作成します。 ETL開発者を利用して、データセットにシナリオスプレッドシートを追加するプロセス全体を自動化し、シナリオが変更される可能性があるため、汎用性とモビリティを実現します。
- 次に、データプロファイリングの結果を利用して、ターゲットデータとソースデータの各フィールドの値の範囲と送信を比較します。
- ETLで生成されたフィールド（代理キーなど）の正確な処理を検証します。
- ウェアハウス内のデータ型の検証は、データモデルまたは設計で指定されたものと同じです。
- 参照整合性をテストするテーブル間にデータシナリオを作成します。
- データ内の親子関係を検証します。
- 最後のステップは、*ルックアップ変換*を実行することです。 ルックアップクエリは集計なしでまっすぐで、ソーステーブルごとに1つの値のみを返すことが期待されます。 前のテストのように、ソース修飾子でルックアップテーブルを直接結合できます。 そうでない場合は、ルックアップテーブルをソースのメインテーブルと結合するクエリを記述し、ターゲットの対応する列のデータを比較します。
ETLテスト–データ品質
ETLテスト中のデータ品質のチェックには、ターゲットシステムにロードされたデータの品質チェックの実行が含まれます。 次のテストが含まれています-
番号チェック
数値形式は、ターゲットシステム全体で同じである必要があります。 たとえば、ソースシステムでは、列の番号付けの形式は x.30 ですが、ターゲットが 30 のみの場合は、ターゲット列番号に* x。*を付けずにロードする必要があります。
日付チェック
日付形式は、ソースシステムとターゲットシステムの両方で一貫している必要があります。 たとえば、すべてのレコードで同じである必要があります。 標準形式はyyyy-mm-ddです。
精度チェック
精度値は、ターゲットテーブルに期待どおりに表示されます。 たとえば、ソーステーブルでは値は15.2323422ですが、ターゲットテーブルでは15.23または15のラウンドとして表示されます。
データチェック
ビジネス要件に従ってデータをチェックする必要があります。 特定の基準を満たさないレコードは除外する必要があります。
例-date_id> = 2015およびAccount_Id！= ‘001’のレコードのみがターゲットテーブルにロードされます。
ヌルチェック
一部の列には、そのフィールドの要件と可能な値に従ってNullが必要です。
例-アクティブステータス列が「T」または「死亡」でない限り、終了日列はヌルを表示する必要があります。
その他のチェック
From_Dateのような一般的なチェックは、To_Dateより大きくすることはできません。
ETLテスト-データの完全性
データの完全性のチェックは、ターゲットシステムのデータがロード後の予想どおりであることを確認するために行われます。
このために実行できる一般的なテストは次のとおりです-
- 集計関数（合計、最大、最小、カウント）の確認、
- 変換なしまたは単純な変換を使用した列のソースとターゲット間のカウントと実際のデータの確認と検証。
カウント検証
ソーステーブルとターゲットテーブルのレコード数のカウントを比較します。 それは次のクエリを書くことで行うことができます-
SELECT count (1) FROM employee;
SELECT count (1) FROM emp_dim;データプロファイルの検証
ソーステーブルとターゲットテーブル（ファクトまたはディメンション）のカウント、合計、最大値などの集計関数をチェックする必要があります。
列データプロファイルの検証
これには、個別の値と、個別の値ごとの行数の比較が含まれます。
SELECT city, count(*) FROM employee GROUP BY city;
SELECT city_id, count(*) FROM emp_dim GROUP BY city_id;重複データ検証
これには、ビジネス要件に従って一意である必要がある列または列の組み合わせで、主キーと一意キーを検証することが含まれます。 次のクエリを使用して、重複データの検証を実行できます-
SELECT first_name, last_name, date_of_joining, count (1) FROM employee
GROUP BY first_name, last_name HAVING count(1)>1;ETLテスト-バックアップリカバリ
システムのバックアップリカバリは、重要なデータを失うことなく、システムを障害からできるだけ早く復元し、操作をできるだけ早く再開するように計画されています。
ETLバックアップリカバリテストは、データウェアハウスシステムがハードウェア、ソフトウェア、またはデータを失ったネットワーク障害から正常にリカバリすることを確認するために使用されます。
システムの可用性を最大にするには、適切なバックアップ計画を準備する必要があります。 バックアップシステムは、簡単に復元でき、データを失うことなく、障害が発生したシステムを引き継ぐ必要があります。
ETLテストバックアップリカバリには、アプリケーションまたはDWシステムをハードウェアコンポーネント、ソフトウェアクラッシュなどの極端な条件にさらすことが含まれます。 次のステップは、復旧プロセスが開始され、システム検証が行われ、データ復旧が達成されることを確認することです。
ETLテスト–自動化
ETLテストは、主にSQLスクリプトを使用して行われ、スプレッドシートでデータを収集します。 ETLテストを実行するこのアプローチは非常に遅く、時間がかかり、エラーが発生しやすく、サンプルデータに対して実行されます。
手動ETLテストの技術的課題
ETLテストチームは、ウェアハウスシステムのテストデータにSQLクエリを記述します。SQLエディターを使用して手動で実行し、データをExcelスプレッドシートに入力して、手動で比較する必要があります。 このプロセスは時間がかかり、リソースを消費し、非効率的です。
このプロセスを自動化するためのさまざまなツールが市場で入手できます。 最も一般的なETLテストツールは、QuerySurgeとInformatica Data Validationです。
QuerySurge
QuerySurgeは、ビッグデータ、データウェアハウス、およびETLプロセスをテストするために設計されたデータテストソリューションです。 プロセス全体を自動化して、DevOps戦略にうまく適合させることができます。
QuerySurgeの主な機能は次のとおりです-
- ユーザーがSQLを作成しなくても、テストクエリペアをすばやく簡単に作成できるクエリウィザードがあります。
- 再利用可能なクエリスニペットを含むデザインライブラリがあります。 カスタムQueryPairsも作成できます。
- ソースファイルとデータストアのデータをターゲットのデータウェアハウスまたはビッグデータストアと比較できます。
- 数百万の行と列のデータを数分で比較できます。
- ユーザーは、（1）即時、（2）任意の日付/時刻、または（3）イベントの終了後に自動的に実行するテストをスケジュールできます。
- 有益なレポートを作成し、更新を表示し、結果をチームに自動メールで送信できます。
プロセス全体を自動化するには、ETLソフトウェアがロードプロセスを完了した後、コマンドラインAPIを使用してETLツールでQuerySurgeを開始する必要があります。
QuerySurgeは自動的に無人で実行され、すべてのテストを実行してからチームの全員に結果をメールで送信します。
QuerySurgeと同様に、Informatica Data ValidationはETLテストツールを提供し、開発および実稼働環境でETLテストプロセスを加速および自動化するのに役立ちます。 これにより、より短時間で完全で再現性のある監査可能なテストカバレッジを提供できます。 プログラミングスキルは必要ありません！
ETLテスト-ベストプラクティス
データウェアハウスシステムまたはBIアプリケーションをテストするには、データ中心のアプローチが必要です。 ETLテストのベストプラクティスは、テストを実行するためのコストと時間を最小限に抑えるのに役立ちます。 エンドユーザー向けの高品質のダッシュボードとレポートを生成するターゲットシステムにロードされるデータの品質を向上させます。
ETLテストで従うことができるいくつかのベストプラクティスをここにリストしました-
データを分析する
正しいデータモデルを設定するには、データを分析して要件を理解することが非常に重要です。 要件を理解するために時間を費やし、ターゲットシステムの正しいデータモデルを用意することで、ETLの課題を軽減できます。 また、ソースシステム、データ品質を調査し、ETLモジュールの正しいデータ検証ルールを構築することも重要です。 ETL戦略は、ソースシステムとターゲットシステムのデータ構造に基づいて策定する必要があります。
ソースシステムの不良データを修正
エンドユーザーは通常、データの問題を認識していますが、それらを修正する方法はわかりません。 ETLシステムに到達する前に、これらのエラーを見つけて修正することが重要です。 これを解決する一般的な方法はETLの実行時ですが、ベストプラクティスはソースシステムでエラーを見つけ、ソースシステムレベルでエラーを修正する手順を実行することです。
互換性のあるETLツールを見つける
一般的なETLベストプラクティスの1つは、ソースシステムとターゲットシステムとの互換性が最も高いツールを選択することです。 ソースシステムとターゲットシステムのSQLスクリプトを生成するETLツールの機能により、処理時間とリソースを削減できます。 これにより、最も適切な環境内の任意の場所で変換を処理できます。
ETLジョブの監視
ETL実装時のもう1つのベストプラクティスは、ETLジョブのスケジューリング、監査、および監視であり、期待どおりにロードが実行されるようにします。
増分データを統合する
場合によっては、データウェアハウステーブルのサイズが大きくなり、ETLサイクルごとにテーブルを更新できない場合があります。 増分ロードにより、最後の更新以降に変更されたレコードのみがETLプロセスに取り込まれ、スケーラビリティとシステムの更新にかかる時間に大きな影響を与えます。
通常、ソースシステムには、変更を簡単に識別するためのタイムスタンプまたはプライマリキーがありません。 このような問題は、プロジェクトの後の段階で特定された場合、非常に費用がかかる可能性があります。 ETLのベストプラクティスの1つは、最初のソースシステムの調査でそのような側面をカバーすることです。 この知識は、ETLチームが変更されたデータキャプチャの問題を特定し、最も適切な戦略を決定するのに役立ちます。
スケーラビリティ
提供されるETLソリューションがスケーラブルであることを確認するのがベストプラクティスです。 実装時には、ETLソリューションがビジネス要件と将来の潜在的な成長に合わせてスケーラブルであることを確認する必要があります。 Etl-testing-interview-questions
