題記：在用 loadrunner 的時候可以生成一個 HTML 的報告，並且裡面包含各種圖表，各種詳細的資料。而在使用 Jmeter 測試完後並不能直接生成 Html 的報告（無論是用 GUI 還是命令列啟動）。

經過查詢資料發現 Jmeter 的 extras 目錄下有生成 HTML 的 xsl 樣式表，其實 Jenkins+ant+Jmeter 生成的 HTML 報告也是呼叫了這裡的樣式表生成的，於是

通過 xsltproc report.jtl > test.html，或者 ant 也可以。這個命令把Jmeter 的結果檔案轉換為 HTML 的報告。結果如下：

這裡雖然能生成 HTML 報告了，但是這個報告太弱了，基本不能用，包含的引數太少。所以需要對這個報告進行擴充套件。因為 Jmeter 本身的聚合報告的資料還是比較全的，

因此打算按照那個報告的值進行擴充套件。

xsltproc，xlst介紹

XSL 指擴充套件樣式表語言（EXtensible Stylesheet Language），把 XML 轉換為HTML 用的就是 xls 編寫的樣式表，所以如果要擴充套件這個報告，首先要對 xls

xsltproc 是一個快速 XSLT 引擎,它可以將通過 XSL 層疊樣式表把 XML 轉換為相應格式的檔案，比如：HTML,XHTML,PDF

比如將 XML 轉換為 HTML，使用格式如下：

xsltproc xsl-html.xsl hoto.xml -o html.html （這裡還可以直接把樣式表文件寫入 jtl 檔案的 href 屬性中，直觀的告訴這個 XML 用哪個樣式表）

xls 中查詢 XML 用的 xpath，因此還需要對 xpath 熟悉，xsltproc 這個引擎用的是 xpath1.0 版本，因此在樣式表中使用 xpath 是不能使用 xpath2.0 的函式
和一些屬性。
個人對 xpath 還算熟悉，但是對 xls 一點也不熟悉，沒辦法為了能夠擴充套件報告，直接學習 xls 和 xpath。（關於 xls 會再寫一遍部落格介紹，順便把使用過程中
的問題和經驗彙總）

如果直接使用 ant 和 Jmeter 整合後也是可以直接生成的，但是 ant 轉換 HTML 的引擎也是隻支援 xpath1.0，後來經過了解大部分的引擎都不支援xpath2.0，所以
期中不能使用 xpath2.0 的函式。

90%Line 時間
為了能夠顯示 90%Line 的時間，首先要對這個指標熟悉，這個指標值得是一組資料，在 90% 的位置的資料的時間，所以我們擴充套件的時候只要知道了 90%
位置的索引，那麼就能取得這個值了。
以下是部分關鍵程式碼

<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>

這裡主要是獲得時間元素的集合，以及 90%line 的位置，有了這兩個引數後就可以進行後續的擴充套件了，擴充套件後的效果圖如下：

因為 90%Line 和 95%Line,99%Line 計算原理都是一致的，因此只要計算出一個值其他的值也很好計算

QPS 擴充套件

Jmeter 的具合報告有 Throughput 這個值，這個在 loadrunner 中是表示為吞吐量的，這裡可以表示 QPS 或者 TPS（在使用了事務的情況下），個人把這個稱為 QPS，因為更直觀。

和 %90Line 同樣的道理，首先必須知道這個值是怎麼計算出來，經過查詢資料和官網的比較，發現這個值是通過如下的公式計算出來的：

官網的截圖：

Throughput = (number of requests) / (total time)
total time = 測試結束時間 - 測試開始時間
測試結束時間 = MAX(請求開始時間 + Elapsed Time)
測試開始時間 = MIN(請求開始時間)

知道了公式，那麼計算就容易了，以下是關鍵程式碼：

<xsl:variable name="nodeThroughput">
                <xsl:call-template name="throughput">
                    <xsl:with-param name="nodes" select="/testResults/*/@ts" />
                    <xsl:with-param name="count" select="$allCount" />
                </xsl:call-template>
            </xsl:variable>

擴充套件後的結果如下：

吞吐量擴充套件

在 loadrunner 中吞吐量就是 Throughput，在 Jmeter 的聚合報告中最後一列的值就是 loadrunner 中的 Throughput，為了便於區分，我把這裡的值稱為Throughput，

也就是吞吐量。

經過查詢資料發現吞吐量的計算和 QPS 的計算公式是一樣的，因為也就是如下的公式：

Throughput = (請求的總位元組數) / (total time)

這裡的 total time 計算和 QPS 是一樣的，而總位元組數直接把所有請求的加起來即可，關鍵程式碼如下：

<xsl:variable name="nodeKB">
                <xsl:call-template name="throughput">
                    <xsl:with-param name="nodes" select="/testResults/*/@ts" />
                    <xsl:with-param name="count" select="sum(/testResults/*/@by) div 1024" />
                </xsl:call-template>
            </xsl:variable>

因為這裡顯示的位元組，最後的結果我打算以 KB 的單位顯示，因此這裡需要除以1024，擴充套件後的結果如下

TPS擴充套件

TPS 在 Jmeter 中雖然某些情況和 QPS 是一致的，但是還是有不一致的地方，因此這裡也需要擴充套件，這樣的結果看著更清晰明瞭。

首先和其他的引數擴充套件一樣，需要知道計算公式，這裡的計算公式和 QPS 也是一樣的，只是資料的集合不一樣，以下是擴充套件後的效果。

在擴充套件的過程中進一步發現 Jmeter 的聚合結果中最後的”總體“一行在某些情況下計算的數值是不準確的。如果指令碼中不包含事務，那麼這裡的結果是準確的，如果都包含事務並且把

Generate parent sample 選中後這裡的結果也是準確的，在指令碼中有事務並且沒有選中 Generate parent sample，或者有些有事務有些沒有時，這時的結果就不準確了，因為檢視計算

方式發現它把所有的請求都算進去了。

比如，一個 jtl 檔案中即包含 HTTP 請求也包含事務，因為事務只是對之前請求的一個統計，本身是不傳送請求的，所以計算總的吞吐量、QPS，TPS 時是不能這麼算的。

所以在擴充套件的過程中分成了兩個樣式表，一個樣式表處理包含事務，或者沒有事務的情況，這時的結果以 QPS 衡量；一個樣式表處理全都是事務的情況，這時候的結果以 TPS 衡量，這樣

就準確了。

測試

擴充套件了好幾個指標，這些指標的正確性如何呢？需要在多種情況下進行測試，經過測試後各個指標都是正確的。但是還沒有在大的資料量級別下測試，如果測試後發現哪裡會有問題，會及時

更改。

切記：由於樣式表中是按照 lb 進行請求區分的，因此這裡的 lable 不能重複，本身也不應該重複，包括 Jmeter 的聚合報告都是以 lable 進行區分的

PS：在擴充套件過程中的難點一是公式如何計算的，二是xls這個 指擴充套件樣式表語言不是很熟悉，本身也有很多限制，會在下個部落格中說明。但是用過後感覺還是很不錯的既熟悉了 xpath 還熟悉了 xls。

三是需要對 Jmeter 的測試結果檔案每個欄位戴錶什麼意思熟悉，這樣才能定製更多的指標，這個也會在單獨的部落格中說明

OneAPM Mobile Insight 以真實使用者體驗為度量標準進行 Crash 分析，監控網路請求及網路錯誤，提升使用者留存。訪問 OneAPM 官方網站感受更多應用效能優化體驗，想閱讀更多技術文章，請訪問 OneAPM 官方技術部落格。