ビジネスインテリジェンス（BI）のテストケースを用いたテスト
編集チーム
⚡ スマートサマリー
ビジネスインテリジェンス（BI）テストは、ステージングデータ、ETLプロセス、および意思決定の根拠となるBIレポートを検証します。データがソースからターゲットへ正しく転送され、レポートに表示されるすべての数値が信頼できることを確認します。
BI テストとは何ですか?
ビジネスインテリジェンス（BI） ビジネスインテリジェンス（BI）とは、ビジネスの成長を促進する実用的な洞察を得るために、データを収集、クレンジング、分析、統合、共有するプロセスです。BIテストは、ステージングデータ、ETLプロセス、BIレポートを検証し、実装が正しいことを確認します。BIテストは、データの信頼性とBIプロセスから得られる洞察の正確性を保証します。
ETL/ビジネス インテリジェンスについて詳しくは、こちらをご覧ください。 チュートリアル
BIテストプロセス
BIテストは、データパイプラインの構造そのものに沿って行われます。各ステージが合格しなければ、次のステージをテストする価値はありません。なぜなら、上流の欠陥が下流で誤った障害として再発する可能性があるからです。
- 要件分析: レポートが回答すべきビジネス上の疑問点と、データが格納されているソースシステムを明確にしてください。ここで曖昧さがあると、後々検証不可能なレポートになってしまいます。
- ソースデータの検証： ソースのプロファイリング（行数、データ型、NULL値の割合、重複データなど）を実施してください。測定していないソースに対して変換を検証することはできません。
- ステージング検証: 元tracフィルタールールを適用した後、照合カウントがソースと一致し、完全に着陸しました。
- ETLおよび変換テスト： すべての地図を確認するping また、派生列、集計、代理キー生成などのビジネスルールも含まれます。
- データウェアハウス そしてキューブテスト。 階層構造のあらゆるレベルで、ディメンションテーブルとファクトテーブルの整合性、緩やかに変化するディメンションの処理、および集計の精度を確認します。
- レポートとダッシュボードのテスト： レポートの数値をデータウェアハウスと比較し、次にソースと比較し、フィルター、ドリルダウン、およびセキュリティロールを確認します。
- パフォーマンスおよび回帰テスト： 負荷ウィンドウの継続時間を測定し、応答時間を報告した後、パイプラインの変更ごとにスイートを再実行します。
和解は、プロセス全体の根幹を成すものである。 あらゆる段階で、主要数値の数と合計は trac情報源まで遡って確認できる。正しく見えるが照合できない報告書は、テストされず、検査されるだけである。
BIテストの種類
このチュートリアルで取り上げるシナリオは、6つの既知のカテゴリに分類されます。これらのカテゴリに名前を付けることで、テスト計画がチェックしやすい部分だけでなく、全体を網羅できるようになります。
| タイプ | それが証明するもの | 典型的な手法 |
|---|---|---|
| データの完全性 | 予想されたすべての記録が | ソースとターゲット間の行数の照合 |
| データ変換 | ビジネスルールが正しく適用されている | 変換後の出力を手動で計算した期待値と比較する |
| データ品質 | 値は有効で、一意であり、範囲内です。 | ヌル値、重複、フォーマット、および参照整合性のチェック |
| メタデータテスト | データ型、長さ、制約は仕様に合致している。 | ソースとターゲット間のスキーマ比較 |
| レポートテスト | 図表、書式設定、ドリルダウン機能は正しいです。 | レポート出力を倉庫クエリと照合する |
| セキュリティテスト | ユーザーは、自分の役割で許可されているデータのみを閲覧できます。 | 異なるロールの認証情報で同一のレポートを実行する |
の選択 BIツール 各タイプの実行方法には影響しますが、必要なタイプには影響しません。セキュリティテストは最も頻繁に省略され、また最もコストがかかるテストです。なぜなら、行レベルのセキュリティ欠陥は、目に見えるエラーを発生させることなく、ビジネスユニット全体にデータを漏洩させてしまうからです。
BIテストのテストケースとシナリオ
以下のシナリオは、ほぼすべてのBIプロジェクトに当てはまります。検証対象となるパイプラインの段階ごとにグループ化し、その順序で実行してください。ステージング段階での不具合は、それ以降のすべての段階で障害を引き起こすためです。
ETL検証テストシナリオ
- データがソース システムからターゲット システムに正しくマッピングされていることを確認します
- すべてのテーブルとそのフィールドがソースからターゲットにコピーされていることを確認します。
- 自動生成されるように構成されたキーがターゲット システムで適切に作成されていることを確認します
- Null フィールドが入力されていないことを確認する
- データが文字化けしたり切り捨てられたりしていないことを確認する
- ターゲット システムのデータ型と形式が期待どおりであることを確認します
- ターゲット システムにデータの重複がないことを確認します。
- 変換が正しく適用されていることを確認する
- 数値フィールドのデータの精度が正確であることを確認する
- 例外処理が堅牢であることを確認する
ステージングデータテストシナリオ
- リコンシリエーション チェック - STG (ステージング) テーブルとターゲット テーブルの間のレコード数は、フィルター ルールの適用後に同じになります
- 指定されたキーの組み合わせでターゲットテーブルにロードされていないレコードを挿入します
- 対象テーブルに既に存在するレコードを再送信し、二重にロードされていないことを確認します。
- day_02 のロードで値列が変更されたときにキーのレコードを更新する
- 対象テーブル内のレコードを論理的に削除します
- プロセステーブルによってロードされる値
- 参照テーブルによってロードされる値
データロードテストシナリオ
- ターゲットとソースのデータベースが適切に接続されており、アクセスの問題がないことを確認してください。
- フルロードの場合は、truncate オプションをチェックして、正常に動作することを確認してください。
- データのロード中にセッションのパフォーマンスを確認します
- 致命的ではないエラーがないか確認します。
- 子タスクが失敗した場合に、呼び出し元の親タスクも失敗できることを確認します。
- ログが更新されていることを確認する
- 地図を確認するping (NAIST) と ワークフロー パラメータが正確に設定されている
- ソース システムとターゲット システムのテーブルの数が同じであることを確認します。
- ステージ テーブルの属性とターゲット テーブルの属性を比較します。 それらは一致する必要があります。
BIレポートのテストシナリオ
- 日付と時刻を表示する
- キー数値の小数精度
- 指定されたページの行数と列数を表示します。
- レポート内の自由な特性
- 特性と主要指標の両方について、空白値がどのように表示されるか
- 特性検索がキー、テキスト、またはその両方に対して機能するかどうかは、指定どおりです。
- テキスト検索が大文字と小文字を区別するかどうか、そしてそれが要件に合致するかどうか
BIテストにおける課題
- データ量。 データウェアハウスには数億行ものデータが蓄積されているため、網羅的な比較は不可能です。テストは、照合結果の合計値に加え、境界レコードや高リスクレコードを対象としたサンプリングに基づいて行われます。
- 異種発生源。 単一のデータウェアハウスは、リレーショナルデータベース、フラットファイル、API、レガシーシステムなどからデータを取得する可能性があり、それぞれが独自のエンコーディング、日付形式、およびヌル値の規則を持っています。
- 目に見える故障はありません。 報告書に誤った数値が記載されていても、それはエラーを示すものではありません。単に誤った判断を示唆するだけであり、そのため照合が唯一信頼できる検出方法となります。
- 情報源は絶えず変化する。 上流システムのスキーマ変更により、マップがサイレントに壊れるpingメタデータのテストは、リリース時だけでなく、定期的に実施する必要がある。
- ゆっくりと変化する次元。 過去の記録の正確性を確保するには、昨年有効だった記録には昨年の値が記載されていなければならないが、これは検証が難しく、間違いやすい。
- 環境の公平性。 テスト環境では本番環境規模のデータを持つことはほとんどないため、ロードウィンドウやクエリのパフォーマンス問題は、本番稼働後に初めて顕在化する。
共通しているのは、BIの欠陥は静かに進行するという点です。上記で挙げた対策はすべて、システム自体が何も発信しないところにシグナルを作り出すことで効果を発揮します。
