data validation tests
このチュートリアルでは、ETLとデータ移行プロジェクトについて説明し、データ品質を向上させるためのETL /データ移行プロジェクトのデータ検証チェックまたはテストについて説明します。
この記事は、ETLまたはデータ移行プロジェクトに取り組んでおり、データ品質の側面のみにテストを集中することに関心のあるソフトウェアテスターを対象としています。これらのタイプのプロジェクトには大量のデータがあり、それらはソースストレージに保存され、ソフトウェアに存在するロジックによって操作され、ターゲットストレージに移動されます。
データ検証テストは、最終的なターゲットシステムに存在するデータが、ビジネス要件に従って有効で正確であり、実際の本番システムでの使用に適していることを確認します。
テストできるデータ品質の側面の数は膨大であり、以下のリストはこのトピックの概要を示しています。
学習内容:
データ検証とは何ですか?
簡単に言うと、データ検証は、ETLまたはデータ移行ジョブの一部として移動されるデータが、ビジネス要件を満たすためにターゲットの本番稼働システムで一貫性があり、正確で、完全であるという事実を検証する行為です。
例: Studentテーブルの学生の住所は、ソースシステムでは2000文字でした。データ検証では、まったく同じ値がターゲットシステムに存在するかどうかを検証します。データが切り捨てられたかどうか、または特定の特殊文字が削除されたかどうかを確認します。
この記事では、これらのデータ検証チェックの多くについて説明します。 ETLまたはデータ移行プロジェクトのテスターとして、ターゲットシステムに伝播し、ビジネスプロセス全体を混乱させる可能性のあるデータ品質の問題を発見した場合、非常に大きな価値があります。
ETLプロジェクトのデータを検証する理由
ETLプロジェクトでは、データはソースから抽出され、ソフトウェアにロジックを適用して処理され、変換されてから、ターゲットストレージに読み込まれます。多くの場合、変換は、ソースデータをビジネス要件に適した形式に変更するために行われます。
ここでは、ターゲットシステムにロードされるデータが完全で正確であり、データの損失や不一致がないことを確認するために、データの検証が必要です。
例: eコマースアプリケーションには、顧客によるTotalDollarsSpendを合計するOrdersテーブルから各CustomerIDに対してすべてのOrdersIdを選択するETLジョブがあり、それを新しいCustomerValueテーブルにロードして、各CustomerRatingを高/中/低値の顧客ベースとしてマークします。いくつかの複雑なアルゴリズムについて。
簡単なデータ検証テストは、CustomerRatingが正しく計算されていることを確認することです。
もう1つのテストは、TotalDollarSpendが正しく計算され、値の丸めや最大値のオーバーフローに欠陥がないことを確認することです。
データ移行プロジェクトのデータを検証する理由
データ移行プロジェクトでは、インフラストラクチャのアップグレード、廃止されたテクノロジー、最適化などの複数の理由により、ソースストレージに保存されている大量のデータが異なるターゲットストレージに移行されます。 例えば、 企業は、巨大なデータウェアハウスをレガシーシステムからAWSまたはAzure上のより新しくより堅牢なソリューションに移行する可能性があります。
このようなプロジェクトの主な動機は、データをソースシステムからターゲットシステムに移動して、ターゲット内のデータがビジネスの中断や悪影響なしに非常に使いやすくなるようにすることです。
ここでも、移動後にソースのデータがターゲットで同じであることを確認するために、データの検証が必要です。
例: eコマースアプリケーションの場合、2億行のOrdersテーブルがAzureのターゲットシステムに移行されたとします。簡単なデータ検証テストは、2億行すべてのデータがターゲットシステムで利用可能であることを確認することです。
別のテストは、日付形式がソースシステムとターゲットシステムの間で一致することを確認することです。
テスターが機能テスト、パフォーマンステスト、セキュリティテスト、インフラテスト、E2Eテスト、回帰テストなどのプロジェクトでテストできるさまざまな側面があります。
推奨読書=> データ移行テスト 、 ETLテストデータウェアハウステストチュートリアル
この記事では、ETLおよび移行プロジェクトのテストのデータの側面のみを見ていきます。
データマッピングシート
まず、データプロジェクトのデータマッピングシートを作成します。データマッピングは、ソーステーブルとターゲットテーブルの間でエンティティを照合するプロセスです。ソースシステム内のすべてのテーブルとそのエンティティをスプレッドシートに文書化することから始めます。次に、ターゲットテーブルで一致すると予想されるこれらの各行に対応する値を文書化します。変換ルールがある場合は、別の列に書き留めます。
データマッピングシートには、データアーキテクトが提供するデータモデルから選択した多くの情報が含まれています。最初に、テスターは簡略化されたバージョンを作成し、進行するにつれてさらに情報を追加できます。以下のデータマッピングシートの例を参照してください-
からテンプレートをダウンロード 簡略化されたデータマッピングシート
データ検証テスト
#1)データの均一性
データ均一性テストは、エンティティの実際の値がさまざまな場所で完全に一致していることを確認するために実行されます。 ここでは、2種類のテストが可能です。
(i)同じスキーマ内のチェック:
- データエンティティは、同じスキーマ(ソースシステムまたはターゲットシステム)内の2つのテーブルに存在する場合があります
- 例: 以下の画像でわかるように、ProductIDはOrderDetailsおよびProductsテーブルに存在します。 OrderDetails vsProductsテーブルにあるProductIdの完全一致検証を実行します。
(ii)スキーマ全体のチェック:
- データエンティティは、そのままターゲットスキーマに移行される可能性があります。つまり、ソースシステムとターゲットシステムに存在します。
- 例: 上の画像でわかるように、ProductIDは、ソースシステムのProductsテーブルとターゲットシステムのProductsテーブルに存在します。ソースシステムのProductsテーブルのProductIdと、ターゲットシステムのProductsテーブルのProductIdの完全一致検証を実行します。
注意: クイックリファレンスとして、データマッピングシートで一致するデータエンティティを強調表示(カラーコード)することをお勧めします。
#2)エンティティの存在
このタイプのテストでは、すべてのエンティティ(テーブルとフィールド)がソースとターゲットの間で一致していることを検証する必要があります。データモデルの設計に従って、エンティティが存在する場合と存在しない場合の2つの可能性があります。
(私) ソースとターゲットの両方に対応する存在を持つすべてのテーブル(および列)が一致することを検証します。すべてのテーブル(および列)のリストを取得し、テキスト比較を行います。この健全性テストは、同じエンティティ名が使用されている場合にのみ機能します。
異なるテーブル名が使用されることがあるため、直接比較が機能しない場合があります。この情報をデータマッピングシートにマッピングし、障害がないか検証する必要がある場合があります。
もう1つの可能性は、データがないことです。データモデルで、ソースシステム(または列)のテーブルがターゲットシステムに対応する存在を持たない(またはその逆)必要がある場合があります。これを検証するためのテストがあります。
- 例: 次の画像でわかるように、CustDemographic Tableは、ソースシステムではなく、ターゲットシステムに存在します。
- CustomersテーブルのCustomerTypeフィールドには、ソースシステムにのみデータがあり、ターゲットシステムにはありません。
#3)データの正確性
名前が示すように、データが論理的に正確であるかどうかを検証します。このタイプのテストには2つのカテゴリがあります。これにより、テスターはソースシステムでもデータ品質の問題を把握できます。
[画像 ソース ]
注意: ターゲットシステムでこのテストを実行し、ソースシステムで欠陥がないかバックチェックします。
(i)非数値型: この分類の下で、非数値コンテンツの正確性を検証します。 例 有効な形式の電子メール、PINコード、電話です。
(ii)ドメイン分析: このタイプのテストでは、データのドメインを選択し、エラーを検証します。 これには3つのグループがあります。
- 値に基づく: ここでは、フィールド(テーブルの列)に発生する可能性のある値のリストを作成します。次に、列の値がリストのサブセットであるかどうかを検証します。
- 例: 性別列にMまたはFが含まれているかどうかを確認します。
- 範囲に基づく: ここでは、論理的またはビジネス上の理由に基づいて、列の有効なデータ値の最小範囲と最大範囲を設定します。次に、列の値がこの範囲内にあるかどうかを検証します。
- 例: 年齢は0から120。
- 参照ファイル :ここでは、システムは外部有効性ファイルを使用します。
- 例: 国コードは有効ですか?参照ファイルから正しい値を選択しますか?国コードはQAと本番環境で同じですか?参照ファイルで国コードが更新されている場合、DBで正しく更新されていますか?
#4)メタデータの検証
メタデータの検証では、ターゲットのテーブルと列のデータ型の定義が正しく設計されていることを検証し、設計が完了すると、データモデルの設計仕様に従って実行されます。
ここには2つのグループがあります。
(i)メタデータの設計: 最初のチェックは、データモデルがターゲットテーブルのビジネス要件に従って正しく設計されていることを検証することです。データアーキテクトは、スキーマエンティティを移行したり、ターゲットシステムを設計するときに変更を加えたりすることができます。
次のチェックは、データモデルを使用して適切なスクリプトが作成されたことを検証することです。
以下の各カテゴリについて、最初にターゲットシステムに定義されたメタデータがビジネス要件を満たしているかどうかを確認し、次にテーブルとフィールド定義が正確に作成されているかどうかを確認します。
メタデータチェックのいくつかを以下に示します。
- データ型チェック: 例: Total Salesは、Decimal(8、16、または20バイト)またはDoubleタイプで正しく機能しますか?
- データ長チェック : 例: Addressフィールドのデータ長は500文字で十分ですか?新しい地域が会社に追加されるにつれて、データ移行が行われる場合があります。新しい地域の住所の形式が非常に長く、元の長さに固執すると、ユースケースでエラーが発生する可能性があります。
- インデックスチェック:例: ターゲットシステムのOrderId列に対してインデックスが作成されていますか?企業の合併が発生し、データ移行が必要になり、Ordersテーブルのサイズがターゲットシステムで100倍になった場合はどうなりますか?
- 環境全体のメタデータチェック: このチェックの下で、メタデータがQAテストと本番環境の間で一致することを確認します。テストはQA環境では合格する可能性がありますが、他の環境では失敗する可能性があります。
(ii)デルタの変更: これらのテストは、プロジェクトの進行中および途中でソースシステムのメタデータに変更があり、ターゲットシステムに実装されなかったときに発生する欠陥を明らかにします。
例: 新しいフィールドCSI(Customer Satisfaction Index)がソースのCustomerテーブルに追加されましたが、ターゲットシステムに対して作成できませんでした。
#5)データの整合性
ここでは、主に外部キー、主キー参照、一意、デフォルトなどの整合性制約を検証します。
[画像 ソース ]
Windows10でjarファイルを開く方法
外部キーの場合、使用されている外部キーが親テーブルに存在しない子テーブルに孤立したレコードがあるかどうかを確認する必要があります。
例: Customersテーブルには、主キーであるCustomerIDがあります。 Ordersテーブルには、外部キーとしてCustomerIDがあります。 Ordersテーブルには、CustomersテーブルにないCustomerIDが含まれている可能性があります。このような整合性制約違反を明らかにするためのテストが必要です。データマッピングテーブルは、どのテーブルにこれらの制約があるかを明確にします。
注意: ターゲットシステムでこのテストを実行し、欠陥がある場合はソースシステムでバックチェックします。
#6)データの完全性
これらは、ソーステーブルとターゲットテーブルの間で欠落しているレコードまたは行の数を明らかにする健全性テストであり、自動化されると頻繁に実行できます。
テストには2つのタイプがあります。
(i)レコード数: ここでは、ソースシステムとターゲットシステムの間で一致するテーブルのレコードの総数を比較します。これは、ETLまたは移行ジョブの実行後を確認するための簡単な健全性チェックです。カウントが一致しない場合、欠陥があります。
ジョブの実行中に拒否されたレコードが存在する場合があります。これらのいくつかは有効かもしれません。しかし、テスターとして、私たちはこれを主張します。
(ii)列データのプロファイリング: このタイプの健全性テストは、レコード数が膨大な場合に役立ちます。ここでは、レコード数を減らす論理データセットを作成してから、ソースとターゲットを比較します。
- 可能な場合は、列内のすべての一意の値をフィルタリングし、 例えば、 ProductIDは、OrderDetailsテーブルで複数回発生している可能性があります。ターゲットテーブルとソーステーブルの両方からProductIDの一意のリストを選択し、検証します。これにより、レコード数が大幅に削減され、健全性テストが高速化されます。
- 上記のテストと同様に、すべての主要な列を選択して、KPI(最小、最大、平均、最大、または最小の長さなど)がターゲットテーブルとソーステーブルの間で一致するかどうかを確認することもできます。 例: OrderDetailsのPrice列から平均値、最小値、および最大値を取得し、これらの値をターゲットテーブルとソーステーブルの間で比較して不一致がないかどうかを確認します。
- Null値に対して別のチェックを行うことができます。重要な列を選択し、列にNull値が含まれている行のリストを除外します。ターゲットシステムとソースシステムの間でこれらの行を比較して、不一致がないか確認します。
#7)データ変換
これらのテストは、プロジェクトのコアテストを形成します。要件ドキュメントを確認して、変換要件を理解してください。さまざまな変換シナリオを反映するように、ソースシステムでテストデータを準備します。これらには多数のテストがあり、ETLテストのトピックで詳細に説明する必要があります。
以下は、これでカバーされるテストの簡潔なリストです。
(i)変換:
- 例: ETLコードには、無効なデータを拒否するロジックが含まれている場合があります。要件に対してこれらを確認します。
- ETLコードには、代理キーなどの特定のキーを自動生成するロジックも含まれている場合があります。これらの正しさ(技術的および論理的)を検証するためのテストが必要です。
- ETLまたは移行ジョブが実行された後、フィールド値の結合または分割の正確さを検証します。
- 参照整合性チェックを検証するためのテストがあります。 例えば、 欠陥のタイプは、Ordersテーブルで使用されているProductIdである可能性があり、親テーブルProductsには存在しません。 ETLジョブ中に孤立したレコードがどのように動作するかを確認するためのテストを行います。
- 欠測データは、ETLコードを使用して挿入される場合があります。これらの正しさを確認してください。
- ETLまたは移行スクリプトには、データを修正するロジックがある場合があります。データ修正が機能することを確認します。
- 無効/拒否/エラーアウトされたデータがユーザーに報告されているかどうかを確認します。
- 入力データと期待される結果のシナリオのスプレッドシートを作成し、ビジネス顧客とこれらを検証します。
(ii)エッジケース: 変換ロジックが境界で適切に機能することを確認します。
- 例: 値が1兆のTotalSalesがETLジョブを実行するとどうなりますか?エンドツーエンドのケースは機能しますか?大きな値を持つ可能性のあるフィールドを特定し、これらの大きな値でテストを実行します。数値と非数値を含める必要があります。
- 予想される日付の全範囲を含む日付フィールドの場合–うるう年、2月の28/29日。他の月は30、31日。
#8)データの一意性または重複
このタイプのテストでは、データモデルに従って一意の値を持つ必要がある列を特定します。また、そのようなデータを取り除くためのビジネスロジックも考慮に入れてください。テストを実行して、それらがシステム内で一意であるかどうかを確認します。次に、テストを実行して実際の重複を特定します。
- 例: 重複データをフィルタリングし、それが本物かどうかを確認します。 例えば、 従業員に依存するレコードには、同じ兄弟データが2回含まれています。
- ユーザーの電話番号は、システム内で一意である必要があります(ビジネス要件)。
- ビジネス要件では、ProductNameは重複する可能性があるため、ProductsテーブルのProductIDとProductNameの組み合わせは一意である必要があります。
#9)必須
このタイプのテストでは、必須としてマークされたすべてのフィールドを識別し、必須フィールドに値があるかどうかを検証します。 DBのフィールドにデフォルト値が関連付けられている場合は、データがないときに正しく入力されているかどうかを確認してください。
- 例: BillDateが入力されていない場合、CurrentDateはBillDateです。
#10)適時性
合意されたタイムラインのデータを使用していることを確認するテストを常に文書化します。
- 例: ProductDiscountは15日前に更新され、ビジネスドメインの状態ではProductDiscountは7日ごとに変更されます。これは、テストが適切な割引値で行われていないことを意味します。
- 顧客満足度指数の予測分析レポートは、ウォルマートでの販売促進週である過去1週間のデータで機能するはずでした。ただし、ETLジョブは15日の頻度で実行されるように設計されています。これは、テスターが発見できる大きな欠陥です。
#11)ヌルデータ
このタイプのテストでは、nullデータの有効性と、重要な列をnullにできないことの検証に焦点を当てます。
- 例: すべてのnullデータを除外し、nullが許可されているかどうかを検証します。
- ビジネス上の意思決定に重要な列がある場合は、nullが存在しないことを確認してください。
#12)範囲チェック
範囲がビジネス上意味のあるデータエンティティをテストする必要があります。
- 例: 請求書あたりの注文数量は、ソフトウェアカテゴリで5Kを超えることはできません。
- 年齢は120歳を超えてはなりません。
#13)ビジネスルール
フィールドのビジネス要件を文書化し、同じテストを実行します。
- 例: 20歳未満のリソースは対象外です。このルールをデータに適用する場合は、データ検証チェックが必要です。
- 従業員のアクティブステータスがTrue /死亡の場合、終了日はnullである必要があります。
- FROMデータはTODateより小さくする必要があります。
- アイテムレベルの購入金額の合計を注文レベルの金額にする
#14)集計関数
集計関数は、データベースの機能に組み込まれています。ソースシステム内のすべての集計を文書化し、集計の使用量がターゲットシステムで同じ値を与えるかどうかを確認します[合計、最大、最小、カウント]。
多くの場合、ソースシステムのツールはターゲットシステムとは異なります。両方のツールが同じ方法で集計関数を実行するかどうかを確認します。
#15)データの切り捨てと丸め
これらのタイプのテストでは、ビジネスに関する切り捨ておよび丸めロジックを使用してフィールドを識別します。次に、製品の所有者との間で切り捨てと丸めのロジックを文書化して承認を得、製造担当者のデータを使用してテストします。
#16)エンコーディングテスト
ソースシステムにエンコードされた値があるかどうかを検証し、ETLまたはデータ移行ジョブの後にターゲットシステムにデータが正しく入力されているかどうかを確認します。
- 例: 中国語のFirstNameの2バイト文字は、エンコードされたソースシステムで受け入れられました。ターゲットシステムに移動したときのこのフィールドの動作を確認します。
- パスワードフィールドはエンコードされ、移行されました。移行後に正常に機能することを確認してください。
#17)回帰テスト
これは基本的なテストの概念であり、テスターは上記のチェックリストを使用して生成されたすべての重要なテストケーススイートを実行し、ソースシステムまたはターゲットシステムに変更を加えます。
結論
したがって、データ検証は、データ集約型プロジェクトを探索するための興味深い領域であり、最も重要なテストを形成することがわかりました。データマッピングシートは、これらのテストを成功させるためにテスターが維持しなければならない重要な成果物です。上記のテストの入力を形成するために、カラーハイライト付きの複数のバージョンを維持できます。
バージョン間でデルタの変更を維持するように注意する必要があります。
テスターコミュニティに利益をもたらすために、読者が作業中に遭遇したテストの他の領域を共有することをお勧めします。