ウェブサイトパフォーマンステスト
究極のガイド

パフォーマンス テストが重要なのはなぜですか。

パフォーマンス テストは多くの理由で重要ですが、訪問者と顧客に世界クラスのエクスペリエンスを提供することは、リストの一番上にあります。 ウェブ サイトやアプリケーションが負荷の高い場合やストレスの下で動作することを保証するだけでなく、売上に直接影響を与える可能性があります。 たとえば ウェブ サイトやアプリケーションがすばやく読み込まれない場合や、訪問者の期待に応える場合、サイトが離れて、他の場所で探しているものを見つける可能性があります。 これは、競合他社への収益を失うことに加えて、潜在的な顧客であったであろうものを失うことを意味します。

パフォーマンステストは、年に一度行うものではありません。 たとえば、ほぼ毎月のオンラインショッピングの休日があります。 定期的なパフォーマンス テストを実行すると、システム ウェブ サイト、およびアプリケーションが正常に動作し、効率的に動作し、トラフィックの多い時間帯に、全体的なエクスペリエンスを継続的に向上させることができます。 テスト中に発見された問題やボトルネックは、ライブ環境の実際の訪問者に影響を与えないように、継続的に修正できます。 また、社内のビジネス関係者は、次の大きなプロモーションを展開する際に ウェブ サイトやアプリケーションが訪問者の流入やトラフィックの急増を管理できる自信を与えます。

パフォーマンス テストを実施することで、同時ユーザー数が大幅に増加する場合に ウェブ サイトやアプリケーションのパフォーマンスを発揮できるだけでなく、システムの応答を示すことができるため、システムに負荷をかけるとのスケールや、その要求に応じてリソースがどのように展開されているかを確認できます。 通常、パフォーマンス テストの主な要因は速度と読み込み時間ですが、スケーラビリティの問題はエラーを引き起こし、ディスクと CPU の使用率に影響を与える可能性があります。 パフォーマンスの観点から、システムの位置をベンチマークと総合的に把握することで、必要に応じて容量計画とハードウェアのアップグレードに必要なデータを得ることができます。

パフォーマンス テストをスキップするとどうなりますか?

パフォーマンス テストは、最も重要なソフトウェア テストの種類の 1 つですが、多くの組織では、パフォーマンス テストが重要であるとは思わないか、予算上の理由により、定期的に実行していません。 どのような場合であっても、組織は、開発サイクルにパフォーマンス テストを含めずに、多くの損失を生じるリスクがあります。 前に述べたように、ユーザー エクスペリエンスは、販売を作成または中断することができます。 ウェブサイトやアプリケーションが意図したとおりに動作していない場合、訪問者はバウンスを開始します。 そして、それが起こるとき、それはすでにそれらを取り戻すには遅すぎます。 パフォーマンス テストは、実稼働環境に何も入れる前に、十分に修正できたボトルネックを特定するのに役立ちます。

多くの訪問者、顧客、または内部ユーザーがアクセスして使用する ウェブ サイトまたはアプリケーションがある場合は、パフォーマンス テストをスキップすることが重要です。 マーケティングチームと営業チームは、自社のサービスや製品を大衆に宣伝し、関与させ、販売する仕事をしました。 ウェブサイトやアプリケーションを最適に実行し、負荷の下で実行する準備をしないことで、訪問者や顧客に不満を持ち、サイトに着陸する前に持っていた可能性のあるブランドロイヤルティを失うリスクがあります。 パフォーマンス テストに時間と投資を費やさないことで、潜在顧客を失うリスクを冒さないでください。

パフォーマンス テストと負荷テスト対ストレス テスト
違いは何ですか?

前述したように、パフォーマンス テスト カテゴリに該当するいくつかの種類のテストがあります。 通常、パフォーマンス テストについて話すとき、最も一般的な種類のテストであるため、負荷テストまたはストレス テストを参照している可能性があります。 ロード テストとストレス テストには類似点がありますが、ロード テストとストレス テストの違い、その違い、使用方法、その他の種類のパフォーマンス テストの種類について詳しく説明します。
パフォーマンス テストは、非機能テストの一形態です。 特定のソフトウェア機能が機能するかどうかをテストしようとする機能テストとは異なり、非機能テストでは、アプリケーションの操作性、パフォーマンス、信頼性などの機能性の問題がチェックされます。 機能テストは、パフォーマンス テストの前に実行されます。 機能テストと比較して、機能テストは迅速に実行でき、手動で行うことができます。 非機能テストはもう少し複雑であり、通常は自動化する必要があります。

たとえば、機能テストでは、ユーザーがポータルまたはアカウントにログインできるかどうかをテストします。 簡単に言えば、その機能は機能するかしないか。 パフォーマンス テストでは、機能テストが次のレベルにまで引き上げ、そのポータルまたはアカウントにログインできる同時ユーザー数をテストします。 これにより、システムがストレスの下でどのように処理および実行されるかを理解できるため、コードの最適化、負荷時間の短縮、ハードウェア容量の追加など、改善するボトルネックや領域を見つけることができます。

すべての種類のパフォーマンス テストでは、アプリケーションまたは ウェブ サイトに対して特定の条件と事前定義されたワークロードをシミュレートする必要があります。 パフォーマンス テストに関しては、実際の条件をシミュレートするほど、テスト結果が向上します。 パフォーマンス テストは定期的に実施する必要がありますが、新しいソフトウェアリリースの前に、サイトへの訪問者が大幅に増加するイベント、またはユーザーがページやアプリケーションの速度が遅いというコメントをユーザーがコメントする前に、必ず行う必要があります。 負荷テストとストレス テストは、どの要素が不安定になっているかを識別し、修正する必要がある要素を特定するのに役立つデータを提供するのに役立ちます。

ロード テストでは、システムが負荷をどのように管理し、パフォーマンスの低下が存在するかを確認するために、定義済みまたは予想される負荷をシステム、アプリケーション、または ウェブ サイトに配置する必要があります。 ロード テストの目的は、システムが特定のパフォーマンスしきい値内で負荷を管理できることを確認することです。 一方、ストレス テストは、アプリケーション、サイト、またはシステムが負荷を増加させるだけで、システムがブレークポイントに達するまで実行します。 負荷テストで定義済みのワークロードが設定されている場合、ストレス テストは、低下または完全な失敗が発生するまで負荷を継続的に増加させます。 ここで、利用可能なリソースがある時点を過ぎてシステムをプッシュした場合、ロード テストが予期せずストレス テストになる可能性があります。

したがって、ストレス テストよりもロード テストを選択する必要がある場合は、次のタイミングで行う必要がありますか。 前述のように、ストレス テストは、システムがブレークポイントに達するまで、できるだけ早く負荷を増やします。 一方、ロード テストには、特定のワークロード制限のもとで実際のユーザー アクション、動作、および ウェブ する一時停止が含まれます。 ストレス テストとは異なり、システムを障害の危機に追い込み、回復の仕方を見る必要はありません。

パフォーマンス テスト ツール

パフォーマンス テストは、ハードウェア、リソース、予算、および時間に大きな投資を要したプロセスでした。 組織は訓練を受けたパフォーマンス テストスペシャリストに頼る必要があり、このプロセスには数週間、あるいは数か月かかる可能性があります。 テクノロジの進歩が進み、ソフトウェア開発のライフ サイクルが短くなり、Agile と DevOps のプラクティスに従って、パフォーマンス テスト ソリューションを開発し、SaaS ベースのプラットフォームとしてリリースすることができました。 SaaS ベースのプラットフォームでは、オンプレミスのパフォーマンス テストに必要な負荷の高い投資は必要ありませんでした。

現在、オープンソースから商用バージョンまで、さまざまな優れたロードテストソリューションとツールが存在し、その間に至るまで、あらゆるものが存在します。 市場に出回っていて、ニーズに合ったパフォーマンス テスト ツールやソリューションを探している場合は、適切なツールを見つけることが非常に困難です。 組織のニーズは異なり、すべてのパフォーマンス テスト ツールが同じで作成されるわけではありません。 一部のパフォーマンス テスト ツールは限られており、少数のテクノロジとプロトコルしかサポートできませんが、さまざまなプロトコル ウェブ アプリケーション テクノロジをサポートし、さまざまなパフォーマンス テスト機能を使用できます。 有料版、無償バージョン、オープンソースバージョンなど、さまざまな種類のパフォーマンス テスト ツールの長所と短所について説明します。

また ウェブ ベースのパフォーマンス テスト ツールは、企業が追加のハードウェアやロード インジェクタに投資する必要がなくてパフォーマンス テストのコストを削減するのに役立ちますが、開発サイクルにパフォーマンス テストを含めようとしている小規模な組織にとって、コストは依然として大きな障壁となる可能性があります。

無料対有料パフォーマンステストツール

あらゆる種類のソフトウェアを検索することになると、最大の要因は常にそれがいくらかかるかにかかっているようです。 パフォーマンス テストの要件は、業界や組織によって異なるため、実際には、お客様のニーズに合ったソリューションを見つけ、予算に合ったソリューションを見つけることが重要です。 市場には無料のパフォーマンステストツールがたくさんありますが、トレードオフは、独自のサーバーと仮想負荷インジェクタを管理する必要があることです。 誰もがそれを取り除く技術的なノウハウや能力を持っているわけではありません。 また、小規模なパフォーマンス テストを実行する場合は、大規模な機能セットを持つツールの料金を支払う必要がなくなるので、無料のパフォーマンス テスト ツールは適切な場合があります。 ただし、無料のパフォーマンス テスト ツールの欠点の一部は、専用のサポート チームが存在せず、機能が制限され、大規模なテストを実行できないことです。

ただし、自分のインフラストラクチャでロード テストをセットアップ、管理、実行するための適切なチームやリソースを持たない小規模な組織の場合は、有料のパフォーマンス テスト ツールが適している可能性があります。 さまざまな機能とオプションを含む多くの商業オプションは、特定の予算に合わせてあります。 これらの ウェブ ベースのパフォーマンス テスト ツールは、独自の環境を設定する必要なく、稼働するために必要なすべてを提供します。 有料パフォーマンス テスト ツールの他の利点は、専用のサポート チーム、ユーザー フレンドリーなインターフェイス、および詳細なレポート オプションにアクセスできる点です。

無料のパフォーマンステストツール

前述したように、すべての組織にリソース帯域幅とパフォーマンス テストを実行する時間があるわけではありませんが、パフォーマンス テストはパフォーマンス テストをまったく行わないよりも優れています。 すべてのアプリケーションは負荷の下で異なるパフォーマンスを発揮するので、ユーザーと訪問者が素晴らしい体験を得られるようにアプリケーションをテストするために手で手に入れることができます。 小規模なチームや組織にとって、 無料のパフォーマンス テスト ツール は必要なすべてを提供できます。 一つには、事前投資(それが気に入らない人)はありませんが、チームがソフトウェアの使い方を学ぶには時間がかかる場合がありますので、初期学習曲線に時間を要します。

無料のパフォーマンスツールの欠点のいくつかについて、機能が満載されておらず、独自のパフォーマンステスト環境を設定する必要があるものもありますが、小規模なテストのみを実行する場合は、無料のパフォーマンステストツールが法案に適合する可能性があります。 ただし、優れたパフォーマンス テストの鍵となるのは、運用環境にできるだけ近い環境をセットアップすることです。 私たちのアドバイスは、あなたの要件を満たす無料のツールを研究し、あなたとあなたのチームのために働くものを見つけるためにいくつかの時間を取るです。

オープンソースのパフォーマンステストツール

オープンソース、または無料のパフォーマンステストツールのメリットとデメリットについて簡単に触れましたが、前述のように、オープンソースソフトウェアを変更したり変更したりできることは、組織にとって大きな利点となります。 パフォーマンス テストに関しては、1 つのサイズがすべてに適合するというものは存在しません。 また、オープンソースのパフォーマンステストツールは常に進化し、変化しています。 しかし、何百人もの人々が継続的に更新に取り組んでいるかもしれませんが、必ずしも顧客サポートではありません。 特定の問題を解決するために、オンラインドキュメントを調べる時間を無駄にするかもしれません。

有料パフォーマンステストツール

先ほど触れたように、有料のパフォーマンス テスト ツールを使用すると、パフォーマンス テストを実施する際の機能、機能、使いやすさを提供できます。 一般的に HTTP/プロトコル ベースのテストのみをサポートするオープンソースのパフォーマンス テスト ツールとは異なり、有料のパフォーマンス テスト ツールでは、実際のブラウザ ベースのテスト、複数のテスト場所、優れたレポートと分析を実行できます。 当然のことながら、予算に制約のあるチームにとって、適切なツールと計画を見つけることは微妙なバランスをとる行為です。 有料パフォーマンス テスト ソリューションの優れた点は、一般的に複数の価格レベルを提供し、長期契約にロックされていないので、チームはニーズを満たすプランを見つけることができるということです。

また、有料のパフォーマンス テスト ツールは、独自の負荷テスト環境をセットアップし、独自の負荷インジェクタ サーバーをインスタンス化する能力とハードウェアを確保する必要があるなど、オープンソースや無料のパフォーマンス テスト ツールで通常実行する必要がある作業の多くを削除します。 そのプロセスだけで節約できる時間とコストは、有料のパフォーマンステストツールを使用することを正当化するのに十分です。 最後に、有料のパフォーマンス テスト ソリューションに疑問がある場合は、通常、期間限定で試して判断できます。

パフォーマンス テスト ウェブ アプリケーション

ウェブ アプリケーションのパフォーマンスは、ユーザー エクスペリエンスとビジネスの収益に直接影響します。 ウェブ アプリケーションの開発と研磨に投入した投資は、パフォーマンス テストを行わない場合は、すべて無駄になります。 明らかに、最悪のシナリオは ウェブ アプリケーションがトラフィックであふれ、完全に失敗してクラッシュすることです。 これは、一連のロード テストまたはストレス テストを通じて、パフォーマンス テストを実行するうえで重要な点であり、パフォーマンスの問題を特定して修正して、悲惨な状況を回避できます。

今日の ウェブ アプリケーションは、AJAX、Java、JavaScript、PHP、NodeJS、AngularJS など、さまざまなテクノロジとフレームワークで構築できます。 さらに、多くのアプリケーションは、サードパーティのコンポーネントが正常に機能することを必要とします。 これらのサードパーティ製のプラグインとコンポーネントは ウェブ アプリケーションの開発と作成に最適ですが、パフォーマンステストの時間になると、制御不能なサードパーティ製プラグインの問題が発生する可能性があります。 パフォーマンス テスト ウェブ アプリケーションは、サーバー側のパフォーマンスだけでなく、ユーザー/クライアント レベルまでパフォーマンスを集中する必要があります。 ウェブ アプリケーション内でボトルネックが発生する場所を把握することは、改善の領域を特定し、より良いユーザー エクスペリエンスを提供するために不可欠です。

ウェブ アプリケーションのパフォーマンス テスト ガイダンス

アジャイル ソフトウェア開発の手法を採用する組織が増えるほど ウェブ アプリケーション開発は構築、テスト、および展開の各段階を通じてより効率的になりました。 しかし、プロセスはまだ完了していません。 実際の世界で ウェブ アプリケーションがどのように動作するかを決定することは、まったく別の問題です。 さいわい、パフォーマンス テスト プロセスをガイドするツールとソリューションがあります。 ウェブ アプリケーションのパフォーマンス テストを実装する際に必要な重要な手順と考慮事項について説明します。

パフォーマンス テスト ウェブ アプリケーションの最も重要な側面の 1 つは、実際の ウェブ ウェブ 直面する条件に合わせてテスト シナリオを設定することです。 アプリケーションが既に実稼働環境にリリースされている場合は、アプリケーションがどのような状況に陥るのかをよく知っておきますが、通常のトラフィック状況とピーク時の交通状況を確認することは常に良いことです。 ウェブ アプリケーションのパフォーマンス テストのもう 1 つの重要な要素は、テストのスクリプト化と自動化が可能であることです。 テストを実行するために実際の人々に頼る日々は過ぎ去りました。 スクリプト ツールは、日常的なユーザーのようにアプリケーションをウォークスルーし、これらのスクリプトをパフォーマンス テストに使用できます。

最後に、クラウドベースのパフォーマンス テスト ツールを使用している場合は、複数のリージョンからテストを実行できる可能性があります。 訪問者は世界の単一の地域から来ただけではないでしょう。 特定の地域からテストを実行できるように設定できることは、世界中のパフォーマンスの変動を理解するために重要です。 複数のリージョンで ウェブ アプリケーションのパフォーマンスの比較を確認できることで、ユーザーエクスペリエンスに関するさらなる洞察が得られます。

AWS とパフォーマンステストの説明

現在、組織の ウェブ アプリケーションや ウェブ サイトの展開に関しては、多くの選択肢があります。 AWS、Google Cloud、Microsoft Azure などのクラウド プロバイダーは、ハードウェア、ソフトウェア、およびサーバーリソースをクラウド プロバイダーにオフロードしてコストを削減し、効率的に活用する方法を提供します。 組織は、使用するリソースに対してのみ課金されます。 クラウドプロバイダーの分野では、AWS が支配的なプレーヤーとなっています。 AWS は、AWS Lamda、AWS EC2、AWS Lightsail など、さまざまな目的に対応する数百の製品やソリューションを提供しています。

ウェブアプリケーションのデプロイに関しては、AWS Lambda が選択した特定のサービスです。 AWS Lambda は、開発者がアプリケーションの開発に集中し、運用上の問題やリソースのプロビジョニングに時間を費やさない機能を提供します。 AWS Lambda が提供するすべてのものに対して、パフォーマンステストに関しては、いくつかの欠点があります。 たとえば、1 つの関数がすべてのリソースを消費して圧倒されないようにするため、またコスト削減策として同時実行制限を設定します。 数千人のユーザーが同時にアクセスする ウェブ アプリケーションを計画する場合は、必要な負荷を生成できるサードパーティ製のツールを使用してアプリケーションをテストすると、よりコスト効率が高く、レポートとデータ分析が向上します。

マイクロサービスとパフォーマンステスト

マイクロサービスという用語は、ここ数年で非常に人気があり、トレンドのトピックとなっています。 この用語は長い間続いていますが、コンテナ化技術により、最終的には組織が十分に活用できるものです。 従来のソフトウェア開発アプローチとは異なり、アプリケーションはよりモノリシックなアプローチで開発され、UI、アプリケーションロジック、データ層などのすべての機能とサービスが単一のユニットとして構築されました。 マイクロサービスは、基本的にこれらの機能とサービスを引き離し、それらを独自の個別のエンティティとして実行します。 ここでの利点は、他のサービスに影響を与えることなく、異なるサービスに同時に変更を加えることができるので、展開をより迅速かつシンプルにします。 また、サービスは互いに独立しているため、さまざまなプログラミング言語で構築できます。 ただし、この分散型アプローチにより、パフォーマンス テストが少し面倒になります。

マイクロサービスは通常 RESTful API を介して接続されるため、REST API とそのエンドポイントのテストをサポートするのと同じツールとプラットフォームでテストする必要があります。 ただし、マイクロサービスをパフォーマンス テストする場合、要求と応答を測定するだけではありません。 分散型の性質上、応答時間が遅い理由やネットワーク状態など、舞台裏でのアクティビティを観察する必要があります。 各サービスは、使用可能なリソースによって異なる方法で実行される場合があります。

角度アプリケーションのパフォーマンス テスト

Angular は、Google が開発したオープンソースの ウェブ アプリケーションフレームワークです。 Angular は通常、SPA (シングルページ アプリケーション) の構築に使用されます。 SPA の利点は、ブラウザ内で動作し、ユーザーが新しいページに移動するたびにページを再読み込みする必要がな点です。 一度読み込まれ、ユーザーの観点からは標準の ウェブ ページのように機能しますが、ブラウザーは毎回新しいページを読み込む必要がないため、パフォーマンスと使いやすさが向上します。 これはユーザーの観点からは素晴らしいことですが、パフォーマンス テストの観点からは、毎回新しい URL が読み込まれないため難易度が増します。

このため、ブラウザー内でユーザーアクションをスクリプト化し、そのシナリオを使用してパフォーマンス テストを実行できるツールを使用する必要があります。 JMeterやHPロードランナーのような標準のHTTPプロトコルパフォーマンステストツールに頼ることはできません。 AWS Lambda などのクラウドサービスからアプリケーションをデプロイする場合でも、作成および API ゲートウェイが必要なため、パフォーマンステストには制限があります。 これは、セットアップに時間がかかる場合があります。 それでも、プロトコル レベルでのみテストできます。 Angular アプリケーションとユーザーの操作の観点からパフォーマンスを測定することはできません。

パフォーマンス テスト ツール/ソフトウェアの推奨事項

パフォーマンス テスト ツールを選択する際には、次の点に関する考慮事項が数多くあります。 無償、有料、オープンソースのパフォーマンス テスト ソフトウェア ツールの利点と欠点について簡単に触れましたが、このセクションでは、今日の市場で最も人気のあるパフォーマンス テスト ソリューションについて説明します。 何が素晴らしいのか、どのように比較するのかを詳しく説明する簡単なレビューを提供します。 ウェブ サイト ウェブ アプリケーション、および API のフレームワークとテクノロジは絶えず進化しているため、現在のテクノロジニーズと将来のテクノロジニーズをサポートできるパフォーマンス テスト ツールを見つけることを強くお勧めします。 パフォーマンス テスト ツールを検索するときに考慮するその他の項目には、次のものがあります。

• 使いやすいインターフェイス
• テスト スクリプトの作成とカスタマイズ
• 複数の地理的位置からテスト
• チームが既に使用しているツールと統合
• 構成可能なレポートとダッシュボードを提供
• 優れたカスタマーサポート

最後に、ロード テストで ウェブ サイト、アプリケーション、および API の使用方法を反映させます。 優れたパフォーマンス テスト プラットフォームを使用すると、ユーザーや訪問者が使用するのと同じように、実際のブラウザーでテストを簡単に作成、構成、実行できます。 ユーザー エクスペリエンスを可能な限り厳密にシミュレートすることは、ユーザーが実際に実行できるパフォーマンスを理解するうえで重要です。

ビューを読み込む

ロード忍者

SmartBear からの LoadNinja は ウェブ サイト ウェブ アプリ、および API の負荷テスト プラットフォームであり、実際のブラウザーを利用して、より正確な実世界の結果を得ることができます。 LoadNinjaはまた、点を提供し、InstaPlayレコーダーと呼ばれるスクリプトツールをクリックします。 レコーダーは ウェブ サイトや ウェブ アプリ開発で使用される多くのテクノロジをサポートし、ロード テスト用のテスト スクリプトを簡単に作成できます。 LoadNinja は、テストの実行に 10 未満のグローバルな場所を提供します。 LoadNinja は、CI/CD プラットフォームでのパフォーマンス テストを自動化する API または Jenkins プラグインも提供します。 LoadNinjaプラットフォームは、より良いテスト管理のために、JIRAのためのZephyrのようなSmartBearの他の製品とも緊密に連携しています。 プランは、毎月または年間で購入できます。

ロードランナー

MicroFocusからのLoadRunnerは、パフォーマンステストソフトウェアスペースで長い間強力な市場シェアを持っていたもう一つの一般的なパフォーマンステストツールです。 このツールは、モバイルを含むあらゆる種類の ウェブ サイトやアプリケーションのパフォーマンステストを行うための幅広いプロトコルをサポートしており、非常に柔軟なツールとなっています。 LoadRunner は複雑なツールであり、オンプレミスで展開する必要がありますが、MicroFocus は LoadRunner クラウドと呼ばれる短期的な要件に対応する ウェブ ベースのソリューションを提供します。 このリストの他のパフォーマンス テスト ツールと比較して、LoadRunner ソリューションの中核的な LoadRunner ソリューションは高価です。 LoadRunner Professional は、このツールをサポートするキャパシティ、インフラストラクチャ、および開発チームを持つエンタープライズ レベルの顧客に向けられています。

ガトリング

ガトリングは ウェブ アプリケーションの限界をテストするために使用されるもう一つのオープンソースのパフォーマンステストツールです。 ガトリングは主にCI/CDのパイプラインと環境向けに設計されており、1台のマシン内で大量の負荷を発生させることができます。 ガトリングを使用すると、開発者はパフォーマンスの問題をテストして検出し、開発サイクル内でアプリケーションの応答時間を遅くすることができます。 JMeterやLoadRunnerと同様に、ガトリングはプロキシレコーダーを利用してスクリプトを作成します。 さらに複雑なスクリプトや手動スクリプトを作成するには、Scala プログラミング言語に関する豊富な知識が必要です。 また、HAR (HTTP アーカイブ ファイル) コンバータを使用して、開発者に少し制御し、オーバーヘッドを軽減することもできます。

k6

以前は LoadImpact と呼ばれていた K6 は、開発チーム向けのオープンソースおよび SaaS ロード テスト プラットフォームです。 このリストの他のツールと同様に、k6 は、Jenkins、GitLab、サークル CI、チーム シティなどの継続的インテグレーションと継続的な展開ソリューションと統合するように特別に設計されています。 API パフォーマンステストでは、k6 は Postman に依存しています。 ユーザーは Postman コレクションをエクスポートし、JavaScript スクリプトに変換してからロード テストを実行する必要があります。 k6 ユーザーは、15 を超えるグローバルロケーションのいずれかを使用してロード テストを実行できますが、複数の場所から同時にテストを実行するには、Team または Pro プランのいずれかに参加している必要があります。

究極のパフォーマンス テストに関する FAQ

パフォーマンス テストは複雑で時間のかかるプロセスですが、適切な計画およびパフォーマンス テスト ツールを使用すると、より簡単で再現性が高くなります。 パフォーマンス テストは、ソフトウェア開発のライフ サイクルにおいて重要なステップです。 負荷が大きい場合に不安定になる可能性のあるアプリケーションを展開するリスクを軽減し、ユーザーに悪影響を与えます。 以下に、パフォーマンス テストに関してよく寄せられる質問と回答を示します。
​

目次

1. ストレス テストはどのように行われますか?
2. オンラインでウェブサイトのパフォーマンスをテストするにはどうしたらいいですか?
3. パフォーマンス テストとロード テストの違い
4. パフォーマンス テスト ツールとは
5. 機能テストを実行するユーザー
6. 受け入れテストは ウェブ サイトで実行されますか。
7. 受け入れテストを実行するユーザー
8. ソフトウェアパフォーマンステストとは
9. ソフトウェアパフォーマンステストと ウェブ サイトのパフォーマンステストの違い
10. パフォーマンス テストのユーザー数はどのように計算しますか。
11. ウェブサイトのパフォーマンスをどのようにベンチマークしますか?
12. パフォーマンス テストの応答時間とは何ですか。
13. ブラウザ互換性テストとパフォーマンス テストの関連付け
14. 最適なパフォーマンス テスト自動化フレームワークとは何ですか。
15. 最高のパフォーマンステストツールは何ですか?

ストレス テストはどのように行われますか?

ストレス テストは、パフォーマンスが低下し始める時点まで、システム、アプリケーション、または ウェブ サイトをプッシュすることを目的としたパフォーマンス テストの一種です。 ストレス テストは、システムのブレークポイントの場所、リソースがどの時点で完全に消費されているか、およびシステムがどのように応答し、回復するかを示すために行われます。 逆に、ロード テストでは、事前に定義された負荷を使用して、システムのパフォーマンスと動作を測定し、パフォーマンスベースラインを設定し、容量を計画します。 ロード テストは、アプリケーションまたはシステムを意図的に失敗に追い込むようには設計されていません。

オンラインでウェブサイトのパフォーマンスをテストするにはどうしたらいいですか?

ウェブ サイトのパフォーマンスのテストは、いくつかの方法で行うことができます。 1 つの方法はウェブ ウェブ ページでウェブ サイトの速度テストを実行することです。 開発者やウェブ デザイナがアクセスできる無料のウェブ サイト速度テスト ツールが多数あり、ページ上のどの要素が読み込み時間に影響を与えているかを迅速に確認できます。 これらの ウェブ サイトの速度テスト ツールの優れた点は、通常、複数のテスト サーバーが含まれるため、訪問者がどの場所から来た場合に最も適した場所を選択できるということです。
ウェブ サイトのパフォーマンスをテストするもう 1 つの方法は、パフォーマンス テストを実行することです。 パフォーマンス テストでは、特定の期間にわたって ウェブ サイトにアクセスする数百または数千のユーザーをシミュレートすることで ウェブ サイトの速度テストを次のレベルにまで引き上げます。 パフォーマンス テストでは、限界に追い込まれたときに発生する CPU、メモリ、ネットワークの問題などのボトルネックが明らかになります。

パフォーマンス テストとロード テストの違い

パフォーマンス テストは、ロード テスト、ストレス テスト、スパイク テスト、耐久テスト、スケーラビリティ テスト、ボリューム テストなど、複数の種類のテストのサブセットを含む非機能テストの一種です。 これらすべてのパフォーマンス テストの種類は、負荷がシステムに置かれて、さまざまな側面とメトリックを決定しようとします。

パフォーマンス テスト ツールとは

パフォーマンス テスト ツールは、アプリケーション ウェブ サイト、または API の効率を判断したり、パフォーマンスの問題を引き起こしているネットワークのボトルネックやコンポーネントを特定したりするために使用できるソフトウェアです。 パフォーマンス テストは、高品質な製品を確実に市場に提供するために不可欠です。 パフォーマンス テスト ツールには、オンプレミス、クラウドベース、または場合によっては両方を含むさまざまな種類があります。 オンプレミス ツールの利点の 1 つは、テスト環境を完全に制御できる点です。 クラウドベースのパフォーマンス テスト ツールを使用すると、開発者は、テスト環境がプロバイダーによって完全に管理されている場合に、稼働を実現できます。

機能テストを実行するユーザー

機能テストは、QA エンジニアおよびチームによって実行されるソフトウェア テストの一種です。 機能テストは、特定の機能が機能するかどうかを調べるために行われます。 たとえば、アプリケーションの機能テストの 1 つの方法として、ユーザーが問題なく特定のページをナビゲートできる場合があります。 機能テストはパフォーマンスを気にせず、機能テストの主な目的は、関数の検証とエラーやユーザビリティの問題の報告のみを行います。 ソフトウェア開発のライフ サイクルでは、機能テストはパフォーマンス テストの前に実行されます。 パフォーマンス テストを開始する前に、ソフトウェアが動作することを確認する必要があります。

受け入れテストは ウェブ サイトで実行されますか。

ユーザー受け入れテスト(UAT テスト)は ウェブ サイトが正式にリリースされる前のソフトウェア開発サイクルの最後のストップです。 受け入れテストは ウェブ サイトが適切に機能し、ユーザーまたはクライアント、およびビジネスに関するすべての定義済み要件を満たしていることを確認するための最終レビューです。 エラーが見つかった場合、開発チームは QA と連携して、最終期限までにそれらを解決できます。 運用環境でこれらの問題を解決する方がコストがかかるので、UAT はコストを節約し、ユーザーに対する潜在的な不満を回避できます。

受け入れテストを実行するユーザー

UAT テストは通常、テスト担当者のグループによって手動で実行されますが、一連のスクリプトに基づいて自動化できます。 アプリケーションまたは ウェブ サイトで UAT テストの準備が整ったら、ユーザーが実行できるさまざまな実世界のシナリオを定義する必要があります。 たとえば、電子商取引 ウェブ サイトを管理する場合、さまざまな支払いオプションと関連する手順を個別にテストして、シームレスなプロセスを確保できます。

ソフトウェアパフォーマンステストとは

ソフトウェア・パフォーマンス・テストは、事前定義されたワークロードの下でソフトウェアのパフォーマンス、可用性、およびスケーラビリティを決定するプロセスです。 ソフトウェアパフォーマンステストの種類には、ロードテスト、ストレステスト、スパイクテスト、および耐久試験が含まれ、通常は機能テストが完了した直後に実施されます。

ソフトウェアパフォーマンステストと ウェブ サイトのパフォーマンステストの違い

ソフトウェア パフォーマンス テストと ウェブ サイト パフォーマンス テストの違いは、それほど異なるものではありません。 それは本当に彼らの定義に来ます。 ウェブ サイトは、ブラウザを介してインターネット経由でアクセスできるウェブ ページのコレクションです。 ソフトウェアとは、ブラウザで実行し ウェブ ページからアクセスできるプログラムまたはアプリケーションのことです。 もう 1 つの考え方は ウェブ ページは通常静的で情報であり ウェブ アプリケーションが対話的になる傾向があるということです。 ただし、その間の線がぼやけているため、誰に尋ねるかによって異なる説明が表示される場合があります。 通常、ソフトウェア アプリケーションのパフォーマンス テストを行う場合は、さまざまなユーザーアクションとパスをシミュレートするスクリプトを作成します。 ウェブ サイトのパフォーマンス テストを行う場合はウェブ サイトがトラフィックをどのように処理するか、およびクライアントとサーバーの問題があるかどうかを確認する必要があります。 ウェブ サイトのパフォーマンス テストを使用してユーザー パスをテストする場合は、あまり関心がありません。

パフォーマンス テストのユーザー数はどのように計算しますか。

パフォーマンス テスト中にシミュレートするユーザー数を把握するのは簡単ですが、間違った想定を作成したくないので、正しい同時ユーザー数を正しく計算するにはどうすればよいでしょうか。 1 つの方法は、Google アナリティクスなどのウェブサイト分析ツールを確認し、訪問者と訪問者の内訳を時間、日、または毎週の訪問で表示することです。 次に、ピーク交通量を見つけます。 ピークよりも大幅に低くなるため、平均トラフィックをオフにテストを行う必要はありません。 ピーク時よりも多くの同時ユーザーを設定して ウェブ サイトがピーク負荷を処理できることを確認します。 これらの要因を使用して、同時ユーザーを計算できます。 同時ユーザー数を計算するには、ピーク時の訪問を 1 回にして、平均訪問者の時間 (秒) で乗算し、それを 60 で除算して 1 時間の分数を指定します。

ウェブサイトのパフォーマンスをどのようにベンチマークしますか?

前述のように、ウェブ ウェブ 高速読み込みは、ユーザー エクスペリエンスと企業の収益にとって非常に重要です。 そのため、ウェブサイトのパフォーマンスを評価することが重要です。 これを行う1つの方法は、世界中のさまざまな場所からウェブサイトのスピードテストを実行することです。 ウェブ サイトのパフォーマンスをベンチマークする場合、ページ読み込み速度、応答時間、ページ サイズ、最初のバイトまでの時間 (TTFB)、最初のコンテンツ型ペイント (FCP)、対話式描画 (TTI) までの時間など、ページ上のメトリックの記録を保持する必要があります。 この指標を業界標準と比較し、パフォーマンスのギャップがあるかどうかを確認します。 そこから、 ウェブサイトの監視ツール を使用して、ウェブサイトが継続的にこれらのパフォーマンスガイドラインに従っていることを確認できます。

パフォーマンス テストの応答時間とは何ですか。

パフォーマンス テストの応答時間は、要求の送受信にかかる時間です。 たとえば ウェブ ページ上のボタンをクリックすると、要求がサーバーによって送信および受信され、完了するまでの応答時間が応答時間になります。 応答時間はウォーターフォールチャートとパフォーマンス結果に表示されます。 パフォーマンス テストで従う重要なメトリックは、平均応答時間と最大応答時間であるため、要素が意図したとおりに実行されていない時期を特定できます。

ブラウザ互換性テストとパフォーマンス テストの関連付け

ブラウザー互換性テストは、クロス ブラウザー テストとも呼ばれ ウェブ サイトまたは ウェブ アプリケーションが互換性があり、さまざまなブラウザーで実行されるかどうかをテストするプロセスです。 パフォーマンス テストを実行する場合は、ユーザーが通常使用するブラウザー内で ウェブ サイトと ウェブ アプリケーションをテストすることを確認します。 デスクトップやモバイル ブラウザーを意味する可能性があります。 デスクトップブラウザーとモバイルブラウザーでは、要素のレンダリング方法が異なるので、不整合を特定して迅速に修正するためにパフォーマンス テストを実行し、ユーザー エクスペリエンスを損なう必要はありません。 これは、ユーザーのネットワーク速度が場所によって異なるため、モバイル デバイスにとって特に重要です。

最適なパフォーマンス テスト自動化フレームワークとは何ですか。

テスト自動化フレームワークは、コードをテスト目的で自動化および再利用できるため、冗長テストの作成に時間を費やす必要がなさ、それに伴う関連コストを排除できるため、開発者にとって有益です。 これにより、チームはコードをより迅速かつ効率的にテストできるため、テスト サイクルが短くなります。 オートメーション ツールにはさまざまな種類があります。 最も人気のあるテスト自動化フレームワークのいくつかは、キュウリ、セレン、アピウム、キプロスです。 しかし、最高のパフォーマンステスト自動化フレームワークの1つはJenkinsです。 Jenkins は、開発者がソフトウェア アプリケーションをビルド、テスト、および展開できるオープンソースのオートメーション サーバーです。

最高のパフォーマンステストツールは何ですか?

最適なパフォーマンス テスト ツールは LoadView です。 LoadView にはウェブ サイト、API、ウェブ アプリケーション、ストリーミングウェブ メディアなど、いくつかのパフォーマンス テスト オプションが用意されています。 このソリューションでは、プロトコル ベースのテストと、実際のブラウザー ベースのテストを実行できます。 ウェブ アプリケーションの場合、ツールには、すべての一般的なウェブ テクノロジとフレームワークをサポートする EveryStep ウェブ Recorder と呼ばれるポイントとクリック スクリプト ツールが付属しており、ユーザー シナリオのスクリプトを簡単に作成できます。 世界中の 20 を超えるグローバル クラウド サーバーのいずれかから実行するようにテストを設定できるため、ローカル マシンを利用したり、テスト用にオンプレミスのハードウェアに投資したりする必要はありません。 テスト結果には、関係者と簡単に共有できる詳細なレポートやダッシュボードが含まれます。 オンデマンド オプションを含む複数の価格レベルを提供し、顧客サポートは 24 時間 365 日利用可能です。