simple approach xml database testing
この記事は、XMLを理解するのに役立ちます データベーステストの概念 、これは挑戦的です テストタイプ 。
データの比較は、品質を達成するための重要なタスクです。欠陥があると、アプリケーションで1つまたは複数の障害が発生します。
XMLはデータを含む電子通信メッセージ形式であり、データベースはデータを含むテーブル/列を備えた物理ストレージです。
ほとんどのアプリケーションは相互にデータを交換します。これらの通信は、データを含むXMLメッセージの形式である場合があります。また、このデータはデータベースシステムに保存されており、必要に応じてアプリケーションによってデータがフェッチされます。
また読む => XMLテクノロジーを使用したデータテストの優れた方法
金融、マーケティング、販売、eコマース、自動車、ロジスティクス、製造などのほとんどのドメインでは、アプリケーションとのデータ通信にこの手法を使用しています。
XMLからデータベースへのテストを成功させるために最も重要な入力は マッピングドキュメント これは、XMLの各要素とデータベースの列を定義します。
マッピングドキュメントは、要素（XML）と列（DB）の関連付けの完全な表現を提供します。 XML要素の値は、DBテーブルへの入力にすることも、その逆も可能です。
ソフトウェアテストにおけるトレーサビリティマトリックスとは
この記事では、XMLメッセージデータをデータベースデータに対してテストしてデータの正確性を確認する方法をよく理解できます。
学習内容：
XMLとデータベースについて話しましょう：
アプリケーションは、さまざまな手法を使用して相互に通信します。 XMLを使用したメッセージ通信もその1つです。 XMLは、2つのアプリケーション間でメッセージ（データ）を通信するための信頼できる手法です。 XMLには、特定の値を持つ要素のセットが含まれています。値がNULLまたは空白になる場合があります。
データベースはデータをテーブルの形式で保存します。データベースにはいくつかのテーブルが含まれています。アプリケーションはデータベース内のテーブルにデータをフィードでき、必要に応じてアプリケーションがテーブルデータをフェッチすることもできます。
現在、アプリケーションはデータベーステーブルからXML形式でデータを格納/フェッチできます。これは非常に信頼性が高く柔軟な手法です。
アプリケーションアーキテクチャ：
テスターとして、次のことが重要です。
- 製品アーキテクチャを調べて、アプリケーションがモジュール/データベース間でメッセージをどのように通信しているかを理解します。この情報を調べて、不整合/質問があることがわかったら、BA / SAに連絡して説明を求めることができます。
- アップストリームおよびダウンストリームのアプリケーションデータフローを理解します。
- アプリケーションへのインバウンドおよびアウトバウンドのデータフロー。
場合によっては、アップストリームアプリケーションとダウンストリームアプリケーションが異なるアプリケーションのデータベースであり、ストアドプロシージャ、Webサービス、APIなどを使用してXML形式でデータを通信/送信している場合もあります。データを通信しているデータベースとアプリケーションの組み合わせが存在する場合もあります。お互いに。
例：
このXMLからデータベースへのテストの記事では、データベースと通信してデータを格納するアプリケーションについて考えてみましょう。
ダウンストリームアプリケーションがあります IBAPX 、XML形式のメッセージをデータベースアプリケーションに送信します MYDBX 。アップストリームアプリケーションがあります OBAPX 、からデータをフェッチします MYDBX レポートアプリケーションの場合 RPTX そしてそれはへのアップストリームアプリケーションです OBAPX 。
注意： 始める前に、ミドルウェア通信に使用されるテクノロジー（ストアドプロシージャ、Webサービス、APIなど）を理解し、アーキテクチャを明確に理解してください。この情報は通常、設計ドキュメントまたはSA / BA / Devチームにあります。
現在、アプリケーションIBAPXはデータベースアプリケーションMYDBXにデータを保存しています。 xmlのどの要素がテーブルの列にマップされているかを知るには、参照する必要があります マッピングドキュメント 。 XML要素と列名が同じである場合とそうでない場合があります。違いはビジネスニーズによるものです。
例えば 。 IBAPXが次の名前の要素を送信しているとしましょう 受注番号 、ただし、MYDBXが同じ要素値をテーブルに格納している場合、MYDBXはそれを次のように参照します。 p_orderid 列名。これは、XML要素が販売関連エンティティと呼ばれているためである可能性があります。同じ値がテーブルに格納されている場合、列名が本番用に変更されている可能性があります。これは、ビジネスニーズに応じて他のアプリケーションで変更される場合があります。
テスト方法：
では、テスターはどのようにしてすべてのシナリオを効果的かつ効率的にテストできるでしょうか。議論しましょう。
まず、入力XMLファイルを取得して XML構造を検証します つまり、要素。これは、それぞれのXMLの構造を定義するXSDを使用して実行できます。
XSDファイルはXMLのように見え、要素名、要素タイプ、minOccurs、maxOccursなどのXMLの構造を定義します。XML検証が完了したら、それをexcelにエクスポートします。 xmlファイルを新しいExcelシートにドラッグするだけです。 (XMLテーブルとして)を選択するだけで、ファイルをどのように開くかを尋ねるポップアップが表示されます。データはテーブルとしてExcelファイルに保存されます。
テーブルに入力されたデータを確認し、特定のデータを使用してテーブルにクエリを実行し、レコードをフェッチできます。同じExcelファイルのデータを別のシートにコピーします。 ExcelでEXACT関数を使用すると、XMLデータとDBデータを簡単に比較できます。列名ではなくデータのみを比較するようにしてください。
このようにして、複数のレコードデータを比較できます。 手作業を大幅に節約できます XML要素のデータ値とDB列のデータ値を比較するため。
参考のために以下のスナップを見つけてください。
注意： 上の画像では、前に説明したように列名が一致しなかったことがわかります。
ヒント： 大きなサイズのXMLとDBを比較しているときに、問題が発生することがあります。その場合、管理する必要があるのは、Excelシートの列の値を配置することだけです。 1つのことを覚えておいてください： Excelファイルの比較は 100MBのファイルサイズに制限されます 。それを超えると、パフォーマンスの問題が発生します。
前に説明したように、XML要素の値はDBテーブルへの入力にすることができ、その逆も可能です。したがって、DBアプリケーションからアプリケーションへのインバウンドファイルとしてXMLメッセージを取得したら、上記のテスト手法を実行して、XMLとDBのデータ値を比較する必要があります。複数のアプリケーションがデータを処理しているE2Eテストを実行する必要がある場合があります。
実際の例：
ユーザーがeコマースサイトのFlipkartに本を注文しました。開始点はユーザーがアイテムを注文することであり、終了点はeコマースセンターで請求書のコピーを受け取ることです。その後、注文の返品または交換、支払いの返品などのシナリオが発生する可能性があります。
ここでは、販売、在庫、アイテム処理、ロジスティクス、支払い、返品、オファーなどの複数のモジュールが、アイテムが顧客に届くまで注文を処理するために含まれています。 E2Eフローは、注文を履行するためにメッセージを通信しています。
E2Eテストに従事するときのテスターとして、アプリケーションとDB、またはDBからDB、またはアプリケーションからアプリケーションのデータを検証するシナリオに出くわす必要がある場合があります。ここでは、E2Eデータフローを完全に明確にする必要があります。つまり、アプリケーションが受信または送信するデータと、DBに保存されているデータまたはDBからフェッチされているデータを明確にする必要があります。
障害シナリオ：
考えられるいくつかの障害シナリオについて説明しましょう。
- 単純な障害シナリオの1つは、 誤ったマッピング 。 XML要素とDB列の間のマッピングは、テスターが分析または計画段階で分析する必要があります。疑問を明確にするために、BA / SAとすべてのマッピングの懸念について話し合ってください。マッピングがフリーズしたら、XML要素とDB列の値が一致することを確認できます。
- 値を比較し、一致しない場合は、問題を解決するために欠陥をログに記録します。データの欠陥のように、発生した欠陥には多くの可能性があります– テストデータの問題 ;コードの欠陥–データ値を解析してマップしないコードのバグである可能性があります。アーティファクトの欠陥– BA / SAによって提供された誤ったマッピングである可能性があります。
- XML形式の問題– XMLヘッダーまたはメタデータまたはいくつかの誤ったxmlタグ。この場合、XML自体がデータ値をデータベーステーブルに格納できませんでした。
- データ型の不一致– XMLの要素値の長さが、DB列が受け入れることができる長さを超えています。これはコードの問題であり、開発チームはその列のデータ型の長さに必要な変更を加える必要があります。
- 環境障害– 環境がダウンしているか、DBアプリケーションがダウンしている場合、データフローは不完全なままです。
- パフォーマンスの問題– メッセージを構成するレコードの量が膨大であるか、DBの負荷が高く、レコードの構成が大きすぎる可能性があります。
- ミドルウェア障害 アプリケーションからデータベースへのデータフローのレットダウンが発生します。
- データベースアクセスの問題 そのため、インバウンドアプリケーションはデータをそれぞれのテーブルに送信できません。
結論：
1つのXMLメッセージが複数のシステムにデータを格納する場合、XMLからデータベースへのテストはより複雑になります。また、大量のデータを保存/取得するためのデータベースのパフォーマンスは、テスターがそのようなシナリオをテストする際の課題になります。
上記の例は、アプリケーションで実行されるテストアクティビティの小さなセグメントです。テスターは、同様のアプローチで大量のデータテストを行う必要がある場合があります。
コメント、質問、経験を以下にお知らせください。