volume testing tutorial
ボリュームテストの概要：
下の写真は、何らかの形でアプリと相関関係がありますか？はい、これは、サーバー、データベース、Webサービスなどを過負荷にしたときに正確に発生することです。
私たち全員が機能テストと非機能テストを知っている必要がありますが、非機能テストは機能テストと同じくらい重要であるという事実に注意していますか？短期間のリリースでは、この機能しないテストを無視する傾向がありますが、理想的にはそうすべきではありません。
製品の所有者がこの要件を与えているかどうかは、私たちにとって重要ではありません。このテストは、小さなリリースの場合でも、完全なテストプロセスの一部と見なす必要があります。
ボリュームテストに関するこのチュートリアルでは、より良い方法で理解できるように、その意味、必要性、重要性、チェックリスト、およびいくつかのツールの完全な概要を説明します。
学習内容：
- ボリュームテストとは何ですか？
- このテストはいつ必須ですか？
- なぜボリュームテストを目指す必要があるのですか？
- このテストのチェックリストは何ですか？
- ボリュームテストと負荷テスト
- このテストを実行する方法は？
- ボリュームテストツール
- 結論
- 推奨読書
ボリュームテストとは何ですか？
ボリュームテストは、非機能テストの一種です。このテストは、データベースによって処理されるデータ量を確認するために行われます。フラッドテストとも呼ばれるボリュームテストは、データベースの膨大なデータに対してソフトウェアまたはアプリのパフォーマンスをチェックするために行われる非機能テストです。
データベースに大量のデータを追加することにより、データベースがしきい値ポイントまで拡張され、システムの応答がテストされます。
これは理論の部分でした。理解に役立ついくつかの実用的な例を紹介します。 'いつ' ボリュームテストの一部。
このテストはいつ必須ですか？
理想的には、すべてのソフトウェアまたはアプリでデータ量をテストする必要がありますが、データが重くならない場合は、このテストを回避する傾向があります。ただし、データが毎日MBまたはGBで処理される場合は、必ずボリュームテストを実行する必要があります。
以下は、私自身の8年間の経験から、「いつ」の部分を説明するいくつかの例です。
例1：
私のベンチャーの1つは、Webアプリとモバイルアプリの両方で構成される大きなシステムでした。しかし、Webアプリ自体には、3つの異なるチームによって処理される3つのモジュールがありました。
時々、私たちがいても、私たち全員がテスト用のデータを「一緒に」追加すると、データベースの速度が低下することがありました。それは煩わしく、大量のデータのために作業が妨げられ、作業を簡単にするためにDBを頻繁にクリーンアップする必要がありました。
「ライブ」システムが処理していたデータは約GBでした。したがって、モバイルアプリと比較した場合、ウェブアプリはデータの量について非常に頻繁にテストされました。 WebアプリのQAチームには、夜間に実行してこのテストを実行する独自の自動化スクリプトがありました。
例2：
私のベンチャーのもう1つの例は、Webアプリだけでなく、SharePointアプリやインストーラーさえも備えたエコシステムでした。これらのシステムはすべて、データ転送のために同じデータベースと通信していました。そのシステムによって処理されるデータも非常に巨大であり、何らかの理由でDBが遅くなると、インストーラーでさえ機能しなくなります。
したがって、ボリュームテストは定期的に実行され、DBのパフォーマンスは問題がないか細かく観察されました。
同様に、 私たちは取ることができます例大量のデータトランザクションを処理するため、ボリュームテストが必要な、ショッピング、チケットの予約、金融トランザクションなどに日常的に使用するいくつかのアプリの一部です。
逆に言えば、理想的なボリュームテストは、独自の制限と課題があるため、常に達成できるとは限りません。
その制限と課題のいくつかは次のとおりです。
- メモリの正確な断片化を作成することは困難です。
- 動的な鍵の生成には注意が必要です。
- 理想的な実環境、つまりライブサーバーのレプリカを作成するのは難しい場合があります。
- 自動化ツール、ネットワークなどもテスト結果に影響します。
今、私たちは理解しました いつ このタイプのテストを行う必要があります。私たちも理解しましょう 'なぜ' このテストを実行する目的または目的のように、このテストを実行する必要があります。
なぜボリュームテストを目指す必要があるのですか？
ボリュームテストは、システムが実際の世界にどの程度適合しているかを理解するのに役立ちます。また、後でメンテナンス目的で使用される費用を節約するのにも役立ちます。
このテストを実行する理由として考えられるものは次のとおりです。
- 最も基本的なニーズは、増加したデータに対してシステムのパフォーマンスを分析することです。大量のデータを作成すると、応答時間やデータ損失などの観点からシステムのパフォーマンスを理解するのに役立ちます。
- 膨大なデータとしきい値で発生する問題を特定します。
- 持続可能ポイントまたはしきい値ポイントを超えると、システムの動作、つまりDBがクラッシュした場合に応答しなくなったり、タイムアウトしたりします。
- DB過負荷のソリューションを実装し、それらを検証します。
- DBの極値（修正できない）を見つけて、それを超えるとシステムに障害が発生するため、予防策を講じる必要があります。
- 複数のDBサーバーの場合、DB通信の問題、つまり、サーバーから最も障害が発生しやすい問題を見つけるなど。
これで、このテストを実行することの重要性と理由がわかりました。
または ここで共有したい経験は、モバイルアプリに関しては、一度に1人しかアプリを使用せず、モバイルアプリはシンプルに設計されているため、ボリュームテストは必要ない場合があるということです。 。
したがって、多くのデータが関与する非常に複雑なアプリがない限り、ボリュームテストはスキップできます。
システムまたはアプリで何を確認する必要があるかがわかったら、次に行うことは、アプリが定義するチェックリストを作成することです。 '何' テストする必要があります。
このテストのチェックリストは何ですか？
配列をメソッドjavaに渡す
アプリまたはシステムのチェックリストを作成するためのいくつかの例に入る前に、ボリュームテストのチェックリストまたはテストを開始する前のアプローチを作成する際に留意すべきいくつかのポイントを最初に理解しましょう。
覚えておくべきポイント：
- 開発者はシステムについて多くのことを知っており、入力やボトルネックさえも提供できるため、テスト計画について開発者を常に把握しておいてください。
- テストを戦略化する前に、サーバー構成、RAM、プロセッサーなどの物理的側面を十分に理解してください。
- DB、プロシージャ、DBスクリプトなどの複雑さを可能な限り理解して、システム全体の複雑さの概要を説明できるようにします。
- 可能であれば、通常のデータ量とシステムの状態について、インフォマティクス（グラフ、データシートなど）を準備します。これにより、DBに負荷をかける前に、通常のデータロードに対してパフォーマンスが良好であることを確認できます。これは、ストレスの多い部分に進む前に、ボリュームテストの修正が必要な問題がないことを確認するのにも役立ちます。
以下は、チェックリストに追加または使用できるいくつかの例です。
- データの保存方法が正しいかどうかを確認してください。
- システムに必要なメモリリソースがあるかどうかを確認します。
- 指定された制限を超えるデータ量のリスクがあるかどうかを確認します。
- データ量に対するシステムの応答を確認して観察します。
- ボリュームテスト中にデータが失われていないかどうかを確認します。
- データが上書きされている場合は、事前の情報を使用して上書きされていることを確認してください。
- 多くの属性（検索可能）のように、通常の範囲を超えて拡張する領域を特定します。ルックアップテーブル、多くのロケーションマッピングなど。
- 前述のように、最初に通常のボリュームの結果を取得してベースラインを作成してから、ストレスをかけます。
他の例、テストケース、およびツールに進む前に、まず、このテストが負荷テストとどのように異なるかを理解しましょう。
ボリュームテストと負荷テスト
以下に、ボリュームテストと負荷テストの主な違いをいくつか示します。
| S.No. | ボリュームテスト | 負荷テスト |
|---|---|---|
| 1 | ボリュームテストは、DB内の大量のデータに対してデータベースのパフォーマンスを検証するために実行されます。 | 負荷テストは、リソースのユーザー負荷を変更し、リソースのパフォーマンスを検証することによって行われます。 |
| 二 | このテストの主な焦点は「データ」です。 | このテストの主な焦点は「ユーザー」です。 |
| 3 | データベースは最大限にストレスを受けています。 | サーバーは最大制限までストレスを受けています。 |
| 4 | 簡単な例は、巨大なサイズのファイルを作成することです。 | 簡単な例として、多数のファイルを作成することができます。 |
このテストを実行する方法は？
このテストは、手動または任意のツールを使用して実行できます。一般的に、ツールを使用すると時間と労力を節約できますが、ボリュームテストの場合は私の経験によると ツールを使用すると、手動テストと比較してより正確な結果が得られます。
テストケースの実行を開始する前に、次のことを確認してください。
- チームは、このテストのテスト計画に同意しました。
- プロジェクトの他のチームは、データベースの変更とその作業への影響について十分な情報を得ています。
- テストベッドは、指定された構成に設定されています。
- テストのベースラインが準備されます。
- テスト用の特定のデータボリューム（データスクリプトまたはプロシージャなど）の準備ができています。データ作成ツールについては、データ生成ページをご覧ください。
実行に使用できるいくつかのサンプルテストケースを見てみましょう。
ボリュームテスト用に選択したすべてのデータボリュームについて、これを確認します。
- データの追加が正常に実行できるかどうか、およびデータがアプリまたはWebサイトに反映されているかどうかを確認します。
- データの削除が正常に実行できるかどうか、およびデータがアプリまたはWebサイトに反映されているかどうかを確認します。
- データの更新が正常に実行できるかどうか、およびデータがアプリまたはWebサイトに反映されているかどうかを確認します。
- データの損失がなく、すべての情報がアプリまたはWebサイトに期待どおりに表示されていることを確認します。
- データ量が多いためにアプリまたはウェブページがタイムアウトしていないことを確認します。
- データ量が多いためにクラッシュエラーが表示されないことを確認します。
- データが上書きされておらず、適切な警告が表示されていることを確認してください。
- ウェブサイトまたはアプリの他のモジュールがクラッシュしたり、大量のデータでタイムアウトしたりしていないことを確認します。
- DBの応答時間が許容範囲内にあることを確認します。
ボリュームテストツール
前に説明したように、自動化テストは時間を節約し、手動テストと比較して正確な結果をもたらします。ボリュームテストにツールを使用するもう1つの利点は、夜間にテストを実行できることです。これにより、他のチームやチームメンバーの作業がDBのデータボリュームの影響を受けなくなります。
午前中にテストをスケジュールすることができ、結果の準備が整います。
以下は、いくつかのオープンソースボリュームテストツールのリストです。
＃1）DbFit：
これは、テスト駆動開発をサポートするオープンソースツールです。
DbFit テストフレームワークはFitnessの上に記述され、テストはテーブルを使用して記述され、任意のJavaIDEまたはCIツールを使用して実行できます。
＃2）HammerDb：
HammerDb また、自動化、マルチスレッド化が可能で、ランタイムスクリプトも可能にするオープンソースツールです。 SQL、Oracle、MYSQLなどで動作します。
＃3）JdbcSlim：
JdbcSlim コマンドはSlimFitnessに簡単に統合でき、JDBCドライバーを持つすべてのデータベースをサポートします。焦点は、構成、テストデータ、およびSQLクエリを個別に保持することです。
＃4）NoSQLMap：
この は、攻撃を自動的に注入し、DB構成を中断して脅威を分析するように設計されたオープンソースのPythonツールです。 MongoDBでのみ機能します。
＃5）Ruby-PLSQL-spec：
Oracleはオープンソースツールとして利用できるため、PLSQLはRubyを使用して単体テストできます。 この 基本的に2つのライブラリを使用します。 Ruby-PLSQLとRspec。
結論
ボリュームテストは、データベースのパフォーマンスを分析するために行われる非機能テストです。それは手動で、そしていくつかのツールの助けを借りて行うことができます。
このテストに不慣れなQAの場合は、最初にツールで遊ぶか、いくつかのテストケースを実行することをお勧めします。これは、テストに入る前にボリュームテストの概念を理解するのに役立ちます。
このテストは非常にトリッキーであり、独自の課題があるため、実行する前に、概念、テストベッドの作成、およびDB言語について完全に理解しておくことが非常に重要です。
このチュートリアルがこのトピックに関する知識量を増やしたことを願っています:)