タイトル:loadrunner を使用すると、さまざまなグラフや詳細データを含む HTML レポートを生成できます。ただし、Jmeter でテストした後、HTML レポートを直接生成することはできません (GUI またはコマンド ラインで開始した場合でも)。
調べてみると、Jmeter の extras ディレクトリに HTML を生成するための xsl スタイルシートがあることが分かりました。実際、Jenkins+ant+Jmeter で生成される HTML レポートもここのスタイルシートを呼び出すことで生成されます。
pass xsltproc report.jtl > test .html、または ant も使用できます。このコマンドは、Jmeter 結果ファイルを HTML レポートに変換します。結果は次のとおりです。 ここで HTML レポートを生成できますが、このレポートは使用するには弱すぎ、パラメータが少なすぎます。したがって、このレポートは拡張する必要があります。 Jmeter 独自の集計レポートのデータは比較的完成度が高いため、
そのレポートの値に応じて拡張する予定です。
xsltproc、xlst の紹介
XSL は、XML を HTML に変換するために使用される EXtensible Stylesheet Language (EXtensible Stylesheet Language) を指します。 xlsに精通しています
スタイルシートを変更および拡張します。この言語は http://www.w3school.com.cn/xsl/index.asp で学習できます。xsltproc は高速 XSLT エンジンで、HTML、-html.xsl hoto.xml -o html.html などの XSL カスケード スタイル シートを通じて XML を対応する形式のファイルに変換できます (ここでスタイル シートを直接記述することもできます)ファイルを jtl ファイルの href 属性に追加し、この XML にどのスタイル シートを使用するかを直感的に示します)
xpath は xls 内の XML を検索するために使用されます。したがって、xsltproc エンジンは xpath1.0 バージョンを使用する必要があります。したがって、スタイルシートで xpath を使用する場合、xpath2.0 の関数および一部のプロパティは使用できません。 xpath についてはよく知っていますが、xls についてはまったく詳しくありません。レポートを拡張するために xls と xpath を直接学習する方法はありません。 (xlsについての紹介は改めてブログに書き、使用中に発生した問題や経験などをまとめます)
antとJmeterを直接使って統合する場合は直接生成できますが、HTMLを変換するantのエンジンはxpath1のみをサポートしています.0. その後、ほとんどのエンジンがxpath2.0に対応していないため、期間中はxpath2.0の機能が使用できないことが分かりました。
90%Line time 90%Line time を表示できるようにするには、まずこのインジケーターが一連のデータ、つまりポジションの 90% でのデータの時間に相当することを理解する必要があります。展開するときは、位置のインデックスの 90% を知るだけで、この値を取得できます。 以下はキー コードの一部です
rrree
ここでの主な目的は、時間要素のコレクションと 90% ラインの位置を取得することです。これらの 2 つのパラメーターを使用して、その後の展開を次のように実行できます。
90%Line、95%Line、99%Line の計算原理は同じなので、1 つの値を計算さえすれば、他の値も簡単に計算できます
QPS 拡張機能
Jmeter の特定のレポートにはスループットの値があり、loadrunner ではスループットとして表されます。ここでは QPS または TPS (トランザクションが使用される場合) を表すことができます。これは、より直感的であるため、私は個人的にこれを QPS と呼びます。
%90Line と同様に、この値がどのように計算されるかを最初に知る必要があります。情報を検索し、公式 Web サイトと比較したところ、この値は次の式で計算されることがわかりました。
公式 Web サイトのスクリーンショット:
スループット = (リクエスト数) / (合計時間)
合計時間 = テスト終了時間 - テスト開始時間
テスト終了時間 = MAX (リクエスト開始時間 + 経過時間) テスト開始時間 = MIN (リクエスト
計算式が分かれば簡単です。キーコードは次のとおりです:
rrree展開された結果は次のとおりです:
スループット拡張
loadrunner では、スループットは Throughput です。 Jmeter の集計レポートでは、1 つの列の値がロードランナーのスループットです。区別しやすくするために、ここでは値をスループット
と呼びます。
情報を検索したところ、スループットの計算式は次の式であり、QPS の計算式と同じであることがわかりました。
スループット = (要求された総バイト数) / (総時間)
ここでの合計時間の計算 QPS と同じで、すべてのリクエストから直接合計バイト数を加算できます。 キー コードは次のとおりです。
<xsl:variable name="allMedianTime"> <xsl:call-template name="LineTime"> <xsl:with-param name="nodes" select="/testResults/*/@t" /> <xsl:with-param name="position" select="ceiling($allCount * 0.9)" /> </xsl:call-template> </xsl:variable>
TPS 拡張子
TPS Jmeter では、一部の状況は QPS と一致していますが、まだ不一致があるため、それも行う必要がありますここで展開すると、結果がより鮮明に表示されます。
まず、他のパラメータ拡張と同様に、計算式を知る必要があります。ここでの計算式も QPS と同じですが、拡張後の効果は次のとおりです。 拡張プロセス中に、Jmeter の集計結果の最後の「全体」行の計算値が場合によっては不正確であることがさらに判明しました。スクリプトにトランザクションが含まれておらず、[親サンプルの生成] が選択されている場合、ここでの結果は正確です。スクリプトにトランザクションがあり、[親サンプルの生成] が選択されていない場合も、ここでの結果は正確です。トランザクションがない場合、計算
メソッドを見ると、すべてのリクエストが含まれていることがわかるため、結果は不正確になります。
たとえば、jtl ファイルには HTTP リクエストとトランザクションの両方が含まれています。トランザクションは以前のリクエストの統計にすぎず、リクエスト自体を送信するものではないため、合計スループット、QPS、および TPS を計算するときにこのように計算することはできません。
したがって、拡張プロセス中、1 つのスタイル シートはトランザクションの有無を処理し、1 つのスタイル シートはすべてのトランザクションを処理します。現時点では TPS で測定されており、この
は正確です。
テスト
いくつかの指標を拡張しました。これらの指標はどの程度正しいですか?さまざまな状況でテストする必要があります。テスト後、各インジケーターは正しくなります。ただし、大規模なデータ量レベルでのテストは行われていません。テスト後に問題が見つかった場合は、時間内に変更されます
。
覚えておいてください: リクエストはスタイルシートの lb に従って区別されるため、ここでのラベルを繰り返すことはできません。また、Jmeter を含む集計レポートはすべてラベルによって区別されます
追記: 拡張プロセス中、最初の困難は次のとおりです。式の計算方法、2 つ目は、拡張スタイルシート言語を指す xls はあまり馴染みがなく、多くの制限があることです。これについては、次のブログで説明します。しかし、使用した後は、xpath と xls の両方に非常に慣れていると感じています。
第三に、より多くのインジケーターをカスタマイズできるように、Jmeter のテスト結果ファイルの各フィールドに精通する必要があります。これについては、別のブログでも説明します
OneAPM モバイル インサイトは、実際のユーザー エクスペリエンスをメトリクスとして使用し、クラッシュ分析、モニターします。ネットワーク リクエストとネットワーク エラーを防止し、ユーザー維持率を向上させます。 OneAPM 公式 Web サイトにアクセスして、アプリケーションのパフォーマンス最適化のエクスペリエンスをさらに体験してください。さらに技術的な記事を読みたい場合は、OneAPM 公式テクノロジー ブログにアクセスしてください。