comprehensive hadoop testing tutorial big data testing guide
このチュートリアルでは、HadoopおよびBigDataテストの基本、テストタイプ、プラン、必要な環境、テストプロセス、検証と検証について説明します。
このチュートリアルでは、HadoopテストとBigDataテストの基本的な概要を説明します。たとえば、テストがいつどこで行われるか、Hadoopテストの一部として何をテストする必要があるかなどです。
また、次のトピックについても詳しく説明します。
- Hadoopテストの役割と責任
- Hadoop / BigDataテストのテストアプローチ
=> ここでビッグデータトレーニングチュートリアルのA〜Zを確認するには、ここをクリックしてください。
学習内容：
- Hadoopでのデータの保存と処理
- BigDataとHadoopのテスト
- ビッグデータをテストするための戦略または計画は何ですか？
- BigDataテストのテストタイプ
- BigDataHadoopテスト用のツール
- テスト環境と設定
- Hadoopテストの役割と責任
- Hadoopテスト/ビッグデータテストのテストアプローチ
- 結論
- 推奨読書
Hadoopでのデータの保存と処理
Hadoopシステムでこれらのプロセスを実行するために、4つのセクションに分類されるマンパワーがあります。
- Hadoop管理者 環境のセットアップを担当し、Hadoopシステムにアクセスするための管理者権限を持っています。
- Hadoop開発者 さまざまな場所から一元化された場所へのデータのプル、保存、および処理に関するプログラムを開発します。
- Hadoopテスター さまざまな場所からプルする前と中央の場所でプルした後のデータの検証と検証、およびデータをクライアント環境にロードするときに検証と検証が行われます。
- Hadoopアナリスト データのロードが完了したとき、およびデータがクライアントの場所にあるウェアハウスに到達したときに動作します。彼らはこのデータをレポートとダッシュボードの生成に使用します。アナリストは、成長と事業開発のためにデータ分析を実行します。
Hadoopは単一のシステムではないことを私たちは知っています。複数のシステムとマシンが含まれています。データは分割されて複数のマシンに保存されます。再度アクセスする場合は、データを結合してレポートなどに取り込む必要があります。
開発者は、データを抽出して保存するためのプログラムをJAVAおよびPythonで作成する責任があります。
開発者のもう1つの仕事は、データを処理することです。 Hadoopには2つのレイヤーがあります。1つはHadoopHDFSの保存用で、もう1つはHadoopMapReduceの処理用です。
保存とは、ソースにあるデータがシステムに保存/挿入されることを意味します。処理とは、それを複数のマシンに分割し、再度結合してクライアントに送信する必要があることを意味します。
したがって、保存と処理はプログラミングスクリプトによって行われ、開発者はスクリプトを作成する責任があります。
プログラミングとは別に、Hadoopでデータを保存および処理する他の方法は、Hive、Impala、HBaseなどのデータベースアプリケーションを使用することです。これらのツールはプログラミングの知識を必要としません。
BigDataとHadoopのテスト
開発者が保存と処理を行うと、データはレポートの生成に使用されます。その前に、処理されたデータの正確性を検証し、データが正確にロードされて正しく処理されているかどうかを確認する必要があります。
そのため、開発者が作成したプログラムやスクリプトは、HadoopまたはBigDataテスターで検証する必要があります。テスターは、スクリプトを検証してコマンドを実行するために、Mapper、Hive、PigScriptsなどの基本的なプログラミングを知っている必要があります。
したがって、テストを行う前に、テスターはすべてのプログラムとスクリプトが機能していること、コードの記述方法を知ってから、それらをテストする方法を考える必要があります。テストは、手動または自動化ツールを使用して実行できます。
Hadoopには、単体テスト、回帰テスト、システムテスト、パフォーマンステストなど、さまざまな種類のテストがあります。したがって、これらは、HadoopテストやBigDataテストだけでなく、通常のテストでも使用される一般的なテストタイプです。
HadoopテストとBigDataテストには、テスト戦略、テストシナリオ、テストケースなどの同じ種類のテスト用語があります。ここではアプリケーションではなくデータをテストする必要があるため、環境のみが異なり、BigDataとHadoopシステムのテストに使用するさまざまな種類の手法があります。
ビッグデータをテストする方法と、ビッグデータでテストする必要があるすべてのものは何ですか？
ビッグデータのテストでは、いくつかの計画と戦略が必要です。
したがって、次の点を考慮する必要があります。
- ビッグデータのテストの戦略または計画は何ですか？
- ビッグデータにはどのようなテスト手法が適用されますか？
- 必要な環境は何ですか？
- ビッグデータを検証および検証する方法は？
- ビッグデータテストで使用されるツールは何ですか？
上記のすべての質問に対する答えを取得してみましょう。
ビッグデータをテストするための戦略または計画は何ですか？
ビッグデータテストとは、データウェアハウスにデータを保存および処理する際のデータの検証と妥当性確認を意味します。
BigDataをテストする際、さまざまなデータベースから抽出され、データウェアハウスまたはHadoopシステムにロードおよび処理されるデータの量と種類をテストする必要があります。このテストは、機能テストの対象となります。
さまざまなデータベースからダウンロードされ、パフォーマンステストの一部であるHadoopシステムにアップロードされたデータの速度をテストする必要があります。
したがって、計画または戦略として、ビッグデータテストの機能テストとパフォーマンステストに集中する必要があります。
ビッグデータテストでは、テスターはコモディティハードウェアと関連コンポーネントを使用して大量のデータの処理を検証する必要があります。したがって、データの品質もビッグデータのテストで重要な役割を果たします。データの品質を検証および検証することが不可欠です。
BigDataテストのテストタイプ
前のセクションでは、機能テストとパフォーマンステストがビッグデータテストで重要な役割を果たしていることを確認しました。ビッグデータテスターとしてのテストとは別に、データベーステストやアーキテクチャテストなど、さらにいくつかの種類のテストを実行する必要があります。
これらのテストタイプは、機能テストやパフォーマンステストと同じくらい重要です。
＃1）アーキテクチャテスト
このテストは、データの処理が適切であり、要件を満たしていることを確認するために行われます。実際、Hadoopシステムは大量のデータを処理し、リソースを非常に包括的に処理します。
アーキテクチャが不適切な場合、パフォーマンスが低下し、データの処理が中断され、データが失われる可能性があります。
＃2）データベーステスト
ここで、プロセスの検証が全体像になり、さまざまなデータベースからのデータを検証する必要があります。つまり、ソースデータベースまたはローカルデータベースからフェッチされたデータが正しく適切である必要があることを確認する必要があります。
また、ソースデータベースで利用可能なデータがHadoopシステムに入力されたデータと一致することを確認する必要があります。
同様に、Hadoopシステムのデータが処理後または変換後に正しく適切であるかどうかを検証し、適切な検証と検証を行ってクライアントの環境にロードする必要があります。
データベーステストの一環として、 クルーエル 操作、すなわち 作成する その後、ローカルデータベースのデータ 取得 データとそれを検索する必要があり、データウェアハウスにロードする前後、およびデータウェアハウスからクライアントの環境にデータベースで利用できる必要があります。
の検証 更新しました データの保存またはロードおよび処理のすべての段階に関するデータ。破損したデータまたは重複したnullデータの削除。
＃3）パフォーマンステスト
パフォーマンステストの一環として、データの読み込みと処理速度をチェックする必要があります。つまり、IOPS（1秒あたりの入出力）のようになります。
さまざまなデータベースからデータウェアハウスまたはHadoopシステムへの入力として、およびHadoopシステムまたはデータウェアハウスからクライアントの環境への入力としてデータまたはデータを入力する速度を確認する必要があります。
また、さまざまなデータベースおよびデータウェアハウスから出力として送信されるデータの速度も確認する必要があります。これは、1秒あたりの入出力またはIOPSと呼ばれるものです。
それとは別に、別の側面は、データ吸収とデータ配布のパフォーマンス、およびデータがさまざまなデータベースからデータウェアハウスによって、およびHadoopシステムからクライアントのシステムによって消費される速度をチェックすることです。
また、テスターとして、Hadoopシステムまたはデータウェアハウスで利用可能なさまざまなファイルにデータがどのくらいの速さで配布されるかなど、データ配布のパフォーマンスを確認する必要があります。同様に、クライアントシステムにデータを配布するときにも同じプロセスが発生します。
Hadoopシステムまたはデータウェアハウスは複数のコンポーネントで構成されているため、テスターはMapReduceジョブ、データの挿入と消費、クエリの応答時間とそのパフォーマンス、検索のパフォーマンスなど、これらすべてのコンポーネントのパフォーマンスを確認する必要があります。操作。これらはすべてパフォーマンステストに含まれています。
＃4）機能テスト
機能テストには、すべてのサブコンポーネント、プログラムとスクリプト、保存またはロードと処理の操作を実行するために使用されるツールなどのテストが含まれます。
テスターにとって、これらは、クライアントが完全でエラーのないデータを取得するためにデータをフィルタリングする必要がある4つの重要なタイプとステージです。
BigDataHadoopテスト用のツール
BigDataのテストに使用されるさまざまなツールがあります。
- BigDataを保存するためのHDFSHadoop配布ファイルシステム。
- BigDataを処理するためのHDFSMapReduce。
- NoSQLまたはHQLCassandra DB、ZooKeeper、HBaseなどの場合。
- EC2のようなクラウドベースのサーバーツール。
テスト環境と設定
どのタイプのテストでも、テスターには適切な設定と環境が必要です。
以下に要件のリストを示します。
- テストされるデータとアプリケーションのタイプ。
- 保存と処理には、大量のデータ用に大きなスペースが必要です。
- クラスタ全体のすべてのDataNodeでのファイルの適切な配布。
- データの処理中は、ハードウェアの使用率を最小限に抑える必要があります。
- アプリケーションの要件に応じた実行可能なプログラムとスクリプト。
Hadoopテストの役割と責任
Hadoopテスターとして、要件の理解、テスト見積もりの準備、テストケースの計画、いくつかのテストケースをテストするためのテストデータの取得、テストベッドの作成、テスト計画の実行、欠陥の報告と再テストを担当します。
また、毎日のステータスレポートとテストの完了に責任を持つ必要があります。
最初に説明するのは、 テスト戦略 。問題の解決策を提案したら、テスト計画を計画または戦略化する必要があります。そこで使用する自動化戦略、納期に応じたテストスケジュールに関する計画、およびリソース計画について話し合う場合があります。
自動化戦略は、製品のテストに必要な手作業を減らすのに役立つものです。テストスケジュールは、製品のタイムリーな納品を保証するため、重要です。
テストに必要な工数と、テスト計画を実行するために必要なHadoopリソースを計画する必要があるため、リソース計画は非常に重要です。
テストの戦略を立てたら、テスト計画の作成、テストの自動化に役立つテストスクリプトの作成、およびテスト計画で使用されるテストデータの特定を含むテスト開発計画を作成する必要があります。そして、それらのテスト計画を実行するのに役立ちます。
テスト計画、テストスクリプト、およびテストデータの作成を含むテスト開発が完了したら、先に進んでそれらのテスト計画の実行を開始します。
テスト計画を実行すると、実際の出力が期待どおりにならない特定のシナリオが発生する可能性があり、それらは欠陥と呼ばれます。欠陥があるときはいつでも、それらの欠陥もテストする必要があり、それらのマトリックスを作成して維持する必要があります。
これらはすべて、次のカテゴリに分類されます。 欠陥管理 。
欠陥管理とは何ですか？
欠陥管理は、バグ追跡、バグ修正、およびバグ検証で構成されています。当社が保有する製品のいずれかに対してテスト計画が実行され、特定のバグが特定されるか欠陥が特定されるとすぐに、その欠陥を開発者に報告するか、開発者に割り当てる必要があります。
したがって、開発者はそれを調べて作業を開始できます。テスターとして、バグの進行状況を追跡し、バグが修正されたかどうかを追跡する必要があります。報告されたとおりにバグが修正された場合は、先に進んで再テストし、解決されたかどうかを確認する必要があります。
すべてのバグが修正され、クローズされ、検証されたら、OKAYテスト済み製品を提供する必要があります。ただし、製品を納品する前に、UAT（ユーザー受け入れテスト）が正常に完了していることを確認する必要があります。
インストールテストと要件の検証が適切に行われていることを確認します。つまり、クライアントまたはエンドユーザーに提供される製品は、ソフトウェア要件ドキュメントに記載されている要件に従っています。
私たちが議論したステップは想像力に基づいており、それらのステップに使用するテストシナリオまたはテストアプローチのいずれかであるか、製品をテストして最終結果を提供するためにそれらのフレーズを言います。 OKAYテスト済みの製品。
先に進んでこれについて詳しく説明し、Hadoopテストと関連付けてみましょう。
Hadoopはバッチ処理に使用されるものであり、ETLはHadoopが頻繁に使用されるフィールドの1つであることもわかっています。 ETLは、Extraction Transformation andLoadingの略です。 。これらのプロセスについては、Hadoopテストの観点からテスト計画とテスト戦略について説明するときに詳しく説明します。
以下の図のように、4つの異なるデータソースがあると想定しています。運用システム、CRM（ 顧客関係管理 ）およびERP（ エンタープライズリソースプランニング ）はRDBMSであるか、私たちが持っているリレーショナルデータベース管理システムと言います。また、ログ、ファイル、レコードなど、データソースに関するフラットファイルもいくつかあります。
SqoopやFlumeなどの特定の製品を使用して、データやレコードなどをデータソースとして取得している可能性があります。これらのツールを使用して、データソースからステージングディレクトリにデータを取得できます。これは、プロセスの最初のフェーズである 抽出。
実際にHDFS（Hadoop Distribution File System）であるステージングディレクトリ内のデータがあれば、特にPIGなどのスクリプト言語を使用して 変換 そのデータ。それ 変換 私たちが持っているデータによるでしょう。
私たちが持っているスクリプト技術を使用してデータがそれに応じて変換されると、 読み込み中 そのデータをデータウェアハウスに入れます。データウェアハウスから、そのデータはOLAP分析、レポート、データマイニング、または分析に使用されます。
先に進んで、Hadoopテストに使用できるすべてのフェーズについて説明しましょう。
最初のフェーズは抽出フェーズになります。ここでは、ソースデータベースまたはフラットファイルからデータを取得します。その場合、すべてのデータがソースからステージングディレクトリに正常かつ正しくコピーされたことを確認できます。
これには、レコードの数、レコードのタイプ、フィールドのタイプなどの検証が含まれる場合があります。
このデータがステージングディレクトリにコピーされたら、次に進み、2番目のフェーズである変換をトリガーします。ここでは、ソースシステムからコピーされたデータに作用し、実際にデータを作成または必要なビジネスロジックに変換するビジネスロジックがいくつかあります。
変換には、データの並べ替え、データのフィルタリング、2つの異なるデータソースからのデータの結合、およびその他の特定の操作が含まれる場合があります。
データが変換されたら、先に進んでテスト計画を準備し、期待どおりの出力が得られているかどうかを確認します。得られているすべての出力は、期待される結果とデータ型、フィールド値、および範囲などは定位置に落ちているものです。
正しくなったら、先に進んでデータをデータウェアハウスにロードできます。
ロードフェーズでは、ステージからのレコード数とデータウェアハウス内のレコード数が同期しているかどうかを実際にチェックしています。これらは類似していない可能性がありますが、同期しているはずです。また、変換されたデータのタイプが同期しているかどうかも確認します。
このデータを製品の最後のレイヤーであるOLAP分析、レポート、およびデータマイニングに使用することを投稿します。その場合、後続のレイヤーを使用するか、これらすべてのレイヤーでテスト計画を利用できると言えます。
ソースから宛先にデータを取得するときは常に、認証された人だけがデータへのアクセスを許可されていることを確認する必要があります。
認証
承認
これらの両方の用語はどういう意味ですか？
これを理解するために、ETL図から物事を概観してみましょう。
上の図のように、ソースRDBMSエンジンとフラットファイルからHDFSにデータを取得しており、そのフェーズは抽出と呼ばれます。
特定の方法で認証について説明しましょう。その性質によって制限されたデータを持つ特定の企業があります。このタイプのデータは、米国の基準ではPIIデータと呼ばれています。
PII を意味する 個人を特定できる情報、 生年月日、社会保障番号、携帯電話番号、電子メールアドレス、自宅の住所などの情報はすべてPIIに該当します。これは制限されており、すべての人と共有することはできません。
データは、それを最も必要としている人と実際の処理のためにデータを必要としている人とだけ共有する必要があります。このチェックと最初の防衛線を設定することを認証と呼びます。
例えば、 ラップトップを使用していて、そこにWindowsがインストールされている場合、Windowsオペレーティングシステムでユーザーアカウントが作成されている可能性があり、そこでパスワードを適用していました。
このようにして、この特定のユーザーアカウントの資格情報を持っている人だけがシステムにログインできます。これにより、データを盗難や不要なアクセスから保護することができます。もう1つの層は承認です。
例、 Windowsオペレーティングシステムには2つの異なるユーザーアカウントがあります。1つのユーザーアカウントは私たちのもので、もう1つはゲストユーザーアカウントである可能性があります。管理者（WE）は、ソフトウェアのインストールとアンインストール、新しいファイルの作成、既存のファイルの削除など、あらゆる種類の操作を行う権利を有します。
一方、ゲストユーザーはこの種のアクセスをすべて持っているわけではありません。ゲストには、システムにログインするための認証がありますが、ファイルの削除または作成、システム内およびシステムからのソフトウェアのインストールとアンインストールをそれぞれ行う権限はありません。
ただし、認証されているため、ゲストユーザーアカウントには、作成されたファイルを読み取り、既にインストールされているソフトウェアを使用する権利があります。
これは、認証と承認がテストされる方法です。この場合、HDFSで利用可能なデータ、またはデータの認証と承認を確認する必要があるファイルシステムのいずれかです。
Hadoopテスト/ビッグデータテストのテストアプローチ
テストアプローチは、通常の手動テスト、自動化テスト、セキュリティテスト、パフォーマンステストに進むときに、BigDataまたはHadoopテストであるという理由だけでなく、すべての種類のテストに共通です。したがって、どの種類のテストも同じアプローチに従います。
要件
テストアプローチの一環として、最初に 要件 、要件は基本的なものであり、今日のアジャイルプロセスでは、ストーリーとエピックと呼ばれています。エピックはより大きな要件に他なりませんが、ストーリーはより小さな要件です。
要件には、基本的に、すべてのデータモデル、ターゲット、ソース、適用する必要のある変換の種類、使用する必要のあるツールの種類が含まれています。これらすべての種類の詳細は、要件で利用可能になります。
これは基本的にクライアント要件または顧客要件です。この要件に基づいて、テストプロセスを開始します。
推定
アプローチの別の部分は 推定 、テストの一部としてアクティビティ全体が実行されるまでに必要な時間。テスト計画、テストシナリオの準備、テストケースの準備、およびその実行を行います。また、欠陥を見つけて報告し、テストレポートも作成します。
これらすべてのアクティビティには時間がかかるため、これらすべてのアクティビティを完了するために必要な時間は、基本的に見積もりと呼ばれます。経営陣に大まかな見積もりをする必要があります。
テスト計画
テスト計画 プロセス、何をテストするか、何をテストしないか、テストの範囲は何か、スケジュールは何か、必要なリソースの数、ハードウェアとソフトウェアの要件、タイムラインとテストサイクルについての説明に他なりません。使用される、必要なテストレベルなど。
テスト計画中に、彼らはプロジェクトへの特定のリソース割り当てを行い、私たちが持っているさまざまなモデル、必要なリソースの数、必要なスキルセットの種類など、これらすべてのものと側面がテストに含まれます計画フェーズ。
ほとんどの場合、リードレベルまたは管理レベルの人々がテスト計画を行います。
テストシナリオとテストケース
テスト計画が完了したら、準備する必要があります テストシナリオとテストケース 、特にビッグデータテストの場合、要件ドキュメントとともにいくつかのドキュメントが必要です。この要件文書とともに、何が必要ですか？
必要です 要件文書 クライアントのニーズが含まれていますが、これに加えて、 入力ドキュメント つまり データモデル。 データベーススキーマとは何か、テーブルとは何か、そしてこのすべてのデータがデータモデルで利用できる関係とは何かという意味でのデータモデル。
また、 マッピングドキュメント 、のマッピングドキュメント 例えば。 リレーショナルデータベースにはいくつかのテーブルがあり、HDFSのデータウェアハウスでETLを介してデータをロードした後、実行する必要のあるすべてのマッピングは何ですか？つまり、マッピングデータ型。
C ++用のEclipseをセットアップする方法
例えば、 HDFSに顧客のテーブルがある場合、HDFSにはCUSTOMER_TARGETテーブルがあるか、同じテーブルがHIVEにある可能性があります。
このCustomerテーブルには特定の列があり、CUSTOMERTARGETテーブルには図に示すように特定の列があります。顧客テーブルから顧客ターゲットテーブル、つまりソースからターゲットにデータをダンプしました。
次に、顧客テーブルの列1と行1であるソーステーブルに存在するデータのように正確なマッピングを確認する必要があり、それをC1R1と見なし、同じデータを顧客ターゲットテーブルのC1R1にマッピングする必要があります。これは基本的にマッピングと呼ばれます。
検証する必要のあるすべてのマッピングをどのようにして知ることができますか？したがって、これらのマッピングはマッピングドキュメントに表示されます。マッピングドキュメントでは、お客様はあらゆる種類のマッピングを提供します。
また、私たちは 設計図書 、開発チームとQAチームの両方に必要な設計ドキュメント。お客様が提供する設計ドキュメントでは、実装するMap Reduceジョブの種類、入力を受け取るMapReduceジョブの種類、MapReduceの種類を指定します。 Jobsは出力を提供します。
同様に、HIVEまたはPIGがある場合、お客様が作成したすべてのUDFと、それらが受け取るすべての入力、およびそれらが生成する出力の種類などは何ですか。
テストシナリオとテストケースを準備するには、これらすべてのドキュメントを手作業で用意する必要があります。
- 要件文書
- データ・モデル
- マッピングドキュメント
- 設計図書
これらは組織ごとに異なる可能性があり、これらすべてのドキュメントを用意する必要があるという必須の規則はありません。すべてのドキュメントがある場合もあれば、2つまたは3つのドキュメントしかない場合もあります。また、プロジェクトの複雑さ、会社のスケジュールなど、すべてが1つのドキュメントに依存する必要がある場合もあります。
テストシナリオとテストケースのレビュー
テストシナリオとテストケースのレビューを実行する必要があります。これは、何らかの理由で、または場合によっては、要件で実行できるすべての可能性を誰もが考えることができないために、テストケースを忘れたり、見逃したりするためです。サードパーティのツールまたは他の誰かからの助け。
したがって、ドキュメントを準備したり、何かを実行したりするときはいつでも、開発者やテスターなど、同じチームのメンバーをレビューする必要があります。彼らは、何かをもっと含めるための適切な提案をするか、テストシナリオとテストケースの更新または変更を提案します。
それらはすべてのコメントを提供し、これに基づいて、テストシナリオとテストケース、および要件に従ってドキュメントが完全に更新されるまでチーム全体でリリースする必要があるドキュメントの複数のバージョンを更新します。
テストの実行
ドキュメントの準備ができたら、上位チームからサインオフを取得して、基本的にテストケース実行と呼ばれる実行プロセスを開始します。
実行中にテストケースを実行する場合は、開発者が情報を送信する必要があることを確認する必要があります。通常の機能テスト、その他のテスト、またはビルドが必要な自動化テストの場合。ただし、ここではHadoopまたはBigDataテストの観点から、開発者はMapReduceジョブを提供します。
HDFSファイル– HDFSにコピーされるファイルはすべて、特権を確認するために必要です。HIVEテーブルのデータを検証するために開発者が作成したHIVEスクリプト、および開発者が開発したHIVE UDF、PIGも必要です。スクリプトとPIGUDF。
これらはすべて、開発者から取得する必要があるものです。実行に行く前に、これらすべてのものを用意する必要があります。
MapReduceジョブの場合、いくつかのJARファイルが提供され、HDFSの一部として、HDFSにデータが既にロードされており、ファイルの準備ができており、HIVEテーブルのデータを検証するためのHIVEスクリプトが必要です。彼らが実装したUDFが何であれ、HIVEUDFで利用できるようになります。 PIGスクリプトとUDFにも同じことが必要です。
欠陥の報告と追跡
テストケースを実行すると、いくつかの欠陥、予想されるものと実際のものが期待される結果と等しくないことがわかります。そのため、同じものをリストアップして開発チームに提供し、解決する必要があります。これは基本的に欠陥レポートと呼ばれます。
MapReduceジョブに欠陥が見つかった場合、それを開発者に報告すると、開発者はMapReduceジョブを再作成し、コードレベルの変更を行ってから、最新のMapReduceジョブを提供します。これをテストする必要があります。 。
これは継続的なプロセスです。ジョブがテストされて合格したら、再度テストして開発者に報告し、次のジョブをテスト用に取得する必要があります。これは、欠陥の報告と追跡のアクティビティが実行される方法です。
テストレポート
すべてのテストプロセスを完了し、欠陥を閉じたら、テストレポートを作成する必要があります。テストレポートは、これまでのテストプロセスを完了するために行ったことです。すべての計画、テストケースの作成と実行、取得した出力など、すべてがテストレポートの形式でまとめて文書化されます。
これらのレポートは、毎日、毎週、またはお客様のニーズに応じて送信する必要があります。現在、組織はアジャイルモデルを使用しているため、すべてのステータスレポートはデイリースクラム中に更新する必要があります。
結論
このチュートリアルでは、次の手順を実行しました。
- BigDataをテストするための戦略または計画。
- ビッグデータテストに必要な環境。
- ビッグデータの検証と検証。
- BigDataのテストに使用されるツール。
また、次のことも学びました–
- Hadoopテストの一部として、テスト戦略、テスト開発、テスト実行、欠陥管理、および配信が役割と責任においてどのように機能するか。
- 要件の収集、推定、テスト計画、テストシナリオとテストケースの作成、およびレビューを含む、Hadoop / BigDataテストのテストアプローチ。
- また、テストの実行、欠陥の報告と追跡、およびテストの報告についても知るようになりました。
このビッグデータテストチュートリアルがお役に立てば幸いです。
=> ここですべてのビッグデータチュートリアルを確認してください。