7

イントラネット Web アプリケーションのテストを開始しようとしています。具体的には、アプリケーションのパフォーマンスを判断する必要があります。

アプリケーションのパフォーマンスを判断する方法について、公式/非公式の基準を提案してください。

4

4 に答える 4

8

ストレスおよび負荷テスト用のツールを使用します。Java を使用している場合は、JMeterをご覧ください。アプリケーションのパフォーマンスをテストするさまざまな方法を提供します。以下に焦点を当てる必要があります。

  • 応答時間: 通常のリクエストに対するアプリケーションの実行速度。読み取り/書き込みのユース ケースをテストする
  • ロード テスト: トラフィックが多いときにアプリケーションがどのように動作するか。ツールは、一定期間中に複数の要求を送信します (適切に構成できます)。
  • ストレステスト: あなたのアプリケーションは長時間稼働できますか? このテストは、アプリケーションを限界まで押し上げます

興味があれば、これから始めてください。他の種類のテストもあります。

于 2008-09-03T15:04:41.517 に答える
4

「具体的には、アプリケーションのパフォーマンスを判断する必要があります....」

これは、要件の問題、つまり合理的で効果的と見なされるものに対するユーザー コミュニティの期待に完全に帰着します。要件には多くのコンポーネントがあります

  1. 一般的な応答時間、「 ... の負荷の下で、サイトの一般的な応答時間は x、y% 未満の時間...」
  2. 具体的な応答時間、「 ... の負荷がかかると、クレジット カードの処理にかかる時間は z 秒未満になります...」
  3. システム容量の項目、「....CPU|ネットワーク|RAM|ディスクの負荷の下で、容量のn%を超えてはならない....」
  4. システム パフォーマンスを判断するために、特定の客観的な測定値が収集されるときに発生するユーザー数とトランザクション数の組み合わせである負荷プロファイル。

応答時間やその他の測定値が絶対的なものではないことに気付くでしょう。シックス シグマの製造原則から 1 ページ取ると、100 万分の 1 の例外から 10 億分の 1 の例外に移行するためのコストは並外れたものであり、例外をゼロにするためのコストは通常​​、平均的な組織では耐えられないコストです。組織固有のアプリケーションの許容応答時間と見なされる時間は、公共のインターネットに面したアプリケーションである高度にコモディティ化された製品とはまったく異なる可能性があります。非常に競争力のあるソリューションの場合、インターネットでの応答時間の期待は、ユーザーの放棄が大幅に増加する 2 ～ 3 秒の範囲に向かっている傾向にあります。これは、過去 10 年間で 8 秒から 4 秒に減少し、現在は 2 ～ 3 秒の範囲になっています。Facebook などの一部のアプリケーションは、競争上の理由から、1 秒未満の範囲でほとんど感知できない応答時間を目指して撮影します。厳しい基準を探している場合、それらは存在しません。

スタイル、形状、機能に関するいくつかの業界ベンチマークを読むことで、理解を深めることができます。

ニーズを表す堅固な一連のパフォーマンス テストを設定することは、簡単なことではありません。QA 作業のこのフェーズを担当するスペシャリストを雇うことができます。

ツールの選択では、できるものを入手してください

  • インターフェースを練習する
  • 要件に照らして報告する
  • あなたまたはあなたのチームは、使用するスキルを持っています
  • あなたはトレーニングを受けることができ、経営陣の祝福を受けて出席します

上記の 4 つの要素のいずれかが失敗した場合、市場で最も高価なツールを購入し、最も高価な会社を雇ってそれを展開したことになります。

幸運を！

于 2011-09-29T14:44:54.607 に答える
3

本当に重要なのは応答時間だと思いますが、他の指標として、プロセッサとメモリの使用量と同時ユーザー/プロセスの数を比較します。また、通常の負荷とピーク負荷の下で、すべてが期待どおりに機能していることも確認します。負荷が高くなると、さまざまな要求が互いに影響し合い、アプリケーション エラーが発生するシナリオが発生する場合があります。

本当に詳細な情報を取得したい場合は、さまざまな種類の負荷/ストレス テストを実行する必要があります。おそらく、ステップ ロード テスト (時間の経過とともにシステム上のユーザーが徐々に増加する) とスパイク テスト (以前はほとんど誰もアクセスしていなかった場所に多数のユーザーが同時にアクセスする) を確認することをお勧めします。また、サーバーを再起動した直後にサーバーに対してテストを実行して、それがシステムにどのように影響するかを確認します。

また、HEAT (Hostile Environment Application Testing) と呼ばれる概念も検討することをお勧めします。これは実際に、システムの一部がオフラインになったときに何が起こるかを示しています。システムは正常に劣化しますか? これは重要な基準となるはずです。

私の本当に大きな提案の 1 つは、テストを行う前にシステムが何をすべきかを確立することです。主な理由は説明責任です。システムが何かを行うことになっていることを人々に認めてもらい、それが正しいかどうかをテストします。これは重要です。なぜなら、人々はすぐに結果を確認し、それが許容範囲の基準となるからです。

于 2008-09-03T15:28:53.753 に答える
3

フロントエンドをテストするには、ユーザーの観点からページの読み込みにかかる時間の統計を取得するのに YSlow が最適です。これは、特定の HTTP リクエストごとの統計、所要時間などに分類されます。http://developer.yahoo.com/yslow/ で入手できます。

もちろん、Firebugも不可欠です。プロファイル ボタンを押すと、JS を明示的またはリアルタイムでプロファイリングできます。必要に応じて最適化を行い、すべての機能の実行にかかる時間を確認します。これにより、JS コードのパフォーマンスを測定する方法が変わりました。http://getfirebug.com/js.html

于 2008-09-03T15:00:18.750 に答える